From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 00:38:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74893106566C for ; Sun, 4 Jan 2009 00:38:02 +0000 (UTC) (envelope-from christof.schulze@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id D3E758FC12 for ; Sun, 4 Jan 2009 00:38:01 +0000 (UTC) (envelope-from christof.schulze@gmx.net) Received: (qmail invoked by alias); 04 Jan 2009 00:11:15 -0000 Received: from p54B6DF1D.dip.t-dialin.net (EHLO klausdieter0815.dyndns.org) [84.182.223.29] by mail.gmx.net (mp037) with SMTP; 04 Jan 2009 01:11:15 +0100 X-Authenticated: #3549759 X-Provags-ID: V01U2FsdGVkX195PHIoHuV53PdfY9wDTzeV6cpR3Oxv9c0o7AuBxm GazMgAYxfZpZWl Received: from ccschu935 (localhost [127.0.0.1]) by myhost.mydomain.de (Postfix) with ESMTP id CC71F261 for ; Sun, 4 Jan 2009 01:11:09 +0100 (CET) Date: Sun, 4 Jan 2009 01:11:07 +0100 From: Christof Schulze To: freebsd-current@freebsd.org Message-ID: <20090104011107.143069c3@ccschu935> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: kldload exec format error on amd64 freebsd-7.1-rc2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 00:38:02 -0000 Hello Everyone, this is my first post to the list so I hope I am not asking a dumb question even though I searched. I am trying to get the Ricoh SD Card reader sdhci0@pci0:5:9:2: class=0x080500 card=0xc024144d chip=0x08221180 rev=0x18 hdr=0x00 to work with the driver written by Alex Motin. The sdhci and mmc code compiles fine and loads into my kernel. The mmcsd module which as I understand things is needed to recognize an inserted SD Card, attach a device name to it etc compiles fine (I ran make clean beforehand) but I cannot kldload it: # kldload mmcsd kldload: can't load mmcsd: Exec format error # dmesg |tail g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 link_elf_obj: symbol kproc_create undefined kldload: /boot/kernel/mmcsd.ko: Unsupported file type link_elf_obj: symbol kproc_create undefined kldload: /boot/kernel/mmcsd.ko: Unsupported file type I ran out of ideas and things to try so maybe someone on this list still has more ideas than I do and is willing to share them. I would greatly appreciate it and of course I will provide further info if needed. These are the stats for the system: # uname -a FreeBSD ccschu935 7.1-RC2 FreeBSD 7.1-RC2 #0: Tue Dec 23 11:42:13 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 # kldstat Id Refs Address Size Name 1 39 0xffffffff80100000 b6fd98 kernel 2 1 0xffffffff80c70000 f5b78 zfs.ko 3 2 0xffffffff80d66000 2c00 opensolaris.ko 4 2 0xffffffff80d69000 38f00 linux.ko 5 1 0xffffffff80da2000 f2a8 if_ipw.ko 6 1 0xffffffff80db2000 1a940 snd_hda.ko 7 2 0xffffffff80dcd000 67470 sound.ko 8 1 0xffffffff80e35000 4fe0 atapicam.ko 9 1 0xffffffff80e3a000 33f50 ipw_bss.ko 10 1 0xffffffff80e6e000 32000 ipw_ibss.ko 11 1 0xffffffff80ea0000 30de8 ipw_monitor.ko 12 1 0xffffffffaf67a000 1076 daemon_saver.ko 13 1 0xffffffffaf6c2000 734 rtc.ko 14 1 0xffffffffaf6c7000 4c7c i915.ko 15 1 0xffffffffaf6cc000 d7ec drm.ko 16 1 0xffffffffaf858000 8eb2 if_wpi.ko 17 1 0xffffffffaf931000 24b2e wpifw.ko 18 1 0xffffffffaf7db000 3c65 sdhci.ko 19 1 0xffffffffafa8c000 4241 mmc.ko Regards Christof Schulze -- From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 05:20:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 696E61065670 for ; Sun, 4 Jan 2009 05:20:33 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 20B228FC0C for ; Sun, 4 Jan 2009 05:20:33 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-4.local ([10.0.0.194]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n045KW3O036184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Jan 2009 21:20:32 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <49604720.4070703@freebsd.org> Date: Sat, 03 Jan 2009 21:20:32 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Randy Bush References: <495F0B2D.7060701@psg.com> In-Reply-To: <495F0B2D.7060701@psg.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: current@freebsd.org Subject: Re: hosts on bridged wlan can not reliably see each other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 05:20:33 -0000 Randy Bush wrote: > soekris 5501 of nov 28, pre new arp > > problem description > o all hosts on the wireless can get outside, no problem > o they can also get to wired devices on vr[1-3] > o they can reliably not see/ping/... each other on the wireless > o the soekris can ping them all > o higher layers are worse > o the messages on this list worry me about upgrading this week, > as this is my home gate to the world and somewhat complex > (bridge, tunnel, pppoe, ...), whereas the mass of servers are > all pretty straightforward. > > .----------------. > | | > | b ---ath0| 192.168.0.0/24 > | r | > ext iij | i --- vr1| LAN hosts, > PPP/NAT ---|vr0--- d | > WAN | g --- vr2| DHCP Clients > | e | > | 0 --- vr3| pptp 200-209 > | | > `----------------' > > ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on > pci0 > ath0: [ITHREAD] > ath0: WARNING: using obsoleted if_watchdog interface > ath0: mac 5.9 phy 4.3 radio 3.6 > > # uname -a > FreeBSD soek0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Fri Nov 28 > 19:16:10 UTC 2008 root@soek0.psg.com:/usr/obj/usr/src/sys/SOEK0 i386 > > wlans_ath0="wlan0 wlan1" > create_args_wlan0="wlanmode hostap channel 11 ssid rgnet-aden wep wepkey > arbitrarykeys weptxkey 1 media autoselect mode 11g up" > cloned_interfaces=bridge0 > ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 addm > wlan1 up" > ifconfig_vr1=up > ifconfig_vr2=up > ifconfig_vr3=up > gateway_enable=YES > > the soekris can see them all > > # arp -an > ? (192.168.0.10) at 00:15:c5:4a:6f:c5 on bridge0 [bridge] > ? (192.168.0.12) at 00:1e:52:70:b6:36 on bridge0 [bridge] > ? (192.168.0.13) at 00:15:00:10:ed:09 on bridge0 [bridge] > ? (192.168.0.17) at 00:0d:65:27:bd:f2 on bridge0 [bridge] > ? (192.168.0.128) at 00:23:12:fc:39:b9 on bridge0 [bridge] > ? (192.168.0.129) at 00:23:df:6a:dc:9b on bridge0 [bridge] > > and gets log entries of > > Jan 2 00:01:09 soek kernel: rtfree: 0xc2e803c0 has 1 refs > Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs > Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs > Jan 2 00:01:16 soek kernel: arp_proxy: ignoring request from > 192.168.0.10 via vr2, expecting bridge0 > > what more should i do to debug? Use tcpdump to track where the packets are visible. If this is a wireless issue you will have stats to identify drops as well as the usual debug facilities. Sam From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 05:44:45 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B82A21065676; Sun, 4 Jan 2009 05:44:45 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9158FC0C; Sun, 4 Jan 2009 05:44:45 +0000 (UTC) (envelope-from randy@psg.com) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LJLn1-000NaT-Fs; Sun, 04 Jan 2009 05:44:44 +0000 Message-ID: <49604CCA.7050301@psg.com> Date: Sun, 04 Jan 2009 14:44:42 +0900 From: Randy Bush User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: Sam Leffler References: <495F0B2D.7060701@psg.com> <49604720.4070703@freebsd.org> In-Reply-To: <49604720.4070703@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: hosts on bridged wlan can not reliably see each other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 05:44:46 -0000 On 09.01.04 14:20, Sam Leffler wrote: > Randy Bush wrote: >> soekris 5501 of nov 28, pre new arp >> >> problem description >> o all hosts on the wireless can get outside, no problem >> o they can also get to wired devices on vr[1-3] >> o they can reliably not see/ping/... each other on the wireless >> o the soekris can ping them all >> o higher layers are worse >> o the messages on this list worry me about upgrading this week, >> as this is my home gate to the world and somewhat complex >> (bridge, tunnel, pppoe, ...), whereas the mass of servers are >> all pretty straightforward. >> >> .----------------. >> | | >> | b ---ath0| 192.168.0.0/24 >> | r | >> ext iij | i --- vr1| LAN hosts, >> PPP/NAT ---|vr0--- d | >> WAN | g --- vr2| DHCP Clients >> | e | >> | 0 --- vr3| pptp 200-209 >> | | >> `----------------' >> >> ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on >> pci0 >> ath0: [ITHREAD] >> ath0: WARNING: using obsoleted if_watchdog interface >> ath0: mac 5.9 phy 4.3 radio 3.6 >> >> # uname -a >> FreeBSD soek0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Fri Nov 28 >> 19:16:10 UTC 2008 root@soek0.psg.com:/usr/obj/usr/src/sys/SOEK0 i386 >> >> wlans_ath0="wlan0 wlan1" >> create_args_wlan0="wlanmode hostap channel 11 ssid rgnet-aden wep wepkey >> arbitrarykeys weptxkey 1 media autoselect mode 11g up" >> cloned_interfaces=bridge0 >> ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 addm >> wlan1 up" >> ifconfig_vr1=up >> ifconfig_vr2=up >> ifconfig_vr3=up >> gateway_enable=YES >> >> the soekris can see them all >> >> # arp -an >> ? (192.168.0.10) at 00:15:c5:4a:6f:c5 on bridge0 [bridge] >> ? (192.168.0.12) at 00:1e:52:70:b6:36 on bridge0 [bridge] >> ? (192.168.0.13) at 00:15:00:10:ed:09 on bridge0 [bridge] >> ? (192.168.0.17) at 00:0d:65:27:bd:f2 on bridge0 [bridge] >> ? (192.168.0.128) at 00:23:12:fc:39:b9 on bridge0 [bridge] >> ? (192.168.0.129) at 00:23:df:6a:dc:9b on bridge0 [bridge] >> >> and gets log entries of >> >> Jan 2 00:01:09 soek kernel: rtfree: 0xc2e803c0 has 1 refs >> Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs >> Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs >> Jan 2 00:01:16 soek kernel: arp_proxy: ignoring request from >> 192.168.0.10 via vr2, expecting bridge0 >> >> what more should i do to debug? > > Use tcpdump to track where the packets are visible. If this is a > wireless issue you will have stats to identify drops as well as the > usual debug facilities. sorry, this is why i was arp conscious soekris# ping 192.168.0.129 PING 192.168.0.129 (192.168.0.129): 56 data bytes 64 bytes from 192.168.0.129: icmp_seq=0 ttl=64 time=113.103 ms 64 bytes from 192.168.0.129: icmp_seq=1 ttl=64 time=349.680 ms 64 bytes from 192.168.0.129: icmp_seq=2 ttl=64 time=366.531 ms ^C --- 192.168.0.129 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 113.103/276.438/366.531/115.700 ms then, when pinging (unsuccessfully) from another host on the wireless soekris# tcpdump -i bridge0 host 192.168.0.129 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bridge0, link-type EN10MB (Ethernet), capture size 96 bytes 05:40:28.486793 arp who-has 192.168.0.129 tell 192.168.0.12 05:40:29.486335 arp who-has 192.168.0.129 tell 192.168.0.12 05:40:30.486776 arp who-has 192.168.0.129 tell 192.168.0.12 05:40:31.487058 arp who-has 192.168.0.129 tell 192.168.0.12 05:40:32.487227 arp who-has 192.168.0.129 tell 192.168.0.12 ^C 5 packets captured 2192 packets received by filter 0 packets dropped by kernel ath ierrors are an old fact of life here, see a thread from almost a year ago soekris# netstat -ni Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll vr0 1500 00:00:24:c8:b3:28 139171779 0 102370058 0 0 vr1 1500 00:00:24:c8:b3:29 0 0 0 0 0 vr2 1500 00:00:24:c8:b3:2a 11034998 0 54497266 0 0 vr3 1500 00:00:24:c8:b3:2b 246912 0 321750 0 0 ath0 2290 00:0b:6b:83:59:25 192042747 20665363 77278643 27 0 lo0 16384 111523 0 111523 0 0 lo0 16384 fe80:6::1/64 fe80:6::1 0 - 0 - - lo0 16384 ::1/128 ::1 0 - 0 - - lo0 16384 127.0.0.0/8 127.0.0.1 111523 - 111523 - - bridg 1500 d6:9b:35:b7:7c:bd 92627892 0 131886570 0 0 bridg 1500 192.168.0.0/2 192.168.0.1 231764 - 146544 - - wlan0 1500 00:0b:6b:83:59:25 81345984 0 77084603 192714 0 wlan1 1500 00:0b:6b:83:59:25 0 0 0 0 0 tun0 1454 138915852 0 102337216 0 0 tun0 1454 210.138.216.5 210.138.216.50 7709196 - 10317194 - - randy From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 06:30:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 016BA106566B for ; Sun, 4 Jan 2009 06:30:11 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id A81218FC16 for ; Sun, 4 Jan 2009 06:30:10 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-4.local ([10.0.0.194]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n046U9Tv036385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Jan 2009 22:30:10 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <49605770.1050702@freebsd.org> Date: Sat, 03 Jan 2009 22:30:08 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Randy Bush References: <495F0B2D.7060701@psg.com> <49604720.4070703@freebsd.org> <49604CCA.7050301@psg.com> In-Reply-To: <49604CCA.7050301@psg.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: current@freebsd.org Subject: Re: hosts on bridged wlan can not reliably see each other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 06:30:11 -0000 Randy Bush wrote: > On 09.01.04 14:20, Sam Leffler wrote: >> Randy Bush wrote: >>> soekris 5501 of nov 28, pre new arp >>> >>> problem description >>> o all hosts on the wireless can get outside, no problem >>> o they can also get to wired devices on vr[1-3] >>> o they can reliably not see/ping/... each other on the wireless >>> o the soekris can ping them all >>> o higher layers are worse >>> o the messages on this list worry me about upgrading this week, >>> as this is my home gate to the world and somewhat complex >>> (bridge, tunnel, pppoe, ...), whereas the mass of servers are >>> all pretty straightforward. >>> >>> .----------------. >>> | | >>> | b ---ath0| 192.168.0.0/24 >>> | r | >>> ext iij | i --- vr1| LAN hosts, >>> PPP/NAT ---|vr0--- d | >>> WAN | g --- vr2| DHCP Clients >>> | e | >>> | 0 --- vr3| pptp 200-209 >>> | | >>> `----------------' >>> >>> ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on >>> pci0 >>> ath0: [ITHREAD] >>> ath0: WARNING: using obsoleted if_watchdog interface >>> ath0: mac 5.9 phy 4.3 radio 3.6 >>> >>> # uname -a >>> FreeBSD soek0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Fri Nov 28 >>> 19:16:10 UTC 2008 root@soek0.psg.com:/usr/obj/usr/src/sys/SOEK0 >>> i386 >>> >>> wlans_ath0="wlan0 wlan1" >>> create_args_wlan0="wlanmode hostap channel 11 ssid rgnet-aden wep wepkey >>> arbitrarykeys weptxkey 1 media autoselect mode 11g up" >>> cloned_interfaces=bridge0 >>> ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 addm >>> wlan1 up" >>> ifconfig_vr1=up >>> ifconfig_vr2=up >>> ifconfig_vr3=up >>> gateway_enable=YES >>> >>> the soekris can see them all >>> >>> # arp -an >>> ? (192.168.0.10) at 00:15:c5:4a:6f:c5 on bridge0 [bridge] >>> ? (192.168.0.12) at 00:1e:52:70:b6:36 on bridge0 [bridge] >>> ? (192.168.0.13) at 00:15:00:10:ed:09 on bridge0 [bridge] >>> ? (192.168.0.17) at 00:0d:65:27:bd:f2 on bridge0 [bridge] >>> ? (192.168.0.128) at 00:23:12:fc:39:b9 on bridge0 [bridge] >>> ? (192.168.0.129) at 00:23:df:6a:dc:9b on bridge0 [bridge] >>> >>> and gets log entries of >>> >>> Jan 2 00:01:09 soek kernel: rtfree: 0xc2e803c0 has 1 refs >>> Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs >>> Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs >>> Jan 2 00:01:16 soek kernel: arp_proxy: ignoring request from >>> 192.168.0.10 via vr2, expecting bridge0 >>> >>> what more should i do to debug? >> >> Use tcpdump to track where the packets are visible. If this is a >> wireless issue you will have stats to identify drops as well as the >> usual debug facilities. > > sorry, this is why i was arp conscious > > soekris# ping 192.168.0.129 > PING 192.168.0.129 (192.168.0.129): 56 data bytes > 64 bytes from 192.168.0.129: icmp_seq=0 ttl=64 time=113.103 ms > 64 bytes from 192.168.0.129: icmp_seq=1 ttl=64 time=349.680 ms > 64 bytes from 192.168.0.129: icmp_seq=2 ttl=64 time=366.531 ms > ^C > --- 192.168.0.129 ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 113.103/276.438/366.531/115.700 ms > > then, when pinging (unsuccessfully) from another host on the wireless > > soekris# tcpdump -i bridge0 host 192.168.0.129 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on bridge0, link-type EN10MB (Ethernet), capture size 96 bytes > 05:40:28.486793 arp who-has 192.168.0.129 tell 192.168.0.12 > 05:40:29.486335 arp who-has 192.168.0.129 tell 192.168.0.12 > 05:40:30.486776 arp who-has 192.168.0.129 tell 192.168.0.12 > 05:40:31.487058 arp who-has 192.168.0.129 tell 192.168.0.12 > 05:40:32.487227 arp who-has 192.168.0.129 tell 192.168.0.12 > ^C > 5 packets captured > 2192 packets received by filter > 0 packets dropped by kernel > > > ath ierrors are an old fact of life here, see a thread from almost a > year ago > > soekris# netstat -ni > Name Mtu Network Address Ipkts Ierrs Opkts > Oerrs Coll > vr0 1500 00:00:24:c8:b3:28 139171779 0 102370058 > 0 0 > vr1 1500 00:00:24:c8:b3:29 0 0 0 0 0 > vr2 1500 00:00:24:c8:b3:2a 11034998 0 54497266 0 0 > vr3 1500 00:00:24:c8:b3:2b 246912 0 321750 0 0 > ath0 2290 00:0b:6b:83:59:25 192042747 20665363 77278643 > 27 0 > lo0 16384 111523 0 111523 0 0 > lo0 16384 fe80:6::1/64 fe80:6::1 0 - 0 - - > lo0 16384 ::1/128 ::1 0 - 0 - - > lo0 16384 127.0.0.0/8 127.0.0.1 111523 - 111523 - - > bridg 1500 d6:9b:35:b7:7c:bd 92627892 0 131886570 > 0 0 > bridg 1500 192.168.0.0/2 192.168.0.1 231764 - 146544 - - > wlan0 1500 00:0b:6b:83:59:25 81345984 0 77084603 > 192714 0 > wlan1 1500 00:0b:6b:83:59:25 0 0 0 0 0 > tun0 1454 138915852 0 102337216 > 0 0 > tun0 1454 210.138.216.5 210.138.216.50 7709196 - 10317194 - - > > > randy > > I don't see you looking on the wireless interface to see if the arp who-has packet goes out. You know it hit the bridge from the wireless sta but not that it went out over the wireless interface. If you don't see it hit the air then look for a reason for a drop. wlanstats should show you and/or wlandebug +output. Looking at the mac addresses registered w/ the bridge might also tell you where packets are being sent. BTW I see an ath0 interface in your diagram but wlan0 and wlan1 in your netstat output. I'm guessing your setup is confused but you haven't provided the info to be sure. Sam From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 06:46:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E7AE1065670; Sun, 4 Jan 2009 06:46:25 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id E3E3F8FC08; Sun, 4 Jan 2009 06:46:24 +0000 (UTC) (envelope-from randy@psg.com) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LJMkh-000NeI-Bm; Sun, 04 Jan 2009 06:46:23 +0000 Message-ID: <49605B3D.50403@psg.com> Date: Sun, 04 Jan 2009 15:46:21 +0900 From: Randy Bush User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: Sam Leffler References: <495F0B2D.7060701@psg.com> <49604720.4070703@freebsd.org> <49604CCA.7050301@psg.com> <49605770.1050702@freebsd.org> In-Reply-To: <49605770.1050702@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: hosts on bridged wlan can not reliably see each other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 06:46:25 -0000 On 09.01.04 15:30, Sam Leffler wrote: > Randy Bush wrote: >> On 09.01.04 14:20, Sam Leffler wrote: >>> Randy Bush wrote: >>>> soekris 5501 of nov 28, pre new arp >>>> >>>> problem description >>>> o all hosts on the wireless can get outside, no problem >>>> o they can also get to wired devices on vr[1-3] >>>> o they can reliably not see/ping/... each other on the wireless >>>> o the soekris can ping them all >>>> o higher layers are worse >>>> o the messages on this list worry me about upgrading this week, >>>> as this is my home gate to the world and somewhat complex >>>> (bridge, tunnel, pppoe, ...), whereas the mass of servers are >>>> all pretty straightforward. >>>> >>>> .----------------. >>>> | | >>>> | b ---ath0| 192.168.0.0/24 >>>> | r | >>>> ext iij | i --- vr1| LAN hosts, >>>> PPP/NAT ---|vr0--- d | >>>> WAN | g --- vr2| DHCP Clients >>>> | e | >>>> | 0 --- vr3| pptp 200-209 >>>> | | >>>> `----------------' >>>> >>>> ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on >>>> pci0 >>>> ath0: [ITHREAD] >>>> ath0: WARNING: using obsoleted if_watchdog interface >>>> ath0: mac 5.9 phy 4.3 radio 3.6 >>>> >>>> # uname -a >>>> FreeBSD soek0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Fri Nov 28 >>>> 19:16:10 UTC 2008 root@soek0.psg.com:/usr/obj/usr/src/sys/SOEK0 >>>> i386 >>>> >>>> wlans_ath0="wlan0 wlan1" >>>> create_args_wlan0="wlanmode hostap channel 11 ssid rgnet-aden wep wepkey >>>> arbitrarykeys weptxkey 1 media autoselect mode 11g up" >>>> cloned_interfaces=bridge0 >>>> ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 addm >>>> wlan1 up" >>>> ifconfig_vr1=up >>>> ifconfig_vr2=up >>>> ifconfig_vr3=up >>>> gateway_enable=YES >>>> >>>> the soekris can see them all >>>> >>>> # arp -an >>>> ? (192.168.0.10) at 00:15:c5:4a:6f:c5 on bridge0 [bridge] >>>> ? (192.168.0.12) at 00:1e:52:70:b6:36 on bridge0 [bridge] >>>> ? (192.168.0.13) at 00:15:00:10:ed:09 on bridge0 [bridge] >>>> ? (192.168.0.17) at 00:0d:65:27:bd:f2 on bridge0 [bridge] >>>> ? (192.168.0.128) at 00:23:12:fc:39:b9 on bridge0 [bridge] >>>> ? (192.168.0.129) at 00:23:df:6a:dc:9b on bridge0 [bridge] >>>> >>>> and gets log entries of >>>> >>>> Jan 2 00:01:09 soek kernel: rtfree: 0xc2e803c0 has 1 refs >>>> Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs >>>> Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs >>>> Jan 2 00:01:16 soek kernel: arp_proxy: ignoring request from >>>> 192.168.0.10 via vr2, expecting bridge0 >>>> >>>> what more should i do to debug? >>> Use tcpdump to track where the packets are visible. If this is a >>> wireless issue you will have stats to identify drops as well as the >>> usual debug facilities. >> sorry, this is why i was arp conscious >> >> soekris# ping 192.168.0.129 >> PING 192.168.0.129 (192.168.0.129): 56 data bytes >> 64 bytes from 192.168.0.129: icmp_seq=0 ttl=64 time=113.103 ms >> 64 bytes from 192.168.0.129: icmp_seq=1 ttl=64 time=349.680 ms >> 64 bytes from 192.168.0.129: icmp_seq=2 ttl=64 time=366.531 ms >> ^C >> --- 192.168.0.129 ping statistics --- >> 3 packets transmitted, 3 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 113.103/276.438/366.531/115.700 ms >> >> then, when pinging (unsuccessfully) from another host on the wireless >> >> soekris# tcpdump -i bridge0 host 192.168.0.129 >> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >> listening on bridge0, link-type EN10MB (Ethernet), capture size 96 bytes >> 05:40:28.486793 arp who-has 192.168.0.129 tell 192.168.0.12 >> 05:40:29.486335 arp who-has 192.168.0.129 tell 192.168.0.12 >> 05:40:30.486776 arp who-has 192.168.0.129 tell 192.168.0.12 >> 05:40:31.487058 arp who-has 192.168.0.129 tell 192.168.0.12 >> 05:40:32.487227 arp who-has 192.168.0.129 tell 192.168.0.12 >> ^C >> 5 packets captured >> 2192 packets received by filter >> 0 packets dropped by kernel >> >> >> ath ierrors are an old fact of life here, see a thread from almost a >> year ago >> >> soekris# netstat -ni >> Name Mtu Network Address Ipkts Ierrs Opkts >> Oerrs Coll >> vr0 1500 00:00:24:c8:b3:28 139171779 0 102370058 >> 0 0 >> vr1 1500 00:00:24:c8:b3:29 0 0 0 0 0 >> vr2 1500 00:00:24:c8:b3:2a 11034998 0 54497266 0 0 >> vr3 1500 00:00:24:c8:b3:2b 246912 0 321750 0 0 >> ath0 2290 00:0b:6b:83:59:25 192042747 20665363 77278643 >> 27 0 >> lo0 16384 111523 0 111523 0 0 >> lo0 16384 fe80:6::1/64 fe80:6::1 0 - 0 - - >> lo0 16384 ::1/128 ::1 0 - 0 - - >> lo0 16384 127.0.0.0/8 127.0.0.1 111523 - 111523 - - >> bridg 1500 d6:9b:35:b7:7c:bd 92627892 0 131886570 >> 0 0 >> bridg 1500 192.168.0.0/2 192.168.0.1 231764 - 146544 - - >> wlan0 1500 00:0b:6b:83:59:25 81345984 0 77084603 >> 192714 0 >> wlan1 1500 00:0b:6b:83:59:25 0 0 0 0 0 >> tun0 1454 138915852 0 102337216 >> 0 0 >> tun0 1454 210.138.216.5 210.138.216.50 7709196 - 10317194 - - >> >> >> randy >> >> > > I don't see you looking on the wireless interface to see if the arp > who-has packet goes out. You know it hit the bridge from the wireless > sta but not that it went out over the wireless interface. If you don't > see it hit the air then look for a reason for a drop. wlanstats should > show you and/or wlandebug +output. Looking at the mac addresses > registered w/ the bridge might also tell you where packets are being sent. the soekris sees all soek# arp -an soek0.psg.com:/root# ping 192.168.0.129 PING 192.168.0.129 (192.168.0.129): 56 data bytes 64 bytes from 192.168.0.129: icmp_seq=0 ttl=64 time=417.356 ms 64 bytes from 192.168.0.129: icmp_seq=1 ttl=64 time=482.347 ms 64 bytes from 192.168.0.129: icmp_seq=2 ttl=64 time=397.344 ms ^C --- 192.168.0.129 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 397.344/432.349/482.347/36.286 ms soek# arp -an ? (192.168.0.10) at 00:15:c5:4a:6f:c5 on bridge0 [bridge] ? (192.168.0.12) at 00:1e:52:70:b6:36 on bridge0 [bridge] ? (192.168.0.13) at 00:15:00:10:ed:09 on bridge0 [bridge] ? (192.168.0.17) at 00:0d:65:27:bd:f2 on bridge0 [bridge] ? (192.168.0.28) at 00:80:77:04:35:16 on bridge0 [bridge] ? (192.168.0.128) at 00:23:12:fc:39:b9 on bridge0 [bridge] ? (192.168.0.129) at 00:23:df:6a:dc:9b on bridge0 [bridge] but pinging from a macbook pro on same wireless (192.168.0.12) to the iphone (192.168.0.129) as seen from the soekris (192.168.0.1) Jan 4 06:33:13 soek kernel: rtfree: 0xc2e80000 has 1 refs Jan 4 06:33:14 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame, sta not associated (type 0x0806) Jan 4 06:33:14 soek kernel: arp_proxy: ignoring request from 192.168.0.12 via wlan0, expecting bridge0 Jan 4 06:33:14 soek kernel: rtfree: 0xc2e80000 has 1 refs Jan 4 06:33:15 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame, sta not associated (type 0x0806) Jan 4 06:33:15 soek kernel: arp_proxy: ignoring request from 192.168.0.12 via wlan0, expecting bridge0 Jan 4 06:33:15 soek kernel: rtfree: 0xc2e80000 has 1 refs Jan 4 06:33:16 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame, sta not associated (type 0x0806) Jan 4 06:33:16 soek kernel: arp_proxy: ignoring request from 192.168.0.12 via wlan0, expecting bridge0 Jan 4 06:33:16 soek kernel: rtfree: 0xc2e80000 has 1 refs Jan 4 06:33:39 soek kernel: wlan0: [01:00:5e:7f:ff:fa] discard frame, sta not associated (type 0x0800) Jan 4 06:33:44 soek kernel: wlan0: [01:00:0c:cc:cc:cc] discard frame, sta not associated (type 0x0074) Jan 4 06:33:45 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame, sta not associated (type 0x0800) > BTW I see an ath0 interface in your diagram but wlan0 and wlan1 in your > netstat output. did not update diagram when life changed six months ago . randy From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 09:39:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D87B4106564A for ; Sun, 4 Jan 2009 09:39:30 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 73AAB8FC0C for ; Sun, 4 Jan 2009 09:39:30 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id 5A68A8FC4F for ; Sun, 4 Jan 2009 12:39:28 +0300 (MSK) Received: from orion.SpringDaemons.com (drsun1.dialup.corbina.ru [85.21.245.235]) by mx0.deglitch.com (Postfix) with ESMTPA id EE73D8FC18; Sun, 4 Jan 2009 12:39:27 +0300 (MSK) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 24A043996C; Sun, 4 Jan 2009 12:41:52 +0300 (MSK) Date: Sun, 4 Jan 2009 12:41:41 +0300 From: Stanislav Sedov To: Christof Schulze Message-Id: <20090104124141.5d757262.stas@FreeBSD.org> In-Reply-To: <20090104011107.143069c3@ccschu935> References: <20090104011107.143069c3@ccschu935> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Jan 4 12:39:28 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 496083d0967001599314920 Cc: freebsd-current@freebsd.org Subject: Re: kldload exec format error on amd64 freebsd-7.1-rc2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 09:39:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 4 Jan 2009 01:11:07 +0100 Christof Schulze mentioned: > Hello Everyone, > > this is my first post to the list so I hope I am not asking a dumb > question even though I searched. > > I am trying to get the Ricoh SD Card reader > sdhci0@pci0:5:9:2: class=0x080500 card=0xc024144d chip=0x08221180 > rev=0x18 hdr=0x00 > to work with the driver written by Alex Motin. > The sdhci and mmc code compiles fine and loads into my kernel. > The mmcsd module which as I understand things is needed to recognize > an inserted SD Card, attach a device name to it etc compiles fine (I > ran make clean beforehand) but I cannot kldload it: > > # kldload mmcsd > kldload: can't load mmcsd: Exec format error > > # dmesg |tail > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > link_elf_obj: symbol kproc_create undefined > kldload: /boot/kernel/mmcsd.ko: Unsupported file type > link_elf_obj: symbol kproc_create undefined > kldload: /boot/kernel/mmcsd.ko: Unsupported file type > > I ran out of ideas and things to try so maybe someone on this list > still has more ideas than I do and is willing to share them. > I would greatly appreciate it and of course I will provide further > info if needed. > > These are the stats for the system: > > # uname -a > FreeBSD ccschu935 7.1-RC2 FreeBSD 7.1-RC2 #0: Tue Dec 23 11:42:13 UTC > 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > amd64 > > > # kldstat > Id Refs Address Size Name > 1 39 0xffffffff80100000 b6fd98 kernel > 2 1 0xffffffff80c70000 f5b78 zfs.ko > 3 2 0xffffffff80d66000 2c00 opensolaris.ko > 4 2 0xffffffff80d69000 38f00 linux.ko > 5 1 0xffffffff80da2000 f2a8 if_ipw.ko > 6 1 0xffffffff80db2000 1a940 snd_hda.ko > 7 2 0xffffffff80dcd000 67470 sound.ko > 8 1 0xffffffff80e35000 4fe0 atapicam.ko > 9 1 0xffffffff80e3a000 33f50 ipw_bss.ko > 10 1 0xffffffff80e6e000 32000 ipw_ibss.ko > 11 1 0xffffffff80ea0000 30de8 ipw_monitor.ko > 12 1 0xffffffffaf67a000 1076 daemon_saver.ko > 13 1 0xffffffffaf6c2000 734 rtc.ko > 14 1 0xffffffffaf6c7000 4c7c i915.ko > 15 1 0xffffffffaf6cc000 d7ec drm.ko > 16 1 0xffffffffaf858000 8eb2 if_wpi.ko > 17 1 0xffffffffaf931000 24b2e wpifw.ko > 18 1 0xffffffffaf7db000 3c65 sdhci.ko > 19 1 0xffffffffafa8c000 4241 mmc.ko > I think you took the code intended for CURRENT. E.g. kproc_create does not exists on 7.x. I believe there were some patches agains 7.x as well. You may try to ask mav for them too. The other way might be to update your system to CURRENT and try with it. If you'll take CURRENT kernel it should be able to run 7.x world without problems. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAklghGAACgkQK/VZk+smlYGtCQCeJjWsnZPwmHOTuHW+5dRrqjcE Xu4AnRpumhlywVKos5r9x7ZMJJxGmjXO =ByTp -----END PGP SIGNATURE----- !DSPAM:496083d0967001599314920! From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 10:48:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30C6B106564A for ; Sun, 4 Jan 2009 10:48:49 +0000 (UTC) (envelope-from christof.schulze@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 756938FC14 for ; Sun, 4 Jan 2009 10:48:48 +0000 (UTC) (envelope-from christof.schulze@gmx.net) Received: (qmail invoked by alias); 04 Jan 2009 10:48:46 -0000 Received: from p54B6CCD1.dip.t-dialin.net (EHLO klausdieter0815.dyndns.org) [84.182.204.209] by mail.gmx.net (mp061) with SMTP; 04 Jan 2009 11:48:46 +0100 X-Authenticated: #3549759 X-Provags-ID: V01U2FsdGVkX1/dl/lAxR3dv5qiJPCbOlmnr0mZ4sugZGbO8gCqxm jhknd8O6Ighhps Received: from ccschu935 (localhost [127.0.0.1]) by myhost.mydomain.de (Postfix) with ESMTP id B41B3279; Sun, 4 Jan 2009 11:48:45 +0100 (CET) Date: Sun, 4 Jan 2009 11:48:44 +0100 From: Christof Schulze To: Christof Schulze Message-ID: <20090104114844.06db3982@ccschu935> In-Reply-To: <20090104011107.143069c3@ccschu935> References: <20090104011107.143069c3@ccschu935> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.79 Cc: freebsd-current@freebsd.org Subject: Re: kldload exec format error on amd64 freebsd-7.1-rc2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 10:48:49 -0000 Hi again, something I forgot to mention: The mmcsd Code is not updated/changed compared to 7.1-rc2. Maybe this is the issue? If so where do I have to go and grab the correct sources? Regards Christof Schulze -- From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 15:00:26 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 994AD106564A; Sun, 4 Jan 2009 15:00:26 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (unknown [IPv6:2001:2f0:104:80a0:230:48ff:fe41:2455]) by mx1.freebsd.org (Postfix) with ESMTP id 352D68FC08; Sun, 4 Jan 2009 15:00:26 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.14.1/8.14.1/NinthNine) with SMTP id n04F0G9g039118; Mon, 5 Jan 2009 00:00:16 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Mon, 5 Jan 2009 00:00:14 +0900 From: Norikatsu Shigemura To: Hans Petter Selasky , Alfred Perlstein Message-Id: <20090105000014.a11a4d7f.nork@FreeBSD.org> In-Reply-To: <200901011233.15537.hselasky@c2i.net> References: <47297827@bb.ipt.ru> <20081231003115.GA22037@cdnetworks.co.kr> <20090101022845.4dc8bc27.nork@FreeBSD.org> <200901011233.15537.hselasky@c2i.net> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Mon, 05 Jan 2009 00:00:17 +0900 (JST) Cc: pyunyh@gmail.com, Boris Samorodov , freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: Call for axe(4) testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 15:00:26 -0000 Hi alfred and hps. On Thu, 1 Jan 2009 12:33:14 +0100 Hans Petter Selasky wrote: > > > the updated axe(4) in near future. Alternatively you can try > > > attached patch for USB2. > > I tried to buildkernel, and I got following messages: > > Sorry, I couldn't fix AXE_FLAG_LINK issue. > This is fixed in P4 and my private SVN. This patch is not yet in -current. > You need to rename the first flag in one of the axe header files > in /sys/dev/usb2/ethernet . I tested on r186730 by alfred@. 1. When my all devices are detached, OS is freeze(not panic). 2. GU-1000T doesn't work, but UE-200TX-G works well. From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 16:12:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D450106564A; Sun, 4 Jan 2009 16:12:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id AF9188FC1C; Sun, 4 Jan 2009 16:12:45 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=rREUrScshOl7G2h6aTFPgw==:17 a=qTXKKKJQCp0Lu8MCL7kA:9 a=xhfZWO0CZApgAuUy7sdOCzPBgGIA:4 a=LY0hPdMaydYA:10 Received: from [62.73.248.227] (account mc467741@c2i.net [62.73.248.227] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1174546606; Sun, 04 Jan 2009 17:12:43 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 4 Jan 2009 17:15:05 +0100 User-Agent: KMail/1.9.7 References: <47297827@bb.ipt.ru> <200901011233.15537.hselasky@c2i.net> <20090105000014.a11a4d7f.nork@FreeBSD.org> In-Reply-To: <20090105000014.a11a4d7f.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901041715.06163.hselasky@c2i.net> Cc: pyunyh@gmail.com, Boris Samorodov , Alfred Perlstein , Norikatsu Shigemura Subject: Re: Call for axe(4) testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 16:12:46 -0000 On Sunday 04 January 2009, Norikatsu Shigemura wrote: > Hi alfred and hps. > > > This is fixed in P4 and my private SVN. This patch is not yet in > > -current. You need to rename the first flag in one of the axe header > > files in /sys/dev/usb2/ethernet . > > I tested on r186730 by alfred@. > > 1. When my all devices are detached, OS is freeze(not panic). When are all devices detached? Can you explain your cable setup and where you unplug? Are there any USB HUBs involved? > 2. GU-1000T doesn't work, but UE-200TX-G works well. If your kernel is compiled with KDB, then try pressing CTRL+ALT+ESC to enter the debugger after the freeze. Then dump the backtrace of all the threads. Look for function names containing the word "axe". --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 16:35:11 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AC9510656DD; Sun, 4 Jan 2009 16:35:11 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (unknown [IPv6:2001:2f0:104:80a0:230:48ff:fe41:2455]) by mx1.freebsd.org (Postfix) with ESMTP id 34C0E8FC17; Sun, 4 Jan 2009 16:35:11 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.14.1/8.14.1/NinthNine) with SMTP id n04GZ28V047016; Mon, 5 Jan 2009 01:35:03 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Mon, 5 Jan 2009 01:35:01 +0900 From: Norikatsu Shigemura To: Hans Petter Selasky Message-Id: <20090105013501.dc07970c.nork@FreeBSD.org> In-Reply-To: <200901041715.06163.hselasky@c2i.net> References: <47297827@bb.ipt.ru> <200901011233.15537.hselasky@c2i.net> <20090105000014.a11a4d7f.nork@FreeBSD.org> <200901041715.06163.hselasky@c2i.net> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Mon, 05 Jan 2009 01:35:03 +0900 (JST) Cc: Alfred Perlstein , pyunyh@gmail.com, Boris Samorodov , freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: Call for axe(4) testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 16:35:12 -0000 Hi hps! On Sun, 4 Jan 2009 17:15:05 +0100 Hans Petter Selasky wrote: > > I tested on r186730 by alfred@. > > 1. When my all devices are detached, OS is freeze(not panic). > When are all devices detached? Can you explain your cable setup and where you > unplug? Are there any USB HUBs involved? Ah, I did following steps: foreach (GU-1000T UE-200TX-G LUA-U2-KTX) { Plug Unplug -> Freeze No key accept reset } On plug: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ugen1.2: at usbus1 axe0: on usbus1 miibus1: on axe0 ukphy0: PHY 16 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto axe0: Ethernet address: 00:90:cc:e7:6b:20 axe0: link state changed to DOWN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - devinfo -rv - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ehci0 pnpinfo vendor=0x8086 device=0x265c subvendor=0x10f7 subdevice=0x8338 class=0x0c0320 at slot=29 function=7 handle=\_SB_.PCI0.EHCI I/O memory addresses: 0xb0040000-0xb00403ff usbus1 ushub1 axe0 pnpinfo vendor=0x0b95 product=0x7720 devclass=0xff devsubclass=0xff sernum="" intclass=0xff intsubclass=0xff at port=1 interface=0 miibus1 ukphy0 pnpinfo oui=0xec6 model=0x1 rev=0x1 at phyno=16 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I have no USB HUBs, so I pluged into NOTE PC's USB port. usbconfig list - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > 2. GU-1000T doesn't work, but UE-200TX-G works well. > If your kernel is compiled with KDB, then try pressing CTRL+ALT+ESC to enter > the debugger after the freeze. Then dump the backtrace of all the threads. > Look for function names containing the word "axe". Any key(CTRL+ALT+DEL, etc..) didn't accept. But I didn't hit CTRL+ALT+ESC. So I'll try to hit it. From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 16:46:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1533106566C; Sun, 4 Jan 2009 16:46:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id B640E8FC17; Sun, 4 Jan 2009 16:46:00 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=rREUrScshOl7G2h6aTFPgw==:17 a=6I5d2MoRAAAA:8 a=TJTINTdxLCbxWTiCwvsA:9 a=fzhzrUtXWbQoV_MxR_UA:7 a=w0_RAtHTMak9oRCe3BWY5IsaNMwA:4 a=9aOQ2cSd83gA:10 a=SV7veod9ZcQA:10 a=50e4U0PicR4A:10 Received: from [62.73.248.227] (account mc467741@c2i.net [62.73.248.227] verified) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1178021491; Sun, 04 Jan 2009 17:45:58 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 4 Jan 2009 17:48:16 +0100 User-Agent: KMail/1.9.7 References: <47297827@bb.ipt.ru> <200901041715.06163.hselasky@c2i.net> <20090105013501.dc07970c.nork@FreeBSD.org> In-Reply-To: <20090105013501.dc07970c.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901041748.18798.hselasky@c2i.net> Cc: pyunyh@gmail.com, Boris Samorodov , Alfred Perlstein , Norikatsu Shigemura Subject: Re: Call for axe(4) testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 16:46:02 -0000 Hi, Also try to turn on axe debugging: sysctl hw.usb2.axe.debug=15 I suspect it is a problem with the miibus. Try waiting some time before you unplug the device (60 seconds). --HPS On Sunday 04 January 2009, Norikatsu Shigemura wrote: > Hi hps! > > On Sun, 4 Jan 2009 17:15:05 +0100 > > Hans Petter Selasky wrote: > > > I tested on r186730 by alfred@. > > > 1. When my all devices are detached, OS is freeze(not panic). > > > > When are all devices detached? Can you explain your cable setup and where > > you unplug? Are there any USB HUBs involved? > > Ah, I did following steps: > foreach (GU-1000T UE-200TX-G LUA-U2-KTX) { > Plug > Unplug -> Freeze > No key accept > reset > } > > On plug: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - ugen1.2: at usbus1 > axe0: on usbus1 > miibus1: on axe0 > ukphy0: PHY 16 on miibus1 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > axe0: Ethernet address: 00:90:cc:e7:6b:20 > axe0: link state changed to DOWN > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - > > devinfo -rv > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - ehci0 pnpinfo vendor=0x8086 device=0x265c subvendor=0x10f7 > subdevice=0x8338 class=0x0c0320 at slot=29 function=7 > handle=\_SB_.PCI0.EHCI I/O memory addresses: > 0xb0040000-0xb00403ff > usbus1 > ushub1 > axe0 pnpinfo vendor=0x0b95 product=0x7720 devclass=0xff > devsubclass=0xff sernum="" intclass=0xff intsubclass=0xff at port=1 > interface=0 miibus1 > ukphy0 pnpinfo oui=0xec6 model=0x1 rev=0x1 at phyno=16 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - > > I have no USB HUBs, so I pluged into NOTE PC's USB port. > > usbconfig list > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON ugen1.2: at usbus1, > cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - > > > > 2. GU-1000T doesn't work, but UE-200TX-G works well. > > > > If your kernel is compiled with KDB, then try pressing CTRL+ALT+ESC to > > enter the debugger after the freeze. Then dump the backtrace of all the > > threads. Look for function names containing the word "axe". > > Any key(CTRL+ALT+DEL, etc..) didn't accept. But I didn't hit > CTRL+ALT+ESC. So I'll try to hit it. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 17:18:22 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E6591065672; Sun, 4 Jan 2009 17:18:22 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (unknown [IPv6:2001:2f0:104:80a0:230:48ff:fe41:2455]) by mx1.freebsd.org (Postfix) with ESMTP id 04E5D8FC08; Sun, 4 Jan 2009 17:18:21 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.14.1/8.14.1/NinthNine) with SMTP id n04HIAte053324; Mon, 5 Jan 2009 02:18:11 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Mon, 5 Jan 2009 02:18:09 +0900 From: Norikatsu Shigemura To: Hans Petter Selasky Message-Id: <20090105021809.d3848b9c.nork@FreeBSD.org> In-Reply-To: <200901041748.18798.hselasky@c2i.net> References: <47297827@bb.ipt.ru> <200901041715.06163.hselasky@c2i.net> <20090105013501.dc07970c.nork@FreeBSD.org> <200901041748.18798.hselasky@c2i.net> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Mon, 05 Jan 2009 02:18:11 +0900 (JST) Cc: Alfred Perlstein , pyunyh@gmail.com, Boris Samorodov , freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: Call for axe(4) testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 17:18:22 -0000 Hi hps! On Sun, 4 Jan 2009 17:48:16 +0100 Hans Petter Selasky wrote: > Also try to turn on axe debugging: > sysctl hw.usb2.axe.debug=15 OK, I'll try. > I suspect it is a problem with the miibus. Yes, me too. after unplug: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - axe0: at ushub1, port 2, addr 3 (disconnected) ukphy0: detached miibus1: detached (freeze) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I hitted CTRL+ALT+ESC, but nothing. > Try waiting some time before you unplug the device (60 seconds). Thank you, I'll try with single user mode. From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 17:53:37 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E85291065670; Sun, 4 Jan 2009 17:53:37 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (unknown [IPv6:2001:2f0:104:80a0:230:48ff:fe41:2455]) by mx1.freebsd.org (Postfix) with ESMTP id 868788FC0C; Sun, 4 Jan 2009 17:53:37 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.14.1/8.14.1/NinthNine) with SMTP id n04HrVLu057609; Mon, 5 Jan 2009 02:53:31 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Mon, 5 Jan 2009 02:53:30 +0900 From: Norikatsu Shigemura To: Norikatsu Shigemura Message-Id: <20090105025330.68b22f63.nork@FreeBSD.org> In-Reply-To: <20090105021809.d3848b9c.nork@FreeBSD.org> References: <47297827@bb.ipt.ru> <200901041715.06163.hselasky@c2i.net> <20090105013501.dc07970c.nork@FreeBSD.org> <200901041748.18798.hselasky@c2i.net> <20090105021809.d3848b9c.nork@FreeBSD.org> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Mon, 05 Jan 2009 02:53:33 +0900 (JST) Cc: pyunyh@gmail.com, Alfred Perlstein , nork@FreeBSD.org, Hans Petter Selasky , Boris Samorodov , freebsd-current@FreeBSD.org Subject: Re: Call for axe(4) testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 17:53:38 -0000 Hi hps! On Mon, 5 Jan 2009 02:18:09 +0900 Norikatsu Shigemura wrote: > > Try waiting some time before you unplug the device (60 seconds). > Thank you, I'll try with single user mode. Hum... No different... (added some messages.., but...) From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 19:52:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80E991065674 for ; Sun, 4 Jan 2009 19:52:07 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (meestal-mk5-141.stack.nl [IPv6:2001:610:1108:5011::149]) by mx1.freebsd.org (Postfix) with ESMTP id 43FBC8FC1A for ; Sun, 4 Jan 2009 19:52:07 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id C4C713FCEE; Sun, 4 Jan 2009 20:52:05 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id B58BD22892; Sun, 4 Jan 2009 20:52:05 +0100 (CET) Date: Sun, 4 Jan 2009 20:52:05 +0100 From: Jilles Tjoelker To: Robert Huff Message-ID: <20090104195205.GA14447@stack.nl> References: <18783.28606.874391.376202@jerusalem.litteratus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18783.28606.874391.376202@jerusalem.litteratus.org> X-Operating-System: FreeBSD 7.1-PRERELEASE i386 User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: kernel complaint about /dev/pts (maybe) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 19:52:08 -0000 On Sat, Jan 03, 2009 at 09:01:34AM -0500, Robert Huff wrote: > On a box running > FreeBSD 7.0-CURRENT #2: Wed Nov 19 06:02:02 EST 2008 i386 > I am seeing a steady (though not particularly rapid) stream of: > comsat[3597]: '/' in "/dev/pts/X" > for X = [1-5]. > There is no mention of this in UPDATING, or (as far as I can > tell) in the lists. Google produces hits for NetBSD and Linux, but > none with either a) a real explanation or b) a real (as opposed to > half-ass) fix. > Doesn't /seem/ to be hurting anything ... but this is a test > box for a reason. > Anyone (please!) have the clue(s) I'm missing? NetBSD seems to have fixed this (properly) in their comsat 3.5 years ago, see http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/comsat/comsat.c.diff?r1=1.32&r2=1.33&only_with_tag=MAIN and http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=30170 A comment describing the potential issue was added over 10 years ago: http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/comsat/comsat.c.diff?r1=1.11&r2=1.12&only_with_tag=MAIN Briefly, the problem is that comsat thinks that "pts/1" is an attempt to access different files by writing into utmp. It needs to be taught that SVr4 style ptys are OK. NetBSD additionally checks the return value of tcgetattr() so it will never write to non-ttys. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 21:07:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1883510656C9 for ; Sun, 4 Jan 2009 21:07:50 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id C431A8FC1E for ; Sun, 4 Jan 2009 21:07:49 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 3572F9CB17F for ; Sun, 4 Jan 2009 21:50:59 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnQ6f1qd6tzz for ; Sun, 4 Jan 2009 21:50:57 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E33949CB22D for ; Sun, 4 Jan 2009 21:50:56 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n04KouZg042049 for current@freebsd.org; Sun, 4 Jan 2009 21:50:56 +0100 (CET) (envelope-from rdivacky) Date: Sun, 4 Jan 2009 21:50:56 +0100 From: Roman Divacky To: current@freebsd.org Message-ID: <20090104205056.GA41264@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: panic related to ipv6 (afaik) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 21:07:50 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi with r186748 I am getting this panic early on boot (hand rewritten): mi_startup() net_add_domain() ip6_ctloutput(0xsome_number, 0, 0, 0, 3,...) in ip6_ctloutput+0x55 (on i386), the panic is null reference I cant get a dump as dump device has not been defined yet ;( kernel from Tue Dec 30 23:07:56 CET 2008 (dont know the revision but should be within 10 minutes around the date) boots just fine I can 100% reproduce this so if you need anything that can be obtained from a DDB prompt just tell me. roman --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklhITAACgkQLVEj6D3CBEwjEgCfZBgvrRluwXpUq/g9p51iu4FL Xc8An1vyPYrmZ5kj+F1o8cdvdF5KUDtB =w1b4 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 21:14:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 135321065674; Sun, 4 Jan 2009 21:14:41 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id A46C68FC2D; Sun, 4 Jan 2009 21:14:40 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 9DEBB1CFE5; Sun, 4 Jan 2009 22:14:39 +0100 (CET) Date: Sun, 4 Jan 2009 22:14:39 +0100 From: Ed Schouten To: Roman Divacky Message-ID: <20090104211439.GJ14235@hoeg.nl> References: <20090104205056.GA41264@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OtZJUqNUNrB9XA/T" Content-Disposition: inline In-Reply-To: <20090104205056.GA41264@freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: panic related to ipv6 (afaik) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 21:14:41 -0000 --OtZJUqNUNrB9XA/T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Roman, * Roman Divacky wrote: > with r186748 I am getting this panic early on boot (hand rewritten): > > I had the same problem, but rwatson discovered the bug. He'll commit a fix in a couple of minutes. --=20 Ed Schouten WWW: http://80386.nl/ --OtZJUqNUNrB9XA/T Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklhJr8ACgkQ52SDGA2eCwVHjQCbBxNIs0BzDrR7ddaF8N1n6nU8 SXwAn1VzOYHidlwnPvjIiNVJpJEOrwdr =qvSP -----END PGP SIGNATURE----- --OtZJUqNUNrB9XA/T-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 21:35:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19072106566B for ; Sun, 4 Jan 2009 21:35:07 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.185]) by mx1.freebsd.org (Postfix) with ESMTP id C19978FC08 for ; Sun, 4 Jan 2009 21:35:06 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so4638167rne.12 for ; Sun, 04 Jan 2009 13:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=IcGyH5LpskQ7FTZ7qprGOHjHZjXv1DQOs2ZvaMwgMqs=; b=h1GD/32Lzzwfeoqc59k268DFbxs7zeiI7p2J7WzjbIJI/2ag291aO7xCsOioKIk+Ry jMdXAYfb0OlpU2lgEo2XhkyLVUPLYio20p66gf2E/mqA3rR+iWZ+VEdG6LZRVtvEU+Q6 SkRsm+i93PogFSwIfeRlsu42ANEIcNaj1d2u8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=RW4wrwXz8jkr/SKLiudqe7vPAGPhCe5ZXOy2A0CAXKj6hz6xMbZI1KCUq6QYcNou4F zZxmIcP0ABzUCa9RRqiRAgBrMqL68kXKRMOJmbOgTHAuiIlEfhLG2nFHw5f615tdOSOg zdckQBAkWxBrZCGPCUbI4rPnbnKwJvmLCCHIM= Received: by 10.150.217.14 with SMTP id p14mr19223927ybg.233.1231104905890; Sun, 04 Jan 2009 13:35:05 -0800 (PST) Received: by 10.150.98.19 with HTTP; Sun, 4 Jan 2009 13:35:05 -0800 (PST) Message-ID: <58c737d70901041335s72ec7335o298d7329fe8a2090@mail.gmail.com> Date: Sun, 4 Jan 2009 15:35:05 -0600 From: "Chris Ruiz" To: freebsd-current@freebsd.org In-Reply-To: <20090104211439.GJ14235@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20090104205056.GA41264@freebsd.org> <20090104211439.GJ14235@hoeg.nl> Subject: Re: panic related to ipv6 (afaik) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 21:35:07 -0000 On Sun, Jan 4, 2009 at 3:14 PM, Ed Schouten wrote: > Hello Roman, > > * Roman Divacky wrote: >> with r186748 I am getting this panic early on boot (hand rewritten): >> >> > > I had the same problem, but rwatson discovered the bug. He'll commit a > fix in a couple of minutes. > > -- > Ed Schouten > WWW: http://80386.nl/ > r186750 breaks the build: cc -c -O2 -fno-strict-aliasing -pipe -march=nocona -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/netinet6/in6_gif.c cc1: warnings being treated as errors /usr/src/sys/netinet6/in6_gif.c:84: warning: excess elements in struct initializer /usr/src/sys/netinet6/in6_gif.c:84: warning: (near initialization for 'in6_gif_protosw') *** Error code 1 =Chris From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 22:01:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 035F1106564A for ; Sun, 4 Jan 2009 22:01:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D3C708FC13 for ; Sun, 4 Jan 2009 22:01:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6492C46B17; Sun, 4 Jan 2009 17:01:05 -0500 (EST) Date: Sun, 4 Jan 2009 22:01:05 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Chris Ruiz In-Reply-To: <58c737d70901041335s72ec7335o298d7329fe8a2090@mail.gmail.com> Message-ID: References: <20090104205056.GA41264@freebsd.org> <20090104211439.GJ14235@hoeg.nl> <58c737d70901041335s72ec7335o298d7329fe8a2090@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: panic related to ipv6 (afaik) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 22:01:06 -0000 On Sun, 4 Jan 2009, Chris Ruiz wrote: > r186750 breaks the build: > > cc -c -O2 -fno-strict-aliasing -pipe -march=nocona -std=c99 -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -Werror /usr/src/sys/netinet6/in6_gif.c cc1: warnings > being treated as errors /usr/src/sys/netinet6/in6_gif.c:84: warning: excess > elements in struct initializer /usr/src/sys/netinet6/in6_gif.c:84: warning: > (near initialization for 'in6_gif_protosw') *** Error code 1 Yes, unfortunately what was intended to be a relatively minor cleanup appears to have snowballed a bit. I think it's now back to booting *and* compiling, but if not let me know. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 22:29:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53C84106564A; Sun, 4 Jan 2009 22:29:04 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id D05708FC08; Sun, 4 Jan 2009 22:29:03 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7c0c.q.ppp-pool.de [89.53.124.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 6E9EF12883F; Sun, 4 Jan 2009 23:09:10 +0100 (CET) Received: from [192.168.16.4] (dardanos.sz.vwsoft.com [192.168.16.4]) by mail.vtec.ipme.de (Postfix) with ESMTP id 82BEA2E916; Sun, 4 Jan 2009 23:08:58 +0100 (CET) Message-ID: <49613379.8040901@vwsoft.com> Date: Sun, 04 Jan 2009 23:08:57 +0100 From: Volker User-Agent: Thunderbird 2.0.0.18 (X11/20081203) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1231711747.81534@rR+KwgHoNNGIrpsmGCFX1A X-MailScanner-ID: 82BEA2E916.912EC X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: attilio@freebsd.org, uwe@grohnwaldt.eu, kib@freebsd.org, Martin Wilke Subject: panic in bundirty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 22:29:04 -0000 Gentlemen, I've had the pleasure to inspect miwi's new tinderbox machine in a panic situation. The debugging info we're able to get out of the box is the following: panic: bundirty: buffer 0xffffffff9a475438 still on queue 1 #9 0xffffffff8049f196 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:556 #10 0xffffffff8050b540 in bundirty (bp=Variable "bp" is not available. ) at /usr/src/sys/kern/vfs_bio.c:1068 #11 0xffffffff8050d684 in brelse (bp=0xffffffff9a475438) at /usr/src/sys/kern/vfs_bio.c:1388 #12 0xffffffff8050f07c in bufdone (bp=0xffffffff9a475438) at /usr/src/sys/kern/vfs_bio.c:3157 #13 0xffffffff8069cb6c in ffs_backgroundwritedone (bp=0xffffffff9a475438) ---Type to continue, or q to quit--- at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1679 #14 0xffffffff8050f051 in bufdone (bp=0xffffffff9a475438) at /usr/src/sys/kern/vfs_bio.c:3151 #15 0xffffffff80452b51 in g_io_schedule_up (tp=Variable "tp" is not available. ) at /usr/src/sys/geom/geom_io.c:587 #16 0xffffffff8045323f in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95 #17 0xffffffff8048037a in fork_exit ( callout=0xffffffff804531d0 , arg=0x0, frame=0xffffffff80e63c80) at /usr/src/sys/kern/kern_fork.c:789 in frame 11, 'p *bp' gives: $1 = {b_bufobj = 0xffffff00034fe958, b_bcount = 16384, b_caller1 = 0x0, b_data = 0xffffffff9f4b7000 "", b_error = 5, b_iocmd = 2 '\002', b_ioflags = 2 '\002', b_iooffset = 7127891968, b_resid = 16384, b_iodone = 0, b_blkno = 13921664, b_offset = 7127891968, b_bobufs = { tqe_next = 0xffffffff9a505a38, tqe_prev = 0xffffff00034fe9a8}, b_left = 0x0, b_right = 0xffffffff9a505a38, b_vflags = 0, b_freelist = { tqe_next = 0xffffffff9a472db8, tqe_prev = 0xffffffff80b56210}, b_qindex = 1, b_flags = 41092, b_xflags = 33 '!', b_lock = {lock_object = { lo_name = 0xffffffff8083ce18 "bufwait", lo_type = 0xffffffff8083ce18 "bufwait", lo_flags = 91947008, lo_witness_data = {lod_list = {stqe_next = 0xffffffff80ae6f80}, lod_witness = 0xffffffff80ae6f80}}, lk_lock = 18446744073709551608, lk_recurse = 0, lk_timo = 0, lk_pri = 80}, b_bufsize = 16384, b_runningbufspace = 0, b_kvabase = 0xffffffff9f4b7000 "", b_kvasize = 16384, b_lblkno = 13921664, b_vp = 0xffffff00034fe820, b_dirtyoff = 0, b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xffffffff9f4b7000, b_pager = {pg_reqpage = 0}, b_cluster = { cluster_head = {tqh_first = 0xffffffff9a479c68, tqh_last = 0xffffffff9a4901b0}, cluster_entry = { tqe_next = 0xffffffff9a479c68, tqe_prev = 0xffffffff9a4901b0}}, b_pages = {0xffffff00de0eafa0, 0xffffff00de0eb010, 0xffffff00de0eb080, 0xffffff00de0eb0f0, 0x0 }, b_npages = 4, b_dep = { lh_first = 0x0}, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, b_fsprivate3 = 0x0, b_pin_count = 0} This panic does not occur before commit 176708. The panic is in sys/kern/vfs_bio.c bundirty 1055: KASSERT( bp->b_flags & B_REMFREE || bp->b_qindex == QUEUE_NONE ... bp->b_qindex = 0x01 (QUEUE_FREE) bp->b_flags = 0xa084 (B_ASYNC | B_DELWRI | B_NOCACHE | B_INVAL) My assumption is: brele knows about the QUEUE_FREE but bundirty only wants to operate on QUEUE_NONE. Either this is a race condition, brele should not call bundirty or bundirty should operate not just on QUEUE_NONE buffers. As there have been some locking related commits in the changes in question, this might also be caused by an unlocked operation. right before the panic, we're seeing DMA errors: ad6: setting up DMA failed _vfs_done():ad6[WRITE(offset=5412487168, length=131072)]error = 5 ad6: FAILURE - load data ad6: setting up DMA failed g_vfs_done():ad6[WRITE(offset=5044109312, length=131072)]error = 5 g_vfs_done():ad6[WRITE(offset=5230985216, length=131072)]error = 5 g_vfs_done():ad6[WRITE(offset=5231116288, length=131072)]error = 5 g_vfs_done():ad6[WRITE(offset=5044240384, length=131072)]error = 5 g_vfs_done():ad6[WRITE(offset=5412618240, length=131072)]error = 5 g_vfs_done():ad4s1d[WRITE(offset=7127891968, length=16384)]error = 5 kgdb output can be found at: http://www.bsdmeat.net/~lando/miwi/kgdb.txt Suggestions what the correct fix to this issue is? Change bundirty or brele? Clean up locking? CC'ing those who committed to vfs_bio.c in the relevant time frame. Thanks Volker From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 23:37:44 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E37D1106577D for ; Sun, 4 Jan 2009 23:37:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id AC1548FC21 for ; Sun, 4 Jan 2009 23:37:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id C8BC1730A6; Mon, 5 Jan 2009 00:42:38 +0100 (CET) Date: Mon, 5 Jan 2009 00:42:38 +0100 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20090104234238.GA44381@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: upcoming elfdump refactoring X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 23:37:45 -0000 I need to extract value and size of some symbols from an ELF file, and make them available to a C program, something like nm -S /boot/kernel/kernel | grep -E "(kernload|kernbase|uscanner_devs)" Rather than using the above tools plus popen() and some parsing code, I have refactored src/usr.bin/elfdump/elfdump.c , making the main routine externally callable, returning the desired info in a struct rather than print them out. I don't know if/how other programs might need to call elfdump(), but given that the changes I made have no functional or performance drawback, I would like to commit them to the tree. Objections ? (note, the diff will be large because in the process I also removed global variables and staticize/constify things) cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 00:29:48 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00C6E106566B for ; Mon, 5 Jan 2009 00:29:48 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id BF6468FC0C for ; Mon, 5 Jan 2009 00:29:47 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n050TjsI011423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 16:29:46 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <49615475.2030803@FreeBSD.org> Date: Sun, 04 Jan 2009 16:29:41 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Luigi Rizzo References: <20090104234238.GA44381@onelab2.iet.unipi.it> In-Reply-To: <20090104234238.GA44381@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: upcoming elfdump refactoring X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 00:29:48 -0000 Luigi Rizzo wrote: > I need to extract value and size of some symbols from an ELF file, > and make them available to a C program, something like > > nm -S /boot/kernel/kernel | grep -E "(kernload|kernbase|uscanner_devs)" > > Rather than using the above tools plus popen() and some parsing code, > I have refactored src/usr.bin/elfdump/elfdump.c , > making the main routine externally callable, returning the > desired info in a struct rather than print them out. > > I don't know if/how other programs might need to call elfdump(), > but given that the changes I made have no functional or performance > drawback, I would like to commit them to the tree. > Objections ? > > (note, the diff will be large because in the process I also removed > global variables and staticize/constify things) Why not make this function part of libelf? -Maxim From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 00:56:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A244E106564A; Mon, 5 Jan 2009 00:56:10 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 677678FC17; Mon, 5 Jan 2009 00:56:10 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7C960730A1; Mon, 5 Jan 2009 02:01:05 +0100 (CET) Date: Mon, 5 Jan 2009 02:01:05 +0100 From: Luigi Rizzo To: Maxim Sobolev Message-ID: <20090105010105.GA47387@onelab2.iet.unipi.it> References: <20090104234238.GA44381@onelab2.iet.unipi.it> <49615475.2030803@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49615475.2030803@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: upcoming elfdump refactoring X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 00:56:10 -0000 On Sun, Jan 04, 2009 at 04:29:41PM -0800, Maxim Sobolev wrote: > Luigi Rizzo wrote: > >I need to extract value and size of some symbols from an ELF file, > >and make them available to a C program, something like > > > > nm -S /boot/kernel/kernel | grep -E "(kernload|kernbase|uscanner_devs)" > > > >Rather than using the above tools plus popen() and some parsing code, > >I have refactored src/usr.bin/elfdump/elfdump.c , > >making the main routine externally callable, returning the > >desired info in a struct rather than print them out. > > > >I don't know if/how other programs might need to call elfdump(), > >but given that the changes I made have no functional or performance > >drawback, I would like to commit them to the tree. > >Objections ? > > > >(note, the diff will be large because in the process I also removed > >global variables and staticize/constify things) > > Why not make this function part of libelf? because i was not aware of its existance (also a reason why I posted the request - i didn't want to reinvent the wheel). Thanks for the pointer, I will look at libelf and see if it already contains soemthing that does what i need. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 01:20:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E252106564A for ; Mon, 5 Jan 2009 01:20:39 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id EC49F8FC1A for ; Mon, 5 Jan 2009 01:20:38 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so8391365rvf.43 for ; Sun, 04 Jan 2009 17:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:content-transfer-encoding:in-reply-to :user-agent:organization:x-operation-sytem:from; bh=HQImEDIsXocNDUBywVfmkxPA43p7SS9RDvDU4HPWs1M=; b=mtnK0csFqvMzZwZ8CNvx1m/mkJCoWPv6GF2OSV8Pl6dcCHazl6bdN+FxjOPzO2Mqg+ 4CS4ilth0vcz0lK9/tXbY4ToD19TyW7zuyOjiVwgfzPEk4+QNtaDnJHz6nC2w7/9bALD 8vRXn/k1w2VvUbGfJmbfDYBMGiHYV+SGFLz28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent:organization :x-operation-sytem:from; b=Hc+GuZyHgHyjGkZuyGKC3/Ex7AUVcHH8KOZZaa82i8E5Gxo6kP4QkP3y1dxPHLTuaL 8UUlelR8GtgxpC3m9tUI772C2dIF08+2CiVJzrqGuogEj5JtXVO/cTpF1OCfX/ORRN5C /GCEtJb3fgLsvQLUHfP27nfLN+PChtvYO5Gac= Received: by 10.114.158.1 with SMTP id g1mr13428417wae.126.1231118438556; Sun, 04 Jan 2009 17:20:38 -0800 (PST) Received: from freebsd.weongyo.org ([211.53.35.67]) by mx.google.com with ESMTPS id q18sm32944489pog.23.2009.01.04.17.20.36 (version=SSLv3 cipher=RC4-MD5); Sun, 04 Jan 2009 17:20:37 -0800 (PST) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Mon, 5 Jan 2009 10:20:25 +0900 Date: Mon, 5 Jan 2009 10:20:25 +0900 To: Alexey Ivanov Message-ID: <20090105012025.GA12414@freebsd.weongyo.org> Mail-Followup-To: Alexey Ivanov , freebsd-current@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Cc: freebsd-current@freebsd.org Subject: Re: Can not build r186708 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 01:20:39 -0000 On Sat, Jan 03, 2009 at 04:10:26AM +0300, Alexey Ivanov wrote: > last time I've updated my FreeBSD was >=20 > [PH34R] ~> uname -a > FreeBSD PH34R 8.0-CURRENT FreeBSD 8.0-CURRENT #14: Mon Dec 22 13:09:06 MS= K 2008 savetherbtz@PH34R:/usr/obj/usr/src/sys/PH34R.8 i386 >=20 >=20 > Now after cvsup I have > ... > .... > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/acpica/acpi_if.= m -h > rm -f .newdep > make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=3D"cc -E" CC= =3D"cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=3Da= thlon-mp -std=3Dc99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prot= otypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef = -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/= src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib= /pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/co= ntrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr= /src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sy= s/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNE= L_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --= param inline-unit-growth=3D100 --param large-function-growth=3D1000 -mno-a= lign-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-= sse -mno-sse2 -mno-sse3 -ffreestand > ing -fstack-protector > /usr/src/sys/compat/ndis/subr_usbd.c:64:21: error: usbdevs.h: No such fil= e or directory > mkdep: compile failed > *** Error code 1 >=20 > Stop in /usr/obj/usr/src/sys/PH34R.8. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 >=20 >=20 > KERNCONF attached Hmm.. It looks weird because sys/modules/ndis/Makefile would include=20 usbdevs.h file. Could you please check it whether it has it? Or your=20 system time? regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 01:34:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3076F106566B for ; Mon, 5 Jan 2009 01:34:18 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id D9AD38FC0C for ; Mon, 5 Jan 2009 01:34:17 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so3141745yxb.13 for ; Sun, 04 Jan 2009 17:34:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=QFAPHTujg/WTw1uD5iJhDKU12ygQTITB4uA+IkCjNFw=; b=YBY2QzgLzhK0a0LxJh9zp8nNedlbA+x7EFp1WWjKZGQHGf0H2QCzm/u45ZmAqS/L4p 6AyWQp3GazaC6NzFyJSboLNd3ynZYBhDfjNvxLDIo618RRLPqmbz1vNT7+VYE3+K9APG xIaR8ml739V0LgbxD6WGP2AVsMmSv06iBCBzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=CWy8qxFwuwQInO3pE3b+A6NW3vwwmlbVH8CpNp65KtEj0FoVRI223z6rAw3CBtpcQi AMevU7gZDexyq7xNjUPFJhLnBy8cAPkHLYfqeUktkiTT/OT6nR/xE0SF+cB+RxY9Ya/V y8LPNWW/8fSLl07LC0fnEejMNniI96p1z8rsE= Received: by 10.150.146.14 with SMTP id t14mr35215743ybd.69.1231119257123; Sun, 04 Jan 2009 17:34:17 -0800 (PST) Received: by 10.150.98.19 with HTTP; Sun, 4 Jan 2009 17:34:17 -0800 (PST) Message-ID: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> Date: Sun, 4 Jan 2009 19:34:17 -0600 From: "Chris Ruiz" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: apcupsd & usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 01:34:18 -0000 apcupsd no longer works now that i switched to usb2. the usb2_input_hid module keeps attaching to it. before, with the old usb stack, my ups would attach as ugen0, my dmesg shows it attaching as uhid0 now and apcupsd cannot find it. if i unload the usb2_input_hid module, my ups disappears. because something is mentioned in the post install text for apcupsd, i believe that the usb2_hid_module should not be attaching to the ups. any help would be appreciated. [old stack] ugen0: on uhub5 [usb2] uhid0: on usbus5 Symlink: uhid0 -> usb5.2.0.16 [error message] apcupsd[3643]: apcupsd FATAL ERROR in bsd-usb.c at line 735 Cannot find UPS device -- For a link to detailed USB trouble shooting information, please see . apcupsd[3643]: apcupsd error shutdown completed thanks for all your hard work on the new usb stack, Chris Ruiz From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 02:32:18 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E34BA106564A for ; Mon, 5 Jan 2009 02:32:18 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id CE4678FC17 for ; Mon, 5 Jan 2009 02:32:18 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.96] (75-101-29-67.dsl.static.sonic.net [75.101.29.67]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KCZ00MGJ8DS2Q20@asmtp022.mac.com>; Sun, 04 Jan 2009 18:32:17 -0800 (PST) Message-id: <0AE16877-C02A-40A1-9F3B-FE839CB7B9E5@mac.com> From: Marcel Moolenaar To: Maxim Sobolev In-reply-to: <49615475.2030803@FreeBSD.org> Date: Sun, 04 Jan 2009 18:32:17 -0800 References: <20090104234238.GA44381@onelab2.iet.unipi.it> <49615475.2030803@FreeBSD.org> X-Mailer: Apple Mail (2.930.3) Cc: Luigi Rizzo , current@FreeBSD.org Subject: Re: upcoming elfdump refactoring X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 02:32:19 -0000 On Jan 4, 2009, at 4:29 PM, Maxim Sobolev wrote: > Luigi Rizzo wrote: >> I need to extract value and size of some symbols from an ELF file, >> and make them available to a C program, something like >> nm -S /boot/kernel/kernel | grep -E "(kernload|kernbase| >> uscanner_devs)" >> Rather than using the above tools plus popen() and some parsing code, >> I have refactored src/usr.bin/elfdump/elfdump.c , >> making the main routine externally callable, returning the >> desired info in a struct rather than print them out. >> I don't know if/how other programs might need to call elfdump(), >> but given that the changes I made have no functional or performance >> drawback, I would like to commit them to the tree. >> Objections ? >> (note, the diff will be large because in the process I also removed >> global variables and staticize/constify things) > > Why not make this function part of libelf? Please don't. libelf has a standard and well-documented API. Don't add random or one-off functions simply on the basis of them having "elf" in the name. In fact, elfdump(1) should really use libelf(3) to read ELF files. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 03:41:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A244106564A for ; Mon, 5 Jan 2009 03:41:01 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by mx1.freebsd.org (Postfix) with ESMTP id 145398FC16 for ; Mon, 5 Jan 2009 03:41:00 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.96] (75-101-29-67.dsl.static.sonic.net [75.101.29.67]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KCZ00CRABKB8730@asmtp017.mac.com> for current@freebsd.org; Sun, 04 Jan 2009 19:41:00 -0800 (PST) Message-id: <8BF346D6-B7EB-4FFC-9216-FEFCABBDADB8@mac.com> From: Marcel Moolenaar To: Takahashi Yoshihiro In-reply-to: <20081220.154722.162072679.nyan@jp.FreeBSD.org> Date: Sun, 04 Jan 2009 19:40:59 -0800 References: <4EA5F491-CC52-43EC-AC03-F50F8B2D6186@mac.com> <20081219.181532.241936859.nyan@jp.FreeBSD.org> <354036B7-A4AA-4D66-A2AC-9CB66D292FAA@mac.com> <20081220.154722.162072679.nyan@jp.FreeBSD.org> X-Mailer: Apple Mail (2.930.3) Cc: current@freebsd.org Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 03:41:01 -0000 On Dec 19, 2008, at 10:47 PM, Takahashi Yoshihiro wrote: > In article <354036B7-A4AA-4D66-A2AC-9CB66D292FAA@mac.com> > Marcel Moolenaar writes: > >>> Please see: >>> http://lists.freebsd.org/pipermail/freebsd-arch/2008-September/008627.html >>> >>> The da0 has a BSD slice. GEOM_BSD/GEOM_PC98 recognize it correctly. >>> But the gpart does not. From debug printf (dmesg.txt), it seems >>> that >>> the gpart read incorrect sector. >> >> This seems to indicate that the pc98 slice is wrong, or >> you don't have the BSD disklabel in the right sector. >> >> Can you give me a dump of the first 32 sectors on the >> disk and the first 32 sectors of slice 1. > > I put to the following. > http://home.jp.freebsd.org/~nyan/geom/da0 > http://home.jp.freebsd.org/~nyan/geom/da0s1 > > BTW, the result of using the gpart is: > http://home.jp.freebsd.org/~nyan/geom/gpart.da0 > http://home.jp.freebsd.org/~nyan/geom/gpart.da0s1 I think the problem is with the perceived geometry. If you boot verbose with GEOM_PC98, do you see that the fwsectors/fwheads are being guessed? If not, can you tell me what the fwsectors and fwheads values are? With GEOM_PART_PC98, can you run: gpart list da0 You should get something like: Geom name: da0 fwheads: 16 fwsectors: 63 last: 80293247 first: 63 entries: 4 scheme: MBR Of course scheme should be PC98 in your case. I suspect that the number of heads and/or sectors per track is different. Thanks, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 05:32:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E20481065670 for ; Mon, 5 Jan 2009 05:32:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 6EFED8FC12 for ; Mon, 5 Jan 2009 05:32:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so1240405ugs.39 for ; Sun, 04 Jan 2009 21:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0t3j4Ws24nZCKEEMHsEucfDmswbAQz9fRYNxZht+6pI=; b=QL+Kk4W/m4M9J/n9mUgtjoULlbgSST1eKnZ7JdRQPwO4EdQebQPBuNtIkplhX41ENA 1RDh71NtPeHs2ZeIkBMZq0bL/xfBNbW67fMQGR/HmKMgc5NDKARrv5j46bvgD3F0A6hM Ik03PHRbryr7/yOn3/cALp2+oQIIJb/IbWEGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=VH2FbzytKWR7a+2hvugggVee6eUTe0sHO2Wprl/VB5SpTVDvxiuwJWpHqYwhDfsXin cdqesbbWea6sUVoQzu6D3CRMtATrfGz5krQcGfP1ma4Xd7K37tZRVKr+CFsxy/4c6dYk X1RgIddMRTA+hj8nnDRR9WixCWc3+8x+jnKHA= Received: by 10.67.106.13 with SMTP id i13mr12645374ugm.7.1231133569142; Sun, 04 Jan 2009 21:32:49 -0800 (PST) Received: by 10.67.88.9 with HTTP; Sun, 4 Jan 2009 21:32:49 -0800 (PST) Message-ID: <7d6fde3d0901042132j637f288eo3031e3b1c496a894@mail.gmail.com> Date: Sun, 4 Jan 2009 21:32:49 -0800 From: "Garrett Cooper" To: "FreeBSD Current" In-Reply-To: <7d6fde3d0901042132w4566d619me72bed36f016606b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> <200812281613.49404.tijl@ulyssis.org> <495B1ABF.4080302@FreeBSD.org> <7d6fde3d0901042132w4566d619me72bed36f016606b@mail.gmail.com> Subject: Re: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 05:32:51 -0000 On Tue, Dec 30, 2008 at 11:09 PM, Doug Barton wrote: > Li, Qing wrote: >> I don't think we can provide binary compatibility without putting >> back RTF_LLINFO exactly as it was. My preference is to continue down >> the new path without RTF_LLINFO. > > Out of curiosity, what's your reasoning for this decision? If I've > missed this explanation previously, my apologies. > > Doug I think I have a fix (for emulators/wine at least). Let me test it out and then get back to you in a bit... -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 09:05:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CD4D1065670 for ; Mon, 5 Jan 2009 09:05:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id EBE6A8FC13 for ; Mon, 5 Jan 2009 09:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 4417141C6BB; Mon, 5 Jan 2009 10:05:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id zqCbfr8Lrhv5; Mon, 5 Jan 2009 10:05:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id DEBD141C6A1; Mon, 5 Jan 2009 10:05:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id A54D04448DD; Mon, 5 Jan 2009 09:02:29 +0000 (UTC) Date: Mon, 5 Jan 2009 09:02:29 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Alexey Ivanov In-Reply-To: Message-ID: <20090105090106.O45399@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Can not build r186708 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 09:05:08 -0000 On Sat, 3 Jan 2009, Alexey Ivanov wrote: > last time I've updated my FreeBSD was > > [PH34R] ~> uname -a > FreeBSD PH34R 8.0-CURRENT FreeBSD 8.0-CURRENT #14: Mon Dec 22 13:09:06 MSK 2008 savetherbtz@PH34R:/usr/obj/usr/src/sys/PH34R.8 i386 > > > Now after cvsup I have re-cvsup; While SVN was up-to-date cvs wasn't for other technical reasons. Should work now. -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 09:16:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 010DE106564A; Mon, 5 Jan 2009 09:16:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id AB1F08FC08; Mon, 5 Jan 2009 09:16:39 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LJlF1-000L2y-Cv; Mon, 05 Jan 2009 10:55:19 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Luigi Rizzo In-reply-to: <20090105010105.GA47387@onelab2.iet.unipi.it> References: <20090104234238.GA44381@onelab2.iet.unipi.it> <49615475.2030803@FreeBSD.org> <20090105010105.GA47387@onelab2.iet.unipi.it> Comments: In-reply-to Luigi Rizzo message dated "Mon, 05 Jan 2009 02:01:05 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Jan 2009 10:55:19 +0200 From: Danny Braniss Message-ID: Cc: current@freebsd.org Subject: Re: upcoming elfdump refactoring X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 09:16:40 -0000 > On Sun, Jan 04, 2009 at 04:29:41PM -0800, Maxim Sobolev wrote: > > Luigi Rizzo wrote: > > >I need to extract value and size of some symbols from an ELF file, > > >and make them available to a C program, something like > > > > > > nm -S /boot/kernel/kernel | grep -E "(kernload|kernbase|uscanner_devs)" > > > > > >Rather than using the above tools plus popen() and some parsing code, > > >I have refactored src/usr.bin/elfdump/elfdump.c , > > >making the main routine externally callable, returning the > > >desired info in a struct rather than print them out. > > > > > >I don't know if/how other programs might need to call elfdump(), > > >but given that the changes I made have no functional or performance > > >drawback, I would like to commit them to the tree. > > >Objections ? > > > > > >(note, the diff will be large because in the process I also removed > > >global variables and staticize/constify things) > > > > Why not make this function part of libelf? > > because i was not aware of its existance (also a reason why I posted > the request - i didn't want to reinvent the wheel). > Thanks for the pointer, I will look at libelf and see if it already > contains soemthing that does what i need. > while you are at it, can you check why there is a null when you do: config -x kernel ie: sunfire> config -x /boot/kernel/kernel | grep device Binary file (standard input) matches sunfire> config -x /boot/kernel/kernel | cat -v| tail device cue device kue device rue device firewire device sbp device fwe device fwip device dcons device dcons_crom ^@sunfire> i think the libelf is involved. > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 09:57:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3088C106564A for ; Mon, 5 Jan 2009 09:57:19 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id BD5D28FC39 for ; Mon, 5 Jan 2009 09:57:18 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=rREUrScshOl7G2h6aTFPgw==:17 a=5gVvIhBEAAAA:8 a=mOvjcLd2HdmKw6BjJY4A:9 a=gjLW8z0CPQc2nHxkVZecRuhqrGAA:4 a=LY0hPdMaydYA:10 Received: from [62.73.248.227] (account mc467741@c2i.net [62.73.248.227] verified) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 124326215; Mon, 05 Jan 2009 10:57:16 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 5 Jan 2009 10:59:38 +0100 User-Agent: KMail/1.9.7 References: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> In-Reply-To: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901051059.39566.hselasky@c2i.net> Cc: Chris Ruiz Subject: Re: apcupsd & usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 09:57:19 -0000 On Monday 05 January 2009, Chris Ruiz wrote: > apcupsd no longer works now that i switched to usb2. the > usb2_input_hid module keeps attaching to it. before, with the old usb > stack, my ups would attach as ugen0, my dmesg shows it attaching as > uhid0 now and apcupsd cannot find it. if i unload the usb2_input_hid > module, my ups disappears. because something is mentioned in the post > install text for apcupsd, i believe that the usb2_hid_module should > not be attaching to the ups. any help would be appreciated. > > [old stack] > ugen0: FW:E6, class 0/0, rev 1.10/1.06, addr 2> on uhub5 > > [usb2] > uhid0: FW:E6, class 0/0, rev 1.10/1.06, addr 2> on usbus5 > Symlink: uhid0 -> usb5.2.0.16 > > [error message] > apcupsd[3643]: apcupsd FATAL ERROR in bsd-usb.c at line 735 Cannot > find UPS device -- For a link to detailed USB trouble shooting > information, please see . > apcupsd[3643]: apcupsd error shutdown completed > > thanks for all your hard work on the new usb stack, Hi Chris, You need to replace libusb0.1.xxx with libusb20 in /usr/local/lib or link apcupsd with libusb20. Then it will work again. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 10:22:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE720106566B for ; Mon, 5 Jan 2009 10:22:02 +0000 (UTC) (envelope-from hopet@ics.muni.cz) Received: from tirith.ics.muni.cz (tirith.ics.muni.cz [147.251.4.36]) by mx1.freebsd.org (Postfix) with ESMTP id 821598FC0C for ; Mon, 5 Jan 2009 10:22:02 +0000 (UTC) (envelope-from hopet@ics.muni.cz) Received: from KLOBOUCEK (dhcp3-89.ics.muni.cz [147.251.3.89]) (authenticated user=hopet@ICS.MUNI.CZ bits=0) by tirith.ics.muni.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id n059ptOe024082 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 5 Jan 2009 10:51:55 +0100 From: "Petr Holub" To: Date: Mon, 5 Jan 2009 10:51:51 +0100 Message-ID: <03a001c96f1b$3fa09b20$bee1d160$@muni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclvGzmhLvyQjTigSriSHbIDJzqaKg== Content-Language: cs X-Muni-Spam-TestIP: 147.251.3.89 X-Muni-Envelope-From: hopet@ics.muni.cz X-Muni-Virus-Test: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (tirith.ics.muni.cz [147.251.4.36]); Mon, 05 Jan 2009 10:51:56 +0100 (CET) Cc: Subject: 8.0-SNAPSHOT200812 reversed locks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 10:22:03 -0000 Hi all, after booting a 8.0-SNAPSHOT200812 DVD on my T61p and entering the fixit ``live'' mode, I've encountered the following messages about reversed locks: DEBUG: ioctl(3, TIOCCONS, NULL) = 0 (success) DEBUG: MADT: Found CPU APIC ID 0 enabled DEBUG: MADT: Found CPU APIC ID 1 enabled lock order reversal: 1st 0xc6e43164 isofs (isofs) @ /usr/src/sys/kern/vfs_subr.c:2079 2nd 0xda8e7960 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 3rd 0xc6ed0488 isofs (isofs) @ /usr/src/sys/fs/cd9660/cd9660_vfsops.c:676 KDB: stack backtrace: db_trace_self_wrapper(...) at db_trace_self_wrapper+0x26 kdb_backtrace(...) at kdb_backtrace+0x29 _witness_debugger(...) at _witness_debugger+0x25 witness_checkorder(...) at witness_checkorder+0x839 __lockmgr_args(...) at __lockmgr_args+0x797 cd9660_vget_internal(...) at cd9660_vget_internal+0x118 cd9660_lookup(...) at cd9660_lookup+0x73f VOP_CACHEDLOOKUP_APV(...) at VOP_CACHED_LOOKUP+0xa5 vfs_cache_lookup(...) at vfs_cache_lookup+0xcc VOP_LOOKUP_APV(...) at VOP_LOOKUP_APV+0xa5 lookup(...) at lookup+0x0x57e namei(...) at namei+0x04db kern_accessat(...) at kern_accessat+0x94 kern_access(...) at kern_access+0x36 access(...) at access+0x29 syscall(c67d1d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (33, FreeBSD ELF32, access), eip = 0x81d6ed7, esp = 0xbfbfe02c, ebp = 0xbfbfe048 --- DEBUG: CD Volume 1 initialized! lock order reversal: 1st 0xc696ae44 user map (user map) @ /usr/src/sys/vm/vm_map.c:3115 2nd 0xc6ed0270 isofs (isofs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper(...) at db_trace_self_wrapper+0x26 kdb_backtrace(...) at kdb_backtrace+0x29 _witness_debugger(...) at _witness_debugger+0x25 witness_checkorder(...) at witness_checkorder+0x839 __lockmgr_args(...) at __lockmgr_args+0x797 vop_stdlock(...) at vop_stdlock+0x62 VOP_LOCK1_APV(...) at VOP_LOCK1_APV+0xa5 _vn_lock(...) at _vn_lock+0x5e vget(...) at vget+0xc9 vnode_pager_lock(...) at vnode_pager_lock+0x1e0 vm_fault(...) at vm_fault+0x1df trap_pfault(...) at trap_pfault+0x118 trap(...) at trap+0x289 calltrap(...) at calltrap+0x6 Because the machine is not enabled for remote debugging, I've hand typed those messages. I function parameters are needed, I can hopefully recover them from screenshots taken by my cell phone :) Petr From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 11:26:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 530521065678 for ; Mon, 5 Jan 2009 11:26:06 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.freebsd.org (Postfix) with ESMTP id DEC3A8FC08 for ; Mon, 5 Jan 2009 11:26:05 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id n05BPvcj079421; Mon, 5 Jan 2009 12:26:01 +0100 (CET) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 5 Jan 2009 12:25:51 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DE3C8@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: build -j3 not working anymore on Current Thread-Index: AcltjLtzW0t2VAviR0ynqFL92mvmbQBmUI6w References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090103101606.GA81276@dragon.NUXI.org> From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org Subject: RE: build -j3 not working anymore on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 11:26:07 -0000 >> I always use the following command to do the buildworld cycles. >> make cleanworld && make -j3 buildworld && make -j3 kernel >> But as of now i get the following error >Based on an email I got from Ken Smith, there seems to be something >weird going on with the rescue build. I've made a temperary change >to make(1) until I can figure out what it is. [svn r186713] >--=20 >-- David (obrien@FreeBSD.org) Well i cvsuped today and still got an error when building with -j3=20 Regards, Johan Hendriks No virus found in this outgoing message. Checked by AVG - http://www.avg.com=20 Version: 8.0.176 / Virus Database: 270.10.2/1874 - Release Date: = 4-1-2009 16:32 From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 11:59:19 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7283106566B for ; Mon, 5 Jan 2009 11:59:19 +0000 (UTC) (envelope-from nyan@jp.FreeBSD.org) Received: from sakura.ccs.furiru.org (unknown [IPv6:2001:2f0:104:8060::1]) by mx1.freebsd.org (Postfix) with ESMTP id 536D18FC14 for ; Mon, 5 Jan 2009 11:59:19 +0000 (UTC) (envelope-from nyan@jp.FreeBSD.org) Received: from localhost (authenticated bits=0) by sakura.ccs.furiru.org (unknown) with ESMTP id n05BxEGs071600; Mon, 5 Jan 2009 20:59:16 +0900 (JST) (envelope-from nyan@jp.FreeBSD.org) Date: Mon, 05 Jan 2009 20:59:12 +0900 (JST) Message-Id: <20090105.205912.94971317.nyan@jp.FreeBSD.org> To: xcllnt@mac.com From: Takahashi Yoshihiro In-Reply-To: <8BF346D6-B7EB-4FFC-9216-FEFCABBDADB8@mac.com> References: <354036B7-A4AA-4D66-A2AC-9CB66D292FAA@mac.com> <20081220.154722.162072679.nyan@jp.FreeBSD.org> <8BF346D6-B7EB-4FFC-9216-FEFCABBDADB8@mac.com> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: gpart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 11:59:19 -0000 In article <8BF346D6-B7EB-4FFC-9216-FEFCABBDADB8@mac.com> Marcel Moolenaar writes: > I think the problem is with the perceived geometry. > If you boot verbose with GEOM_PC98, do you see that > the fwsectors/fwheads are being guessed? If not, can > you tell me what the fwsectors and fwheads values > are? The value of the fwheads and fwsectors are: g_pc98_taste(PC98,da0): 8 heads / 128 sectors > With GEOM_PART_PC98, can you run: > gpart list da0 The result is: Geom name: da0 fwheads: 255 fwsectors: 63 last: 40017914 first: 16065 entries: 16 scheme: PC98 Providers: 1. Name: da0s1 Mediasize: 321542645760 (299G) Sectorsize: 512 Mode: r0w0e0 rawtype: 17428 attrib: active attrib: bootable label: FreeBSD length: 321542645760 offset: 8225280 type: freebsd index: 1 Consumers: 1. Name: da0 Mediasize: 20496236544 (19G) Sectorsize: 512 Mode: r0w0e0 --- TAKAHASHI Yoshihiro From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 12:28:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CD12106564A for ; Mon, 5 Jan 2009 12:28:13 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f19.google.com (mail-bw0-f19.google.com [209.85.218.19]) by mx1.freebsd.org (Postfix) with ESMTP id 709F48FC0C for ; Mon, 5 Jan 2009 12:28:12 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz12 with SMTP id 12so19809546bwz.19 for ; Mon, 05 Jan 2009 04:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=e4OgRNTclJrh98IM1434mcSqXeD7MFmYyKELJCWXaB0=; b=UJ4ZylJzF/MdyH07jWB7FsrBPViouKnVVUrbDiKbjwpphPzVAkYgF/bNjilT35EnhS AunMbHI1/HD4rQ5Vk8D7mMTqQ8ktFPgiXBrYoa/IvvoC7ZzLeWiRD5BoweCwWJJx61wx DUd7KJxy02gXO9ZM1FauBlBoYkyQDuegzbfW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=PrUYokdw/1O258zQw7XJvIYapKQjPWass7NwpEudU9jk71SODCb0AwoSxbSROwWxy9 eAkSnmZ16njGMoYbYTUwC5DWooEHeyimHEznSN0JUZD5e06rZ0DbJp10orh0M5llZsEN XZuo1npMvygJYDqnjAUKJUsqqIJk9SZDaehb8= Received: by 10.223.126.203 with SMTP id d11mr14572216fas.8.1231158490497; Mon, 05 Jan 2009 04:28:10 -0800 (PST) Received: by 10.223.115.1 with HTTP; Mon, 5 Jan 2009 04:28:10 -0800 (PST) Message-ID: <3a142e750901050428we124de0r38fccd4fd50fb135@mail.gmail.com> Date: Mon, 5 Jan 2009 12:28:10 +0000 From: "Paul B. Mahol" To: "Bjoern A. Zeeb" In-Reply-To: <20090105090106.O45399@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20090105090106.O45399@maildrop.int.zabbadoz.net> Cc: Alexey Ivanov , freebsd-current@freebsd.org Subject: Re: Can not build r186708 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 12:28:13 -0000 On 1/5/09, Bjoern A. Zeeb wrote: > On Sat, 3 Jan 2009, Alexey Ivanov wrote: > >> last time I've updated my FreeBSD was >> >> [PH34R] ~> uname -a >> FreeBSD PH34R 8.0-CURRENT FreeBSD 8.0-CURRENT #14: Mon Dec 22 13:09:06 MSK >> 2008 savetherbtz@PH34R:/usr/obj/usr/src/sys/PH34R.8 i386 >> >> >> Now after cvsup I have > > re-cvsup; While SVN was up-to-date cvs wasn't for other technical > reasons. Should work now. There is no point to have ndis{api} defined in kernel when usb2 is used instead of usb in same kernel. -- Paul From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 12:29:31 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BC7010656C0 for ; Mon, 5 Jan 2009 12:29:31 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id BEFBF8FC1E for ; Mon, 5 Jan 2009 12:29:30 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1LJoJh-0004To-OF>; Mon, 05 Jan 2009 13:12:21 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1LJoJh-0007Yr-NB>; Mon, 05 Jan 2009 13:12:21 +0100 Message-ID: <4961F89F.4000004@zedat.fu-berlin.de> Date: Mon, 05 Jan 2009 12:10:07 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: FreeBSD 8-Current AMD64: not compiling world, core dump with new kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 12:29:31 -0000 Hello. I've trouble compiling world on a FreeBSD 8.0-CUR/amd64 box. uname is as follows: FreeBSD thusnelda.geoinf.fu-berlin.de 8.0-CURRENT FreeBSD 8.0-CURRENT #5 r185330: Wed Nov 26 08:29:58 UTC 2008 I've cvsup'ed the most recent sources, but as the weeks before, compilation of 'world' stops at this point: ===> gnu/usr.bin/texinfo/doc (all) makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi -o info.info makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi -o info-stnd.info ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi texinfo.texi makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi -o texinfo.info gzip -cn info.info > info.info.gz gzip -cn info-stnd.info > info-stnd.info.gz gzip -cn texinfo.info > texinfo.info.gz 1 error *** Error code 2 1 error *** Error code 2 1 error Also, the kernel dated as the uname output shows is the only one that boots correctly on this box (DELL Poweredge 1950 with two XEON CPUs, dmesg follows). I can compile a kernel with the most recent sources, but the kernel crashes when booting (this happens also on a dual core Lenovo Thinkpad and affects another SMP box also, but not my private UP box). But this is another issue I will report separately. Can anyone help fixing the problem above? I deleted the stuff remaining in /usr/obj/ and started with a freshly 'svn update', but without success. I guess there is something out of sync, but don't know what. Thanks in advance, Oliver From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 12:39:46 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3A1A106566B for ; Mon, 5 Jan 2009 12:39:46 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.freebsd.org (Postfix) with ESMTP id 7FA178FC20 for ; Mon, 5 Jan 2009 12:39:46 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id n05CdiwC036769; Mon, 5 Jan 2009 13:39:44 +0100 (CET) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 5 Jan 2009 13:39:43 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DE3C9@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD 8-Current AMD64: not compiling world, core dump with new kernel Thread-Index: AclvMdva9ZcDEyXjQ96kQXRVLLczrAAAEvKw References: <4961F89F.4000004@zedat.fu-berlin.de> From: "Johan Hendriks" To: "O. Hartmann" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@FreeBSD.org Subject: RE: FreeBSD 8-Current AMD64: not compiling world, core dump with new kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 12:39:47 -0000 >Hello. >I've trouble compiling world on a FreeBSD 8.0-CUR/amd64 box. uname is = as=20 >follows: >FreeBSD thusnelda.geoinf.fu-berlin.de 8.0-CURRENT FreeBSD 8.0-CURRENT = #5=20 >r185330: Wed Nov 26 08:29:58 UTC 2008 >I've cvsup'ed the most recent sources, but as the weeks before,=20 >compilation of 'world' stops at this point: < snip > ........... ........... ........... < /snip > >Also, the kernel dated as the uname output shows is the only one that=20 >boots correctly on this box (DELL Poweredge 1950 with two XEON CPUs,=20 >dmesg follows). I can compile a kernel with the most recent sources, = but=20 >the kernel crashes when booting (this happens also on a dual core = Lenovo=20 >Thinkpad and affects another SMP box also, but not my private UP box).=20 >But this is another issue I will report separately. >Can anyone help fixing the problem above? I deleted the stuff remaining = >in /usr/obj/ and started with a freshly 'svn update', but without=20 >success. I guess there is something out of sync, but don't know what. >Thanks in advance, >Oliver Do you use -jx to do a buildworld ? If so do the buildworld without -jx=20 I have 2 systems running 8.0-CURRENT, and both do not compile with -jx, = but do build fine without the -jx option. See also the build with -j3 fails thread. Regards Johan Hendriks No virus found in this outgoing message. Checked by AVG - http://www.avg.com=20 Version: 8.0.176 / Virus Database: 270.10.2/1874 - Release Date: = 4-1-2009 16:32 From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 14:53:05 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF506106566B for ; Mon, 5 Jan 2009 14:53:05 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 780F48FC12 for ; Mon, 5 Jan 2009 14:53:05 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1LJqpE-00033T-7q>; Mon, 05 Jan 2009 15:53:04 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1LJqpE-0000MI-6k>; Mon, 05 Jan 2009 15:53:04 +0100 Message-ID: <49621E49.6030708@zedat.fu-berlin.de> Date: Mon, 05 Jan 2009 14:50:49 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Johan Hendriks References: <4961F89F.4000004@zedat.fu-berlin.de> <57200BF94E69E54880C9BB1AF714BBCB5DE3C9@w2003s01.double-l.local> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DE3C9@w2003s01.double-l.local> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-current@FreeBSD.org Subject: Re: FreeBSD 8-Current AMD64: not compiling world, core dump with new kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 14:53:06 -0000 Johan Hendriks wrote: >> Hello. > >> I've trouble compiling world on a FreeBSD 8.0-CUR/amd64 box. uname is as >> follows: > >> FreeBSD thusnelda.geoinf.fu-berlin.de 8.0-CURRENT FreeBSD 8.0-CURRENT #5 >> r185330: Wed Nov 26 08:29:58 UTC 2008 > >> I've cvsup'ed the most recent sources, but as the weeks before, >> compilation of 'world' stops at this point: > > < snip > > ........... > ........... > ........... > < /snip > > >> Also, the kernel dated as the uname output shows is the only one that >> boots correctly on this box (DELL Poweredge 1950 with two XEON CPUs, >> dmesg follows). I can compile a kernel with the most recent sources, but >> the kernel crashes when booting (this happens also on a dual core Lenovo >> Thinkpad and affects another SMP box also, but not my private UP box). >> But this is another issue I will report separately. > >> Can anyone help fixing the problem above? I deleted the stuff remaining >> in /usr/obj/ and started with a freshly 'svn update', but without >> success. I guess there is something out of sync, but don't know what. > >> Thanks in advance, >> Oliver > > Do you use -jx to do a buildworld ? > If so do the buildworld without -jx > I have 2 systems running 8.0-CURRENT, and both do not compile with -jx, but do build fine without the -jx option. > See also the build with -j3 fails thread. > > Regards > Johan Hendriks You're right, I used -j8. Without a buildworld performs well. I will see if the core dump problem vanishes when everything is in sync. Thanks Oliver From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 15:56:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FD571065678 for ; Mon, 5 Jan 2009 15:56:18 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 50A6D8FC0C for ; Mon, 5 Jan 2009 15:56:18 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n05FuFVY048822; Mon, 5 Jan 2009 07:56:16 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n05FuFOC048821; Mon, 5 Jan 2009 07:56:15 -0800 (PST) (envelope-from obrien) Date: Mon, 5 Jan 2009 07:56:15 -0800 From: "David O'Brien" To: Johan Hendriks Message-ID: <20090105155615.GB46222@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Johan Hendriks , freebsd-current@freebsd.org References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090103101606.GA81276@dragon.NUXI.org> <57200BF94E69E54880C9BB1AF714BBCB5DE3C8@w2003s01.double-l.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DE3C8@w2003s01.double-l.local> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: build -j3 not working anymore on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 15:56:19 -0000 On Mon, Jan 05, 2009 at 12:25:51PM +0100, Johan Hendriks wrote: > >> I always use the following command to do the buildworld cycles. > >> make cleanworld && make -j3 buildworld && make -j3 kernel > >> But as of now i get the following error > > >Based on an email I got from Ken Smith, there seems to be something > >weird going on with the rescue build. I've made a temperary change > >to make(1) until I can figure out what it is. [svn r186713] > > >-- > >-- David (obrien@FreeBSD.org) > > Well i cvsuped today and still got an error when building with -j3 The SVN->CVS exporter was broken (disabled?) over the Holiday, please try again. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 16:22:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F244106564A for ; Mon, 5 Jan 2009 16:22:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0178FC08 for ; Mon, 5 Jan 2009 16:22:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2393511fgb.35 for ; Mon, 05 Jan 2009 08:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Mbw9FiO+ceqNd/m7oJEjy10vtNkklXSCRkNu5nYWVD4=; b=AMB1Dw+HQ5Viw70U2ZMoKOFZjlEkPRJ/62p4Z0TpVZqlDctCjJ1UvWxTfqkRyO8WSH Lh1XAjcMduv22UeGIi74J1wtIMN09saDKoqOFyKdQ4f50f0HMG1zqGOQJh/gg7MAUVQr J2dr8vz2+plPoKIxTfDzUJEwuIpJAKD6F6hK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=xqriF/QtsYQoP+Blk3s0N6mn/apOZ4DRsdPEhQmXtHYydZfYwKtAPPXKdSzBUVWdtX WRIrqafvFuwP0K/XcvHbqCDXAipG1wBso2x3Q8oMcEWR8zKCEmuJM4+tQ0QyhDcOR7jX gUAgJiTIfT9vuzyJ9z00L7n6+0NSKtViUKpHI= Received: by 10.86.52.6 with SMTP id z6mr11881925fgz.63.1231170664132; Mon, 05 Jan 2009 07:51:04 -0800 (PST) Received: by 10.86.90.10 with HTTP; Mon, 5 Jan 2009 07:51:04 -0800 (PST) Message-ID: <3bbf2fe10901050751y74ccd7e3va68fea0634fbd79f@mail.gmail.com> Date: Mon, 5 Jan 2009 16:51:04 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Anton Yuzhaninov" In-Reply-To: <494B740B.4080602@citrin.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4947C526.2080702@citrin.ru> <494B740B.4080602@citrin.ru> X-Google-Sender-Auth: be89fe954a9cf821 Cc: current@freebsd.org Subject: Re: hangup (livelock) - db> prompt in endless loop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 16:22:30 -0000 2008/12/19 Anton Yuzhaninov : > Anton Yuzhaninov wrote: >> >> My box with fresh current sometimes stops to respond. >> >> On screen in endless loop printed debugger prompt >> >> db> >> >> but I can't type anything here. >> >> Alt+Ctrl+Esc and Alt+Ctrl+Del don't stops this loop. >> >> How I can debug this problem? >> >> system: current from Mon Dec 15 16:16:23 MSK 2008 with GENERIC kernel, >> amd64, SMP. >> > > With more fresh current - Wed Dec 17 21:09:38 > Panic not repeated. This is probabilly a bug in the DDB lookup function. It just stops immediately or after a couple of commands? (and if it does, which comands exactly?) Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 17:45:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 947C6106566C for ; Mon, 5 Jan 2009 17:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 501878FC14 for ; Mon, 5 Jan 2009 17:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 84ED641C67E for ; Mon, 5 Jan 2009 18:45:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id KrLMCYdZBi7n for ; Mon, 5 Jan 2009 18:45:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 2FE0041C67B; Mon, 5 Jan 2009 18:45:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id CE2454448DD for ; Mon, 5 Jan 2009 17:43:38 +0000 (UTC) Date: Mon, 5 Jan 2009 17:43:38 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20090105172736.A45399@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: [cfr] rc.shutdown patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 17:45:07 -0000 Hi, while starting and stopping jails with rc.d/jail on a system that had no killall in the base (very stripped /usr/**) I found that unmounting devfs for the jail hadn't worked. Digging into this I found that rc.shutdown lets a sleep 30 (rcshutdown_timeout) hanging around for the rest of that time which is unpleasent if it could go away cleanly. I am using pkill, which is in /bin/ as well, to kill the sleep and the subshell instead of only killing the subshell and leaving the sleep hanging re-parented to init. I'd like to commit this but am a bit unsure for adding pkill dependency to such a central rc file; Though, two startup scripts seem to use it already (*ppp*) and dhclient uses 'pgrep' which is the same inode. I have a patch here: http://people.freebsd.org/~bz/20090105-03-rc-shutdown.diff ! ! Instead of killing the 'watchdog' subshell and leaving ! a sleep for the timeout, make sure all goes away cleanly. ! ! This avoids needing killall in rc.d/jail for a clean shutdown ! and generally does not leave dangling processes on shutdown that ! something else has to kill. ! Index: etc/rc.shutdown =================================================================== --- etc/rc.shutdown (revision 186775) +++ etc/rc.shutdown (working copy) @@ -98,7 +98,7 @@ # Terminate the background watchdog timer (if it is running) # if [ -n "$_rcshutdown_watchdog" ]; then - kill -TERM $_rcshutdown_watchdog >/dev/null 2>&1 + pkill -TERM -P $_rcshutdown_watchdog >/dev/null 2>&1 fi # Insert other shutdown procedures here Footnote: for jails we will want to keep the killall for other reasons (as we usually cannot trust the admin inside the jail to get a clean shutdown working). Any comments? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 21:00:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0D0F106566B for ; Mon, 5 Jan 2009 21:00:16 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 935728FC1B for ; Mon, 5 Jan 2009 21:00:16 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id 953968FC54 for ; Tue, 6 Jan 2009 00:00:15 +0300 (MSK) Received: from orion.SpringDaemons.com (drsun1.dialup.corbina.ru [85.21.245.235]) by mx0.deglitch.com (Postfix) with ESMTPA id 895F58FC4F; Tue, 6 Jan 2009 00:00:14 +0300 (MSK) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 16FC4398F3; Tue, 6 Jan 2009 00:02:40 +0300 (MSK) Date: Tue, 6 Jan 2009 00:02:40 +0300 From: Stanislav Sedov To: Hans Petter Selasky Message-Id: <20090106000240.d9636f60.stas@FreeBSD.org> In-Reply-To: <200901051059.39566.hselasky@c2i.net> References: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> <200901051059.39566.hselasky@c2i.net> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Jan 6 00:00:15 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 496274df967002024588998 Cc: Chris Ruiz , freebsd-current@freebsd.org Subject: Re: apcupsd & usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 21:00:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 5 Jan 2009 10:59:38 +0100 Hans Petter Selasky mentioned: > > You need to replace libusb0.1.xxx with libusb20 in /usr/local/lib or link > apcupsd with libusb20. Then it will work again. > Or use libmap.conf(5) which is safer. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAklidXAACgkQK/VZk+smlYFRpgCfe9cTucBn5HgRr4MT4inSikG7 2MwAn2Uwy7MBQoV76PpWeNX8KlJiJYhP =wAe+ -----END PGP SIGNATURE----- !DSPAM:496274df967002024588998! From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 21:28:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD49D10656BA for ; Mon, 5 Jan 2009 21:28:04 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8FBED8FC0C for ; Mon, 5 Jan 2009 21:28:04 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so3292313yxb.13 for ; Mon, 05 Jan 2009 13:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=uHeR2KybxH1cAdTcCvx53o5mfkQ/LDjb3XcQp28jMZQ=; b=ach+H9q7sx0l+jygMdzifNu0NdH3Y0BDfyM2JnwszTMyiF6/cZ0Jkl4Cn2agvKMEPr R+V/W/1Xn12lOPwqEC1Qegr4Anm1orBNbXSEu4NKluEzA9BZECEfjbY4DKw9K3cllkzg 1P0DSsyyDdb7QWKKYDQ0YwEP7z+yyPFO0Hv1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jI6yAGXa5pKTsAz64bTs1bbFzRhD9hyrvamaS1dDZARNE81lM5BlbRnljoXwHXk9wD CTxrJ3kBbdtWGA+vdMeTL1C+9sIFeT4WIGrv/pXzE+xED9PO62BnlJbOIdRUTiAV+c43 mrkUOpbHwVrriC0AgadvbnxIr7BWYVeTE4mNw= Received: by 10.151.41.21 with SMTP id t21mr12658529ybj.132.1231190883754; Mon, 05 Jan 2009 13:28:03 -0800 (PST) Received: by 10.150.98.19 with HTTP; Mon, 5 Jan 2009 13:28:03 -0800 (PST) Message-ID: <58c737d70901051328t38b99a14g52a0d85bbbc1daa2@mail.gmail.com> Date: Mon, 5 Jan 2009 15:28:03 -0600 From: "Chris Ruiz" To: freebsd-current@freebsd.org In-Reply-To: <200901051059.39566.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> <200901051059.39566.hselasky@c2i.net> Subject: Re: apcupsd & usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 21:28:05 -0000 On Mon, Jan 5, 2009 at 3:59 AM, Hans Petter Selasky wrote: > On Monday 05 January 2009, Chris Ruiz wrote: >> apcupsd no longer works now that i switched to usb2. the >> usb2_input_hid module keeps attaching to it. before, with the old usb >> stack, my ups would attach as ugen0, my dmesg shows it attaching as >> uhid0 now and apcupsd cannot find it. if i unload the usb2_input_hid >> module, my ups disappears. because something is mentioned in the post >> install text for apcupsd, i believe that the usb2_hid_module should >> not be attaching to the ups. any help would be appreciated. >> >> [old stack] >> ugen0: > FW:E6, class 0/0, rev 1.10/1.06, addr 2> on uhub5 >> >> [usb2] >> uhid0: > FW:E6, class 0/0, rev 1.10/1.06, addr 2> on usbus5 >> Symlink: uhid0 -> usb5.2.0.16 >> >> [error message] >> apcupsd[3643]: apcupsd FATAL ERROR in bsd-usb.c at line 735 Cannot >> find UPS device -- For a link to detailed USB trouble shooting >> information, please see . >> apcupsd[3643]: apcupsd error shutdown completed >> >> thanks for all your hard work on the new usb stack, > > Hi Chris, > > You need to replace libusb0.1.xxx with libusb20 in /usr/local/lib or link > apcupsd with libusb20. Then it will work again. > > --HPS > I dont have a libusb0.1.* anywhere on my system. Here's what apcupsd is linked to: # ldd /usr/local/sbin/apcupsd /usr/local/sbin/apcupsd: libwrap.so.5 => /usr/lib/libwrap.so.5 (0x800660000) libthr.so.3 => /lib/libthr.so.3 (0x800769000) libc.so.7 => /lib/libc.so.7 (0x800880000) Thanks, Chris From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 21:48:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4818110656C5 for ; Mon, 5 Jan 2009 21:48:19 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swip.net [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 62F918FC08 for ; Mon, 5 Jan 2009 21:48:18 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=rREUrScshOl7G2h6aTFPgw==:17 a=5gVvIhBEAAAA:8 a=6VBTdfXg2-7jrbF3rtoA:9 a=L6iBP6StayY52gENlcIA:7 a=f38zJypjYi7OxMaMJJfFUD7HcZ4A:4 a=9aOQ2cSd83gA:10 a=LY0hPdMaydYA:10 Received: from [62.73.248.227] (account mc467741@c2i.net [62.73.248.227] verified) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1006232591; Mon, 05 Jan 2009 22:48:16 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 5 Jan 2009 22:50:34 +0100 User-Agent: KMail/1.9.7 References: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> <200901051059.39566.hselasky@c2i.net> <58c737d70901051328t38b99a14g52a0d85bbbc1daa2@mail.gmail.com> In-Reply-To: <58c737d70901051328t38b99a14g52a0d85bbbc1daa2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901052250.36428.hselasky@c2i.net> Cc: Chris Ruiz Subject: Re: apcupsd & usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 21:48:19 -0000 On Monday 05 January 2009, Chris Ruiz wrote: > On Mon, Jan 5, 2009 at 3:59 AM, Hans Petter Selasky wrote: > > On Monday 05 January 2009, Chris Ruiz wrote: > >> apcupsd no longer works now that i switched to usb2. the > >> usb2_input_hid module keeps attaching to it. before, with the old usb > >> stack, my ups would attach as ugen0, my dmesg shows it attaching as > >> uhid0 now and apcupsd cannot find it. if i unload the usb2_input_hid > >> module, my ups disappears. because something is mentioned in the post > >> install text for apcupsd, i believe that the usb2_hid_module should > >> not be attaching to the ups. any help would be appreciated. > >> > >> [old stack] > >> ugen0: >> FW:E6, class 0/0, rev 1.10/1.06, addr 2> on uhub5 > >> > >> [usb2] > >> uhid0: >> FW:E6, class 0/0, rev 1.10/1.06, addr 2> on usbus5 > >> Symlink: uhid0 -> usb5.2.0.16 > >> > >> [error message] > >> apcupsd[3643]: apcupsd FATAL ERROR in bsd-usb.c at line 735 Cannot > >> find UPS device -- For a link to detailed USB trouble shooting > >> information, please see . > >> apcupsd[3643]: apcupsd error shutdown completed > >> > >> thanks for all your hard work on the new usb stack, > > > > Hi Chris, > > > > You need to replace libusb0.1.xxx with libusb20 in /usr/local/lib or link > > apcupsd with libusb20. Then it will work again. > > > > --HPS > > I dont have a libusb0.1.* anywhere on my system. Here's what apcupsd > is linked to: Ok, Then you have to recompile apcupsd to use the generic USB driver (NOT the bsd.c). Maybe you can figure this out? /usr/ports/sysutils/apcupsd/work/apcupsd-3.14.4/src/drivers/usb/generic Makefile generic-usb.c hidutils.c hidutils.h libusb.h.in After that libusb gets installed you can use libmap.conf to make apcupsd use libusb20 instead of libusb from ports. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 00:22:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA0D3106564A for ; Tue, 6 Jan 2009 00:22:38 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 3E8DD8FC17 for ; Tue, 6 Jan 2009 00:22:38 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1LJzTT-0005n5-8U>; Tue, 06 Jan 2009 01:07:11 +0100 Received: from e178006011.adsl.alicedsl.de ([85.178.6.11] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1LJzTT-0000F7-0R>; Tue, 06 Jan 2009 01:07:11 +0100 Message-ID: <4962A0D3.1010704@mail.zedat.fu-berlin.de> Date: Tue, 06 Jan 2009 01:07:47 +0100 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.6.11 X-Mailman-Approved-At: Tue, 06 Jan 2009 01:30:13 +0000 Subject: FreeBSD 8: fails booting from slice ad8s1a X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 00:22:39 -0000 Since January, 3rd my FreeBSD 8/amd64 box won't boot anymore. I have buildworld the most recent sources. Symptomes: after loading and booting kernel, booting suddenly stops and I'm getting prompted for defining the boot slice like ufs:/dev/ad8s1a Typing '?' offers GEOM managed slices/partitions/devices. What changed? Well, I;m confused, because everything worked perfect on January 3rd when I recompiled world, but after then, after svn updating again, booting stops. What informations should I provide? dmesg follows: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #29 r186724: Sat Jan 3 17:19:08 CET 2009 root@thor.walstatt.dyndns.org:/usr/obj/usr/src/sys/THOR Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3500+ (2376.07-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 Features=0x78bfbff AMD Features=0xe2500800 AMD Features2=0x1 usable memory = 2136616960 (2037 MB) avail memory = 2065059840 (1969 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded kbd1 at kbdmux0 smbios0: at iomem 0xfbdc0-0xfbdde on motherboard smbios0: Version: 2.3, BCD Revision: 2.3 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of e0000, 20000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 atapci0: port 0xcc00-0xcc7f mem 0xdceffc00-0xdceffc7f,0xdcef8000-0xdcefbfff irq 16 at device 0.0 on pci1 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pcib2: at device 3.0 on pci0 pci2: on pcib2 mskc0: port 0xd800-0xd8ff mem 0xdcffc000-0xdcffffff irq 17 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:15:f2:a2:79:aa miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [FILTER] pcib3: at device 4.0 on pci0 pci3: on pcib3 vgapci0: mem 0xde000000-0xdeffffff,0xc0000000-0xcfffffff,0xdd000000-0xddffffff irq 17 at device 0.0 on pci3 pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 nfsmb0: port 0xbc00-0xbc1f,0x600-0x63f,0x700-0x73f irq 20 at device 10.1 on pci0 smbus0: on nfsmb0 smb0: on smbus0 nfsmb1: on nfsmb0 smbus1: on nfsmb1 smb1: on smbus1 ohci0: mem 0xdcdfe000-0xdcdfefff irq 21 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xdcdffc00-0xdcdffcff irq 22 at device 11.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 15.0 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] atapci2: port 0xb480-0xb487,0xb400-0xb403,0xb080-0xb087,0xb000-0xb003,0xac00-0xac0f mem 0xdcdfd000-0xdcdfdfff irq 23 at device 16.0 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xa880-0xa887,0xa800-0xa803,0xa480-0xa487,0xa400-0xa403,0xa080-0xa08f mem 0xdcdfc000-0xdcdfcfff irq 20 at device 17.0 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] pcib4: at device 18.0 on pci0 pci4: on pcib4 pcm0: port 0xec00-0xec1f,0xe880-0xe8ff irq 18 at device 8.0 on pci4 pcm0: [GIANT-LOCKED] pcm0: [ITHREAD] pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x3631 XIN2 Clock Source: 49.152MHz(192kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 DAC #: 3 Multi-track converter type: I2S(with volume, 192KHz support, 24bit resolution, ID#0x0) S/PDIF(IN/OUT): 0/1 ID# 0x00 GPIO(mask/dir/state): 0x3fff85/0x4000fa/0x72 pci4: at device 11.0 (no driver attached) nfe0: port 0xa000-0xa007 mem 0xdcdfb000-0xdcdfbfff irq 21 at device 19.0 on pci0 miibus1: on nfe0 e1000phy1: PHY 1 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:15:f2:a2:85:ba nfe0: [FILTER] pcib5: at device 22.0 on pci0 pci5: on pcib5 pcib6: at device 23.0 on pci0 pci6: on pcib6 k8temp0: on hostb3 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 acpi_throttle0: on cpu0 sc0: at flags 0x100 on isa0 sc0: VGA <8 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0 at vga0 Timecounter "TSC" frequency 2376069974 Hz quality 800 Timecounters tick every 1.333 msec IPsec: Initialized Security Association Processing. usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 ushub0: on usbus0 ushub0: 10 ports with 10 removable, self powered usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 ushub1: on usbus1 ushub1: 10 ports with 10 removable, self powered acd0: DVDR at ata0-master UDMA33 ad8: 238475MB at ata4-master SATA300 ad10: 953869MB at ata5-master SATA300 GEOM: ad8s1: geometry does not match label (255h,63s != 16h,63s). ad12: 238475MB at ata6-master SATA300 GEOM: ad8s2: geometry does not match label (255h,63s != 16h,63s). ad14: 152627MB at ata7-master SATA300 ar0: 476950MB Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present ia MediaShield RAID0 (stripe 64 KB)> status: READY ar0: disk0 READY using ad12 at ata6-master ar0: disk1 READY using ad8 at ata4-master hwpmc: TSC/1/64/0x20 K8/4/48/0x1ff GEOM_LABEL: Label for provider ad14s1 is ntfs/THOR. Trying to mount root from ufs:/dev/ad8s1a ugen0.2: at usbus0 ums0: on usbus0 ums0: 8 buttons and [XYZ] coordinates Symlink: ums0 -> usb0.2.0.16 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 13 ZFS storage pool version 13 pid 1226 (slapd), uid 389: exited on signal 11 nfe0: link state changed to UP From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 04:08:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92D7F106564A for ; Tue, 6 Jan 2009 04:08:36 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9958FC16 for ; Tue, 6 Jan 2009 04:08:36 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.96] (75-101-29-67.dsl.static.sonic.net [75.101.29.67]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KD1000ET7IB4X10@asmtp022.mac.com> for freebsd-current@freebsd.org; Mon, 05 Jan 2009 20:08:36 -0800 (PST) Message-id: From: Marcel Moolenaar To: "O. Hartmann" In-reply-to: <4962A0D3.1010704@mail.zedat.fu-berlin.de> Date: Mon, 05 Jan 2009 20:08:35 -0800 References: <4962A0D3.1010704@mail.zedat.fu-berlin.de> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 8: fails booting from slice ad8s1a X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 04:08:36 -0000 On Jan 5, 2009, at 4:07 PM, O. Hartmann wrote: > Since January, 3rd my FreeBSD 8/amd64 box won't boot anymore. I have > buildworld the most recent sources. Symptomes: after loading and > booting > kernel, > booting suddenly stops and I'm getting prompted for defining the boot > slice like > > ufs:/dev/ad8s1a > > Typing '?' offers GEOM managed slices/partitions/devices. What > changed? GEOM_PART is default. What are the GEOM managed slices/partitions/devices listed? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 13:14:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 966651065674 for ; Tue, 6 Jan 2009 13:14:20 +0000 (UTC) (envelope-from root@dchagin.dialup.corbina.ru) Received: from contrabass.post.ru (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 93D938FC16 for ; Tue, 6 Jan 2009 13:14:19 +0000 (UTC) (envelope-from root@dchagin.dialup.corbina.ru) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.post.ru (Postfix) with ESMTP id 9F1123FA98 for ; Tue, 6 Jan 2009 15:46:46 +0300 (MSK) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from dchagin.dialup.corbina.ru ([78.107.232.239] verified) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 1554528032 for freebsd-current@freebsd.org; Tue, 06 Jan 2009 15:46:46 +0300 Received: from dchagin.dialup.corbina.ru (localhost.chd.net [127.0.0.1]) by dchagin.dialup.corbina.ru (8.14.3/8.14.3) with ESMTP id n06Cki3f002691 for ; Tue, 6 Jan 2009 15:46:46 +0300 (MSK) (envelope-from root@dchagin.dialup.corbina.ru) Received: (from root@localhost) by dchagin.dialup.corbina.ru (8.14.3/8.14.3/Submit) id n06Ckde9002687 for freebsd-current@freebsd.org; Tue, 6 Jan 2009 15:46:39 +0300 (MSK) (envelope-from root) Date: Tue, 6 Jan 2009 15:46:16 +0300 From: Chagin Dmitry To: freebsd-current@freebsd.org Message-ID: <20090106124615.GA2563@dchagin.dialup.corbina.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: RFC: ELF branding. looking to a ".note.ABI-tag" section X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 13:14:20 -0000 Hi, please, look a patch bellow. kern/118473 related. any comments, help :) Implement new way of branding ELF binaries by looking to a ".note.ABI-tag" section. For what handler .brand_abi_note in Elf_Brandinfo is added. The search order of a brand is changed, now first of all the ".note.ABI-tag" is looked through. Implement .brand_abi_note handler for FreeBSD and Linux binaries. Move code which fetch osreldate for FreeBSD binaries to corresponding handler. Add new branding flag BI_CAN_EXEC_INTERP, which is used if the ABI allows interpreter start (as executable). Implement corresponding handler. diff --git a/sys/amd64/amd64/elf_machdep.c b/sys/amd64/amd64/elf_machdep.c index 4f6d178..0aea61d 100644 --- a/sys/amd64/amd64/elf_machdep.c +++ b/sys/amd64/amd64/elf_machdep.c @@ -84,7 +84,8 @@ static Elf64_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf64, SI_SUB_EXEC, SI_ORDER_ANY, @@ -99,7 +100,8 @@ static Elf64_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf64, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/amd64/linux32/linux32_sysvec.c b/sys/amd64/linux32/linux32_sysvec.c index de60744..339bc38 100644 --- a/sys/amd64/linux32/linux32_sysvec.c +++ b/sys/amd64/linux32/linux32_sysvec.c @@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include #include @@ -93,6 +94,8 @@ MALLOC_DEFINE(M_LINUX, "linux", "Linux mode structures"); suword32(pos++, val); \ } while (0) +#define aligned(a, t) (rounddown((unsigned long)(a), sizeof(t)) == (unsigned long)(a)) + #if BYTE_ORDER == LITTLE_ENDIAN #define SHELLMAGIC 0x2123 /* #! */ #else @@ -999,6 +1002,54 @@ linux32_fixlimit(struct rlimit *rl, int which) } } +static const char GNULINUX_ABI_VENDOR[] = "GNU"; +static const int GNULINUX_ABI_LEN = 16; + +static int +linux32_abi_note(struct image_params *imgp, int32_t *osrel) +{ + const Elf_Note *note, *note_end; + const Elf32_Phdr *phdr, *pnote; + const Elf32_Ehdr *hdr; + const char *note_name; + int i; + + pnote = NULL; + hdr = (const Elf32_Ehdr *)imgp->image_header; + phdr = (const Elf32_Phdr *)(imgp->image_header + hdr->e_phoff); + + for (i = 0; i < hdr->e_phnum; i++) + if (phdr[i].p_type == PT_NOTE) { + pnote = &phdr[i]; + break; + } + + if (pnote == NULL || pnote->p_offset >= PAGE_SIZE || + pnote->p_offset + pnote->p_filesz >= PAGE_SIZE) + return (0); + + note = (const Elf_Note *)(imgp->image_header + pnote->p_offset); + if (!aligned(note, uint32_t)) + return (0); + note_end = (const Elf_Note *)(hdr + pnote->p_offset + + pnote->p_filesz); + while (note < note_end) { + if (note->n_namesz == sizeof(GNULINUX_ABI_VENDOR) && + note->n_descsz == GNULINUX_ABI_LEN && + note->n_type == 1 /* ABI_NOTETYPE */) { + note_name = (const char *)(note + 1); + if (strncmp(GNULINUX_ABI_VENDOR, note_name, + sizeof(GNULINUX_ABI_VENDOR)) == 0) + return(1); + } + note = (const Elf_Note *)((const char *)(note + 1) + + roundup2(note->n_namesz, sizeof(Elf32_Addr)) + + roundup2(note->n_descsz, sizeof(Elf32_Addr))); + } + + return (0); +} + struct sysentvec elf_linux_sysvec = { .sv_size = LINUX_SYS_MAXSYSCALL, .sv_table = linux_sysent, @@ -1038,7 +1089,8 @@ static Elf32_Brandinfo linux_brand = { .interp_path = "/lib/ld-linux.so.1", .sysvec = &elf_linux_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = linux32_abi_note, + .flags = BI_CAN_EXEC_DYN | BI_CAN_EXEC_INTERP }; static Elf32_Brandinfo linux_glibc2brand = { @@ -1049,7 +1101,8 @@ static Elf32_Brandinfo linux_glibc2brand = { .interp_path = "/lib/ld-linux.so.2", .sysvec = &elf_linux_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = linux32_abi_note, + .flags = BI_CAN_EXEC_DYN | BI_CAN_EXEC_INTERP }; Elf32_Brandinfo *linux_brandlist[] = { diff --git a/sys/arm/arm/elf_machdep.c b/sys/arm/arm/elf_machdep.c index 693eab1..e65f947 100644 --- a/sys/arm/arm/elf_machdep.c +++ b/sys/arm/arm/elf_machdep.c @@ -84,7 +84,8 @@ static Elf32_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf32, SI_SUB_EXEC, SI_ORDER_ANY, @@ -99,7 +100,8 @@ static Elf32_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf32, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/compat/ia32/ia32_sysvec.c b/sys/compat/ia32/ia32_sysvec.c index 0b32b9a..92b990a 100644 --- a/sys/compat/ia32/ia32_sysvec.c +++ b/sys/compat/ia32/ia32_sysvec.c @@ -148,6 +148,7 @@ static Elf32_Brandinfo ia32_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &ia32_freebsd_sysvec, .interp_newpath = "/libexec/ld-elf32.so.1", + .brand_abi_note = __elfN(freebsd_abi_note), .flags = BI_CAN_EXEC_DYN }; @@ -163,7 +164,8 @@ static Elf32_Brandinfo ia32_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &ia32_freebsd_sysvec, .interp_newpath = "/libexec/ld-elf32.so.1", - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oia32, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/compat/svr4/svr4_sysvec.c b/sys/compat/svr4/svr4_sysvec.c index 0030e3a..a406576 100644 --- a/sys/compat/svr4/svr4_sysvec.c +++ b/sys/compat/svr4/svr4_sysvec.c @@ -204,6 +204,7 @@ Elf32_Brandinfo svr4_brand = { .interp_path = "/lib/libc.so.1", .sysvec = &svr4_sysvec, .interp_newpath = NULL, + .brand_abi_note = NULL, .flags = 0 }; diff --git a/sys/i386/i386/elf_machdep.c b/sys/i386/i386/elf_machdep.c index 19eddd0..593f9bd 100644 --- a/sys/i386/i386/elf_machdep.c +++ b/sys/i386/i386/elf_machdep.c @@ -84,7 +84,8 @@ static Elf32_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf32, SI_SUB_EXEC, SI_ORDER_ANY, @@ -99,7 +100,8 @@ static Elf32_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf32, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linux_sysvec.c index 66cb336..c3f1e84 100644 --- a/sys/i386/linux/linux_sysvec.c +++ b/sys/i386/linux/linux_sysvec.c @@ -91,6 +91,7 @@ MALLOC_DEFINE(M_LINUX, "linux", "Linux mode structures"); #define fldcw(addr) __asm("fldcw %0" : : "m" (*(addr))) #define __LINUX_NPXCW__ 0x37f +#define aligned(a, t) (rounddown((unsigned long)(a), sizeof(t)) == (unsigned long)(a)) extern char linux_sigcode[]; extern int linux_szsigcode; @@ -964,6 +965,53 @@ linux_get_machine(const char **dst) return (0); } +static const char GNULINUX_ABI_VENDOR[] = "GNU"; +static const int GNULINUX_ABI_LEN = 16; + +static int +linux_abi_note(struct image_params *imgp, int32_t *osrel) +{ + const Elf_Note *note, *note_end; + const Elf32_Phdr *phdr, *pnote; + const Elf32_Ehdr *hdr; + const char *note_name; + int i; + + pnote = NULL; + hdr = (const Elf32_Ehdr *)imgp->image_header; + phdr = (const Elf32_Phdr *)(imgp->image_header + hdr->e_phoff); + + for (i = 0; i < hdr->e_phnum; i++) + if (phdr[i].p_type == PT_NOTE) { + pnote = &phdr[i]; + break; + } + if (pnote == NULL || pnote->p_offset >= PAGE_SIZE || + pnote->p_offset + pnote->p_filesz >= PAGE_SIZE) + return (0); + + note = (const Elf_Note *)(imgp->image_header + pnote->p_offset); + if (!aligned(note, uint32_t)) + return (0); + note_end = (const Elf_Note *)(hdr + pnote->p_offset + + pnote->p_filesz); + while (note < note_end) { + if (note->n_namesz == sizeof(GNULINUX_ABI_VENDOR) && + note->n_descsz == GNULINUX_ABI_LEN && + note->n_type == 1 /* ABI_NOTETYPE */) { + note_name = (const char *)(note + 1); + if (strncmp(GNULINUX_ABI_VENDOR, note_name, + sizeof(GNULINUX_ABI_VENDOR)) == 0) + return(1); + } + note = (const Elf_Note *)((const char *)(note + 1) + + roundup2(note->n_namesz, sizeof(Elf32_Addr)) + + roundup2(note->n_descsz, sizeof(Elf32_Addr))); + } + + return (0); +} + struct sysentvec linux_sysvec = { .sv_size = LINUX_SYS_MAXSYSCALL, @@ -1035,7 +1083,8 @@ static Elf32_Brandinfo linux_brand = { .interp_path = "/lib/ld-linux.so.1", .sysvec = &elf_linux_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = linux_abi_note, + .flags = BI_CAN_EXEC_DYN | BI_CAN_EXEC_INTERP }; static Elf32_Brandinfo linux_glibc2brand = { @@ -1046,7 +1095,8 @@ static Elf32_Brandinfo linux_glibc2brand = { .interp_path = "/lib/ld-linux.so.2", .sysvec = &elf_linux_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = linux_abi_note, + .flags = BI_CAN_EXEC_DYN | BI_CAN_EXEC_INTERP }; Elf32_Brandinfo *linux_brandlist[] = { diff --git a/sys/ia64/ia64/elf_machdep.c b/sys/ia64/ia64/elf_machdep.c index a3a6e57..a0289de 100644 --- a/sys/ia64/ia64/elf_machdep.c +++ b/sys/ia64/ia64/elf_machdep.c @@ -92,7 +92,8 @@ static Elf64_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf64, SI_SUB_EXEC, SI_ORDER_ANY, (sysinit_cfunc_t)elf64_insert_brand_entry, &freebsd_brand_info); @@ -105,7 +106,8 @@ static Elf64_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf64, SI_SUB_EXEC, SI_ORDER_ANY, (sysinit_cfunc_t)elf64_insert_brand_entry, &freebsd_brand_oinfo); diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 431ee38..c970291 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -78,8 +78,8 @@ __FBSDID("$FreeBSD$"); #define OLD_EI_BRAND 8 static int __elfN(check_header)(const Elf_Ehdr *hdr); -static Elf_Brandinfo *__elfN(get_brandinfo)(const Elf_Ehdr *hdr, - const char *interp); +static Elf_Brandinfo *__elfN(get_brandinfo)(struct image_params *imgp, + const char *interp, int32_t *osrel); static int __elfN(load_file)(struct proc *p, const char *file, u_long *addr, u_long *entry, size_t pagesize); static int __elfN(load_section)(struct vmspace *vmspace, vm_object_t object, @@ -158,19 +158,31 @@ __elfN(brand_inuse)(Elf_Brandinfo *entry) } static Elf_Brandinfo * -__elfN(get_brandinfo)(const Elf_Ehdr *hdr, const char *interp) +__elfN(get_brandinfo)(struct image_params *imgp, const char *interp, + int32_t *osrel) { + const Elf_Ehdr *hdr = (const Elf_Ehdr *)imgp->image_header; Elf_Brandinfo *bi; + int ret, fname_len, interp_len; int i; /* - * We support three types of branding -- (1) the ELF EI_OSABI field + * We support four types of branding -- (1) the ELF EI_OSABI field * that SCO added to the ELF spec, (2) FreeBSD 3.x's traditional string - * branding w/in the ELF header, and (3) path of the `interp_path' - * field. We should also look for an ".note.ABI-tag" ELF section now - * in all Linux ELF binaries, FreeBSD 4.1+, and some NetBSD ones. + * branding w/in the ELF header, (3) path of the `interp_path' + * field, and (4) the ".note.ABI-tag" ELF section. */ + /* Look for an ".note.ABI-tag" ELF section */ + for (i = 0; i < MAX_BRANDS; i++) { + bi = elf_brand_list[i]; + if (bi != NULL && hdr->e_machine == bi->machine && bi->brand_abi_note) { + ret = (*bi->brand_abi_note)(imgp, osrel); + if (ret) + return (bi); + } + } + /* If the executable has a brand, search for it in the brand list. */ for (i = 0; i < MAX_BRANDS; i++) { bi = elf_brand_list[i]; @@ -191,6 +203,23 @@ __elfN(get_brandinfo)(const Elf_Ehdr *hdr, const char *interp) } } + /* Some ABI (Linux) allow to run the interpreter. */ + for (i = 0; i < MAX_BRANDS; i++) { + bi = elf_brand_list[i]; + if (bi == NULL || hdr->e_machine != bi->machine || + (bi->flags & BI_CAN_EXEC_INTERP) == 0) + continue; + + fname_len = strlen(imgp->args->fname); + interp_len = strlen(bi->interp_path); + if (fname_len < interp_len) + continue; + ret = strncmp(imgp->args->fname + (fname_len - interp_len), + bi->interp_path, interp_len); + if (ret == 0) + return (bi); + } + /* Lacking a recognized interpreter, try the default brand */ for (i = 0; i < MAX_BRANDS; i++) { bi = elf_brand_list[i]; @@ -590,13 +619,11 @@ fail: return (error); } -static const char FREEBSD_ABI_VENDOR[] = "FreeBSD"; - static int __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) { const Elf_Ehdr *hdr = (const Elf_Ehdr *)imgp->image_header; - const Elf_Phdr *phdr, *pnote = NULL; + const Elf_Phdr *phdr; Elf_Auxargs *elf_auxargs; struct vmspace *vmspace; vm_prot_t prot; @@ -604,12 +631,11 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) u_long text_addr = 0, data_addr = 0; u_long seg_size, seg_addr; u_long addr, entry = 0, proghdr = 0; + int32_t osrel = 0; int error = 0, i; const char *interp = NULL, *newinterp = NULL; Elf_Brandinfo *brand_info; - const Elf_Note *note, *note_end; char *path; - const char *note_name; struct sysentvec *sv; /* @@ -646,7 +672,7 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) } } - brand_info = __elfN(get_brandinfo)(hdr, interp); + brand_info = __elfN(get_brandinfo)(imgp, interp, &osrel); if (brand_info == NULL) { uprintf("ELF binary type \"%u\" not known.\n", hdr->e_ident[EI_OSABI]); @@ -750,9 +776,6 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) case PT_PHDR: /* Program header table info */ proghdr = phdr[i].p_vaddr; break; - case PT_NOTE: - pnote = &phdr[i]; - break; default: break; } @@ -839,41 +862,7 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) imgp->auxargs = elf_auxargs; imgp->interpreted = 0; - - /* - * Try to fetch the osreldate for FreeBSD binary from the ELF - * OSABI-note. Only the first page of the image is searched, - * the same as for headers. - */ - if (pnote != NULL && pnote->p_offset < PAGE_SIZE && - pnote->p_offset + pnote->p_filesz < PAGE_SIZE ) { - note = (const Elf_Note *)(imgp->image_header + pnote->p_offset); - if (!aligned(note, Elf32_Addr)) { - free(imgp->auxargs, M_TEMP); - imgp->auxargs = NULL; - return (ENOEXEC); - } - note_end = (const Elf_Note *)(imgp->image_header + pnote->p_offset + - pnote->p_filesz); - while (note < note_end) { - if (note->n_namesz == sizeof(FREEBSD_ABI_VENDOR) && - note->n_descsz == sizeof(int32_t) && - note->n_type == 1 /* ABI_NOTETYPE */) { - note_name = (const char *)(note + 1); - if (strncmp(FREEBSD_ABI_VENDOR, note_name, - sizeof(FREEBSD_ABI_VENDOR)) == 0) { - imgp->proc->p_osrel = *(const int32_t *) - (note_name + - round_page_ps(sizeof(FREEBSD_ABI_VENDOR), - sizeof(Elf32_Addr))); - break; - } - } - note = (const Elf_Note *)((const char *)(note + 1) + - round_page_ps(note->n_namesz, sizeof(Elf32_Addr)) + - round_page_ps(note->n_descsz, sizeof(Elf32_Addr))); - } - } + imgp->proc->p_osrel = osrel; return (error); } @@ -1334,6 +1323,63 @@ __elfN(putnote)(void *dst, size_t *off, const char *name, int type, *off += roundup2(note.n_descsz, sizeof(Elf_Size)); } +static const char FREEBSD_ABI_VENDOR[] = "FreeBSD"; + +int +__elfN(freebsd_abi_note)(struct image_params *imgp, int32_t *osrel) +{ + const Elf_Note *note, *note_end; + const Elf32_Phdr *phdr, *pnote; + const Elf32_Ehdr *hdr; + const char *note_name; + int i; + + pnote = NULL; + hdr = (const Elf32_Ehdr *)imgp->image_header; + phdr = (const Elf32_Phdr *)(imgp->image_header + hdr->e_phoff); + + for (i = 0; i < hdr->e_phnum; i++) + if (phdr[i].p_type == PT_NOTE) { + pnote = &phdr[i]; + break; + } + + if (pnote == NULL || pnote->p_offset >= PAGE_SIZE || + pnote->p_offset + pnote->p_filesz >= PAGE_SIZE) + return (0); + + note = (const Elf_Note *)(imgp->image_header + pnote->p_offset); + if (!aligned(note, uint32_t)) + return (0); + note_end = (const Elf_Note *)(hdr + pnote->p_offset + + pnote->p_filesz); + while (note < note_end) { + if (note->n_namesz == sizeof(FREEBSD_ABI_VENDOR) && + note->n_descsz == sizeof(int32_t) && + note->n_type == 1 /* ABI_NOTETYPE */) { + note_name = (const char *)(note + 1); + if (strncmp(FREEBSD_ABI_VENDOR, note_name, + sizeof(FREEBSD_ABI_VENDOR)) != 0) + continue; + /* + * Fetch the osreldate for FreeBSD binary + * from the ELF OSABI-note. + */ + if (osrel != NULL) + *osrel = *(const int32_t *) + (note_name + + round_page_ps(sizeof(FREEBSD_ABI_VENDOR), + sizeof(Elf32_Addr))); + return(1); + } + note = (const Elf_Note *)((const char *)(note + 1) + + round_page_ps(note->n_namesz, sizeof(Elf32_Addr)) + + round_page_ps(note->n_descsz, sizeof(Elf32_Addr))); + } + + return (0); +} + /* * Tell kern_execve.c about it, with a little help from the linker. */ diff --git a/sys/mips/mips/elf_machdep.c b/sys/mips/mips/elf_machdep.c index 163d0ee..807ae67 100644 --- a/sys/mips/mips/elf_machdep.c +++ b/sys/mips/mips/elf_machdep.c @@ -86,6 +86,8 @@ static Elf32_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, + .brand_abi_note = NULL, + .brand_abi_note = NULL, .flags = 0 }; diff --git a/sys/powerpc/powerpc/elf_machdep.c b/sys/powerpc/powerpc/elf_machdep.c index 69ac55b..f0dc474 100644 --- a/sys/powerpc/powerpc/elf_machdep.c +++ b/sys/powerpc/powerpc/elf_machdep.c @@ -87,7 +87,8 @@ static Elf32_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf32, SI_SUB_EXEC, SI_ORDER_ANY, @@ -102,7 +103,8 @@ static Elf32_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf32, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/sparc64/sparc64/elf_machdep.c b/sys/sparc64/sparc64/elf_machdep.c index a956c5c..03b9056 100644 --- a/sys/sparc64/sparc64/elf_machdep.c +++ b/sys/sparc64/sparc64/elf_machdep.c @@ -99,7 +99,8 @@ static Elf64_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf64, SI_SUB_EXEC, SI_ORDER_ANY, @@ -114,7 +115,8 @@ static Elf64_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf64, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/sys/imgact_elf.h b/sys/sys/imgact_elf.h index deb5b10..d290185 100644 --- a/sys/sys/imgact_elf.h +++ b/sys/sys/imgact_elf.h @@ -62,8 +62,10 @@ typedef struct { const char *interp_path; struct sysentvec *sysvec; const char *interp_newpath; + int (*brand_abi_note)(struct image_params *, int32_t *); int flags; -#define BI_CAN_EXEC_DYN 0x0001 +#define BI_CAN_EXEC_DYN 0x0001 +#define BI_CAN_EXEC_INTERP 0x0002 } __ElfN(Brandinfo); __ElfType(Auxargs); @@ -76,6 +78,7 @@ int __elfN(insert_brand_entry)(Elf_Brandinfo *entry); int __elfN(remove_brand_entry)(Elf_Brandinfo *entry); int __elfN(freebsd_fixup)(register_t **, struct image_params *); int __elfN(coredump)(struct thread *, struct vnode *, off_t); +int __elfN(freebsd_abi_note)(struct image_params *, int32_t *); /* Machine specific function to dump per-thread information. */ void __elfN(dump_thread)(struct thread *, void *, size_t *); -- Have fun! chd From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 15:20:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4319106566B for ; Tue, 6 Jan 2009 15:20:32 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A4DAC8FC12 for ; Tue, 6 Jan 2009 15:20:31 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LKDjG-0003Eo-NU for freebsd-current@freebsd.org; Tue, 06 Jan 2009 15:20:26 +0000 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Jan 2009 15:20:26 +0000 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Jan 2009 15:20:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Tue, 06 Jan 2009 07:20:15 -0800 Lines: 793 Message-ID: References: <4962A0D3.1010704@mail.zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.10.9 Sender: news Subject: Re: FreeBSD 8: fails booting from slice ad8s1a X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 15:20:32 -0000 Marcel Moolenaar wrote: > On Jan 5, 2009, at 4:07 PM, O. Hartmann wrote: > >> Since January, 3rd my FreeBSD 8/amd64 box won't boot anymore. I have >> buildworld the most recent sources. Symptomes: after loading and >> booting >> kernel, >> booting suddenly stops and I'm getting prompted for defining the boot >> slice like >> >> ufs:/dev/ad8s1a >> >> Typing '?' offers GEOM managed slices/partitions/devices. What >> changed? > > GEOM_PART is default. > > What are the GEOM managed slices/partitions/devices listed? > I am having the same problem updating yesterday to Jan 5th -current sources from a Nov 25 kernel. The old kernel boots and mounts find, the Jan 5th kernel does not. The way mountroot fails hints that it's just probably looking in the wrong place. lsdev from the bootloader finds the filesystem and I can boot /boot/kernel.old/kernel from here. But the mountroot fallback cannot find the slice. OK lsdev cd devices: disk devices: disk0: BIOS drive C: disk0s1a: FFS disk0s1b: swap pxe devices: Full verbose boot, mountroot failure and slice/label info below: OK boot -v -s GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009f800 SMAP type=02 base=000000000009f800 len=0000000000000800 SMAP type=02 base=00000000000dc000 len=0000000000024000 SMAP type=01 base=0000000000100000 len=000000003fd90000 SMAP type=03 base=000000003fe90000 len=000000000000d000 SMAP type=04 base=000000003fe9d000 len=0000000000063000 SMAP type=02 base=000000003ff00000 len=0000000000100000 SMAP type=02 base=00000000fec00000 len=0000000000010000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ff000000 len=0000000001000000 Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #27: Mon Jan 5 14:48:48 PST 2009 root@pogo-1.f5test.net:/usr/obj/usr/src/sys/POGO WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc1045000. Preloaded acpi_dsdt "/boot/DSDT.aml" at 0xc10451ac. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3192016720 Hz CPU: Intel(R) Pentium(R) D CPU 3.20GHz (3192.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf44 Stepping = 4 Features=0xbfebfbff Features2=0x649d AMD Features=0x20100000 TSC: P-state invariant Cores per package: 2 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 16 KB, 8-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 1 MB, 8-way set associative, sectored cache, 64 byte line size L2 cache: 1024 kbytes, 8-way associative, 64 bytes/line real memory = 1072234496 (1022 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001425000 - 0x000000003ed4afff, 1033003008 bytes (252198 pages) avail memory = 1031671808 (983 MB) Table 'FACP' at 0x3fe9cda9 Table 'ASF!' at 0x3fe9ce1d Table 'SPCR' at 0x3fe9cee4 Table 'MCFG' at 0x3fe9cf34 Table 'APIC' at 0x3fe9cf70 MADT: Found table at 0x3fe9cf70 MP Configuration Table version 1.4 found at 0xc009fda1 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 bios32: Found BIOS32 Service Directory header at 0xc00f6080 bios32: Entry = 0xfd450 (c00fd450) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd450+0x1e3 pnpbios: Found PnP BIOS data at 0xc00f6110 pnpbios: Entry = f0000:a9fd Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP @ 0x0xf60d0/0x0014 (v 0 PTLTD ) ACPI: RSDT @ 0x0x3fe97360/0x0040 (v 1 PTLTD RSDT 0x06040000 LTP 0x00000000) ACPI: FACP @ 0x0x3fe9cda9/0x0074 (v 1 INTEL 0x06040000 PTL 0x00000003) ACPI: DSDT @ 0x0x3fe9775a/0x564F (v 1 INTEL GLENWOOD 0x06040000 MSFT 0x0100000E) ACPI: FACS @ 0x0x3fe9dfc0/0x0040 ACPI: ASF! @ 0x0x3fe9ce1d/0x00C7 (v 32 ISM CETP 0x06040000 PTL 0x00000001) ACPI: SPCR @ 0x0x3fe9cee4/0x0050 (v 1 PTLTD $UCRTBL$ 0x06040000 PTL 0x00000001) ACPI: MCFG @ 0x0x3fe9cf34/0x003C (v 1 PTLTD MCFG 0x06040000 LTP 0x00000000) ACPI: APIC @ 0x0x3fe9cf70/0x0068 (v 1 PTLTD APIC 0x06040000 LTP 0x00000000) ACPI: BOOT @ 0x0x3fe9cfd8/0x0028 (v 1 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) ACPI: SSDT @ 0x0x3fe973a0/0x03BA (v 1 PmRef CpuPm 0x00003000 INTL 0x20030224) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00000400 ath_rate: version 1.9 wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jan 5 2009 14:46:50) npx0: INT 16 interface acpi0: on motherboard ACPI: Table DSDT replaced by host OS ACPI: DSDT @ 0x0/0x5634 (v 1 INTEL GLENWOOD 0x06040000 INTL 0x20051021) PCIe: Memory Mapped configuration base @ 0xe0000000 pcibios: BIOS version 2.10 ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc41b0000 pa 0x1000 AcpiOsDerivePciId: \_SB_.PCI0.REGS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.MMTO -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.REGS -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.PIRX -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.PIRY -> bus 0 dev 31 func 0 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 12 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 10 11 14 15 Validation 0 11 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 10 11 14 15 Validation 0 10 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2778, revid=0x81 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2779, revid=0x81 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0100, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d0, revid=0x01 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27e0, revid=0x01 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27e2, revid=0x01 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27c8, revid=0x01 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0x3000, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x01 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x3020, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x01 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x3040, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x01 domain=0, bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=7 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x01 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8500000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xe1 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x01 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0x30a0, size 4, enabled found-> vendor=0x8086, dev=0x27c0, revid=0x01 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x30e8, size 3, enabled map[14]: type I/O Port, range 32, base 0x30dc, size 2, enabled map[18]: type I/O Port, range 32, base 0x30e0, size 3, enabled map[1c]: type I/O Port, range 32, base 0x30d8, size 2, enabled map[20]: type I/O Port, range 32, base 0x30b0, size 4, enabled map[24]: type Memory, range 32, base 0xd8500400, size 10, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27da, revid=0x01 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0101, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x1100, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: irq 16 at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 17 at device 28.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: irq 17 at device 28.4 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x4000-0x4fff pcib3: memory decode 0xd8000000-0xd80fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x8086, dev=0x108b, revid=0x03 domain=0, bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd8000000, size 17, enabled pcib3: requested memory range 0xd8000000-0xd801ffff: good map[18]: type I/O Port, range 32, base 0x4000, size 5, enabled pcib3: requested I/O range 0x4000-0x401f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 em0: port 0x4000-0x401f mem 0xd8000000-0xd801ffff irq 16 at device 0.0 on pci3 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8000000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 49 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:13:d3:fe:04:f2 pcib4: irq 16 at device 28.5 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x5000-0x5fff pcib4: memory decode 0xd8100000-0xd81fffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x8086, dev=0x108b, revid=0x00 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd8100000, size 17, enabled pcib4: requested memory range 0xd8100000-0xd811ffff: good map[18]: type I/O Port, range 32, base 0x5000, size 5, enabled pcib4: requested I/O range 0x5000-0x501f: in range pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 17 em1: port 0x5000-0x501f mem 0xd8100000-0xd811ffff irq 17 at device 0.0 on pci4 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8100000 em1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to vector 50 em1: using IRQ 257 for MSI em1: Using MSI interrupt em1: [FILTER] em1: bpf attached em1: Ethernet address: 00:13:d3:fe:04:f3 uhci0: port 0x3000-0x301f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3000 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 51 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3020-0x303f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3020 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 52 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3040 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 53 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3060 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 54 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd8500000-0xd85003ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8500000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib5: at device 30.0 on pci0 pcib5: domain 0 pcib5: secondary bus 10 pcib5: subordinate bus 10 pcib5: I/O decode 0x6000-0x6fff pcib5: memory decode 0xd8200000-0xd82fffff pcib5: prefetched decode 0xd0000000-0xd7ffffff pcib5: Subtractively decoded bridge. pci10: on pcib5 pci10: domain=0, physical bus=10 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30a0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=51 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 ata0: [MPSAFE] ata0: [ITHREAD] atapci1: port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xd8500400-0xd85007ff irq 19 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30b0 atapci1: [MPSAFE] atapci1: [ITHREAD] pci0: child atapci1 requested type 4 for rid 0x24, but the BAR says it is an memio ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x30e8 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x30dc ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat1=0x7f err=0xff lsb=0xff msb=0xff ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x30e0 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x30d8 ata3: reset tp1 mask=03 ostat0=50 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 uart0: [FILTER] uart0: fast interrupt uart0: console (115200,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ioapic0: routing intpin 3 (ISA IRQ 3) to vector 57 uart1: [FILTER] uart1: fast interrupt psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. cpu0: on acpi0 cpu0: switching to generic Cx mode est0: enabling SpeedStep est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 102d00000e23 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 102d00000e23 device_attach: est1 attach returned 6 p4tcc1: on cpu1 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcafff,0xdc000-0xdffff,0xe0000-0xe17ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata1 failed to probe at port 0x170 irq 15 on isa0 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sn0: not probed (disabled) uart2: not probed (disabled) uart3: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 99750516 hz Timecounter "TSC" frequency 3192016720 Hz quality -100 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached hptrr: no controller detected. ata0: identify ch->devices=00010000 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on ICH7 chip acd0: setting UDMA33 on ICH7 chip acd0: CDRW drive at ata0 as master acd0: 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata2: identify ch->devices=00000000 ata3: identify ch->devices=00000001 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 76319MB at ata3-master SATA150 ad6: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad6 ad6: Intel check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 3 to local APIC 1 ioapic0: Assigning ISA IRQ 4 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning PCI IRQ 16 to local APIC 1 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 1 ioapic0: Assigning PCI IRQ 23 to local APIC 0 msi: Assigning MSI IRQ 256 to local APIC 1 msi: Assigning MSI IRQ 257 to local APIC 0 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad6s1a Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ? List of GEOM managed disk devices: ad6b ad6a ad6 acd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:ad6a Trying to mount root from ufs:ad6a WARNING: / was not properly dismounted /: mount pending error: blocks 8 files 1 Lookup of /dev for devfs, error: 20 exec /sbin/init: error 20 exec /sbin/oinit: error 20 exec /sbin/init.bak: error 20 exec /rescue/init: error 20 exec /stand/sysinstall: error 20 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall panic: no init cpuid = 1 KDB: enter: panic [thread pid 1 tid 100002 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> If I boot back to the old kernel, here's what the slice layout looks like: # fdisk -v /dev/ad6 ******* Working on device /dev/ad6 ******* parameters extracted from in-core disklabel are: cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 156296322 (76316 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: and what bsdlabel thinks: # bsdlabel -A /dev/ad6 # /dev/ad6: type: ESDI disk: ad6s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 155061 sectors/unit: 156301488 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 152205312 0 4.2BSD 2048 16384 28552 b: 4096176 152205312 swap c: 156301488 0 unused 0 0 # "raw" part, don't edit -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 16:02:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2B25106566C for ; Tue, 6 Jan 2009 16:02:21 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 9BEBD8FC25 for ; Tue, 6 Jan 2009 16:02:21 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.21.160] (helo=beastie.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LKENX-000Mka-3n for freebsd-current@freebsd.org; Wed, 07 Jan 2009 00:02:03 +0800 Message-ID: <4963808A.20006@micom.mng.net> Date: Wed, 07 Jan 2009 00:02:18 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.19 (X11/20090104) MIME-Version: 1.0 To: "freebsd-current@freebsd.org" X-Enigmail-Version: 0.95.7 OpenPGP: id=78F6425E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: boot hangs with discrete graphics set in BIOS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 16:02:22 -0000 Hi, The laptop has 2 graphics, integrated G45 and ATI HD 3740. BIOS has 3 settings, integrated, discrete and switchable. CURRENT boots when BIOS is set to either integrated or switchable. But boot fails when BIOS is set to discrete (ATI graphics). I also tried hw.pci.mcfg=0 on loader.conf, but no success. Boot hangs right after hitting enter after the Boot Menu. Is there any known solution for this? dmesg is at: http://people.freebsd.org/~ganbold/dmesg_verbose.log thanks, Ganbold -- Be cautious in your daily affairs. From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 18:32:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33EEE106564A; Tue, 6 Jan 2009 18:32:57 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 926B68FC14; Tue, 6 Jan 2009 18:32:56 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so1507055nfh.33 for ; Tue, 06 Jan 2009 10:32:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=nzFHKjFSk43U854OqxMy1S9M+dJ98BYVxT6pXsdPV5M=; b=JnH75VwRCK8avdPaYuk5IJSAifggOQxQfHnPbodhcqjNGcoW9ujol5jUnPOy5L/7Jo OBDYEBY4WFTOFOVUZtBQL2p5gqXMKHperGNV2KzCP5W1i9Wve4RhPm02q9Vbhpjzyw9U PrC4oaXMPdJ5YZnr8IwkeF1KeNHuLYVDWOq1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=ZJii6lXxqfnZz3GwOClxJy5O+7u7vMFCsmCAk8G5RfsHX+uvUbDV5wDSsYmHoAvJhD yZoFllbufTVbnADLgHxK6y04fABvJD2cKGecwblfum9FWPWngQeh05AcJsh/yKki5I6G O9J5KeyvFtNvVGX8QgtTnn4PxUkZycnLCGxCk= Received: by 10.66.252.18 with SMTP id z18mr13458186ugh.30.1231266775060; Tue, 06 Jan 2009 10:32:55 -0800 (PST) Received: by 10.67.88.9 with HTTP; Tue, 6 Jan 2009 10:32:55 -0800 (PST) Message-ID: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> Date: Tue, 6 Jan 2009 10:32:55 -0800 From: "Garrett Cooper" To: "FreeBSD Current" , mav@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: snd_hda(4): getting line-in to work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 18:32:57 -0000 Hi CURRENT and Alexander, I'm not sure if it's user error or not, but my snd_hda(4) enabled chipset doesn't have line-in support enabled. I was wondering if there were a special set of instructions I need to follow to get this working. My /dev/sndstat says: [gcooper@orangebox /scratch/ltp]$ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) Installed devices: pcm0: at cad 0 nid 1 on hdac0 [MPSAFE] (1p:1v/1r:1v channels duplex default) pcm1: at cad 0 nid 1 on hdac0 [MPSAFE] (1p:1v/0r:0v channels) pcm2: at cad 0 nid 1 on hdac0 [MPSAFE] (1p:1v/0r:0v channels) [gcooper@orangebox /scratch/ltp]$ uname -a FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Sat Jan 3 22:54:52 PST 2009 gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX i386 [gcooper@orangebox /scratch/ltp]$ sysctl -a | grep snd hw.snd.latency_profile: 1 hw.snd.latency: 5 hw.snd.report_soft_formats: 1 hw.snd.compat_linux_mmap: 0 hw.snd.feeder_buffersize: 16384 hw.snd.feeder_rate_round: 25 hw.snd.feeder_rate_max: 2016000 hw.snd.feeder_rate_min: 1 hw.snd.verbose: 1 hw.snd.maxautovchans: 16 hw.snd.default_unit: 0 hw.snd.version: 2007061600/i386 hw.snd.default_auto: 0 pciconf(1) snippet: hdac0@pci0:0:27:0: class=0x040300 card=0x82771043 chip=0x293e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) HD Audio Controller' class = multimedia subclass = HDA Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 18:05:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C855C1065676 for ; Tue, 6 Jan 2009 18:05:16 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from web32702.mail.mud.yahoo.com (web32702.mail.mud.yahoo.com [68.142.207.246]) by mx1.freebsd.org (Postfix) with SMTP id 785048FC23 for ; Tue, 6 Jan 2009 18:05:16 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: (qmail 95255 invoked by uid 60001); 6 Jan 2009 17:38:36 -0000 X-YMail-OSG: lEFWqA8VM1lcqcvTYdAGhfOsIP6Q1JXPnWfhdfzeUDhrn5LvfBVTYkql.IJOnnDx_TTPy9RxZCpXiXH4Ofa83cqyb35l5BzlOlPXKf0zAZUBI9olERcVRFfFkCdDgqb4.T7n.wphN0S9VOlPH025_qd6VbO0XBzcOjCxfl8tqajkzZkR0U2avVJoyt_L Received: from [190.24.208.73] by web32702.mail.mud.yahoo.com via HTTP; Tue, 06 Jan 2009 09:38:35 PST X-RocketYMMF: giffunip X-Mailer: YahooMailWebService/0.7.260.1 Date: Tue, 6 Jan 2009 09:38:35 -0800 (PST) From: "Pedro F. Giffuni" To: Chagin Dmitry MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <25454.95171.qm@web32702.mail.mud.yahoo.com> X-Mailman-Approved-At: Tue, 06 Jan 2009 18:33:28 +0000 Cc: freebsd-current@freebsd.org Subject: Re: RFC: ELF branding. looking to a ".note.ABI-tag" section X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: giffunip@tutopia.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 18:05:17 -0000 Hi; As the author of kern/118473 I think that ELF notes for brand-ELFing is a useless non standard hack. I do understand that we want to teach our linuxulator about GNU ELF notes, but why would we want to use them for FreeBSD binaries? If you follow the posting on the lists by John Polstra and ELF spec you will find we don't need ELF notes. There is also a thread in some binutils list that made me conclude the reason they chose for not using the standard way was "NIH". Pedro. From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 18:41:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 938951065673 for ; Tue, 6 Jan 2009 18:41:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2E88FC1C for ; Tue, 6 Jan 2009 18:41:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LKGrL-0003Pi-Mi for freebsd-current@freebsd.org; Tue, 06 Jan 2009 18:40:59 +0000 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Jan 2009 18:40:59 +0000 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Jan 2009 18:40:59 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Tue, 06 Jan 2009 10:40:51 -0800 Lines: 55 Message-ID: References: <4962A0D3.1010704@mail.zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.10.9 Sender: news Subject: Re: FreeBSD 8: fails booting from slice ad8s1a X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 18:41:05 -0000 Replying to myself, solution below: Mark Atkinson wrote: > Trying to mount root from ufs:/dev/ad6s1a > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices > Abort manual input > > mountroot> ? > > List of GEOM managed disk devices: > ad6b ad6a ad6 acd0 > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices > Abort manual input > > mountroot> ufs:ad6a > Trying to mount root from ufs:ad6a > WARNING: / was not properly dismounted > /: mount pending error: blocks 8 files 1 > Lookup of /dev for devfs, error: 20 > exec /sbin/init: error 20 > exec /sbin/oinit: error 20 > exec /sbin/init.bak: error 20 > exec /rescue/init: error 20 > exec /stand/sysinstall: error 20 > init: not found in > path /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall > panic: no init > cpuid = 1 > KDB: enter: panic > [thread pid 1 tid 100002 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> This is the 'stale label' problem described here: http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001750.html with the solution here: http://lists.freebsd.org/pipermail/freebsd-current/2009-January/001892.html After erasing the 'non-slice' label on the disk, I'm able to mount root. -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 19:59:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7775D106566B for ; Tue, 6 Jan 2009 19:59:12 +0000 (UTC) (envelope-from root@dchagin.dialup.corbina.ru) Received: from contrabass.post.ru (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA738FC1E for ; Tue, 6 Jan 2009 19:59:11 +0000 (UTC) (envelope-from root@dchagin.dialup.corbina.ru) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.post.ru (Postfix) with ESMTP id 6D0C63E7D6; Tue, 6 Jan 2009 22:59:09 +0300 (MSK) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from dchagin.dialup.corbina.ru ([78.107.232.239] verified) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 1554964813; Tue, 06 Jan 2009 22:59:09 +0300 Received: from dchagin.dialup.corbina.ru (localhost.chd.net [127.0.0.1]) by dchagin.dialup.corbina.ru (8.14.3/8.14.3) with ESMTP id n06Jx8pQ051857; Tue, 6 Jan 2009 22:59:09 +0300 (MSK) (envelope-from root@dchagin.dialup.corbina.ru) Received: (from root@localhost) by dchagin.dialup.corbina.ru (8.14.3/8.14.3/Submit) id n06Jx3wo051856; Tue, 6 Jan 2009 22:59:03 +0300 (MSK) (envelope-from root) Date: Tue, 6 Jan 2009 22:59:03 +0300 From: Chagin Dmitry To: "Pedro F. Giffuni" Message-ID: <20090106195903.GA51780@dchagin.dialup.corbina.ru> References: <25454.95171.qm@web32702.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25454.95171.qm@web32702.mail.mud.yahoo.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: RFC: ELF branding. looking to a ".note.ABI-tag" section X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 19:59:12 -0000 On Tue, Jan 06, 2009 at 09:38:35AM -0800, Pedro F. Giffuni wrote: > Hi; > > As the author of kern/118473 I think that ELF notes for brand-ELFing is a useless non standard hack. I do understand that we want to teach our linuxulator about GNU ELF notes, but why would we want to use them for FreeBSD binaries? > > If you follow the posting on the lists by John Polstra and ELF spec you will find we don't need ELF notes. There is also a thread in some binutils list that made me conclude the reason they chose for not using the standard way was "NIH". > > Pedro. > Hi, I don't think so. We already use this for native binaries. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/imgact_elf.c.diff?r1=1.181;r2=1.182 -- Have fun! chd From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 20:53:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48ED610656BA for ; Tue, 6 Jan 2009 20:53:17 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id C04B38FC19 for ; Tue, 6 Jan 2009 20:53:16 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 231132786; Tue, 06 Jan 2009 22:53:15 +0200 Message-ID: <4963C4C0.6000509@FreeBSD.org> Date: Tue, 06 Jan 2009 22:53:20 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> In-Reply-To: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: snd_hda(4): getting line-in to work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 20:53:18 -0000 Garrett Cooper wrote: > I'm not sure if it's user error or not, but my snd_hda(4) enabled > chipset doesn't have line-in support enabled. I was wondering if there > were a special set of instructions I need to follow to get this > working. The main instruction is to boot system with verbose messages. snd_hda writes all information needed to answer most questions. Read it yourself and if it does not help - send it to me. > [gcooper@orangebox /scratch/ltp]$ cat /dev/sndstat > FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) > Installed devices: > pcm0: at cad 0 nid 1 on > hdac0 [MPSAFE] (1p:1v/1r:1v channels duplex default) All I can see here is that you have some recording device. You can browse and select specific recording source with `mixer =rec` command. For additional details look verbose output and read new snd_hda man page. > pcm1: at cad 0 nid 1 on > hdac0 [MPSAFE] (1p:1v/0r:0v channels) > pcm2: at cad 0 nid 1 on > hdac0 [MPSAFE] (1p:1v/0r:0v channels) -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 21:04:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C42631065670 for ; Tue, 6 Jan 2009 21:04:16 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBAE8FC13 for ; Tue, 6 Jan 2009 21:04:16 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2603754fgb.35 for ; Tue, 06 Jan 2009 13:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/arMew5eOxPhJvE5m0ASVazVbX9HW46Xwk8OslrrnTA=; b=oMFEKit7AnvbEWoWIh730S3Qxgr6dxBGrK6hbscyjV3JcSO4l3LL0ATDuYg7roLor2 24lzytMiF2F8eBHCxhLhkUiAqT/20nzuJLHqqU7+lIkRLMYTUqpzMcYCWsGVs9F5mat/ CI65SUC5bqkRtilOYDp5E2qw9HEaVm/MVNXmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=PH7BpHTKxwHkS1ne2SAkrQhPIeuVSwf20jzGemCc3LrwBl26wHutfvsZkD1tyhfZIT uXqn0xxl4FxzxMYeWhsZKUfXkWD5Elfmz2/ApCHVBy1ERraBedl0seWcKXTxIP2y9Tqj SmFchcX41Ld/96us6Cf5oNiDce8yGV4qyfrFM= Received: by 10.86.63.19 with SMTP id l19mr13035942fga.40.1231274098249; Tue, 06 Jan 2009 12:34:58 -0800 (PST) Received: by 10.86.31.11 with HTTP; Tue, 6 Jan 2009 12:34:58 -0800 (PST) Message-ID: <9e20d71e0901061234n2b6a526ap3290abdca4ef7527@mail.gmail.com> Date: Tue, 6 Jan 2009 22:34:58 +0200 From: "Artis Caune" To: "Stefan Bethke" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: FreeBSD Current Subject: Re: Labeling disks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 21:04:17 -0000 2008/12/5 Stefan Bethke : > - Using glabel to label the disks, and then fdisk/bsdlabel partioning them, > works nicely. As soon as I put a gmirror on the label/disk?s1a partitions, > *all* labels disappear. Huh? I can understand removing the labels for the > partitions that are now the providers used by the gmirror, but why to the > other get removed? Also, it seems that gmirror references the actual disks > (see gmirror output below) instead of the labels. I was under the impression > that glabel would consume a provider and provide it minus the last sector, > so /dev/label/foo and /dev/ad22 are not the same device (but do overlap). Have you tried to label gmirror with -h flag? -- regards, Artis Caune <----. CCNA | BSDA <----|==================== <----' didii FreeBSD From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 20:48:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0099106566B for ; Tue, 6 Jan 2009 20:48:20 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from tutopia.com (mail06mass.ifxnetworks.com [190.60.24.76]) by mx1.freebsd.org (Postfix) with ESMTP id 31FFB8FC1B for ; Tue, 6 Jan 2009 20:48:19 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: (qmail 7066 invoked from network); 6 Jan 2009 20:21:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail06mass.ifxnetworks.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=7.0 tests=MISSING_MID,RDNS_NONE autolearn=disabled version=3.2.5 Received: from unknown (HELO mail13.ifxnetworks.com) ([190.61.128.23]) (envelope-sender ) by mail06mass.ifxnetworks.com (qmail-ldap-1.03) with SMTP for ; 6 Jan 2009 20:21:32 -0000 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 From: To: 'Pedro F . Giffuni' , Chagin Dmitry X-Origin: 190.60.24.4 Date: Tue, 06 Jan 2009 20:21:32 +0000 X-Uidl: 20090106195903.GA51780@dchagin.dialup.corbina.ru X-Mailer: AtMail 4.11 Message-Id: <20090106204820.31FFB8FC1B@mx1.freebsd.org> X-Mailman-Approved-At: Tue, 06 Jan 2009 21:11:07 +0000 Cc: freebsd-current@freebsd.org Subject: Re: RFC: ELF branding. looking to a '.note.ABI-tag' section X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: giffunip@tutopia.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 20:48:20 -0000 =0D =0D On Mar Ene 6 14:59 , Chagin Dmitry sent:=0D =0D >On Tue, Jan 06, 2009 at 09:38:35AM -0800, Pedro F. Giffuni wrote:=0D >> Hi;=0D >> =0D >> As the author of kern/118473 I think that ELF notes for brand-ELFing is = a =0D useless non standard hack. I do understand that we want to teach our linuxu= lator =0D about GNU ELF notes, but why would we want to use them for FreeBSD binaries= ?=0D >> =0D >> If you follow the posting on the lists by John Polstra and ELF spec you = will =0D find we don't need ELF notes. There is also a thread in some binutils list = that =0D made me conclude the reason they chose for not using the standard way was "= NIH".=0D >> =0D >> Pedro.=0D >> =0D >=0D >Hi, I don't think so. We already use this for native binaries.=0D >=0D >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/imgact_elf.c.diff\?=0D r1=3D1.181;r2=3D1.182=0D >=0D =0D Aha .. The ELF standard doesn't include the OS_version so using notes for t= hat =0D makes sense, however for the ABI the standard has always been EI_ABI field.= =0D =0D http://www.sco.com/developers/gabi/latest/ch4.eheader.html#osabi=0D =0D Please check this interesting link:=0D =0D http://people.freebsd.org/~obrien/ei_osabi-binutils.mbox=0D =0D Pedro.=0D =0D =0D From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 01:25:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86DB91065677 for ; Wed, 7 Jan 2009 01:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA598FC18 for ; Wed, 7 Jan 2009 01:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 8A98241C613; Wed, 7 Jan 2009 02:25:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id JJpXpByURCnp; Wed, 7 Jan 2009 02:25:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 226D241C5DC; Wed, 7 Jan 2009 02:25:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 018904448DD; Wed, 7 Jan 2009 01:22:39 +0000 (UTC) Date: Wed, 7 Jan 2009 01:22:39 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andrzej Tobola In-Reply-To: <20081216053058.GA37217@amp2.iem.pw.edu.pl> Message-ID: <20090107012048.K45399@maildrop.int.zabbadoz.net> References: <20081215220539.W97918@maildrop.int.zabbadoz.net> <20081216053058.GA37217@amp2.iem.pw.edu.pl> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: need conf/kern.post.mk review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 01:25:07 -0000 On Tue, 16 Dec 2008, Andrzej Tobola wrote: Hi, > If we are already on kern.port.mk what about the following patch > which gives the posibility to instal to fs without chflags (e.g. nfs) ? > I am using it from a long time as can be seen from time-stamps. > > --- /usr/src/sys/conf/kern.post.mk-OLD 2007-03-24 06:35:08.000000000 +0100 > +++ /usr/src/sys/conf/kern.post.mk 2007-11-24 23:52:03.000000000 +0100 > @@ -14,6 +14,12 @@ > .endif > MKMODULESENV+= KERNBUILDDIR="${.CURDIR}" > > +.if defined(NO_FSCHG) > +CHFLAGS= echo > +.else > +CHFLAGS= chflags -R noschg > +.endif > + > .MAIN: all > > .for target in all clean cleandepend cleandir clobber depend install \ > @@ -208,11 +214,11 @@ > .if exists(${DESTDIR}${KODIR}) > -thiskernel=`sysctl -n kern.bootfile` ; \ > if [ ! "`dirname "$$thiskernel"`" -ef ${DESTDIR}${KODIR} ] ; then \ > - chflags -R noschg ${DESTDIR}${KODIR} ; \ > + ${CHFLAGS} ${DESTDIR}${KODIR} ; \ > rm -rf ${DESTDIR}${KODIR} ; \ > else \ > if [ -d ${DESTDIR}${KODIR}.old ] ; then \ > - chflags -R noschg ${DESTDIR}${KODIR}.old ; \ > + ${CHFLAGS} ${DESTDIR}${KODIR}.old ; \ > rm -rf ${DESTDIR}${KODIR}.old ; \ > fi ; \ > mv ${DESTDIR}${KODIR} ${DESTDIR}${KODIR}.old ; \ > @@ -231,7 +237,7 @@ > > > kernel-reinstall: > - @-chflags -R noschg ${DESTDIR}${KODIR} > + @-${CHFLAGS} ${DESTDIR}${KODIR} > ${INSTALL} -p -m 555 -o root -g wheel ${KERNEL_KO} ${DESTDIR}${KODIR} > .if defined(DEBUG) && !defined(INSTALL_NODEBUG) > ${INSTALL} -p -m 555 -o root -g wheel ${KERNEL_KO}.symbols ${DESTDIR}${KODIR} I cannot see why you would need any of those changes. All three places do not care if they fail. the shell commands are using ; so the next command is just executed and kernel-reinstall has a - which means that a non-zero exist status is ignored. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 01:42:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5ED76106564A for ; Wed, 7 Jan 2009 01:42:44 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id E6C3F8FC0C for ; Wed, 7 Jan 2009 01:42:43 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.37,222,1231110000"; d="scan'208";a="266383905" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 07 Jan 2009 02:42:42 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 9473C1B075D; Wed, 7 Jan 2009 02:42:42 +0100 (CET) Date: Wed, 07 Jan 2009 02:42:42 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Problem with usbconfig and powerstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 01:42:44 -0000 hi there, i'm having a bit of a problem with usbconfig. the problem first occured a few days ago. when i try to disable a usb device with power_off the power state changes to SAVE and not OFF. if i try to enable the usb device with power_on it won't work although usbconfig tells me the power state is ON. the only way to get the usb device working again is to unlpug it and plug it in again. last week i could switch the power state from off to on and vice versa without any problems. cheers. alex From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 00:58:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C17691065672 for ; Wed, 7 Jan 2009 00:58:20 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from web32704.mail.mud.yahoo.com (web32704.mail.mud.yahoo.com [68.142.207.248]) by mx1.freebsd.org (Postfix) with SMTP id 7120C8FC17 for ; Wed, 7 Jan 2009 00:58:20 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: (qmail 54121 invoked by uid 60001); 7 Jan 2009 00:58:19 -0000 X-YMail-OSG: 0vugQ70VM1m7thN4_HgS6C9AoZ1hhUlRO_j9w2wrHDnOpPIcRsV46ExpxPh8lV3W_2U63N.lTT9mM.qgdd3Y0DWcfqOapNFMjQLJyNOiQVUBLGplZCXMBksWaaZ8BL57E7760DFFBYvgxeJRC2vFEoqB2nrz4j.qjzfcJDkUTHUaBCLfoULU9H26ImnV Received: from [190.157.124.207] by web32704.mail.mud.yahoo.com via HTTP; Tue, 06 Jan 2009 16:58:19 PST X-RocketYMMF: giffunip X-Mailer: YahooMailWebService/0.7.260.1 Date: Tue, 6 Jan 2009 16:58:19 -0800 (PST) From: "Pedro F. Giffuni" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <735174.53499.qm@web32704.mail.mud.yahoo.com> X-Mailman-Approved-At: Wed, 07 Jan 2009 02:19:35 +0000 Subject: Re: RFC: ELF branding. looking to a ".note.ABI-tag" section X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: giffunip@tutopia.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 00:58:21 -0000 On Tue, Jan 06, 2009 at 09:38:35AM -0800, Pedro F. Giffuni wrote: > Hi; > > As the author of kern/118473 I think that ELF notes for brand-ELFing is a > useless non standard hack. I do understand that we want to teach our > linuxulator about GNU ELF notes, but why would we want to use them for > FreeBSD binaries? > Bah .. replying to myself after reviewing the end of the patch, this is the right approach since we still use the standard FreeBSD branding by default. Nevermind. Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 04:29:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56B6E106566C; Wed, 7 Jan 2009 04:29:54 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 307A08FC18; Wed, 7 Jan 2009 04:29:52 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so1377772ugs.39 for ; Tue, 06 Jan 2009 20:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=va4UeLttDwlva5zuFfehvXCo8nnArDX/v6OlfQGZmdU=; b=iHBQQXFG7xVAmtYJsOKRIo38ZkYclKz7ZKQGTPcsw43Y6AveZ1BzqwyYHYbo9cSPy+ r4FlnmWIXpPtxbqGLfTARu/bexZHICG/bHYGZ6yvZMmMD0UseqOUKQqIFN/oGEP51vEx Fm2P+yZr/R0vQNCx1X2mNTpNggaoZDYTRPkfs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=dhvGiozqNhC9mQIzVTIoOFE2t+paf37IhM2rG57J+16Gnv3/EQSsIdAtQow5GaUa2b H2M8ktEan74Zu9HFjX/xSPbUUwnyqG1cvIpCWQk+xBQcpHZMZR4rnw0uTbMI+KJdHQ0P 1vQnOU4dDJx8u4eDfzX3tlHjB6cupCoy9Ujv0= Received: by 10.67.40.15 with SMTP id s15mr13669524ugj.89.1231302591775; Tue, 06 Jan 2009 20:29:51 -0800 (PST) Received: by 10.67.88.9 with HTTP; Tue, 6 Jan 2009 20:29:51 -0800 (PST) Message-ID: <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> Date: Tue, 6 Jan 2009 20:29:51 -0800 From: "Garrett Cooper" To: "Alexander Motin" In-Reply-To: <4963C4C0.6000509@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6752_21875099.1231302591757" References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> Cc: FreeBSD Current Subject: Re: snd_hda(4): getting line-in to work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 04:29:54 -0000 ------=_Part_6752_21875099.1231302591757 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, Jan 6, 2009 at 12:53 PM, Alexander Motin wrote: > Garrett Cooper wrote: >> >> I'm not sure if it's user error or not, but my snd_hda(4) enabled >> chipset doesn't have line-in support enabled. I was wondering if there >> were a special set of instructions I need to follow to get this >> working. > > The main instruction is to boot system with verbose messages. snd_hda writes > all information needed to answer most questions. Read it yourself and if it > does not help - send it to me. > >> [gcooper@orangebox /scratch/ltp]$ cat /dev/sndstat >> FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) >> Installed devices: >> pcm0: at cad 0 nid 1 on >> hdac0 [MPSAFE] (1p:1v/1r:1v channels duplex default) > > All I can see here is that you have some recording device. You can browse > and select specific recording source with `mixer =rec` command. For > additional details look verbose output and read new snd_hda man page. > >> pcm1: at cad 0 nid 1 on >> hdac0 [MPSAFE] (1p:1v/0r:0v channels) >> pcm2: at cad 0 nid 1 on >> hdac0 [MPSAFE] (1p:1v/0r:0v channels) > > -- > Alexander Motin Trying with the instructions on the manpage actually disabled my sound... then again I probably screwed up the settings (I believe it was noted as pcm2 before??). Here're the device.hints entries and I attached the -v boot log snippet for the card: hint.hdac.0.cad0.nid17.config="as=1seq=0 device=Headphones" hint.hdac.0.cad0.nid18.config="as=2seq=0 device=Line-out" hint.hdac.0.cad0.nid19.config="as=3seq=0 device=Speaker" hint.hdac.0.cad0.nid20.config="as=4seq=0 device=Mic" hint.hdac.0.cad0.nid21.config="as=5seq=0 device=Line-in" hint.hdac.0.cad0.nid22.config="as=6seq=0 device=Line-out" hint.hdac.0.cad0.nid23.config="as=6seq=0 device=Mic" hint.hdac.0.cad0.nid24.config="as=6seq=0 device=CD" hint.hdac.0.cad0.nid36.config="as=5seq=0 device=Line-out" hint.hdac.0.cad0.nid37.config="as=6seq=0 device=Line-out" Thanks! -Garrett ------=_Part_6752_21875099.1231302591757 Content-Type: application/octet-stream; name=hdac.log Content-Transfer-Encoding: base64 X-Attachment-Id: f_fpnhr8h30 Content-Disposition: attachment; filename=hdac.log aGRhYzA6IDxJbnRlbCA4MjgwMUkgSGlnaCBEZWZpbml0aW9uIEF1ZGlvIENvbnRyb2xsZXI+IG1l bSAweGYzZmY4MDAwLTB4ZjNmZmJmZmYgaXJxIDIyIGF0IGRldmljZSAyNy4wIG9uIHBjaTAKaGRh YzA6IEhEQSBEcml2ZXIgUmV2aXNpb246IDIwMDgxMjI2XzAxMjIKaGRhYzA6IFJlc2VydmVkIDB4 NDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZjNmZjgwMDAKaGRhYzA6IFtNUFNB RkVdCmhkYWMwOiBbSVRIUkVBRF0KaGRhYzA6IFByb2JpbmcgY29kZWMgIzAuLi4KaGRhYzA6IEhE QSBDb2RlYyAjMDogQW5hbG9nIERldmljZXMgQUQxOTg4QgpoZGFjMDogIEhEQSBDb2RlYyBJRDog MHgxMWQ0MTk4YgpoZGFjMDogICAgICAgIFZlbmRvcjogMHgxMWQ0CmhkYWMwOiAgICAgICAgRGV2 aWNlOiAweDE5OGIKaGRhYzA6ICAgICAgUmV2aXNpb246IDB4MDQKaGRhYzA6ICAgICAgU3RlcHBp bmc6IDB4MDAKaGRhYzA6IFBDSSBTdWJ2ZW5kb3I6IDB4ODI3NzEwNDMKaGRhYzA6IAlGb3VuZCBh dWRpbyBGRyBuaWQ9MSBzdGFydG5vZGU9MiBlbmRub2RlPTYyIHRvdGFsPTYwCmhkYWMwOiAKaGRh YzA6IFByb2Nlc3NpbmcgYXVkaW8gRkcgY2FkPTAgbmlkPTEuLi4KaGRhYzA6IEdQSU86IDB4NDAw MDAwMDIgTnVtR1BJTz0yIE51bUdQTz0wIE51bUdQST0wIEdQSVdha2U9MCBHUElVbnNvbD0xCmhk YWMwOiAgbmlkIDE3IDB4MDIyMTQwMzAgYXMgIDMgc2VxICAwICAgIEhlYWRwaG9uZXMgIEphY2sg amFjayAgMSBsb2MgIDIgY29sb3IgICBHcmVlbiBtaXNjIDAKaGRhYzA6ICBuaWQgMTggMHgwMTAx NDAxMCBhcyAgMSBzZXEgIDAgICAgICBMaW5lLW91dCAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xv ciAgIEdyZWVuIG1pc2MgMApoZGFjMDogIG5pZCAxOSAweDUxMTcxMWYwIGFzIDE1IHNlcSAgMCAg ICAgICBTcGVha2VyICBOb25lIGphY2sgIDcgbG9jIDE3IGNvbG9yICAgQmxhY2sgbWlzYyAxCmhk YWMwOiAgbmlkIDIwIDB4MDJhMTkwMmUgYXMgIDIgc2VxIDE0ICAgICAgICAgICBNaWMgIEphY2sg amFjayAgMSBsb2MgIDIgY29sb3IgICAgUGluayBtaXNjIDAKaGRhYzA6ICBuaWQgMjEgMHgwMTgx MzAyMSBhcyAgMiBzZXEgIDEgICAgICAgTGluZS1pbiAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xv ciAgICBCbHVlIG1pc2MgMApoZGFjMDogIG5pZCAyMiAweDAxMDExMDEyIGFzICAxIHNlcSAgMiAg ICAgIExpbmUtb3V0ICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgQmxhY2sgbWlzYyAwCmhk YWMwOiAgbmlkIDIzIDB4MDFhMTkwMjAgYXMgIDIgc2VxICAwICAgICAgICAgICBNaWMgIEphY2sg amFjayAgMSBsb2MgIDEgY29sb3IgICAgUGluayBtaXNjIDAKaGRhYzA6ICBuaWQgMjQgMHg5OTMz MTEyMiBhcyAgMiBzZXEgIDIgICAgICAgICAgICBDRCBGaXhlZCBqYWNrICAzIGxvYyAyNSBjb2xv ciAgIEJsYWNrIG1pc2MgMQpoZGFjMDogUGF0Y2hpbmcgd2lkZ2V0IGNhcHMgbmlkPTI2IDB4MDA0 MDAwMDAgLT4gMHgwMDcwMDAwMApoZGFjMDogIG5pZCAyNyAweDAxNDVmMWYwIGFzIDE1IHNlcSAg MCAgICAgU1BESUYtb3V0ICBKYWNrIGphY2sgIDUgbG9jICAxIGNvbG9yICAgT3RoZXIgbWlzYyAx CmhkYWMwOiAgbmlkIDI4IDB4NDFjNWYxZjAgYXMgMTUgc2VxICAwICAgICAgU1BESUYtaW4gIE5v bmUgamFjayAgNSBsb2MgIDEgY29sb3IgICBPdGhlciBtaXNjIDEKaGRhYzA6IEdIT1NUOiBuaWQ9 Mjkgaj0wIGVudG51bT00IGluZGV4PTAgcmVzPTB4MDAwMDBiMDEKaGRhYzA6ICBuaWQgMzYgMHgw MTAxNjAxMSBhcyAgMSBzZXEgIDEgICAgICBMaW5lLW91dCAgSmFjayBqYWNrICAxIGxvYyAgMSBj b2xvciAgT3JhbmdlIG1pc2MgMApoZGFjMDogIG5pZCAzNyAweDAxMDEyMDE0IGFzICAxIHNlcSAg NCAgICAgIExpbmUtb3V0ICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgIEdyZXkgbWlzYyAw CmhkYWMwOiBQYXRjaGVkIHBpbnMgY29uZmlndXJhdGlvbjoKaGRhYzA6ICBuaWQgMTcgMHgwMjIx NDAzMCBhcyAgMyBzZXEgIDAgICAgSGVhZHBob25lcyAgSmFjayBqYWNrICAxIGxvYyAgMiBjb2xv ciAgIEdyZWVuIG1pc2MgMApoZGFjMDogIG5pZCAxOCAweDAxMDE0MDEwIGFzICAxIHNlcSAgMCAg ICAgIExpbmUtb3V0ICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgR3JlZW4gbWlzYyAwCmhk YWMwOiAgbmlkIDE5IDB4NTExNzExZjAgYXMgMTUgc2VxICAwICAgICAgIFNwZWFrZXIgIE5vbmUg amFjayAgNyBsb2MgMTcgY29sb3IgICBCbGFjayBtaXNjIDEgW0RJU0FCTEVEXQpoZGFjMDogIG5p ZCAyMCAweDAyYTE5MDJlIGFzICAyIHNlcSAxNCAgICAgICAgICAgTWljICBKYWNrIGphY2sgIDEg bG9jICAyIGNvbG9yICAgIFBpbmsgbWlzYyAwCmhkYWMwOiAgbmlkIDIxIDB4MDE4MTMwMjEgYXMg IDIgc2VxICAxICAgICAgIExpbmUtaW4gIEphY2sgamFjayAgMSBsb2MgIDEgY29sb3IgICAgQmx1 ZSBtaXNjIDAKaGRhYzA6ICBuaWQgMjIgMHgwMTAxMTAxMiBhcyAgMSBzZXEgIDIgICAgICBMaW5l LW91dCAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xvciAgIEJsYWNrIG1pc2MgMApoZGFjMDogIG5p ZCAyMyAweDAxYTE5MDIwIGFzICAyIHNlcSAgMCAgICAgICAgICAgTWljICBKYWNrIGphY2sgIDEg bG9jICAxIGNvbG9yICAgIFBpbmsgbWlzYyAwCmhkYWMwOiAgbmlkIDI0IDB4OTkzMzExMjIgYXMg IDIgc2VxICAyICAgICAgICAgICAgQ0QgRml4ZWQgamFjayAgMyBsb2MgMjUgY29sb3IgICBCbGFj ayBtaXNjIDEKaGRhYzA6ICBuaWQgMjcgMHgwMTQ1ZjFmMCBhcyAxNSBzZXEgIDAgICAgIFNQRElG LW91dCAgSmFjayBqYWNrICA1IGxvYyAgMSBjb2xvciAgIE90aGVyIG1pc2MgMQpoZGFjMDogIG5p ZCAyOCAweDQxYzVmMWYwIGFzIDE1IHNlcSAgMCAgICAgIFNQRElGLWluICBOb25lIGphY2sgIDUg bG9jICAxIGNvbG9yICAgT3RoZXIgbWlzYyAxIFtESVNBQkxFRF0KaGRhYzA6ICBuaWQgMzYgMHgw MTAxNjAxMSBhcyAgMSBzZXEgIDEgICAgICBMaW5lLW91dCAgSmFjayBqYWNrICAxIGxvYyAgMSBj b2xvciAgT3JhbmdlIG1pc2MgMApoZGFjMDogIG5pZCAzNyAweDAxMDEyMDE0IGFzICAxIHNlcSAg NCAgICAgIExpbmUtb3V0ICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgIEdyZXkgbWlzYyAw CmhkYWMwOiA0IGFzc29jaWF0aW9ucyBmb3VuZDoKaGRhYzA6IEFzc29jaWF0aW9uIDAgKDEpIG91 dDoKaGRhYzA6ICBQaW4gbmlkPTE4IHNlcT0wCmhkYWMwOiAgUGluIG5pZD0zNiBzZXE9MQpoZGFj MDogIFBpbiBuaWQ9MjIgc2VxPTIKaGRhYzA6ICBQaW4gbmlkPTM3IHNlcT00CmhkYWMwOiBBc3Nv Y2lhdGlvbiAxICgyKSBpbjoKaGRhYzA6ICBQaW4gbmlkPTIzIHNlcT0wCmhkYWMwOiAgUGluIG5p ZD0yMSBzZXE9MQpoZGFjMDogIFBpbiBuaWQ9MjQgc2VxPTIKaGRhYzA6ICBQaW4gbmlkPTIwIHNl cT0xNApoZGFjMDogQXNzb2NpYXRpb24gMiAoMykgb3V0OgpoZGFjMDogIFBpbiBuaWQ9MTcgc2Vx PTAKaGRhYzA6IEFzc29jaWF0aW9uIDMgKDE1KSBvdXQ6CmhkYWMwOiAgUGluIG5pZD0yNyBzZXE9 MApoZGFjMDogVHJhY2luZyBhc3NvY2lhdGlvbiAwICgxKQpoZGFjMDogIFBpbiAxOCB0cmFjZWQg dG8gREFDIDQKaGRhYzA6ICBQaW4gMzYgdHJhY2VkIHRvIERBQyA1CmhkYWMwOiAgUGluIDIyIHRy YWNlZCB0byBEQUMgNgpoZGFjMDogIFBpbiAzNyB0cmFjZWQgdG8gREFDIDEwCmhkYWMwOiBBc3Nv Y2lhdGlvbiAwICgxKSB0cmFjZSBzdWNjZWRlZApoZGFjMDogVHJhY2luZyBhc3NvY2lhdGlvbiAx ICgyKQpoZGFjMDogIFVuYWJsZSB0byB0cmFjZSBwaW4gMjMgdG8gQURDIDcsIHVuZG8gdHJhY2Vz CmhkYWMwOiAgUGluIDIzIHRyYWNlZCB0byBBREMgOApoZGFjMDogIFBpbiAyMSB0cmFjZWQgdG8g QURDIDgKaGRhYzA6ICBQaW4gMjQgdHJhY2VkIHRvIEFEQyA4CmhkYWMwOiAgUGluIDIwIHRyYWNl ZCB0byBBREMgOApoZGFjMDogQXNzb2NpYXRpb24gMSAoMikgdHJhY2Ugc3VjY2VkZWQKaGRhYzA6 IFRyYWNpbmcgYXNzb2NpYXRpb24gMiAoMykKaGRhYzA6ICBQaW4gMTcgdHJhY2VkIHRvIERBQyAz CmhkYWMwOiBBc3NvY2lhdGlvbiAyICgzKSB0cmFjZSBzdWNjZWRlZApoZGFjMDogVHJhY2luZyBh c3NvY2lhdGlvbiAzICgxNSkKaGRhYzA6ICBQaW4gMjcgdHJhY2VkIHRvIERBQyAyCmhkYWMwOiBB c3NvY2lhdGlvbiAzICgxNSkgdHJhY2Ugc3VjY2VkZWQKaGRhYzA6IFRyYWNpbmcgaW5wdXQgbW9u aXRvcgpoZGFjMDogIFRyYWNpbmcgbmlkIDMyIHRvIG91dApoZGFjMDogIG5pZCAzMiBpcyBpbnB1 dCBtb25pdG9yCmhkYWMwOiBUcmFjaW5nIGJlZXBlcgpoZGFjMDogIG5pZCAyNiB0cmFjZWQgdG8g b3V0CmhkYWMwOiBGRyBjb25maWcvcXVpcmtzOiBmb3JjZXN0ZXJlbyBpdnJlZjgwCmhkYWMwOiAK aGRhYzA6ICstLS0tLS0tLS0tLS0tLS0tLS0tKwpoZGFjMDogfCBEVU1QSU5HIEhEQSBOT0RFUyB8 CmhkYWMwOiArLS0tLS0tLS0tLS0tLS0tLS0tLSsKaGRhYzA6IApoZGFjMDogRGVmYXVsdCBQYXJh bWV0ZXIKaGRhYzA6IC0tLS0tLS0tLS0tLS0tLS0tCmhkYWMwOiAgICAgIFN0cmVhbSBjYXA6IDB4 MDAwMDAwMDEKaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCmhkYWMwOiAgICAgICAgIFBDTSBj YXA6IDB4MDAwZTA3ZmYKaGRhYzA6ICAgICAgICAgICAgICAgICAgMTYgMjAgMjQgYml0cywgOCAx MSAxNiAyMiAzMiA0NCA0OCA4OCA5NiAxNzYgMTkyIEtIegpoZGFjMDogICAgICAgICAgSU4gYW1w OiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAgIE9VVCBhbXA6IDB4MDAwNTI3MjcKaGRhYzA6IApo ZGFjMDogICAgICAgICAgICAgbmlkOiAyCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG91 dHB1dApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMDMwMzExCmhkYWMwOiAgICAgICAgICAg ICAgICAgIERJR0lUQUwgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDMgKDB4MDAwMDAw MDEpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSAocGNtKQpoZGFjMDogICAgICBTdHJlYW0g Y2FwOiAweDAwMDAwMDA1CmhkYWMwOiAgICAgICAgICAgICAgICAgIEFDMyBQQ00KaGRhYzA6ICAg ICAgICAgUENNIGNhcDogMHgwMDBlMDdlMApoZGFjMDogICAgICAgICAgICAgICAgICAxNiAyMCAy NCBiaXRzLCA0NCA0OCA4OCA5NiAxNzYgMTkyIEtIegpoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAx CmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9 MjkgW2F1ZGlvIG1peGVyXSBbRElTQUJMRURdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5p ZDogMwpoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKaGRhYzA6ICAgICAgV2lk Z2V0IGNhcDogMHgwMDAwMDQwNQpoZGFjMDogICAgICAgICAgICAgICAgICBQV1IgU1RFUkVPCmhk YWMwOiAgICAgQXNzb2NpYXRpb246IDIgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAgICAgICAgICBP U1M6IHBjbSAocGNtKQpoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCmhkYWMwOiAg ICAgICAgICAgICAgICAgIFBDTQpoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwN2ZmCmhk YWMwOiAgICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDggMTEgMTYgMjIgMzIgNDQgNDgg ODggOTYgMTc2IDE5MiBLSHoKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDA1MjcyNwpoZGFj MDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zOSBzaXplPTUgb2Zmc2V0PTM5CmhkYWMw OiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNApoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRp byBvdXRwdXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDAwMDQwNQpoZGFjMDogICAgICAg ICAgICAgICAgICBQV1IgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDAw MDEpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSAocGNtKQpoZGFjMDogICAgICBTdHJlYW0g Y2FwOiAweDAwMDAwMDAxCmhkYWMwOiAgICAgICAgICAgICAgICAgIFBDTQpoZGFjMDogICAgICAg ICBQQ00gY2FwOiAweDAwMGUwN2ZmCmhkYWMwOiAgICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJp dHMsIDggMTEgMTYgMjIgMzIgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKaGRhYzA6ICAgICAgT3V0 cHV0IGFtcDogMHgwMDA1MjcyNwpoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0z OSBzaXplPTUgb2Zmc2V0PTM5CmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNQpoZGFj MDogICAgICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDog MHgwMDAwMDQwNQpoZGFjMDogICAgICAgICAgICAgICAgICBQV1IgU1RFUkVPCmhkYWMwOiAgICAg QXNzb2NpYXRpb246IDAgKDB4MDAwMDAwMDIpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSAo cGNtKQpoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCmhkYWMwOiAgICAgICAgICAg ICAgICAgIFBDTQpoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwN2ZmCmhkYWMwOiAgICAg ICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDggMTEgMTYgMjIgMzIgNDQgNDggODggOTYgMTc2 IDE5MiBLSHoKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDA1MjcyNwpoZGFjMDogICAgICAg ICAgICAgICAgICBtdXRlPTAgc3RlcD0zOSBzaXplPTUgb2Zmc2V0PTM5CmhkYWMwOiAKaGRhYzA6 ICAgICAgICAgICAgIG5pZDogNgpoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQK aGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDAwMDQwNQpoZGFjMDogICAgICAgICAgICAgICAg ICBQV1IgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDAwMDQpCmhkYWMw OiAgICAgICAgICAgICBPU1M6IHBjbSAocGNtKQpoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAw MDAwMDAxCmhkYWMwOiAgICAgICAgICAgICAgICAgIFBDTQpoZGFjMDogICAgICAgICBQQ00gY2Fw OiAweDAwMGUwN2ZmCmhkYWMwOiAgICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDggMTEg MTYgMjIgMzIgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDog MHgwMDA1MjcyNwpoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zOSBzaXplPTUg b2Zmc2V0PTM5CmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNyBbRElTQUJMRURdCmhk YWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIGlucHV0CmhkYWMwOiAgICAgIFdpZGdldCBjYXA6 IDB4MDAxMzAzOTEKaGRhYzA6ICAgICAgICAgICAgICAgICAgRElHSVRBTCBVTlNPTCBTVEVSRU8K aGRhYzA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwNQpoZGFjMDogICAgICAgICAgICAgICAg ICBBQzMgUENNCmhkYWMwOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3ZTAKaGRhYzA6ICAgICAg ICAgICAgICAgICAgMTYgMjAgMjQgYml0cywgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKaGRhYzA6 ICAgICBjb25uZWN0aW9uczogMQpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICAr IFtESVNBQkxFRF0gPC0gbmlkPTI4IFtwaW46IFNQRElGLWluIChOb25lKV0gW0RJU0FCTEVEXQpo ZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDgKaGRhYzA6ICAgICAgICAgICAgTmFtZTog YXVkaW8gaW5wdXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDEwMDUwMQpoZGFjMDogICAg ICAgICAgICAgICAgICBQV1IgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDEgKDB4MDAw MDQwMDcpCmhkYWMwOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEKaGRhYzA6ICAgICAgICAg ICAgICAgICAgUENNCmhkYWMwOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3ZmYKaGRhYzA6ICAg ICAgICAgICAgICAgICAgMTYgMjAgMjQgYml0cywgOCAxMSAxNiAyMiAzMiA0NCA0OCA4OCA5NiAx NzYgMTkyIEtIegpoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAxCmhkYWMwOiAgICAgICAgICAgfApo ZGFjMDogICAgICAgICAgICsgPC0gbmlkPTEyIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6IApoZGFj MDogICAgICAgICAgICAgbmlkOiA5IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTog YXVkaW8gaW5wdXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDEwMDUwMQpoZGFjMDogICAg ICAgICAgICAgICAgICBQV1IgU1RFUkVPCmhkYWMwOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAw MDEKaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCmhkYWMwOiAgICAgICAgIFBDTSBjYXA6IDB4 MDAwZTA3ZmYKaGRhYzA6ICAgICAgICAgICAgICAgICAgMTYgMjAgMjQgYml0cywgOCAxMSAxNiAy MiAzMiA0NCA0OCA4OCA5NiAxNzYgMTkyIEtIegpoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAxCmhk YWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTEzIFthdWRpbyBzZWxl Y3Rvcl0gW0RJU0FCTEVEXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDEwCmhkYWMw OiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG91dHB1dApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAw eDAwMDAwNDA1CmhkYWMwOiAgICAgICAgICAgICAgICAgIFBXUiBTVEVSRU8KaGRhYzA6ICAgICBB c3NvY2lhdGlvbjogMCAoMHgwMDAwMDAxMCkKaGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtIChw Y20pCmhkYWMwOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEKaGRhYzA6ICAgICAgICAgICAg ICAgICAgUENNCmhkYWMwOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3ZmYKaGRhYzA6ICAgICAg ICAgICAgICAgICAgMTYgMjAgMjQgYml0cywgOCAxMSAxNiAyMiAzMiA0NCA0OCA4OCA5NiAxNzYg MTkyIEtIegpoZGFjMDogICAgICBPdXRwdXQgYW1wOiAweDAwMDUyNzI3CmhkYWMwOiAgICAgICAg ICAgICAgICAgIG11dGU9MCBzdGVwPTM5IHNpemU9NSBvZmZzZXQ9MzkKaGRhYzA6IApoZGFjMDog ICAgICAgICAgICAgbmlkOiAxMSBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1 ZGlvIHNlbGVjdG9yCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAzMDAzMDEKaGRhYzA6ICAg ICAgICAgICAgICAgICAgRElHSVRBTCBTVEVSRU8KaGRhYzA6ICAgICBjb25uZWN0aW9uczogMwpo ZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD04IFthdWRpbyBpbnB1 dF0gKHNlbGVjdGVkKQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTkgW2F1ZGlvIGlucHV0XSBb RElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTUgW2F1ZGlvIGlucHV0XSBbRElT QUJMRURdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMTIKaGRhYzA6ICAgICAgICAg ICAgTmFtZTogYXVkaW8gc2VsZWN0b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEw ZApoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjog MSAoMHgwMDAwNDAwNykKaGRhYzA6ICAgICAgICAgICAgIE9TUzogbGluZSwgbWljLCBjZCwgbWl4 LCBtb25pdG9yCmhkYWMwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwNTM2MjcKaGRhYzA6ICAgICAg ICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9NTQgc2l6ZT01IG9mZnNldD0zOQpoZGFjMDogICAgIGNv bm5lY3Rpb25zOiAxMApoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIFtESVNB QkxFRF0gPC0gbmlkPTU2IFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVEXQpoZGFjMDogICAgICAg ICAgICsgPC0gbmlkPTU3IFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6ICAgICAgICAgICArIDwtIG5p ZD01OCBbYXVkaW8gc2VsZWN0b3JdCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5p ZD01OSBbYXVkaW8gc2VsZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5p ZD02MCBbYXVkaW8gc2VsZWN0b3JdIChzZWxlY3RlZCkKaGRhYzA6ICAgICAgICAgICArIDwtIG5p ZD0yNCBbcGluOiBDRCAoRml4ZWQpXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBu aWQ9MzYgW3BpbjogTGluZS1vdXQgKEphY2spXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVE XSA8LSBuaWQ9MzcgW3BpbjogTGluZS1vdXQgKEphY2spXQpoZGFjMDogICAgICAgICAgICsgW0RJ U0FCTEVEXSA8LSBuaWQ9NjEgW2F1ZGlvIHNlbGVjdG9yXSBbRElTQUJMRURdCmhkYWMwOiAgICAg ICAgICAgKyA8LSBuaWQ9MzIgW2F1ZGlvIG1peGVyXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAg ICBuaWQ6IDEzIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gc2VsZWN0 b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwZApoZGFjMDogICAgICAgICAgICAg ICAgICBTVEVSRU8KaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDA1MzYyNwpoZGFjMDogICAg ICAgICAgICAgICAgICBtdXRlPTEgc3RlcD01NCBzaXplPTUgb2Zmc2V0PTM5CmhkYWMwOiAgICAg Y29ubmVjdGlvbnM6IDEwCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgPC0g bmlkPTU2IFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVEXSAoc2VsZWN0ZWQpCmhkYWMwOiAgICAg ICAgICAgKyA8LSBuaWQ9NTcgW2F1ZGlvIHNlbGVjdG9yXQpoZGFjMDogICAgICAgICAgICsgPC0g bmlkPTU4IFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01OSBbYXVk aW8gc2VsZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD02MCBbYXVk aW8gc2VsZWN0b3JdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MjQgW3BpbjogQ0QgKEZpeGVk KV0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0zNiBbcGluOiBMaW5lLW91dCAoSmFjayldCmhk YWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MzcgW3BpbjogTGluZS1vdXQgKEphY2spXQpoZGFjMDog ICAgICAgICAgICsgPC0gbmlkPTYxIFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVEXQpoZGFjMDog ICAgICAgICAgICsgPC0gbmlkPTMyIFthdWRpbyBtaXhlcl0KaGRhYzA6IApoZGFjMDogICAgICAg ICAgICAgbmlkOiAxNCBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIHNl bGVjdG9yCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAzMDAxMGQKaGRhYzA6ICAgICAgICAg ICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwNTM2MjcKaGRhYzA6 ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9NTQgc2l6ZT01IG9mZnNldD0zOQpoZGFjMDog ICAgIGNvbm5lY3Rpb25zOiAxMApoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICAr IDwtIG5pZD01NiBbYXVkaW8gc2VsZWN0b3JdIFtESVNBQkxFRF0gKHNlbGVjdGVkKQpoZGFjMDog ICAgICAgICAgICsgPC0gbmlkPTU3IFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6ICAgICAgICAgICAr IDwtIG5pZD01OCBbYXVkaW8gc2VsZWN0b3JdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9NTkg W2F1ZGlvIHNlbGVjdG9yXSBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9NjAg W2F1ZGlvIHNlbGVjdG9yXQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTI0IFtwaW46IENEIChG aXhlZCldCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MzYgW3BpbjogTGluZS1vdXQgKEphY2sp XQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTM3IFtwaW46IExpbmUtb3V0IChKYWNrKV0KaGRh YzA6ICAgICAgICAgICArIDwtIG5pZD02MSBbYXVkaW8gc2VsZWN0b3JdIFtESVNBQkxFRF0KaGRh YzA6ICAgICAgICAgICArIDwtIG5pZD0zMiBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAKaGRhYzA6ICAg ICAgICAgICAgIG5pZDogMTUgW0RJU0FCTEVEXQpoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRp byBpbnB1dApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMTAwNTAxCmhkYWMwOiAgICAgICAg ICAgICAgICAgIFBXUiBTVEVSRU8KaGRhYzA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpo ZGFjMDogICAgICAgICAgICAgICAgICBQQ00KaGRhYzA6ICAgICAgICAgUENNIGNhcDogMHgwMDBl MDdmZgpoZGFjMDogICAgICAgICAgICAgICAgICAxNiAyMCAyNCBiaXRzLCA4IDExIDE2IDIyIDMy IDQ0IDQ4IDg4IDk2IDE3NiAxOTIgS0h6CmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6 ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTQgW2F1ZGlvIHNlbGVjdG9y XSBbRElTQUJMRURdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMTYKaGRhYzA6ICAg ICAgICAgICAgTmFtZTogYmVlcCB3aWRnZXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDcw MDAwYwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAtMiAoMHgwMDAwMDAwMCkKaGRhYzA6ICAgICAg ICAgICAgIE9TUzogc3BlYWtlciAoc3BlYWtlcikKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHg4 MDBiMGYwZgpoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0xNSBzaXplPTExIG9m ZnNldD0xNQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDE3CmhkYWMwOiAgICAgICAg ICAgIE5hbWU6IHBpbjogSGVhZHBob25lcyAoSmFjaykKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDog MHgwMDQwMDE4ZApoZGFjMDogICAgICAgICAgICAgICAgICBVTlNPTCBTVEVSRU8KaGRhYzA6ICAg ICBBc3NvY2lhdGlvbjogMiAoMHgwMDAwMDAwMSkKaGRhYzA6ICAgICAgICAgUGluIGNhcDogMHgw MDAwMzczZgpoZGFjMDogICAgICAgICAgICAgICAgICBJU0MgVFJRRCBQREMgSFAgT1VUIElOIFZS RUZbIDUwIDgwIDEwMCBHUk9VTkQgSElaIF0KaGRhYzA6ICAgICAgUGluIGNvbmZpZzogMHgwMjIx NDAzMApoZGFjMDogICAgIFBpbiBjb250cm9sOiAweDAwMDAwMGMwIEhQIE9VVApoZGFjMDogICAg ICBPdXRwdXQgYW1wOiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBz dGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6ICAg ICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MzQgW2F1ZGlvIG1peGVyXQpoZGFj MDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDE4CmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBp bjogTGluZS1vdXQgKEphY2spCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAxOGQKaGRh YzA6ICAgICAgICAgICAgICAgICAgVU5TT0wgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246 IDAgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDM3M2YKaGRhYzA6 ICAgICAgICAgICAgICAgICAgSVNDIFRSUUQgUERDIEhQIE9VVCBJTiBWUkVGWyA1MCA4MCAxMDAg R1JPVU5EIEhJWiBdCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDEwMTQwMTAKaGRhYzA6ICAg ICBQaW4gY29udHJvbDogMHgwMDAwMDA0MCBPVVQKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHg4 MDAwMDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZz ZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAxCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDog ICAgICAgICAgICsgPC0gbmlkPTQxIFthdWRpbyBtaXhlcl0KaGRhYzA6IApoZGFjMDogICAgICAg ICAgICAgbmlkOiAxOSBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogU3Bl YWtlciAoTm9uZSkKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDEwYwpoZGFjMDogICAg ICAgICBQaW4gY2FwOiAweDAwMDAwMDEwCmhkYWMwOiAgICAgICAgICAgICAgICAgIE9VVApoZGFj MDogICAgICBQaW4gY29uZmlnOiAweDUxMTcxMWYwCmhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4 MDAwMDAwMDAKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDA1MWYxZgpoZGFjMDogICAgICAg ICAgICAgICAgICBtdXRlPTEgc3RlcD0zMSBzaXplPTUgb2Zmc2V0PTMxCmhkYWMwOiAgICAgY29u bmVjdGlvbnM6IDEKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJM RURdIDwtIG5pZD00NSBbYXVkaW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYzA6IApoZGFjMDogICAg ICAgICAgICAgbmlkOiAyMApoZGFjMDogICAgICAgICAgICBOYW1lOiBwaW46IE1pYyAoSmFjaykK aGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDE4ZApoZGFjMDogICAgICAgICAgICAgICAg ICBVTlNPTCBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMSAoMHgwMDAwNDAwMCkKaGRh YzA6ICAgICAgICAgICAgIE9TUzogbWljIChtaWMpCmhkYWMwOiAgICAgICAgIFBpbiBjYXA6IDB4 MDAwMDM3M2YKaGRhYzA6ICAgICAgICAgICAgICAgICAgSVNDIFRSUUQgUERDIEhQIE9VVCBJTiBW UkVGWyA1MCA4MCAxMDAgR1JPVU5EIEhJWiBdCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDJh MTkwMmUKaGRhYzA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDAyNCBJTiBWUkVGcwpoZGFjMDog ICAgICBPdXRwdXQgYW1wOiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9 MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6 ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD00MyBbYXVk aW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiAyMQpo ZGFjMDogICAgICAgICAgICBOYW1lOiBwaW46IExpbmUtaW4gKEphY2spCmhkYWMwOiAgICAgIFdp ZGdldCBjYXA6IDB4MDA0MDAxOGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgVU5TT0wgU1RFUkVP CmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDEgKDB4MDAwMDAwMDIpCmhkYWMwOiAgICAgICAgICAg ICBPU1M6IGxpbmUgKGxpbmUpCmhkYWMwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDM3MzcKaGRh YzA6ICAgICAgICAgICAgICAgICAgSVNDIFRSUUQgUERDIE9VVCBJTiBWUkVGWyA1MCA4MCAxMDAg R1JPVU5EIEhJWiBdCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDE4MTMwMjEKaGRhYzA6ICAg ICBQaW4gY29udHJvbDogMHgwMDAwMDAyNCBJTiBWUkVGcwpoZGFjMDogICAgICBPdXRwdXQgYW1w OiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0w IG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6ICAgICAgICAgICB8Cmhk YWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD00NCBbYXVkaW8gbWl4ZXJdIFtESVNB QkxFRF0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiAyMgpoZGFjMDogICAgICAgICAg ICBOYW1lOiBwaW46IExpbmUtb3V0IChKYWNrKQpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAw NDAwMThkCmhkYWMwOiAgICAgICAgICAgICAgICAgIFVOU09MIFNURVJFTwpoZGFjMDogICAgIEFz c29jaWF0aW9uOiAwICgweDAwMDAwMDA0KQpoZGFjMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAz NzM3CmhkYWMwOiAgICAgICAgICAgICAgICAgIElTQyBUUlFEIFBEQyBPVVQgSU4gVlJFRlsgNTAg ODAgMTAwIEdST1VORCBISVogXQpoZGFjMDogICAgICBQaW4gY29uZmlnOiAweDAxMDExMDEyCmhk YWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwNDAgT1VUCmhkYWMwOiAgICAgIE91dHB1dCBh bXA6IDB4ODAwMDAwMDAKaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXpl PTAgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFjMDogICAgICAgICAgIHwK aGRhYzA6ICAgICAgICAgICArIDwtIG5pZD00MiBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAKaGRhYzA6 ICAgICAgICAgICAgIG5pZDogMjMKaGRhYzA6ICAgICAgICAgICAgTmFtZTogcGluOiBNaWMgKEph Y2spCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDA5OGQKaGRhYzA6ICAgICAgICAgICAg ICAgICAgTFJTV0FQIFVOU09MIFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAxICgweDAw MDAwMDAxKQpoZGFjMDogICAgICAgICAgICAgT1NTOiBtb25pdG9yIChtb25pdG9yKQpoZGFjMDog ICAgICAgICBQaW4gY2FwOiAweDAwMDAzNzM3CmhkYWMwOiAgICAgICAgICAgICAgICAgIElTQyBU UlFEIFBEQyBPVVQgSU4gVlJFRlsgNTAgODAgMTAwIEdST1VORCBISVogXQpoZGFjMDogICAgICBQ aW4gY29uZmlnOiAweDAxYTE5MDIwCmhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwMjQg SU4gVlJFRnMKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDAwMDAwMApoZGFjMDogICAgICAg ICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFjMDogICAgIGNvbm5l Y3Rpb25zOiAxCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVE XSA8LSBuaWQ9MzggW2F1ZGlvIG1peGVyXSBbRElTQUJMRURdCmhkYWMwOiAKaGRhYzA6ICAgICAg ICAgICAgIG5pZDogMjQKaGRhYzA6ICAgICAgICAgICAgTmFtZTogcGluOiBDRCAoRml4ZWQpCmhk YWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAwMDEKaGRhYzA6ICAgICAgICAgICAgICAgICAg U1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDEgKDB4MDAwMDAwMDQpCmhkYWMwOiAgICAg ICAgICAgICBPU1M6IGNkIChjZCkKaGRhYzA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMDAyMApo ZGFjMDogICAgICAgICAgICAgICAgICBJTgpoZGFjMDogICAgICBQaW4gY29uZmlnOiAweDk5MzMx MTIyCmhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwMjAgSU4KaGRhYzA6IApoZGFjMDog ICAgICAgICAgICAgbmlkOiAyNSBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBv d2VyIHdpZGdldApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwNTAwNTAwCmhkYWMwOiAgICAg ICAgICAgICAgICAgIFBXUgpoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAyCmhkYWMwOiAgICAgICAg ICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTMyIFthdWRpbyBtaXhlcl0gKHNlbGVjdGVk KQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTMzIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6IApo ZGFjMDogICAgICAgICAgICAgbmlkOiAyNgpoZGFjMDogICAgICAgICAgICBOYW1lOiBiZWVwIHdp ZGdldApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwNzAwMDAwCmhkYWMwOiAgICAgQXNzb2Np YXRpb246IC0yICgweDAwMDAwMDAwKQpoZGFjMDogICAgICAgICAgICAgT1NTOiBzcGVha2VyIChz cGVha2VyKQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDI3CmhkYWMwOiAgICAgICAg ICAgIE5hbWU6IHBpbjogU1BESUYtb3V0IChKYWNrKQpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAw eDAwNDAwMzBkCmhkYWMwOiAgICAgICAgICAgICAgICAgIERJR0lUQUwgU1RFUkVPCmhkYWMwOiAg ICAgQXNzb2NpYXRpb246IDMgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAgICAgIFBpbiBjYXA6IDB4 MDAwMDAwMTAKaGRhYzA6ICAgICAgICAgICAgICAgICAgT1VUCmhkYWMwOiAgICAgIFBpbiBjb25m aWc6IDB4MDE0NWYxZjAKaGRhYzA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDA0MCBPVVQKaGRh YzA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDA1MjcyNwpoZGFjMDogICAgICAgICAgICAgICAgICBt dXRlPTEgc3RlcD0zOSBzaXplPTUgb2Zmc2V0PTM5CmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEK aGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MiBbYXVkaW8gb3V0 cHV0XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDI4IFtESVNBQkxFRF0KaGRhYzA6 ICAgICAgICAgICAgTmFtZTogcGluOiBTUERJRi1pbiAoTm9uZSkKaGRhYzA6ICAgICAgV2lkZ2V0 IGNhcDogMHgwMDQwMDIwYgpoZGFjMDogICAgICAgICAgICAgICAgICBESUdJVEFMIFNURVJFTwpo ZGFjMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAwMDIwCmhkYWMwOiAgICAgICAgICAgICAgICAg IElOCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4NDFjNWYxZjAKaGRhYzA6ICAgICBQaW4gY29u dHJvbDogMHgwMDAwMDAwMApoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDUxZjE3CmhkYWMw OiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTMxIHNpemU9NSBvZmZzZXQ9MjMKaGRhYzA6 IApoZGFjMDogICAgICAgICAgICAgbmlkOiAyOSBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAg IE5hbWU6IGF1ZGlvIG1peGVyCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAyMDAzMDMKaGRh YzA6ICAgICAgICAgICAgICAgICAgRElHSVRBTCBTVEVSRU8KaGRhYzA6ICAgICAgIElucHV0IGFt cDogMHg4MDAwMDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9 MCBvZmZzZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAyCmhkYWMwOiAgICAgICAgICAgfApo ZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MSBbR0hPU1QhXSBbVU5LTk9XTl0K aGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTExIFthdWRpbyBzZWxlY3Rvcl0g W0RJU0FCTEVEXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDMwIFtESVNBQkxFRF0K aGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gbWl4ZXIKaGRhYzA6ICAgICAgV2lkZ2V0IGNh cDogMHgwMDIwMDEwMwpoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICAg IElucHV0IGFtcDogMHg4MDAwMDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3Rl cD0wIHNpemU9MCBvZmZzZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAyCmhkYWMwOiAgICAg ICAgICAgfApoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9NTQgW2F1ZGlvIHNl bGVjdG9yXSBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0z MyBbYXVkaW8gc2VsZWN0b3JdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMzEgW0RJ U0FCTEVEXQpoZGFjMDogICAgICAgICAgICBOYW1lOiB2b2x1bWUgd2lkZ2V0CmhkYWMwOiAgICAg IFdpZGdldCBjYXA6IDB4MDA2MDAwODAKaGRhYzA6ICAgICAgICAgICAgICAgICAgVU5TT0wKaGRh YzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiAzMgpoZGFjMDogICAgICAgICAgICBOYW1lOiBh dWRpbyBtaXhlcgpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMjAwMTBiCmhkYWMwOiAgICAg ICAgICAgICAgICAgIFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAtMiAoMHgwMDAwNDAw NykKaGRhYzA6ICAgICAgICAgICAgIE9TUzogbWl4IChtaXgpCmhkYWMwOiAgICAgICBJbnB1dCBh bXA6IDB4ODAwNTFmMTcKaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MzEgc2l6 ZT01IG9mZnNldD0yMwpoZGFjMDogICAgIGNvbm5lY3Rpb25zOiA4CmhkYWMwOiAgICAgICAgICAg fApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTU3IFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6ICAg ICAgICAgICArIDwtIG5pZD01MSBbYXVkaW8gc2VsZWN0b3JdCmhkYWMwOiAgICAgICAgICAgKyBb RElTQUJMRURdIDwtIG5pZD01NiBbYXVkaW8gc2VsZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6ICAg ICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTYxIFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVE XQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTUyIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6ICAg ICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTU5IFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVE XQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTI0IFtwaW46IENEIChGaXhlZCldCmhkYWMwOiAg ICAgICAgICAgKyA8LSBuaWQ9MjYgW2JlZXAgd2lkZ2V0XQpoZGFjMDogCmhkYWMwOiAgICAgICAg ICAgICBuaWQ6IDMzCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMw OiAgICAgIFdpZGdldCBjYXA6IDB4MDAzMDAxMGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RF UkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IC0yICgweDAwMDAwMDAwKQpoZGFjMDogICAgICAg ICAgICAgT1NTOiBtaXgKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDA1MWYxZgpoZGFjMDog ICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0zMSBzaXplPTUgb2Zmc2V0PTMxCmhkYWMwOiAg ICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyA8 LSBuaWQ9MzIgW2F1ZGlvIG1peGVyXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDM0 CmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG1peGVyCmhkYWMwOiAgICAgIFdpZGdldCBj YXA6IDB4MDAyMDAxMDMKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAg QXNzb2NpYXRpb246IDIgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSwg bWl4CmhkYWMwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAwMDAwMDAKaGRhYzA6ICAgICAgICAgICAg ICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9u czogMgpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01NSBbYXVk aW8gc2VsZWN0b3JdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MzMgW2F1ZGlvIHNlbGVjdG9y XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDM1IFtESVNBQkxFRF0KaGRhYzA6ICAg ICAgICAgICAgTmFtZTogdmVuZG9yIHdpZGdldApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAw ZjAwMTAwCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDE4CmhkYWMwOiAgICAgICAgICAgfApoZGFj MDogICAgICAgICAgICsgPC0gbmlkPTE3IFtwaW46IEhlYWRwaG9uZXMgKEphY2spXSAoc2VsZWN0 ZWQpCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTggW3BpbjogTGluZS1vdXQgKEphY2spXQpo ZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTkgW3BpbjogU3BlYWtlciAoTm9u ZSldIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yMCBbcGluOiBNaWMgKEph Y2spXQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTIxIFtwaW46IExpbmUtaW4gKEphY2spXQpo ZGFjMDogICAgICAgICAgICsgPC0gbmlkPTIyIFtwaW46IExpbmUtb3V0IChKYWNrKV0KaGRhYzA6 ICAgICAgICAgICArIDwtIG5pZD0yMyBbcGluOiBNaWMgKEphY2spXQpoZGFjMDogICAgICAgICAg ICsgPC0gbmlkPTI0IFtwaW46IENEIChGaXhlZCldCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9 MzYgW3BpbjogTGluZS1vdXQgKEphY2spXQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTM3IFtw aW46IExpbmUtb3V0IChKYWNrKV0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01NiBbYXVkaW8g c2VsZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01NyBbYXVkaW8g c2VsZWN0b3JdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9NTggW2F1ZGlvIHNlbGVjdG9yXQpo ZGFjMDogICAgICAgICAgICsgPC0gbmlkPTU5IFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVEXQpo ZGFjMDogICAgICAgICAgICsgPC0gbmlkPTYwIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6ICAgICAg ICAgICArIDwtIG5pZD02MSBbYXVkaW8gc2VsZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6ICAgICAg ICAgICArIDwtIG5pZD0zMiBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9 MzMgW2F1ZGlvIHNlbGVjdG9yXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDM2Cmhk YWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogTGluZS1vdXQgKEphY2spCmhkYWMwOiAgICAgIFdp ZGdldCBjYXA6IDB4MDA0MDA5OGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgTFJTV0FQIFVOU09M IFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAwICgweDAwMDAwMDAyKQpoZGFjMDogICAg ICAgICBQaW4gY2FwOiAweDAwMDAwMDM3CmhkYWMwOiAgICAgICAgICAgICAgICAgIElTQyBUUlFE IFBEQyBPVVQgSU4KaGRhYzA6ICAgICAgUGluIGNvbmZpZzogMHgwMTAxNjAxMQpoZGFjMDogICAg IFBpbiBjb250cm9sOiAweDAwMDAwMDQwIE9VVApoZGFjMDogICAgICBPdXRwdXQgYW1wOiAweDgw MDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNl dD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAg ICAgICAgICAgKyA8LSBuaWQ9MzkgW2F1ZGlvIG1peGVyXQpoZGFjMDogCmhkYWMwOiAgICAgICAg ICAgICBuaWQ6IDM3CmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogTGluZS1vdXQgKEphY2sp CmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAxOGQKaGRhYzA6ICAgICAgICAgICAgICAg ICAgVU5TT0wgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDAwMTApCmhk YWMwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDAwMzcKaGRhYzA6ICAgICAgICAgICAgICAgICAg SVNDIFRSUUQgUERDIE9VVCBJTgpoZGFjMDogICAgICBQaW4gY29uZmlnOiAweDAxMDEyMDE0Cmhk YWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwNDAgT1VUCmhkYWMwOiAgICAgIE91dHB1dCBh bXA6IDB4ODAwMDAwMDAKaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXpl PTAgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFjMDogICAgICAgICAgIHwK aGRhYzA6ICAgICAgICAgICArIDwtIG5pZD00MCBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAKaGRhYzA6 ICAgICAgICAgICAgIG5pZDogMzggW0RJU0FCTEVEXQpoZGFjMDogICAgICAgICAgICBOYW1lOiBh dWRpbyBtaXhlcgpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMjAwMTAzCmhkYWMwOiAgICAg ICAgICAgICAgICAgIFNURVJFTwpoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDAwMDAwCmhk YWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMw OiAgICAgY29ubmVjdGlvbnM6IDIKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAg KyBbRElTQUJMRURdIDwtIG5pZD01MCBbYXVkaW8gc2VsZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6 ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTMzIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6 IApoZGFjMDogICAgICAgICAgICAgbmlkOiAzOQpoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRp byBtaXhlcgpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMjAwMTAzCmhkYWMwOiAgICAgICAg ICAgICAgICAgIFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAwICgweDAwMDAwMDAyKQpo ZGFjMDogICAgICAgICAgICAgT1NTOiBwY20sIG1peApoZGFjMDogICAgICAgSW5wdXQgYW1wOiAw eDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9m ZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDIKaGRhYzA6ICAgICAgICAgICB8CmhkYWMw OiAgICAgICAgICAgKyA8LSBuaWQ9NSBbYXVkaW8gb3V0cHV0XQpoZGFjMDogICAgICAgICAgICsg PC0gbmlkPTMzIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlk OiA0MApoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBtaXhlcgpoZGFjMDogICAgICBXaWRn ZXQgY2FwOiAweDAwMjAwMTAzCmhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpoZGFjMDog ICAgIEFzc29jaWF0aW9uOiAwICgweDAwMDAwMDEwKQpoZGFjMDogICAgICAgICAgICAgT1NTOiBw Y20sIG1peApoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAg ICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVj dGlvbnM6IDIKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTAg W2F1ZGlvIG91dHB1dF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0zMyBbYXVkaW8gc2VsZWN0 b3JdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNDEKaGRhYzA6ICAgICAgICAgICAg TmFtZTogYXVkaW8gbWl4ZXIKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwMwpoZGFj MDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMCAoMHgw MDAwMDAwMSkKaGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtLCBtaXgKaGRhYzA6ICAgICAgIElu cHV0IGFtcDogMHg4MDAwMDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0w IHNpemU9MCBvZmZzZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAyCmhkYWMwOiAgICAgICAg ICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTQgW2F1ZGlvIG91dHB1dF0KaGRhYzA6ICAg ICAgICAgICArIDwtIG5pZD0zMyBbYXVkaW8gc2VsZWN0b3JdCmhkYWMwOiAKaGRhYzA6ICAgICAg ICAgICAgIG5pZDogNDIKaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gbWl4ZXIKaGRhYzA6 ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwMwpoZGFjMDogICAgICAgICAgICAgICAgICBTVEVS RU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMCAoMHgwMDAwMDAwNCkKaGRhYzA6ICAgICAgICAg ICAgIE9TUzogcGNtLCBtaXgKaGRhYzA6ICAgICAgIElucHV0IGFtcDogMHg4MDAwMDAwMApoZGFj MDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFjMDog ICAgIGNvbm5lY3Rpb25zOiAyCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsg PC0gbmlkPTYgW2F1ZGlvIG91dHB1dF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0zMyBbYXVk aW8gc2VsZWN0b3JdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNDMgW0RJU0FCTEVE XQpoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBtaXhlcgpoZGFjMDogICAgICBXaWRnZXQg Y2FwOiAweDAwMjAwMTAzCmhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpoZGFjMDogICAg ICAgSW5wdXQgYW1wOiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBz dGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDIKaGRhYzA6ICAg ICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD00OCBbYXVkaW8g c2VsZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlk PTMzIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiA0NCBb RElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG1peGVyCmhkYWMwOiAgICAg IFdpZGdldCBjYXA6IDB4MDAyMDAxMDMKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhk YWMwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAwMDAwMDAKaGRhYzA6ICAgICAgICAgICAgICAgICAg bXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMgpo ZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTQ5 IFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVEXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVE XSA8LSBuaWQ9MzMgW2F1ZGlvIHNlbGVjdG9yXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBu aWQ6IDQ1IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gbWl4ZXIKaGRh YzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwMApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAx CmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTMwIFthdWRpbyBt aXhlcl0gW0RJU0FCTEVEXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDQ2IFtESVNB QkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogdmVuZG9yIHdpZGdldApoZGFjMDogICAgICBX aWRnZXQgY2FwOiAweDAwZjAwMDAwCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNDcg W0RJU0FCTEVEXQpoZGFjMDogICAgICAgICAgICBOYW1lOiB2ZW5kb3Igd2lkZ2V0CmhkYWMwOiAg ICAgIFdpZGdldCBjYXA6IDB4MDBmMDAxMDAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogNgpoZGFj MDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0xNyBbcGluOiBIZWFkcGhv bmVzIChKYWNrKV0gKHNlbGVjdGVkKQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTE4IFtwaW46 IExpbmUtb3V0IChKYWNrKV0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yMCBbcGluOiBNaWMg KEphY2spXQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTIxIFtwaW46IExpbmUtaW4gKEphY2sp XQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTIyIFtwaW46IExpbmUtb3V0IChKYWNrKV0KaGRh YzA6ICAgICAgICAgICArIDwtIG5pZD0yMyBbcGluOiBNaWMgKEphY2spXQpoZGFjMDogCmhkYWMw OiAgICAgICAgICAgICBuaWQ6IDQ4IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTog YXVkaW8gc2VsZWN0b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwMQpoZGFjMDog ICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBjb25uZWN0aW9uczogMwpoZGFjMDog ICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0zIFthdWRpbyBvdXRwdXRdIChz ZWxlY3RlZCkKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD00IFthdWRpbyBvdXRwdXRdCmhkYWMw OiAgICAgICAgICAgKyA8LSBuaWQ9NiBbYXVkaW8gb3V0cHV0XQpoZGFjMDogCmhkYWMwOiAgICAg ICAgICAgICBuaWQ6IDQ5IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8g c2VsZWN0b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwMQpoZGFjMDogICAgICAg ICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBjb25uZWN0aW9uczogMgpoZGFjMDogICAgICAg ICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD00IFthdWRpbyBvdXRwdXRdIChzZWxlY3Rl ZCkKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0xMCBbYXVkaW8gb3V0cHV0XQpoZGFjMDogCmhk YWMwOiAgICAgICAgICAgICBuaWQ6IDUwIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFt ZTogYXVkaW8gc2VsZWN0b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwMQpoZGFj MDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBjb25uZWN0aW9uczogMgpoZGFj MDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01IFthdWRpbyBvdXRwdXRd IChzZWxlY3RlZCkKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD00IFthdWRpbyBvdXRwdXRdCmhk YWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNTEKaGRhYzA6ICAgICAgICAgICAgTmFtZTog YXVkaW8gc2VsZWN0b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwMQpoZGFjMDog ICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMSAoMHgwMDAw MDAwMikKaGRhYzA6ICAgICAgICAgICAgIE9TUzogbGluZQpoZGFjMDogICAgIGNvbm5lY3Rpb25z OiAzCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTU4IFthdWRp byBzZWxlY3Rvcl0gKHNlbGVjdGVkKQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBu aWQ9MzcgW3BpbjogTGluZS1vdXQgKEphY2spXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVE XSA8LSBuaWQ9MzYgW3BpbjogTGluZS1vdXQgKEphY2spXQpoZGFjMDogCmhkYWMwOiAgICAgICAg ICAgICBuaWQ6IDUyCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMw OiAgICAgIFdpZGdldCBjYXA6IDB4MDAzMDAxMDEKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RF UkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDEgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAgICAg ICAgICBPU1M6IG1vbml0b3IKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMwpoZGFjMDogICAgICAg ICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD02MCBbYXVkaW8gc2VsZWN0b3JdIChzZWxl Y3RlZCkKaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTM3IFtwaW46IExpbmUt b3V0IChKYWNrKV0KaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTM2IFtwaW46 IExpbmUtb3V0IChKYWNrKV0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiA1MyBbRElT QUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHZlbmRvciB3aWRnZXQKaGRhYzA6ICAgICAg V2lkZ2V0IGNhcDogMHgwMGYwMDAwMApoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDU0 IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gc2VsZWN0b3IKaGRhYzA6 ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwMQpoZGFjMDogICAgICAgICAgICAgICAgICBTVEVS RU8KaGRhYzA6ICAgICBjb25uZWN0aW9uczogMwpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAg ICAgICAgICArIDwtIG5pZD0zIFthdWRpbyBvdXRwdXRdIChzZWxlY3RlZCkKaGRhYzA6ICAgICAg ICAgICArIDwtIG5pZD00IFthdWRpbyBvdXRwdXRdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9 NiBbYXVkaW8gb3V0cHV0XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDU1CmhkYWMw OiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6 IDB4MDAzMDAxMDEKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAgQXNz b2NpYXRpb246IDIgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbQpoZGFj MDogICAgIGNvbm5lY3Rpb25zOiAzCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAg ICsgPC0gbmlkPTMgW2F1ZGlvIG91dHB1dF0gKHNlbGVjdGVkKQpoZGFjMDogICAgICAgICAgICsg W0RJU0FCTEVEXSA8LSBuaWQ9NCBbYXVkaW8gb3V0cHV0XQpoZGFjMDogICAgICAgICAgICsgW0RJ U0FCTEVEXSA8LSBuaWQ9NiBbYXVkaW8gb3V0cHV0XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAg ICBuaWQ6IDU2IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gc2VsZWN0 b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwZApoZGFjMDogICAgICAgICAgICAg ICAgICBTVEVSRU8KaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDI3MDMwMApoZGFjMDogICAg ICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zIHNpemU9Mzkgb2Zmc2V0PTAKaGRhYzA6ICAgICBj b25uZWN0aW9uczogMQpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5p ZD0xNyBbcGluOiBIZWFkcGhvbmVzIChKYWNrKV0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAg bmlkOiA1NwpoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBzZWxlY3RvcgpoZGFjMDogICAg ICBXaWRnZXQgY2FwOiAweDAwMzAwMTBkCmhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpo ZGFjMDogICAgIEFzc29jaWF0aW9uOiAxICgweDAwMDA0MDAwKQpoZGFjMDogICAgICAgICAgICAg T1NTOiBtaWMKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDI3MDMwMApoZGFjMDogICAgICAg ICAgICAgICAgICBtdXRlPTAgc3RlcD0zIHNpemU9Mzkgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25u ZWN0aW9uczogMQpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0y MCBbcGluOiBNaWMgKEphY2spXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDU4Cmhk YWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMwOiAgICAgIFdpZGdldCBj YXA6IDB4MDAzMDAxMGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAg QXNzb2NpYXRpb246IDEgKDB4MDAwMDAwMDIpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IGxpbmUK aGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDI3MDMwMApoZGFjMDogICAgICAgICAgICAgICAg ICBtdXRlPTAgc3RlcD0zIHNpemU9Mzkgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczog MQpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yMSBbcGluOiBM aW5lLWluIChKYWNrKV0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiA1OSBbRElTQUJM RURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMwOiAgICAgIFdp ZGdldCBjYXA6IDB4MDAzMDAxMGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMw OiAgICAgIE91dHB1dCBhbXA6IDB4MDAyNzAzMDAKaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0 ZT0wIHN0ZXA9MyBzaXplPTM5IG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRh YzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MjIgW3BpbjogTGluZS1v dXQgKEphY2spXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDYwCmhkYWMwOiAgICAg ICAgICAgIE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAz MDAxMGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRp b246IDEgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IG1vbml0b3IKaGRhYzA6 ICAgICAgT3V0cHV0IGFtcDogMHgwMDI3MDMwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRl PTAgc3RlcD0zIHNpemU9Mzkgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFj MDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yMyBbcGluOiBNaWMgKEph Y2spXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDYxIFtESVNBQkxFRF0KaGRhYzA6 ICAgICAgICAgICAgTmFtZTogYXVkaW8gc2VsZWN0b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDog MHgwMDMwMDEwZApoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICAgT3V0 cHV0IGFtcDogMHgwMDI3MDMwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0z IHNpemU9Mzkgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFjMDogICAgICAg ICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0xOCBbcGluOiBMaW5lLW91dCAoSmFjayld CmhkYWMwOiAKcGNtMDogPEhEQSBBbmFsb2cgRGV2aWNlcyBBRDE5ODhCIFBDTSAjMCBBbmFsb2c+ IGF0IGNhZCAwIG5pZCAxIG9uIGhkYWMwCnBjbTE6IDxIREEgQW5hbG9nIERldmljZXMgQUQxOTg4 QiBQQ00gIzEgQW5hbG9nPiBhdCBjYWQgMCBuaWQgMSBvbiBoZGFjMApwY20yOiA8SERBIEFuYWxv ZyBEZXZpY2VzIEFEMTk4OEIgUENNICMyIERpZ2l0YWw+IGF0IGNhZCAwIG5pZCAxIG9uIGhkYWMw Cg== ------=_Part_6752_21875099.1231302591757-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 09:29:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAD27106564A for ; Wed, 7 Jan 2009 09:29:35 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB8D8FC0C for ; Wed, 7 Jan 2009 09:29:34 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 231150224; Wed, 07 Jan 2009 11:29:34 +0200 Message-ID: <49647602.9060402@FreeBSD.org> Date: Wed, 07 Jan 2009 11:29:38 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> In-Reply-To: <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: snd_hda(4): getting line-in to work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 09:29:36 -0000 Garrett Cooper wrote: > On Tue, Jan 6, 2009 at 12:53 PM, Alexander Motin wrote: >> Garrett Cooper wrote: >>> I'm not sure if it's user error or not, but my snd_hda(4) enabled >>> chipset doesn't have line-in support enabled. I was wondering if there >>> were a special set of instructions I need to follow to get this >>> working. >> The main instruction is to boot system with verbose messages. snd_hda writes >> all information needed to answer most questions. Read it yourself and if it >> does not help - send it to me. >> >>> [gcooper@orangebox /scratch/ltp]$ cat /dev/sndstat >>> FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) >>> Installed devices: >>> pcm0: at cad 0 nid 1 on >>> hdac0 [MPSAFE] (1p:1v/1r:1v channels duplex default) >> All I can see here is that you have some recording device. You can browse >> and select specific recording source with `mixer =rec` command. For >> additional details look verbose output and read new snd_hda man page. >> >>> pcm1: at cad 0 nid 1 on >>> hdac0 [MPSAFE] (1p:1v/0r:0v channels) >>> pcm2: at cad 0 nid 1 on >>> hdac0 [MPSAFE] (1p:1v/0r:0v channels) >> -- >> Alexander Motin > > Trying with the instructions on the manpage actually disabled my > sound... then again I probably screwed up the settings (I believe it > was noted as pcm2 before??). > > Here're the device.hints entries and I attached the -v boot log > snippet for the card: In attached log you have missed one of very interesting parts while grepping: pcmX devices output prints sound processing paths within codec for every PCM device. Look it first before doing something. > hint.hdac.0.cad0.nid17.config="as=1seq=0 device=Headphones" > hint.hdac.0.cad0.nid18.config="as=2seq=0 device=Line-out" > hint.hdac.0.cad0.nid19.config="as=3seq=0 device=Speaker" > hint.hdac.0.cad0.nid20.config="as=4seq=0 device=Mic" > hint.hdac.0.cad0.nid21.config="as=5seq=0 device=Line-in" > hint.hdac.0.cad0.nid22.config="as=6seq=0 device=Line-out" > hint.hdac.0.cad0.nid23.config="as=6seq=0 device=Mic" > hint.hdac.0.cad0.nid24.config="as=6seq=0 device=CD" > hint.hdac.0.cad0.nid36.config="as=5seq=0 device=Line-out" > hint.hdac.0.cad0.nid37.config="as=6seq=0 device=Line-out" Except lack of speces between fields there is also lack of any sense. I don't understand what was you trying to do, but it will not work: - you configured nid 21 and nid 36 as association five, but made one of them input and other output. It is incorrect, association may include only pins of one direction (in/out); - association 6 is the same; - nid 19 has connectivity "None", so it will not be used by driver. It is all described in manual. Actually I think default configuration is quite reasonable. There is some things that can be tuned, but you should first understand what you have and how it works. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 10:24:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50DD4106566C for ; Wed, 7 Jan 2009 10:24:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id D7F9D8FC16 for ; Wed, 7 Jan 2009 10:24:57 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=SdnMM7u8Px4A:10 a=nklthdr5v5AUSfVrlghuJA==:17 a=6dKDmB7TKdn1_aAX2d4A:9 a=suT37CYBWv5LY4Aq8TxHne0WlQgA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 125376464; Wed, 07 Jan 2009 11:24:56 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 7 Jan 2009 11:27:18 +0100 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901071127.19863.hselasky@c2i.net> Cc: Alexander Best Subject: Re: Problem with usbconfig and powerstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 10:24:58 -0000 On Wednesday 07 January 2009, Alexander Best wrote: > hi there, > > i'm having a bit of a problem with usbconfig. the problem first occured a > few days ago. when i try to disable a usb device with power_off the power > state changes to SAVE and not OFF. if i try to enable the usb device with > power_on it won't work although usbconfig tells me the power state is ON. > the only way to get the usb device working again is to unlpug it and plug > it in again. > > last week i could switch the power state from off to on and vice versa > without any problems. > Hi, Last week power-save support was introduced. It might be a minor bug in the HC driver's power save support. What host controller are you using? dmesg | grep -i usb --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 10:57:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96B33106566B for ; Wed, 7 Jan 2009 10:57:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2DD168FC12 for ; Wed, 7 Jan 2009 10:57:13 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=SdnMM7u8Px4A:10 a=nklthdr5v5AUSfVrlghuJA==:17 a=6I5d2MoRAAAA:8 a=_MVxbyHXJlMGmW25JUIA:9 a=QbS6LPC-Zi1xx5fTQIgP0urLcJUA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 125397113; Wed, 07 Jan 2009 11:57:12 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 7 Jan 2009 11:59:31 +0100 User-Agent: KMail/1.9.7 References: <200901071127.19863.hselasky@c2i.net> In-Reply-To: <200901071127.19863.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901071159.33529.hselasky@c2i.net> Cc: Alexander Best Subject: Re: Problem with usbconfig and powerstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 10:57:14 -0000 On Wednesday 07 January 2009, Hans Petter Selasky wrote: > On Wednesday 07 January 2009, Alexander Best wrote: > > hi there, > > > > i'm having a bit of a problem with usbconfig. the problem first occured a > > few days ago. when i try to disable a usb device with power_off the power > > state changes to SAVE and not OFF. if i try to enable the usb device with > > power_on it won't work although usbconfig tells me the power state is ON. > > the only way to get the usb device working again is to unlpug it and plug > > it in again. > > > > last week i could switch the power state from off to on and vice versa > > without any problems. > > Hi, > > Last week power-save support was introduced. It might be a minor bug in the > HC driver's power save support. What host controller are you using? > > dmesg | grep -i usb > Here are some patches which you can try: http://perforce.freebsd.org/chv.cgi?CH=155750 --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 13:28:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 307FC106567B; Wed, 7 Jan 2009 13:28:00 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 6032D8FC20; Wed, 7 Jan 2009 13:27:59 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nklthdr5v5AUSfVrlghuJA==:17 a=6I5d2MoRAAAA:8 a=S6OfEhMYIk30SjVt-qAA:9 a=20TI77FPNFu4HN9K32krc5IVeOUA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1174733725; Wed, 07 Jan 2009 14:27:57 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 7 Jan 2009 14:30:18 +0100 User-Agent: KMail/1.9.7 References: <47297827@bb.ipt.ru> <20090105021809.d3848b9c.nork@FreeBSD.org> <20090105025330.68b22f63.nork@FreeBSD.org> In-Reply-To: <20090105025330.68b22f63.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901071430.20446.hselasky@c2i.net> Cc: pyunyh@gmail.com, Boris Samorodov , Alfred Perlstein , Norikatsu Shigemura Subject: Re: Call for axe(4) testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 13:28:01 -0000 On Sunday 04 January 2009, Norikatsu Shigemura wrote: > Hi hps! > Try this patch: http://perforce.freebsd.org/chv.cgi?CH=155755 --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 14:43:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 863FE1065677 for ; Wed, 7 Jan 2009 14:43:06 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from mail-bw0-f14.google.com (mail-bw0-f14.google.com [209.85.218.14]) by mx1.freebsd.org (Postfix) with ESMTP id 134948FC2B for ; Wed, 7 Jan 2009 14:43:05 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by bwz7 with SMTP id 7so348535bwz.19 for ; Wed, 07 Jan 2009 06:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=5pqj97x7k9KMec+UmSApbWDBaOUim6LhoVCikORbe3w=; b=JXD4K3VHfNYk8QKYxlskX7bT6alCFB/XiEQIlKeRjh48llplvPfTXZRNB7yjsEeQC0 FrH661wWc5Ejs8IICTN9uotwVe9zUnW0Olb0pj0AVKatTcLmWPaDRpvP0H2GSZsWYe7+ z0SvTFfuXzXKtQk1kXe50NQh0ipU1LV++MeEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=IdPhbf5LLryQ29wq57s3uxqNOzhBE3+wkn0XbhSTOBs5pTFfnpf6bICtoFyRQJQJC1 /Ouz/MHvPnL28+A/vjT56k7WP7FNXYdWg4qCRCzRymy38EyazudYNZbM+N3xBDP3PA+A Jp6RvzSdIhHbP7z7grWEtW4OF6we0VBUGmPno= Received: by 10.223.127.8 with SMTP id e8mr16021143fas.10.1231337841873; Wed, 07 Jan 2009 06:17:21 -0800 (PST) Received: by 10.223.119.74 with HTTP; Wed, 7 Jan 2009 06:17:21 -0800 (PST) Message-ID: <8e10486b0901070617q2ddb82cem18b34b70c8cc45ef@mail.gmail.com> Date: Wed, 7 Jan 2009 12:17:21 -0200 From: "Alexandre Biancalana" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ZFS boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 14:43:07 -0000 Hi List ! Happy New Year! I From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 14:43:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C665710656D7 for ; Wed, 7 Jan 2009 14:43:34 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from mail-bw0-f14.google.com (mail-bw0-f14.google.com [209.85.218.14]) by mx1.freebsd.org (Postfix) with ESMTP id 3A3388FC1A for ; Wed, 7 Jan 2009 14:43:34 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by mail-bw0-f14.google.com with SMTP id 7so348535bwz.19 for ; Wed, 07 Jan 2009 06:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=XDiWp7k//zn9RjXwiEGk4i5YlNITveuCpBta5UKk7is=; b=DkG+TQ4p1GnGNww5PA6n61Mz2SzpGnfIgidc1b5mTfwCG93q5ERk11cFB+wNycUtE6 pqVVVU8+hj4uYBpzoygNQjg+hujHF/Sy5zge8qbhu+9bNIKZsqPFtyaaFXCAOXwtYAB7 yd1AQyOCfqnMkz8bIiZsOWI7FiSjX6TqlcW9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wTXHGybRJrBVtPPZJCEs0KCT0rnk0+Ks/uQHcmW+CKGcB1VnwpXljRldB3b3Hqa2CS LiMkPTXMcDOzAqZhtmPZ+pTFrVKQYm9cKRVtszwOtI+5D7gyb5Pb/vJNs2CsSAhxGyyN olFLsbTdDG7IqswqVwh/0EPYepzC3iMZW72vc= Received: by 10.223.111.211 with SMTP id t19mr16467917fap.64.1231338046488; Wed, 07 Jan 2009 06:20:46 -0800 (PST) Received: by 10.223.119.74 with HTTP; Wed, 7 Jan 2009 06:20:46 -0800 (PST) Message-ID: <8e10486b0901070620x610a8156lfc1206e5262f8f5a@mail.gmail.com> Date: Wed, 7 Jan 2009 12:20:46 -0200 From: "Alexandre Biancalana" To: freebsd-current@freebsd.org In-Reply-To: <8e10486b0901070617q2ddb82cem18b34b70c8cc45ef@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0901070617q2ddb82cem18b34b70c8cc45ef@mail.gmail.com> Subject: Re: ZFS boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 14:43:35 -0000 Hi List ! Happy New Year! Is already possible to boot directly from zfs ?? Regards, From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 15:02:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F19C10656C9 for ; Wed, 7 Jan 2009 15:02:11 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 197D98FC2B for ; Wed, 7 Jan 2009 15:02:10 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by fk-out-0910.google.com with SMTP id k31so5621254fkk.11 for ; Wed, 07 Jan 2009 07:02:10 -0800 (PST) Received: by 10.223.111.19 with SMTP id q19mr16530919fap.58.1231340529867; Wed, 07 Jan 2009 07:02:09 -0800 (PST) Received: by 10.223.112.75 with HTTP; Wed, 7 Jan 2009 07:02:09 -0800 (PST) Message-ID: <367b2c980901070702k161bf1a6n1315db538b68a33c@mail.gmail.com> Date: Wed, 7 Jan 2009 16:02:09 +0100 From: "Olivier SMEDTS" To: freebsd-current@freebsd.org In-Reply-To: <8e10486b0901070620x610a8156lfc1206e5262f8f5a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0901070617q2ddb82cem18b34b70c8cc45ef@mail.gmail.com> <8e10486b0901070620x610a8156lfc1206e5262f8f5a@mail.gmail.com> Cc: Alexandre Biancalana Subject: Re: ZFS boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 15:02:12 -0000 Hi ! 2009/1/7 Alexandre Biancalana : > Hi List ! Happy New Year! > > Is already possible to boot directly from zfs ?? Yes. Look at http://blogs.freebsdish.org/lulf/category/freebsd/ for a ZFS-only FreeBSD using GPT. This is for -CURRENT only. For an MBR partition table scheme, it's more complicated. I wasn't able to boot from a ZFS pool on my amd64 system, but maybe I'm doing something wrong. Look at threads on this list from late 2008, and especially the "LOADER_ZFS_SUPPORT=yes" option and how to install the zfsboot loader with dd. Happy new year :) Olivier > > Regards, > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 16:27:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF5351065670 for ; Wed, 7 Jan 2009 16:27:19 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 77E988FC18 for ; Wed, 7 Jan 2009 16:27:19 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 7BA4C130C39; Wed, 7 Jan 2009 17:27:17 +0100 (CET) Date: Wed, 7 Jan 2009 17:27:17 +0100 From: Guido Falsi To: freebsd-current@freebsd.org Message-ID: <20090107162717.GC13446@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 7.1-PRERELEASE User-Agent: Mutt/1.5.18 (2008-05-17) Subject: ZFS send core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 16:27:20 -0000 Hi, I am playing around a little with an 8.0 system on AMD64 and ZFS. Since I wanted to try out gtp booting I thought I'd make a backup of my system, repartition and restore from there. This is just a test machine, so I don't need the backup to be really safe, I thought I could try using zfs send functionality. I gave the follwing commands: zfs snapshot -r tank@test1 zfs send -vR tank@test1 > testdump to create a file I could "receive" later with all the FS data and configurations(I hope I'm getting this right, if I'm just doing something stupid, sorry for the noise). The second command simply dumped core right away. These are the last few lines from a backtrace: #0 0x000000080066d830 in zfs_prop_readonly () from /lib/libzfs.so.1 #1 0x0000000800653dda in fletcher_4_incremental_byteswap () from /lib/libzfs.so.1 #2 0x0000000800654054 in fletcher_4_incremental_byteswap () from /lib/libzfs.so.1 #3 0x00000008006548f0 in fletcher_4_incremental_byteswap () from /lib/libzfs.so.1 #4 0x000000080065833a in zfs_send () from /lib/libzfs.so.1 #5 0x00000000004069a4 in ?? () #6 0x0000000000406176 in ?? () and it goes on up to #634. I can reproduce this all the time. I don't really know if this is zfs fault or I'm simply doing something wrong. I am available to give back any more information needed, just tell me what to look for. BTW zfs send without the -R option works fine, but, as explained in the man page, just dumps one zfs, not the whole hierarchy, which was what I wanted to do. Thank you. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 16:34:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79177106566C for ; Wed, 7 Jan 2009 16:34:20 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 2886A8FC17 for ; Wed, 7 Jan 2009 16:34:19 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id F1A3E130C39; Wed, 7 Jan 2009 17:34:18 +0100 (CET) Date: Wed, 7 Jan 2009 17:34:18 +0100 From: Guido Falsi To: freebsd-current@freebsd.org Message-ID: <20090107163418.GD13446@megatron.madpilot.net> References: <20090107162717.GC13446@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090107162717.GC13446@megatron.madpilot.net> X-Operating-System: FreeBSD 7.1-PRERELEASE User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: ZFS send core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 16:34:20 -0000 On Wed, Jan 07, 2009 at 05:27:17PM +0100, Guido Falsi wrote: > The second command simply dumped core right away. Forgot one information, this is a recent current, using zfs 13. I'm also booting using the system described here: http://wiki.freebsd.org/ZFSOnRoot -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 18:07:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 689901065674 for ; Wed, 7 Jan 2009 18:07:52 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 271818FC21 for ; Wed, 7 Jan 2009 18:07:51 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from [172.16.129.134] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 88984A6771 for ; Wed, 7 Jan 2009 18:49:20 +0100 (CET) Message-ID: <4964EB20.5070709@fsn.hu> Date: Wed, 07 Jan 2009 18:49:20 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Stationery: 0.4.8.12 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Wed, 07 Jan 2009 18:49:20 +0100 (CET) Subject: pxeboot does not work on Sun X4540 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 18:07:52 -0000 Hello, I'm trying to boot FreeBSD 8-CURRENT on a Sun X4540 (2xquad core Opteron, 64 GB memory, 48 SATA disks (in fact 47, the 48th is a write optimized SSD, because this box is a 7210 OpenStorage "appliance", running OpenSolaris) on LSI controllers, nvidia NIC) from our boot server without success. The PXE on the NIC downloads pxeboot with TFTP, but then gets stuck at loading the kernel: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png pxeboot is configured to load the kernel via NFS (the default) and according to the tcpdump output, the client (X4540) issues an NFS GETPORT call and gets the response from the NFS server and then nothing else happens. I've tried with LOADER_TFTP_SUPPORT=YES and the result is the same, the only difference is that the machine stops sending packets after the first TFTP read request (for /boot/boot.4th.split), which doesn't exist, so the server sends the answer and then nothing comes back from the X4540 box. It seems that it gets to send exactly one packet, then freezes. What else should be done to debug this problem? Thanks, From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 18:51:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7834E106564A for ; Wed, 7 Jan 2009 18:51:42 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 369C68FC19 for ; Wed, 7 Jan 2009 18:51:41 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from [172.16.129.134] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 7EEE6A6925 for ; Wed, 7 Jan 2009 19:51:40 +0100 (CET) Message-ID: <4964F9BB.3020407@fsn.hu> Date: Wed, 07 Jan 2009 19:51:39 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4964EB20.5070709@fsn.hu> In-Reply-To: <4964EB20.5070709@fsn.hu> X-Stationery: 0.4.8.12 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Wed, 07 Jan 2009 19:51:40 +0100 (CET) Subject: Re: pxeboot does not work on Sun X4540 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 18:51:42 -0000 Attila Nagy wrote: > Hello, > > I'm trying to boot FreeBSD 8-CURRENT on a Sun X4540 (2xquad core > Opteron, 64 GB memory, 48 SATA disks (in fact 47, the 48th is a write > optimized SSD, because this box is a 7210 OpenStorage "appliance", > running OpenSolaris) on LSI controllers, nvidia NIC) from our boot > server without success. > > The PXE on the NIC downloads pxeboot with TFTP, but then gets stuck at > loading the kernel: > http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png > > pxeboot is configured to load the kernel via NFS (the default) and > according to the tcpdump output, the client (X4540) issues an NFS > GETPORT call and gets the response from the NFS server and then > nothing else happens. > > I've tried with LOADER_TFTP_SUPPORT=YES and the result is the same, > the only difference is that the machine stops sending packets after > the first TFTP read request (for /boot/boot.4th.split), which doesn't > exist, so the server sends the answer and then nothing comes back from > the X4540 box. > > It seems that it gets to send exactly one packet, then freezes. > > What else should be done to debug this problem? > > Thanks, BTW, the last FreeBSD 8-CURRENT snapshot from december boots fine (at least I can get to sysinstall, I haven't yet tried installation, because I wouldn't like to touch the boot drives, which house the OpenSolaris image -that's why I want to boot from the net). I would like to do a FreeBSD vs. OpenSolaris comparison on this machine, so please help. :) Thanks, From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 20:02:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B416D1065686 for ; Wed, 7 Jan 2009 20:02:19 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 967EC8FC14 for ; Wed, 7 Jan 2009 20:02:19 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n07K2JMe071169 for ; Wed, 7 Jan 2009 12:02:19 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n07K2Jpd071168 for freebsd-current@freebsd.org; Wed, 7 Jan 2009 12:02:19 -0800 (PST) (envelope-from sgk) Date: Wed, 7 Jan 2009 12:02:19 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20090107200219.GA71053@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: mount_nfs is broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 20:02:20 -0000 Someone appears to have broken mount_nfs. I rebuilt kernel and world and install it on my primary system. Everything appears be working fine. So, I then update the first node in my cluster. It reboots fine until the node tries to mount the users' home directories. The line in /etc/fstab is node10:/home /home nfs rw,noatime 0 0 Trying to manually mount /home, I find % mount_nfs 192.168.0.10:/usr/home /home mount_nfs: /usr/home, mount option is unknown: Invalid argument There are no clues in src/UPDATING concerning incompatibilities with NFS. I do not use modules. The kernels are identical on the two system and it was built with options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_LEGACYRPC The last option is only documented at http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/mount_nfs/mount_nfs.c The wonderfully fun part of this problem is that I can no longer NFS mount /usr/src from the node. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 20:43:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 035C51065673 for ; Wed, 7 Jan 2009 20:43:52 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id B776D8FC14 for ; Wed, 7 Jan 2009 20:43:51 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id D1C542394A8; Wed, 7 Jan 2009 21:43:49 +0100 (CET) Date: Wed, 7 Jan 2009 21:43:49 +0100 From: Peter Schuller To: Stefan Bethke Message-ID: <20090107204349.GA18095@hyperion.scode.org> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> <5C97E586-4296-4835-A103-FD273B2D7A4F@lassitu.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: ZFS gets stuck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 20:43:52 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > I've disabled zil on one of the two identical machines, and the one =20 > with zil still enabled keeps locking up, while the one with zil =20 > disabled keeps on running. Just wanted to add a "me three"; with CURRENT from ~ 2008-12-03, I would semi-determinstically have the machine freeze at some point during a binary package build on my desktop, and sometimes otherwise. After disabling zil, I have not suffered any crashes. By now sufficient time/builds have passed that it seems fairly likely that the change helped. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkllFAQACgkQDNor2+l1i31VyACfb0SQMd9r/nG3Ne1SiikaYMKp Q9IAoLNM/Ydns4LCRDnt+Vs+2J9Le2xN =vVOp -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 21:19:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1060) id CD1E210656C3; Wed, 7 Jan 2009 21:19:20 +0000 (UTC) Date: Wed, 7 Jan 2009 21:19:20 +0000 From: Craig Rodrigues To: Steve Kargl Message-ID: <20090107211920.GA54918@crodrigues.org> References: <20090107200219.GA71053@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090107200219.GA71053@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: mount_nfs is broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 21:19:21 -0000 On Wed, Jan 07, 2009 at 12:02:19PM -0800, Steve Kargl wrote: > mount_nfs: /usr/home, mount option is unknown: Invalid argument This error seems to indicate that your kernel is older than your mount_nfs in userland. Did you rebuild and install the new kernel? -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 21:58:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99DBC1065AD4 for ; Wed, 7 Jan 2009 21:58:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 760A78FC25 for ; Wed, 7 Jan 2009 21:58:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n07Lw8c0072243; Wed, 7 Jan 2009 13:58:08 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n07Lw8gn072242; Wed, 7 Jan 2009 13:58:08 -0800 (PST) (envelope-from sgk) Date: Wed, 7 Jan 2009 13:58:08 -0800 From: Steve Kargl To: Craig Rodrigues Message-ID: <20090107215808.GA72048@troutmask.apl.washington.edu> References: <20090107200219.GA71053@troutmask.apl.washington.edu> <20090107211920.GA54918@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090107211920.GA54918@crodrigues.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: mount_nfs is broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 21:58:16 -0000 On Wed, Jan 07, 2009 at 09:19:20PM +0000, Craig Rodrigues wrote: > On Wed, Jan 07, 2009 at 12:02:19PM -0800, Steve Kargl wrote: > > mount_nfs: /usr/home, mount option is unknown: Invalid argument > > This error seems to indicate that your kernel > is older than your mount_nfs in userland. Did you rebuild and install > the new kernel? Hmmm. Odd, I know I typed "make installkernel" twice. The timestamp of the kernel on the node is too old, so I must have installed the kernel twice on my primary system. :( Thanks for pointer. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 23:00:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A50391065736 for ; Wed, 7 Jan 2009 23:00:08 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id 78D248FC0C for ; Wed, 7 Jan 2009 23:00:08 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so11298018wfg.7 for ; Wed, 07 Jan 2009 15:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=wKuCokDIpxedBRYccppwBd2/8LEwiW1l/OQniNbPtEU=; b=OW3z6cFaMBNm1LsKZNwYkounsLFwCUh5RHy7+ZuQ1fKaia8aa8wm+g0hs1nRC3QrHt ekHhL3ezfgihJp7zGa2zGU7ipCNb0e5tIogHu64lSRDlcd0d2eUTWdbhnshachae/UHL tMkfs9jo440hLx8ht4UgucSrS4r/gDaqskhJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=hUxnM4Fop4N7wBOd4BmGqkvHKey2zmUyvp3OqZwWxYbact8eWWB+9Sh60W5Kp/nDd/ /dsB0YDuqkVA7jnmtOVt4OYVE8d9HkWrY/fPJ3nEaSRcHbfQeEjq6Hf30GmEfoEFfmzL 2KYQTG1yNrBSGG3GtLpiZH32HkfJgLKik3ZJc= Received: by 10.143.45.14 with SMTP id x14mr9845943wfj.165.1231367908843; Wed, 07 Jan 2009 14:38:28 -0800 (PST) Received: by 10.142.142.10 with HTTP; Wed, 7 Jan 2009 14:38:28 -0800 (PST) Message-ID: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> Date: Wed, 7 Jan 2009 17:38:28 -0500 From: "Kim Culhan" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: msk Marvell Yukon 88E8038 hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 23:00:11 -0000 The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. Not necessarily at each hang but sometimes coincident, this is intermittently output to the console: in_cksum_skip: out of data by 56952 The above is also output to the console at times when receiving a character through ssh to a shell. The in_cksum_skip messages and msk hangs are also present on this hardware running 7.1-RELEASE. Any help here is very greatly appreciated. regards -kim -- From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 23:14:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 532A410658C0 for ; Wed, 7 Jan 2009 23:14:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 34C958FC0A for ; Wed, 7 Jan 2009 23:14:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n07NE0cF072931; Wed, 7 Jan 2009 15:14:00 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n07NE0Zw072930; Wed, 7 Jan 2009 15:14:00 -0800 (PST) (envelope-from sgk) Date: Wed, 7 Jan 2009 15:14:00 -0800 From: Steve Kargl To: Craig Rodrigues Message-ID: <20090107231400.GA72918@troutmask.apl.washington.edu> References: <20090107200219.GA71053@troutmask.apl.washington.edu> <20090107211920.GA54918@crodrigues.org> <20090107215808.GA72048@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090107215808.GA72048@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: mount_nfs is broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 23:14:06 -0000 On Wed, Jan 07, 2009 at 01:58:08PM -0800, Steve Kargl wrote: > On Wed, Jan 07, 2009 at 09:19:20PM +0000, Craig Rodrigues wrote: > > On Wed, Jan 07, 2009 at 12:02:19PM -0800, Steve Kargl wrote: > > > mount_nfs: /usr/home, mount option is unknown: Invalid argument > > > > This error seems to indicate that your kernel > > is older than your mount_nfs in userland. Did you rebuild and install > > the new kernel? > > Hmmm. Odd, I know I typed "make installkernel" twice. > The timestamp of the kernel on the node is too old, > so I must have installed the kernel twice on my primary > system. :( > > Thanks for pointer. > Something is broken with 'make installkernel' from an NFS mounted /usr/src and /usr/obj. I just updated a 2nd node from the node's console. 'make installkernel' appeared to complete. Upon rebooting, the old kernel was still present. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 23:31:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CBBC1065670 for ; Wed, 7 Jan 2009 23:31:53 +0000 (UTC) (envelope-from joe@via.net) Received: from smtp2.via.net (smtp2.via.net [209.81.9.14]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC2E8FC1E for ; Wed, 7 Jan 2009 23:31:53 +0000 (UTC) (envelope-from joe@via.net) Received: from mail.via.net (mail.via.net [209.81.9.12]) by smtp2.via.net (8.14.1/8.12.11-VIANET) with ESMTP id n07N4etP024241 for ; Wed, 7 Jan 2009 15:04:41 -0800 (PST) Received: from [209.81.2.67] ([209.81.2.67]) by mail.via.net (8.14.1/8.12.11-VIANET) with ESMTP id n07N4Zh5028413 for ; Wed, 7 Jan 2009 15:04:38 -0800 (PST) Message-Id: From: joe mcguckin To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 7 Jan 2009 15:04:24 -0800 X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.93.3/8842/Wed Jan 7 06:06:50 2009 on smtp2.via.net X-Virus-Scanned: ClamAV 0.93.3/8842/Wed Jan 7 06:06:50 2009 on mail.via.net X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (smtp2.via.net [209.81.9.14]); Wed, 07 Jan 2009 15:04:41 -0800 (PST) Subject: Best torrent client/server available for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 23:31:54 -0000 There's quite a number of implementation in the ports collection. Does anyone have any options regarding which are the 'best'? Thanks, Joe Joe McGuckin ViaNet Communications joe@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 01:12:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 314A01065675 for ; Thu, 8 Jan 2009 01:12:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id EE18F8FC17 for ; Thu, 8 Jan 2009 01:12:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so9986277rvf.43 for ; Wed, 07 Jan 2009 17:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=XkJfbglIlOB1PfqwQKiWISXPw+y1ELMfQz0/UljRt24=; b=aX80ked4VTtzkl30ZFM/0Y+DmbBQRqJ+z7Hkks0jqh6RG+ycSLrdjcIIKZvYcucok7 uYO2fs1fSgcMAP0UnutgddStBq7V5JOgJp5guIwGZTNwTN0bmRWaifmYaupqZiAKgltP SwBgWffKAisTd3/hhPf+DlcfOsHhKAi4np6DM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=dHhjtgB2kv5FpDc511B/YC3Ejn/uUCj/LWe2UkjOk1cBhNBiEyvpvIkuYlkHsTdKjl PBhmQkbu1ce8U4u81Ggq+Ny3jZgVoiN0W1RluBxrG9Uz+xf1pKBjEruERo1J7xuFfFQt ds2LrM02WCBBYd8H8B3Bb0ClmuT4ToMqRzhO0= Received: by 10.140.161.11 with SMTP id j11mr1435124rve.162.1231377147480; Wed, 07 Jan 2009 17:12:27 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id f21sm61716213rvb.7.2009.01.07.17.12.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Jan 2009 17:12:26 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.14.3/8.14.3) with ESMTP id n081CLcg050957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 10:12:21 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.14.3/8.14.3/Submit) id n081CKxj050956; Thu, 8 Jan 2009 10:12:20 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 8 Jan 2009 10:12:20 +0900 From: Pyun YongHyeon To: Kim Culhan Message-ID: <20090108011220.GA1256@cdnetworks.co.kr> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: msk Marvell Yukon 88E8038 hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 01:12:28 -0000 On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > Not necessarily at each hang but sometimes coincident, this is > intermittently output to the console: > > in_cksum_skip: out of data by 56952 > > The above is also output to the console at times when receiving a > character through ssh > to a shell. > > The in_cksum_skip messages and msk hangs are also present on this hardware > running 7.1-RELEASE. > Would you show me dmesg output for msk(4)? -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 01:18:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C4C01065672 for ; Thu, 8 Jan 2009 01:18:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 231808FC1A for ; Thu, 8 Jan 2009 01:18:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n081I896073405; Wed, 7 Jan 2009 17:18:08 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n081I8oF073404; Wed, 7 Jan 2009 17:18:08 -0800 (PST) (envelope-from sgk) Date: Wed, 7 Jan 2009 17:18:08 -0800 From: Steve Kargl To: Craig Rodrigues Message-ID: <20090108011808.GA73377@troutmask.apl.washington.edu> References: <20090107200219.GA71053@troutmask.apl.washington.edu> <20090107211920.GA54918@crodrigues.org> <20090107215808.GA72048@troutmask.apl.washington.edu> <20090107231400.GA72918@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090107231400.GA72918@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: mount_nfs is broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 01:18:11 -0000 On Wed, Jan 07, 2009 at 03:14:00PM -0800, Steve Kargl wrote: > On Wed, Jan 07, 2009 at 01:58:08PM -0800, Steve Kargl wrote: > > On Wed, Jan 07, 2009 at 09:19:20PM +0000, Craig Rodrigues wrote: > > > On Wed, Jan 07, 2009 at 12:02:19PM -0800, Steve Kargl wrote: > > > > mount_nfs: /usr/home, mount option is unknown: Invalid argument > > > > > > This error seems to indicate that your kernel > > > is older than your mount_nfs in userland. Did you rebuild and install > > > the new kernel? > > > > Hmmm. Odd, I know I typed "make installkernel" twice. > > The timestamp of the kernel on the node is too old, > > so I must have installed the kernel twice on my primary > > system. :( > > > > Thanks for pointer. > > > > Something is broken with 'make installkernel' from an > NFS mounted /usr/src and /usr/obj. > > I just updated a 2nd node from the node's console. > 'make installkernel' appeared to complete. Upon > rebooting, the old kernel was still present. > Yes, I'm monologuing. Pilot error. I had KERNCONF pointing at an experimental kernel from early October, so kernel and world were out of sync. Sorry about the noise. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 02:04:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D844106566B for ; Thu, 8 Jan 2009 02:04:36 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id A38FC8FC1F for ; Thu, 8 Jan 2009 02:04:35 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so1446504ugs.39 for ; Wed, 07 Jan 2009 18:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=HxMkqGgVwP+ujpdH3hQyrm6J7nqCuHT0pB/xvUsuXP0=; b=N3G18C+jIG3LkOwC308YTcqhwliQt9h700tGSoHeu8TcEu+kF9Ac2Fw4tqQIYXNRi+ mFso3mprOegS58baPBZWY7T3EcJsssdlGtY/YRZPLAg3npGTr8NPzGTCmrihf1zb3SXO PaQhB8ys4bHK0A3kebPdAKV6jXSdzb7CkyhMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DkkIFLPmeivhKBfL6cQmpnSWLkla5gFovkSZWOyrlWMzRZBpaxl8gyARB67BPYFnSu aZeVp92Pghl4ZkymY8oNdZQqfciq04Yy/tkuVM6hrNTBiBTJvOqEqyOfaWZsr81fgipc HWlhUgg0w/c+9PIuG1Q3x/fIqsiTHrH/nmg5M= Received: by 10.67.115.14 with SMTP id s14mr14264788ugm.57.1231380274595; Wed, 07 Jan 2009 18:04:34 -0800 (PST) Received: by 10.67.88.9 with HTTP; Wed, 7 Jan 2009 18:04:34 -0800 (PST) Message-ID: <7d6fde3d0901071804q546c5e5fk332904064d772821@mail.gmail.com> Date: Wed, 7 Jan 2009 18:04:34 -0800 From: "Garrett Cooper" To: "joe mcguckin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: Best torrent client/server available for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 02:04:36 -0000 On Wed, Jan 7, 2009 at 3:04 PM, joe mcguckin wrote: > There's quite a number of implementation in the ports collection. Does > anyone have any options regarding which are the 'best'? > > Thanks, > > Joe > > > Joe McGuckin > ViaNet Communications > > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax I haven't really run across a best in Unix (I personally prefer utorrent -- a Windows torrent client -- but the author refuses to opensource it ;(..), but if memory/CPU isn't so much of an issue (it uses Java), I suggest net-p2p/azureus. -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 02:36:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37A29106566C for ; Thu, 8 Jan 2009 02:36:16 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id DF25F8FC14 for ; Thu, 8 Jan 2009 02:36:15 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so5086109qwb.7 for ; Wed, 07 Jan 2009 18:36:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=WTciu4LxbKPrVVelLR8QHPusn4jPzkJXRKj3cPqBQzs=; b=OtO2pmlKrn/EEsQrlh5gT82ueOd+/gWTgCjrSZD70ag1fULL0ghHsnf3qcFsUmAazl mZtLpuzBrKMOuvBkEGppOcvnJ75Z0tiQj8awgiP0zrMBQ2Gk6u8HWNOwEuus9NCzPZLu FNvzbDx2tQrtzEIPqKLJKWHWBrkeGiH6GvVj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Mt4HcU0X5LbqyllXBghO14uFriPrWlYdq0dmnTbApM3whP4BBA/zHvVFuTQ5eFgWKb g8/g+dCr6eT6HVWA0pHWhy/UJn/IXVx7Vfzie5FnJKPEyL9hPlCWPI58jDa1p9rU01o+ WQZzzmirqvdD4q2/0Eb4H7R6UYwo1SuxYD80k= Received: by 10.214.26.2 with SMTP id 2mr20695607qaz.89.1231380618518; Wed, 07 Jan 2009 18:10:18 -0800 (PST) Received: by 10.214.181.6 with HTTP; Wed, 7 Jan 2009 18:10:18 -0800 (PST) Message-ID: <4d7dd86f0901071810o65e0bf32m196f120bd0e5748c@mail.gmail.com> Date: Thu, 8 Jan 2009 13:10:18 +1100 From: "David N" To: "joe mcguckin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: Best torrent client/server available for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 02:36:16 -0000 2009/1/8 joe mcguckin : > There's quite a number of implementation in the ports collection. Does > anyone have any options regarding which are the 'best'? > > Thanks, > > Joe > > > Joe McGuckin > ViaNet Communications > > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax I use transmission daemon + transmission web. You can control it via command line or web interface. Regards David N From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 05:43:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA42C106564A for ; Thu, 8 Jan 2009 05:43:28 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 90E0F8FC17 for ; Thu, 8 Jan 2009 05:43:28 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.123.2.23] (p53.kientzle.com [66.166.149.53]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n085hRtv048584 for ; Wed, 7 Jan 2009 21:43:27 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <4965927D.1060507@freebsd.org> Date: Wed, 07 Jan 2009 21:43:25 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'freebsd-current@freebsd.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Extattr portability? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 05:43:29 -0000 I'm trying to complete the extended attribute support in libarchive. There are a handful of odd issues that arise which I think I could resolve if I knew of good use cases. Anyone here actually use extended attributes? (Note that ACLs are handled separately.) What software? What information do you store there? If you could benefit from being able to move extended attributes between FreeBSD and other systems, I'm especially interested. Cheers, Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 07:16:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87BBA106566C for ; Thu, 8 Jan 2009 07:16:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 40F288FC12 for ; Thu, 8 Jan 2009 07:16:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LKoYw-000A3a-7s; Thu, 08 Jan 2009 08:40:14 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Attila Nagy In-reply-to: <4964F9BB.3020407@fsn.hu> References: <4964EB20.5070709@fsn.hu> <4964F9BB.3020407@fsn.hu> Comments: In-reply-to Attila Nagy message dated "Wed, 07 Jan 2009 19:51:39 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Jan 2009 08:40:14 +0200 From: Danny Braniss Message-ID: Cc: freebsd-current@freebsd.org Subject: Re: pxeboot does not work on Sun X4540 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 07:16:35 -0000 > Attila Nagy wrote: > > Hello, > > > > I'm trying to boot FreeBSD 8-CURRENT on a Sun X4540 (2xquad core > > Opteron, 64 GB memory, 48 SATA disks (in fact 47, the 48th is a write > > optimized SSD, because this box is a 7210 OpenStorage "appliance", > > running OpenSolaris) on LSI controllers, nvidia NIC) from our boot > > server without success. > > > > The PXE on the NIC downloads pxeboot with TFTP, but then gets stuck at > > loading the kernel: > > http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png > > > > pxeboot is configured to load the kernel via NFS (the default) and > > according to the tcpdump output, the client (X4540) issues an NFS > > GETPORT call and gets the response from the NFS server and then > > nothing else happens. > > > > I've tried with LOADER_TFTP_SUPPORT=YES and the result is the same, > > the only difference is that the machine stops sending packets after > > the first TFTP read request (for /boot/boot.4th.split), which doesn't > > exist, so the server sends the answer and then nothing comes back from > > the X4540 box. > > > > It seems that it gets to send exactly one packet, then freezes. > > > > What else should be done to debug this problem? > > > > Thanks, > BTW, the last FreeBSD 8-CURRENT snapshot from december boots fine (at > least I can get to sysinstall, I haven't yet tried installation, because > I wouldn't like to touch the boot drives, which house the OpenSolaris > image -that's why I want to boot from the net). > older pxeboot - pre interrupt handling fixes - work ok, so you can use that instead. danny > I would like to do a FreeBSD vs. OpenSolaris comparison on this machine, > so please help. :) > > Thanks, > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 07:36:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AB09106566B for ; Thu, 8 Jan 2009 07:36:49 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id 4E14B8FC08 for ; Thu, 8 Jan 2009 07:36:49 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so11510128wfg.7 for ; Wed, 07 Jan 2009 23:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=BDNYqzflMt0stMenIbEq9CBBkStGP9oIKZnxnSU9omI=; b=Xyk1NTtUaixchMw0oJBHny32VrDOb7XIKsHIhUmgRUH8Scs1/dApZO4ExXFxF0KdjU FxgI9V4aZU9c7fsLApN0XYXyyNVKTQuL2rPTFo9XiSb46Rx1yz1VfppQ4EPWfU/7Akvc Tx9c0KuQlCjAsLeE4fSIfTLttRZrzN3XmuS3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=N7D4yJ1j7uKrQdUDWNwdhRBrkE1w04Q0HvbQyKURyU4XCHBQg65OzMaNb5D32+2LOS maAEvm9NLSLWBxM9Rw+YhpCqeglqojPpME+IOtQOafKeV1NucsFEXwt4YYE9ImymVLA/ oJ/+Oahm47gC/3UtA1t4M4T5P9wLVXrCSyhjI= Received: by 10.142.79.14 with SMTP id c14mr10035759wfb.346.1231400209017; Wed, 07 Jan 2009 23:36:49 -0800 (PST) Received: by 10.142.142.10 with HTTP; Wed, 7 Jan 2009 23:36:48 -0800 (PST) Message-ID: <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> Date: Thu, 8 Jan 2009 02:36:48 -0500 From: "Kim Culhan" To: pyunyh@gmail.com In-Reply-To: <20090108011220.GA1256@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> Cc: freebsd-current@freebsd.org Subject: Re: msk Marvell Yukon 88E8038 hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 07:36:49 -0000 On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > Not necessarily at each hang but sometimes coincident, this is > > intermittently output to the console: > > > > in_cksum_skip: out of data by 56952 > > > > The above is also output to the console at times when receiving a > > character through ssh > > to a shell. > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > running 7.1-RELEASE. > > > > Would you show me dmesg output for msk(4)? dmesg: mskc0: port 0x2000-0x20ff mem 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:1b:24:59:5b:7a miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto mskc0: [FILTER] -kim From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 07:49:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E617106567F for ; Thu, 8 Jan 2009 07:49:27 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id E5E068FC26 for ; Thu, 8 Jan 2009 07:49:26 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so1457252ugs.39 for ; Wed, 07 Jan 2009 23:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=5OukikFinzgRaqUeaqXFnWWe3vAujmqVygen5vtFfwM=; b=Y/8u2ssVhW+1pXAX2JhDo9xakmwNsWvKYI7ceNS1F6fchoooYHJQ98pfi521cYoJF4 hnPZJJBW5DA3lTduXs9ZFkpjm7DVQTb/zPJH/XpL/Dxs8jQQJAW/Bg30Qwl8DyTktJad JD7Hpc40Kk+WF0y98ZhsaWM8qJsdkmRkGsmFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=Hhe+8pcnRR1Lmr6Tx2kQd3xmrGQDvxIiKpD6ulcQoYDX/lUOuio9nkfkCnfuqxC+LL CcUtULFDpfgRJ+mMsEKTNH0ymTLY4aoNuDzb9Vfh2e1IaWGEWlA810VdHSK5YRgFUizM /1d7Fr+ZPixk3rMoPwcgdqRIF+TiM1f41Rr5A= Received: by 10.67.87.11 with SMTP id p11mr14379638ugl.32.1231400966074; Wed, 07 Jan 2009 23:49:26 -0800 (PST) Received: by 10.67.88.9 with HTTP; Wed, 7 Jan 2009 23:49:26 -0800 (PST) Message-ID: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> Date: Wed, 7 Jan 2009 23:49:26 -0800 From: "Garrett Cooper" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 07:49:27 -0000 Hello folks, As many probably know, I recently installed FreeBSD 8-CURRENT on my desktop. One of the things I'm noting is that when I use dual displays with the nvidia driver, and xscreensaver kicks in and keeps going for a period of time, the machine's X.org console eats up a core, and when I try and do anything like gdb Xorg, the system hangs, attempts to panic (I assume that's the case because I hear it beep and attempt to restart), then I have to give it a warm boot. truss(1)'ing Xorg showed that there were a lot of SIGALARM's being fired and masked. This is incredibly reminiscent of the days when I used to run Linux and I forgot to configure my dump device (doh), but this problem appears to be easily reproducible with my environment. I'm fixing that issue right now, so I should have a working crashdump soon... Just wondering if anyone else has seen this issue, or if it's just me once again. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 07:52:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89D7A1065673 for ; Thu, 8 Jan 2009 07:52:07 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id 5008F8FC23 for ; Thu, 8 Jan 2009 07:52:07 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so11515364wfg.7 for ; Wed, 07 Jan 2009 23:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=7VQ+yz6u/u9VBGsBxOwOGHdlSIOIJY3GYTE+m8nfql8=; b=dQmGC1CNWWAgcY+8DBnQhaigRr/LJUaJ1qkb117Bf6+PbdQ6UTMuupWFV+tUBXk3vB Y1e+PsAOYJtedteyNmM3/7HLM3SpT7XLYDmKsHUNnAY+sBcpBrAFeWD7D/Mj9AEQA7De vfPMffBnrFmdcyFj4x2QAchpmhSJvxnL7T0n8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=De4QE0h4/nlD1Dp4YqRLW0mYhAC0TDPzlpXU7h4JvyvfpuFITHbvfqnva5oDxDJre2 JySRtfRNtZBq83uHSV033TnJTnnmCJf/Nh4dPM7Y/kQebInuETVLuSdoS1/hBRO+gyNT g0UaV1EdzIwH0hExGr2kQKuvJOPFYbSW58JNc= Received: by 10.143.159.11 with SMTP id l11mr7594365wfo.143.1231401127058; Wed, 07 Jan 2009 23:52:07 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id 28sm444436wfg.28.2009.01.07.23.52.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Jan 2009 23:52:06 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.14.3/8.14.3) with ESMTP id n087q0id027708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 16:52:00 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.14.3/8.14.3/Submit) id n087pxtZ027707; Thu, 8 Jan 2009 16:51:59 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 8 Jan 2009 16:51:59 +0900 From: Pyun YongHyeon To: Kim Culhan Message-ID: <20090108075159.GH1256@cdnetworks.co.kr> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: msk Marvell Yukon 88E8038 hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 07:52:08 -0000 On Thu, Jan 08, 2009 at 02:36:48AM -0500, Kim Culhan wrote: > On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > > > Not necessarily at each hang but sometimes coincident, this is > > > intermittently output to the console: > > > > > > in_cksum_skip: out of data by 56952 > > > > > > The above is also output to the console at times when receiving a > > > character through ssh > > > to a shell. > > > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > > running 7.1-RELEASE. > > > > > > > Would you show me dmesg output for msk(4)? > > dmesg: > > mskc0: port 0x2000-0x20ff mem > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 > msk0: on mskc0 > msk0: Ethernet address: 00:1b:24:59:5b:7a > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > mskc0: [FILTER] > Would you try changes made in r183485(CVS if_msk.c, 1.33)? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/msk/if_msk.c.diff?r1=1.32;r2=1.33;f=h -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 08:55:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FE90106564A for ; Thu, 8 Jan 2009 08:55:53 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1987C8FC13 for ; Thu, 8 Jan 2009 08:55:53 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 823209CB1BA; Thu, 8 Jan 2009 09:36:48 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng47Wp0N3Mal; Thu, 8 Jan 2009 09:36:46 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E5A239CB22D; Thu, 8 Jan 2009 09:36:45 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n088ajcG056931; Thu, 8 Jan 2009 09:36:45 +0100 (CET) (envelope-from rdivacky) Date: Thu, 8 Jan 2009 09:36:45 +0100 From: Roman Divacky To: Garrett Cooper Message-ID: <20090108083645.GA56613@freebsd.org> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 08:55:53 -0000 On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: > Hello folks, > As many probably know, I recently installed FreeBSD 8-CURRENT on my desktop. > One of the things I'm noting is that when I use dual displays with > the nvidia driver, and xscreensaver kicks in and keeps going for a > period of time, the machine's X.org console eats up a core, and when I > try and do anything like gdb Xorg, the system hangs, attempts to panic > (I assume that's the case because I hear it beep and attempt to > restart), then I have to give it a warm boot. truss(1)'ing Xorg showed > that there were a lot of SIGALARM's being fired and masked. > This is incredibly reminiscent of the days when I used to run Linux and > I forgot to configure my dump device (doh), but this problem appears > to be easily reproducible with my environment. I'm fixing that issue > right now, so I should have a working crashdump soon... > Just wondering if anyone else has seen this issue, or if it's just me > once again. > Thanks, the nvidia driver keeps my 8-current crashing/deadlocking when playing video quite often (once a week?). I have no idea what it causes. the code of the driver seems to be done in 5.x times. I believe it needs some rehashing as it might not get the semantics of "things" in 8.x right From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 09:34:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12319106566B; Thu, 8 Jan 2009 09:34:36 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id DC6B18FC0C; Thu, 8 Jan 2009 09:34:35 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout2.cac.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id n089YZha005806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Jan 2009 01:34:35 -0800 X-Auth-Received: from [192.168.10.7] (adsl-99-133-163-225.dsl.pltn13.sbcglobal.net [99.133.163.225]) (authenticated authid=youshi10) by smtp.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id n089YY97030565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 8 Jan 2009 01:34:34 -0800 Message-Id: <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> From: Garrett Cooper To: Roman Divacky In-Reply-To: <20090108083645.GA56613@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 8 Jan 2009 01:39:04 -0800 References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> X-Mailer: Apple Mail (2.930.3) X-PMX-Version: 5.5.0.356843, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.1.8.91633 X-Uwash-Spam: Gauge=IIIIIII, Probability=8%, Report='FORGED_FROM_GMAIL 0.1, BODY_SIZE_1700_1799 0, BODY_SIZE_5000_LESS 0, __BOUNCE_CHALLENGE_SUBJ 0, __CP_MEDIA_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_WEBMAIL 0, __FRAUD_419_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 09:34:37 -0000 On Jan 8, 2009, at 12:36 AM, Roman Divacky wrote: > On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: >> Hello folks, >> As many probably know, I recently installed FreeBSD 8-CURRENT on >> my desktop. >> One of the things I'm noting is that when I use dual displays with >> the nvidia driver, and xscreensaver kicks in and keeps going for a >> period of time, the machine's X.org console eats up a core, and >> when I >> try and do anything like gdb Xorg, the system hangs, attempts to >> panic >> (I assume that's the case because I hear it beep and attempt to >> restart), then I have to give it a warm boot. truss(1)'ing Xorg >> showed >> that there were a lot of SIGALARM's being fired and masked. >> This is incredibly reminiscent of the days when I used to >> run Linux and >> I forgot to configure my dump device (doh), but this problem appears >> to be easily reproducible with my environment. I'm fixing that issue >> right now, so I should have a working crashdump soon... >> Just wondering if anyone else has seen this issue, or if it's just >> me >> once again. >> Thanks, > > the nvidia driver keeps my 8-current crashing/deadlocking when > playing video > quite often (once a week?). I have no idea what it causes. > > the code of the driver seems to be done in 5.x times. I believe it > needs > some rehashing as it might not get the semantics of "things" in 8.x > right Hey Roman! Yeah, I'm fine with it being slow, for a little while, as long as it's functional... I do realize that nvidia is still giant locked (ew..), so it might be some nasty resource contention. Are you using Linux emulation support with the driver? Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 09:42:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64708106566C for ; Thu, 8 Jan 2009 09:42:23 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1CCFB8FC1F for ; Thu, 8 Jan 2009 09:42:22 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 3D89D9CB159; Thu, 8 Jan 2009 10:42:14 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQbxIht-8UOa; Thu, 8 Jan 2009 10:42:02 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 83FC19CB22D; Thu, 8 Jan 2009 10:42:02 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n089g2wx083963; Thu, 8 Jan 2009 10:42:02 +0100 (CET) (envelope-from rdivacky) Date: Thu, 8 Jan 2009 10:42:02 +0100 From: Roman Divacky To: Garrett Cooper Message-ID: <20090108094202.GA83183@freebsd.org> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 09:42:23 -0000 On Thu, Jan 08, 2009 at 01:39:04AM -0800, Garrett Cooper wrote: > On Jan 8, 2009, at 12:36 AM, Roman Divacky wrote: > > >On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: > >>Hello folks, > >> As many probably know, I recently installed FreeBSD 8-CURRENT on > >>my desktop. > >> One of the things I'm noting is that when I use dual displays with > >>the nvidia driver, and xscreensaver kicks in and keeps going for a > >>period of time, the machine's X.org console eats up a core, and > >>when I > >>try and do anything like gdb Xorg, the system hangs, attempts to > >>panic > >>(I assume that's the case because I hear it beep and attempt to > >>restart), then I have to give it a warm boot. truss(1)'ing Xorg > >>showed > >>that there were a lot of SIGALARM's being fired and masked. > >> This is incredibly reminiscent of the days when I used to > >>run Linux and > >> I forgot to configure my dump device (doh), but this problem appears > >>to be easily reproducible with my environment. I'm fixing that issue > >>right now, so I should have a working crashdump soon... > >> Just wondering if anyone else has seen this issue, or if it's just > >>me > >>once again. > >>Thanks, > > > >the nvidia driver keeps my 8-current crashing/deadlocking when > >playing video > >quite often (once a week?). I have no idea what it causes. > > > >the code of the driver seems to be done in 5.x times. I believe it > >needs > >some rehashing as it might not get the semantics of "things" in 8.x > >right > > > Hey Roman! > Yeah, I'm fine with it being slow, for a little while, as long as > it's functional... I do realize that nvidia is still giant locked I didnt mean it being Giant locked. it's just that some semantic might have changed since 5.x and the driver does not reflect that > (ew..), so it might be some nasty resource contention. > Are you using Linux emulation support with the driver? no.... From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 11:16:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9585106568F for ; Thu, 8 Jan 2009 11:16:16 +0000 (UTC) (envelope-from christof.schulze@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id EA6628FC17 for ; Thu, 8 Jan 2009 11:16:15 +0000 (UTC) (envelope-from christof.schulze@gmx.net) Received: (qmail invoked by alias); 08 Jan 2009 11:16:13 -0000 Received: from dslb-088-075-231-081.pools.arcor-ip.net (EHLO eri.localnet) [88.75.231.81] by mail.gmx.net (mp024) with SMTP; 08 Jan 2009 12:16:13 +0100 X-Authenticated: #3549759 X-Provags-ID: V01U2FsdGVkX1/wKUMHQKzweUlWdzr+k+45cE8L4c7kYrfSn6qvqy E/T4hOiF4ZsKGm From: Christof Schulze To: freebsd-current@freebsd.org Date: Thu, 8 Jan 2009 12:16:00 +0100 User-Agent: KMail/1.10.1 (FreeBSD/7.1-BETA2; KDE/4.1.1; i386; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart18948688.M8lSHFoigc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200901081216.07107.christof.schulze@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: Re: Best torrent client/server available for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 11:16:17 -0000 --nextPart18948688.M8lSHFoigc Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Donnerstag 08 Januar 2009 00:04:24 schrieb joe mcguckin: > There's quite a number of implementation in the ports collection. Does > anyone have any options regarding which are the 'best'? Azureus is a good client except for: * high cpou/mem usage * does not work in Freebsd 7.X - not sure about 8 because it will not get=20 any connections so I use trackerbt as a tracker and ktorrent as a client. Christof --nextPart18948688.M8lSHFoigc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkll4HcACgkQpZfyPAmdZJkpXACgt5F3tkVTqXHAL4TXJHTEtzd0 1P8AmwbOeMnRj0O1yZ26Tzr7WXHGFoLA =+28N -----END PGP SIGNATURE----- --nextPart18948688.M8lSHFoigc-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 11:29:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8E8C1065670 for ; Thu, 8 Jan 2009 11:29:19 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 422678FC1E for ; Thu, 8 Jan 2009 11:29:19 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 1E0211CCA7; Thu, 8 Jan 2009 12:29:18 +0100 (CET) Date: Thu, 8 Jan 2009 12:29:18 +0100 From: Ed Schouten To: joe mcguckin Message-ID: <20090108112918.GK45775@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Jl+DbTnyraiZ/loT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: Best torrent client/server available for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 11:29:19 -0000 --Jl+DbTnyraiZ/loT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Joe, * joe mcguckin wrote: > There's quite a number of implementation in the ports collection. Does = =20 > anyone have any options regarding which are the 'best'? Have you tried net-p2p/rtorrent? Works pretty well. It's a terminal application, which makes it easy to run in screen(1), for example. --=20 Ed Schouten WWW: http://80386.nl/ --Jl+DbTnyraiZ/loT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkll444ACgkQ52SDGA2eCwXz9ACeNXz4dqWlQq1YVDrDG3cKf4hQ RggAn3OmQvQibbTvYn8TTNsJBEQ6tXSp =a0pQ -----END PGP SIGNATURE----- --Jl+DbTnyraiZ/loT-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 11:31:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A1A4106566C for ; Thu, 8 Jan 2009 11:31:35 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id A15A38FC0C for ; Thu, 8 Jan 2009 11:31:34 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.37,233,1231110000"; d="scan'208";a="208520621" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 08 Jan 2009 12:31:32 +0100 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id E7AF21B07DD; Thu, 8 Jan 2009 12:31:32 +0100 (CET) Date: Thu, 08 Jan 2009 12:31:32 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: mouse cursor corrupts chars under syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 11:31:35 -0000 hi there, i noticed the mouse cursor currupting characters under syscons. to test this do the following under syscons/bash: for i in `jot 5000`; do echo -n 0; done now gently move your cursor over the zeros. see? alex From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 11:42:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FDD2106564A for ; Thu, 8 Jan 2009 11:42:44 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 01C7D8FC0C for ; Thu, 8 Jan 2009 11:42:44 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 5A0531CCA7; Thu, 8 Jan 2009 12:42:43 +0100 (CET) Date: Thu, 8 Jan 2009 12:42:43 +0100 From: Ed Schouten To: Alexander Best Message-ID: <20090108114243.GL45775@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ybNbZnZ8tziJ7D6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: mouse cursor corrupts chars under syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 11:42:44 -0000 --4ybNbZnZ8tziJ7D6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Alexander, * Alexander Best wrote: > i noticed the mouse cursor currupting characters under syscons. to test t= his > do the following under syscons/bash: >=20 > for i in `jot 5000`; do echo -n 0; done >=20 > now gently move your cursor over the zeros. see? Just a message to the lists, to make sure it doesn't end up assigned to me. This issue is not in any way related to the libteken commit I did a week ago, but I also noticed this issue back in June last year. At first I thought it was related to the new MPSAFE TTY layer, but I can remember seeing this on stock sources as well. I think we should see whether it is also present on other architectures supported by syscons. I think it might be a syscons VGA renderer issue. --=20 Ed Schouten WWW: http://80386.nl/ --4ybNbZnZ8tziJ7D6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkll5rMACgkQ52SDGA2eCwWU6ACeIrUBHrVkOc7tQlyLvB1EuSpZ xvwAni1VeUjEjifJ/0zw2YFWJ/XOeFoO =chjB -----END PGP SIGNATURE----- --4ybNbZnZ8tziJ7D6-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 12:39:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87A511065670 for ; Thu, 8 Jan 2009 12:39:49 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 59BF38FC1C for ; Thu, 8 Jan 2009 12:39:49 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by rv-out-0506.google.com with SMTP id b25so10224425rvf.43 for ; Thu, 08 Jan 2009 04:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=G/9M7LrX9QMZCQE3zOEQ1qMsqqkr4hJCtUsNzs539YE=; b=GiUpPBJFpChIE4zGmvEcZ9/1womJLigBAegx6ImIZua3f871PNrQUq+Lf/WrFk2lrs 5KIzCnIANRhmonknIUFA9wr4CuCAa9bmijCZwovH5eYFuXvjDY2oHnNh51rDXH01uPOk GZ5YdkoiJGFdAA6Q2rACSs+t2rnaJ5T5Z/ftM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ommGlY8E4qGOKwA5wKxXhkLKcTRNssF+Z5nn2fnt4oIdbJ+7oZmVlhdNK3POAmgghj M2nMcbc/w0MRzWQDEo7jVm1jC6iva/iErLPnKpmZsc1j5aYwXzlAWajtKQQvNV2WTII2 G/qwjwMIWjqCglJ/iMiY9aMp5qKi7/aRkhZtM= Received: by 10.141.53.4 with SMTP id f4mr12106767rvk.155.1231418389024; Thu, 08 Jan 2009 04:39:49 -0800 (PST) Received: by 10.140.161.15 with HTTP; Thu, 8 Jan 2009 04:39:48 -0800 (PST) Message-ID: <90a5caac0901080439h14aa7c6au59a754ce9c0fdf5c@mail.gmail.com> Date: Thu, 8 Jan 2009 13:39:48 +0100 From: "Lucius Windschuh" To: freebsd-current@freebsd.org In-Reply-To: <4d7dd86f0901071810o65e0bf32m196f120bd0e5748c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d7dd86f0901071810o65e0bf32m196f120bd0e5748c@mail.gmail.com> Subject: Re: Best torrent client/server available for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 12:39:50 -0000 2009/1/8 David N : > > I use transmission daemon + transmission web. > You can control it via command line or web interface. transmission is a nice, small client, but be aware that it performs poorly on torrents with many files / many torrents. It uses a hard-coded number of open files: 16. Not more. So, transmission gives you a nice system load by opening and closing many files per second (and the only thing you can do is change the source code :-D) with torrents containing many files. That's why I second Ed and suggest net-p2p/rtorrent. rtorrent hashes files slowly because it uses mmap for this and counts on the kernel to behave like Linux does, but FreeBSD doesn't: On Linux, madvise(..., MADV_WILLNEED) will preload a page, and seemingly, FreeBSD has a different behaviour. That's the simple reason. Nonetheless, rtorrent is small and very efficient. Lucius From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 13:03:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40472106564A for ; Thu, 8 Jan 2009 13:03:10 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 856F18FC16 for ; Thu, 8 Jan 2009 13:03:09 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 08 Jan 2009 12:36:28 -0000 Received: from p54A3E282.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.226.130] by mail.gmx.net (mp070) with SMTP; 08 Jan 2009 13:36:28 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/gghQVm/zgNrA4YP9N97rKqOE4O5GI2W9aY9ngoQ xpSwdIK1YDm76J Message-ID: <4965F348.90407@gmx.de> Date: Thu, 08 Jan 2009 13:36:24 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Cc: freebsd-current@freebsd.org Subject: Re: mouse cursor corrupts chars under syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 13:03:10 -0000 Alexander Best schrieb: > i noticed the mouse cursor currupting characters under syscons. to test this > do the following under syscons/bash: > > for i in `jot 5000`; do echo -n 0; done > > now gently move your cursor over the zeros. see? What do you mean? When moving the mouse cursor down then its bottom suddenly pops up in a row when it already should be several pixels in that row? From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 13:05:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22A6410656CF for ; Thu, 8 Jan 2009 13:05:58 +0000 (UTC) (envelope-from dam@c-mal.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id 05E9B8FC1D for ; Thu, 8 Jan 2009 13:05:57 +0000 (UTC) (envelope-from dam@c-mal.com) Received: by wf-out-1314.google.com with SMTP id 24so11626258wfg.7 for ; Thu, 08 Jan 2009 05:05:57 -0800 (PST) Received: by 10.142.50.15 with SMTP id x15mr1591260wfx.280.1231418226150; Thu, 08 Jan 2009 04:37:06 -0800 (PST) Received: by 10.142.215.4 with HTTP; Thu, 8 Jan 2009 04:37:06 -0800 (PST) Message-ID: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> Date: Thu, 8 Jan 2009 13:37:06 +0100 From: "Damien Fleuriot" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Bug or unwanted behaviour in echo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 13:05:58 -0000 Hello list, First of all, my apologies if this issue was already raised and discussed, I haven't found it so far. I was toying around with a site that proposed to hash passwords to MD5, and comparing results with my host running FreeBSD 7.0-STABLE At some point I didn't get the same hash from the website and from BSD. On BSD: echo -n "test'$@" | md5 5c28a8c6d799d302f3ef53afefdfc81b On website: f883cdacbb478c241c51da1f67fbe9bf After swapping characters around I realized that echo just interprets $@ (which in our case is null). So I tried escaping the @ which didn't work: echo -n "test'$\@" | md5 cff4781da603112b5a271891c7c9cc47 Escaping the $ did work however: echo -n "test'\$@" | md5 f883cdacbb478c241c51da1f67fbe9bf I can not think of a concrete example at the moment, but I can imagine a program creating a hash and inadvertently feeding md5 a string containing $? , $@ , $# or $1 for example. This could lead to unwanted results. Anyone knows if this behaviour is intended ? It sure confused me here. Perhaps a switch should be added to tell echo to not parse the $variables ? Or perhaps it should be the natural behaviour to not parse them, and only do it if -e was given ? Regards, From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 13:15:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08B971065670 for ; Thu, 8 Jan 2009 13:15:34 +0000 (UTC) (envelope-from jelte@NLnetLabs.nl) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 916FF8FC16 for ; Thu, 8 Jan 2009 13:15:33 +0000 (UTC) (envelope-from jelte@NLnetLabs.nl) Received: from mirre.nlnetlabs.nl (mirre.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:fe0b:89f4]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n08DFP6M094924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 14:15:25 +0100 (CET) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4965FC6D.5090403@NLnetLabs.nl> Date: Thu, 08 Jan 2009 14:15:25 +0100 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Damien Fleuriot References: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> In-Reply-To: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 08 Jan 2009 14:15:25 +0100 (CET) X-Spam-Status: No, score=-100.0 required=5.0 tests=NO_RELAYS, USER_IN_WHITELIST autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on open.nlnetlabs.nl Cc: freebsd-current@freebsd.org Subject: Re: Bug or unwanted behaviour in echo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 13:15:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Damien Fleuriot wrote: > > After swapping characters around I realized that echo just interprets > $@ (which in our case is null). > that's your shell doing the replacement, not echo. With most most shells you can inhibit this behaviour by using single quotes. Escaping the @ should work in some cases too. $ echo "abc$@" abc $ echo 'abc$@' abc$@ Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkll/G0ACgkQ4nZCKsdOncUSSQCeJuQZi1h+TrKNyxpHmu6hjykO +mAAnjKGHk76zsyTwwaahKbFWHQvjf1E =wJHv -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 13:49:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5BD4106564A for ; Thu, 8 Jan 2009 13:49:16 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id B6ACE8FC16 for ; Thu, 8 Jan 2009 13:49:16 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id n08DM20Q084728; Thu, 8 Jan 2009 05:22:02 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id n08DM2EK084727; Thu, 8 Jan 2009 05:22:02 -0800 (PST) (envelope-from david) Date: Thu, 8 Jan 2009 05:22:02 -0800 From: David Wolfskill To: Damien Fleuriot Message-ID: <20090108132202.GD64787@albert.catwhisker.org> References: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ruyc9IU5x/hZJuxv" Content-Disposition: inline In-Reply-To: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Bug or unwanted behaviour in echo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 13:49:17 -0000 --Ruyc9IU5x/hZJuxv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 08, 2009 at 01:37:06PM +0100, Damien Fleuriot wrote: > ... > I was toying around with a site that proposed to hash passwords to > MD5, and comparing results with my host running FreeBSD 7.0-STABLE >=20 > At some point I didn't get the same hash from the website and from BSD. >=20 > On BSD: > echo -n "test'$@" | md5 > 5c28a8c6d799d302f3ef53afefdfc81b >=20 > On website: > f883cdacbb478c241c51da1f67fbe9bf >=20 > After swapping characters around I realized that echo just interprets > $@ (which in our case is null). Errr... no, I think you will find that what echo saw was actually a string whose md5 hash was "5c28a8c6d799d302f3ef53afefdfc81b". The "$@" was seen as a token by the shell, its value interpolated, and passed along to echo (which may well have been a shell builtin in any case, depending on what shell you were using). That's what escaping the "$" worked. > ...=20 Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Ruyc9IU5x/hZJuxv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkll/fkACgkQmprOCmdXAD3qSgCghhyCVHC95+6T1i06PqJXfL9D iO4AmgKDJDu7rrOJoqwY8nN9yV6NcXex =QvE5 -----END PGP SIGNATURE----- --Ruyc9IU5x/hZJuxv-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 13:34:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60F9A106568C for ; Thu, 8 Jan 2009 13:34:33 +0000 (UTC) (envelope-from rnoland@2hip.net) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 26EBE8FC0A for ; Thu, 8 Jan 2009 13:34:32 +0000 (UTC) (envelope-from rnoland@2hip.net) Received: from [192.168.2.15] (c-71-56-39-94.hsd1.ga.comcast.net [71.56.39.94]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n08DGJTL000668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 08:16:20 -0500 (EST) (envelope-from rnoland@2hip.net) From: Robert Noland To: Christof Schulze In-Reply-To: <200901081216.07107.christof.schulze@gmx.net> References: <200901081216.07107.christof.schulze@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gMPmIS9bdgp+5xXXCXDa" Organization: 2Hip Networks Date: Thu, 08 Jan 2009 08:16:58 -0500 Message-Id: <1231420618.1810.1.camel@wombat.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net X-Mailman-Approved-At: Thu, 08 Jan 2009 14:17:13 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Best torrent client/server available for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 13:34:34 -0000 --=-gMPmIS9bdgp+5xXXCXDa Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-01-08 at 12:16 +0100, Christof Schulze wrote: > Am Donnerstag 08 Januar 2009 00:04:24 schrieb joe mcguckin: > > There's quite a number of implementation in the ports collection. Does > > anyone have any options regarding which are the 'best'? > Azureus is a good client except for: > * high cpou/mem usage > * does not work in Freebsd 7.X - not sure about 8 because it will not get= =20 > any connections Does work on 7 and 8. You need to enable "extra hack" option for it to work well. I guess that I should really make that the default. Also, latest version is net-p2p/vuze. robert. > so I use trackerbt as a tracker and ktorrent as a client. >=20 > Christof --=-gMPmIS9bdgp+5xXXCXDa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkll/MoACgkQM4TrQ4qfROPnRgCfYufJ3e9ma9i1wlmv0j9OmjRv 2MQAn0fJxJeF95PyEpsXfuhFipUF/1ZT =vUNT -----END PGP SIGNATURE----- --=-gMPmIS9bdgp+5xXXCXDa-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 14:54:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C19E1065670 for ; Thu, 8 Jan 2009 14:54:22 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 7F7C28FC13 for ; Thu, 8 Jan 2009 14:54:21 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 7C21D1B114B2; Thu, 8 Jan 2009 15:36:21 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=ham version=3.2.5 Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 7EC441B1144C; Thu, 8 Jan 2009 15:36:18 +0100 (CET) Message-Id: <7B865AAF-4E24-4DE8-B4C2-25494F449EFD@moneybookers.com> From: Stefan Lambrev To: joe mcguckin In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 8 Jan 2009 16:36:18 +0200 References: X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94/8843/Thu Jan 8 07:01:58 2009 on blah.cmotd.com X-Virus-Status: Clean Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Best torrent client/server available for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 14:54:22 -0000 Greetings, On Jan 8, 2009, at 1:04 AM, joe mcguckin wrote: > There's quite a number of implementation in the ports collection. > Does anyone have any options regarding which are the 'best'? I'm very happy with deluge. But it depends on your needs. For desktop my choice is deluge. > > > Thanks, > > Joe > > > Joe McGuckin > ViaNet Communications > > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 14:56:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C78CF1065677 for ; Thu, 8 Jan 2009 14:56:12 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3BD8FC14 for ; Thu, 8 Jan 2009 14:56:11 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from [172.16.129.134] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id B8FAEA5AD3; Thu, 8 Jan 2009 15:56:09 +0100 (CET) Message-ID: <49661409.4090600@fsn.hu> Date: Thu, 08 Jan 2009 15:56:09 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Danny Braniss References: <4964EB20.5070709@fsn.hu> <4964F9BB.3020407@fsn.hu> In-Reply-To: X-Stationery: 0.4.8.12 X-Stationery: 0.4.8.12 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Thu, 08 Jan 2009 15:56:09 +0100 (CET) Cc: freebsd-current@freebsd.org, peter@wemm.org Subject: Re: pxeboot does not work on Sun X4540 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 14:56:13 -0000 Danny Braniss wrote: >> Attila Nagy wrote: >> >>> Hello, >>> >>> I'm trying to boot FreeBSD 8-CURRENT on a Sun X4540 (2xquad core >>> Opteron, 64 GB memory, 48 SATA disks (in fact 47, the 48th is a write >>> optimized SSD, because this box is a 7210 OpenStorage "appliance", >>> running OpenSolaris) on LSI controllers, nvidia NIC) from our boot >>> server without success. >>> >>> The PXE on the NIC downloads pxeboot with TFTP, but then gets stuck at >>> loading the kernel: >>> http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png >>> >>> pxeboot is configured to load the kernel via NFS (the default) and >>> according to the tcpdump output, the client (X4540) issues an NFS >>> GETPORT call and gets the response from the NFS server and then >>> nothing else happens. >>> >>> I've tried with LOADER_TFTP_SUPPORT=YES and the result is the same, >>> the only difference is that the machine stops sending packets after >>> the first TFTP read request (for /boot/boot.4th.split), which doesn't >>> exist, so the server sends the answer and then nothing comes back from >>> the X4540 box. >>> >>> It seems that it gets to send exactly one packet, then freezes. >>> >>> What else should be done to debug this problem? >>> >>> Thanks, >>> >> BTW, the last FreeBSD 8-CURRENT snapshot from december boots fine (at >> least I can get to sysinstall, I haven't yet tried installation, because >> I wouldn't like to touch the boot drives, which house the OpenSolaris >> image -that's why I want to boot from the net). >> >> > > older pxeboot - pre interrupt handling fixes - work ok, so you can use that > instead. > I thought that I did testing with an older version, but as it turned out I was wrong. Confirmed, older versions work fine. The next problem is that a freshly compiled kernel (HEAD from today) panics with this: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-55.png "BIOS smap did not include a basemem segment!" which is true, according to the above verbose output and taking a quick look at the code. (in the loop there is only a base=0x0 and len=0x0 entry) I'm not an expert of this topic (too), for me these numbers look pretty strange. Maybe Peter can help? Thanks, From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 15:24:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15A68106564A for ; Thu, 8 Jan 2009 15:24:55 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id 9599F8FC14 for ; Thu, 8 Jan 2009 15:24:53 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.37,234,1231110000"; d="scan'208";a="266508688" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 08 Jan 2009 16:24:52 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 81CE51B075D; Thu, 8 Jan 2009 16:24:52 +0100 (CET) Date: Thu, 08 Jan 2009 16:24:52 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Christoph Mallon Message-ID: In-Reply-To: <4965F348.90407@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: mouse cursor corrupts chars under syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 15:24:55 -0000 the effect is hard to describe. when moving the cursor over chars you can see that the edges of certain chars flicker. try running the command below. the effect should be quite obvious. i'm using an old fashioned crt monitor. the effect might not be visible on tft displays. i have absolutely no idea what's causing this. but here's a wild guess: from the effect it looks like the mouse cursor is actually made up of a 32x32 or 64x64 pixel square. this square contains the white cursor. apart from the cursor the rest of the square is transparent. it appears the code that calculates the actual pixel-colour-value between the transparent parts of the cursor-square and the cars on syscons has a bug in it. however that's just a wild guess. alex Christoph Mallon schrieb am 2009-01-08: > Alexander Best schrieb: > >i noticed the mouse cursor currupting characters under syscons. to > >test this > >do the following under syscons/bash: > >for i in `jot 5000`; do echo -n 0; done > >now gently move your cursor over the zeros. see? > What do you mean? When moving the mouse cursor down then its bottom > suddenly pops up in a row when it already should be several pixels > in that row? From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 16:03:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E378106566B for ; Thu, 8 Jan 2009 16:03:21 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DB8958FC3C for ; Thu, 8 Jan 2009 16:03:20 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 08 Jan 2009 16:03:18 -0000 Received: from p54A3E282.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.226.130] by mail.gmx.net (mp006) with SMTP; 08 Jan 2009 17:03:18 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18uRn4I3douBkhws4Sj+KE81wP2ATRrcqNuWFLUio Z09J9AD8L+ZUOR Message-ID: <496623C5.90400@gmx.de> Date: Thu, 08 Jan 2009 17:03:17 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: freebsd-current@freebsd.org Subject: Re: mouse cursor corrupts chars under syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 16:03:21 -0000 Alexander Best schrieb: > the effect is hard to describe. when moving the cursor over chars you can see > that the edges of certain chars flicker. try running the command below. the > effect should be quite obvious. i'm using an old fashioned crt monitor. the > effect might not be visible on tft displays. > > i have absolutely no idea what's causing this. but here's a wild guess: > > from the effect it looks like the mouse cursor is actually made up of a 32x32 > or 64x64 pixel square. this square contains the white cursor. apart from the > cursor the rest of the square is transparent. it appears the code that > calculates the actual pixel-colour-value between the transparent parts of the > cursor-square and the cars on syscons has a bug in it. > > however that's just a wild guess. Ah! Now I understand what you mean. First I did not see the effect, because I use 80x50 instead of 80x25 and a different font is used there. You see the right border of the "0" flickering when you move the mouse cursor, right? The effect is caused by how video hardware works in textmode and how the mouse cursor magic works. First video hardware in textmode: You see 80x25 chars. The resolution is 720x400 pixels. So every char consists 9x16 pixels. To display a char the video card uses a map with a bitmap for every char. But the bitmap of every char consists only of 16 bytes. So we are missing one bit per line. So there is another trick: Either the 9th column is displayed black (or whatever the background colour is) *or* the 8th column is repeated. What actually happens depends on two registers in the video card, which represent a range. You can set them so that char 213 till 234 (just random example) have their 8th column repeated to the 9th and all others have a black 9th column. Usually "0" is outside of this range, so the 9th column is black. Now how does the mouse cursor magic work: The mouse cursors consists of 2x2 chars. The bitmap for these 4 chars are altered and the codes for the 4 chars are copied to the place where the mouse cursor should appear. Remember: We are in text mode, so you cannot just paint pixels. Everything has to go through the character map. So to make the mouse cursor appear following happens: First the pixel coordinates of the cursor are mapped to the character coordinates. Then the 4 chars there are read and the character maps are copied to the 4 reserved chars. Then the mouse cursor is painted onto these 4 reserved chars. Last the 4 reserved character codes are copied to the screen, so you see the mouse cursor appear. So when you move your mouse onto a "0" you no longer see a "real" 0, but you see another character with the same charmap but the mouse cursor painted on it. Now the 9th column trick: The cursor would have a gap when it is outside the repeat-8th-column range. So the reserved characters are chosen to be in this range, the 8th column is copied and the mouse cursor appears continuous. This is also the reason why the mouse cursor has a "jumping" step when you move it around, just look closely. It is exactly at the right edge of a character. So the 8th column gets copied, but a "0" (and other chars, too) have pixel data in there, which also gets copied and this causes the effect you observe. Long story short: Everything is correct. (: Bonus: You can see the mouse cursor magic at work if you move the reserved character range: Write ABCD on the terminal: echo AB; echo CD Then execute "vidcontrol -M 65". 65 is ASCII A, you can only specify the start of the range. Now you see how the magic works in the four letters ABCD you wrote before. You'll also notice, that the mouse cursor now has a gap, because 65-68 are outside of the repeat-8th-column range. When you now move the mouse over "0" you no longer see the effect you described for the same reason. Use "vidcontrol -M 208" to reset to default. I hope this explanation is helpful for you Christoph From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 16:35:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AC8E1065672 for ; Thu, 8 Jan 2009 16:35:29 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id C3ADC8FC0C for ; Thu, 8 Jan 2009 16:35:28 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so11733851wfg.7 for ; Thu, 08 Jan 2009 08:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=iaRqvHCm955ePryYKN64TvMajBbFqtHRnl+G9Ir8D+0=; b=pKoNC6NCREwxcgyUwHI+0XcP9z7P2yvJRfpRwGMstQSoOfvWwvYa7Cabeo7V8oqSEG XJrUasQw664lXl3RgDsiaR2KzCZ8PVidkdmeqnYdp1a732o32scrU6lG020FsAtR3HKB +i7ilihKe5nFOMgjsaoZphvhrL9oBWXiT0lOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=b8zIL1Gsh9zWuyYxaDPbpNMiXZ3VH6LebVeE/7xDED9dauw61DPqTMBucwlAJm+nnE V8ZdTJ2pymMaU76QOOGpiaBAl+6jorPWKflqXXGrufYQ6VdOvVs8RlETbZSUIFIpggTy sXmDNBYy5cMrKv/A4IEopC3NMc4MQ2wRk3UU0= Received: by 10.143.160.17 with SMTP id m17mr10231207wfo.298.1231432528279; Thu, 08 Jan 2009 08:35:28 -0800 (PST) Received: by 10.142.142.10 with HTTP; Thu, 8 Jan 2009 08:35:28 -0800 (PST) Message-ID: <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> Date: Thu, 8 Jan 2009 11:35:28 -0500 From: "Kim Culhan" To: pyunyh@gmail.com In-Reply-To: <20090108075159.GH1256@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> Cc: freebsd-current@freebsd.org Subject: Re: msk Marvell Yukon 88E8038 hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 16:35:29 -0000 On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > On Thu, Jan 08, 2009 at 02:36:48AM -0500, Kim Culhan wrote: > > On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > > > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > > > > > Not necessarily at each hang but sometimes coincident, this is > > > > intermittently output to the console: > > > > > > > > in_cksum_skip: out of data by 56952 > > > > > > > > The above is also output to the console at times when receiving a > > > > character through ssh > > > > to a shell. > > > > > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > > > running 7.1-RELEASE. > > > > > > > > > > Would you show me dmesg output for msk(4)? > > > > dmesg: > > > > mskc0: port 0x2000-0x20ff mem > > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 > > msk0: on mskc0 > > msk0: Ethernet address: 00:1b:24:59:5b:7a > > miibus0: on msk0 > > e1000phy0: PHY 0 on miibus0 > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > mskc0: [FILTER] > > > > Would you try changes made in r183485(CVS if_msk.c, 1.33)? > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/msk/if_msk.c.diff?r1=1.32;r2=1.33;f=h The version in use is 1.35 dated 11-24-08 from 8.0-current cvsup'd on 1-7-09 This has the changes you have made in the diff from the link above. -- regards -kim From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 17:07:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE93110658A2 for ; Thu, 8 Jan 2009 17:07:35 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 91FCE8FC30 for ; Thu, 8 Jan 2009 17:07:34 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 08 Jan 2009 17:07:33 -0000 Received: from p54A3E282.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.226.130] by mail.gmx.net (mp071) with SMTP; 08 Jan 2009 18:07:33 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+bl+gbeISb67AlZ7v+StTMTyFknFNj3a7ItLmnZv 3s3GeHl2ZRkZvF Message-ID: <496632D3.5070608@gmx.de> Date: Thu, 08 Jan 2009 18:07:31 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Alexander Best References: <496623C5.90400@gmx.de> In-Reply-To: <496623C5.90400@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 Cc: freebsd-current@freebsd.org Subject: Re: mouse cursor corrupts chars under syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 17:07:50 -0000 Christoph Mallon schrieb: > What actually happens depends on two registers in the video > card, which represent a range. You can set them so that char 213 till > 234 (just random example) have their 8th column repeated to the 9th and > all others have a black 9th column. I remembered some details wrong. The range of chars, which get their 8th column repeated, is always 0xC0 till 0xDF. There is just one bit to completely deactivate repeating the 8th column. From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 17:11:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B358D106589D for ; Thu, 8 Jan 2009 17:11:44 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 255978FC1B for ; Thu, 8 Jan 2009 17:11:42 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so5254282qwb.7 for ; Thu, 08 Jan 2009 09:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=QFLm8ISuoEfXyk6Z/7/GWFXnyzPOu+x5Ikp1jjrWRe0=; b=GzaE0BQ5CUWCKSXQAMU4wEEfkHtOip8wEjxHqerktUAUAdPbDcdNQiRcZd0aauQ3rv pgUPqTh7oSbK+JB+6cMmKPmt60ea+JntkqZOAjzKUiWG5IUfapZBAH4LCF/94RFhVJQP +Vf8OGU75gPIGq4OYXwlaNvU9gLYwmSeOD9uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=eU2l70lgD3hEswQBK2uCiIITNYjQif9xN65JjmWWQUdiPLVH3lpGQVLO7R9WHAYnhc VNL1kXbamH/dhmf8cZ3slkQcw/dI8EED+wbw9zaCjHsPA4h6ieQ9o83hgbr56L3Nhydb uRko3VKrqbxet0wqHRE/ji61wvkpVMZFv4Cic= Received: by 10.214.78.21 with SMTP id a21mr6024380qab.221.1231434701979; Thu, 08 Jan 2009 09:11:41 -0800 (PST) Received: by 10.214.44.19 with HTTP; Thu, 8 Jan 2009 09:11:41 -0800 (PST) Message-ID: <47d0403c0901080911n7a364a3o20172ce579619fad@mail.gmail.com> Date: Thu, 8 Jan 2009 12:11:41 -0500 From: "Ben Kaduk" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: panic: initiate_write_inodeblock_ufs2: already started X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 17:11:51 -0000 I upgraded a few days ago from a year-old RELENG_7 to a fresh RELENG_7 (right before the 7.1 release, basically), and then started an upgrade to CURRENT but noticed that my gmirror was degraded when booting to single-user. It had been degraded for a few days, corresponding roughly to when I physically moved the machine to a different room. I hesitated for a while before sending this, because there are so many correlated things going on, and it's hard to rule out hardware problems. However, I have now seen this panic a couple times; once, the panic string was interleaved with "ad2: FAILURE - load data" and another where the string was interleaved with "ad0: FAILURE - load data", so I am using the working hypothesis that this failure is not tied to a particular one of the disks. Such sparse data as I have collected is up here: http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/periphrasis/20090107/panic.txt I have seen three four panics so far; I was in X for the first, and thus have no data for it; the last three are in the above file. I was only able to get to KDB for the middle of the three, and I sadly did not print the panicstr from it, so I'm not sure if it's the same panic as the subject line or not. The machine had just errored about failing to set up DMA for both disks, so I was unable to get a dump :( I'll try to see if I can see if there's a difference between kernel.old and kernel. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 17:13:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F211065882 for ; Thu, 8 Jan 2009 17:13:16 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id E5F098FC1F for ; Thu, 8 Jan 2009 17:13:15 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.37,235,1231110000"; d="scan'208";a="266517786" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER02.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 08 Jan 2009 18:13:14 +0100 Received: by ZIVMAILUSER02.UNI-MUENSTER.DE (Postfix, from userid 149459) id CA4BE1B0871; Thu, 8 Jan 2009 18:13:14 +0100 (CET) Date: Thu, 08 Jan 2009 18:13:14 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: patch to fix burncd bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 17:13:17 -0000 could somebody please commit the following patch to dev/ata? it fixes a nasty bug during fixation in burncd. the bug exists in RELENG6, RELENG7 and HEAD (and maybe RELENG5): http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch the whole PR can be found here: http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 cheers. alex From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 17:34:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 610171065705 for ; Thu, 8 Jan 2009 17:34:48 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63908.mail.re1.yahoo.com (web63908.mail.re1.yahoo.com [69.147.97.123]) by mx1.freebsd.org (Postfix) with SMTP id E2B288FC16 for ; Thu, 8 Jan 2009 17:34:47 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 5553 invoked by uid 60001); 8 Jan 2009 17:08:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=4CjiwzD4L08M9tRw+CqbAcp4B1H9IR8+Zxs2VGtPeLAMyAbBJkBXZ9kjydDatqpxfqJS/gwFpD6AcMcdEkxbtIxejKAFGhrlqE3kJQ2Uf0307slS4pJt/528wpkHhVs2QlYppGbxeCA/j6fiboF023VJKb7nfxuL0+Z//a2ikd4=; X-YMail-OSG: PNuAlVoVM1nQ9gjS0Paqy1MNAfELxQV9CcyTJYevVN2yzrgYfXJmoh_I15.WuKOkHPhs0_FxSxGis7y.LjkOq9Au7wmjTfobyUHxMm0__VCS55Mxlph8c4ADSfVux4JOnUwZ6MjVJ5QYBuWlRc8W2DtFv1I- Received: from [98.242.222.229] by web63908.mail.re1.yahoo.com via HTTP; Thu, 08 Jan 2009 09:08:07 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Thu, 8 Jan 2009 09:08:07 -0800 (PST) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <321406.5257.qm@web63908.mail.re1.yahoo.com> Cc: Subject: Adding a new kernel module? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 17:34:48 -0000 I'm testing a new kernel module that needs to be compiled in, and everything works fine except that make doesn't make the module for the new driver. The driver is under dev /sys/dev/foo How does the kernel make system decide what modules to build? How can I add a new kernel modules to the build system to get it to build the new module automatically? Thanks, Barney From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 17:35:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1139F1065686 for ; Thu, 8 Jan 2009 17:35:57 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id E1E0B8FC13 for ; Thu, 8 Jan 2009 17:35:56 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: by wa-out-1112.google.com with SMTP id m34so5037368wag.27 for ; Thu, 08 Jan 2009 09:35:56 -0800 (PST) Received: by 10.115.78.1 with SMTP id f1mr16205357wal.157.1231436156560; Thu, 08 Jan 2009 09:35:56 -0800 (PST) Received: by 10.114.61.20 with HTTP; Thu, 8 Jan 2009 09:35:56 -0800 (PST) Message-ID: <1de79840901080935s130f647r36815df468a9220b@mail.gmail.com> Date: Thu, 8 Jan 2009 12:35:56 -0500 From: "Michael Proto" To: "Alexander Best" In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: patch to fix burncd bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 17:35:57 -0000 On Thu, Jan 8, 2009 at 12:13 PM, Alexander Best < alexbestms@math.uni-muenster.de> wrote: > could somebody please commit the following patch to dev/ata? it fixes a > nasty > bug during fixation in burncd. the bug exists in RELENG6, RELENG7 and HEAD > (and maybe RELENG5): > > http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch > > the whole PR can be found here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 > > I second this request. A fix would be nice, this bug has bitten me in both 7-STABLE and 8-CURRENT :) -Proto From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 17:37:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AFBB1065811; Thu, 8 Jan 2009 17:37:19 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 0AD1C8FC41; Thu, 8 Jan 2009 17:37:17 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so1491660ugs.39 for ; Thu, 08 Jan 2009 09:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=vgRO5b8Z5mw2Y8lKKie/r5mdQTl+N1ip267U+Ijpm9E=; b=xZbJa+lAUL3cfBcOIZphuhCiniGOZJmEvq0jDDNyupvhsdTU8QML2RU+v4kSOs1gTz x9OlvhXzVFBphpbTIyCUtbN6vZu4l0jdZqUQwG5SL6wc2xSznTTPESUS4NOviH9GfV29 lyV/lfdsNr9sljRb8zDcxYPWUhOlhjSXr4Yn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=wl+IiEmQt3YumGyN0q+6eT74EA+tvCtdn4W6v78UL/a9d2yxoXnvPJL03x5z1NKlDb rqDgA2RrAz2MTU8APEGi4tIBs9ydFsHzp6/entl4dvPcROFHUehjpwGXw0hGe6kvo9IN A33uagyh0cxqH9UjSvnpEYGUm253yeVepoEmU= Received: by 10.67.98.15 with SMTP id a15mr14610078ugm.86.1231436236734; Thu, 08 Jan 2009 09:37:16 -0800 (PST) Received: by 10.67.88.9 with HTTP; Thu, 8 Jan 2009 09:37:16 -0800 (PST) Message-ID: <7d6fde3d0901080937t29ec42f5i6684b9223d0b368a@mail.gmail.com> Date: Thu, 8 Jan 2009 09:37:16 -0800 From: "Garrett Cooper" To: "Alexander Motin" In-Reply-To: <49649333.6060902@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14307_5073483.1231436236730" References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> <49647602.9060402@FreeBSD.org> <49649333.6060902@gmail.com> Cc: FreeBSD Current Subject: Re: snd_hda(4): getting line-in to work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 17:37:20 -0000 ------=_Part_14307_5073483.1231436236730 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Jan 7, 2009 at 3:34 AM, Garrett Cooper wrote: > Alexander Motin wrote: >> >> Garrett Cooper wrote: >>> >>> On Tue, Jan 6, 2009 at 12:53 PM, Alexander Motin wrote: >>>> >>>> Garrett Cooper wrote: >>>>> >>>>> I'm not sure if it's user error or not, but my snd_hda(4) enabled >>>>> chipset doesn't have line-in support enabled. I was wondering if there >>>>> were a special set of instructions I need to follow to get this >>>>> working. >>>> >>>> The main instruction is to boot system with verbose messages. snd_hda >>>> writes >>>> all information needed to answer most questions. Read it yourself and if >>>> it >>>> does not help - send it to me. >>>> >>>>> [gcooper@orangebox /scratch/ltp]$ cat /dev/sndstat >>>>> FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) >>>>> Installed devices: >>>>> pcm0: at cad 0 nid 1 on >>>>> hdac0 [MPSAFE] (1p:1v/1r:1v channels duplex default) >>>> >>>> All I can see here is that you have some recording device. You can >>>> browse >>>> and select specific recording source with `mixer =rec` command. For >>>> additional details look verbose output and read new snd_hda man page. >>>> >>>>> pcm1: at cad 0 nid 1 on >>>>> hdac0 [MPSAFE] (1p:1v/0r:0v channels) >>>>> pcm2: at cad 0 nid 1 on >>>>> hdac0 [MPSAFE] (1p:1v/0r:0v channels) >>>> >>>> -- >>>> Alexander Motin >>> >>> Trying with the instructions on the manpage actually disabled my >>> sound... then again I probably screwed up the settings (I believe it >>> was noted as pcm2 before??). >>> >>> Here're the device.hints entries and I attached the -v boot log >>> snippet for the card: >> >> In attached log you have missed one of very interesting parts while >> grepping: pcmX devices output prints sound processing paths within codec for >> every PCM device. Look it first before doing something. >> >>> hint.hdac.0.cad0.nid17.config="as=1seq=0 device=Headphones" >>> hint.hdac.0.cad0.nid18.config="as=2seq=0 device=Line-out" >>> hint.hdac.0.cad0.nid19.config="as=3seq=0 device=Speaker" >>> hint.hdac.0.cad0.nid20.config="as=4seq=0 device=Mic" >>> hint.hdac.0.cad0.nid21.config="as=5seq=0 device=Line-in" >>> hint.hdac.0.cad0.nid22.config="as=6seq=0 device=Line-out" >>> hint.hdac.0.cad0.nid23.config="as=6seq=0 device=Mic" >>> hint.hdac.0.cad0.nid24.config="as=6seq=0 device=CD" >>> hint.hdac.0.cad0.nid36.config="as=5seq=0 device=Line-out" >>> hint.hdac.0.cad0.nid37.config="as=6seq=0 device=Line-out" >> >> Except lack of speces between fields there is also lack of any sense. I >> don't understand what was you trying to do, but it will not work: >> - you configured nid 21 and nid 36 as association five, but made one of >> them input and other output. It is incorrect, association may include only >> pins of one direction (in/out); >> - association 6 is the same; >> - nid 19 has connectivity "None", so it will not be used by driver. >> It is all described in manual. >> >> Actually I think default configuration is quite reasonable. There is some >> things that can be tuned, but you should first understand what you have and >> how it works. > > Honestly, I feel as if I'm staring at a jigsaw puzzle all in pieces right > now, trying to sort out what's going on -- I've never truly played with > device.hints(5) before... > I'll look at the PCM entries and try to finally sort this out... > Thanks, > -Garrett Alexander, Ok, I got stuck again. Can you possibly push me in the right direction (complete verbose dmesg attached)? The line-in and SPDIF (not so much of a concern) are the only issues that I'm aware of. I'll have to open up my case and wire up the front ports in order to test them for you. Also, the knobs that show up in xfce4-mixer are completely useless for snd_hda(4) (every time I move the sliders it sets the volume back to 0). Is this a known issue? Thanks, -Garrett ------=_Part_14307_5073483.1231436236730 Content-Type: application/octet-stream; name=dmesg.today Content-Transfer-Encoding: base64 X-Attachment-Id: f_fpppas4n0 Content-Disposition: attachment; filename=dmesg.today cGNpYjA6IHNsb3QgMzEgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDIyCmZvdW5kLT4JdmVuZG9yPTB4 ODA4NiwgZGV2PTB4MjkzMCwgcmV2aWQ9MHgwMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBm dW5jPTMKCWNsYXNzPTBjLTA1LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAw MDMsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49Yywg aXJxPTUKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGYzZmZmNDAwLCBz aXplICA4LCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAw eDQwMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4zMS5JTlRD CnBjaWIwOiBzbG90IDMxIElOVEMgaGFyZHdpcmVkIHRvIElSUSAxOApwY2liMTogPEFDUEkgUENJ LVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpYjE6ICAgZG9tYWlu ICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAxCnBjaWIxOiAgIHN1Ym9y ZGluYXRlIGJ1cyAgIDEKcGNpYjE6ICAgSS9PIGRlY29kZSAgICAgICAgMHhjMDAwLTB4Y2ZmZgpw Y2liMTogICBtZW1vcnkgZGVjb2RlICAgICAweGY0MDAwMDAwLTB4ZjdlZmZmZmYKcGNpYjE6ICAg cHJlZmV0Y2hlZCBkZWNvZGUgMHhkMDAwMDAwMC0weGRmZmZmZmZmCnBjaTE6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWIxCnBjaTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MQpmb3VuZC0+CXZlbmRv cj0weDEwZGUsIGRldj0weDAxOTMsIHJldmlkPTB4YTIKCWRvbWFpbj0wLCBidXM9MSwgc2xvdD0w LCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0w eDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHgw MCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49 YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBz dXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMy LCBiYXNlIDB4ZjYwMDAwMDAsIHNpemUgMjQsIGVuYWJsZWQKcGNpYjE6IHJlcXVlc3RlZCBtZW1v cnkgcmFuZ2UgMHhmNjAwMDAwMC0weGY2ZmZmZmZmOiBnb29kCgltYXBbMTRdOiB0eXBlIFByZWZl dGNoYWJsZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZDAwMDAwMDAsIHNpemUgMjgsIGVuYWJs ZWQKcGNpYjE6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhkMDAwMDAwMC0weGRmZmZmZmZmOiBn b29kCgltYXBbMWNdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmNDAwMDAwMCwgc2l6 ZSAyNSwgZW5hYmxlZApwY2liMTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGY0MDAwMDAwLTB4 ZjVmZmZmZmY6IGdvb2QKCW1hcFsyNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4 Y2MwMCwgc2l6ZSAgNywgZW5hYmxlZApwY2liMTogcmVxdWVzdGVkIEkvTyByYW5nZSAweGNjMDAt MHhjYzdmOiBpbiByYW5nZQpwY2liMTogbWF0Y2hlZCBlbnRyeSBmb3IgMS4wLklOVEEKcGNpYjE6 IHNsb3QgMCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxl IGRpc3BsYXk+IHBvcnQgMHhjYzAwLTB4Y2M3ZiBtZW0gMHhmNjAwMDAwMC0weGY2ZmZmZmZmLDB4 ZDAwMDAwMDAtMHhkZmZmZmZmZiwweGY0MDAwMDAwLTB4ZjVmZmZmZmYgaXJxIDE2IGF0IGRldmlj ZSAwLjAgb24gcGNpMQpudmlkaWEwOiA8R2VGb3JjZSA4ODAwIEdUUz4gb24gdmdhcGNpMAp2Z2Fw Y2kwOiBjaGlsZCBudmlkaWEwIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2J1c21hc3Rlcgp2Z2FwY2kw OiBjaGlsZCBudmlkaWEwIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2lvCnZnYXBjaTA6IFJlc2VydmVk IDB4MTAwMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZjYwMDAwMDAKdmdhcGNp MDogUmVzZXJ2ZWQgMHgxMDAwMDAwMCBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSAzIGF0IDB4ZDAw MDAwMDAKdmdhcGNpMDogUmVzZXJ2ZWQgMHgyMDAwMDAwIGJ5dGVzIGZvciByaWQgMHgxYyB0eXBl IDMgYXQgMHhmNDAwMDAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNiAoUENJIElSUSAxNikg dG8gdmVjdG9yIDQ5Cm52aWRpYTA6IFtHSUFOVC1MT0NLRURdCm52aWRpYTA6IFtJVEhSRUFEXQp1 aGNpMDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhiODAwLTB4 YjgxZiBpcnEgMTYgYXQgZGV2aWNlIDI2LjAgb24gcGNpMAp1aGNpMDogUmVzZXJ2ZWQgMHgyMCBi eXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4YjgwMAp1aGNpMDogW0dJQU5ULUxPQ0tFRF0K dWhjaTA6IFtJVEhSRUFEXQp1c2IwOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxl cj4gb24gdWhjaTAKdXNiMDogVVNCIHJldmlzaW9uIDEuMAp1aHViMDogPEludGVsIFVIQ0kgcm9v dCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IwCnVodWIwOiAy IHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNpMTogPEludGVsIDgyODAx SSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhiODgwLTB4Yjg5ZiBpcnEgMjEgYXQgZGV2 aWNlIDI2LjEgb24gcGNpMAp1aGNpMTogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAg dHlwZSA0IGF0IDB4Yjg4MAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMSAoUENJIElSUSAyMSkg dG8gdmVjdG9yIDUwCnVoY2kxOiBbR0lBTlQtTE9DS0VEXQp1aGNpMTogW0lUSFJFQURdCnVzYjE6 IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMQp1c2IxOiBVU0Ig cmV2aXNpb24gMS4wCnVodWIxOiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYg MS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjEKdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkCnVoY2kyOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxl cj4gcG9ydCAweGJjMDAtMHhiYzFmIGlycSAxOCBhdCBkZXZpY2UgMjYuMiBvbiBwY2kwCnVoY2ky OiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhiYzAwCmlvYXBp YzA6IHJvdXRpbmcgaW50cGluIDE4IChQQ0kgSVJRIDE4KSB0byB2ZWN0b3IgNTEKdWhjaTI6IFtH SUFOVC1MT0NLRURdCnVoY2kyOiBbSVRIUkVBRF0KdXNiMjogPEludGVsIDgyODAxSSAoSUNIOSkg VVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kyCnVzYjI6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjI6IDxJ bnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNiMgp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKZWhjaTA6 IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjNmZmZjMDAt MHhmM2ZmZmZmZiBpcnEgMTggYXQgZGV2aWNlIDI2Ljcgb24gcGNpMAplaGNpMDogUmVzZXJ2ZWQg MHg0MDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGYzZmZmYzAwCmVoY2kwOiBbR0lB TlQtTE9DS0VEXQplaGNpMDogW0lUSFJFQURdCnVzYjM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNiMzog Y29tcGFuaW9uIGNvbnRyb2xsZXJzLCAyIHBvcnRzIGVhY2g6IHVzYjAgdXNiMSB1c2IyCnVzYjM6 IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKdXNiMzog VVNCIHJldmlzaW9uIDIuMAp1aHViMzogPEludGVsIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwg cmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IzCnVodWIzOiA2IHBvcnRzIHdpdGggNiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZApoZGFjMDogPEludGVsIDgyODAxSSBIaWdoIERlZmluaXRpb24g QXVkaW8gQ29udHJvbGxlcj4gbWVtIDB4ZjNmZjgwMDAtMHhmM2ZmYmZmZiBpcnEgMjIgYXQgZGV2 aWNlIDI3LjAgb24gcGNpMApoZGFjMDogSERBIERyaXZlciBSZXZpc2lvbjogMjAwODEyMjZfMDEy MgpoZGFjMDogUmVzZXJ2ZWQgMHg0MDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhm M2ZmODAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMiAoUENJIElSUSAyMikgdG8gdmVjdG9y IDUyCmhkYWMwOiBbTVBTQUZFXQpoZGFjMDogW0lUSFJFQURdCnBjaWIyOiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gaXJxIDE3IGF0IGRldmljZSAyOC4wIG9uIHBjaTAKcGNpYjI6ICAgZG9tYWluICAg ICAgICAgICAgMApwY2liMjogICBzZWNvbmRhcnkgYnVzICAgICAzCnBjaWIyOiAgIHN1Ym9yZGlu YXRlIGJ1cyAgIDMKcGNpYjI6ICAgSS9PIGRlY29kZSAgICAgICAgMHgwLTB4MApwY2liMjogICBw cmVmZXRjaGVkIGRlY29kZSAweGYyZjAwMDAwLTB4ZjJmZmZmZmYKcGNpMzogPEFDUEkgUENJIGJ1 cz4gb24gcGNpYjIKcGNpMzogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0zCnBjaWIzOiA8QUNQSSBQ Q0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAyOC41IG9uIHBjaTAKcGNpYjM6ICAgZG9t YWluICAgICAgICAgICAgMApwY2liMzogICBzZWNvbmRhcnkgYnVzICAgICAyCnBjaWIzOiAgIHN1 Ym9yZGluYXRlIGJ1cyAgIDIKcGNpYjM6ICAgSS9PIGRlY29kZSAgICAgICAgMHhkMDAwLTB4ZGZm ZgpwY2liMzogICBtZW1vcnkgZGVjb2RlICAgICAweGY3ZjAwMDAwLTB4ZjdmZmZmZmYKcGNpYjM6 ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKcGNp MjogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0yCmZvdW5kLT4JdmVuZG9yPTB4MTFhYiwgZGV2PTB4 NDM2NCwgcmV2aWQ9MHgxMgoJZG9tYWluPTAsIGJ1cz0yLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9 MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0w eDAwMTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vy c3BlYyAzICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEg bWVzc2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhm N2ZmYzAwMCwgc2l6ZSAxNCwgZW5hYmxlZApwY2liMzogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAw eGY3ZmZjMDAwLTB4ZjdmZmZmZmY6IGdvb2QKCW1hcFsxOF06IHR5cGUgSS9PIFBvcnQsIHJhbmdl IDMyLCBiYXNlIDB4ZDgwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMzogcmVxdWVzdGVkIEkvTyBy YW5nZSAweGQ4MDAtMHhkOGZmOiBpbiByYW5nZQpwY2liMzogbWF0Y2hlZCBlbnRyeSBmb3IgMi4w LklOVEEKcGNpYjM6IHNsb3QgMCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTcKbXNrYzA6IDxNYXJ2 ZWxsIFl1a29uIDg4RTgwNTYgR2lnYWJpdCBFdGhlcm5ldD4gcG9ydCAweGQ4MDAtMHhkOGZmIG1l bSAweGY3ZmZjMDAwLTB4ZjdmZmZmZmYgaXJxIDE3IGF0IGRldmljZSAwLjAgb24gcGNpMgptc2tj MDogUmVzZXJ2ZWQgMHg0MDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmN2ZmYzAw MAptc2tjMDogTVNJIGNvdW50IDogMQptc2tjMDogYXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1T SSB2ZWN0b3JzICgxIHN1cHBvcnRlZCkKbXNpOiByb3V0aW5nIE1TSSBJUlEgMjU2IHRvIHZlY3Rv ciA1Mwptc2tjMDogdXNpbmcgSVJRIDI1NiBmb3IgTVNJCm1za2MwOiBSQU0gYnVmZmVyIHNpemUg OiAwS0IKbXNrMDogPE1hcnZlbGwgVGVjaG5vbG9neSBHcm91cCBMdGQuIFl1a29uIEVDIFVsdHJh IElkIDB4YjQgUmV2IDB4MDI+IG9uIG1za2MwCm1zazA6IGJwZiBhdHRhY2hlZAptc2swOiBFdGhl cm5ldCBhZGRyZXNzOiAwMDoxZDo2MDpiNjplYjo5NwptaWlidXMwOiA8TUlJIGJ1cz4gb24gbXNr MAplMTAwMHBoeTA6IDxNYXJ2ZWxsIDg4RTExNDkgR2lnYWJpdCBQSFk+IFBIWSAwIG9uIG1paWJ1 czAKZTEwMDBwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRY LUZEWCwgMTAwMGJhc2VUWC1GRFgsIGF1dG8KbXNrYzA6IFtNUFNBRkVdCm1za2MwOiBbRklMVEVS XQp1aGNpMzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhiMDgw LTB4YjA5ZiBpcnEgMjMgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1aGNpMzogUmVzZXJ2ZWQgMHgy MCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4YjA4MAppb2FwaWMwOiByb3V0aW5nIGlu dHBpbiAyMyAoUENJIElSUSAyMykgdG8gdmVjdG9yIDU0CnVoY2kzOiBbR0lBTlQtTE9DS0VEXQp1 aGNpMzogW0lUSFJFQURdCnVzYjQ6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVy PiBvbiB1aGNpMwp1c2I0OiBVU0IgcmV2aXNpb24gMS4wCnVodWI0OiA8SW50ZWwgVUhDSSByb290 IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjQKdWh1YjQ6IDIg cG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2k0OiA8SW50ZWwgODI4MDFJ IChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGI0MDAtMHhiNDFmIGlycSAxOSBhdCBkZXZp Y2UgMjkuMSBvbiBwY2kwCnVoY2k0OiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0 eXBlIDQgYXQgMHhiNDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE5IChQQ0kgSVJRIDE5KSB0 byB2ZWN0b3IgNTUKdWhjaTQ6IFtHSUFOVC1MT0NLRURdCnVoY2k0OiBbSVRIUkVBRF0KdXNiNTog PEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k0CnVzYjU6IFVTQiBy ZXZpc2lvbiAxLjAKdWh1YjU6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiNQp1aHViNTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKdWhjaTU6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVy PiBwb3J0IDB4YjQ4MC0weGI0OWYgaXJxIDE4IGF0IGRldmljZSAyOS4yIG9uIHBjaTAKdWhjaTU6 IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGI0ODAKdWhjaTU6 IFtHSUFOVC1MT0NLRURdCnVoY2k1OiBbSVRIUkVBRF0KdXNiNjogPEludGVsIDgyODAxSSAoSUNI OSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k1CnVzYjY6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjY6 IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNiNgp1aHViNjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKZWhj aTE6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjNmZmY4 MDAtMHhmM2ZmZmJmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAplaGNpMTogUmVzZXJ2 ZWQgMHg0MDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGYzZmZmODAwCmVoY2kxOiBb R0lBTlQtTE9DS0VEXQplaGNpMTogW0lUSFJFQURdCnVzYjc6IEVIQ0kgdmVyc2lvbiAxLjAKdXNi NzogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAyIHBvcnRzIGVhY2g6IHVzYjQgdXNiNSB1c2I2CnVz Yjc6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTEKdXNi NzogVVNCIHJldmlzaW9uIDIuMAp1aHViNzogPEludGVsIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkv MCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2I3CnVodWI3OiA2IHBvcnRzIHdpdGggNiBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViODogPHZlbmRvciAweDA0MjQgcHJvZHVjdCAweDI1 MDIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMC4wMSwgYWRkciAyPiBvbiB1aHViNwp1aHViODogc2lu Z2xlIHRyYW5zYWN0aW9uIHRyYW5zbGF0b3IKdWh1Yjg6IDIgcG9ydHMgd2l0aCAxIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkCnVodWI5OiA8dmVuZG9yIDB4MDQyNCBwcm9kdWN0IDB4MjYwMiwgY2xh c3MgOS8wLCByZXYgMi4wMC8wLjAwLCBhZGRyIDM+IG9uIHVodWI4CnVodWI5OiBtdWx0aXBsZSB0 cmFuc2FjdGlvbiB0cmFuc2xhdG9ycwp1aHViOTogNCBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBz ZWxmIHBvd2VyZWQKdW1hc3MwOiA8R2VuZXJpYyBGbGFzaCBDYXJkIFJlYWRlciwgY2xhc3MgMC8w LCByZXYgMi4wMC80LjQ0LCBhZGRyIDQ+IG9uIHVodWI5CnVtYXNzMDowOjA6LTE6IEF0dGFjaGVk IHRvIHNjYnVzMApwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9u IHBjaTAKcGNpYjQ6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liNDogICBzZWNvbmRhcnkgYnVz ICAgICA0CnBjaWI0OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDQKcGNpYjQ6ICAgSS9PIGRlY29kZSAg ICAgICAgMHhlMDAwLTB4ZWZmZgpwY2liNDogICBtZW1vcnkgZGVjb2RlICAgICAweGY4MDAwMDAw LTB4ZmViZmZmZmYKcGNpYjQ6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpYjQ6ICAgU3VidHJh Y3RpdmVseSBkZWNvZGVkIGJyaWRnZS4KcGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKcGNp NDogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz00CmZvdW5kLT4JdmVuZG9yPTB4MTEwMiwgZGV2PTB4 MDAwNSwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz00LCBzbG90PTIsIGZ1bmM9MAoJY2xhc3M9 MDQtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0w eDAyMTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWlu Z250PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwNSAoMTI1MCBucykKCWludHBpbj1hLCBpcnE9 NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCglNU0kgc3Vw cG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMy LCBiYXNlIDB4ZWMwMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liNDogcmVxdWVzdGVkIEkvTyByYW5n ZSAweGVjMDAtMHhlYzFmOiBpbiByYW5nZQoJbWFwWzE0XTogdHlwZSBNZW1vcnksIHJhbmdlIDY0 LCBiYXNlIDB4ZmVhMDAwMDAsIHNpemUgMjEsIGVuYWJsZWQKcGNpYjQ6IHJlcXVlc3RlZCBtZW1v cnkgcmFuZ2UgMHhmZWEwMDAwMC0weGZlYmZmZmZmOiBnb29kCgltYXBbMWNdOiB0eXBlIE1lbW9y eSwgcmFuZ2UgNjQsIGJhc2UgMHhmODAwMDAwMCwgc2l6ZSAyNiwgZW5hYmxlZApwY2liNDogcmVx dWVzdGVkIG1lbW9yeSByYW5nZSAweGY4MDAwMDAwLTB4ZmJmZmZmZmY6IGdvb2QKcGNpYjQ6IG1h dGNoZWQgZW50cnkgZm9yIDQuMi5JTlRBCnBjaWI0OiBzbG90IDIgSU5UQSBoYXJkd2lyZWQgdG8g SVJRIDE4CmZvdW5kLT4JdmVuZG9yPTB4MTFjMSwgZGV2PTB4NTgxMSwgcmV2aWQ9MHg3MAoJZG9t YWluPTAsIGJ1cz00LCBzbG90PTMsIGZ1bmM9MAoJY2xhc3M9MGMtMDAtMTAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MAoJY21kcmVnPTB4MDAxNiwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej04IChk d29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MGMgKDMwMDAgbnMpLCBt YXhsYXQ9MHgxOCAoNjAwMCBucykKCWludHBpbj1hLCBpcnE9MTQKCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdl IDMyLCBiYXNlIDB4ZmU5ZmYwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjQ6IHJlcXVlc3RlZCBt ZW1vcnkgcmFuZ2UgMHhmZTlmZjAwMC0weGZlOWZmZmZmOiBnb29kCnBjaWI0OiBtYXRjaGVkIGVu dHJ5IGZvciA0LjMuSU5UQQpwY2liNDogc2xvdCAzIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxOQpw Y2k0OiA8bXVsdGltZWRpYSwgYXVkaW8+IGF0IGRldmljZSAyLjAgKG5vIGRyaXZlciBhdHRhY2hl ZCkKZndvaGNpMDogPEx1Y2VudCBGVzMyMi8zMjM+IG1lbSAweGZlOWZmMDAwLTB4ZmU5ZmZmZmYg aXJxIDE5IGF0IGRldmljZSAzLjAgb24gcGNpNApmd29oY2kwOiBSZXNlcnZlZCAweDEwMDAgYnl0 ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGZlOWZmMDAwCmZ3b2hjaTA6IFtNUFNBRkVdCmZ3 b2hjaTA6IFtGSUxURVJdCmZ3b2hjaTA6IE9IQ0kgdmVyc2lvbiAxLjAgKFJPTT0xKQpmd29oY2kw OiBOby4gb2YgSXNvY2hyb25vdXMgY2hhbm5lbHMgaXMgOC4KZndvaGNpMDogRVVJNjQgMDA6MTE6 ZDg6MDA6MDE6ODM6MWU6NjEKZndvaGNpMDogUGh5IDEzOTRhIGF2YWlsYWJsZSBTNDAwLCAyIHBv cnRzLgpmd29oY2kwOiBMaW5rIFM0MDAsIG1heF9yZWMgMjA0OCBieXRlcy4KZmlyZXdpcmUwOiA8 SUVFRTEzOTQoRmlyZVdpcmUpIGJ1cz4gb24gZndvaGNpMApzYnAwOiA8U0JQLTIvU0NTSSBvdmVy IEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKZndvaGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0CmZ3b2hj aTA6IEJVUyByZXNldApmd29oY2kwOiBub2RlX2lkPTB4YzgwMGZmYzAsIGdlbj0xLCBDWUNMRU1B U1RFUiBtb2RlCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAK aXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCAoSUQ9MjkyMjgwODYpIEFI Q0kgY29udHJvbGxlcj4gcG9ydCAweGFjMDAtMHhhYzA3LDB4YTg4MC0weGE4ODMsMHhhODAwLTB4 YTgwNywweGE0ODAtMHhhNDgzLDB4YTQwMC0weGE0MWYgbWVtIDB4ZjNmZmU4MDAtMHhmM2ZmZWZm ZiBpcnEgMjIgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDIwIGJ5 dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhhNDAwCmF0YXBjaTA6IFJlc2VydmVkIDB4ODAw IGJ5dGVzIGZvciByaWQgMHgyNCB0eXBlIDMgYXQgMHhmM2ZmZTgwMAphdGFwY2kwOiBbTVBTQUZF XQphdGFwY2kwOiBbSVRIUkVBRF0KYXRhcGNpMDogQUhDSSBWZXJzaW9uIDAxLjIwIGNvbnRyb2xs ZXIgd2l0aCA2IHBvcnRzIFBNIHN1cHBvcnRlZAphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRh cGNpMAphdGEyOiBTQVRBIGNvbm5lY3Qgc3RhdHVzPTAwMDAwMDAwCmF0YTI6IHBoeSByZXNldCBm b3VuZCBubyBkZXZpY2UKYXRhMjogW01QU0FGRV0KYXRhMjogW0lUSFJFQURdCmF0YTM6IDxBVEEg Y2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YTM6IGV4ZWN1dGluZyBDTE8gZmFpbGVkCmF0YTM6IFNB VEEgY29ubmVjdCB0aW1lPTBtcwphdGEzOiBCVVNZIHdhaXQgdGltZT0xbXMKYXRhMzogU0lHTkFU VVJFOiAwMDAwMDEwMQphdGEzOiBhaGNpX3Jlc2V0IGRldmljZXM9MDAwMDAwMDEKYXRhMzogW01Q U0FGRV0KYXRhMzogW0lUSFJFQURdCmF0YTQ6IDxBVEEgY2hhbm5lbCAyPiBvbiBhdGFwY2kwCmF0 YTQ6IGV4ZWN1dGluZyBDTE8gZmFpbGVkCmF0YTQ6IFNBVEEgY29ubmVjdCB0aW1lPTBtcwphdGE0 OiBCVVNZIHdhaXQgdGltZT0xbXMKYXRhNDogU0lHTkFUVVJFOiAwMDAwMDEwMQphdGE0OiBhaGNp X3Jlc2V0IGRldmljZXM9MDAwMDAwMDEKYXRhNDogW01QU0FGRV0KYXRhNDogW0lUSFJFQURdCmF0 YTU6IDxBVEEgY2hhbm5lbCAzPiBvbiBhdGFwY2kwCmF0YTU6IGV4ZWN1dGluZyBDTE8gZmFpbGVk CmF0YTU6IFNBVEEgY29ubmVjdCB0aW1lPTBtcwphdGE1OiBCVVNZIHdhaXQgdGltZT0xbXMKYXRh NTogU0lHTkFUVVJFOiBlYjE0MDEwMQphdGE1OiBhaGNpX3Jlc2V0IGRldmljZXM9MDAwMTAwMDAK YXRhNTogW01QU0FGRV0KYXRhNTogW0lUSFJFQURdCmF0YTY6IDxBVEEgY2hhbm5lbCA0PiBvbiBh dGFwY2kwCmF0YTY6IFNBVEEgY29ubmVjdCBzdGF0dXM9MDAwMDAwMDAKYXRhNjogcGh5IHJlc2V0 IGZvdW5kIG5vIGRldmljZQphdGE2OiBbTVBTQUZFXQphdGE2OiBbSVRIUkVBRF0KYXRhNzogPEFU QSBjaGFubmVsIDU+IG9uIGF0YXBjaTAKYXRhNzogU0FUQSBjb25uZWN0IHN0YXR1cz0wMDAwMDAw MAphdGE3OiBwaHkgcmVzZXQgZm91bmQgbm8gZGV2aWNlCmF0YTc6IFtNUFNBRkVdCmF0YTc6IFtJ VEhSRUFEXQpwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2 ZXIgYXR0YWNoZWQpCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYXRydGMw OiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIGlycSA4IG9uIGFjcGkwCmF0cnRj MDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrIChyZXNvbHV0aW9uIDEwMDAwMDB1 cykKdWFydDA6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZs YWdzIDB4MTAgb24gYWNwaTAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gNCAoSVNBIElSUSA0KSB0 byB2ZWN0b3IgNTYKdWFydDA6IFtGSUxURVJdCnVhcnQwOiBmYXN0IGludGVycnVwdAphdGtiZGMw OiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBh Y3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2Jk MAprYmQwOiBhdGtiZDAsIGdlbmVyaWMgKDApLCBjb25maWc6MHgwLCBmbGFnczoweDNmMDAwMApp b2FwaWMwOiByb3V0aW5nIGludHBpbiAxIChJU0EgSVJRIDEpIHRvIHZlY3RvciA1NwphdGtiZDA6 IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdCnBzbTA6IHVuYWJsZSB0byBhbGxvY2F0 ZSBJUlEKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApBQ1BJIFdhcm5pbmcgKHRidXRpbHMtMDI0 Myk6IEluY29ycmVjdCBjaGVja3N1bSBpbiB0YWJsZSBbT0VNQl0gLSAgRTUsIHNob3VsZCBiZSBF NCBbMjAwNzAzMjBdCkFDUEk6IFNTRFQgQCAweDB4N2ZmOGUwZDAvMHgwMUQyICh2ICAxICAgIEFN SSAgIENQVTFQTSAweDAwMDAwMDAxIElOVEwgMHgyMDA2MDExMykKY3B1MDogc3dpdGNoaW5nIHRv IGdlbmVyaWMgQ3ggbW9kZQplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250 cm9sPiBvbiBjcHUwCmVzdDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE1NTgsIDE1Njcp CmVzdDA6IEludmFsaWQgZnJlcSAxOTk4LCBpZ25vcmVkLgpwNHRjYzA6IDxDUFUgRnJlcXVlbmN5 IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MApjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwCkFDUEk6 IFNTRFQgQCAweDB4N2ZmOGUyYjAvMHgwMTQzICh2ICAxICAgIEFNSSAgIENQVTJQTSAweDAwMDAw MDAxIElOVEwgMHgyMDA2MDExMykKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kg Q29udHJvbD4gb24gY3B1MQplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNTU4LCAx NTY3KQplc3QxOiBJbnZhbGlkIGZyZXEgMTk5OCwgaWdub3JlZC4KcDR0Y2MxOiA8Q1BVIEZyZXF1 ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApB Q1BJOiBTU0RUIEAgMHgweDdmZjhlNDAwLzB4MDE0MyAodiAgMSAgICBBTUkgICBDUFUzUE0gMHgw MDAwMDAwMSBJTlRMIDB4MjAwNjAxMTMpCmVzdDI6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVl bmN5IENvbnRyb2w+IG9uIGNwdTIKZXN0MjogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTU1 OCwgMTU2NykKZXN0MjogSW52YWxpZCBmcmVxIDE5OTgsIGlnbm9yZWQuCnA0dGNjMjogPENQVSBG cmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUyCmNwdTM6IDxBQ1BJIENQVT4gb24gYWNw aTAKQUNQSTogU1NEVCBAIDB4MHg3ZmY4ZTU1MC8weDAxNDMgKHYgIDEgICAgQU1JICAgQ1BVNFBN IDB4MDAwMDAwMDEgSU5UTCAweDIwMDYwMTEzKQplc3QzOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZy ZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUzCmVzdDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0g KDE1NTgsIDE1NjcpCmVzdDM6IEludmFsaWQgZnJlcSAxOTk4LCBpZ25vcmVkLgpwNHRjYzM6IDxD UFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MwpwbnBfaWRlbnRpZnk6IFRyeWlu ZyBSZWFkX1BvcnQgYXQgMjAzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyNDMK cG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI4MwpwbnBfaWRlbnRpZnk6IFRyeWlu ZyBSZWFkX1BvcnQgYXQgMmMzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzMDMK cG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM0MwpwbnBfaWRlbnRpZnk6IFRyeWlu ZyBSZWFkX1BvcnQgYXQgMzgzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMK UE5QIElkZW50aWZ5IGNvbXBsZXRlCmlzYV9wcm9iZV9jaGlsZHJlbjogZGlzYWJsaW5nIFBuUCBk ZXZpY2VzCmF0a2JkYzogYXRrYmRjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRydGM6 IGF0cnRjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKc2M6IHNjMCBhbHJlYWR5IGV4aXN0 czsgc2tpcHBpbmcgaXQKdWFydDogdWFydDAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnZn YTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2NoaWxkcmVuOiBw cm9iaW5nIG5vbi1QblAgZGV2aWNlcwpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgx MDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNj MDogZmIwLCBrYmQxLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2N0ZWtlbiAodGVrZW4gdGVybWluYWwp CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAw MC0weGJmZmZmIG9uIGlzYTAKYWR2MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmFoYTA6IG5vdCBw cm9iZWQgKGRpc2FibGVkKQphaWMwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKYXRhMCBhdCBwb3J0 IDB4MWYwLTB4MWY3LDB4M2Y2IGlycSAxNCBvbiBpc2EwCmF0YTA6IHJlc2V0IHRwMSBtYXNrPTAw IG9zdGF0MD1mZiBvc3RhdDE9ZmYKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTQgKElTQSBJUlEg MTQpIHRvIHZlY3RvciA1OAphdGEwOiBbTVBTQUZFXQphdGEwOiBbSVRIUkVBRF0KYXRhMSBhdCBw b3J0IDB4MTcwLTB4MTc3LDB4Mzc2IGlycSAxNSBvbiBpc2EwCmF0YTE6IHJlc2V0IHRwMSBtYXNr PTAwIG9zdGF0MD1mZiBvc3RhdDE9ZmYKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTUgKElTQSBJ UlEgMTUpIHRvIHZlY3RvciA1OQphdGExOiBbTVBTQUZFXQphdGExOiBbSVRIUkVBRF0KYnQwOiBu b3QgcHJvYmVkIChkaXNhYmxlZCkKY3MwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKZWQwOiBub3Qg cHJvYmVkIChkaXNhYmxlZCkKZmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmMCBpcnEg NiBkcnEgMiBvbiBpc2EwCmZlMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmllMDogbm90IHByb2Jl ZCAoZGlzYWJsZWQpCmxlMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCnBwYzAgZmFpbGVkIHRvIHBy b2JlIGF0IGlycSA3IG9uIGlzYTAKc24wOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdWFydDE6IDxu czgyNTA+IGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlzYTAK dWFydDI6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp1YXJ0Mzogbm90IHByb2JlZCAoZGlzYWJsZWQp CmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQblAgZGV2aWNlcwp1bXMwOiA8TG9naXRlY2gg VHJhY2tiYWxsLCBjbGFzcyAwLzAsIHJldiAxLjEwLzIuMjAsIGFkZHIgMj4gb24gdWh1YjQKdW1z MDogMyBidXR0b25zIGFuZCBaIGRpci4KdWtiZDA6IDxEZWxsIERlbGwgVVNCIEtleWJvYXJkLCBj bGFzcyAwLzAsIHJldiAxLjEwLzIuMDAsIGFkZHIgMj4gb24gdWh1YjUKa2JkMiBhdCB1a2JkMApr YmQyOiB1a2JkMCwgZ2VuZXJpYyAoMCksIGNvbmZpZzoweDAsIGZsYWdzOjB4M2QwMDAwCkRldmlj ZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLgpSZWR1Y2luZyBrZXJuLm1heHZub2RlcyAxMzM5NDkg LT4gMTAwMDAwCnByb2NmcyByZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSAx NjY5NzYwNTMgaHoKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDI2NzE2MTY3ODQgSHogcXVh bGl0eSAtMTAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKTGludXggRUxGIGV4 ZWMgaGFuZGxlciBpbnN0YWxsZWQKbG8wOiBicGYgYXR0YWNoZWQKYXRhMDogaWRlbnRpZnkgY2gt PmRldmljZXM9MDAwMDAwMDAKZmlyZXdpcmUwOiAxIG5vZGVzLCBtYXhob3AgPD0gMCwgY2FibGUg SVJNID0gMCAobWUpCmZpcmV3aXJlMDogYnVzIG1hbmFnZXIgMCAobWUpCmF0YTE6IGlkZW50aWZ5 IGNoLT5kZXZpY2VzPTAwMDAwMDAwCmF0YTI6IGlkZW50aWZ5IGNoLT5kZXZpY2VzPTAwMDAwMDAw CmF0YTM6IGlkZW50aWZ5IGNoLT5kZXZpY2VzPTAwMDAwMDAxCmF0YTMtbWFzdGVyOiBwaW89UElP NCB3ZG1hPVdETUEyIHVkbWE9VURNQTEzMyBjYWJsZT00MCB3aXJlCmFkNjogNDc2OTQwTUIgPFNl YWdhdGUgU1QzNTAwMzIwQVMgU0QxNT4gYXQgYXRhMy1tYXN0ZXIgU0FUQTE1MAphZDY6IDk3Njc3 MzE2OCBzZWN0b3JzIFs5NjkwMjFDLzE2SC82M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVw dGggcXVldWUKR0VPTTogbmV3IGRpc2sgYWQ2CmF0YTQ6IGlkZW50aWZ5IGNoLT5kZXZpY2VzPTAw MDAwMDAxCmF0YTQtbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEzMyBjYWJs ZT00MCB3aXJlCmFkODogMzA1MjQ1TUIgPFdEQyBXRDMyMDBBQUpTLTAwUllBMCAxMi4wMUIwMT4g YXQgYXRhNC1tYXN0ZXIgU0FUQTMwMAphZDg6IDYyNTE0MjQ0OCBzZWN0b3JzIFs2MjAxODFDLzE2 SC82M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVwdGggcXVldWUKYXRhNTogaWRlbnRpZnkg Y2gtPmRldmljZXM9MDAwMTAwMDAKYXRhNS1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRt YT1VRE1BMTMzIGNhYmxlPTQwIHdpcmUKYXRhNTogZGV2aWNlX3Jlc2V0IHRpbWVvdXQ9NzIxMHVz CmFjZDA6IDxITC1EVC1TVCBCRERWRFJXIEdHQy1IMjBMLzEuMDM+IERWRFIgZHJpdmUgYXQgYXRh NSBhcyBtYXN0ZXIKYWNkMDogcmVhZCA2NDkyS0IvcyAoNjQ5MktCL3MpIHdyaXRlIDY4OTBLQi9z ICg2ODkwS0IvcyksIDIwNDhLQiBidWZmZXIsIFNBVEExNTAKYWNkMDogUmVhZHM6IENEUiwgQ0RS VywgQ0REQSBzdHJlYW0sIERWRFJPTSwgRFZEUiwgRFZEUkFNLCBwYWNrZXQKYWNkMDogV3JpdGVz OiBDRFIsIENEUlcsIERWRFIsIERWRFJBTSwgdGVzdCB3cml0ZSwgYnVybnByb29mCmFjZDA6IEF1 ZGlvOiBwbGF5LCAyNTYgdm9sdW1lIGxldmVscwphY2QwOiBNZWNoYW5pc206IGVqZWN0YWJsZSB0 cmF5LCB1bmxvY2tlZAphY2QwOiBNZWRpdW06IERWRCAxMjBtbSBkYXRhIGRpc2MKYXRhNjogaWRl bnRpZnkgY2gtPmRldmljZXM9MDAwMDAwMDAKYXRhNzogaWRlbnRpZnkgY2gtPmRldmljZXM9MDAw MDAwMDAKaGRhYzA6IFByb2JpbmcgY29kZWMgIzAuLi4KaGRhYzA6IEhEQSBDb2RlYyAjMDogQW5h bG9nIERldmljZXMgQUQxOTg4QgpoZGFjMDogIEhEQSBDb2RlYyBJRDogMHgxMWQ0MTk4YgpoZGFj MDogICAgICAgIFZlbmRvcjogMHgxMWQ0CmhkYWMwOiAgICAgICAgRGV2aWNlOiAweDE5OGIKaGRh YzA6ICAgICAgUmV2aXNpb246IDB4MDQKaGRhYzA6ICAgICAgU3RlcHBpbmc6IDB4MDAKaGRhYzA6 IFBDSSBTdWJ2ZW5kb3I6IDB4ODI3NzEwNDMKaGRhYzA6IAlGb3VuZCBhdWRpbyBGRyBuaWQ9MSBz dGFydG5vZGU9MiBlbmRub2RlPTYyIHRvdGFsPTYwCmhkYWMwOiAKaGRhYzA6IFByb2Nlc3Npbmcg YXVkaW8gRkcgY2FkPTAgbmlkPTEuLi4KaGRhYzA6IEdQSU86IDB4NDAwMDAwMDIgTnVtR1BJTz0y IE51bUdQTz0wIE51bUdQST0wIEdQSVdha2U9MCBHUElVbnNvbD0xCmhkYWMwOiAgbmlkIDE3IDB4 MDIyMTQwMzAgYXMgIDMgc2VxICAwICAgIEhlYWRwaG9uZXMgIEphY2sgamFjayAgMSBsb2MgIDIg Y29sb3IgICBHcmVlbiBtaXNjIDAKaGRhYzA6ICBuaWQgMTggMHgwMTAxNDAxMCBhcyAgMSBzZXEg IDAgICAgICBMaW5lLW91dCAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xvciAgIEdyZWVuIG1pc2Mg MApoZGFjMDogIG5pZCAxOSAweDUxMTcxMWYwIGFzIDE1IHNlcSAgMCAgICAgICBTcGVha2VyICBO b25lIGphY2sgIDcgbG9jIDE3IGNvbG9yICAgQmxhY2sgbWlzYyAxCmhkYWMwOiAgbmlkIDIwIDB4 MDJhMTkwMmUgYXMgIDIgc2VxIDE0ICAgICAgICAgICBNaWMgIEphY2sgamFjayAgMSBsb2MgIDIg Y29sb3IgICAgUGluayBtaXNjIDAKaGRhYzA6ICBuaWQgMjEgMHgwMTgxMzAyMSBhcyAgMiBzZXEg IDEgICAgICAgTGluZS1pbiAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xvciAgICBCbHVlIG1pc2Mg MApoZGFjMDogIG5pZCAyMiAweDAxMDExMDEyIGFzICAxIHNlcSAgMiAgICAgIExpbmUtb3V0ICBK YWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgQmxhY2sgbWlzYyAwCmhkYWMwOiAgbmlkIDIzIDB4 MDFhMTkwMjAgYXMgIDIgc2VxICAwICAgICAgICAgICBNaWMgIEphY2sgamFjayAgMSBsb2MgIDEg Y29sb3IgICAgUGluayBtaXNjIDAKaGRhYzA6ICBuaWQgMjQgMHg5OTMzMTEyMiBhcyAgMiBzZXEg IDIgICAgICAgICAgICBDRCBGaXhlZCBqYWNrICAzIGxvYyAyNSBjb2xvciAgIEJsYWNrIG1pc2Mg MQpoZGFjMDogUGF0Y2hpbmcgd2lkZ2V0IGNhcHMgbmlkPTI2IDB4MDA0MDAwMDAgLT4gMHgwMDcw MDAwMApoZGFjMDogIG5pZCAyNyAweDAxNDVmMWYwIGFzIDE1IHNlcSAgMCAgICAgU1BESUYtb3V0 ICBKYWNrIGphY2sgIDUgbG9jICAxIGNvbG9yICAgT3RoZXIgbWlzYyAxCmhkYWMwOiAgbmlkIDI4 IDB4NDFjNWYxZjAgYXMgMTUgc2VxICAwICAgICAgU1BESUYtaW4gIE5vbmUgamFjayAgNSBsb2Mg IDEgY29sb3IgICBPdGhlciBtaXNjIDEKaGRhYzA6IEdIT1NUOiBuaWQ9Mjkgaj0wIGVudG51bT00 IGluZGV4PTAgcmVzPTB4MDAwMDBiMDEKaGRhYzA6ICBuaWQgMzYgMHgwMTAxNjAxMSBhcyAgMSBz ZXEgIDEgICAgICBMaW5lLW91dCAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xvciAgT3JhbmdlIG1p c2MgMApoZGFjMDogIG5pZCAzNyAweDAxMDEyMDE0IGFzICAxIHNlcSAgNCAgICAgIExpbmUtb3V0 ICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgIEdyZXkgbWlzYyAwCmhkYWMwOiBQYXRjaGVk IHBpbnMgY29uZmlndXJhdGlvbjoKaGRhYzA6ICBuaWQgMTcgMHgwMjIxNDAzMCBhcyAgMyBzZXEg IDAgICAgSGVhZHBob25lcyAgSmFjayBqYWNrICAxIGxvYyAgMiBjb2xvciAgIEdyZWVuIG1pc2Mg MApoZGFjMDogIG5pZCAxOCAweDAxMDE0MDEwIGFzICAxIHNlcSAgMCAgICAgIExpbmUtb3V0ICBK YWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgR3JlZW4gbWlzYyAwCmhkYWMwOiAgbmlkIDE5IDB4 NTExNzExZjAgYXMgMTUgc2VxICAwICAgICAgIFNwZWFrZXIgIE5vbmUgamFjayAgNyBsb2MgMTcg Y29sb3IgICBCbGFjayBtaXNjIDEgW0RJU0FCTEVEXQpoZGFjMDogIG5pZCAyMCAweDAyYTE5MDJl IGFzICAyIHNlcSAxNCAgICAgICAgICAgTWljICBKYWNrIGphY2sgIDEgbG9jICAyIGNvbG9yICAg IFBpbmsgbWlzYyAwCmhkYWMwOiAgbmlkIDIxIDB4MDE4MTMwMjEgYXMgIDIgc2VxICAxICAgICAg IExpbmUtaW4gIEphY2sgamFjayAgMSBsb2MgIDEgY29sb3IgICAgQmx1ZSBtaXNjIDAKaGRhYzA6 ICBuaWQgMjIgMHgwMTAxMTAxMiBhcyAgMSBzZXEgIDIgICAgICBMaW5lLW91dCAgSmFjayBqYWNr ICAxIGxvYyAgMSBjb2xvciAgIEJsYWNrIG1pc2MgMApoZGFjMDogIG5pZCAyMyAweDAxYTE5MDIw IGFzICAyIHNlcSAgMCAgICAgICAgICAgTWljICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAg IFBpbmsgbWlzYyAwCmhkYWMwOiAgbmlkIDI0IDB4OTkzMzExMjIgYXMgIDIgc2VxICAyICAgICAg ICAgICAgQ0QgRml4ZWQgamFjayAgMyBsb2MgMjUgY29sb3IgICBCbGFjayBtaXNjIDEKaGRhYzA6 ICBuaWQgMjcgMHgwMTQ1ZjFmMCBhcyAxNSBzZXEgIDAgICAgIFNQRElGLW91dCAgSmFjayBqYWNr ICA1IGxvYyAgMSBjb2xvciAgIE90aGVyIG1pc2MgMQpoZGFjMDogIG5pZCAyOCAweDQxYzVmMWYw IGFzIDE1IHNlcSAgMCAgICAgIFNQRElGLWluICBOb25lIGphY2sgIDUgbG9jICAxIGNvbG9yICAg T3RoZXIgbWlzYyAxIFtESVNBQkxFRF0KaGRhYzA6ICBuaWQgMzYgMHgwMTAxNjAxMSBhcyAgMSBz ZXEgIDEgICAgICBMaW5lLW91dCAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xvciAgT3JhbmdlIG1p c2MgMApoZGFjMDogIG5pZCAzNyAweDAxMDEyMDE0IGFzICAxIHNlcSAgNCAgICAgIExpbmUtb3V0 ICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgIEdyZXkgbWlzYyAwCmhkYWMwOiA0IGFzc29j aWF0aW9ucyBmb3VuZDoKaGRhYzA6IEFzc29jaWF0aW9uIDAgKDEpIG91dDoKaGRhYzA6ICBQaW4g bmlkPTE4IHNlcT0wCmhkYWMwOiAgUGluIG5pZD0zNiBzZXE9MQpoZGFjMDogIFBpbiBuaWQ9MjIg c2VxPTIKaGRhYzA6ICBQaW4gbmlkPTM3IHNlcT00CmhkYWMwOiBBc3NvY2lhdGlvbiAxICgyKSBp bjoKaGRhYzA6ICBQaW4gbmlkPTIzIHNlcT0wCmhkYWMwOiAgUGluIG5pZD0yMSBzZXE9MQpoZGFj MDogIFBpbiBuaWQ9MjQgc2VxPTIKaGRhYzA6ICBQaW4gbmlkPTIwIHNlcT0xNApoZGFjMDogQXNz b2NpYXRpb24gMiAoMykgb3V0OgpoZGFjMDogIFBpbiBuaWQ9MTcgc2VxPTAKaGRhYzA6IEFzc29j aWF0aW9uIDMgKDE1KSBvdXQ6CmhkYWMwOiAgUGluIG5pZD0yNyBzZXE9MApoZGFjMDogVHJhY2lu ZyBhc3NvY2lhdGlvbiAwICgxKQpoZGFjMDogIFBpbiAxOCB0cmFjZWQgdG8gREFDIDQKaGRhYzA6 ICBQaW4gMzYgdHJhY2VkIHRvIERBQyA1CmhkYWMwOiAgUGluIDIyIHRyYWNlZCB0byBEQUMgNgpo ZGFjMDogIFBpbiAzNyB0cmFjZWQgdG8gREFDIDEwCmhkYWMwOiBBc3NvY2lhdGlvbiAwICgxKSB0 cmFjZSBzdWNjZWRlZApoZGFjMDogVHJhY2luZyBhc3NvY2lhdGlvbiAxICgyKQpoZGFjMDogIFVu YWJsZSB0byB0cmFjZSBwaW4gMjMgdG8gQURDIDcsIHVuZG8gdHJhY2VzCmhkYWMwOiAgUGluIDIz IHRyYWNlZCB0byBBREMgOApoZGFjMDogIFBpbiAyMSB0cmFjZWQgdG8gQURDIDgKaGRhYzA6ICBQ aW4gMjQgdHJhY2VkIHRvIEFEQyA4CmhkYWMwOiAgUGluIDIwIHRyYWNlZCB0byBBREMgOApoZGFj MDogQXNzb2NpYXRpb24gMSAoMikgdHJhY2Ugc3VjY2VkZWQKaGRhYzA6IFRyYWNpbmcgYXNzb2Np YXRpb24gMiAoMykKaGRhYzA6ICBQaW4gMTcgdHJhY2VkIHRvIERBQyAzCmhkYWMwOiBBc3NvY2lh dGlvbiAyICgzKSB0cmFjZSBzdWNjZWRlZApoZGFjMDogVHJhY2luZyBhc3NvY2lhdGlvbiAzICgx NSkKaGRhYzA6ICBQaW4gMjcgdHJhY2VkIHRvIERBQyAyCmhkYWMwOiBBc3NvY2lhdGlvbiAzICgx NSkgdHJhY2Ugc3VjY2VkZWQKaGRhYzA6IFRyYWNpbmcgaW5wdXQgbW9uaXRvcgpoZGFjMDogIFRy YWNpbmcgbmlkIDMyIHRvIG91dApoZGFjMDogIG5pZCAzMiBpcyBpbnB1dCBtb25pdG9yCmhkYWMw OiBUcmFjaW5nIGJlZXBlcgpoZGFjMDogIG5pZCAyNiB0cmFjZWQgdG8gb3V0CmhkYWMwOiBGRyBj b25maWcvcXVpcmtzOiBmb3JjZXN0ZXJlbyBpdnJlZjgwCmhkYWMwOiAKaGRhYzA6ICstLS0tLS0t LS0tLS0tLS0tLS0tKwpoZGFjMDogfCBEVU1QSU5HIEhEQSBOT0RFUyB8CmhkYWMwOiArLS0tLS0t LS0tLS0tLS0tLS0tLSsKaGRhYzA6IApoZGFjMDogRGVmYXVsdCBQYXJhbWV0ZXIKaGRhYzA6IC0t LS0tLS0tLS0tLS0tLS0tCmhkYWMwOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEKaGRhYzA6 ICAgICAgICAgICAgICAgICAgUENNCmhkYWMwOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3ZmYK aGRhYzA6ICAgICAgICAgICAgICAgICAgMTYgMjAgMjQgYml0cywgOCAxMSAxNiAyMiAzMiA0NCA0 OCA4OCA5NiAxNzYgMTkyIEtIegpoZGFjMDogICAgICAgICAgSU4gYW1wOiAweDgwMDAwMDAwCmhk YWMwOiAgICAgICAgIE9VVCBhbXA6IDB4MDAwNTI3MjcKaGRhYzA6IApoZGFjMDogICAgICAgICAg ICAgbmlkOiAyCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG91dHB1dApoZGFjMDogICAg ICBXaWRnZXQgY2FwOiAweDAwMDMwMzExCmhkYWMwOiAgICAgICAgICAgICAgICAgIERJR0lUQUwg U1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDMgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAg ICAgICAgICBPU1M6IHBjbSAocGNtKQpoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDA1 CmhkYWMwOiAgICAgICAgICAgICAgICAgIEFDMyBQQ00KaGRhYzA6ICAgICAgICAgUENNIGNhcDog MHgwMDBlMDdlMApoZGFjMDogICAgICAgICAgICAgICAgICAxNiAyMCAyNCBiaXRzLCA0NCA0OCA4 OCA5NiAxNzYgMTkyIEtIegpoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAxCmhkYWMwOiAgICAgICAg ICAgfApoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjkgW2F1ZGlvIG1peGVy XSBbRElTQUJMRURdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMwpoZGFjMDogICAg ICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDAw MDQwNQpoZGFjMDogICAgICAgICAgICAgICAgICBQV1IgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2Np YXRpb246IDIgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSAocGNtKQpo ZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCmhkYWMwOiAgICAgICAgICAgICAgICAg IFBDTQpoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwN2ZmCmhkYWMwOiAgICAgICAgICAg ICAgICAgIDE2IDIwIDI0IGJpdHMsIDggMTEgMTYgMjIgMzIgNDQgNDggODggOTYgMTc2IDE5MiBL SHoKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDA1MjcyNwpoZGFjMDogICAgICAgICAgICAg ICAgICBtdXRlPTAgc3RlcD0zOSBzaXplPTUgb2Zmc2V0PTM5CmhkYWMwOiAKaGRhYzA6ICAgICAg ICAgICAgIG5pZDogNApoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKaGRhYzA6 ICAgICAgV2lkZ2V0IGNhcDogMHgwMDAwMDQwNQpoZGFjMDogICAgICAgICAgICAgICAgICBQV1Ig U1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAg ICAgICAgICBPU1M6IHBjbSAocGNtKQpoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAx CmhkYWMwOiAgICAgICAgICAgICAgICAgIFBDTQpoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAw MGUwN2ZmCmhkYWMwOiAgICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDggMTEgMTYgMjIg MzIgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDA1 MjcyNwpoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zOSBzaXplPTUgb2Zmc2V0 PTM5CmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNQpoZGFjMDogICAgICAgICAgICBO YW1lOiBhdWRpbyBvdXRwdXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDAwMDQwNQpoZGFj MDogICAgICAgICAgICAgICAgICBQV1IgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDAg KDB4MDAwMDAwMDIpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSAocGNtKQpoZGFjMDogICAg ICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCmhkYWMwOiAgICAgICAgICAgICAgICAgIFBDTQpoZGFj MDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwN2ZmCmhkYWMwOiAgICAgICAgICAgICAgICAgIDE2 IDIwIDI0IGJpdHMsIDggMTEgMTYgMjIgMzIgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKaGRhYzA6 ICAgICAgT3V0cHV0IGFtcDogMHgwMDA1MjcyNwpoZGFjMDogICAgICAgICAgICAgICAgICBtdXRl PTAgc3RlcD0zOSBzaXplPTUgb2Zmc2V0PTM5CmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5p ZDogNgpoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKaGRhYzA6ICAgICAgV2lk Z2V0IGNhcDogMHgwMDAwMDQwNQpoZGFjMDogICAgICAgICAgICAgICAgICBQV1IgU1RFUkVPCmhk YWMwOiAgICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDAwMDQpCmhkYWMwOiAgICAgICAgICAgICBP U1M6IHBjbSAocGNtKQpoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCmhkYWMwOiAg ICAgICAgICAgICAgICAgIFBDTQpoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwN2ZmCmhk YWMwOiAgICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDggMTEgMTYgMjIgMzIgNDQgNDgg ODggOTYgMTc2IDE5MiBLSHoKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDA1MjcyNwpoZGFj MDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zOSBzaXplPTUgb2Zmc2V0PTM5CmhkYWMw OiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNyBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAg IE5hbWU6IGF1ZGlvIGlucHV0CmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAxMzAzOTEKaGRh YzA6ICAgICAgICAgICAgICAgICAgRElHSVRBTCBVTlNPTCBTVEVSRU8KaGRhYzA6ICAgICAgU3Ry ZWFtIGNhcDogMHgwMDAwMDAwNQpoZGFjMDogICAgICAgICAgICAgICAgICBBQzMgUENNCmhkYWMw OiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3ZTAKaGRhYzA6ICAgICAgICAgICAgICAgICAgMTYg MjAgMjQgYml0cywgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKaGRhYzA6ICAgICBjb25uZWN0aW9u czogMQpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0g bmlkPTI4IFtwaW46IFNQRElGLWluIChOb25lKV0gW0RJU0FCTEVEXQpoZGFjMDogCmhkYWMwOiAg ICAgICAgICAgICBuaWQ6IDgKaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gaW5wdXQKaGRh YzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDEwMDUwMQpoZGFjMDogICAgICAgICAgICAgICAgICBQ V1IgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDEgKDB4MDAwMDQwMDcpCmhkYWMwOiAg ICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEKaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCmhk YWMwOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3ZmYKaGRhYzA6ICAgICAgICAgICAgICAgICAg MTYgMjAgMjQgYml0cywgOCAxMSAxNiAyMiAzMiA0NCA0OCA4OCA5NiAxNzYgMTkyIEtIegpoZGFj MDogICAgIGNvbm5lY3Rpb25zOiAxCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAg ICsgPC0gbmlkPTEyIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAg bmlkOiA5IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gaW5wdXQKaGRh YzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDEwMDUwMQpoZGFjMDogICAgICAgICAgICAgICAgICBQ V1IgU1RFUkVPCmhkYWMwOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEKaGRhYzA6ICAgICAg ICAgICAgICAgICAgUENNCmhkYWMwOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3ZmYKaGRhYzA6 ICAgICAgICAgICAgICAgICAgMTYgMjAgMjQgYml0cywgOCAxMSAxNiAyMiAzMiA0NCA0OCA4OCA5 NiAxNzYgMTkyIEtIegpoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAxCmhkYWMwOiAgICAgICAgICAg fApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTEzIFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVE XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDEwCmhkYWMwOiAgICAgICAgICAgIE5h bWU6IGF1ZGlvIG91dHB1dApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMDAwNDA1CmhkYWMw OiAgICAgICAgICAgICAgICAgIFBXUiBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMCAo MHgwMDAwMDAxMCkKaGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtIChwY20pCmhkYWMwOiAgICAg IFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEKaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCmhkYWMw OiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3ZmYKaGRhYzA6ICAgICAgICAgICAgICAgICAgMTYg MjAgMjQgYml0cywgOCAxMSAxNiAyMiAzMiA0NCA0OCA4OCA5NiAxNzYgMTkyIEtIegpoZGFjMDog ICAgICBPdXRwdXQgYW1wOiAweDAwMDUyNzI3CmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9 MCBzdGVwPTM5IHNpemU9NSBvZmZzZXQ9MzkKaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlk OiAxMSBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhk YWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAzMDAzMDEKaGRhYzA6ICAgICAgICAgICAgICAgICAg RElHSVRBTCBTVEVSRU8KaGRhYzA6ICAgICBjb25uZWN0aW9uczogMwpoZGFjMDogICAgICAgICAg IHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD04IFthdWRpbyBpbnB1dF0gKHNlbGVjdGVkKQpo ZGFjMDogICAgICAgICAgICsgPC0gbmlkPTkgW2F1ZGlvIGlucHV0XSBbRElTQUJMRURdCmhkYWMw OiAgICAgICAgICAgKyA8LSBuaWQ9MTUgW2F1ZGlvIGlucHV0XSBbRElTQUJMRURdCmhkYWMwOiAK aGRhYzA6ICAgICAgICAgICAgIG5pZDogMTIKaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8g c2VsZWN0b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwZApoZGFjMDogICAgICAg ICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMSAoMHgwMDAwNDAwNykK aGRhYzA6ICAgICAgICAgICAgIE9TUzogbGluZSwgbWljLCBjZCwgbWl4LCBtb25pdG9yCmhkYWMw OiAgICAgIE91dHB1dCBhbXA6IDB4ODAwNTM2MjcKaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0 ZT0xIHN0ZXA9NTQgc2l6ZT01IG9mZnNldD0zOQpoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAxMApo ZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTU2 IFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVEXQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTU3 IFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01OCBbYXVkaW8gc2Vs ZWN0b3JdCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD01OSBbYXVkaW8gc2Vs ZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD02MCBbYXVkaW8gc2Vs ZWN0b3JdIChzZWxlY3RlZCkKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yNCBbcGluOiBDRCAo Rml4ZWQpXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MzYgW3BpbjogTGlu ZS1vdXQgKEphY2spXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MzcgW3Bp bjogTGluZS1vdXQgKEphY2spXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9 NjEgW2F1ZGlvIHNlbGVjdG9yXSBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9 MzIgW2F1ZGlvIG1peGVyXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDEzIFtESVNB QkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gc2VsZWN0b3IKaGRhYzA6ICAgICAg V2lkZ2V0IGNhcDogMHgwMDMwMDEwZApoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRh YzA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDA1MzYyNwpoZGFjMDogICAgICAgICAgICAgICAgICBt dXRlPTEgc3RlcD01NCBzaXplPTUgb2Zmc2V0PTM5CmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEw CmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTU2IFthdWRpbyBz ZWxlY3Rvcl0gW0RJU0FCTEVEXSAoc2VsZWN0ZWQpCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9 NTcgW2F1ZGlvIHNlbGVjdG9yXQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTU4IFthdWRpbyBz ZWxlY3Rvcl0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01OSBbYXVkaW8gc2VsZWN0b3JdIFtE SVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD02MCBbYXVkaW8gc2VsZWN0b3JdCmhk YWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MjQgW3BpbjogQ0QgKEZpeGVkKV0KaGRhYzA6ICAgICAg ICAgICArIDwtIG5pZD0zNiBbcGluOiBMaW5lLW91dCAoSmFjayldCmhkYWMwOiAgICAgICAgICAg KyA8LSBuaWQ9MzcgW3BpbjogTGluZS1vdXQgKEphY2spXQpoZGFjMDogICAgICAgICAgICsgPC0g bmlkPTYxIFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVEXQpoZGFjMDogICAgICAgICAgICsgPC0g bmlkPTMyIFthdWRpbyBtaXhlcl0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiAxNCBb RElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMwOiAg ICAgIFdpZGdldCBjYXA6IDB4MDAzMDAxMGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVP CmhkYWMwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwNTM2MjcKaGRhYzA6ICAgICAgICAgICAgICAg ICAgbXV0ZT0xIHN0ZXA9NTQgc2l6ZT01IG9mZnNldD0zOQpoZGFjMDogICAgIGNvbm5lY3Rpb25z OiAxMApoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01NiBbYXVk aW8gc2VsZWN0b3JdIFtESVNBQkxFRF0gKHNlbGVjdGVkKQpoZGFjMDogICAgICAgICAgICsgPC0g bmlkPTU3IFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01OCBbYXVk aW8gc2VsZWN0b3JdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9NTkgW2F1ZGlvIHNlbGVjdG9y XSBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9NjAgW2F1ZGlvIHNlbGVjdG9y XQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTI0IFtwaW46IENEIChGaXhlZCldCmhkYWMwOiAg ICAgICAgICAgKyA8LSBuaWQ9MzYgW3BpbjogTGluZS1vdXQgKEphY2spXQpoZGFjMDogICAgICAg ICAgICsgPC0gbmlkPTM3IFtwaW46IExpbmUtb3V0IChKYWNrKV0KaGRhYzA6ICAgICAgICAgICAr IDwtIG5pZD02MSBbYXVkaW8gc2VsZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAr IDwtIG5pZD0zMiBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDog MTUgW0RJU0FCTEVEXQpoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBpbnB1dApoZGFjMDog ICAgICBXaWRnZXQgY2FwOiAweDAwMTAwNTAxCmhkYWMwOiAgICAgICAgICAgICAgICAgIFBXUiBT VEVSRU8KaGRhYzA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpoZGFjMDogICAgICAgICAg ICAgICAgICBQQ00KaGRhYzA6ICAgICAgICAgUENNIGNhcDogMHgwMDBlMDdmZgpoZGFjMDogICAg ICAgICAgICAgICAgICAxNiAyMCAyNCBiaXRzLCA4IDExIDE2IDIyIDMyIDQ0IDQ4IDg4IDk2IDE3 NiAxOTIgS0h6CmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6ICAgICAgICAgICB8Cmhk YWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTQgW2F1ZGlvIHNlbGVjdG9yXSBbRElTQUJMRURdCmhk YWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMTYKaGRhYzA6ICAgICAgICAgICAgTmFtZTog YmVlcCB3aWRnZXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDcwMDAwYwpoZGFjMDogICAg IEFzc29jaWF0aW9uOiAtMiAoMHgwMDAwMDAwMCkKaGRhYzA6ICAgICAgICAgICAgIE9TUzogc3Bl YWtlciAoc3BlYWtlcikKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDBiMGYwZgpoZGFjMDog ICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0xNSBzaXplPTExIG9mZnNldD0xNQpoZGFjMDog CmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDE3CmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjog SGVhZHBob25lcyAoSmFjaykKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDE4ZApoZGFj MDogICAgICAgICAgICAgICAgICBVTlNPTCBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjog MiAoMHgwMDAwMDAwMSkKaGRhYzA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMzczZgpoZGFjMDog ICAgICAgICAgICAgICAgICBJU0MgVFJRRCBQREMgSFAgT1VUIElOIFZSRUZbIDUwIDgwIDEwMCBH Uk9VTkQgSElaIF0KaGRhYzA6ICAgICAgUGluIGNvbmZpZzogMHgwMjIxNDAzMApoZGFjMDogICAg IFBpbiBjb250cm9sOiAweDAwMDAwMGMwIEhQIE9VVApoZGFjMDogICAgICBPdXRwdXQgYW1wOiAw eDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9m ZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6ICAgICAgICAgICB8CmhkYWMw OiAgICAgICAgICAgKyA8LSBuaWQ9MzQgW2F1ZGlvIG1peGVyXQpoZGFjMDogCmhkYWMwOiAgICAg ICAgICAgICBuaWQ6IDE4CmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogTGluZS1vdXQgKEph Y2spCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAxOGQKaGRhYzA6ICAgICAgICAgICAg ICAgICAgVU5TT0wgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDAwMDEp CmhkYWMwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDM3M2YKaGRhYzA6ICAgICAgICAgICAgICAg ICAgSVNDIFRSUUQgUERDIEhQIE9VVCBJTiBWUkVGWyA1MCA4MCAxMDAgR1JPVU5EIEhJWiBdCmhk YWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDEwMTQwMTAKaGRhYzA6ICAgICBQaW4gY29udHJvbDog MHgwMDAwMDA0MCBPVVQKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDAwMDAwMApoZGFjMDog ICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFjMDogICAg IGNvbm5lY3Rpb25zOiAxCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgPC0g bmlkPTQxIFthdWRpbyBtaXhlcl0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiAxOSBb RElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogU3BlYWtlciAoTm9uZSkKaGRh YzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDEwYwpoZGFjMDogICAgICAgICBQaW4gY2FwOiAw eDAwMDAwMDEwCmhkYWMwOiAgICAgICAgICAgICAgICAgIE9VVApoZGFjMDogICAgICBQaW4gY29u ZmlnOiAweDUxMTcxMWYwCmhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwMDAKaGRhYzA6 ICAgICAgT3V0cHV0IGFtcDogMHg4MDA1MWYxZgpoZGFjMDogICAgICAgICAgICAgICAgICBtdXRl PTEgc3RlcD0zMSBzaXplPTUgb2Zmc2V0PTMxCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRh YzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD00NSBb YXVkaW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiAy MApoZGFjMDogICAgICAgICAgICBOYW1lOiBwaW46IE1pYyAoSmFjaykKaGRhYzA6ICAgICAgV2lk Z2V0IGNhcDogMHgwMDQwMDE4ZApoZGFjMDogICAgICAgICAgICAgICAgICBVTlNPTCBTVEVSRU8K aGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMSAoMHgwMDAwNDAwMCkKaGRhYzA6ICAgICAgICAgICAg IE9TUzogbWljIChtaWMpCmhkYWMwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDM3M2YKaGRhYzA6 ICAgICAgICAgICAgICAgICAgSVNDIFRSUUQgUERDIEhQIE9VVCBJTiBWUkVGWyA1MCA4MCAxMDAg R1JPVU5EIEhJWiBdCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDJhMTkwMmUKaGRhYzA6ICAg ICBQaW4gY29udHJvbDogMHgwMDAwMDAyNCBJTiBWUkVGcwpoZGFjMDogICAgICBPdXRwdXQgYW1w OiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0w IG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6ICAgICAgICAgICB8Cmhk YWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD00MyBbYXVkaW8gbWl4ZXJdIFtESVNB QkxFRF0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiAyMQpoZGFjMDogICAgICAgICAg ICBOYW1lOiBwaW46IExpbmUtaW4gKEphY2spCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0 MDAxOGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgVU5TT0wgU1RFUkVPCmhkYWMwOiAgICAgQXNz b2NpYXRpb246IDEgKDB4MDAwMDAwMDIpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IGxpbmUgKGxp bmUpCmhkYWMwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDM3MzcKaGRhYzA6ICAgICAgICAgICAg ICAgICAgSVNDIFRSUUQgUERDIE9VVCBJTiBWUkVGWyA1MCA4MCAxMDAgR1JPVU5EIEhJWiBdCmhk YWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDE4MTMwMjEKaGRhYzA6ICAgICBQaW4gY29udHJvbDog MHgwMDAwMDAyNCBJTiBWUkVGcwpoZGFjMDogICAgICBPdXRwdXQgYW1wOiAweDgwMDAwMDAwCmhk YWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMw OiAgICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAg KyBbRElTQUJMRURdIDwtIG5pZD00NCBbYXVkaW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYzA6IApo ZGFjMDogICAgICAgICAgICAgbmlkOiAyMgpoZGFjMDogICAgICAgICAgICBOYW1lOiBwaW46IExp bmUtb3V0IChKYWNrKQpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwNDAwMThkCmhkYWMwOiAg ICAgICAgICAgICAgICAgIFVOU09MIFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAwICgw eDAwMDAwMDA0KQpoZGFjMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAzNzM3CmhkYWMwOiAgICAg ICAgICAgICAgICAgIElTQyBUUlFEIFBEQyBPVVQgSU4gVlJFRlsgNTAgODAgMTAwIEdST1VORCBI SVogXQpoZGFjMDogICAgICBQaW4gY29uZmlnOiAweDAxMDExMDEyCmhkYWMwOiAgICAgUGluIGNv bnRyb2w6IDB4MDAwMDAwNDAgT1VUCmhkYWMwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwMDAwMDAK aGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRh YzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAg ICArIDwtIG5pZD00MiBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5p ZDogMjMKaGRhYzA6ICAgICAgICAgICAgTmFtZTogcGluOiBNaWMgKEphY2spCmhkYWMwOiAgICAg IFdpZGdldCBjYXA6IDB4MDA0MDA5OGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgTFJTV0FQIFVO U09MIFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAxICgweDAwMDAwMDAxKQpoZGFjMDog ICAgICAgICAgICAgT1NTOiBtb25pdG9yIChtb25pdG9yKQpoZGFjMDogICAgICAgICBQaW4gY2Fw OiAweDAwMDAzNzM3CmhkYWMwOiAgICAgICAgICAgICAgICAgIElTQyBUUlFEIFBEQyBPVVQgSU4g VlJFRlsgNTAgODAgMTAwIEdST1VORCBISVogXQpoZGFjMDogICAgICBQaW4gY29uZmlnOiAweDAx YTE5MDIwCmhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwMjQgSU4gVlJFRnMKaGRhYzA6 ICAgICAgT3V0cHV0IGFtcDogMHg4MDAwMDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRl PTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAxCmhkYWMw OiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MzggW2F1 ZGlvIG1peGVyXSBbRElTQUJMRURdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMjQK aGRhYzA6ICAgICAgICAgICAgTmFtZTogcGluOiBDRCAoRml4ZWQpCmhkYWMwOiAgICAgIFdpZGdl dCBjYXA6IDB4MDA0MDAwMDEKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAg ICAgQXNzb2NpYXRpb246IDEgKDB4MDAwMDAwMDQpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IGNk IChjZCkKaGRhYzA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMDAyMApoZGFjMDogICAgICAgICAg ICAgICAgICBJTgpoZGFjMDogICAgICBQaW4gY29uZmlnOiAweDk5MzMxMTIyCmhkYWMwOiAgICAg UGluIGNvbnRyb2w6IDB4MDAwMDAwMjAgSU4KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlk OiAyNSBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBvd2VyIHdpZGdldApoZGFj MDogICAgICBXaWRnZXQgY2FwOiAweDAwNTAwNTAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIFBX UgpoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAyCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAg ICAgICAgICsgPC0gbmlkPTMyIFthdWRpbyBtaXhlcl0gKHNlbGVjdGVkKQpoZGFjMDogICAgICAg ICAgICsgPC0gbmlkPTMzIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6IApoZGFjMDogICAgICAgICAg ICAgbmlkOiAyNgpoZGFjMDogICAgICAgICAgICBOYW1lOiBiZWVwIHdpZGdldApoZGFjMDogICAg ICBXaWRnZXQgY2FwOiAweDAwNzAwMDAwCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IC0yICgweDAw MDAwMDAwKQpoZGFjMDogICAgICAgICAgICAgT1NTOiBzcGVha2VyIChzcGVha2VyKQpoZGFjMDog CmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDI3CmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjog U1BESUYtb3V0IChKYWNrKQpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwNDAwMzBkCmhkYWMw OiAgICAgICAgICAgICAgICAgIERJR0lUQUwgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246 IDMgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDAwMTAKaGRhYzA6 ICAgICAgICAgICAgICAgICAgT1VUCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDE0NWYxZjAK aGRhYzA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDA0MCBPVVQKaGRhYzA6ICAgICAgT3V0cHV0 IGFtcDogMHg4MDA1MjcyNwpoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0zOSBz aXplPTUgb2Zmc2V0PTM5CmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6ICAgICAgICAg ICB8CmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MiBbYXVkaW8gb3V0cHV0XQpoZGFjMDogCmhk YWMwOiAgICAgICAgICAgICBuaWQ6IDI4IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFt ZTogcGluOiBTUERJRi1pbiAoTm9uZSkKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDIw YgpoZGFjMDogICAgICAgICAgICAgICAgICBESUdJVEFMIFNURVJFTwpoZGFjMDogICAgICAgICBQ aW4gY2FwOiAweDAwMDAwMDIwCmhkYWMwOiAgICAgICAgICAgICAgICAgIElOCmhkYWMwOiAgICAg IFBpbiBjb25maWc6IDB4NDFjNWYxZjAKaGRhYzA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDAw MApoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDUxZjE3CmhkYWMwOiAgICAgICAgICAgICAg ICAgIG11dGU9MSBzdGVwPTMxIHNpemU9NSBvZmZzZXQ9MjMKaGRhYzA6IApoZGFjMDogICAgICAg ICAgICAgbmlkOiAyOSBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG1p eGVyCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAyMDAzMDMKaGRhYzA6ICAgICAgICAgICAg ICAgICAgRElHSVRBTCBTVEVSRU8KaGRhYzA6ICAgICAgIElucHV0IGFtcDogMHg4MDAwMDAwMApo ZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFj MDogICAgIGNvbm5lY3Rpb25zOiAyCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAg ICsgW0RJU0FCTEVEXSA8LSBuaWQ9MSBbR0hPU1QhXSBbVU5LTk9XTl0KaGRhYzA6ICAgICAgICAg ICArIFtESVNBQkxFRF0gPC0gbmlkPTExIFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVEXQpoZGFj MDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDMwIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAg ICAgTmFtZTogYXVkaW8gbWl4ZXIKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwMwpo ZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICAgIElucHV0IGFtcDogMHg4 MDAwMDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZz ZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAyCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDog ICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9NTQgW2F1ZGlvIHNlbGVjdG9yXSBbRElTQUJM RURdCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0zMyBbYXVkaW8gc2VsZWN0 b3JdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMzEgW0RJU0FCTEVEXQpoZGFjMDog ICAgICAgICAgICBOYW1lOiB2b2x1bWUgd2lkZ2V0CmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4 MDA2MDAwODAKaGRhYzA6ICAgICAgICAgICAgICAgICAgVU5TT0wKaGRhYzA6IApoZGFjMDogICAg ICAgICAgICAgbmlkOiAzMgpoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBtaXhlcgpoZGFj MDogICAgICBXaWRnZXQgY2FwOiAweDAwMjAwMTBiCmhkYWMwOiAgICAgICAgICAgICAgICAgIFNU RVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAtMiAoMHgwMDAwNDAwNykKaGRhYzA6ICAgICAg ICAgICAgIE9TUzogbWl4IChtaXgpCmhkYWMwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAwNTFmMTcK aGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MzEgc2l6ZT01IG9mZnNldD0yMwpo ZGFjMDogICAgIGNvbm5lY3Rpb25zOiA4CmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAg ICAgICsgPC0gbmlkPTU3IFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6ICAgICAgICAgICArIDwtIG5p ZD01MSBbYXVkaW8gc2VsZWN0b3JdCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5p ZD01NiBbYXVkaW8gc2VsZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICArIFtESVNB QkxFRF0gPC0gbmlkPTYxIFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVEXQpoZGFjMDogICAgICAg ICAgICsgPC0gbmlkPTUyIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6ICAgICAgICAgICArIFtESVNB QkxFRF0gPC0gbmlkPTU5IFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVEXQpoZGFjMDogICAgICAg ICAgICsgPC0gbmlkPTI0IFtwaW46IENEIChGaXhlZCldCmhkYWMwOiAgICAgICAgICAgKyA8LSBu aWQ9MjYgW2JlZXAgd2lkZ2V0XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDMzCmhk YWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMwOiAgICAgIFdpZGdldCBj YXA6IDB4MDAzMDAxMGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAg QXNzb2NpYXRpb246IC0yICgweDAwMDAwMDAwKQpoZGFjMDogICAgICAgICAgICAgT1NTOiBtaXgK aGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDA1MWYxZgpoZGFjMDogICAgICAgICAgICAgICAg ICBtdXRlPTEgc3RlcD0zMSBzaXplPTUgb2Zmc2V0PTMxCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6 IDEKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MzIgW2F1ZGlv IG1peGVyXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDM0CmhkYWMwOiAgICAgICAg ICAgIE5hbWU6IGF1ZGlvIG1peGVyCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAyMDAxMDMK aGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDIg KDB4MDAwMDAwMDEpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSwgbWl4CmhkYWMwOiAgICAg ICBJbnB1dCBhbXA6IDB4ODAwMDAwMDAKaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0 ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMgpoZGFjMDogICAg ICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01NSBbYXVkaW8gc2VsZWN0b3JdCmhk YWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MzMgW2F1ZGlvIHNlbGVjdG9yXQpoZGFjMDogCmhkYWMw OiAgICAgICAgICAgICBuaWQ6IDM1IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTog dmVuZG9yIHdpZGdldApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwZjAwMTAwCmhkYWMwOiAg ICAgY29ubmVjdGlvbnM6IDE4CmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsg PC0gbmlkPTE3IFtwaW46IEhlYWRwaG9uZXMgKEphY2spXSAoc2VsZWN0ZWQpCmhkYWMwOiAgICAg ICAgICAgKyA8LSBuaWQ9MTggW3BpbjogTGluZS1vdXQgKEphY2spXQpoZGFjMDogICAgICAgICAg ICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTkgW3BpbjogU3BlYWtlciAoTm9uZSldIFtESVNBQkxFRF0K aGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yMCBbcGluOiBNaWMgKEphY2spXQpoZGFjMDogICAg ICAgICAgICsgPC0gbmlkPTIxIFtwaW46IExpbmUtaW4gKEphY2spXQpoZGFjMDogICAgICAgICAg ICsgPC0gbmlkPTIyIFtwaW46IExpbmUtb3V0IChKYWNrKV0KaGRhYzA6ICAgICAgICAgICArIDwt IG5pZD0yMyBbcGluOiBNaWMgKEphY2spXQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTI0IFtw aW46IENEIChGaXhlZCldCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MzYgW3BpbjogTGluZS1v dXQgKEphY2spXQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTM3IFtwaW46IExpbmUtb3V0IChK YWNrKV0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01NiBbYXVkaW8gc2VsZWN0b3JdIFtESVNB QkxFRF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01NyBbYXVkaW8gc2VsZWN0b3JdCmhkYWMw OiAgICAgICAgICAgKyA8LSBuaWQ9NTggW2F1ZGlvIHNlbGVjdG9yXQpoZGFjMDogICAgICAgICAg ICsgPC0gbmlkPTU5IFthdWRpbyBzZWxlY3Rvcl0gW0RJU0FCTEVEXQpoZGFjMDogICAgICAgICAg ICsgPC0gbmlkPTYwIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD02 MSBbYXVkaW8gc2VsZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0z MiBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MzMgW2F1ZGlvIHNlbGVj dG9yXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDM2CmhkYWMwOiAgICAgICAgICAg IE5hbWU6IHBpbjogTGluZS1vdXQgKEphY2spCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0 MDA5OGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgTFJTV0FQIFVOU09MIFNURVJFTwpoZGFjMDog ICAgIEFzc29jaWF0aW9uOiAwICgweDAwMDAwMDAyKQpoZGFjMDogICAgICAgICBQaW4gY2FwOiAw eDAwMDAwMDM3CmhkYWMwOiAgICAgICAgICAgICAgICAgIElTQyBUUlFEIFBEQyBPVVQgSU4KaGRh YzA6ICAgICAgUGluIGNvbmZpZzogMHgwMTAxNjAxMQpoZGFjMDogICAgIFBpbiBjb250cm9sOiAw eDAwMDAwMDQwIE9VVApoZGFjMDogICAgICBPdXRwdXQgYW1wOiAweDgwMDAwMDAwCmhkYWMwOiAg ICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMwOiAgICAg Y29ubmVjdGlvbnM6IDEKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyA8LSBu aWQ9MzkgW2F1ZGlvIG1peGVyXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDM3Cmhk YWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogTGluZS1vdXQgKEphY2spCmhkYWMwOiAgICAgIFdp ZGdldCBjYXA6IDB4MDA0MDAxOGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgVU5TT0wgU1RFUkVP CmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDAwMTApCmhkYWMwOiAgICAgICAgIFBp biBjYXA6IDB4MDAwMDAwMzcKaGRhYzA6ICAgICAgICAgICAgICAgICAgSVNDIFRSUUQgUERDIE9V VCBJTgpoZGFjMDogICAgICBQaW4gY29uZmlnOiAweDAxMDEyMDE0CmhkYWMwOiAgICAgUGluIGNv bnRyb2w6IDB4MDAwMDAwNDAgT1VUCmhkYWMwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwMDAwMDAK aGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRh YzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAg ICArIDwtIG5pZD00MCBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5p ZDogMzggW0RJU0FCTEVEXQpoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBtaXhlcgpoZGFj MDogICAgICBXaWRnZXQgY2FwOiAweDAwMjAwMTAzCmhkYWMwOiAgICAgICAgICAgICAgICAgIFNU RVJFTwpoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAg ICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlv bnM6IDIKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwt IG5pZD01MCBbYXVkaW8gc2VsZWN0b3JdIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICArIFtE SVNBQkxFRF0gPC0gbmlkPTMzIFthdWRpbyBzZWxlY3Rvcl0KaGRhYzA6IApoZGFjMDogICAgICAg ICAgICAgbmlkOiAzOQpoZGFjMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBtaXhlcgpoZGFjMDog ICAgICBXaWRnZXQgY2FwOiAweDAwMjAwMTAzCmhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJF TwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAwICgweDAwMDAwMDAyKQpoZGFjMDogICAgICAgICAg ICAgT1NTOiBwY20sIG1peApoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDAwMDAwCmhkYWMw OiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMwOiAg ICAgY29ubmVjdGlvbnM6IDIKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyA8 LSBuaWQ9NSBbYXVkaW8gb3V0cHV0XQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTMzIFthdWRp byBzZWxlY3Rvcl0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiA0MApoZGFjMDogICAg ICAgICAgICBOYW1lOiBhdWRpbyBtaXhlcgpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMjAw MTAzCmhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9u OiAwICgweDAwMDAwMDEwKQpoZGFjMDogICAgICAgICAgICAgT1NTOiBwY20sIG1peApoZGFjMDog ICAgICAgSW5wdXQgYW1wOiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9 MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDIKaGRhYzA6 ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTAgW2F1ZGlvIG91dHB1dF0K aGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0zMyBbYXVkaW8gc2VsZWN0b3JdCmhkYWMwOiAKaGRh YzA6ICAgICAgICAgICAgIG5pZDogNDEKaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gbWl4 ZXIKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwMwpoZGFjMDogICAgICAgICAgICAg ICAgICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMCAoMHgwMDAwMDAwMSkKaGRhYzA6 ICAgICAgICAgICAgIE9TUzogcGNtLCBtaXgKaGRhYzA6ICAgICAgIElucHV0IGFtcDogMHg4MDAw MDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9 MApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAyCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAg ICAgICAgICsgPC0gbmlkPTQgW2F1ZGlvIG91dHB1dF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5p ZD0zMyBbYXVkaW8gc2VsZWN0b3JdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNDIK aGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gbWl4ZXIKaGRhYzA6ICAgICAgV2lkZ2V0IGNh cDogMHgwMDIwMDEwMwpoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBB c3NvY2lhdGlvbjogMCAoMHgwMDAwMDAwNCkKaGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtLCBt aXgKaGRhYzA6ICAgICAgIElucHV0IGFtcDogMHg4MDAwMDAwMApoZGFjMDogICAgICAgICAgICAg ICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rpb25z OiAyCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTYgW2F1ZGlv IG91dHB1dF0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0zMyBbYXVkaW8gc2VsZWN0b3JdCmhk YWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNDMgW0RJU0FCTEVEXQpoZGFjMDogICAgICAg ICAgICBOYW1lOiBhdWRpbyBtaXhlcgpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMjAwMTAz CmhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpoZGFjMDogICAgICAgSW5wdXQgYW1wOiAw eDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9m ZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDIKaGRhYzA6ICAgICAgICAgICB8CmhkYWMw OiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD00OCBbYXVkaW8gc2VsZWN0b3JdIFtESVNB QkxFRF0KaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTMzIFthdWRpbyBzZWxl Y3Rvcl0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiA0NCBbRElTQUJMRURdCmhkYWMw OiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG1peGVyCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4 MDAyMDAxMDMKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAgICBJbnB1 dCBhbXA6IDB4ODAwMDAwMDAKaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBz aXplPTAgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMgpoZGFjMDogICAgICAgICAg IHwKaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTQ5IFthdWRpbyBzZWxlY3Rv cl0gW0RJU0FCTEVEXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MzMgW2F1 ZGlvIHNlbGVjdG9yXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDQ1IFtESVNBQkxF RF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gbWl4ZXIKaGRhYzA6ICAgICAgV2lkZ2V0 IGNhcDogMHgwMDIwMDEwMApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAxCmhkYWMwOiAgICAgICAg ICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTMwIFthdWRpbyBtaXhlcl0gW0RJU0FCTEVE XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDQ2IFtESVNBQkxFRF0KaGRhYzA6ICAg ICAgICAgICAgTmFtZTogdmVuZG9yIHdpZGdldApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAw ZjAwMDAwCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNDcgW0RJU0FCTEVEXQpoZGFj MDogICAgICAgICAgICBOYW1lOiB2ZW5kb3Igd2lkZ2V0CmhkYWMwOiAgICAgIFdpZGdldCBjYXA6 IDB4MDBmMDAxMDAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogNgpoZGFjMDogICAgICAgICAgIHwK aGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0xNyBbcGluOiBIZWFkcGhvbmVzIChKYWNrKV0gKHNl bGVjdGVkKQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTE4IFtwaW46IExpbmUtb3V0IChKYWNr KV0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yMCBbcGluOiBNaWMgKEphY2spXQpoZGFjMDog ICAgICAgICAgICsgPC0gbmlkPTIxIFtwaW46IExpbmUtaW4gKEphY2spXQpoZGFjMDogICAgICAg ICAgICsgPC0gbmlkPTIyIFtwaW46IExpbmUtb3V0IChKYWNrKV0KaGRhYzA6ICAgICAgICAgICAr IDwtIG5pZD0yMyBbcGluOiBNaWMgKEphY2spXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBu aWQ6IDQ4IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gc2VsZWN0b3IK aGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwMQpoZGFjMDogICAgICAgICAgICAgICAg ICBTVEVSRU8KaGRhYzA6ICAgICBjb25uZWN0aW9uczogMwpoZGFjMDogICAgICAgICAgIHwKaGRh YzA6ICAgICAgICAgICArIDwtIG5pZD0zIFthdWRpbyBvdXRwdXRdIChzZWxlY3RlZCkKaGRhYzA6 ICAgICAgICAgICArIDwtIG5pZD00IFthdWRpbyBvdXRwdXRdCmhkYWMwOiAgICAgICAgICAgKyA8 LSBuaWQ9NiBbYXVkaW8gb3V0cHV0XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDQ5 IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gc2VsZWN0b3IKaGRhYzA6 ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwMQpoZGFjMDogICAgICAgICAgICAgICAgICBTVEVS RU8KaGRhYzA6ICAgICBjb25uZWN0aW9uczogMgpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAg ICAgICAgICArIDwtIG5pZD00IFthdWRpbyBvdXRwdXRdIChzZWxlY3RlZCkKaGRhYzA6ICAgICAg ICAgICArIDwtIG5pZD0xMCBbYXVkaW8gb3V0cHV0XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAg ICBuaWQ6IDUwIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gc2VsZWN0 b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwMQpoZGFjMDogICAgICAgICAgICAg ICAgICBTVEVSRU8KaGRhYzA6ICAgICBjb25uZWN0aW9uczogMgpoZGFjMDogICAgICAgICAgIHwK aGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01IFthdWRpbyBvdXRwdXRdIChzZWxlY3RlZCkKaGRh YzA6ICAgICAgICAgICArIDwtIG5pZD00IFthdWRpbyBvdXRwdXRdCmhkYWMwOiAKaGRhYzA6ICAg ICAgICAgICAgIG5pZDogNTEKaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gc2VsZWN0b3IK aGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwMQpoZGFjMDogICAgICAgICAgICAgICAg ICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMSAoMHgwMDAwMDAwMikKaGRhYzA6ICAg ICAgICAgICAgIE9TUzogbGluZQpoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAzCmhkYWMwOiAgICAg ICAgICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTU4IFthdWRpbyBzZWxlY3Rvcl0gKHNl bGVjdGVkKQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MzcgW3BpbjogTGlu ZS1vdXQgKEphY2spXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MzYgW3Bp bjogTGluZS1vdXQgKEphY2spXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDUyCmhk YWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMwOiAgICAgIFdpZGdldCBj YXA6IDB4MDAzMDAxMDEKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAg QXNzb2NpYXRpb246IDEgKDB4MDAwMDAwMDEpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IG1vbml0 b3IKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMwpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAg ICAgICAgICArIDwtIG5pZD02MCBbYXVkaW8gc2VsZWN0b3JdIChzZWxlY3RlZCkKaGRhYzA6ICAg ICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTM3IFtwaW46IExpbmUtb3V0IChKYWNrKV0KaGRh YzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTM2IFtwaW46IExpbmUtb3V0IChKYWNr KV0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiA1MyBbRElTQUJMRURdCmhkYWMwOiAg ICAgICAgICAgIE5hbWU6IHZlbmRvciB3aWRnZXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgw MGYwMDAwMApoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDU0IFtESVNBQkxFRF0KaGRh YzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gc2VsZWN0b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNh cDogMHgwMDMwMDEwMQpoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBj b25uZWN0aW9uczogMwpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5p ZD0zIFthdWRpbyBvdXRwdXRdIChzZWxlY3RlZCkKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD00 IFthdWRpbyBvdXRwdXRdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9NiBbYXVkaW8gb3V0cHV0 XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDU1CmhkYWMwOiAgICAgICAgICAgIE5h bWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAzMDAxMDEKaGRh YzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDIgKDB4 MDAwMDAwMDEpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbQpoZGFjMDogICAgIGNvbm5lY3Rp b25zOiAzCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTMgW2F1 ZGlvIG91dHB1dF0gKHNlbGVjdGVkKQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBu aWQ9NCBbYXVkaW8gb3V0cHV0XQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9 NiBbYXVkaW8gb3V0cHV0XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDU2IFtESVNB QkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gc2VsZWN0b3IKaGRhYzA6ICAgICAg V2lkZ2V0IGNhcDogMHgwMDMwMDEwZApoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRh YzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDI3MDMwMApoZGFjMDogICAgICAgICAgICAgICAgICBt dXRlPTAgc3RlcD0zIHNpemU9Mzkgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpo ZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0xNyBbcGluOiBIZWFk cGhvbmVzIChKYWNrKV0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiA1NwpoZGFjMDog ICAgICAgICAgICBOYW1lOiBhdWRpbyBzZWxlY3RvcgpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAw eDAwMzAwMTBkCmhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpoZGFjMDogICAgIEFzc29j aWF0aW9uOiAxICgweDAwMDA0MDAwKQpoZGFjMDogICAgICAgICAgICAgT1NTOiBtaWMKaGRhYzA6 ICAgICAgT3V0cHV0IGFtcDogMHgwMDI3MDMwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRl PTAgc3RlcD0zIHNpemU9Mzkgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFj MDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yMCBbcGluOiBNaWMgKEph Y2spXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDU4CmhkYWMwOiAgICAgICAgICAg IE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAzMDAxMGQK aGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDEg KDB4MDAwMDAwMDIpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IGxpbmUKaGRhYzA6ICAgICAgT3V0 cHV0IGFtcDogMHgwMDI3MDMwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0z IHNpemU9Mzkgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFjMDogICAgICAg ICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yMSBbcGluOiBMaW5lLWluIChKYWNrKV0K aGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiA1OSBbRElTQUJMRURdCmhkYWMwOiAgICAg ICAgICAgIE5hbWU6IGF1ZGlvIHNlbGVjdG9yCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAz MDAxMGQKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAgIE91dHB1dCBh bXA6IDB4MDAyNzAzMDAKaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0wIHN0ZXA9MyBzaXpl PTM5IG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRhYzA6ICAgICAgICAgICB8 CmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MjIgW3BpbjogTGluZS1vdXQgKEphY2spXQpoZGFj MDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDYwCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1 ZGlvIHNlbGVjdG9yCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAzMDAxMGQKaGRhYzA6ICAg ICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDEgKDB4MDAwMDAw MDEpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IG1vbml0b3IKaGRhYzA6ICAgICAgT3V0cHV0IGFt cDogMHgwMDI3MDMwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zIHNpemU9 Mzkgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFjMDogICAgICAgICAgIHwK aGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yMyBbcGluOiBNaWMgKEphY2spXQpoZGFjMDogCmhk YWMwOiAgICAgICAgICAgICBuaWQ6IDYxIFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFt ZTogYXVkaW8gc2VsZWN0b3IKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDMwMDEwZApoZGFj MDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDI3 MDMwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zIHNpemU9Mzkgb2Zmc2V0 PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAg ICAgICAgICArIDwtIG5pZD0xOCBbcGluOiBMaW5lLW91dCAoSmFjayldCmhkYWMwOiAKcGNtMDog PEhEQSBBbmFsb2cgRGV2aWNlcyBBRDE5ODhCIFBDTSAjMCBBbmFsb2c+IGF0IGNhZCAwIG5pZCAx IG9uIGhkYWMwCnBjbTA6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsK cGNtMDogfCBEVU1QSU5HIFBDTSBQbGF5YmFjay9SZWNvcmQgQ2hhbm5lbHMgfApwY20wOiArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnBjbTA6IApwY20wOiBQbGF5YmFj azoKcGNtMDogCnBjbTA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpwY20wOiAgICAgICAg ICAgICAgICAgIFBDTQpwY20wOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3ZmYKcGNtMDogICAg ICAgICAgICAgICAgICAxNiAyMCAyNCBiaXRzLCA4IDExIDE2IDIyIDMyIDQ0IDQ4IDg4IDk2IDE3 NiAxOTIgS0h6CnBjbTA6ICAgICAgICAgICAgIERBQzogNCA1IDYgMTAKcGNtMDogCnBjbTA6IFJl Y29yZDoKcGNtMDogCnBjbTA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpwY20wOiAgICAg ICAgICAgICAgICAgIFBDTQpwY20wOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3ZmYKcGNtMDog ICAgICAgICAgICAgICAgICAxNiAyMCAyNCBiaXRzLCA4IDExIDE2IDIyIDMyIDQ0IDQ4IDg4IDk2 IDE3NiAxOTIgS0h6CnBjbTA6ICAgICAgICAgICAgIEFEQzogOApwY20wOiAKcGNtMDogKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20wOiB8IERVTVBJTkcgUGxheWJhY2svUmVj b3JkIFBhdGhlcyB8CnBjbTA6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKcGNt MDogCnBjbTA6IFBsYXliYWNrOgpwY20wOiAKcGNtMDogICAgIG5pZD0xOCBbcGluOiBMaW5lLW91 dCAoSmFjayldCnBjbTA6ICAgICAgIHwKcGNtMDogICAgICAgKyA8LSBuaWQ9NDEgW2F1ZGlvIG1p eGVyXSBbc3JjOiBwY20sIG1peF0KcGNtMDogICAgICAgICAgICAgIHwKcGNtMDogICAgICAgICAg ICAgICsgPC0gbmlkPTQgW2F1ZGlvIG91dHB1dF0gW3NyYzogcGNtXQpwY20wOiAgICAgICAgICAg ICAgKyA8LSBuaWQ9MzMgW2F1ZGlvIHNlbGVjdG9yXSBbc3JjOiBtaXhdCnBjbTA6ICAgICAgICAg ICAgICAgICAgICAgfApwY20wOiAgICAgICAgICAgICAgICAgICAgICsgPC0gbmlkPTMyIFthdWRp byBtaXhlcl0gW3NyYzogbWl4XQpwY20wOiAKcGNtMDogICAgIG5pZD0yMiBbcGluOiBMaW5lLW91 dCAoSmFjayldCnBjbTA6ICAgICAgIHwKcGNtMDogICAgICAgKyA8LSBuaWQ9NDIgW2F1ZGlvIG1p eGVyXSBbc3JjOiBwY20sIG1peF0KcGNtMDogICAgICAgICAgICAgIHwKcGNtMDogICAgICAgICAg ICAgICsgPC0gbmlkPTYgW2F1ZGlvIG91dHB1dF0gW3NyYzogcGNtXQpwY20wOiAgICAgICAgICAg ICAgKyA8LSBuaWQ9MzMgW2F1ZGlvIHNlbGVjdG9yXSBbc3JjOiBtaXhdCnBjbTA6ICAgICAgICAg ICAgICAgICAgICAgfApwY20wOiAgICAgICAgICAgICAgICAgICAgICsgPC0gbmlkPTMyIFthdWRp byBtaXhlcl0gW3NyYzogbWl4XQpwY20wOiAKcGNtMDogICAgIG5pZD0zNiBbcGluOiBMaW5lLW91 dCAoSmFjayldCnBjbTA6ICAgICAgIHwKcGNtMDogICAgICAgKyA8LSBuaWQ9MzkgW2F1ZGlvIG1p eGVyXSBbc3JjOiBwY20sIG1peF0KcGNtMDogICAgICAgICAgICAgIHwKcGNtMDogICAgICAgICAg ICAgICsgPC0gbmlkPTUgW2F1ZGlvIG91dHB1dF0gW3NyYzogcGNtXQpwY20wOiAgICAgICAgICAg ICAgKyA8LSBuaWQ9MzMgW2F1ZGlvIHNlbGVjdG9yXSBbc3JjOiBtaXhdCnBjbTA6ICAgICAgICAg ICAgICAgICAgICAgfApwY20wOiAgICAgICAgICAgICAgICAgICAgICsgPC0gbmlkPTMyIFthdWRp byBtaXhlcl0gW3NyYzogbWl4XQpwY20wOiAKcGNtMDogICAgIG5pZD0zNyBbcGluOiBMaW5lLW91 dCAoSmFjayldCnBjbTA6ICAgICAgIHwKcGNtMDogICAgICAgKyA8LSBuaWQ9NDAgW2F1ZGlvIG1p eGVyXSBbc3JjOiBwY20sIG1peF0KcGNtMDogICAgICAgICAgICAgIHwKcGNtMDogICAgICAgICAg ICAgICsgPC0gbmlkPTEwIFthdWRpbyBvdXRwdXRdIFtzcmM6IHBjbV0KcGNtMDogICAgICAgICAg ICAgICsgPC0gbmlkPTMzIFthdWRpbyBzZWxlY3Rvcl0gW3NyYzogbWl4XQpwY20wOiAgICAgICAg ICAgICAgICAgICAgIHwKcGNtMDogICAgICAgICAgICAgICAgICAgICArIDwtIG5pZD0zMiBbYXVk aW8gbWl4ZXJdIFtzcmM6IG1peF0KcGNtMDogCnBjbTA6IFJlY29yZDoKcGNtMDogCnBjbTA6ICAg ICBuaWQ9OCBbYXVkaW8gaW5wdXRdCnBjbTA6ICAgICAgIHwKcGNtMDogICAgICAgKyA8LSBuaWQ9 MTIgW2F1ZGlvIHNlbGVjdG9yXSBbc3JjOiBsaW5lLCBtaWMsIGNkLCBtaXgsIG1vbml0b3JdCnBj bTA6ICAgICAgICAgICAgICB8CnBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD01NyBbYXVkaW8g c2VsZWN0b3JdIFtzcmM6IG1pY10KcGNtMDogICAgICAgICAgICAgICAgICAgICB8CnBjbTA6ICAg ICAgICAgICAgICAgICAgICAgKyA8LSBuaWQ9MjAgW3BpbjogTWljIChKYWNrKV0gW3NyYzogbWlj XQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9NTggW2F1ZGlvIHNlbGVjdG9yXSBbc3JjOiBs aW5lXQpwY20wOiAgICAgICAgICAgICAgICAgICAgIHwKcGNtMDogICAgICAgICAgICAgICAgICAg ICArIDwtIG5pZD0yMSBbcGluOiBMaW5lLWluIChKYWNrKV0gW3NyYzogbGluZV0KcGNtMDogICAg ICAgICAgICAgICsgPC0gbmlkPTYwIFthdWRpbyBzZWxlY3Rvcl0gW3NyYzogbW9uaXRvcl0KcGNt MDogICAgICAgICAgICAgICAgICAgICB8CnBjbTA6ICAgICAgICAgICAgICAgICAgICAgKyA8LSBu aWQ9MjMgW3BpbjogTWljIChKYWNrKV0gW3NyYzogbW9uaXRvcl0KcGNtMDogICAgICAgICAgICAg ICsgPC0gbmlkPTI0IFtwaW46IENEIChGaXhlZCldIFtzcmM6IGNkXQpwY20wOiAgICAgICAgICAg ICAgKyA8LSBuaWQ9MzIgW2F1ZGlvIG1peGVyXSBbc3JjOiBtaXhdCnBjbTA6IApwY20wOiBJbnB1 dCBNaXg6CnBjbTA6IApwY20wOiAgICAgbmlkPTMyIFthdWRpbyBtaXhlcl0KcGNtMDogICAgICAg fApwY20wOiAgICAgICArIDwtIG5pZD01NyBbYXVkaW8gc2VsZWN0b3JdIFtzcmM6IG1pY10KcGNt MDogICAgICAgICAgICAgIHwKcGNtMDogICAgICAgICAgICAgICsgPC0gbmlkPTIwIFtwaW46IE1p YyAoSmFjayldIFtzcmM6IG1pY10KcGNtMDogICAgICAgKyA8LSBuaWQ9NTEgW2F1ZGlvIHNlbGVj dG9yXSBbc3JjOiBsaW5lXQpwY20wOiAgICAgICAgICAgICAgfApwY20wOiAgICAgICAgICAgICAg KyA8LSBuaWQ9NTggW2F1ZGlvIHNlbGVjdG9yXSBbc3JjOiBsaW5lXQpwY20wOiAgICAgICAgICAg ICAgICAgICAgIHwKcGNtMDogICAgICAgICAgICAgICAgICAgICArIDwtIG5pZD0yMSBbcGluOiBM aW5lLWluIChKYWNrKV0gW3NyYzogbGluZV0KcGNtMDogICAgICAgKyA8LSBuaWQ9NTIgW2F1ZGlv IHNlbGVjdG9yXSBbc3JjOiBtb25pdG9yXQpwY20wOiAgICAgICAgICAgICAgfApwY20wOiAgICAg ICAgICAgICAgKyA8LSBuaWQ9NjAgW2F1ZGlvIHNlbGVjdG9yXSBbc3JjOiBtb25pdG9yXQpwY20w OiAgICAgICAgICAgICAgICAgICAgIHwKcGNtMDogICAgICAgICAgICAgICAgICAgICArIDwtIG5p ZD0yMyBbcGluOiBNaWMgKEphY2spXSBbc3JjOiBtb25pdG9yXQpwY20wOiAgICAgICArIDwtIG5p ZD0yNCBbcGluOiBDRCAoRml4ZWQpXSBbc3JjOiBjZF0KcGNtMDogICAgICAgKyA8LSBuaWQ9MjYg W2JlZXAgd2lkZ2V0XSBbc3JjOiBzcGVha2VyXQpwY20wOiAKcGNtMDogKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rCnBjbTA6IHwgRFVNUElORyBWb2x1bWUgQ29udHJvbHMgfApwY20wOiArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKcGNtMDogCnBjbTA6IE1hc3RlciBWb2x1bWUgKE9TUzog dm9sKQpwY20wOiAgICB8CnBjbTA6ICAgICstIGN0bCAgMiAobmlkICAgNCBvdXQpOiAgICAtNTgv MGRCICg0MCBzdGVwcykKcGNtMDogICAgKy0gY3RsICAzIChuaWQgICA1IG91dCk6ICAgIC01OC8w ZEIgKDQwIHN0ZXBzKQpwY20wOiAgICArLSBjdGwgIDQgKG5pZCAgIDYgb3V0KTogICAgLTU4LzBk QiAoNDAgc3RlcHMpCnBjbTA6ICAgICstIGN0bCAgNSAobmlkICAxMCBvdXQpOiAgICAtNTgvMGRC ICg0MCBzdGVwcykKcGNtMDogICAgKy0gY3RsIDExIChuaWQgIDE4IGluICk6ICAgIG11dGUKcGNt MDogICAgKy0gY3RsIDE1IChuaWQgIDIyIGluICk6ICAgIG11dGUKcGNtMDogICAgKy0gY3RsIDMz IChuaWQgIDM2IGluICk6ICAgIG11dGUKcGNtMDogICAgKy0gY3RsIDM0IChuaWQgIDM3IGluICk6 ICAgIG11dGUKcGNtMDogICAgKy0gY3RsIDM3IChuaWQgIDM5IGluICAgMCk6IG11dGUKcGNtMDog ICAgKy0gY3RsIDM4IChuaWQgIDM5IGluICAgMSk6IG11dGUKcGNtMDogICAgKy0gY3RsIDM5IChu aWQgIDQwIGluICAgMCk6IG11dGUKcGNtMDogICAgKy0gY3RsIDQwIChuaWQgIDQwIGluICAgMSk6 IG11dGUKcGNtMDogICAgKy0gY3RsIDQxIChuaWQgIDQxIGluICAgMCk6IG11dGUKcGNtMDogICAg Ky0gY3RsIDQyIChuaWQgIDQxIGluICAgMSk6IG11dGUKcGNtMDogICAgKy0gY3RsIDQzIChuaWQg IDQyIGluICAgMCk6IG11dGUKcGNtMDogICAgKy0gY3RsIDQ0IChuaWQgIDQyIGluICAgMSk6IG11 dGUKcGNtMDogCnBjbTA6IFBDTSBWb2x1bWUgKE9TUzogcGNtKQpwY20wOiAgICB8CnBjbTA6ICAg ICstIGN0bCAgMiAobmlkICAgNCBvdXQpOiAgICAtNTgvMGRCICg0MCBzdGVwcykKcGNtMDogICAg Ky0gY3RsICAzIChuaWQgICA1IG91dCk6ICAgIC01OC8wZEIgKDQwIHN0ZXBzKQpwY20wOiAgICAr LSBjdGwgIDQgKG5pZCAgIDYgb3V0KTogICAgLTU4LzBkQiAoNDAgc3RlcHMpCnBjbTA6ICAgICst IGN0bCAgNSAobmlkICAxMCBvdXQpOiAgICAtNTgvMGRCICg0MCBzdGVwcykKcGNtMDogICAgKy0g Y3RsIDM3IChuaWQgIDM5IGluICAgMCk6IG11dGUKcGNtMDogICAgKy0gY3RsIDM5IChuaWQgIDQw IGluICAgMCk6IG11dGUKcGNtMDogICAgKy0gY3RsIDQxIChuaWQgIDQxIGluICAgMCk6IG11dGUK cGNtMDogICAgKy0gY3RsIDQzIChuaWQgIDQyIGluICAgMCk6IG11dGUKcGNtMDogCnBjbTA6IENE IFZvbHVtZSAoT1NTOiBjZCkKcGNtMDogICAgfApwY20wOiAgICArLSBjdGwgMjggKG5pZCAgMzIg aW4gICA2KTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogCnBjbTA6IE1pY3JvcGhv bmUgVm9sdW1lIChPU1M6IG1pYykKcGNtMDogICAgfApwY20wOiAgICArLSBjdGwgNTAgKG5pZCAg NTcgb3V0KTogICAgMC8zMGRCICg0IHN0ZXBzKQpwY20wOiAKcGNtMDogTWljcm9waG9uZTIgVm9s dW1lIChPU1M6IG1vbml0b3IpCnBjbTA6ICAgIHwKcGNtMDogICAgKy0gY3RsIDUzIChuaWQgIDYw IG91dCk6ICAgIDAvMzBkQiAoNCBzdGVwcykKcGNtMDogCnBjbTA6IExpbmUtaW4gVm9sdW1lIChP U1M6IGxpbmUpCnBjbTA6ICAgIHwKcGNtMDogICAgKy0gY3RsIDUxIChuaWQgIDU4IG91dCk6ICAg IDAvMzBkQiAoNCBzdGVwcykKcGNtMDogCnBjbTA6IFNwZWFrZXIvQmVlcCBWb2x1bWUgKE9TUzog c3BlYWtlcikKcGNtMDogICAgfApwY20wOiAgICArLSBjdGwgIDkgKG5pZCAgMTYgb3V0KTogICAg LTQ1LzBkQiAoMTYgc3RlcHMpICsgbXV0ZQpwY20wOiAgICArLSBjdGwgMjkgKG5pZCAgMzIgaW4g ICA3KTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogCnBjbTA6IFJlY29yZGluZyBM ZXZlbCAoT1NTOiByZWMpCnBjbTA6ICAgIHwKcGNtMDogICAgKy0gY3RsICA2IChuaWQgIDEyIG91 dCk6ICAgIC01OC8yMmRCICg1NSBzdGVwcykgKyBtdXRlCnBjbTA6IApwY20wOiBJbnB1dCBNaXgg TGV2ZWwgKE9TUzogbWl4KQpwY20wOiAgICB8CnBjbTA6ICAgICstIGN0bCAyMiAobmlkICAzMiBp biAgIDApOiAtMzQvMTJkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20wOiAgICArLSBjdGwgMjMgKG5p ZCAgMzIgaW4gICAxKTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0gY3Rs IDI2IChuaWQgIDMyIGluICAgNCk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6ICAg ICstIGN0bCAyOCAobmlkICAzMiBpbiAgIDYpOiAtMzQvMTJkQiAoMzIgc3RlcHMpICsgbXV0ZQpw Y20wOiAgICArLSBjdGwgMjkgKG5pZCAgMzIgaW4gICA3KTogLTM0LzEyZEIgKDMyIHN0ZXBzKSAr IG11dGUKcGNtMDogICAgKy0gY3RsIDMwIChuaWQgIDMzIG91dCk6ICAgIC00Ni8wZEIgKDMyIHN0 ZXBzKSArIG11dGUKcGNtMDogICAgKy0gY3RsIDM4IChuaWQgIDM5IGluICAgMSk6IG11dGUKcGNt MDogICAgKy0gY3RsIDQwIChuaWQgIDQwIGluICAgMSk6IG11dGUKcGNtMDogICAgKy0gY3RsIDQy IChuaWQgIDQxIGluICAgMSk6IG11dGUKcGNtMDogICAgKy0gY3RsIDQ0IChuaWQgIDQyIGluICAg MSk6IG11dGUKcGNtMDogCnBjbTA6IE1peGVyICJ2b2wiOgpwY20wOiBNaXhlciAicGNtIjoKcGNt MDogTWl4ZXIgInNwZWFrZXIiOgpwY20wOiBNaXhlciAibGluZSI6CnBjbTA6IE1peGVyICJtaWMi OgpwY20wOiBNaXhlciAiY2QiOgpwY20wOiBNaXhlciAibWl4IjoKcGNtMDogTWl4ZXIgInJlYyI6 CnBjbTA6IE1peGVyICJtb25pdG9yIjoKcGNtMDogY2xvbmUgbWFuYWdlcjogZGVhZGxpbmU9NzUw bXMgZmxhZ3M9MHg4MDAwMDAxZQpwY20wOiBzbmRidWZfc2V0bWFwIDJkYTAwMDAsIDQwMDA7IDB4 ZTYzYTcwMDAgLT4gMmRhMDAwMApwY20wOiBzbmRidWZfc2V0bWFwIDJkYjAwMDAsIDQwMDA7IDB4 ZTYzYjcwMDAgLT4gMmRiMDAwMApwY20xOiA8SERBIEFuYWxvZyBEZXZpY2VzIEFEMTk4OEIgUENN ICMxIEFuYWxvZz4gYXQgY2FkIDAgbmlkIDEgb24gaGRhYzAKcGNtMTogKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20xOiB8IERVTVBJTkcgUENNIFBsYXliYWNrL1Jl Y29yZCBDaGFubmVscyB8CnBjbTE6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsKcGNtMTogCnBjbTE6IFBsYXliYWNrOgpwY20xOiAKcGNtMTogICAgICBTdHJlYW0gY2Fw OiAweDAwMDAwMDAxCnBjbTE6ICAgICAgICAgICAgICAgICAgUENNCnBjbTE6ICAgICAgICAgUENN IGNhcDogMHgwMDBlMDdmZgpwY20xOiAgICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDgg MTEgMTYgMjIgMzIgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKcGNtMTogICAgICAgICAgICAgREFD OiAzCnBjbTE6IApwY20xOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnBjbTE6 IHwgRFVNUElORyBQbGF5YmFjay9SZWNvcmQgUGF0aGVzIHwKcGNtMTogKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwpwY20xOiAKcGNtMTogUGxheWJhY2s6CnBjbTE6IApwY20xOiAg ICAgbmlkPTE3IFtwaW46IEhlYWRwaG9uZXMgKEphY2spXQpwY20xOiAgICAgICB8CnBjbTE6ICAg ICAgICsgPC0gbmlkPTM0IFthdWRpbyBtaXhlcl0gW3NyYzogcGNtLCBtaXhdCnBjbTE6ICAgICAg ICAgICAgICB8CnBjbTE6ICAgICAgICAgICAgICArIDwtIG5pZD01NSBbYXVkaW8gc2VsZWN0b3Jd IFtzcmM6IHBjbV0KcGNtMTogICAgICAgICAgICAgICAgICAgICB8CnBjbTE6ICAgICAgICAgICAg ICAgICAgICAgKyA8LSBuaWQ9MyBbYXVkaW8gb3V0cHV0XSBbc3JjOiBwY21dCnBjbTE6ICAgICAg ICAgICAgICArIDwtIG5pZD0zMyBbYXVkaW8gc2VsZWN0b3JdIFtzcmM6IG1peF0KcGNtMTogICAg ICAgICAgICAgICAgICAgICB8CnBjbTE6ICAgICAgICAgICAgICAgICAgICAgKyA8LSBuaWQ9MzIg W2F1ZGlvIG1peGVyXSBbc3JjOiBtaXhdCnBjbTE6IApwY20xOiArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsKcGNtMTogfCBEVU1QSU5HIFZvbHVtZSBDb250cm9scyB8CnBjbTE6ICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwpwY20xOiAKcGNtMTogTWFzdGVyIFZvbHVtZSAoT1NTOiB2b2wp CnBjbTE6ICAgIHwKcGNtMTogICAgKy0gY3RsICAxIChuaWQgICAzIG91dCk6ICAgIC01OC8wZEIg KDQwIHN0ZXBzKQpwY20xOiAgICArLSBjdGwgMTAgKG5pZCAgMTcgaW4gKTogICAgbXV0ZQpwY20x OiAgICArLSBjdGwgMzEgKG5pZCAgMzQgaW4gICAwKTogbXV0ZQpwY20xOiAgICArLSBjdGwgMzIg KG5pZCAgMzQgaW4gICAxKTogbXV0ZQpwY20xOiAKcGNtMTogUENNIFZvbHVtZSAoT1NTOiBwY20p CnBjbTE6ICAgIHwKcGNtMTogICAgKy0gY3RsICAxIChuaWQgICAzIG91dCk6ICAgIC01OC8wZEIg KDQwIHN0ZXBzKQpwY20xOiAgICArLSBjdGwgMzEgKG5pZCAgMzQgaW4gICAwKTogbXV0ZQpwY20x OiAKcGNtMTogSW5wdXQgTWl4IExldmVsIChPU1M6IG1peCkKcGNtMTogICAgfApwY20xOiAgICAr LSBjdGwgMzIgKG5pZCAgMzQgaW4gICAxKTogbXV0ZQpwY20xOiAKcGNtMTogTWl4ZXIgInZvbCI6 CnBjbTE6IE1peGVyICJwY20iOgpwY20xOiBNaXhlciAibWl4IjoKcGNtMTogY2xvbmUgbWFuYWdl cjogZGVhZGxpbmU9NzUwbXMgZmxhZ3M9MHg4MDAwMDAxZQpwY20xOiBzbmRidWZfc2V0bWFwIDJk YzAwMDAsIDQwMDA7IDB4ZTYzYzcwMDAgLT4gMmRjMDAwMApwY20yOiA8SERBIEFuYWxvZyBEZXZp Y2VzIEFEMTk4OEIgUENNICMyIERpZ2l0YWw+IGF0IGNhZCAwIG5pZCAxIG9uIGhkYWMwCnBjbTI6 ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKcGNtMjogfCBEVU1QSU5H IFBDTSBQbGF5YmFjay9SZWNvcmQgQ2hhbm5lbHMgfApwY20yOiArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rCnBjbTI6IApwY20yOiBQbGF5YmFjazoKcGNtMjogCnBjbTI6 ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwNQpwY20yOiAgICAgICAgICAgICAgICAgIEFDMyBQ Q00KcGNtMjogICAgICAgICBQQ00gY2FwOiAweDAwMGUwN2UwCnBjbTI6ICAgICAgICAgICAgICAg ICAgMTYgMjAgMjQgYml0cywgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKcGNtMjogICAgICAgICAg ICAgREFDOiAyCnBjbTI6IApwY20yOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r CnBjbTI6IHwgRFVNUElORyBQbGF5YmFjay9SZWNvcmQgUGF0aGVzIHwKcGNtMjogKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20yOiAKcGNtMjogUGxheWJhY2s6CnBjbTI6IApw Y20yOiAgICAgbmlkPTI3IFtwaW46IFNQRElGLW91dCAoSmFjayldCnBjbTI6ICAgICAgIHwKcGNt MjogICAgICAgKyA8LSBuaWQ9MiBbYXVkaW8gb3V0cHV0XSBbc3JjOiBwY21dCnBjbTI6IApwY20y OiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKcGNtMjogfCBEVU1QSU5HIFZvbHVtZSBDb250 cm9scyB8CnBjbTI6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20yOiAKcGNtMjogTWFz dGVyIFZvbHVtZSAoT1NTOiB2b2wpCnBjbTI6ICAgIHwKcGNtMjogICAgKy0gY3RsIDE3IChuaWQg IDI3IGluICk6ICAgIC01OC8wZEIgKDQwIHN0ZXBzKSArIG11dGUKcGNtMjogCnBjbTI6IFBDTSBW b2x1bWUgKE9TUzogcGNtKQpwY20yOiAgICB8CnBjbTI6ICAgICstIGN0bCAxNyAobmlkICAyNyBp biApOiAgICAtNTgvMGRCICg0MCBzdGVwcykgKyBtdXRlCnBjbTI6IApwY20yOiBNaXhlciAidm9s IjoKcGNtMjogTWl4ZXIgInBjbSI6CnBjbTI6IGNsb25lIG1hbmFnZXI6IGRlYWRsaW5lPTc1MG1z IGZsYWdzPTB4ODAwMDAwMWUKcGNtMjogc25kYnVmX3NldG1hcCAyZGQwMDAwLCA0MDAwOyAweGU2 M2Q3MDAwIC0+IDJkZDAwMDAKR0VPTTogbmV3IGRpc2sgYWQ4CkdFT006IGFkNnMxOiBnZW9tZXRy eSBkb2VzIG5vdCBtYXRjaCBsYWJlbCAoMjU1aCw2M3MgIT0gMTZoLDYzcykuCkdFT006IGFkNnMy OiBnZW9tZXRyeSBkb2VzIG5vdCBtYXRjaCBsYWJlbCAoMjU1aCw2M3MgIT0gMTZoLDYzcykuCkdF T01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhY2QwIGlzIGlzbzk2NjAvVEhFX0RBUktfTklH SFQuCmFjZDA6IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVTVCBhc2M9MHgyNCBhc2Nx PTB4MDAgc2tzPTB4NDAgMHgwMCAweDAxCihwcm9iZTA6YXRhNTowOjA6MCk6IGVycm9yIDIyCihw cm9iZTA6YXRhNTowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCmFjZDA6IEZBSUxVUkUgLSBJTlFV SVJZIElMTEVHQUwgUkVRVUVTVCBhc2M9MHgyNCBhc2NxPTB4MDAgc2tzPTB4NDAgMHgwMCAweDAx Cihwcm9iZTA6YXRhNTowOjA6MCk6IGVycm9yIDIyCihwcm9iZTA6YXRhNTowOjA6MCk6IFVucmV0 cnlhYmxlIEVycm9yCihwcm9iZTI6c2JwMDowOjA6MCk6IGVycm9yIDIyCihwcm9iZTI6c2JwMDow OjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTQ6c2JwMDowOjI6MCk6IGVycm9yIDIyCihw cm9iZTQ6c2JwMDowOjI6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTU6c2JwMDowOjM6MCk6 IGVycm9yIDIyCihwcm9iZTU6c2JwMDowOjM6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTY6 c2JwMDowOjQ6MCk6IGVycm9yIDIyCihwcm9iZTY6c2JwMDowOjQ6MCk6IFVucmV0cnlhYmxlIEVy cm9yCihwcm9iZTc6c2JwMDowOjU6MCk6IGVycm9yIDIyCihwcm9iZTc6c2JwMDowOjU6MCk6IFVu cmV0cnlhYmxlIEVycm9yCihwcm9iZTg6c2JwMDowOjY6MCk6IGVycm9yIDIyCihwcm9iZTg6c2Jw MDowOjY6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTM6c2JwMDowOjE6MCk6IGVycm9yIDIy Cihwcm9iZTM6c2JwMDowOjE6MCk6IFVucmV0cnlhYmxlIEVycm9yCkdFT006IG5ldyBkaXNrIGRh MApHRU9NOiBuZXcgZGlzayBkYTEKR0VPTTogbmV3IGRpc2sgY2QwY2QwIGF0IGF0YTUgYnVzIDAg dGFyZ2V0IDAgbHVuIDAKY2QwOiA8SEwtRFQtU1QgQkREVkRSVyBHR0MtSDIwTCAxLjAzPiBSZW1v dmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZpY2UgCmNkMDogMy4zMDBNQi9zIHRyYW5zZmVycwpjZDA6 IGNkIHByZXNlbnQgWzM5Njc5ODQgeCAyMDQ4IGJ5dGUgcmVjb3Jkc10KCnBhc3MwIGF0IHVtYXNz LXNpbTAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKcGFzczA6IDxHZW5lcmljIEZsYXNoIEhTLUNGIDQu NDQ+IFJlbW92YWJsZSBEaXJlY3QgQWNjZXNzIFNDU0ktMCBkZXZpY2UgCnBhc3MwOiA0MC4wMDBN Qi9zIHRyYW5zZmVycwpwYXNzMSBhdCB1bWFzcy1zaW0wIGJ1cyAwIHRhcmdldCAwIGx1biAxCnBh c3MxOiA8R2VuZXJpYyBGbGFzaCBIUy1DT01CTyA0LjQ0PiBSZW1vdmFibGUgRGlyZWN0IEFjY2Vz cyBTQ1NJLTAgZGV2aWNlIApwYXNzMTogNDAuMDAwTUIvcyB0cmFuc2ZlcnMKcGFzczIgYXQgYXRh NSBidXMgMCB0YXJnZXQgMCBsdW4gMApwYXNzMjogPEhMLURULVNUIEJERFZEUlcgR0dDLUgyMEwg MS4wMz4gUmVtb3ZhYmwoZGEwOnVtYXNzLXNpbTA6MDowOjApOiBlcnJvciA2CihkYTA6dW1hc3Mt c2ltMDowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCmRhMCBhdCB1bWFzcy1zaW0wIGJ1cyAwIHRh cmdldCAwIGx1biAwCmRhMDogPEdlbmVyaWMgRmxhc2ggSFMtQ0YgNC40ND4gUmVtb3ZhYmxlIERp cmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKZGEwOiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTA6 IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBu b3QgcHJlc2VudAplIENELVJPTSBTQ1NJLTAgZGV2aWNlIApwYXNzMjogMy4zMDBNQi9zIHRyYW5z ZmVycwpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKY3B1MSBBUDoKICAgICBJRDogMHgwMTAwMDAw MCAgIFZFUjogMHgwMDA1MDAxNCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGlu dDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgw MDAwMDFmZgogIHRpbWVyOiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAx MDAwMCBwY206IDB4MDAwMDA0MDAKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhCmNwdTMgQVA6CiAg ICAgSUQ6IDB4MDMwMDAwMDAgICBWRVI6IDB4MDAwNTAwMTQgTERSOiAweDAwMDAwMDAwIERGUjog MHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgw MDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAx MDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDAwNDAwClNNUDogQVAgQ1BVICMyIExhdW5j aGVkIQpjcHUyIEFQOgogICAgIElEOiAweDAyMDAwMDAwICAgVkVSOiAweDAwMDUwMDE0IExEUjog MHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgw MDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMjAw ZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAwMDQwMAppb2Fw aWMwOiBBc3NpZ25pbmcgSVNBIElSUSAxIHRvIGxvY2FsIEFQSUMgMAppb2FwaWMwOiBBc3NpZ25p bmcgSVNBIElSUSA0IHRvIGxvY2FsIEFQSUMgMQppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElSUSA5 IHRvIGxvY2FsIEFQSUMgMgppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElSUSAxNCB0byBsb2NhbCBB UElDIDMKaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgMTUgdG8gbG9jYWwgQVBJQyAwCmlvYXBp YzA6IEFzc2lnbmluZyBQQ0kgSVJRIDE2IHRvIGxvY2FsIEFQSUMgMQppb2FwaWMwOiBBc3NpZ25p bmcgUENJIElSUSAxOCB0byBsb2NhbCBBUElDIDIKaW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEg MTkgdG8gbG9jYWwgQVBJQyAzCmlvYXBpYzA6IEFzc2lnbmluZyBQQ0kgSVJRIDIxIHRvIGxvY2Fs IEFQSUMgMAppb2FwaWMwOiBBc3NpZ25pbmcgUENJIElSUSAyMiB0byBsb2NhbCBBUElDIDEKaW9h cGljMDogQXNzaWduaW5nIFBDSSBJUlEgMjMgdG8gbG9jYWwgQVBJQyAyCm1zaTogQXNzaWduaW5n IE1TSSBJUlEgMjU2IHRvIGxvY2FsIEFQSUMgMwooZGExOnVtYXNzLXNpbTA6MDowOjEpOiBlcnJv ciA2CihkYTE6dW1hc3Mtc2ltMDowOjA6MSk6IFVucmV0cnlhYmxlIEVycm9yCmRhMSBhdCB1bWFz cy1zaW0wIGJ1cyAwIHRhcmdldCAwIGx1biAxCmRhMTogPEdlbmVyaWMgRmxhc2ggSFMtQ09NQk8g NC40ND4gUmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKZGExOiA0MC4wMDBN Qi9zIHRyYW5zZmVycwpkYTE6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBO T1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2VudAooZGEwOnVtYXNzLXNpbTA6MDowOjApOiBlcnJv ciA2CihkYTA6dW1hc3Mtc2ltMDowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCk9wZW5lZCBkaXNr IGRhMCAtPiA2CihkYTA6dW1hc3Mtc2ltMDowOjA6MCk6IGVycm9yIDYKKGRhMDp1bWFzcy1zaW0w OjA6MDowKTogVW5yZXRyeWFibGUgRXJyb3IKT3BlbmVkIGRpc2sgZGEwIC0+IDYKKGRhMTp1bWFz cy1zaW0wOjA6MDoxKTogZXJyb3IgNgooZGExOnVtYXNzLXNpbTA6MDowOjEpOiBVbnJldHJ5YWJs ZSBFcnJvcgpPcGVuZWQgZGlzayBkYTEgLT4gNgooZGExOnVtYXNzLXNpbTA6MDowOjEpOiBlcnJv ciA2CihkYTE6dW1hc3Mtc2ltMDowOjA6MSk6IFVucmV0cnlhYmxlIEVycm9yCk9wZW5lZCBkaXNr IGRhMSAtPiA2ClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvYWQ2czFhCmN0X3Rv X3RzKFsyMDA5LTAxLTA4IDAwOjA5OjI3XSkgPSAxMjMxMzczMzY3LjAwMDAwMDAwMApzdGFydF9p bml0OiB0cnlpbmcgL3NiaW4vaW5pdAp0c190b19jdCgxMjMxMzczMzg0LjczMDgzODExNykgPSBb MjAwOS0wMS0wOCAwMDowOTo0NF0KdWh1Yjg6IGF0IHVodWI3IHBvcnQgMiAoYWRkciAyKSBkaXNj b25uZWN0ZWQKdWh1Yjk6IGF0IHVodWI4IHBvcnQgMSAoYWRkciAzKSBkaXNjb25uZWN0ZWQKdW1h c3MwOiBhdCB1aHViOSBwb3J0IDEgKGFkZHIgNCkgZGlzY29ubmVjdGVkCihwYXNzMDp1bWFzcy1z aW0wOjA6MDowKTogbG9zdCBkZXZpY2UKKHBhc3MwOnVtYXNzLXNpbTA6MDowOjApOiByZW1vdmlu ZyBkZXZpY2UgZW50cnkKKGRhMDp1bWFzcy1zaW0wOjA6MDowKTogbG9zdCBkZXZpY2UKKGRhMDp1 bWFzcy1zaW0wOjA6MDowKTogcmVtb3ZpbmcgZGV2aWNlIGVudHJ5CihwYXNzMTp1bWFzcy1zaW0w OjA6MDoxKTogbG9zdCBkZXZpY2UKKHBhc3MxOnVtYXNzLXNpbTA6MDowOjEpOiByZW1vdmluZyBk ZXZpY2UgZW50cnkKKGRhMTp1bWFzcy1zaW0wOjA6MDoxKTogbG9zdCBkZXZpY2UKKGRhMTp1bWFz cy1zaW0wOjA6MDoxKTogcmVtb3ZpbmcgZGV2aWNlIGVudHJ5CnVtYXNzMDogZGV0YWNoZWQKdWh1 Yjk6IGRldGFjaGVkCnVodWI4OiBkZXRhY2hlZAo= ------=_Part_14307_5073483.1231436236730-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 17:39:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80CD110658F9 for ; Thu, 8 Jan 2009 17:39:15 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE258FC1F for ; Thu, 8 Jan 2009 17:39:14 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n08HdE10071513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 09:39:14 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <49663A42.7010101@freebsd.org> Date: Thu, 08 Jan 2009 09:39:14 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> In-Reply-To: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Cc: FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 17:39:19 -0000 Garrett Cooper wrote: > Hello folks, > As many probably know, I recently installed FreeBSD 8-CURRENT on my desktop. > One of the things I'm noting is that when I use dual displays with > the nvidia driver, and xscreensaver kicks in and keeps going for a > period of time, the machine's X.org console eats up a core, and when I > try and do anything like gdb Xorg, the system hangs, attempts to panic > (I assume that's the case because I hear it beep and attempt to > restart), then I have to give it a warm boot. truss(1)'ing Xorg showed > that there were a lot of SIGALARM's being fired and masked. > This is incredibly reminiscent of the days when I used to run Linux and > I forgot to configure my dump device (doh), but this problem appears > to be easily reproducible with my environment. I'm fixing that issue > right now, so I should have a working crashdump soon... > Just wondering if anyone else has seen this issue, or if it's just me > once again. > I have been battling with the nvidia binary driver on HEAD for a long time. I've got a Quadro NVS card: vgapci0@pci0:1:0:0: class=0x030000 card=0x019010de chip=0x018a10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'Quadro NVS with AGP 8x [NV18GL.2]' class = display subclass = VGA and run the older port because the card support was yanked at some point: nvidia-driver-96.43.07 NVidia graphics card binary drivers for hardware OpenGL ren I run dual-dvi displays w/ xinerama. I have not seen panics but I do see unacceptable performance. The most obvious problems are impossible mouse and rendering lag. I also see large memory consumption when running something like firefox w/ lots of hidden/off-screen images in a page (e.g. p4web). I am now 100% certain the nvidia driver is at fault as I swapped in an ATI card over the holiday break and the change was like night and day. Unfortunately the xrandr support for the ATI card was too busted to use so I gave up and stuck the nvidia card back in the box (for those that care the card is a Radeon 9600 and the problem is that after a while one display would blank randomly). This is a dual-core AMD (i386) desktop but performance actually dropped when I went from UP to SMP which makes me believe there's something braindead in the nvidia driver. The problems have only gotten worse as FreeBSD has evolved. I've not replaced the video card because I need dual-dvi in an AGP format which is rare these days. Moving to PCIE means a new mb/box which I'm trying to avoid. Sam From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 17:55:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92BB61065752 for ; Thu, 8 Jan 2009 17:55:54 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 20AF18FC1E for ; Thu, 8 Jan 2009 17:55:54 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 321BC1CCA7; Thu, 8 Jan 2009 18:55:53 +0100 (CET) Date: Thu, 8 Jan 2009 18:55:53 +0100 From: Ed Schouten To: Damien Fleuriot Message-ID: <20090108175553.GQ45775@hoeg.nl> References: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QFliEIXSSz7hGqqc" Content-Disposition: inline In-Reply-To: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: Bug or unwanted behaviour in echo ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 17:55:58 -0000 --QFliEIXSSz7hGqqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Damien, If you want to see what actually happens when you run those echo commands, you can run: echo -n "foobarbaz" | hexdump -C Or you can use xxd(1). Good luck! --=20 Ed Schouten WWW: http://80386.nl/ --QFliEIXSSz7hGqqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklmPikACgkQ52SDGA2eCwVEmQCbBqNFz0Q081Ugosf/dcpmH42w d0sAmgLgby+oudQv8BlqbhlwKxKzvlCS =vp8Z -----END PGP SIGNATURE----- --QFliEIXSSz7hGqqc-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 18:16:12 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6851065673 for ; Thu, 8 Jan 2009 18:16:12 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id DF8AD8FC0C for ; Thu, 8 Jan 2009 18:16:11 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n08IG8Yh028656; Thu, 8 Jan 2009 18:16:08 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1LKzQO-0007C0-M0; Thu, 08 Jan 2009 18:16:08 +0000 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id n08IG8tl099449; Thu, 8 Jan 2009 18:16:08 GMT (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id n08IG8Ij099448; Thu, 8 Jan 2009 18:16:08 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: barney_cordoba@yahoo.com In-Reply-To: <321406.5257.qm@web63908.mail.re1.yahoo.com> References: <321406.5257.qm@web63908.mail.re1.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 08 Jan 2009 18:16:08 +0000 Message-Id: <1231438568.98820.7.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: current@FreeBSD.org Subject: Re: Adding a new kernel module? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 18:16:12 -0000 On Thu, 2009-01-08 at 09:08 -0800, Barney Cordoba wrote: > I'm testing a new kernel module that needs to be compiled in, and > everything works fine except that make doesn't make the module for the > new driver. The driver is under dev > > /sys/dev/foo > > How does the kernel make system decide what modules to build? How can > I add a new kernel modules to the build system to get it to build the > new module automatically? Short answer: have a look at /usr/src/sys/modules/Makefile and the directories below that. It might be a little out of date, but have a look at http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-kld.html Gavin From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 18:48:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4907D1065672 for ; Thu, 8 Jan 2009 18:48:57 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from mail.rubicom.hu (mail.rubicom.hu [89.147.80.28]) by mx1.freebsd.org (Postfix) with ESMTP id A33798FC12 for ; Thu, 8 Jan 2009 18:48:57 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from localhost ([127.0.0.1] helo=mail.rubicom.hu) by mail.rubicom.hu with smtp (Exim 4.63) (envelope-from ) id 1LKzJ9-00012k-08 for freebsd-current@freebsd.org; Thu, 08 Jan 2009 19:08:39 +0100 Received: from ip5993549e.rubicom.hu ([89.147.84.158] helo=baranyfelhocske.buza.adamsfamily.xx) by mail.rubicom.hu with esmtp (Exim 4.63) (envelope-from ) id 1LKzJ8-00012c-TC for freebsd-current@freebsd.org; Thu, 08 Jan 2009 19:08:38 +0100 Received: from baranyfelhocske.buza.adamsfamily.xx (localhost [127.0.0.1]) by baranyfelhocske.buza.adamsfamily.xx (8.14.3/8.14.3) with ESMTP id n08I8caV005946 for ; Thu, 8 Jan 2009 19:08:38 +0100 (CET) (envelope-from sziszi@bsd.hu) Received: (from sziszi@localhost) by baranyfelhocske.buza.adamsfamily.xx (8.14.3/8.14.3/Submit) id n08I8chb005945 for freebsd-current@freebsd.org; Thu, 8 Jan 2009 19:08:38 +0100 (CET) (envelope-from sziszi@bsd.hu) X-Authentication-Warning: baranyfelhocske.buza.adamsfamily.xx: sziszi set sender to sziszi@bsd.hu using -f Date: Thu, 8 Jan 2009 19:08:38 +0100 From: Szilveszter Adam To: freebsd-current@freebsd.org Message-ID: <20090108180838.GA3094@baranyfelhocske.buza.adamsfamily.xx> References: <321406.5257.qm@web63908.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <321406.5257.qm@web63908.mail.re1.yahoo.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: Adding a new kernel module? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 18:48:59 -0000 Hello Barney, On Thu, Jan 08, 2009 at 09:08:07AM -0800, Barney Cordoba wrote: > I'm testing a new kernel module that needs to be compiled in, and everything works fine except that make doesn't make the module for the new driver. The driver is under dev > > /sys/dev/foo > > How does the kernel make system decide what modules to build? How can I add a new kernel modules to the build system to get it to build the new module automatically? This is quite easy. You should make a new directory under sys/modules with the module name, prepare a Makefile there (you can use one of the many existing ones in the other module directories as example). This Makefile should contain all files that your driver uses, and any specific flags that are used for compilation. Again, you will find many simple and more complicated examples among the existing modules. After this, you should add the new subdir to the Makefile in sys/modules (the order is alphabetical now, but you can add it anywhere). I believe that's all. Hope this helps. -- Regards: Szilveszter ADAM Budapest Hungary From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 19:11:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD0E81065670 for ; Thu, 8 Jan 2009 19:11:17 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 32D1C8FC14 for ; Thu, 8 Jan 2009 19:11:16 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 231216161; Thu, 08 Jan 2009 21:11:16 +0200 Message-ID: <49664FD8.1060700@FreeBSD.org> Date: Thu, 08 Jan 2009 21:11:20 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> <49647602.9060402@FreeBSD.org> <49649333.6060902@gmail.com> <7d6fde3d0901080937t29ec42f5i6684b9223d0b368a@mail.gmail.com> In-Reply-To: <7d6fde3d0901080937t29ec42f5i6684b9223d0b368a@mail.gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: snd_hda(4): getting line-in to work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 19:11:18 -0000 Garrett Cooper wrote: > Ok, I got stuck again. Can you possibly push me in the right > direction (complete verbose dmesg attached)? The line-in and SPDIF > (not so much of a concern) are the only issues that I'm aware of. I'll > have to open up my case and wire up the front ports in order to test > them for you. Ok. Let's stop for a moment and start from the beginning, because now it is already like a puzzle for me too. Let me explain once more what I see you have and then you explain me where is your problem. You have 3 PCM devices configured: - pcm0: 7.1 playback via 4 rear jacks (Green, Black, Orange and Grey) + record from mic (front Pink), line (rear Blue), monitor (second mic, rear Pink), cd (internal Black) or mix (sum of all these). - pcm1: stereo playback via front Green jack. - pcm2: SPDIF output As for me, this configuration is correct and good enough. You can record from your line-in via pcm0 after selecting that source via `mixer =rec line` command. You can playback via SPDIF by using pcm2 device. So what's wrong? What are you doing and what is not working and how? > Also, the knobs that show up in xfce4-mixer are completely useless > for snd_hda(4) (every time I move the sliders it sets the volume back > to 0). Is this a known issue? You are the first. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 19:45:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D37E1106564A; Thu, 8 Jan 2009 19:45:01 +0000 (UTC) (envelope-from Manfred.Knick@T-Online.de) Received: from mailout03.t-online.de (mailout03.t-online.de [194.25.134.81]) by mx1.freebsd.org (Postfix) with ESMTP id 96D2F8FC1E; Thu, 8 Jan 2009 19:45:01 +0000 (UTC) (envelope-from Manfred.Knick@T-Online.de) Received: from fwd08.aul.t-online.de by mailout03.sul.t-online.de with smtp id 1LL0QY-0005sY-03; Thu, 08 Jan 2009 20:20:22 +0100 Received: from [192.168.1.21] (EwqEm+ZcohCX0EhpU-BaQ2RccKnHZBalcKca+nmKmW6Sg-vWXwo5RQfJ5wb0qUZZkO@[79.239.220.135]) by fwd08.t-online.de with esmtp id 1LL0QP-0VGLkO0; Thu, 8 Jan 2009 20:20:13 +0100 Message-ID: <496651ED.8080102@T-Online.de> Date: Thu, 08 Jan 2009 20:20:13 +0100 From: Manfred_Knick User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: current@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ID: EwqEm+ZcohCX0EhpU-BaQ2RccKnHZBalcKca+nmKmW6Sg-vWXwo5RQfJ5wb0qUZZkO X-TOI-MSGID: bdb551d1-8197-45ec-8e38-57848e2e79f3 X-Mailman-Approved-At: Thu, 08 Jan 2009 19:56:00 +0000 Cc: Subject: possibility of a "severe flaw in the logic of FreeBSD's kernel handling multiple host bridges ..." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 19:45:02 -0000 First: Congratulations upon 7.1 final RELEASE ! On Fri, 24 Oct 2008, I pointed out the "possibility of a severe flaw in the logic of FreeBSD's kernel handling multiple host bridges and the corresponding assignment of (in principle, correctly detected) devices to their host bridges" :: --> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/128331 :: --> http://forums.freebsd.org/showthread.php?t=236 but unfortunately, I did not get any response at all. Two mails to "kensmith@cse.Buffalo.EDU" asking for any contact e-mail address of a FreeBSD Kernel developer knowing his way around host-bridges and PCI-devices also gave no reaction. I am sorry for this noise (I would have preferred to handle this more quietly), but finally I take hope to the advice of Daniel Gerzo (Thanks @ danger): "If you will not receive any feedback I would recommend you to send an email to current@ and stable@ mailing lists. PR's sometimes get lost in the traffic and not all developers are checking GNATS all the time." Looking forward to a contact Kind regards Manfred From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 20:57:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2A45106566B for ; Thu, 8 Jan 2009 20:57:21 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 875318FC12 for ; Thu, 8 Jan 2009 20:57:21 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7A99F73098; Thu, 8 Jan 2009 22:02:21 +0100 (CET) Date: Thu, 8 Jan 2009 22:02:21 +0100 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20090108210221.GA87253@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: reduce directories in sys/modules ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 20:57:22 -0000 Is there a way to reduce the number of directories in sys/modules ? There seems to be one directory per module, even though many of those are related and the source resides in one place (e.g. sys/modules/iwifw/ has three children but the source is in sys/contrib/dev/iwi ; and the same goes for many other entries e.g. sys/modules/digi* <-> /sys/dev/digi, sys/modules/drm <-> sys/dev/drm sys/modules/ata and many more. Ideas ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 22:17:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D9561065748 for ; Thu, 8 Jan 2009 22:17:49 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 099FF8FC08 for ; Thu, 8 Jan 2009 22:17:48 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 58F0673098; Thu, 8 Jan 2009 23:22:50 +0100 (CET) Date: Thu, 8 Jan 2009 23:22:50 +0100 From: Luigi Rizzo To: Julian Elischer Message-ID: <20090108222250.GA90051@onelab2.iet.unipi.it> References: <20090108210221.GA87253@onelab2.iet.unipi.it> <4966756E.7050102@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4966756E.7050102@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: reduce directories in sys/modules ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 22:17:49 -0000 On Thu, Jan 08, 2009 at 01:51:42PM -0800, Julian Elischer wrote: > Luigi Rizzo wrote: > >Is there a way to reduce the number of directories in sys/modules ? > > > >There seems to be one directory per module, even though many of > >those are related and the source resides in one place > >(e.g. sys/modules/iwifw/ has three children but the source > >is in sys/contrib/dev/iwi ; and the same goes for many other > >entries e.g. > >sys/modules/digi* <-> /sys/dev/digi, > >sys/modules/drm <-> sys/dev/drm > >sys/modules/ata > > > >and many more. > >Ideas ? > > I have many under netgraph. > maybe we could cluster them by type. > ethernet > protocols > or does that not help what you want? yes, i wanted something like that: one directory per cluster (of course where it makes sense to pack stuff). Take e.g. /sys/dev/ata (but there are many similar cases) which has 24 files and generates 15 different directories, each one with only one Makefile containing the same thing # $FreeBSD: ... $ .PATH: ${.CURDIR}/../../../dev/ata KMOD= atasomething SRCS= ata-some-thing.c SRCS+= opt_ata.h ata_if.h device_if.h bus_if.h pci_if.h .include It would be a lot simpler to have one dir and one Makefile in /sys/modules/ata/Makefile with this content # $FreeBSD: ... $ common_headers= opt_ata.h ata_if.h device_if.h bus_if.h KMOD_LIST= atafoo atabar atabaz atadisc ataata atapci... SRCS_atafoo= ata-some-foo.c ${common_headers} SRCS_atabar= ata-bar-src.c ${common_headers} ... .include This would be backward compatible with the existing structure, provided that the bsd.kmod.mk expands the entries in KMOD_LIST creating the individual targets etc. cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 22:19:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 060DE10658EE for ; Thu, 8 Jan 2009 22:19:49 +0000 (UTC) (envelope-from prvs=julian=25242c0f6@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id E5B548FC1C for ; Thu, 8 Jan 2009 22:19:48 +0000 (UTC) (envelope-from prvs=julian=25242c0f6@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.63]) by smtp-outbound.ironport.com with ESMTP; 08 Jan 2009 13:51:43 -0800 Message-ID: <4966756E.7050102@elischer.org> Date: Thu, 08 Jan 2009 13:51:42 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Luigi Rizzo References: <20090108210221.GA87253@onelab2.iet.unipi.it> In-Reply-To: <20090108210221.GA87253@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: reduce directories in sys/modules ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 22:19:50 -0000 Luigi Rizzo wrote: > Is there a way to reduce the number of directories in sys/modules ? > > There seems to be one directory per module, even though many of > those are related and the source resides in one place > (e.g. sys/modules/iwifw/ has three children but the source > is in sys/contrib/dev/iwi ; and the same goes for many other > entries e.g. > sys/modules/digi* <-> /sys/dev/digi, > sys/modules/drm <-> sys/dev/drm > sys/modules/ata > > and many more. > Ideas ? I have many under netgraph. maybe we could cluster them by type. ethernet protocols or does that not help what you want? > > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 22:48:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F4E9106566B for ; Thu, 8 Jan 2009 22:48:15 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id AD71F8FC0A for ; Thu, 8 Jan 2009 22:48:14 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 15C6873098; Thu, 8 Jan 2009 23:53:16 +0100 (CET) Date: Thu, 8 Jan 2009 23:53:16 +0100 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20090108225316.GA91026@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: Subject: kldpatch updated (Re: RFC: new utility, kmodpatch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 22:48:15 -0000 Hi, I have updated and renamed the "kldpatch" utility (formerly kmodpatch), so that now it can also patch the disk copy of modules (or kernel). You can find the updated version at the following URL http://info.iet.unipi.it/~luigi/FreeBSD/20090108-kldpatch.tgz A description of what it can do is below (old posting attached for convenience). The manpage in the tarball is more up-to-date. cheers luigi On Thu, Jan 01, 2009 at 07:30:26PM +0100, Luigi Rizzo wrote: > I mentioned this utility a couple of months ago, and it's now working > so i would like to receive feedback on whether this is good to have > as part of the system, or just keep it as a port (which is what > i plan to do by default). > > In a nutshell, the kmodpatch utility can print or alter the content > of device/quirk tables in kernel modules (I think Linux has some > similar tool, though i don't remember the name -- or perhaps it is > a feature of insmod ?). > > Full manpage is attached at the end, full sources are at > > http://info.iet.unipi.it/~luigi/FreeBSD/20090101-kmodpatch.tgz > > What is missing is some extra code to let it patch an on-disk file > (elfdump returns the info we need, so in the worst case we just > need to write a wrapper around elfdump). > > Feedback welcome. > > cheers > luigi > > ------- manpage content -------- > > KMODPATCH(8) FreeBSD System Manager's Manual KMODPATCH(8) > > NAME > kmodpatch -- print/modify device/quirk tables in kernel modules > > SYNOPSIS > kmodpatch [-v] [-t file | format] module_name table_name [@offset [args > ...]] > > DESCRIPTION > The kmodpatch utility can print or alter the content of device/quirk > tables in kernel modules. These tables are generally used to identify > devices, and possibly apply specific quirks to enable/disable certain > features. kmodpatch is especially useful to let the kernel recognise a > new device without rebooting and rebuilding/reinstalling kernel or mod- > ules. > > In read mode (when no args are specified), kmodpatch only list one or > more entries in the matching module and table. > > In write mode, kmodpatch overwrites a user's specified entry in a table > with the values passed on the command line. kmodpatch does some amount > of checking to make sure that the arguments (module and table name, off- > set, parameters formats) are compatible with the currently loaded mod- > ules. > > A couple of real life examples: > > kmodpatch umass.ko - @0 0x4050 0x4a5 0x0101 0x4200 > set the kernel to use flags UMASS_PROTO_SCSI | UMASS_PROTO_BBB and > quirks WRONG_CSWSIG | NO_SYNCHRONIZE_CACHE for a certain GSM phone > that implements the umass interface; > > kmodpatch uscanner.ko - @0 0x04b8 0x084a 0 > let uscanner.ko recognise a newly introduced MFP scanner device. > > kmodpatch relies on a list of which modules and tables (associated to > kernel symbols) it can work on, and the format of the records in each ta- > ble. By default kmodpatch uses an internal list, which can be overridden > from the command line using the -t option followed by either a file name, > or by immediate text describing the kernel table. The format of the file > is described in Section MODULE DESCRIPTION > > The following options are available: > > -v Verbose mode, print some debugging info > > -t file | format > Specify a file containing the name and format of descriptor > tables, or a line with the actual format of the table. > > MODULE DESCRIPTION > The file (or text) describing modules, tables and record structure has a > simple text format with one line per table. The `#' character is a com- > ment delimiter, and can appear anywhere in the text. Each valid line > must contain the following fields: > > module_name symbol_name entry_format [entry_format ...] > > Each entry_format describes one field in the table, and it is made of a > number and/or a character specifying the field size and format, followed > by an optional ':' and a word describing the field itself. > > Supported formats are: > > 2 | 2l | 2b > 16-bit unsigned in host, little-endian or big-endian format; > > 4 | 4l | 4b > 32-bit unsigned in host, little-endian or big-endian format; > > 8 | 8l | 8b > 64-bit unsigned in host, little-endian or big-endian format; > > p a pointer; > > s a null-terminated string; > > The optional description is used as a header when listing the content of > a table. > > EXAMPLE MODULE DESCRIPTION > The following is an example of a file containing module descriptions. > > umass.ko umass_devdescrs 4:vendor 4:product 4:rev 2:proto 2:quirks > uscanner.ko uscanner_devs 2:vendor 2:device 4:flags # comment > if_nfe.ko nfe_devs 2:vendor 2:device s:name > if_re.ko re_devs 2:vendor 2:device 4:type s:name > > EXAMPLES > In addition to the two examples given at the beginning, one can use > kmodpatch to explore the content of kernel tables, as follows. > > To list entries in module if_re: > > kmodpatch if_re - > > To list entry 10 in module umass: > > kmodpatch umass - @10 > > To set the last entry in module uscanner.ko > > kmodpatch uscanner.ko - @-1 0x04b8 0x0839 0 > > WARNINGS > kmodpatch requires root privileges even to just read the content of the > kernel tables. > > In write mode, the use of kmodpatch is as dangerous as accessing > /dev/kmem in write mode, even though kmodpatch does some amount of check- > ing to make sure that the arguments passed are reasonable. To this pur- > pose, it is fundamental that the table descriptions used by kmodpatch > match the actual structure of the kernel tables. There is no automatic > way to extract this info. > > BUGS > Right now, kmodpatch only writes to in-memory modules (or kernel). As a > consequence the approach is not suitable to devices that are persistently > connected to the system and for which the system cannot do a "reprobe". > > SEE ALSO > kldconfig(8), kldload(8), kldstat(8), kldunload(8) > > HISTORY > The kmodpatch utility first appeared in FreeBSD 8.0 inspired by a similar > feature present on Linux. > > AUTHORS > The kmodpatch utility was designed and implemented by Luigi Rizzo > . From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 22:59:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5618C1065674 for ; Thu, 8 Jan 2009 22:59:07 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 307128FC1C for ; Thu, 8 Jan 2009 22:59:07 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n08Mx6Hq073767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 14:59:06 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <4966853A.70605@freebsd.org> Date: Thu, 08 Jan 2009 14:59:06 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Luigi Rizzo References: <20090108210221.GA87253@onelab2.iet.unipi.it> In-Reply-To: <20090108210221.GA87253@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Cc: current@freebsd.org Subject: Re: reduce directories in sys/modules ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 22:59:07 -0000 Luigi Rizzo wrote: > Is there a way to reduce the number of directories in sys/modules ? > > There seems to be one directory per module, even though many of > those are related and the source resides in one place > (e.g. sys/modules/iwifw/ has three children but the source > is in sys/contrib/dev/iwi ; and the same goes for many other > entries e.g. > sys/modules/digi* <-> /sys/dev/digi, > sys/modules/drm <-> sys/dev/drm > sys/modules/ata > > and many more. > Ideas ? > Perhaps you should start by saying why you want to change this? Sam From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 23:00:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29F6C1065694 for ; Thu, 8 Jan 2009 23:00:10 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2E68FC18 for ; Thu, 8 Jan 2009 23:00:02 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1LL3r7-0004pm-Qe>; Fri, 09 Jan 2009 00:00:01 +0100 Received: from e178036186.adsl.alicedsl.de ([85.178.36.186] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1LL3r7-0004cT-N7>; Fri, 09 Jan 2009 00:00:01 +0100 Message-ID: <4966859E.7080301@mail.zedat.fu-berlin.de> Date: Fri, 09 Jan 2009 00:00:46 +0100 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> In-Reply-To: <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.36.186 X-Mailman-Approved-At: Thu, 08 Jan 2009 23:08:22 +0000 Cc: Roman Divacky , FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 23:00:11 -0000 Garrett Cooper wrote: > On Jan 8, 2009, at 12:36 AM, Roman Divacky wrote: > >> On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: >>> Hello folks, >>> As many probably know, I recently installed FreeBSD 8-CURRENT on >>> my desktop. >>> One of the things I'm noting is that when I use dual displays with >>> the nvidia driver, and xscreensaver kicks in and keeps going for a >>> period of time, the machine's X.org console eats up a core, and when I >>> try and do anything like gdb Xorg, the system hangs, attempts to panic >>> (I assume that's the case because I hear it beep and attempt to >>> restart), then I have to give it a warm boot. truss(1)'ing Xorg showed >>> that there were a lot of SIGALARM's being fired and masked. >>> This is incredibly reminiscent of the days when I used to run >>> Linux and >>> I forgot to configure my dump device (doh), but this problem >>> appears >>> to be easily reproducible with my environment. I'm fixing that issue >>> right now, so I should have a working crashdump soon... >>> Just wondering if anyone else has seen this issue, or if it's >>> just me >>> once again. >>> Thanks, >> >> the nvidia driver keeps my 8-current crashing/deadlocking when >> playing video >> quite often (once a week?). I have no idea what it causes. >> >> the code of the driver seems to be done in 5.x times. I believe it needs >> some rehashing as it might not get the semantics of "things" in 8.x >> right > > > Hey Roman! > Yeah, I'm fine with it being slow, for a little while, as long as > it's functional... I do realize that nvidia is still giant locked > (ew..), so it might be some nasty resource contention. > Are you using Linux emulation support with the driver? > Cheers, > -Garrett > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" I have and I had the same in FreeBSD 7.0/7.1 and now with 8.0-CUR with both a NV8600GTS and an older NV6800GT. A very old NV6600 never showed up these lockings when I used that PCIe-Card with FreeBSD 7.0/7.1, but I'm not sure. The locks came spontanous, sometimes after heavy usage of 'mplayer', but sometimes instantanously after the destop showed up. On those boxes, there is no Linux emulation and no Linux BLOB (useless, due to 64 Bit). I swapped the 'nv' driver on all FreeBSD boxes with 'vesa', because there is another issue with sprites/graphics buffers many times reported using FireFox. When the display got locked, sometimes I had the chance opening a ssh session killing Xorg/xdm and restarting working, but by the end, that was when changing towards 8.0-CUR, this 'trick' didn't work anymore. On FBSD 7, Xorg was eating up 100% CPU time. From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 23:14:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1DD8106566C; Thu, 8 Jan 2009 23:14:08 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id 493A08FC08; Thu, 8 Jan 2009 23:14:07 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id n08Mxxnv014792; Fri, 9 Jan 2009 00:59:59 +0200 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.3/8.14.3) with ESMTP id n08Mxx7O004392; Fri, 9 Jan 2009 00:59:59 +0200 Received: from kobe.laptop (adsl18-21.kln.forthnet.gr [77.49.145.21]) by MX-IN-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id n08MxooL032019; Fri, 9 Jan 2009 00:59:51 +0200 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=keramida@freebsd.org; spf=permerror Authentication-Results: MX-IN-01.forthnet.gr header.from=keramida@freebsd.org; sender-id=permerror Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n08MxoE6003301; Fri, 9 Jan 2009 00:59:50 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n08MxnuM003297; Fri, 9 Jan 2009 00:59:49 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Alexander Best References: Date: Fri, 09 Jan 2009 00:59:49 +0200 In-Reply-To: (Alexander Best's message of "Thu, 08 Jan 2009 18:13:14 +0100 (CET)") Message-ID: <87prixz9ne.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, sos@freebsd.org Subject: Re: patch to fix burncd bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 23:14:09 -0000 On Thu, 08 Jan 2009 18:13:14 +0100 (CET), Alexander Best wrote: > could somebody please commit the following patch to dev/ata? it fixes > a nasty bug during fixation in burncd. the bug exists in RELENG6, > RELENG7 and HEAD (and maybe RELENG5): > > http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch > > the whole PR can be found here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 I think Soren is the best person to look into this bug (Cc: added). Soren, what do you think? Does the patch at bin/95979 look like a nice change to commit? I just saw this PR so I haven't tried the patch on my laptop's CURRENT yet, but I can confirm that burning CD-ROMs and DVDs is busted in my laptop for a few weeks now. From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 23:07:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BE3F106564A for ; Thu, 8 Jan 2009 23:07:35 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 48C6B8FC20 for ; Thu, 8 Jan 2009 23:07:35 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1LL3yQ-0005en-AS>; Fri, 09 Jan 2009 00:07:34 +0100 Received: from e178036186.adsl.alicedsl.de ([85.178.36.186] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1LL3yQ-0004wi-7t>; Fri, 09 Jan 2009 00:07:34 +0100 Message-ID: <49668763.8020705@mail.zedat.fu-berlin.de> Date: Fri, 09 Jan 2009 00:08:19 +0100 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.36.186 X-Mailman-Approved-At: Thu, 08 Jan 2009 23:22:20 +0000 Subject: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 23:07:35 -0000 When will gcc 4.3 incorporated in FreeBSD 8 and become the standard compiler suite? We figured out that gcc 4.3 does have a speed gain in some numerical code of 3 - 8 % and I guess we can use this in the basic OS as well ... Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 23:23:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A689106567C; Thu, 8 Jan 2009 23:23:24 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 5AAF68FC0A; Thu, 8 Jan 2009 23:23:24 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 799397309E; Fri, 9 Jan 2009 00:28:25 +0100 (CET) Date: Fri, 9 Jan 2009 00:28:25 +0100 From: Luigi Rizzo To: Sam Leffler Message-ID: <20090108232825.GA91454@onelab2.iet.unipi.it> References: <20090108210221.GA87253@onelab2.iet.unipi.it> <4966853A.70605@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4966853A.70605@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: reduce directories in sys/modules ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 23:23:25 -0000 On Thu, Jan 08, 2009 at 02:59:06PM -0800, Sam Leffler wrote: > Luigi Rizzo wrote: > >Is there a way to reduce the number of directories in sys/modules ? > > > >There seems to be one directory per module, even though many of > >those are related and the source resides in one place ... > Perhaps you should start by saying why you want to change this? Because I find it overcomplicated and error prone to force one directory per module. There are many examples of closely related modules whose source live in a single directory whereas the module infrastructure consumes a large subtree. I don't want to put every module in one Makefile, but at least the related ones sometimes do deserve a merge. I already mentioned ata with 15 children, iwifw with 3 entries, netgraph with over 50 children, geom has several too... The problems that I see are: + very easy to forget to update one or more entries when creating or modifying the makefiles; + redundancy in the content of the Makefiles -- e.g. often times related modules share headers and other Makefile variables that right now we need to repeat in every Makefile (and given that the hierarchy is not clear, children Makefiles cannot inherit from the parent's Makefile) + confusion with the names and the hierarchy: sometimes the children are at the same level as the parent (e.g. modules/wlan and modules/wlan_*), sometimes a child replicates a parent's name (modules/ata/ata) sometimes there is a repeated prefix (modules/geom/geom_*) and sometimes there is not (e.g. modules/netgraph/*) I know that kmod.mk is quite large and touching it is perhaps non trivial, but if there is at least agreement on what is the direction we might find someone who wants to work on this. cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 23:33:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B64A31065674 for ; Thu, 8 Jan 2009 23:33:12 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 6596F8FC1D for ; Thu, 8 Jan 2009 23:33:12 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 64A7C3B9A3 for ; Fri, 9 Jan 2009 00:33:11 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GavA700RnGIA for ; Fri, 9 Jan 2009 00:33:11 +0100 (CET) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 1B89C3B9A2; Fri, 9 Jan 2009 00:33:11 +0100 (CET) Date: Fri, 9 Jan 2009 00:33:11 +0100 From: Ollivier Robert To: freebsd-current@freebsd.org Message-ID: <20090108233311.GA69883@keltia.freenix.fr> References: <49668763.8020705@mail.zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49668763.8020705@mail.zedat.fu-berlin.de> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7 / Dell D820 SMP User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 23:33:12 -0000 According to O. Hartmann: > When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > compiler suite? We figured out that gcc 4.3 does have a speed gain in > some numerical code of 3 - 8 % and I guess we can use this in the basic > OS as well ... I'd rather have llvm instead... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Dons / donation Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 00:00:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB359106566B for ; Fri, 9 Jan 2009 00:00:24 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8FC8FC12 for ; Fri, 9 Jan 2009 00:00:23 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.37,236,1231110000"; d="diff'?scan'208";a="266549112" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 09 Jan 2009 01:00:22 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 6CFB71B074C; Fri, 9 Jan 2009 01:00:22 +0100 (CET) Date: Fri, 09 Jan 2009 01:00:17 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-200901090000171e86ffa800002ad6-a_best01+ Subject: fix tools/tools/usb/print-usb-if-vids.sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 00:00:25 -0000 This is a MIME encoded multipart message. --+permail-200901090000171e86ffa800002ad6-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit here's a fix to make tools/tools/usb/print-usb-if-vids.sh work again. the file hasn't been touched in over 4 years. ;) alex --+permail-200901090000171e86ffa800002ad6-a_best01+ Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="printusbifvids.sh.diff" LS0tIHRvb2xzL3Rvb2xzL3VzYi9wcmludC11c2ItaWYtdmlkcy5zaAkyMDA4LTExLTI3IDAwOjI1 OjM0LjAwMDAwMDAwMCArMDAwMAorKysgdG9vbHMvdG9vbHMvdXNiL3ByaW50LXVzYi1pZi12aWRz LnNoCTIwMDktMDEtMDkgMDA6NDk6NTAuMDAwMDAwMDAwICswMDAwCkBAIC0yNyw1ICsyNyw1IEBA CiAjICRGcmVlQlNEJAogCiAKLWZldGNoIC1vIC90bXAvdXNiLmlmIGh0dHA6Ly93d3cudXNiLm9y Zy9hcHAvcHViL2R1bXAvY29tcF9kdW1wLworZmV0Y2ggLW8gL3RtcC91c2IuaWYgaHR0cDovL3d3 dy51c2Iub3JnL2RldmVsb3BlcnMvdG9vbHMvY29tcF9kdW1wLwogYXdrIC1GICd8JyAneyBwcmlu dGYgIiUjMDZ4XHQlc1xuIiwgJDEsICQyIH0nIDwgL3RtcC91c2IuaWYgfCBzb3J0Cg== --+permail-200901090000171e86ffa800002ad6-a_best01+-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 00:21:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A45D106566C for ; Fri, 9 Jan 2009 00:21:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 7BE6E8FC1A for ; Fri, 9 Jan 2009 00:21:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n090LXPU092915; Thu, 8 Jan 2009 16:21:33 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n090LXEu092914; Thu, 8 Jan 2009 16:21:33 -0800 (PST) (envelope-from sgk) Date: Thu, 8 Jan 2009 16:21:33 -0800 From: Steve Kargl To: "O. Hartmann" Message-ID: <20090109002133.GA92874@troutmask.apl.washington.edu> References: <49668763.8020705@mail.zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49668763.8020705@mail.zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 00:21:33 -0000 On Fri, Jan 09, 2009 at 12:08:19AM +0100, O. Hartmann wrote: > When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > compiler suite? We figured out that gcc 4.3 does have a speed gain in > some numerical code of 3 - 8 % and I guess we can use this in the basic > OS as well ... > Probably not for a very long time. gcc 4.3 requires both GMP and MPFR libraries. Neither library is in src. gcc 4.3 is also subject to the GPLv3 license. This may have a negative impact on contributions from commercial entities such as Juniper. Is there a problem with using port/lang/gcc43? -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 00:24:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE09E1065670 for ; Fri, 9 Jan 2009 00:24:15 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1E88FC14 for ; Fri, 9 Jan 2009 00:24:15 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.166.46] ([68.0.14.34]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n090NTQw004479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 19:23:29 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Manfred_Knick In-Reply-To: <496651ED.8080102@T-Online.de> References: <496651ED.8080102@T-Online.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4quzKMo81l27ylrUYnye" Organization: FreeBSD Date: Thu, 08 Jan 2009 19:24:08 -0500 Message-Id: <1231460648.93079.65.camel@squirrel.corp.cox.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@freebsd.org, current@freebsd.org Subject: Re: possibility of a "severe flaw in the logic of FreeBSD's kernel handling multiple host bridges ..." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 00:24:16 -0000 --=-4quzKMo81l27ylrUYnye Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-01-08 at 20:20 +0100, Manfred_Knick wrote: > First: Congratulations upon 7.1 final RELEASE ! >=20 > On Fri, 24 Oct 2008, I pointed out the >=20 > "possibility of a severe flaw in the logic of FreeBSD's kernel > handling multiple host bridges > and the corresponding assignment of > (in principle, correctly detected) > devices to their host bridges" >=20 > :: --> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/128331 >=20 > :: --> http://forums.freebsd.org/showthread.php?t=3D236 >=20 > but unfortunately, I did not get any response at all. > Two mails to "kensmith@cse.Buffalo.EDU" asking for any contact e-mail=20 > address of a FreeBSD Kernel developer knowing his way around=20 > host-bridges and PCI-devices also gave no reaction. >=20 > I am sorry for this noise > (I would have preferred to handle this more quietly), > but finally I take hope to the advice of Daniel Gerzo (Thanks @ danger): >=20 > "If you will not receive any feedback I would recommend you to send an > email to current@ and stable@ mailing lists. PR's sometimes get lost > in the traffic and not all developers are checking GNATS all the time." >=20 > Looking forward to a contact I'm really not sure that I am the best person to try and tackle this, but it does fall somewhere near me... Can you send me a pciconf -lv. robert. > Kind regards >=20 > Manfred > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --=-4quzKMo81l27ylrUYnye Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAklmmSgACgkQM4TrQ4qfROMiLgCfaVsdDfiu2umDnv045Xa8cZMl D7IAn1zf0ifxFd6hDpQN6frES+fEuX5n =tt8s -----END PGP SIGNATURE----- --=-4quzKMo81l27ylrUYnye-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 01:45:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86714106564A for ; Fri, 9 Jan 2009 01:45:28 +0000 (UTC) (envelope-from rmtodd@servalan.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id CC9DE8FC08 for ; Fri, 9 Jan 2009 01:45:27 +0000 (UTC) (envelope-from rmtodd@servalan.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 190B4C7C; Thu, 8 Jan 2009 20:45:26 -0500 (EST) Received: from rmtodd by servalan.servalan.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LL5YT-00063G-Oy; Thu, 08 Jan 2009 18:48:53 -0600 Date: Thu, 8 Jan 2009 18:48:53 -0600 From: Richard Todd To: freebsd-current@freebsd.org Message-ID: <20090109004853.GA34384@ichotolot.servalan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.4.2.3i Subject: Recent changes to pseudofs causing panics -- leaking a vnode lock? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 01:45:28 -0000 I've noticed that ever since updating to a kernel after the recent changes to the pseudofs code late last month, that I've occasionally gotten the=20 following sort of panic: System call readlink returning with the following locks held: exclusive lockmgr pseudofs (pseudofs) r =3D 0 (0xffffff00ba581cc8) locked @= /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:193 panic: witness_warn The line in question is the one I marked by an arrow in this chunk of the= =20 pfs_vncache_alloc code:=20 if ((pn->pn_flags & PFS_PROCDEP) !=3D 0) (*vpp)->v_vflag |=3D VV_PROCDEP; pvd->pvd_vnode =3D *vpp; VN_LOCK_AREC(*vpp); vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); <=3D=3D=3D=3D this lock here error =3D insmntque(*vpp, mp); So somehow, a vnode is getting locked here and not getting unlocked. I suspect the code in the retry2: loop later, simply because that's the code that got added in the late December commits, but I'm not clear on how exactly. I've tried littering the code with extra printfs to try to clarify what's going on, but alas, I'm still not really sure what's going on. I do have a good coredump that I can get info out of, if someone can suggest to me what would be useful things to dump. Anyway, here's the patch for the debugging printfs I added, and the console messages produced by those printfs from the most recent coredump/panic. The console msgs do seem to indicate some sort of race condition going on, though, as they seem to show two or more proces= ses simultaneously hitting the pseudofs code and hitting my debugging print statements (alas, making the console log rather a confused mess.) The debugging additions: Index: pseudofs_vncache.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/FreeBSDCVS/src/sys/fs/pseudofs/pseudofs_vncache.c,v retrieving revision 1.44 diff -u -r1.44 pseudofs_vncache.c --- pseudofs_vncache.c 29 Dec 2008 13:25:58 -0000 1.44 +++ pseudofs_vncache.c 8 Jan 2009 02:22:50 -0000 @@ -129,6 +129,7 @@ mtx_unlock(&pfs_vncache_mutex); if (vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, curthread) =3D=3D 0) { ++pfs_vncache_hits; + vprint("XXX vncache 6", vp); *vpp =3D vp; /* * Some callers cache_enter(vp) later, so @@ -191,7 +192,9 @@ pvd->pvd_vnode =3D *vpp; VN_LOCK_AREC(*vpp); vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); + printf("XXX vncache 1 *vpp=3D%p\n", *vpp); error =3D insmntque(*vpp, mp); + printf("XXX vncache 2 *vpp=3D%p\n", *vpp); if (error !=3D 0) { *vpp =3D NULLVP; return (error); @@ -211,11 +214,14 @@ mtx_unlock(&pfs_vncache_mutex); if (vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, curthread) =3D=3D 0) { ++pfs_vncache_hits; + vprint("XXX vncache 3", *vpp); vgone(*vpp); + vprint("XXX vncache 4", *vpp); *vpp =3D vp; cache_purge(vp); return (0); } + vprint("XXX vncache 5", *vpp); goto retry2; } } Index: pseudofs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/FreeBSDCVS/src/sys/fs/pseudofs/pseudofs_vnops.c,v retrieving revision 1.72 diff -u -r1.72 pseudofs_vnops.c --- pseudofs_vnops.c 30 Dec 2008 21:49:39 -0000 1.72 +++ pseudofs_vnops.c 6 Jan 2009 23:12:40 -0000 @@ -369,6 +369,7 @@ VOP_UNLOCK(vp, 0); =20 error =3D pfs_vncache_alloc(mp, dvp, pn, pid); + vprint("XXX vptocnp", *dvp); if (error) { vn_lock(vp, locked | LK_RETRY); vfs_unbusy(mp); @@ -502,6 +503,7 @@ } =20 error =3D pfs_vncache_alloc(vn->v_mount, vpp, pn, pid); + vprint("XXX lookup", *vpp); if (error) goto failed; =20 and the msgs from the most recent coredump: Script started on Thu Jan 8 18:34:33 2009 You have mail. ichotolot# kgdb kernel.debug /var/crash/vmcore.206=20 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: XXX vncache 1 *vpp=3D0xffffff00b0173c30 XXX vncache 2 *vpp=3D0xffffff00b0173c30 XXX vncache 1 *vpp=3D0xffffff000d420270XXX vncache 1 *vp p=3D0xffXfXfX fvfn0cache 2 *vp0c6886750p=3D0xffffff000d420270 XXX vncache 2 *vpp=3D0xffffff00c6886750 XXX lookup 0xffffff00c6886750: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff804cf473 at pfs_lookup+0x273 #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805a83d3 at lookup+0x513 #10 0xffffffff805a928e at namei+0x53e #11 0xffffffff805b6ffa at kern_readlinkat+0x7a #12 0xffffffff805b7121 at kern_readlink+0x21 #13 0xffffffff807f16b7 at syscall+0x1e7 #14 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 3 0xffffff000d420270: tag pseudofs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_ROOT) lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff805a885f at lookup+0x99f #6 0xffffffff805a928e at namei+0x53e #7 0xffffffff805b6ffa at kern_readlinkat+0x7a #8 0xffffffff805b7121 at kern_readlink+0x21 #9 0xffffffff807f16b7 at syscall+0x1e7 #10 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 4 0xffffff000d420270: tag none, type VBAD usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_ROOT|VI_DOOMED) lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff805a885f at lookup+0x99f #6 0xffffffff805a928e at namei+0x53e #7 0xffffffff805b6ffa at kern_readlinkat+0x7a #8 0xffffffff805b7121 at kern_readlink+0x21 #9 0xffffffff807f16b7 at syscall+0x1e7 #10 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 6 0xffffff00c6886750: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff805b3fdb at vget+0x8b #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 #6 0xffffffff804cf473 at pfs_lookup+0x273 #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #10 0xffffffff805a83d3 at lookup+0x513 #11 0xffffffff805a928e at namei+0x53e #12 0xffffffff805b6ffa at kern_readlinkat+0x7a #13 0xffffffff805b7121 at kern_readlink+0x21 #14 0xffffffff807f16b7 at syscall+0x1e7 #15 0xffffffff807d41bb at Xfast_syscall+0xab XXX lookup 0xffffff00c6886750: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff805b3fdb at vget+0x8b #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 #6 0xffffffff804cf473 at pfs_lookup+0x273 #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #10 0xffffffff805a83d3 at lookup+0x513 #11 0xffffffff805a928e at namei+0x53e #12 0xffffffff805b6ffa at kern_readlinkat+0x7a #13 0xffffffff805b7121 at kern_readlink+0x21 #14 0xffffffff807f16b7 at syscall+0x1e7 #15 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 1 *vpp=3D0xffffff007af74270 XXX vncache 2 *vpp=3D0xffffff007af74270 XXX lookup 0xffffff007af74270: tag pseudofs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_PROCDEP) lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff804cf473 at pfs_lookup+0x273 #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805a83d3 at lookup+0x513 #10 0xffffffff805a928e at namei+0x53e #11 0xffffffff805b6ffa at kern_readlinkat+0x7a #12 0xffffffff805b7121 at kern_readlink+0x21 #13 0xffffffff807f16b7 at syscall+0x1e7 #14 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 1 *vpp=3D0xffffff00cd4719c0 XXX vncache 2 *vpp=3D0xffffff00cd4719c0 XXX lookup 0xffffff00cd4719c0: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_PROCDEP) lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff804cf473 at pfs_lookup+0x273 #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805a83d3 at lookup+0x513 #10 0xffffffff805a928e at namei+0x53e #11 0xffffffff805b6ffa at kern_readlinkat+0x7a #12 0xffffffff805b7121 at kern_readlink+0x21 #13 0xffffffff807f16b7 at syscall+0x1e7 #14 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 6 0xffffff00b0173c30: tag pseudofs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags (VV_ROOT) lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff805b3fdb at vget+0x8b #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 #6 0xffffffff805a885f at lookup+0x99f #7 0xffffffff805a928e at namei+0x53e #8 0xffffffff805b6ffa at kern_readlinkat+0x7a #9 0xffffffff805b7121 at kern_readlink+0x21 #10 0xffffffff807f16b7 at syscall+0x1e7 #11 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 6 0xffffff00c6886750: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff805b3fdb at vget+0x8b #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 #6 0xffffffff804cf473 at pfs_lookup+0x273 #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #10 0xffffffff805a83d3 at lookup+0x513 #11 0xffffffff805a928e at namei+0x53e #12 0xffffffff805b6ffa at kern_readlinkat+0x7a #13 0xffffffff805b7121 at kern_readlink+0x21 #14 0xffffffff807f16b7 at syscall+0x1e7 #15 0xffffffff807d41bb at Xfast_syscall+0xab XXX lookup 0xffffff00c6886750: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff805b3fdb at vget+0x8b #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 #6 0xffffffff804cf473 at pfs_lookup+0x273 #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #10 0xffffffff805a83d3 at lookup+0x513 #11 0xffffffff805a928e at namei+0x53e #12 0xffffffff805b6ffa at kern_readlinkat+0x7a #13 0xffffffff805b7121 at kern_readlink+0x21 #14 0xffffffff807f16b7 at syscall+0x1e7 #15 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 1 *vpp=3D0xffffff0053e7a750 XXX vncache 2 *vpp=3D0xffffff0053e7a750 XXX lookup 0xffffff0053e7a750: tag pseudofs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_PROCDEP) lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff804cf473 at pfs_lookup+0x273 #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805a83d3 at lookup+0x513 #10 0xffffffff805a928e at namei+0x53e #11 0xffffffff805b6ffa at kern_readlinkat+0x7a #12 0xffffffff805b7121 at kern_readlink+0x21 #13 0xffffffff807f16b7 at syscall+0x1e7 #14 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 1 *vpp=3D0xffffff00429cb4e0XXX vncache 1 *vpp=3D0xffffff007a92a= 750 XXX vncache 2 *vpp=3D0xffffff00429cb4e0 XXX vncache 2 *vpp=3D0xffffff007a92a750 XXX lookup XXX lookup 0xffffff00429cb4e0:=20 0xffffff007a92a750: tag pseudofs, type VLNKtag pseudofs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_PROCDEP) flags (VV_PROCDEP) =20 lock type ps eudofs: EXCL by thrleoacdk type0 pseudofs: EXCL by xftfh= frfefafd0 0829099x3f9f0 f(pid 18860)fff00c625bab0 (pid 18865) #0 0xffffffff80514c28 at __lockmgr_args+0x758#0=20 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b#2=20 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0x#f5f ffff0fxff8f0f4fcff473 at pfs_lookffufp8+004xc2f7473 at pfs_lookup= +30x273 #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf#6 0xffffffff8083543f at = VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0#7 0xffffffff805a2220 at vf s_cache_lookup+0xf0 #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7#8 0xffffffff808378 a7 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805a83d3 at lookup+0x513 #9 0xffffffff805a83d3 at lookup+0x513 #10 0xffffff#ff8105a928e at namei+00 x53e0xffffffff805a928e at namei+0x53e #11 0xffffffff805b6ffa at kern_readlinkat+0x7a#11 0xffffffff805b6ffa at ker= n_readlinkat+0x7a #12 0xffffffff805b7121 at kern_readlink+0x21#12 0xffffffff805b7121 at ker n_readlink+0x21 #13 0xffffffff807f16b7 at syscall+0x1e7 #13 0xffffffff807f16b7 at syscall+0x1e7 #14 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 1 *vpp=3D0xffffff007a357750#14 0xffffffff807d41bb at Xfast_sysc= all+0xab XXX vncache 2 *vpp=3D0xffffff007a357750 XXX looku p 0xffffff007a357750: tag pseudofs, type VLNKSystem call readlink returning usecount 1, writecount 0, refcount 1 mountedhere 0 with the following flags (VV_PROCDEP) locks held: exclusive lockmgr pseudofs lock type pseudofs: EXCL by thread 0xffffff00c625b a(b0 (ppid seu1d886= 5)ofs) r =3D 0 (0xffffff000d420308) locked @ /usr/src/sys/fs/pseudofs/pseudofs_vn= cache.c:194 panic: witness_warn cpuid =3D 0 KDB: enter: panic Physical memory: 4012 MB Dumping 2401 MB: 2386 2370 2354 2338 2322 2306 2290 2274 2258 2242 2226 221= 0 2194 2178 2162 2146 2130 2114 2098 2082 2066 2050 2034 2018 2002 1986 197= 0 1954 1938 1922 1906 1890 1874 1858 1842 1826 1810 1794 1778 1762 1746 173= 0 1714 1698 1682 1666 1650 1634 1618 1602 1586 1570 1554 1538 1522 1506 149= 0 1474 1458 1442 1426 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 125= 0 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 101= 0 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722 7= 06 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 418 = 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114= 98 82 66 50 34 18 2 Reading symbols from /boot/kernel/zfs.ko...done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_mirror.ko...done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/snd_hda.ko...done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/coretemp.ko...done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/atapicam.ko...done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/tmpfs.ko...done. Loaded symbols for /boot/kernel/tmpfs.ko Reading symbols from /boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /boot/modules/cpu.ko...done. Loaded symbols for /boot/modules/cpu.ko Reading symbols from /boot/kernel/green_saver.ko...done. Loaded symbols for /boot/kernel/green_saver.ko Reading symbols from /boot/kernel/radeon.ko...done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/nullfs.ko...done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/linprocfs.ko...done. Loaded symbols for /boot/kernel/linprocfs.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movq %%gs:0,%0" : "=3Dr" (td)); (kgdb) =08 =08p =08 =08=08 =08=08 =08=07bt #0 doadump () at pcpu.h:196 #1 0xffffffff801c752c in db_fncall (dummy1=3DVariable "dummy1" is not avai= lable. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801c7861 in db_command (last_cmdp=3D0xffffffff80b547a0, cmd_t= able=3DVariable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801c7ab0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801c9a59 in db_trap (type=3DVariable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff80558fd5 in kdb_trap (type=3D3, code=3D0, tf=3D0xffffffff2d73= e840) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff807f1e14 in trap (frame=3D0xffffffff2d73e840) at /usr/src/sys/amd64/amd64/trap.c:533 #7 0xffffffff807d3fae in calltrap () at /usr/src/sys/amd64/amd64/exception.S:217 #8 0xffffffff805591ad in kdb_enter (why=3D0xffffffff808d5179 "panic",=20 msg=3D0x1
) at cpufunc.h:63 #9 0xffffffff80529c5b in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:559 #10 0xffffffff8056c41e in witness_warn (flags=3DVariable "flags" is not ava= ilable. ) at /usr/src/sys/kern/subr_witness.c:1655 #11 0xffffffff807f175e in syscall (frame=3D0xffffffff2d73ec90) at /usr/src/sys/amd64/amd64/trap.c:965 #12 0xffffffff807d41bb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:338 #13 0x0000000018c1ec1c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 11 #11 0xffffffff807f175e in syscall (frame=3D0xffffffff2d73ec90) at /usr/src/sys/amd64/amd64/trap.c:965 965 WITNESS_WARN(WARN_PANIC, NULL, "System call %s returning", (kgdb) p td $1 =3D (struct thread *) 0xffffff0082999390 (kgdb) p td->td_proc $2 =3D (struct proc *) 0xffffff0082ae4880 (kgdb) p td->td_proc[0] $3 =3D {p_list =3D {le_next =3D 0xffffff00c82e6440, le_prev =3D 0xffffff007= ac31000},=20 p_threads =3D {tqh_first =3D 0xffffff0082999390, tqh_last =3D 0xffffff008= 29993a0},=20 p_slock =3D {lock_object =3D {lo_name =3D 0xffffffff808d3982 "process slo= ck",=20 lo_flags =3D 720896, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D= 4},=20 p_ucred =3D 0xffffff0010b4ec00, p_fd =3D 0xffffff00bdaac400, p_fdtol =3D = 0x0,=20 p_stats =3D 0xffffff0082a83c00, p_limit =3D 0xffffff000ef56c00, p_limco = =3D { c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0,=20 tqe_prev =3D 0x0}}, c_time =3D 0, c_arg =3D 0x0, c_func =3D 0,=20 c_lock =3D 0xffffff0082ae4978, c_flags =3D 0, c_cpu =3D 0},=20 p_sigacts =3D 0xffffff00290e1000, p_flag =3D 268451840, p_state =3D PRS_N= ORMAL,=20 p_pid =3D 18860, p_hash =3D {le_next =3D 0x0, le_prev =3D 0xfffffffe4023f= d60},=20 p_pglist =3D {le_next =3D 0x0, le_prev =3D 0xffffff007ac57948},=20 p_pptr =3D 0xffffff007ac57880, p_sibling =3D {le_next =3D 0x0,=20 le_prev =3D 0xffffff007ac57970}, p_children =3D {lh_first =3D 0x0}, p_m= tx =3D { lock_object =3D {lo_name =3D 0xffffffff808d3975 "process lock",=20 lo_flags =3D 21168128, lo_data =3D 0, lo_witness =3D 0xfffffffe4021a4= 00},=20 mtx_lock =3D 4}, p_ksi =3D 0xffffff000515e000, p_sigqueue =3D {sq_signa= ls =3D { __bits =3D {0, 0, 0, 0}}, sq_kill =3D {__bits =3D {0, 0, 0, 0}}, sq_l= ist =3D { tqh_first =3D 0x0, tqh_last =3D 0xffffff0082ae49c0},=20 sq_proc =3D 0xffffff0082ae4880, sq_flags =3D 1}, p_oppid =3D 0,=20 p_vmspace =3D 0xffffff0082315d38, p_swtick =3D 10457673, p_realtimer =3D { it_interval =3D {tv_sec =3D 0, tv_usec =3D 0}, it_value =3D {tv_sec =3D= 0,=20 tv_usec =3D 0}}, p_ru =3D {ru_utime =3D {tv_sec =3D 0, tv_usec =3D 0}= , ru_stime =3D { tv_sec =3D 0, tv_usec =3D 0}, ru_maxrss =3D 0, ru_ixrss =3D 0, ru_idr= ss =3D 0,=20 ru_isrss =3D 0, ru_minflt =3D 0, ru_majflt =3D 0, ru_nswap =3D 0, ru_in= block =3D 0,=20 ru_oublock =3D 0, ru_msgsnd =3D 0, ru_msgrcv =3D 0, ru_nsignals =3D 0,= =20 ru_nvcsw =3D 0, ru_nivcsw =3D 0}, p_rux =3D {rux_runtime =3D 0, rux_uti= cks =3D 0,=20 rux_sticks =3D 0, rux_iticks =3D 0, rux_uu =3D 0, rux_su =3D 0, rux_tu = =3D 0},=20 p_crux =3D {rux_runtime =3D 0, rux_uticks =3D 0, rux_sticks =3D 0, rux_it= icks =3D 0,=20 rux_uu =3D 0, rux_su =3D 0, rux_tu =3D 0}, p_profthreads =3D 0, p_exitt= hreads =3D 0,=20 p_traceflag =3D 0, p_tracevp =3D 0x0, p_tracecred =3D 0x0,=20 p_textvp =3D 0xffffff001b02a750, p_lock =3D 0 '\0', p_sigiolst =3D { slh_first =3D 0x0}, p_sigparent =3D 20, p_sig =3D 0, p_code =3D 0, p_st= ops =3D 0,=20 p_stype =3D 0, p_step =3D 0 '\0', p_pfsflags =3D 0 '\0', p_nlminfo =3D 0x= 0,=20 p_aioinfo =3D 0x0, p_singlethread =3D 0x0, p_suspcount =3D 0, p_xthread = =3D 0x0,=20 p_boundary_count =3D 0, p_pendingcnt =3D 0, p_itimers =3D 0x0,=20 p_magic =3D 3203398350, p_osrel =3D 800054,=20 p_comm =3D "perl\000l", '\0' , p_pgrp =3D 0xffffff000b0= 6ec00,=20 p_sysent =3D 0xffffffff80b30320, p_args =3D 0xffffff00bdceda80,=20 p_cpulimit =3D 9223372036854775807, p_nice =3D 0 '\0', p_fibnum =3D 0,=20 p_xstat =3D 0, p_klist =3D {kl_list =3D {slh_first =3D 0x0},=20 kl_lock =3D 0xffffffff805008a0 ,=20 kl_unlock =3D 0xffffffff805008c0 ,=20 kl_locked =3D 0xffffffff80501ba0 ,=20 kl_lockarg =3D 0xffffff0082ae4978}, p_numthreads =3D 1,=20 p_md =3D , p_itcallout =3D {c_links =3D {sle =3D {sle_ne= xt =3D 0x0},=20 tqe =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}}, c_time =3D 0, c_arg = =3D 0x0,=20 c_func =3D 0, c_lock =3D 0x0, c_flags =3D 16, c_cpu =3D 0}, p_acflag = =3D 0,=20 p_peers =3D 0x0, p_leader =3D 0xffffff0082ae4880, p_emuldata =3D 0x0,=20 p_label =3D 0x0, p_sched =3D 0xffffff0082ae4cc0, p_ktr =3D {stqh_first = =3D 0x0,=20 stqh_last =3D 0xffffff0082ae4c90}, p_mqnotifier =3D {lh_first =3D 0x0},= =20 p_dtrace =3D 0x0, p_pwait =3D {cv_description =3D 0xffffffff808d42c2 "ppw= ait",=20 cv_waiters =3D 0}} (kgdb) =08 =08=07p *td $4 =3D {td_lock =3D 0xffffffff80b91680, td_proc =3D 0xffffff0082ae4880, td_= plist =3D { tqe_next =3D 0x0, tqe_prev =3D 0xffffff0082ae4890}, td_runq =3D { tqe_next =3D 0xffffff000549d720, tqe_prev =3D 0xffffffff80b918c8}, td_s= lpq =3D { tqe_next =3D 0x0, tqe_prev =3D 0xffffff000721e190}, td_lockq =3D { tqe_next =3D 0x0, tqe_prev =3D 0xffffffff2cb3f750},=20 td_cpuset =3D 0xffffff000288cdc8, td_sel =3D 0xffffff0082f7bb00,=20 td_sleepqueue =3D 0xffffff000721e190, td_turnstile =3D 0xffffff0005469900= ,=20 td_umtxq =3D 0xffffff008284b500, td_tid =3D 100316, td_sigqueue =3D {sq_s= ignals =3D { __bits =3D {0, 0, 0, 0}}, sq_kill =3D {__bits =3D {0, 0, 0, 0}}, sq_l= ist =3D { tqh_first =3D 0x0, tqh_last =3D 0xffffff0082999430},=20 sq_proc =3D 0xffffff0082ae4880, sq_flags =3D 1}, td_flags =3D 4,=20 td_inhibitors =3D 0, td_pflags =3D 0, td_dupfd =3D 0, td_sqqueue =3D 0,= =20 td_wchan =3D 0x0, td_wmesg =3D 0x0, td_lastcpu =3D 0 '\0', td_oncpu =3D 0= '\0',=20 td_owepreempt =3D 0 '\0', td_tsqueue =3D 0 '\0', td_locks =3D 1, td_rw_rl= ocks =3D 0,=20 td_lk_slocks =3D 0, td_blocked =3D 0x0, td_lockname =3D 0x0, td_contested= =3D { lh_first =3D 0x0}, td_sleeplocks =3D 0xffffffff80cebd40,=20 td_intr_nesting_level =3D 0, td_pinned =3D 1, td_ucred =3D 0xffffff0010b4= ec00,=20 td_estcpu =3D 0, td_slptick =3D 0, td_ru =3D {ru_utime =3D {tv_sec =3D 0,= =20 tv_usec =3D 0}, ru_stime =3D {tv_sec =3D 0, tv_usec =3D 0}, ru_maxrss= =3D 2044,=20 ru_ixrss =3D 48, ru_idrss =3D 3352, ru_isrss =3D 512, ru_minflt =3D 186= ,=20 ru_majflt =3D 0, ru_nswap =3D 0, ru_inblock =3D 0, ru_oublock =3D 0,=20 ru_msgsnd =3D 0, ru_msgrcv =3D 0, ru_nsignals =3D 0, ru_nvcsw =3D 13,= =20 ru_nivcsw =3D 13}, td_incruntime =3D 61985988, td_runtime =3D 61985988,= =20 td_pticks =3D 3, td_sticks =3D 4, td_iticks =3D 0, td_uticks =3D 0, td_uu= ticks =3D 0,=20 td_usticks =3D 0, td_intrval =3D 0, td_oldsigmask =3D {__bits =3D {0, 0, = 0, 0}},=20 td_sigmask =3D {__bits =3D {0, 0, 0, 0}}, td_generation =3D 26, td_sigstk= =3D { ss_sp =3D 0x0, ss_size =3D 0, ss_flags =3D 4}, td_xsig =3D 0, td_profil= _addr =3D 0,=20 td_profil_ticks =3D 0, td_name =3D "perl\000l", '\0' ,= =20 td_fpop =3D 0x0, td_dbgflags =3D 0, td_osd =3D {osd_nslots =3D 0, osd_slo= ts =3D 0x0,=20 osd_next =3D {le_next =3D 0x0, le_prev =3D 0x0}}, td_rqindex =3D 32 ' '= ,=20 td_base_pri =3D 128 '\200', td_priority =3D 128 '\200', td_pri_class =3D = 3 '\003',=20 td_user_pri =3D 129 '\201', td_base_user_pri =3D 129 '\201',=20 td_pcb =3D 0xffffffff2d73ed50, td_state =3D TDS_RUNNING, td_retval =3D {2= 3, 1023},=20 td_slpcallout =3D {c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_= next =3D 0x0,=20 tqe_prev =3D 0xffffffff0031d340}}, c_time =3D 9773098,=20 c_arg =3D 0xffffff0082999390, c_func =3D 0xffffffff80561850 ,=20 c_lock =3D 0x0, c_flags =3D 16, c_cpu =3D 0}, td_frame =3D 0xffffffff2d= 73ec90,=20 td_kstack_obj =3D 0xffffff00c83a7c80, td_kstack =3D 18446744070177140736,= =20 td_kstack_pages =3D 4, td_altkstack_obj =3D 0x0, td_altkstack =3D 0,=20 td_altkstack_pages =3D 0, td_critnest =3D 1, td_md =3D {md_spinlock_count= =3D 0,=20 md_saved_flags =3D 70}, td_sched =3D 0xffffff00829996f0, td_ar =3D 0x0,= =20 td_syscalls =3D 1517973, td_lprof =3D {{lh_first =3D 0x0}, {lh_first =3D = 0x0}},=20 td_dtrace =3D 0x0, td_errno =3D 0} (kgdb) p td=08 =08=08 =08*td->td_lock $5 =3D {lock_object =3D {lo_name =3D 0xffffffff80b922d8 "sched lock 0",=20 lo_flags =3D 720896, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 4} (kgdb) q ichotolot#=20 From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 01:50:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27223106564A; Fri, 9 Jan 2009 01:50:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id F1D988FC12; Fri, 9 Jan 2009 01:50:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 331522048AF; Thu, 8 Jan 2009 20:34:38 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 08 Jan 2009 20:34:38 -0500 X-Sasl-enc: o/yGKYGshJh/PZWdnq4Zbx1FHTAURaYfEeV5AidjUZNR 1231464877 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 8F7D129284; Thu, 8 Jan 2009 20:34:37 -0500 (EST) Message-ID: <4966A9AB.2040802@FreeBSD.org> Date: Fri, 09 Jan 2009 01:34:35 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 To: Tim Kientzle References: <4965927D.1060507@freebsd.org> In-Reply-To: <4965927D.1060507@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'freebsd-current@freebsd.org'" Subject: bsdtar fan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 01:50:56 -0000 Off topic: Tim, thank you for bsdtar. I recently had to muck around with ISO images on a debian box, and mounting them all would have been prohibitive. Thanks to bsdtar, I could just extract the files I needed, without using loopback mounts. That was invaluable. thank you! From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 03:12:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2539106564A for ; Fri, 9 Jan 2009 03:12:05 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwmtas01p.mx.bigpond.com (nschwmtas01p.mx.bigpond.com [61.9.189.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2FFF58FC0C for ; Fri, 9 Jan 2009 03:12:04 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx02p.mx.bigpond.com ([124.188.162.219]) by nschwmtas01p.mx.bigpond.com with ESMTP id <20090109031203.TAZT412.nschwmtas01p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com> for ; Fri, 9 Jan 2009 03:12:03 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20090109031158.BDEI14268.nschwotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Fri, 9 Jan 2009 03:11:58 +0000 Received: (qmail 55700 invoked by uid 501); 9 Jan 2009 03:11:47 -0000 Date: Fri, 9 Jan 2009 14:11:47 +1100 From: Andrew Reilly To: Ollivier Robert Message-ID: <20090109031147.GB44317@duncan.reilly.home> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090108233311.GA69883@keltia.freenix.fr> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.4966C07F.000A:SCFSTAT2704298,ss=1,fgs=0 Cc: freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 03:12:05 -0000 On Fri, Jan 09, 2009 at 12:33:11AM +0100, Ollivier Robert wrote: > According to O. Hartmann: > > When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > > compiler suite? We figured out that gcc 4.3 does have a speed gain in > > some numerical code of 3 - 8 % and I guess we can use this in the basic > > OS as well ... > > I'd rather have llvm instead... I wouldn't mind that, either. I've got the llvm port installed myself, in preparation for doing some experiments of my own, but haven't tried using it to build the kernel or user-land (or even any of the ports). Has anyone given it a go? Is it missing any crucial features? I believe that it had different (or no?) support for PIC code generation, which could affect the ability to do shared libraries, but recent release notes seem to indicate that that's been addressed. There's also someone working on a BSD-licenced retooling (ANSI/ISO-ification) of the PCC compiler, which is getting close to being useful as a system compiler, I believe. (http://www.ludd.ltu.se/~ragge/pcc/ in ports/lang/pcc) In any case, performance gains on numerical code have almost zero bearing on performance of "operating system" code -- no floating point in kernel for starters, and hardly any time spent in loops, either... Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 05:44:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 766A8106566B for ; Fri, 9 Jan 2009 05:44:04 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 4541E8FC0A for ; Fri, 9 Jan 2009 05:44:04 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so10651552rvf.43 for ; Thu, 08 Jan 2009 21:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=rEN7atpdLPElJjyGAZsSWPibFfseqp5QhYJhLPO3vpI=; b=F1f000Y78nUcf0yCOow+y5SWF6J6YKK/uuQrRZ7ipYJy4vdpkpAla886iZJHbjfiP5 HY5S+iyUnzOZ4dp4LNgSikYiVdZf8IviJcMw+w/yGXHAuyMrm/2LXaxO86X+UMZciURc TbbIxzwIflM18lnZncmlcOsZUIxpYP4cFrmyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ojm+YQ+GfIbmU90kIdE4+/ODDrUpJwG01R3FU1+a5U7KPSPaWwGyEhPNgz+cFjpXpX HEMmvKuq4Jg/aZN+xlVrRQoHTN9TW2ZXXNxeLchaZSf/mWNY6BRVlseYWQaHfT79U7q+ 7e5eliSAm50uH58riE9fRBNOyDwee+8/5LwGs= Received: by 10.141.211.5 with SMTP id n5mr12564850rvq.19.1231479843972; Thu, 08 Jan 2009 21:44:03 -0800 (PST) Received: by 10.140.135.2 with HTTP; Thu, 8 Jan 2009 21:44:03 -0800 (PST) Message-ID: <7d6fde3d0901082144q4ecc989do7a57948a96b8bd74@mail.gmail.com> Date: Thu, 8 Jan 2009 21:44:03 -0800 From: "Garrett Cooper" To: "FreeBSD Current" In-Reply-To: <7d6fde3d0901082143xb1fb1acj6a0579a844a10bc3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> <4966859E.7080301@mail.zedat.fu-berlin.de> <20090109025218.GA44317@duncan.reilly.home> <7d6fde3d0901082143xb1fb1acj6a0579a844a10bc3@mail.gmail.com> Subject: Fwd: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 05:44:04 -0000 On Thu, Jan 8, 2009 at 6:52 PM, Andrew Reilly wrote: > On Fri, Jan 09, 2009 at 12:00:46AM +0100, O. Hartmann wrote: >> Garrett Cooper wrote: >> > On Jan 8, 2009, at 12:36 AM, Roman Divacky wrote: >> > >> >> On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: >> >>> One of the things I'm noting is that when I use dual displays with >> >>> the nvidia driver, and xscreensaver kicks in and keeps going for a >> >>> period of time, the machine's X.org console eats up a core, and when I >> >>> try and do anything like gdb Xorg, the system hangs, attempts to panic >> >>> (I assume that's the case because I hear it beep and attempt to >> >>> restart), then I have to give it a warm boot. truss(1)'ing Xorg showed >> >>> that there were a lot of SIGALARM's being fired and masked. > > Straight up: I can't help with this particular OP's quesiton, > just have a comment, further down. > >> I have and I had the same in FreeBSD 7.0/7.1 and now with 8.0-CUR with >> both a NV8600GTS and an older NV6800GT. A very old NV6600 never showed >> up these lockings when I used that PCIe-Card with FreeBSD 7.0/7.1, but >> I'm not sure. The locks came spontanous, sometimes after heavy usage of >> 'mplayer', but sometimes instantanously after the destop showed up. >> >> On those boxes, there is no Linux emulation and no Linux BLOB (useless, >> due to 64 Bit). I swapped the 'nv' driver on all FreeBSD boxes with >> 'vesa', because there is another issue with sprites/graphics buffers >> many times reported using FireFox. > > I have had terrible trouble with an NV6800 card on my AMD64 > machine and a 1600x1200 LCD display. I mostly had to use the > vesa driver, becauase sometimes the nv driver would just fail > to initialize the card properly, and it would be just black, > or wrong frequencies/jumbled: it was a mess. Vesa worked, > but generally didn't let me go beyond 1280x1024. When nv was > (occasionally) working I had the firefox bug surface. > > I've commented about this on the lists (and on usenet) before, > so I thought that I'd better also mention, for the record, that > I have completely solved the problem by replacing that card with > an inexpensive ATI card that the radionhd driver recognizes as > "RV635" based. Should have done it long ago... Everything > appears to work perfectly, now. > > Cheers, > > Andrew Ok, well given the feedback (what I was kind of fishing for), I'll gladly start talking to some nVidia folks about reproducing these issues and bugfixing their driver. Another datapoint: when it doesn't lock up, Xorg dies mysteriously after some hours use. I'm running XFCE4, but I'm wondering a) what desktops folks are running that have had issues, and b) what the configurations are. That way we can better tie down the problem at hand. Replacing my 8800GTS with a lower grade nVidia card isn't going to cut it -- I don't like workarounds that cost most money and create more spare hardware that I don't use :). Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 06:10:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB75F106564A for ; Fri, 9 Jan 2009 06:10:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id A144C8FC0A for ; Fri, 9 Jan 2009 06:10:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so10660752rvf.43 for ; Thu, 08 Jan 2009 22:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=89HzZBiaiIHFMCApcXs8h5mUonhZe429DmwlHAeiVAA=; b=gIFTIblRZ1TLot0V50uDml9ZXclDRVw8QFvV21DIhaa1ZIH+mSznl82U6YYxQPFAvh dqeBWK6YPl/4jYefbS5fYc+zn9vyLSYqRCil3JwvlvmyWx8GIhm+rvj4S7N5Lan6tkgk BIKBQsGr+lVTI4C+NrxHTGCCh7NYJ7pTF8xKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Na2SCVg2FS6wG2MLejEX8nNnbIf800awtQWzxsWQ5e5EYzX7DJv8gUOAcZpC8d4AwT QaEikjx6tp5lF14Me1og1rqrBwAmV8MgLlB1uADIluRrzy4r6AOLPwdadhsH6aAgc7kj VqXqwHshh89SUkbI3MhFvnsTd18mjBYrZIrS8= Received: by 10.141.100.15 with SMTP id c15mr12568529rvm.52.1231481442359; Thu, 08 Jan 2009 22:10:42 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id f21sm67562374rvb.7.2009.01.08.22.10.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Jan 2009 22:10:41 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.14.3/8.14.3) with ESMTP id n096AXVr034515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 15:10:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.14.3/8.14.3/Submit) id n096AX7l034514; Fri, 9 Jan 2009 15:10:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 9 Jan 2009 15:10:32 +0900 From: Pyun YongHyeon To: Kim Culhan Message-ID: <20090109061032.GF30747@cdnetworks.co.kr> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: msk Marvell Yukon 88E8038 hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 06:10:43 -0000 On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote: > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > > On Thu, Jan 08, 2009 at 02:36:48AM -0500, Kim Culhan wrote: > > > On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > > > > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > > > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > > > > > > > Not necessarily at each hang but sometimes coincident, this is > > > > > intermittently output to the console: > > > > > > > > > > in_cksum_skip: out of data by 56952 > > > > > > > > > > The above is also output to the console at times when receiving a > > > > > character through ssh > > > > > to a shell. > > > > > > > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > > > > running 7.1-RELEASE. > > > > > > > > > > > > > Would you show me dmesg output for msk(4)? > > > > > > dmesg: > > > > > > mskc0: port 0x2000-0x20ff mem > > > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 > > > msk0: on mskc0 > > > msk0: Ethernet address: 00:1b:24:59:5b:7a > > > miibus0: on msk0 > > > e1000phy0: PHY 0 on miibus0 > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > mskc0: [FILTER] > > > > > > > Would you try changes made in r183485(CVS if_msk.c, 1.33)? > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/msk/if_msk.c.diff?r1=1.32;r2=1.33;f=h > > The version in use is 1.35 dated 11-24-08 from 8.0-current cvsup'd on 1-7-09 > > This has the changes you have made in the diff from the link above. > Ok, then how about disabling TSO/Tx checksum offload? (eg. ifconfig msk0 -tso -txcsum) -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 06:53:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB68A10656EC for ; Fri, 9 Jan 2009 06:53:54 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntqsrv02p.mx.bigpond.com (nskntqsrv02p.mx.bigpond.com [61.9.168.234]) by mx1.freebsd.org (Postfix) with ESMTP id 342F48FC18 for ; Fri, 9 Jan 2009 06:53:53 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntotgx01p.mx.bigpond.com ([124.188.162.219]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20090109025251.CZFH24984.nskntmtas02p.mx.bigpond.com@nskntotgx01p.mx.bigpond.com> for ; Fri, 9 Jan 2009 02:52:51 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nskntotgx01p.mx.bigpond.com with ESMTP id <20090109025247.YJJN17478.nskntotgx01p.mx.bigpond.com@areilly.bpa.nu> for ; Fri, 9 Jan 2009 02:52:47 +0000 Received: (qmail 54697 invoked by uid 501); 9 Jan 2009 02:52:18 -0000 Date: Fri, 9 Jan 2009 13:52:18 +1100 From: Andrew Reilly To: "O. Hartmann" Message-ID: <20090109025218.GA44317@duncan.reilly.home> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> <4966859E.7080301@mail.zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4966859E.7080301@mail.zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.4966BBFF.007F:SCFSTAT2704298,ss=1,fgs=0 Cc: Garrett Cooper , Roman Divacky , FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 06:53:54 -0000 On Fri, Jan 09, 2009 at 12:00:46AM +0100, O. Hartmann wrote: > Garrett Cooper wrote: > > On Jan 8, 2009, at 12:36 AM, Roman Divacky wrote: > > > >> On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: > >>> One of the things I'm noting is that when I use dual displays with > >>> the nvidia driver, and xscreensaver kicks in and keeps going for a > >>> period of time, the machine's X.org console eats up a core, and when I > >>> try and do anything like gdb Xorg, the system hangs, attempts to panic > >>> (I assume that's the case because I hear it beep and attempt to > >>> restart), then I have to give it a warm boot. truss(1)'ing Xorg showed > >>> that there were a lot of SIGALARM's being fired and masked. Straight up: I can't help with this particular OP's quesiton, just have a comment, further down. > I have and I had the same in FreeBSD 7.0/7.1 and now with 8.0-CUR with > both a NV8600GTS and an older NV6800GT. A very old NV6600 never showed > up these lockings when I used that PCIe-Card with FreeBSD 7.0/7.1, but > I'm not sure. The locks came spontanous, sometimes after heavy usage of > 'mplayer', but sometimes instantanously after the destop showed up. > > On those boxes, there is no Linux emulation and no Linux BLOB (useless, > due to 64 Bit). I swapped the 'nv' driver on all FreeBSD boxes with > 'vesa', because there is another issue with sprites/graphics buffers > many times reported using FireFox. I have had terrible trouble with an NV6800 card on my AMD64 machine and a 1600x1200 LCD display. I mostly had to use the vesa driver, becauase sometimes the nv driver would just fail to initialize the card properly, and it would be just black, or wrong frequencies/jumbled: it was a mess. Vesa worked, but generally didn't let me go beyond 1280x1024. When nv was (occasionally) working I had the firefox bug surface. I've commented about this on the lists (and on usenet) before, so I thought that I'd better also mention, for the record, that I have completely solved the problem by replacing that card with an inexpensive ATI card that the radionhd driver recognizes as "RV635" based. Should have done it long ago... Everything appears to work perfectly, now. Cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 07:01:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 231191065744 for ; Fri, 9 Jan 2009 07:01:15 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id A534D8FC13 for ; Fri, 9 Jan 2009 07:01:14 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by ewy14 with SMTP id 14so11189226ewy.19 for ; Thu, 08 Jan 2009 23:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=ZRwpUC2QTeDXbmvR7HEF6WJnnKxyWV/tRtexCupwj48=; b=hvPgyi452vxmZOyAIWYSph9nCZcUVPhdvKRKqFila4s+ibsZR40QtgGhZueH6FEOnT h+KvLYlfr7TyeJTJ9KojfRgCN+jrwOIxE7CTZdfJIwTWhYGoSjFB1SLp7PhWCJqFnkMf 1K67FWKbQMQXvY2eLkHrQsLBfhp3QRgqR33UI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=U4NQS8y3GeS2S1dqdgzRST1LiDwCSmXIcDtEeTH7tl5dpaNjEYXIvKqp/EX378YmrJ ESxmJVoPBEMzYm8Xx7C5mGFBUSZzN9+ahLR+pIJem6tbXHJi5QtBdPvZ0jOXW0twiMHM NxLkH0jdVETRBCYuGPB5G8mXVV5eNhrh0B4sA= Received: by 10.210.119.16 with SMTP id r16mr8063793ebc.193.1231482651199; Thu, 08 Jan 2009 22:30:51 -0800 (PST) Received: by 10.210.58.4 with HTTP; Thu, 8 Jan 2009 22:30:51 -0800 (PST) Message-ID: <3cb459ed0901082230y31c5fe2cw98abd9dbdc0e0b83@mail.gmail.com> Date: Fri, 9 Jan 2009 09:30:51 +0300 From: "Alexander Churanov" To: "joe mcguckin" In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Best torrent client/server available for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 07:01:16 -0000 Hi! I am happy with www/aria2 as ftp- http- and torrent- downloader. Alexander From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 07:36:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F6AC106564A; Fri, 9 Jan 2009 07:36:08 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id 53A9B8FC0A; Fri, 9 Jan 2009 07:36:08 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so10688410rvf.43 for ; Thu, 08 Jan 2009 23:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=jH3NOq1AgdMTvtXYTtwE4qX8LF7ROPKZqsawlgtLIPw=; b=Co0Ly5dmBbCpOyqrL5C6bmcjtKSy5z+jR5UzeSPkvrM6CNW2wbJ2ID2nIU6SSXpZN9 VcPZH8nampTZYPYvB2vx63XKOgsn2yx3787Wm5nmGLMGDxYajuJyVZKV2JIfmjtpk08B cdgao2UHRHx9LPa+JjA4x8idOgZoD3WieFsUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=xPZCGBy3UBi1/uEb9/MY1SMzYA3RoNUU7RLHJL8C+HcDgQB/M987d5QSUidnhR46UE 0w4LvOuO9x5vs+UO01xaPirR6b+Tpua6zc+amq+LsJSjUcp9NIxDCoj4wZxVAZ+iMaCw CKQLEned5Rfut9O7gLTlDbfnZvu6jO68tS81U= Received: by 10.141.161.6 with SMTP id n6mr12593038rvo.57.1231486567750; Thu, 08 Jan 2009 23:36:07 -0800 (PST) Received: by 10.140.135.2 with HTTP; Thu, 8 Jan 2009 23:36:07 -0800 (PST) Message-ID: <7d6fde3d0901082336o6291c3a8r5cbb91a89db13ef7@mail.gmail.com> Date: Thu, 8 Jan 2009 23:36:07 -0800 From: "Garrett Cooper" To: "Alexander Motin" In-Reply-To: <49664FD8.1060700@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> <49647602.9060402@FreeBSD.org> <49649333.6060902@gmail.com> <7d6fde3d0901080937t29ec42f5i6684b9223d0b368a@mail.gmail.com> <49664FD8.1060700@FreeBSD.org> Cc: FreeBSD Current Subject: Re: snd_hda(4): getting line-in to work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 07:36:09 -0000 On Thu, Jan 8, 2009 at 11:11 AM, Alexander Motin wrote: > Garrett Cooper wrote: >> >> Ok, I got stuck again. Can you possibly push me in the right >> direction (complete verbose dmesg attached)? The line-in and SPDIF >> (not so much of a concern) are the only issues that I'm aware of. I'll >> have to open up my case and wire up the front ports in order to test >> them for you. > > Ok. Let's stop for a moment and start from the beginning, because now it is > already like a puzzle for me too. Let me explain once more what I see you > have and then you explain me where is your problem. > > You have 3 PCM devices configured: > - pcm0: 7.1 playback via 4 rear jacks (Green, Black, Orange and Grey) + > record from mic (front Pink), line (rear Blue), monitor (second mic, rear > Pink), cd (internal Black) or mix (sum of all these). > - pcm1: stereo playback via front Green jack. > - pcm2: SPDIF output > > As for me, this configuration is correct and good enough. You can record > from your line-in via pcm0 after selecting that source via `mixer =rec line` > command. You can playback via SPDIF by using pcm2 device. > > So what's wrong? What are you doing and what is not working and how? Ok, just checking my sanity, I started swapping around the plugs in the back, checking my connections, etc. I tried my mic, worked (the gain was a bit small, sound was _really_ distorted), then switched back to my line-in and sure enough, it now works :D. What changed since yesterday: - I hadn't set mixer_enable="YES" in rc.conf. This brought up a LOT more channels and options than I had originally. - Rebooted the machine with fixed device.hints (unchanged from the default :P). - I changed the volume for mix from 0:0 to 30:30. My summary (experience) thus far: So far the driver functions as expected, but the frequency response seems a bit off for the output -- it's really focused around the vocal range (the lower 3 frequencies on the audacity, iTunes, xmms equalizer -- forget the frequencies). It's not so bad with PCM sound, but It's really off with Line-in / Mic. Any hints or hacking I can do to adjust the voltage levels sent to the ADC's in the hardware? >> Also, the knobs that show up in xfce4-mixer are completely useless >> for snd_hda(4) (every time I move the sliders it sets the volume back >> to 0). Is this a known issue? > > You are the first. oss was complaining about a `unable to open mixer recording device: bad file descriptor' whenever I try and set the mixer levels by opening it up directly from the GUI. Interestingly enough when I opened up the mixer from an xterm, it worked 0-o.. However, I just toasted ~/.config/xfce4/mixer/* and now it works, so apparently it was bad cached preferences. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 08:29:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB6BB106564A for ; Fri, 9 Jan 2009 08:29:40 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0608FC1B for ; Fri, 9 Jan 2009 08:29:39 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 231240661; Fri, 09 Jan 2009 10:29:39 +0200 Message-ID: <49670AF2.7040901@FreeBSD.org> Date: Fri, 09 Jan 2009 10:29:38 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> <49647602.9060402@FreeBSD.org> <49649333.6060902@gmail.com> <7d6fde3d0901080937t29ec42f5i6684b9223d0b368a@mail.gmail.com> <49664FD8.1060700@FreeBSD.org> <7d6fde3d0901082336o6291c3a8r5cbb91a89db13ef7@mail.gmail.com> In-Reply-To: <7d6fde3d0901082336o6291c3a8r5cbb91a89db13ef7@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: snd_hda(4): getting line-in to work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 08:29:41 -0000 Garrett Cooper wrote: > On Thu, Jan 8, 2009 at 11:11 AM, Alexander Motin wrote: >> Garrett Cooper wrote: >>> Ok, I got stuck again. Can you possibly push me in the right >>> direction (complete verbose dmesg attached)? The line-in and SPDIF >>> (not so much of a concern) are the only issues that I'm aware of. I'll >>> have to open up my case and wire up the front ports in order to test >>> them for you. >> Ok. Let's stop for a moment and start from the beginning, because now it is >> already like a puzzle for me too. Let me explain once more what I see you >> have and then you explain me where is your problem. >> >> You have 3 PCM devices configured: >> - pcm0: 7.1 playback via 4 rear jacks (Green, Black, Orange and Grey) + >> record from mic (front Pink), line (rear Blue), monitor (second mic, rear >> Pink), cd (internal Black) or mix (sum of all these). >> - pcm1: stereo playback via front Green jack. >> - pcm2: SPDIF output >> >> As for me, this configuration is correct and good enough. You can record >> from your line-in via pcm0 after selecting that source via `mixer =rec line` >> command. You can playback via SPDIF by using pcm2 device. >> >> So what's wrong? What are you doing and what is not working and how? > > Ok, just checking my sanity, I started swapping around the plugs in > the back, checking my connections, etc. I tried my mic, worked (the > gain was a bit small, sound was _really_ distorted), then switched It is possible to control external mic phantom power via loader.conf. I have never tried it myself, but it may be related. > back to my line-in and sure enough, it now works :D. > > What changed since yesterday: > - I hadn't set mixer_enable="YES" in rc.conf. This brought up a LOT > more channels and options than I had originally. Don't very understand what you mean by channels. mixer_enable just loads mixer settings saved on shutdown. > - Rebooted the machine with fixed device.hints (unchanged from the default :P). > - I changed the volume for mix from 0:0 to 30:30. mix now controls volume of mixed inputs recording (if you select this record source. I would prefer direct line recording) and input monitoring. Sure it is not very good, I am thinking to somehow separate them. > My summary (experience) thus far: > > So far the driver functions as expected, but the frequency response > seems a bit off for the output -- it's really focused around the vocal > range (the lower 3 frequencies on the audacity, iTunes, xmms equalizer > -- forget the frequencies). > > It's not so bad with PCM sound, but It's really off with Line-in / > Mic. Any hints or hacking I can do to adjust the voltage levels sent > to the ADC's in the hardware? There is no standardized ADC controls in HDA specification. Some codecs allows loading some unstandardized "processing coefficients" for some widgets, but I don't see respective "PROC" capability in your verbose output. All you can is to control amplifiers gains and Vref for mics. If you have distorted sound on line-in, I would recommend you to check gains of all amplifiers inside codec where signal passes. Most inputs of your codec (including line) have +30dB mic pre-amplifiers. It is good for mics, but not needed for line-in. Set mixer "line" level to the lowest nonzero value to disable pre-amplification (without muting it) and avoid signal clipping there. Control recording level by other controls. If you are recording from mix, but not from the line, take note that mix control also have +12dB upper amplifier control range, so setting it to maximum values can also produce clipping. All this information obtained from your dmesg. >>> Also, the knobs that show up in xfce4-mixer are completely useless >>> for snd_hda(4) (every time I move the sliders it sets the volume back >>> to 0). Is this a known issue? >> You are the first. > > oss was complaining about a `unable to open mixer recording device: > bad file descriptor' whenever I try and set the mixer levels by > opening it up directly from the GUI. Interestingly enough when I > opened up the mixer from an xterm, it worked 0-o.. However, I just > toasted ~/.config/xfce4/mixer/* and now it works, so apparently it was > bad cached preferences. Fine. I am just using standard console `mixer` tool. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 08:30:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8FDB106566C for ; Fri, 9 Jan 2009 08:30:23 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 917038FC22 for ; Fri, 9 Jan 2009 08:30:22 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 1DBC79CB1A1; Fri, 9 Jan 2009 09:30:12 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJcwl31DS9iK; Fri, 9 Jan 2009 09:30:09 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D20F39CB22D; Fri, 9 Jan 2009 09:30:09 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n098U9gN056042; Fri, 9 Jan 2009 09:30:09 +0100 (CET) (envelope-from rdivacky) Date: Fri, 9 Jan 2009 09:30:09 +0100 From: Roman Divacky To: "O. Hartmann" Message-ID: <20090109083009.GA55615@freebsd.org> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> <4966859E.7080301@mail.zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4966859E.7080301@mail.zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: Garrett Cooper , FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 08:30:24 -0000 > I have and I had the same in FreeBSD 7.0/7.1 and now with 8.0-CUR with > both a NV8600GTS and an older NV6800GT. A very old NV6600 never showed > up these lockings when I used that PCIe-Card with FreeBSD 7.0/7.1, but > I'm not sure. The locks came spontanous, sometimes after heavy usage of > 'mplayer', but sometimes instantanously after the destop showed up. > > On those boxes, there is no Linux emulation and no Linux BLOB (useless, > due to 64 Bit). I swapped the 'nv' driver on all FreeBSD boxes with > 'vesa', because there is another issue with sprites/graphics buffers > many times reported using FireFox. > > When the display got locked, sometimes I had the chance opening a ssh > session killing Xorg/xdm and restarting working, but by the end, that > was when changing towards 8.0-CUR, this 'trick' didn't work anymore. On > FBSD 7, Xorg was eating up 100% CPU time. exactly my situation. I noticed that when the machine stucks while starting X I am sometimes (~ 60%) able to ctrl-alt-backspace and it after some minutes kills the X (= some sort of livelock?), after that I can 100% start the X successfully... From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 08:34:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DF2B1065670 for ; Fri, 9 Jan 2009 08:34:20 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 39E7D8FC08 for ; Fri, 9 Jan 2009 08:34:20 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id C8A539CB22A; Fri, 9 Jan 2009 09:34:10 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6rYyhsoC8gP; Fri, 9 Jan 2009 09:34:04 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id C67E39CB2CC; Fri, 9 Jan 2009 09:34:04 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n098Y4KS056461; Fri, 9 Jan 2009 09:34:04 +0100 (CET) (envelope-from rdivacky) Date: Fri, 9 Jan 2009 09:34:04 +0100 From: Roman Divacky To: Ollivier Robert Message-ID: <20090109083404.GB55615@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090108233311.GA69883@keltia.freenix.fr> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 08:34:20 -0000 On Fri, Jan 09, 2009 at 12:33:11AM +0100, Ollivier Robert wrote: > According to O. Hartmann: > > When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > > compiler suite? We figured out that gcc 4.3 does have a speed gain in > > some numerical code of 3 - 8 % and I guess we can use this in the basic > > OS as well ... > > I'd rather have llvm instead... I am working a little on clang/llvm and I also looked at pcc, it's not there yet to be able to compile world/kernel but it's progressing well... there are two major features missing from clang (designated initializers and wchars) that prevents it from compiling world/kernel, and of course bugs :) but I am periodically checking how it performs and I post thebugs to the llvm/clang team... I believe we'll have it one day :) roman From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 08:49:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0667E106564A for ; Fri, 9 Jan 2009 08:49:14 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id A7F458FC17 for ; Fri, 9 Jan 2009 08:49:13 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 8B21C3B9A4 for ; Fri, 9 Jan 2009 09:49:11 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNFgY6Bp4xdy for ; Fri, 9 Jan 2009 09:49:11 +0100 (CET) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 11AA43B9A2; Fri, 9 Jan 2009 09:49:11 +0100 (CET) Date: Fri, 9 Jan 2009 09:49:11 +0100 From: Ollivier Robert To: freebsd-current@freebsd.org Message-ID: <20090109084908.GA76970@keltia.freenix.fr> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090109002133.GA92874@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090109002133.GA92874@troutmask.apl.washington.edu> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7 / Dell D820 SMP User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 08:49:14 -0000 According to Steve Kargl: > Probably not for a very long time. gcc 4.3 requires both GMP and > MPFR libraries. Neither library is in src. I do not know what MPFR is (something about FP, right?) but I wonder at why GMP could be needed by a compiler... Considering the amount of effort Apple is putting into llvm, I think this is the way to go. I'm not sure whether going with llvm-gcc4 is worth it although it would get us in bed with llvm faster. Go Roman! :) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Dons / donation Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 09:16:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A96831065672 for ; Fri, 9 Jan 2009 09:16:25 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6EB8FC27 for ; Fri, 9 Jan 2009 09:16:25 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so5465793qwb.7 for ; Fri, 09 Jan 2009 01:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=4A6AjuRPM6V7vSpLdcK/bHz0kFJeDWihnLhhErLnk7I=; b=b1ZXg/bX8yKHTuzkir1yzCN6YVY/JRXji49DfiL5w6InC6przfE9r/n0LAcH+TkGFT g5zNXUSCpCk98wDbdM+u9AudUqCyco4mUW39Tx+kwweRbjEa6H3Wu4/yMZYyYThEOIij VFynJTIDRtIGYZ0A2HweQWSIDergPc2poxr1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ZwhuxLZoQIVTSPTr5QwHO5rgBAsSEYHpeOrJKvatUHvz76IqioSUMef+5z18CDZkuh 320JtRQM4snejljYkVxGk0InAnomETpYKlggN5s/+mnGtyGsZa8a15wbDxGaSSxaW4fZ 0E/4uUXRnfQ5prtnBITWp/exCpeNy/0DzPQMk= Received: by 10.214.11.14 with SMTP id 14mr22404376qak.210.1231490700433; Fri, 09 Jan 2009 00:45:00 -0800 (PST) Received: by 10.214.115.6 with HTTP; Fri, 9 Jan 2009 00:45:00 -0800 (PST) Message-ID: Date: Fri, 9 Jan 2009 16:45:00 +0800 From: "Jiawei Ye" To: "Roman Divacky" In-Reply-To: <20090109083404.GB55615@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109083404.GB55615@freebsd.org> Cc: Ollivier Robert , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 09:16:26 -0000 On Fri, Jan 9, 2009 at 4:34 PM, Roman Divacky wrote: > I am working a little on clang/llvm and I also looked at pcc, it's not > there yet to be able to compile world/kernel but it's progressing well... > > > there are two major features missing from clang (designated initializers > and wchars) that prevents it from compiling world/kernel, and of course > bugs :) but I am periodically checking how it performs and I post thebugs > to the llvm/clang team... > > I believe we'll have it one day :) > > roman What about llvm-gcc4? This has more compatibility with gcc than clang. Jiawei -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 09:19:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 891D31065680 for ; Fri, 9 Jan 2009 09:19:37 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id CCFCB8FC0C for ; Fri, 9 Jan 2009 09:19:36 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 09 Jan 2009 09:19:35 -0000 Received: from p54A3E499.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.228.153] by mail.gmx.net (mp038) with SMTP; 09 Jan 2009 10:19:35 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18UyVlf8s8U0cBfdmkXtBDUmFdlTgs5OhYDmxokrL gG4SPKW+DndB5q Message-ID: <496716A6.7010606@gmx.de> Date: Fri, 09 Jan 2009 10:19:34 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Ollivier Robert References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090109002133.GA92874@troutmask.apl.washington.edu> <20090109084908.GA76970@keltia.freenix.fr> In-Reply-To: <20090109084908.GA76970@keltia.freenix.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Cc: freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 09:19:38 -0000 Ollivier Robert schrieb: > According to Steve Kargl: >> Probably not for a very long time. gcc 4.3 requires both GMP and >> MPFR libraries. Neither library is in src. > > I do not know what MPFR is (something about FP, right?) but I wonder at why > GMP could be needed by a compiler... Mostly host independent constant folding. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 09:21:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6481B1065673 for ; Fri, 9 Jan 2009 09:21:36 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1D8478FC1C for ; Fri, 9 Jan 2009 09:21:36 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 7A22F9CB12C; Fri, 9 Jan 2009 10:21:26 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hc8fUKGmhf6B; Fri, 9 Jan 2009 10:21:23 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id A277E9CB232; Fri, 9 Jan 2009 10:21:23 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n099LNb1078268; Fri, 9 Jan 2009 10:21:23 +0100 (CET) (envelope-from rdivacky) Date: Fri, 9 Jan 2009 10:21:23 +0100 From: Roman Divacky To: Jiawei Ye Message-ID: <20090109092123.GA78163@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109083404.GB55615@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Ollivier Robert , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 09:21:37 -0000 On Fri, Jan 09, 2009 at 04:45:00PM +0800, Jiawei Ye wrote: > On Fri, Jan 9, 2009 at 4:34 PM, Roman Divacky wrote: > > I am working a little on clang/llvm and I also looked at pcc, it's not > > there yet to be able to compile world/kernel but it's progressing well... > > > > > > there are two major features missing from clang (designated initializers > > and wchars) that prevents it from compiling world/kernel, and of course > > bugs :) but I am periodically checking how it performs and I post thebugs > > to the llvm/clang team... > > > > I believe we'll have it one day :) > > > > roman > What about llvm-gcc4? This has more compatibility with gcc than clang. it sure does.... now, but I think it's and dead end (for a number of reasons) I like clang better (and hence I work on that) From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 09:22:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBE32106564A for ; Fri, 9 Jan 2009 09:22:18 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 1D1AC8FC14 for ; Fri, 9 Jan 2009 09:22:17 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 09 Jan 2009 09:22:16 -0000 Received: from p54A3E499.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.228.153] by mail.gmx.net (mp046) with SMTP; 09 Jan 2009 10:22:16 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18o1No6x30ooNjwofLBYNNydOLMUUeCpMlPhMyQES Dau3VbUmbdKKC4 Message-ID: <49671748.3030709@gmx.de> Date: Fri, 09 Jan 2009 10:22:16 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "O. Hartmann" References: <49668763.8020705@mail.zedat.fu-berlin.de> In-Reply-To: <49668763.8020705@mail.zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Cc: freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 09:22:19 -0000 O. Hartmann schrieb: > When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > compiler suite? We figured out that gcc 4.3 does have a speed gain in > some numerical code of 3 - 8 % and I guess we can use this in the basic > OS as well ... Number crunching has a totally different execution profile than basic operating system services. Gains in one area cannot simply be transferred to the other. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 09:37:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B3BA106566C for ; Fri, 9 Jan 2009 09:37:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id E70808FC0C for ; Fri, 9 Jan 2009 09:37:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 21857 invoked by uid 399); 9 Jan 2009 09:37:06 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Jan 2009 09:37:06 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Fri, 9 Jan 2009 01:37:04 -0800 (PST) From: Doug Barton To: Garrett Cooper In-Reply-To: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> Message-ID: References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 09:37:07 -0000 On Wed, 7 Jan 2009, Garrett Cooper wrote: > Hello folks, > As many probably know, I recently installed FreeBSD 8-CURRENT on > my desktop. Why would we know that? I mean good for you, but seriously ... :) > One of the things I'm noting is that when I use dual displays with > the nvidia driver, and xscreensaver kicks in and keeps going for a > period of time, the machine's X.org console eats up a core, and when I > try and do anything like gdb Xorg, the system hangs, attempts to panic > (I assume that's the case because I hear it beep and attempt to > restart), then I have to give it a warm boot. truss(1)'ing Xorg showed > that there were a lot of SIGALARM's being fired and masked. No solutions, but a few general comments. First, I know that the author of xscreensaver has put a lot of work into dual head stuff, and also that it creates a lot of problems, so you're not alone here. If you get any conclusive evidence that xscreensaver is at fault you should contact him at http://www.jwz.org/xscreensaver/bugs.html A few things you can try to narrow it down .... first try turning off the xscreensaver daemon and just run one of the screensaver programs full screen for a while to see if that causes the crash. It's also worth testing GL vs. non-GL screensavers. I had a problem with GL stuff for a while that was fixed by an nvidia driver update a few versions ago. You should probably also try running with just the nv driver and see if that causes the same crash. Finally, you might try setting debug.debugger_on_panic=0 in /etc/sysctl.conf if you don't have it already. That will cause panics to go directly to dumping which is useful if you're in X. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 10:06:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7E7C106566B for ; Fri, 9 Jan 2009 10:06:05 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 4F9A58FC1D for ; Fri, 9 Jan 2009 10:06:04 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 09 Jan 2009 10:06:02 -0000 Received: from p54A3E499.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.228.153] by mail.gmx.net (mp055) with SMTP; 09 Jan 2009 11:06:02 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/ypdp9cTbyqYxfNMvQ29/nozaNpIUey7Kfpynv1J jyRZ7Q/u1lUKtB Message-ID: <49672189.5060109@gmx.de> Date: Fri, 09 Jan 2009 11:06:01 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Andrew Reilly References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> In-Reply-To: <20090109031147.GB44317@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Cc: Ollivier Robert , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 10:06:06 -0000 Andrew Reilly schrieb: > On Fri, Jan 09, 2009 at 12:33:11AM +0100, Ollivier Robert wrote: >> According to O. Hartmann: >>> When will gcc 4.3 incorporated in FreeBSD 8 and become the standard >>> compiler suite? We figured out that gcc 4.3 does have a speed gain in >>> some numerical code of 3 - 8 % and I guess we can use this in the basic >>> OS as well ... >> I'd rather have llvm instead... > > I wouldn't mind that, either. I've got the llvm port installed myself, in > preparation for doing some experiments of my own, but haven't tried using it to > build the kernel or user-land (or even any of the ports). Has anyone given it a > go? Is it missing any crucial features? I believe that it had different (or > no?) support for PIC code generation, which could affect the ability to do > shared libraries, but recent release notes seem to indicate that that's been > addressed. One quite important difference between GCC and LLVM is that GCC has been used to compile literally billions and billions of lines of code. Sure, LLVM has compiled many lines, too, but it's hard to beat GCC in terms of stability in this respect (yes, I am well aware that GCC had and has its share of bugs). You have to do *lots* of testing before you can honestly say that a compiler can really be used to compile a whole operating system. Another aspect is that LLVM is in some parts more aggressive at optimisation than GCC. So sloppy code, which GCC let you get away with, may suddenly break - though it was wrong all along, but you just never noticed. Of course the code has to be fixed, but this takes time. I'm not saying it's wrong to look for alternatives, but you cannot just change your system compiler like you change underwear. > There's also someone working on a BSD-licenced retooling (ANSI/ISO-ification) of > the PCC compiler, which is getting close to being useful as a system compiler, I > believe. (http://www.ludd.ltu.se/~ragge/pcc/ in ports/lang/pcc) PCC cannot seriously be considered. Its design is stuck in the seventies. From the point of view of compiler construction it is plain plain out of question. I especially was amused by the statement of the author who claimed PCC supports SSA - except for phi-functions. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 10:10:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D4481065670 for ; Fri, 9 Jan 2009 10:10:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 038268FC1A for ; Fri, 9 Jan 2009 10:10:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7554B3F12F for ; Fri, 9 Jan 2009 09:53:53 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n099rrJw003995 for ; Fri, 9 Jan 2009 09:53:53 GMT (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Fri, 09 Jan 2009 09:53:53 +0000 Message-ID: <3994.1231494833@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 10:10:15 -0000 I tried using my 3g modem (Huawei E196) yesterday, with both the old and the new USB stack, and it fails in slightly different ways. With the old USB stack, it works until I actually try to get a packet of more than approx 1024 bytes through, at which point it hangs with ucom0: ucomreadcb: IOERROR And I need to stop and start ppp(1) to get it working until the next big packet comes around. It does not help to reduce the MRU because two small packets back to back will also trigger this error. With the new USB stack, I am not able to talk to the modem at all using the cuaU* devices. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 10:32:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52AC2106564A for ; Fri, 9 Jan 2009 10:32:26 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id E17E98FC08 for ; Fri, 9 Jan 2009 10:32:25 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by yx-out-2324.google.com with SMTP id 8so3950327yxb.13 for ; Fri, 09 Jan 2009 02:32:25 -0800 (PST) Received: by 10.90.88.16 with SMTP id l16mr1805410agb.4.1231497145052; Fri, 09 Jan 2009 02:32:25 -0800 (PST) Received: by 10.90.106.8 with HTTP; Fri, 9 Jan 2009 02:32:25 -0800 (PST) Message-ID: Date: Fri, 9 Jan 2009 11:32:25 +0100 From: "=?ISO-8859-1?Q?Marius_N=FCnnerich?=" To: "Bruce M. Simpson" In-Reply-To: <4966A9AB.2040802@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4965927D.1060507@freebsd.org> <4966A9AB.2040802@FreeBSD.org> Cc: Tim Kientzle , "freebsd-current@freebsd.org" Subject: Re: bsdtar fan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 10:32:26 -0000 On Fri, Jan 9, 2009 at 2:34 AM, Bruce M. Simpson wrote: > Off topic: > Tim, thank you for bsdtar. I recently had to muck around with ISO images on > a debian box, and mounting them all would have been prohibitive. Thanks to > bsdtar, I could just extract the files I needed, without using loopback > mounts. That was invaluable. thank you! When I'm on other systems I constantly try tar xf and fail. bsdtar rocks Tim :) From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 10:41:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAD731065701 for ; Fri, 9 Jan 2009 10:41:28 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9D90A8FC1A for ; Fri, 9 Jan 2009 10:41:28 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from PegaPegII (93-152-14-233.daisydsl.managedbroadband.co.uk [93.152.14.233]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n09AfMiE065895; Fri, 9 Jan 2009 10:41:23 GMT (envelope-from ken@mthelicon.com) Message-ID: <2889C93967084361AF31BC85B2D52D1D@PegaPegII> From: "Pegasus Mc Cleaft" To: "Christoph Mallon" , "Andrew Reilly" References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr><20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> In-Reply-To: <49672189.5060109@gmx.de> Date: Fri, 9 Jan 2009 10:41:24 -0000 Organization: Feathers MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Antivirus: avast! (VPS 090108-0, 08/01/2009), Outbound message X-Antivirus-Status: Clean Cc: Ollivier Robert , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pegasus Mc Cleaft List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 10:41:29 -0000 ----- Original Message ----- From: "Christoph Mallon" To: "Andrew Reilly" Cc: "Ollivier Robert" ; Sent: Friday, January 09, 2009 10:06 AM Subject: Re: gcc 4.3: when will it become standard compiler? > Andrew Reilly schrieb: >> On Fri, Jan 09, 2009 at 12:33:11AM +0100, Ollivier Robert wrote: >>> According to O. Hartmann: >>>> When will gcc 4.3 incorporated in FreeBSD 8 and become the standard >>>> compiler suite? We figured out that gcc 4.3 does have a speed gain in >>>> some numerical code of 3 - 8 % and I guess we can use this in the basic >>>> OS as well ... >>> I'd rather have llvm instead... >> >> I wouldn't mind that, either. I've got the llvm port installed myself, >> in >> preparation for doing some experiments of my own, but haven't tried using >> it to >> build the kernel or user-land (or even any of the ports). Has anyone >> given it a >> go? Is it missing any crucial features? I believe that it had different >> (or >> no?) support for PIC code generation, which could affect the ability to >> do >> shared libraries, but recent release notes seem to indicate that that's >> been >> addressed. > > One quite important difference between GCC and LLVM is that GCC has been > used to compile literally billions and billions of lines of code. Sure, > LLVM has compiled many lines, too, but it's hard to beat GCC in terms of > stability in this respect (yes, I am well aware that GCC had and has its > share of bugs). You have to do *lots* of testing before you can honestly > say that a compiler can really be used to compile a whole operating > system. > Another aspect is that LLVM is in some parts more aggressive at > optimisation than GCC. So sloppy code, which GCC let you get away with, > may suddenly break - though it was wrong all along, but you just never > noticed. Of course the code has to be fixed, but this takes time. > I'm not saying it's wrong to look for alternatives, but you cannot just > change your system compiler like you change underwear. > >> There's also someone working on a BSD-licenced retooling >> (ANSI/ISO-ification) of >> the PCC compiler, which is getting close to being useful as a system >> compiler, I >> believe. (http://www.ludd.ltu.se/~ragge/pcc/ in ports/lang/pcc) > > PCC cannot seriously be considered. Its design is stuck in the seventies. > From the point of view of compiler construction it is plain plain out of > question. I especially was amused by the statement of the author who > claimed PCC supports SSA - except for phi-functions. Hi Current, I personally dont mind GCC being of a older version for the world and kernel compiles, however, I do wish that a newer version of binutils were used. I can compile GCC from the ports or download the sources and compile it there, but it seems to get really icky if you have two versions of binutils installed. The benifits of having the newer binutils is that I can compile using SSE4.1 which bomb out now due to the older "as" not knowing the new opcodes. I believe there are licenscing issues with using the newer binutils, but what they are I have no idea. Peg From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 10:44:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C741106566B for ; Fri, 9 Jan 2009 10:44:55 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-fx0-f26.google.com (mail-fx0-f26.google.com [209.85.220.26]) by mx1.freebsd.org (Postfix) with ESMTP id E21478FC1B for ; Fri, 9 Jan 2009 10:44:54 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by fxm7 with SMTP id 7so1802902fxm.19 for ; Fri, 09 Jan 2009 02:44:53 -0800 (PST) Received: by 10.223.113.194 with SMTP id b2mr18390243faq.80.1231497893650; Fri, 09 Jan 2009 02:44:53 -0800 (PST) Received: by 10.223.112.75 with HTTP; Fri, 9 Jan 2009 02:44:53 -0800 (PST) Message-ID: <367b2c980901090244t64d33c2fx171cda607914189e@mail.gmail.com> Date: Fri, 9 Jan 2009 11:44:53 +0100 From: "Olivier SMEDTS" To: "freebsd-current@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4965927D.1060507@freebsd.org> <4966A9AB.2040802@FreeBSD.org> Cc: Tim Kientzle Subject: Re: bsdtar fan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 10:44:55 -0000 2009/1/9 Marius N=FCnnerich : > On Fri, Jan 9, 2009 at 2:34 AM, Bruce M. Simpson wrote: >> Off topic: >> Tim, thank you for bsdtar. I recently had to muck around with ISO images= on >> a debian box, and mounting them all would have been prohibitive. Thanks = to >> bsdtar, I could just extract the files I needed, without using loopback >> mounts. That was invaluable. thank you! > > When I'm on other systems I constantly try tar xf and fail. bsdtar rocks = Tim :) I totally agree. Just fed up determining compression type of archives and using z/j flags with non-bsd tar :) Thank you Tim ! > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:00:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A1861065670; Fri, 9 Jan 2009 11:00:50 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id ABD448FC12; Fri, 9 Jan 2009 11:00:49 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nklthdr5v5AUSfVrlghuJA==:17 a=Tby5vXGZl2FAB7Z_HuoA:9 a=X6rXYyvLX17rPgHO2KUA:7 a=3NddBVTjV7soyHz1fAiOhIBmzjoA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1175523982; Fri, 09 Jan 2009 12:00:47 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 9 Jan 2009 12:02:39 +0100 User-Agent: KMail/1.9.7 References: <3994.1231494833@critter.freebsd.dk> In-Reply-To: <3994.1231494833@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901091202.41011.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:00:50 -0000 On Friday 09 January 2009, Poul-Henning Kamp wrote: > I tried using my 3g modem (Huawei E196) yesterday, with both the > old and the new USB stack, and it fails in slightly different > ways. > > With the old USB stack, it works until I actually try to get a packet > of more than approx 1024 bytes through, at which point it hangs with > ucom0: ucomreadcb: IOERROR > And I need to stop and start ppp(1) to get it working until the next > big packet comes around. > > It does not help to reduce the MRU because two small packets back to > back will also trigger this error. > > With the new USB stack, I am not able to talk to the modem at all > using the cuaU* devices. Hi, With regard to the new USB stack: Do you see any USB error messages in dmesg? What does the dmesg print out? Also there are debugging sysctls: sysctl -a hw.usb2 | grep debug Also try dumping the descriptors of your device using "usbconfig -u xxx -a yyy dump_device_desc dump_curr_config_desc". You can also try things like: usbconfig -u xxx -a yyy reset --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:00:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A1861065670; Fri, 9 Jan 2009 11:00:50 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id ABD448FC12; Fri, 9 Jan 2009 11:00:49 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nklthdr5v5AUSfVrlghuJA==:17 a=Tby5vXGZl2FAB7Z_HuoA:9 a=X6rXYyvLX17rPgHO2KUA:7 a=3NddBVTjV7soyHz1fAiOhIBmzjoA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1175523982; Fri, 09 Jan 2009 12:00:47 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 9 Jan 2009 12:02:39 +0100 User-Agent: KMail/1.9.7 References: <3994.1231494833@critter.freebsd.dk> In-Reply-To: <3994.1231494833@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901091202.41011.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:00:50 -0000 On Friday 09 January 2009, Poul-Henning Kamp wrote: > I tried using my 3g modem (Huawei E196) yesterday, with both the > old and the new USB stack, and it fails in slightly different > ways. > > With the old USB stack, it works until I actually try to get a packet > of more than approx 1024 bytes through, at which point it hangs with > ucom0: ucomreadcb: IOERROR > And I need to stop and start ppp(1) to get it working until the next > big packet comes around. > > It does not help to reduce the MRU because two small packets back to > back will also trigger this error. > > With the new USB stack, I am not able to talk to the modem at all > using the cuaU* devices. Hi, With regard to the new USB stack: Do you see any USB error messages in dmesg? What does the dmesg print out? Also there are debugging sysctls: sysctl -a hw.usb2 | grep debug Also try dumping the descriptors of your device using "usbconfig -u xxx -a yyy dump_device_desc dump_curr_config_desc". You can also try things like: usbconfig -u xxx -a yyy reset --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:05:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CBDD106564A for ; Fri, 9 Jan 2009 11:05:23 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2ADAA8FC0C for ; Fri, 9 Jan 2009 11:05:22 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 2CCF29CB12C; Fri, 9 Jan 2009 12:05:12 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epZ+9E70lOkY; Fri, 9 Jan 2009 12:05:09 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 749209CB2B7; Fri, 9 Jan 2009 12:05:09 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n09B59l7013300; Fri, 9 Jan 2009 12:05:09 +0100 (CET) (envelope-from rdivacky) Date: Fri, 9 Jan 2009 12:05:08 +0100 From: Roman Divacky To: Christoph Mallon Message-ID: <20090109110508.GA12123@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49672189.5060109@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: Andrew Reilly , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:05:25 -0000 On Fri, Jan 09, 2009 at 11:06:01AM +0100, Christoph Mallon wrote: > Andrew Reilly schrieb: > >On Fri, Jan 09, 2009 at 12:33:11AM +0100, Ollivier Robert wrote: > >>According to O. Hartmann: > >>>When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > >>>compiler suite? We figured out that gcc 4.3 does have a speed gain in > >>>some numerical code of 3 - 8 % and I guess we can use this in the basic > >>>OS as well ... > >>I'd rather have llvm instead... > > > >I wouldn't mind that, either. I've got the llvm port installed myself, in > >preparation for doing some experiments of my own, but haven't tried using > >it to > >build the kernel or user-land (or even any of the ports). Has anyone > >given it a > >go? Is it missing any crucial features? I believe that it had different > >(or > >no?) support for PIC code generation, which could affect the ability to do > >shared libraries, but recent release notes seem to indicate that that's > >been > >addressed. > > One quite important difference between GCC and LLVM is that GCC has been > used to compile literally billions and billions of lines of code. Sure, > LLVM has compiled many lines, too, but it's hard to beat GCC in terms of > stability in this respect (yes, I am well aware that GCC had and has its > share of bugs). You have to do *lots* of testing before you can honestly > say that a compiler can really be used to compile a whole operating system. > Another aspect is that LLVM is in some parts more aggressive at > optimisation than GCC. So sloppy code, which GCC let you get away with, > may suddenly break - though it was wrong all along, but you just never > noticed. Of course the code has to be fixed, but this takes time. > I'm not saying it's wrong to look for alternatives, but you cannot just > change your system compiler like you change underwear. well... the first step is imho starting to compile world with C99... that might reveal some bugs, note that as of a few months ago 8-current compiles cleanly with C99, that does not mean that it's working when you run those programs correctly :) > >There's also someone working on a BSD-licenced retooling > >(ANSI/ISO-ification) of > >the PCC compiler, which is getting close to being useful as a system > >compiler, I > >believe. (http://www.ludd.ltu.se/~ragge/pcc/ in ports/lang/pcc) > > PCC cannot seriously be considered. Its design is stuck in the > seventies. From the point of view of compiler construction it is plain > plain out of question. I especially was amused by the statement of the > author who claimed PCC supports SSA - except for phi-functions. what's wrong with design stuck in 70's when it compiles the whole world/kernel? I would not use it for default compilation of releases but it might be useful when you are developing - because of its fast compilation times btw.. are you sure the design is stuck in the 70's? the author claims to have rewritten almost the whole thing. have you looked at the recent code? another question - how is libfirm/cparser? last time I tried it didnt support much of the gcc options (-Wsomething -f-something etc.) so it could not be used as a direct drop-in From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:07:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C161F10656DC for ; Fri, 9 Jan 2009 11:07:08 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3A38FC0A for ; Fri, 9 Jan 2009 11:07:08 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D77609CB12C; Fri, 9 Jan 2009 12:06:58 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 079elGwfvHSE; Fri, 9 Jan 2009 12:06:47 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 1A7349CB298; Fri, 9 Jan 2009 12:06:47 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n09B6kpu013505; Fri, 9 Jan 2009 12:06:46 +0100 (CET) (envelope-from rdivacky) Date: Fri, 9 Jan 2009 12:06:46 +0100 From: Roman Divacky To: Pegasus Mc Cleaft Message-ID: <20090109110646.GB12123@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <49672189.5060109@gmx.de> <2889C93967084361AF31BC85B2D52D1D@PegaPegII> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2889C93967084361AF31BC85B2D52D1D@PegaPegII> User-Agent: Mutt/1.4.2.3i Cc: Andrew Reilly , Christoph Mallon , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:07:09 -0000 > Hi Current, > > I personally dont mind GCC being of a older version for the world and > kernel compiles, however, I do wish that a newer version of binutils were > used. > > I can compile GCC from the ports or download the sources and compile it > there, but it seems to get really icky if you have two versions of binutils > installed. The benifits of having the newer binutils is that I can compile > using SSE4.1 which bomb out now due to the older "as" not knowing the new > opcodes. > > I believe there are licenscing issues with using the newer binutils, but > what they are I have no idea. I am sure the last GPLv2 is MUCH newer than what we have now :) From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:27:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C184106566B for ; Fri, 9 Jan 2009 11:27:06 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-fx0-f26.google.com (mail-fx0-f26.google.com [209.85.220.26]) by mx1.freebsd.org (Postfix) with ESMTP id 5FFE08FC22 for ; Fri, 9 Jan 2009 11:27:05 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by fxm7 with SMTP id 7so1805121fxm.19 for ; Fri, 09 Jan 2009 03:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=JhwTH2XGxahLcUwppJoyFazssnxcjcArSHBXJtSmUCE=; b=HKtfVGkBcWhWzq2jpmS9PSKuzc/aIlrZGRR/OJpVzl9qvOQbExmGqwyraPvzEqws+5 FfidHhY0URpPtsNlUFQ753Ly5pLxZs9Lld0mhox1WXc+DnFmI64aB8nE51KZNsYsezIk ia/cC3DamCKNmBffjrJlTI94mw/7BO9b31mQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=bU2dukpNtNyP3voueL8YfOEW5FKWoCVcRAke5IzOYfbJYCyVQZKCQwuKlhpKmg7Sw6 qoFA5BpYP2GpDBEWqpQjJiju3zZ/UorC8gj7HmjSP448UQVMdDFYWOTTp8WjyZYqawgQ l7EikpAk5ShGDhWZzR2LKtiQq16w0JbLJ1e9Y= Received: by 10.103.182.3 with SMTP id j3mr9140323mup.113.1231500424175; Fri, 09 Jan 2009 03:27:04 -0800 (PST) Received: by 10.103.137.8 with HTTP; Fri, 9 Jan 2009 03:27:04 -0800 (PST) Message-ID: Date: Fri, 9 Jan 2009 09:27:04 -0200 From: "Carlos A. M. dos Santos" To: "Giorgos Keramidas" In-Reply-To: <87prixz9ne.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_147700_25352261.1231500424172" References: <87prixz9ne.fsf@kobe.laptop> Cc: Alexander Best , freebsd-current@freebsd.org, sos@freebsd.org Subject: Re: patch to fix burncd bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:27:07 -0000 ------=_Part_147700_25352261.1231500424172 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, Jan 8, 2009 at 8:59 PM, Giorgos Keramidas wrote: > On Thu, 08 Jan 2009 18:13:14 +0100 (CET), Alexander Best wrote: >> could somebody please commit the following patch to dev/ata? it fixes >> a nasty bug during fixation in burncd. the bug exists in RELENG6, >> RELENG7 and HEAD (and maybe RELENG5): >> >> http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch >> >> the whole PR can be found here: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 > > I think Soren is the best person to look into this bug (Cc: added). > > Soren, what do you think? Does the patch at bin/95979 look like a nice > change to commit? I just saw this PR so I haven't tried the patch on my > laptop's CURRENT yet, but I can confirm that burning CD-ROMs and DVDs is > busted in my laptop for a few weeks now. I proposed a solution a similar problem (bin/123693), but patching burncd instead of the kernel. I'm attaching the patch, for your convenience. -- cd /usr/ports/sysutils/life make clean ------=_Part_147700_25352261.1231500424172 Content-Type: text/x-diff; name=burncd_eject.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_fpqrhhzs0 Content-Disposition: attachment; filename=burncd_eject.patch ZGlmZiAtZHVyUCBidXJuY2Qub3JpZy9idXJuY2QuYyBidXJuY2QvYnVybmNkLmMKLS0tIGJ1cm5j ZC5vcmlnL2J1cm5jZC5jCTIwMDUtMDUtMTMgMTc6MDY6NDQuMDAwMDAwMDAwIC0wMzAwCisrKyBi dXJuY2QvYnVybmNkLmMJMjAwOC0wNS0yNiAwMDo1MTozMS4wMDAwMDAwMDAgLTAzMDAKQEAgLTQ2 LDYgKzQ2LDcgQEAKICNpbmNsdWRlIDxhcnBhL2luZXQuaD4KIAogI2RlZmluZSBCTE9DS1MJMTYK KyNkZWZpbmUgRUpFQ1RfVFJJRVMgNQogCiBzdHJ1Y3QgdHJhY2tfaW5mbyB7CiAJaW50CWZpbGU7 CkBAIC0zMTYsOSArMzE3LDE1IEBACiAJCWVycihFWF9JT0VSUiwgImlvY3RsKENEUklPQ1NFVEJM T0NLU0laRSkiKTsKIAl9CiAKLQlpZiAoZWplY3QpCi0JCWlmIChpb2N0bChmZCwgQ0RJT0NFSkVD VCkgPCAwKQorCWlmIChlamVjdCkgeworCQlpbnQgc3RhdHVzLCB0cnkgPSBFSkVDVF9UUklFUywg ZGVsYXkgPSAxOworCQl3aGlsZSAoKHN0YXR1cyA9IGlvY3RsKGZkLCBDRElPQ0VKRUNUKSkgPCAw ICYmIC0tdHJ5ID4gMCkgeworCQkJc2xlZXAoZGVsYXkpOworCQkJZGVsYXkgKj0gMjsKKwkJfQor CQlpZiAoc3RhdHVzIDwgMCkKIAkJCWVycihFWF9JT0VSUiwgImlvY3RsKENESU9DRUpFQ1QpIik7 CisJfQogCWNsb3NlKGZkKTsKIAlleGl0KEVYX09LKTsKIH0KT25seSBpbiBidXJuY2Qub3JpZzog YnVybmNkLmMub3JpZwo= ------=_Part_147700_25352261.1231500424172-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:30:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E32310656F4; Fri, 9 Jan 2009 11:30:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 201588FC08; Fri, 9 Jan 2009 11:30:11 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1CA173F12F; Fri, 9 Jan 2009 11:30:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n09BUAxC020723; Fri, 9 Jan 2009 11:30:10 GMT (envelope-from phk@critter.freebsd.dk) To: Hans Petter Selasky From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Jan 2009 12:02:39 +0100." <200901091202.41011.hselasky@c2i.net> Date: Fri, 09 Jan 2009 11:30:10 +0000 Message-ID: <20722.1231500610@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:30:14 -0000 In message <200901091202.41011.hselasky@c2i.net>, Hans Petter Selasky writes: >On Friday 09 January 2009, Poul-Henning Kamp wrote: >With regard to the new USB stack: > >Do you see any USB error messages in dmesg? I didn't see anything that looked like an error, the device just does not respond to "AT" commands on the tty device. It goes through the "change mode from install-CD" dance, comes up with /dev/cuaU[0-2], /dev/cd0 and /dev/da1, da1 because I have another USB disk in the system also (which works), but the cuaU[0-2] devices does not seem to work. >What does the dmesg print out? I don't have the messages saved, I did it in single user. >Also there are debugging sysctls: > >sysctl -a hw.usb2 | grep debug Yeah, tried those, but didn't see anything that looked like an error. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:30:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E32310656F4; Fri, 9 Jan 2009 11:30:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 201588FC08; Fri, 9 Jan 2009 11:30:11 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1CA173F12F; Fri, 9 Jan 2009 11:30:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n09BUAxC020723; Fri, 9 Jan 2009 11:30:10 GMT (envelope-from phk@critter.freebsd.dk) To: Hans Petter Selasky From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Jan 2009 12:02:39 +0100." <200901091202.41011.hselasky@c2i.net> Date: Fri, 09 Jan 2009 11:30:10 +0000 Message-ID: <20722.1231500610@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:30:15 -0000 In message <200901091202.41011.hselasky@c2i.net>, Hans Petter Selasky writes: >On Friday 09 January 2009, Poul-Henning Kamp wrote: >With regard to the new USB stack: > >Do you see any USB error messages in dmesg? I didn't see anything that looked like an error, the device just does not respond to "AT" commands on the tty device. It goes through the "change mode from install-CD" dance, comes up with /dev/cuaU[0-2], /dev/cd0 and /dev/da1, da1 because I have another USB disk in the system also (which works), but the cuaU[0-2] devices does not seem to work. >What does the dmesg print out? I don't have the messages saved, I did it in single user. >Also there are debugging sysctls: > >sysctl -a hw.usb2 | grep debug Yeah, tried those, but didn't see anything that looked like an error. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:42:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62C4910656E1; Fri, 9 Jan 2009 11:42:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id C52DD8FC1E; Fri, 9 Jan 2009 11:42:08 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nklthdr5v5AUSfVrlghuJA==:17 a=JbGu6aKE2JXbL2_Z0GkA:9 a=PEWGqpi1ORKls2qO-Ti0ANZmcC8A:4 a=9aOQ2cSd83gA:10 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1177058963; Fri, 09 Jan 2009 12:42:07 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 9 Jan 2009 12:43:39 +0100 User-Agent: KMail/1.9.7 References: <20722.1231500610@critter.freebsd.dk> In-Reply-To: <20722.1231500610@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901091243.40981.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:42:10 -0000 On Friday 09 January 2009, Poul-Henning Kamp wrote: > In message <200901091202.41011.hselasky@c2i.net>, Hans Petter Selasky writes: > >On Friday 09 January 2009, Poul-Henning Kamp wrote: > > > >With regard to the new USB stack: > > > >Do you see any USB error messages in dmesg? > > I didn't see anything that looked like an error, the device just > does not respond to "AT" commands on the tty device. Which serial driver are you using? U3G? Are you using the latest code from -current ? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:42:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62C4910656E1; Fri, 9 Jan 2009 11:42:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id C52DD8FC1E; Fri, 9 Jan 2009 11:42:08 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nklthdr5v5AUSfVrlghuJA==:17 a=JbGu6aKE2JXbL2_Z0GkA:9 a=PEWGqpi1ORKls2qO-Ti0ANZmcC8A:4 a=9aOQ2cSd83gA:10 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1177058963; Fri, 09 Jan 2009 12:42:07 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 9 Jan 2009 12:43:39 +0100 User-Agent: KMail/1.9.7 References: <20722.1231500610@critter.freebsd.dk> In-Reply-To: <20722.1231500610@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901091243.40981.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:42:10 -0000 On Friday 09 January 2009, Poul-Henning Kamp wrote: > In message <200901091202.41011.hselasky@c2i.net>, Hans Petter Selasky writes: > >On Friday 09 January 2009, Poul-Henning Kamp wrote: > > > >With regard to the new USB stack: > > > >Do you see any USB error messages in dmesg? > > I didn't see anything that looked like an error, the device just > does not respond to "AT" commands on the tty device. Which serial driver are you using? U3G? Are you using the latest code from -current ? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:46:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35C821065708; Fri, 9 Jan 2009 11:46:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E5A148FC18; Fri, 9 Jan 2009 11:46:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5681E3F130; Fri, 9 Jan 2009 11:46:34 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n09BkYQp021014; Fri, 9 Jan 2009 11:46:34 GMT (envelope-from phk@critter.freebsd.dk) To: Hans Petter Selasky From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Jan 2009 12:43:39 +0100." <200901091243.40981.hselasky@c2i.net> Date: Fri, 09 Jan 2009 11:46:34 +0000 Message-ID: <21013.1231501594@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:46:36 -0000 In message <200901091243.40981.hselasky@c2i.net>, Hans Petter Selasky writes: >Which serial driver are you using? U3G? > >Are you using the latest code from -current ? I just compiled a USB2 kernel from yesterdays -current while sitting in the train. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:46:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35C821065708; Fri, 9 Jan 2009 11:46:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E5A148FC18; Fri, 9 Jan 2009 11:46:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5681E3F130; Fri, 9 Jan 2009 11:46:34 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n09BkYQp021014; Fri, 9 Jan 2009 11:46:34 GMT (envelope-from phk@critter.freebsd.dk) To: Hans Petter Selasky From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Jan 2009 12:43:39 +0100." <200901091243.40981.hselasky@c2i.net> Date: Fri, 09 Jan 2009 11:46:34 +0000 Message-ID: <21013.1231501594@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:46:36 -0000 In message <200901091243.40981.hselasky@c2i.net>, Hans Petter Selasky writes: >Which serial driver are you using? U3G? > >Are you using the latest code from -current ? I just compiled a USB2 kernel from yesterdays -current while sitting in the train. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 11:53:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0F57106566C for ; Fri, 9 Jan 2009 11:53:34 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-bw0-f33.google.com (mail-bw0-f33.google.com [209.85.218.33]) by mx1.freebsd.org (Postfix) with ESMTP id 29E138FC1A for ; Fri, 9 Jan 2009 11:53:33 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by bwz14 with SMTP id 14so7347394bwz.19 for ; Fri, 09 Jan 2009 03:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=V2P+dsqaU2Moa1ou9iLApAi7kCeKW2EoxYlIN04vpuM=; b=l4vL4it83AqkRwLUku0Yu3OHSvPySiOBISxG5zCFg/AMF4ModFyxB1qgzCXaBBU/lw nIHjJUyH9jumJo7vrD45ddlyrKmXXT5TPK0C3MfRjk5cTsH7yE3uXaRHHCL1NEUjeh/3 ukKatjBPzrHklQLVpyrUkhq7FtXmnCzamWr60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=yDN6iPpk8hDyvwPTuNyUQugc85ujpdWe2QoBydUP0FTwU1RIoD/we45v8WDFGduneO GKnUTcAvZtb6DeaFnaTuMp91lnAwMQiseJZpbpd376Ze5vk9StbIN0pmiUvHZFCDgKjP MXNcH9Iq7VoPGbJoXbBEHBWOTNA6ouVSZmEp0= Received: by 10.103.212.2 with SMTP id o2mr9144046muq.131.1231502012835; Fri, 09 Jan 2009 03:53:32 -0800 (PST) Received: by 10.103.137.8 with HTTP; Fri, 9 Jan 2009 03:53:32 -0800 (PST) Message-ID: Date: Fri, 9 Jan 2009 09:53:32 -0200 From: "Carlos A. M. dos Santos" To: "Andrew Reilly" In-Reply-To: <20090109031147.GB44317@duncan.reilly.home> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> Cc: Ollivier Robert , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 11:53:35 -0000 On Fri, Jan 9, 2009 at 1:11 AM, Andrew Reilly wrote: [...] > There's also someone working on a BSD-licenced retooling (ANSI/ISO-ification) of > the PCC compiler, which is getting close to being useful as a system compiler, I > believe. (http://www.ludd.ltu.se/~ragge/pcc/ in ports/lang/pcc) Yes, and they nedd money to keep working on it. Please see http://bsdfund.org/projects/pcc/ I already gave a contribution. Would you guys like to join me? -- cd /usr/ports/sysutils/life make clean From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 09:01:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2E93106567A; Fri, 9 Jan 2009 09:01:36 +0000 (UTC) (envelope-from Manfred.Knick@T-Online.de) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB078FC18; Fri, 9 Jan 2009 09:01:36 +0000 (UTC) (envelope-from Manfred.Knick@T-Online.de) Received: from fwd04.aul.t-online.de by mailout04.sul.t-online.de with smtp id 1LLDFF-0004c8-03; Fri, 09 Jan 2009 10:01:33 +0100 Received: from [192.168.1.21] (XLoqoOZDZh5MRjlyDX26rt6fXNOlz6ox2BpCGijcMFB7T2AlwtPrmr8P+YpKrFBQar@[79.239.220.135]) by fwd04.t-online.de with esmtp id 1LLDF0-0xTVqa0; Fri, 9 Jan 2009 10:01:18 +0100 Message-ID: <4967125D.80801@T-Online.de> Date: Fri, 09 Jan 2009 10:01:17 +0100 From: Manfred_Knick User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Robert Noland References: <496651ED.8080102@T-Online.de> <1231460648.93079.65.camel@squirrel.corp.cox.com> In-Reply-To: <1231460648.93079.65.camel@squirrel.corp.cox.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ID: XLoqoOZDZh5MRjlyDX26rt6fXNOlz6ox2BpCGijcMFB7T2AlwtPrmr8P+YpKrFBQar X-TOI-MSGID: e7b39dcc-7ee2-4c0b-ba68-2d7c791ff922 X-Mailman-Approved-At: Fri, 09 Jan 2009 12:26:33 +0000 Cc: stable@freebsd.org, current@freebsd.org Subject: Re: possibility of a "severe flaw in the logic of FreeBSD's kernel handling multiple host bridges ..." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 09:01:37 -0000 Robert Noland schrieb: > I'm really not sure that I am the best person to try and tackle this, Hi, Robert, thank you very much for your reply! > but it does fall somewhere near me... Can you send me a pciconf -lv. You are welcome! Well, as stated in the reports, I'm prepared to help with additional information and tests I can provide. My main background is Gentoo (GNU/Linux source based rolling meta- distribution), thus knowing my way around building my hand-crafted kernels ... Kind regards Manfred . --- --- --- pciconf -lv --- --- --- hostb0@pci0:0:0:0: class=0x060000 card=0x00e11849 chip=0x00e110de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Host/PCI Bridge' <===== class = bridge subclass = HOST-PCI isab0@pci0:0:1:0: class=0x060100 card=0x00e01849 chip=0x00e010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 LPC Interface Bridge' class = bridge subclass = PCI-ISA none0@pci0:0:1:1: class=0x0c0500 card=0x00e41849 chip=0x00e410de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 PCI System Management' class = serial bus subclass = SMBus ohci0@pci0:0:2:0: class=0x0c0310 card=0x00e71849 chip=0x00e710de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 OpenHCD USB Controller' class = serial bus subclass = USB ohci1@pci0:0:2:1: class=0x0c0310 card=0x00e71849 chip=0x00e710de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 OpenHCD USB Controller' class = serial bus subclass = USB ehci0@pci0:0:2:2: class=0x0c0320 card=0x00e81849 chip=0x00e810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Enhanced PCI to USB Controller' class = serial bus subclass = USB atapci0@pci0:0:8:0: class=0x01018a card=0x00e51849 chip=0x00e510de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Parallel ATA Controller' class = mass storage subclass = ATA atapci1@pci0:0:10:0: class=0x010185 card=0x00e31849 chip=0x00e310de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Serial ATA Controller' class = mass storage subclass = ATA pcib1@pci0:0:11:0: class=0x060400 card=0x00000000 chip=0x00e210de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce3 250 AGP Host to PCI Bridge' <===== class = bridge subclass = PCI-PCI pcib2@pci0:0:14:0: class=0x060400 card=0x00000000 chip=0x00ed10de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce3 250 PCI-PCI Bridge' <===== class = bridge subclass = PCI-PCI hostb1@pci0:0:16:0: class=0x060000 card=0x00000000 chip=0x169510b9 rev=0x00 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi/ULi)' device = 'ULi M1695 K8 Northbridge with PCIe and hypertransport' class = bridge subclass = HOST-PCI pcib3@pci0:0:17:0: class=0x060400 card=0x00000000 chip=0x524b10b9 rev=0x00 hdr=0x01 vendor = 'Acer Labs Incorporated (ALi/ULi)' device = 'ALi PCIe Bridge' class = bridge subclass = PCI-PCI pcib4@pci0:0:18:0: class=0x060400 card=0x00000000 chip=0x524c10b9 rev=0x00 hdr=0x01 vendor = 'Acer Labs Incorporated (ALi/ULi)' device = 'ALi PCIe Bridge' class = bridge subclass = PCI-PCI pcib5@pci0:0:19:0: class=0x060400 card=0x00000000 chip=0x524d10b9 rev=0x00 hdr=0x01 vendor = 'Acer Labs Incorporated (ALi/ULi)' class = bridge subclass = PCI-PCI hostb2@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron Address Map' class = bridge subclass = HOST-PCI hostb4@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron DRAM Controller' class = bridge subclass = HOST-PCI hostb5@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron Miscellaneous Control' class = bridge subclass = HOST-PCI hostb6@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron Link Control' class = bridge subclass = HOST-PCI vgapci0@pci0:4:0:0: class=0x030000 card=0x0f84102b chip=0x2527102b rev=0x01 hdr=0x00 vendor = 'Matrox Electronic Systems Ltd.' device = 'MGA-G550 AGP Chipset' <===== class = display subclass = VGA atapci2@pci0:1:0:0: class=0x010185 card=0x23631849 chip=0x2363197b rev=0x03 hdr=0x00 vendor = 'JMicron Technology Corp' device = 'JMB36X PCIe-to-SATA-300/IDE RAID Controller' class = mass storage subclass = ATA re0@pci0:2:0:0: class=0x020000 card=0x81681849 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 09:27:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CB38106564A; Fri, 9 Jan 2009 09:27:31 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.131.111.2]) by mx1.freebsd.org (Postfix) with ESMTP id CB6038FC14; Fri, 9 Jan 2009 09:27:30 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from acrux.dbai.tuwien.ac.at (acrux [128.131.111.60]) by vexpert.dbai.tuwien.ac.at (Postfix) with ESMTP id 94FF13910A; Fri, 9 Jan 2009 10:27:28 +0100 (CET) Received: by acrux.dbai.tuwien.ac.at (Postfix, from userid 1203) id 09C5C10059; Fri, 9 Jan 2009 10:27:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by acrux.dbai.tuwien.ac.at (Postfix) with ESMTP id EB7F310054; Fri, 9 Jan 2009 10:27:29 +0100 (CET) Date: Fri, 9 Jan 2009 10:27:29 +0100 (CET) From: Gerald Pfeifer To: "Li, Qing" In-Reply-To: Message-ID: References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> User-Agent: Alpine 1.99 (LSU 1142 2008-08-13) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 09 Jan 2009 12:27:38 +0000 Cc: Tijl Coosemans , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Qing Li Subject: RE: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 09:27:31 -0000 On Tue, 30 Dec 2008, Li, Qing wrote: > I don't think we can provide binary compatibility without putting > back RTF_LLINFO exactly as it was. My preference is to continue down > the new path without RTF_LLINFO. So, you are saying that applications built on FreeBSD 7 or earlier that use RTF_LLINFO will no longer work properly on FreeBSD 8 after your change? Ignoring everything else, that would be a killer and the one reason to definitely change the current situation. Otherwise, ISVs will need two builds, one for FreeBSD 7 and earlier and one for FreeBSD 8, and believe me, that is bad, bad, bad. Or rather: unlikely. (GNU/Linux distributions do provide this level of compatibility.) > We still have some time before the 8.0 release. It's straightforward > for me to retain some of the RTF_LLINFO support in the new kernel if > and when the situation becomes necessary. Sounds like that is the case? > Since the affected ports now have the conditional code around > RTF_LLINFO, the updates would allow these ports to compile in > both -current and in the previous releases. emulators/wine still is broken, and upstream Wine has not accepted the patch yet. I believe one reason likely is the above, and the fact that this may break commercial builds of Wine. How are you going to address this? Gerald -- Gerald (Jerry) Pfeifer gerald@pfeifer.com http://www.pfeifer.com/gerald/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 10:39:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8389106566C for ; Fri, 9 Jan 2009 10:39:07 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with ESMTP id A37C08FC18 for ; Fri, 9 Jan 2009 10:39:07 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from [192.168.4.8] (varnish.stillbilde.net [192.168.4.8]) (Authenticated sender: svein) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id ABD1A3A for ; Fri, 9 Jan 2009 10:22:23 +0000 (UTC) Message-ID: <4967259C.9090408@stillbilde.net> Date: Fri, 09 Jan 2009 11:23:24 +0100 From: "Svein Skogen (List Mail Account)" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49668763.8020705@mail.zedat.fu-berlin.de> <49671748.3030709@gmx.de> In-Reply-To: <49671748.3030709@gmx.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Jan 2009 12:27:52 +0000 Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 10:39:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph Mallon wrote: > O. Hartmann schrieb: >> When will gcc 4.3 incorporated in FreeBSD 8 and become the standard >> compiler suite? We figured out that gcc 4.3 does have a speed gain in >> some numerical code of 3 - 8 % and I guess we can use this in the basic >> OS as well ... > > Number crunching has a totally different execution profile than basic > operating system services. Gains in one area cannot simply be > transferred to the other. Would it be possible, as a "workaround" to have "system-CC" and "ports-CC" defined in make.conf, making one CC the compiler for /usr/src and another for ports, or would this just create debugging nightmares? //Svein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklnJZwACgkQtVbTV+BEzaPDQACgqOavzljEEcRFsI4tsQXxIuhr ZDMAoJwjZI26U0wEMtdbRgVWMvOkkBgY =NDwj -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 13:12:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64C4F1065670 for ; Fri, 9 Jan 2009 13:12:01 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id E42208FC17 for ; Fri, 9 Jan 2009 13:12:00 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so26829ugs.39 for ; Fri, 09 Jan 2009 05:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=MmqCj3WCrM6pzqQ5Xp5nD8DGa7wn4BlcMH+XxifKii4=; b=M/0MGkf1XdeIiFFKEe9oPZSLbTppDCTajEAba5Kw5LWHdo1Jw2cMIk8yAcij+j9Ev9 PIH5ieQF7eX4iL9/Kb2nBCsZSFqKxGf/ucxMy+0xjYXl8xoBafqwNJPwgGLUBVGfdZxU Qw1vdB4rgkE6zSXOI7kLmYQtits5sbT5Dyfmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=PNstuRNLqtpsc3hv9B13nyqstPPFrwPSeTi21fJtArdFAeFx+l9HtzA/fsuhLhivUP vI6vkaOhWW2X5BsOhu3G53B5vp4w3TDVBjz5D4heNRXzuAbVDVc796q2cPucb/eXISYW VVXS1004WLqWFckp2Powzgs79k4wnfPTA/nO4= Received: by 10.67.91.8 with SMTP id t8mr2610343ugl.41.1231506719893; Fri, 09 Jan 2009 05:11:59 -0800 (PST) Received: by 10.67.88.9 with HTTP; Fri, 9 Jan 2009 05:11:59 -0800 (PST) Message-ID: <7d6fde3d0901090511x21f9109ei527a1998c0f05bf8@mail.gmail.com> Date: Fri, 9 Jan 2009 05:11:59 -0800 From: "Garrett Cooper" To: "Svein Skogen (List Mail Account)" In-Reply-To: <4967259C.9090408@stillbilde.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49668763.8020705@mail.zedat.fu-berlin.de> <49671748.3030709@gmx.de> <4967259C.9090408@stillbilde.net> Cc: freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 13:12:01 -0000 On Fri, Jan 9, 2009 at 2:23 AM, Svein Skogen (List Mail Account) wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Christoph Mallon wrote: >> O. Hartmann schrieb: >>> When will gcc 4.3 incorporated in FreeBSD 8 and become the standard >>> compiler suite? We figured out that gcc 4.3 does have a speed gain in >>> some numerical code of 3 - 8 % and I guess we can use this in the basic >>> OS as well ... >> >> Number crunching has a totally different execution profile than basic >> operating system services. Gains in one area cannot simply be >> transferred to the other. > > Would it be possible, as a "workaround" to have "system-CC" and > "ports-CC" defined in make.conf, making one CC the compiler for /usr/src > and another for ports, or would this just create debugging nightmares? > > //Svein If setup properly, something similar to what Gentoo Linux for profiled compilers would be a very nice thing to have for `muxing' between development tools. It would just make upgrades potentially more painful though, and it would make tracking viral license tainting more difficult for folks who are on the receiving end, or ones that aren't paying attention to the licensing in the pieces of software they're distributing... The problem is that gcc is indeed lightyears ahead of any other [opensource] compiler available, and the fact that there are a number of bugs being filed against newer releases of gcc which don't translate back necessarily into our version, cleanly. Similarly, gdb has a lot of years of tread behind it as a debugger. If we were to drop either the compiler or the debugger (and I'm pretty sure we'd have to dump both if we dumped one), I believe that it would take another group of individuals an extensive period of time to get back to speed with what's available thanks to the GNU folks now... even if the GNU stuff in its current state is buggy. One thing I'm curious about though: for the bugs that do matter to us, if there is a patch, would the patch be considered GPLv2 or GPLv3 licensed code? Not a lawyer, and I don't expect a lawyer's PoV, but if the fix is truly trivial and it's compatible with the existing license, that would be cool to import I would think... Yes, we should really upgrade binutils though.. newer binutils would bring in a number of bugfixes as well as feature enhancements... Cheers, -Garrett PS Huzzah for R Stallman and his licensing crusade ;(... From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 13:18:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63602106566C; Fri, 9 Jan 2009 13:18:32 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id BD4808FC21; Fri, 9 Jan 2009 13:18:31 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so27319ugs.39 for ; Fri, 09 Jan 2009 05:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=abOLf/PSa1pe/oCcp8hfJEgXBijx+KirsslnKRthG0w=; b=ak5a+byls0Ji7urM9MjomhZP5nblXN65c2F56AWYJeu8+K9EKHZWOKEIuLyvvsrJcc ebKVNMNpK9k/kVmMs+YQmWouf6/JkvPQ71geqNwzTljtMeLRdFa7KFRAfxzupevMO9NM VXS9QZxNpIFDlMvlojkEDrxHk5gonEV5PE2MA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=CJ8+XSwC9RxHVXbEOvQFGmkRKC+jBjvEG9HhiDlABUXZDFNVW5I1BdKG9MlcCraFDj sV7O5XtqAduM3bpq/k2Ocob048P3/YaNpiLzs2YWALRPKE0FKh5Lne59NFWXxf1/eHEk 8ECJ8LgtiFIg3vJD4bKVyT4qctLIWU3n8iLG0= Received: by 10.66.248.5 with SMTP id v5mr4209154ugh.4.1231507110677; Fri, 09 Jan 2009 05:18:30 -0800 (PST) Received: by 10.67.88.9 with HTTP; Fri, 9 Jan 2009 05:18:30 -0800 (PST) Message-ID: <7d6fde3d0901090518m6e214a7pfe4d38249daf445e@mail.gmail.com> Date: Fri, 9 Jan 2009 05:18:30 -0800 From: "Garrett Cooper" To: "Roman Divacky" In-Reply-To: <20090109083009.GA55615@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> <4966859E.7080301@mail.zedat.fu-berlin.de> <20090109083009.GA55615@freebsd.org> Cc: "O. Hartmann" , FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 13:18:32 -0000 On Fri, Jan 9, 2009 at 12:30 AM, Roman Divacky wrote: >> I have and I had the same in FreeBSD 7.0/7.1 and now with 8.0-CUR with >> both a NV8600GTS and an older NV6800GT. A very old NV6600 never showed >> up these lockings when I used that PCIe-Card with FreeBSD 7.0/7.1, but >> I'm not sure. The locks came spontanous, sometimes after heavy usage of >> 'mplayer', but sometimes instantanously after the destop showed up. >> >> On those boxes, there is no Linux emulation and no Linux BLOB (useless, >> due to 64 Bit). I swapped the 'nv' driver on all FreeBSD boxes with >> 'vesa', because there is another issue with sprites/graphics buffers >> many times reported using FireFox. >> >> When the display got locked, sometimes I had the chance opening a ssh >> session killing Xorg/xdm and restarting working, but by the end, that >> was when changing towards 8.0-CUR, this 'trick' didn't work anymore. On >> FBSD 7, Xorg was eating up 100% CPU time. > > exactly my situation. I noticed that when the machine stucks while starting > X I am sometimes (~ 60%) able to ctrl-alt-backspace and it after some minutes > kills the X (= some sort of livelock?), after that I can 100% start the X > successfully... Mine doesn't happen boot -- it happens with the screensaver. Interestingly enough though, it happens less when I use a single screensaver instead of 2 separate screensavers. I'm going to put it back to 2 separate random screensavers and see what happens... -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 13:18:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABD4F1065672; Fri, 9 Jan 2009 13:18:57 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 13CB28FC19; Fri, 9 Jan 2009 13:18:56 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so27319ugs.39 for ; Fri, 09 Jan 2009 05:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0O+GaEEQiwf4ePeNdXqW85iGn3C6kvMmK2vYfpJDOlo=; b=r/E5CyMnkMH88CyASZADFERBRnNVZ567I2RMwgpWHCdWToFIRpdkjBi9xmLd3m8rwN IE1v0VosC5oOqLM97jgw9Ss2mS9E8DhXCRLHusPeFvwcRw3YfrKiwayxBgUaM2JA377s lU/4EeuOpN5K8iMzfZtBwgBU7Zq5ZnBlSxdbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=gOUK6QTfsClOJ1zVvVcPU4atPivh5AMMLhmb442WN/U8Io/qfYGk7ClZr5eFQIkBr7 IoAG/HIsF7eNGcizqrHT4vSnTuQcUMs8JkZNm5BZJEmBJ+UAEnOk0Hkq38X6dJsv7e3A U6JcSaRWV1MriolpM0D9F5r/n294F48zLD4/A= Received: by 10.67.98.15 with SMTP id a15mr15008552ugm.86.1231507136739; Fri, 09 Jan 2009 05:18:56 -0800 (PST) Received: by 10.67.88.9 with HTTP; Fri, 9 Jan 2009 05:18:56 -0800 (PST) Message-ID: <7d6fde3d0901090518j26dccc51v3f7be8e46ce0af77@mail.gmail.com> Date: Fri, 9 Jan 2009 05:18:56 -0800 From: "Garrett Cooper" To: "Doug Barton" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> Cc: FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 13:18:57 -0000 On Fri, Jan 9, 2009 at 1:37 AM, Doug Barton wrote: > On Wed, 7 Jan 2009, Garrett Cooper wrote: > >> Hello folks, >> As many probably know, I recently installed FreeBSD 8-CURRENT on my >> desktop. > > Why would we know that? I mean good for you, but seriously ... :) > >> One of the things I'm noting is that when I use dual displays with >> the nvidia driver, and xscreensaver kicks in and keeps going for a >> period of time, the machine's X.org console eats up a core, and when I >> try and do anything like gdb Xorg, the system hangs, attempts to panic >> (I assume that's the case because I hear it beep and attempt to >> restart), then I have to give it a warm boot. truss(1)'ing Xorg showed >> that there were a lot of SIGALARM's being fired and masked. > > No solutions, but a few general comments. First, I know that the author of > xscreensaver has put a lot of work into dual head stuff, and also that it > creates a lot of problems, so you're not alone here. If you get any > conclusive evidence that xscreensaver is at fault you should contact him at > http://www.jwz.org/xscreensaver/bugs.html > > A few things you can try to narrow it down .... first try turning off the > xscreensaver daemon and just run one of the screensaver programs full screen > for a while to see if that causes the crash. It's also worth testing GL vs. > non-GL screensavers. I had a problem with GL stuff for a while that was > fixed by an nvidia driver update a few versions ago. > > You should probably also try running with just the nv driver and see if that > causes the same crash. > > Finally, you might try setting debug.debugger_on_panic=0 in /etc/sysctl.conf > if you don't have it already. That will cause panics to go directly to > dumping which is useful if you're in X. > > > hth, > > Doug Thanks for the tips Doug -- I'll give them a shot of course... -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 13:32:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75C31106566C for ; Fri, 9 Jan 2009 13:32:05 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id D0E588FC18 for ; Fri, 9 Jan 2009 13:32:04 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 09 Jan 2009 13:32:02 -0000 Received: from p54A3E499.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.228.153] by mail.gmx.net (mp006) with SMTP; 09 Jan 2009 14:32:02 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+xYIVlWTmxYEPLtU9nqpPFd9OfqiAscj02NN5f6E DkZspg4VYNvHq1 Message-ID: <496751D1.20605@gmx.de> Date: Fri, 09 Jan 2009 14:32:01 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Roman Divacky References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> In-Reply-To: <20090109110508.GA12123@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: Andrew Reilly , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 13:32:06 -0000 Roman Divacky schrieb: >> I'm not saying it's wrong to look for alternatives, but you cannot just >> change your system compiler like you change underwear. > > well... the first step is imho starting to compile world with C99... > that might reveal some bugs, note that as of a few months ago > 8-current compiles cleanly with C99, that does not mean that it's > working when you run those programs correctly :) One step in the right direction is embracing the nice features modern C offers you. For example declaring a variable right were you need it instead of dozens of lines away is one such nice thing which improves readability. Designated initializers improve readability, too. But I'm not exactly sure what you mean by "compile world with C99". C99 is pretty much backwards compatible to C89. >> PCC cannot seriously be considered. Its design is stuck in the >> seventies. From the point of view of compiler construction it is plain >> plain out of question. I especially was amused by the statement of the >> author who claimed PCC supports SSA - except for phi-functions. > > what's wrong with design stuck in 70's when it compiles the whole world/kernel? > > I would not use it for default compilation of releases but it might be > useful when you are developing - because of its fast compilation times If you want a real speed devil, try TCC. > btw.. are you sure the design is stuck in the 70's? the author claims > to have rewritten almost the whole thing. have you looked at the recent > code? It's still a simple tree based approach. From point of view of optimisations this often gets in the way. For example you need temporary variables as helper construct which just complicates things (yes, there are intermediate representations which do not have temporary variables at all). Much has happend in compiler land in the last 30 years. Now we have stuff like SSA and some are even doing code generation in this form. I can go into more details, but this is not the right place. > another question - how is libfirm/cparser? last time I tried it didnt > support much of the gcc options (-Wsomething -f-something etc.) so > it could not be used as a direct drop-in The next release will support several more switches for GCC compatibility. Here's the latest manpage: http://tron.homeunix.org/cparser.1 - you can view it with "nroff -man cparser.1". Switches like -Wl, and -Wp, are supported. Many bugs have been resolved. More warning options have been added - many similar to what GCC does, some doing a better job. We plan to make a new release Really Soon Now(TM). From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 13:47:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B846E106566C for ; Fri, 9 Jan 2009 13:47:43 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9138FC12 for ; Fri, 9 Jan 2009 13:47:42 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 7F4FD9CB170; Fri, 9 Jan 2009 14:47:32 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUSP3S2ANchJ; Fri, 9 Jan 2009 14:47:25 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id CA6229CB298; Fri, 9 Jan 2009 14:47:25 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n09DlPN7039631; Fri, 9 Jan 2009 14:47:25 +0100 (CET) (envelope-from rdivacky) Date: Fri, 9 Jan 2009 14:47:25 +0100 From: Roman Divacky To: Christoph Mallon Message-ID: <20090109134725.GA38233@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <496751D1.20605@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: Andrew Reilly , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 13:47:44 -0000 On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: > Roman Divacky schrieb: > >>I'm not saying it's wrong to look for alternatives, but you cannot just > >>change your system compiler like you change underwear. > > > >well... the first step is imho starting to compile world with C99... > >that might reveal some bugs, note that as of a few months ago > >8-current compiles cleanly with C99, that does not mean that it's > >working when you run those programs correctly :) > > One step in the right direction is embracing the nice features modern C > offers you. For example declaring a variable right were you need it > instead of dozens of lines away is one such nice thing which improves > readability. Designated initializers improve readability, too. > But I'm not exactly sure what you mean by "compile world with C99". C99 > is pretty much backwards compatible to C89. sorry for the bad wording - I meant to turn C99 compilation on default. We compile in gnu89 mode now. > >>PCC cannot seriously be considered. Its design is stuck in the > >>seventies. From the point of view of compiler construction it is plain > >>plain out of question. I especially was amused by the statement of the > >>author who claimed PCC supports SSA - except for phi-functions. > > > >what's wrong with design stuck in 70's when it compiles the whole > >world/kernel? > > > >I would not use it for default compilation of releases but it might be > >useful when you are developing - because of its fast compilation times > > If you want a real speed devil, try TCC. well.. tcc does not seem to be integrated by any *BSD while pcc has been adopted by netbsd and openbsd :) that shows it has something good (at least good promotion *grin*) > >btw.. are you sure the design is stuck in the 70's? the author claims > >to have rewritten almost the whole thing. have you looked at the recent > >code? > > It's still a simple tree based approach. From point of view of > optimisations this often gets in the way. For example you need temporary > variables as helper construct which just complicates things (yes, there > are intermediate representations which do not have temporary variables > at all). Much has happend in compiler land in the last 30 years. Now we > have stuff like SSA and some are even doing code generation in this > form. I can go into more details, but this is not the right place. ok.. I just wanted to be sure you looked at the new version. > >another question - how is libfirm/cparser? last time I tried it didnt > >support much of the gcc options (-Wsomething -f-something etc.) so > >it could not be used as a direct drop-in > > The next release will support several more switches for GCC > compatibility. Here's the latest manpage: > http://tron.homeunix.org/cparser.1 - you can view it with "nroff -man > cparser.1". Switches like -Wl, and -Wp, are supported. Many bugs have > been resolved. More warning options have been added - many similar to > what GCC does, some doing a better job. We plan to make a new release > Really Soon Now(TM). ok.. looking forward :) From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 14:09:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23091106564A; Fri, 9 Jan 2009 14:09:46 +0000 (UTC) (envelope-from estrabd@gmail.com) Received: from gate011.lsu.edu (gate011.ocs.lsu.edu [130.39.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id B343E8FC1A; Fri, 9 Jan 2009 14:09:45 +0000 (UTC) (envelope-from estrabd@gmail.com) Received: from bc3.lsu.edu ([130.39.195.165]) by gate011.lsu.edu (Lotus Domino Release 6.0.3) with ESMTP id 2009010907593235-219 ; Fri, 9 Jan 2009 07:59:32 -0600 Received: from bc3.lsu.edu (localhost [127.0.0.1]) by bc3.lsu.edu (8.14.3/8.14.2) with ESMTP id n09DqGig078796; Fri, 9 Jan 2009 07:52:16 -0600 (CST) (envelope-from estrabd@gmail.com) Received: (from estrabd@localhost) by bc3.lsu.edu (8.14.3/8.14.2/Submit) id n09DqGVG078795; Fri, 9 Jan 2009 07:52:16 -0600 (CST) (envelope-from estrabd@gmail.com) X-Authentication-Warning: bc3.lsu.edu: estrabd set sender to estrabd@gmail.com using -f Date: Fri, 9 Jan 2009 07:52:15 -0600 From: "B. Estrade" To: Roman Divacky Message-ID: <20090109135215.GI1020@bc3.lsu.edu> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> Mime-Version: 1.0 In-Reply-To: <20090109134725.GA38233@freebsd.org> User-Agent: Mutt/1.4.2.3i mailed-by: estrabd@lsu.edu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Andrew Reilly , Ollivier Robert , Christoph Mallon , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 14:09:46 -0000 On Fri, Jan 09, 2009 at 02:47:25PM +0100, Roman Divacky wrote: > On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: > > Roman Divacky schrieb: > > >>I'm not saying it's wrong to look for alternatives, but you cannot just > > >>change your system compiler like you change underwear. > > > > > >well... the first step is imho starting to compile world with C99... > > >that might reveal some bugs, note that as of a few months ago > > >8-current compiles cleanly with C99, that does not mean that it's > > >working when you run those programs correctly :) > > > > One step in the right direction is embracing the nice features modern C > > offers you. For example declaring a variable right were you need it > > instead of dozens of lines away is one such nice thing which improves > > readability. Designated initializers improve readability, too. > > But I'm not exactly sure what you mean by "compile world with C99". C99 > > is pretty much backwards compatible to C89. > > sorry for the bad wording - I meant to turn C99 compilation on default. > We compile in gnu89 mode now. This is slightly off topic, but how important might it be wrt SMP progress for there to be OpenMP support in the C compiler? I am not suggesting this be part of any FreeBSD code, but I find having OpenMP support in the base compiler very appealing for many reasons - one of which is SMP benchmarking/testing. I ask because while shared memory executables produced by 4.2.1 are not the fastest (when using OpenMP), the directives are at least mostly supported. And I suppose that the later version of gcc will only get better. On the otherhand, other solutions don't seem to have this support whatsoever - so I ask again, how important might this kind of support be when considering /which/ compiler to use? Thank you, Brett > > > >>PCC cannot seriously be considered. Its design is stuck in the > > >>seventies. From the point of view of compiler construction it is plain > > >>plain out of question. I especially was amused by the statement of the > > >>author who claimed PCC supports SSA - except for phi-functions. > > > > > >what's wrong with design stuck in 70's when it compiles the whole > > >world/kernel? > > > > > >I would not use it for default compilation of releases but it might be > > >useful when you are developing - because of its fast compilation times > > > > If you want a real speed devil, try TCC. > > well.. tcc does not seem to be integrated by any *BSD while pcc has been > adopted by netbsd and openbsd :) that shows it has something good (at least > good promotion *grin*) > > > >btw.. are you sure the design is stuck in the 70's? the author claims > > >to have rewritten almost the whole thing. have you looked at the recent > > >code? > > > > It's still a simple tree based approach. From point of view of > > optimisations this often gets in the way. For example you need temporary > > variables as helper construct which just complicates things (yes, there > > are intermediate representations which do not have temporary variables > > at all). Much has happend in compiler land in the last 30 years. Now we > > have stuff like SSA and some are even doing code generation in this > > form. I can go into more details, but this is not the right place. > > ok.. I just wanted to be sure you looked at the new version. > > > >another question - how is libfirm/cparser? last time I tried it didnt > > >support much of the gcc options (-Wsomething -f-something etc.) so > > >it could not be used as a direct drop-in > > > > The next release will support several more switches for GCC > > compatibility. Here's the latest manpage: > > http://tron.homeunix.org/cparser.1 - you can view it with "nroff -man > > cparser.1". Switches like -Wl, and -Wp, are supported. Many bugs have > > been resolved. More warning options have been added - many similar to > > what GCC does, some doing a better job. We plan to make a new release > > Really Soon Now(TM). > > ok.. looking forward :) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- B. Estrade Louisiana Optical Network Initiative +1.225.578.1920 aim: bz743 :wq From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 14:12:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49A9510656F3 for ; Fri, 9 Jan 2009 14:12:14 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id CF77E8FC14 for ; Fri, 9 Jan 2009 14:12:13 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.37,239,1231110000"; d="scan'208";a="266665045" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 09 Jan 2009 15:12:11 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 9C43F1B074C; Fri, 9 Jan 2009 15:12:11 +0100 (CET) Date: Fri, 09 Jan 2009 15:12:10 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Carlos A. M. dos Santos" Subject: Re: patch to fix burncd bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 14:12:14 -0000 the actual problem is that the return value EBUSY got overwritten in sys/dev/ata/ata-queue.c. so even when the device returns EBUSY the ioctl call returned EIO. what your patch does is to wait for a specific time until it gives up calling ioctl(fd, CDIOCEJECT). with the changes to sys/dev/ata/atapi-cd.c the EBUSY return value doesn't get overwritten anymore. now when an ioctl call returns EIO you don't have to repeat doing the ioctl. EIO really means EIO! only if the return value is EBUSY you have to repeat doing an ioctl until it returns != EBUSY. alex Carlos A. M. dos Santos schrieb am 2009-01-09: > On Thu, Jan 8, 2009 at 8:59 PM, Giorgos Keramidas > wrote: > > On Thu, 08 Jan 2009 18:13:14 +0100 (CET), Alexander Best > > wrote: > >> could somebody please commit the following patch to dev/ata? it > >> fixes > >> a nasty bug during fixation in burncd. the bug exists in RELENG6, > >> RELENG7 and HEAD (and maybe RELENG5): > >> http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch > >> the whole PR can be found here: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 > > I think Soren is the best person to look into this bug (Cc: added). > > Soren, what do you think? Does the patch at bin/95979 look like a > > nice > > change to commit? I just saw this PR so I haven't tried the patch > > on my > > laptop's CURRENT yet, but I can confirm that burning CD-ROMs and > > DVDs is > > busted in my laptop for a few weeks now. > I proposed a solution a similar problem (bin/123693), but patching > burncd instead of the kernel. I'm attaching the patch, for your > convenience. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 14:12:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3616E1065894; Fri, 9 Jan 2009 14:12:35 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swip.net [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 926508FC17; Fri, 9 Jan 2009 14:12:34 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nklthdr5v5AUSfVrlghuJA==:17 a=0xUp2HoiObph-xRNSUwA:9 a=1x0DzkLnImVnU2QREzsJvpfy_T0A:4 a=9aOQ2cSd83gA:10 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 435156236; Fri, 09 Jan 2009 15:12:32 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 9 Jan 2009 15:14:53 +0100 User-Agent: KMail/1.9.7 References: <21013.1231501594@critter.freebsd.dk> In-Reply-To: <21013.1231501594@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901091514.55076.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 14:12:36 -0000 On Friday 09 January 2009, Poul-Henning Kamp wrote: > In message <200901091243.40981.hselasky@c2i.net>, Hans Petter Selasky writes: > >Which serial driver are you using? U3G? > > > >Are you using the latest code from -current ? > > I just compiled a USB2 kernel from yesterdays -current while sitting > in the train. Try connecting your device through an external USB HUB. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 14:12:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3616E1065894; Fri, 9 Jan 2009 14:12:35 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swip.net [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 926508FC17; Fri, 9 Jan 2009 14:12:34 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nklthdr5v5AUSfVrlghuJA==:17 a=0xUp2HoiObph-xRNSUwA:9 a=1x0DzkLnImVnU2QREzsJvpfy_T0A:4 a=9aOQ2cSd83gA:10 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 435156236; Fri, 09 Jan 2009 15:12:32 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 9 Jan 2009 15:14:53 +0100 User-Agent: KMail/1.9.7 References: <21013.1231501594@critter.freebsd.dk> In-Reply-To: <21013.1231501594@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901091514.55076.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 14:12:36 -0000 On Friday 09 January 2009, Poul-Henning Kamp wrote: > In message <200901091243.40981.hselasky@c2i.net>, Hans Petter Selasky writes: > >Which serial driver are you using? U3G? > > > >Are you using the latest code from -current ? > > I just compiled a USB2 kernel from yesterdays -current while sitting > in the train. Try connecting your device through an external USB HUB. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 14:28:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66020106566C for ; Fri, 9 Jan 2009 14:28:24 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id C12308FC14 for ; Fri, 9 Jan 2009 14:28:23 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 09 Jan 2009 14:28:21 -0000 Received: from p54A3E499.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.228.153] by mail.gmx.net (mp049) with SMTP; 09 Jan 2009 15:28:21 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19TVFYtaAJTXAV8i5uHzhcYuaYvar/d0muXW9cAYg FQt8WFX2zRfZgV Message-ID: <49675F04.20006@gmx.de> Date: Fri, 09 Jan 2009 15:28:20 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Roman Divacky References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> In-Reply-To: <20090109134725.GA38233@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Cc: Andrew Reilly , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 14:28:24 -0000 Roman Divacky schrieb: > On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: >> Roman Divacky schrieb: >>>> I'm not saying it's wrong to look for alternatives, but you cannot just >>>> change your system compiler like you change underwear. >>> well... the first step is imho starting to compile world with C99... >>> that might reveal some bugs, note that as of a few months ago >>> 8-current compiles cleanly with C99, that does not mean that it's >>> working when you run those programs correctly :) >> One step in the right direction is embracing the nice features modern C >> offers you. For example declaring a variable right were you need it >> instead of dozens of lines away is one such nice thing which improves >> readability. Designated initializers improve readability, too. >> But I'm not exactly sure what you mean by "compile world with C99". C99 >> is pretty much backwards compatible to C89. > > sorry for the bad wording - I meant to turn C99 compilation on default. > We compile in gnu89 mode now. I still have no idea what you mean. Sure, you can specify -std=c99 (or more likely gnu99), but an int is still an int - what do you expect? In fact default mode of GCC accepts many C99 constructs like // comments and mixed declarations and code, which are not valid C89. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 14:33:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB24F1065670 for ; Fri, 9 Jan 2009 14:33:52 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id A2BC58FC14 for ; Fri, 9 Jan 2009 14:33:52 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 8B46F9CB1A1; Fri, 9 Jan 2009 15:33:42 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsZSqzKfpML9; Fri, 9 Jan 2009 15:33:40 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 42A3F9CB298; Fri, 9 Jan 2009 15:33:40 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n09EXdsC046175; Fri, 9 Jan 2009 15:33:39 +0100 (CET) (envelope-from rdivacky) Date: Fri, 9 Jan 2009 15:33:39 +0100 From: Roman Divacky To: Christoph Mallon Message-ID: <20090109143339.GA45569@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49675F04.20006@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: Andrew Reilly , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 14:33:53 -0000 On Fri, Jan 09, 2009 at 03:28:20PM +0100, Christoph Mallon wrote: > Roman Divacky schrieb: > >On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: > >>Roman Divacky schrieb: > >>>>I'm not saying it's wrong to look for alternatives, but you cannot just > >>>>change your system compiler like you change underwear. > >>>well... the first step is imho starting to compile world with C99... > >>>that might reveal some bugs, note that as of a few months ago > >>>8-current compiles cleanly with C99, that does not mean that it's > >>>working when you run those programs correctly :) > >>One step in the right direction is embracing the nice features modern C > >>offers you. For example declaring a variable right were you need it > >>instead of dozens of lines away is one such nice thing which improves > >>readability. Designated initializers improve readability, too. > >>But I'm not exactly sure what you mean by "compile world with C99". C99 > >>is pretty much backwards compatible to C89. > > > >sorry for the bad wording - I meant to turn C99 compilation on default. > >We compile in gnu89 mode now. > > I still have no idea what you mean. Sure, you can specify -std=c99 (or > more likely gnu99), but an int is still an int - what do you expect? In > fact default mode of GCC accepts many C99 constructs like // comments > and mixed declarations and code, which are not valid C89. for example __restricted is C99 thing and there are others, I want this because clang for example defaults to C99 (in fact gnu99 as they support gnu extensions on default). By switching to default compilation in C99 mode we can be sure we stay compatible with clang and others.... for example opensolaris seems to use C99 features which are not enabled in our world because of this (I found same assert() related stuff) etc. plus other benefits of the newer languge standard From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 14:56:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE3A6106566B for ; Fri, 9 Jan 2009 14:56:28 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 058878FC1D for ; Fri, 9 Jan 2009 14:56:27 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 09 Jan 2009 14:56:26 -0000 Received: from p54A3E499.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.228.153] by mail.gmx.net (mp052) with SMTP; 09 Jan 2009 15:56:26 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/uX3cRwRXuFyV8RNkJ4GzSqwDvTQ/a5k1Qn9MMTN LyZCmvmHc+0oyN Message-ID: <49676598.7040708@gmx.de> Date: Fri, 09 Jan 2009 15:56:24 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Roman Divacky References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <20090109143339.GA45569@freebsd.org> In-Reply-To: <20090109143339.GA45569@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Cc: Andrew Reilly , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 14:56:29 -0000 Roman Divacky schrieb: > On Fri, Jan 09, 2009 at 03:28:20PM +0100, Christoph Mallon wrote: >> Roman Divacky schrieb: >>> On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: >>>> Roman Divacky schrieb: >>>>>> I'm not saying it's wrong to look for alternatives, but you cannot just >>>>>> change your system compiler like you change underwear. >>>>> well... the first step is imho starting to compile world with C99... >>>>> that might reveal some bugs, note that as of a few months ago >>>>> 8-current compiles cleanly with C99, that does not mean that it's >>>>> working when you run those programs correctly :) >>>> One step in the right direction is embracing the nice features modern C >>>> offers you. For example declaring a variable right were you need it >>>> instead of dozens of lines away is one such nice thing which improves >>>> readability. Designated initializers improve readability, too. >>>> But I'm not exactly sure what you mean by "compile world with C99". C99 >>>> is pretty much backwards compatible to C89. >>> sorry for the bad wording - I meant to turn C99 compilation on default. >>> We compile in gnu89 mode now. >> I still have no idea what you mean. Sure, you can specify -std=c99 (or >> more likely gnu99), but an int is still an int - what do you expect? In >> fact default mode of GCC accepts many C99 constructs like // comments >> and mixed declarations and code, which are not valid C89. > > for example __restricted is C99 thing and there are others, I want this __restrict (not __restricted) is a GCC extension. The C99 spelling is restrict. GCC also accepts __restrict__. Further, you should be *very* careful with the restrict qualifier, because its exact semantic is non-trivial (§6.7.3.1, it's one page of standardese speak). But I see no problem for existing code in this respect. C99 mostly only adds new language constructs. Only very few were removed. E.g. implicit int was removed, but GCC still accepts it (and I guess clang too, cpareser does). > because clang for example defaults to C99 (in fact gnu99 as they support > gnu extensions on default). By switching to default compilation in C99 > mode we can be sure we stay compatible with clang and others.... I'm pretty sure clang also accepts __restrict. A compiler, which does not support most GCC extensions (inline assembler being the most important) has no chance anyway. > for example opensolaris seems to use C99 features which are not enabled > in our world because of this (I found same assert() related stuff) etc. assert() predates C99. The only C99 specific aspect about assert(), that I'm aware of, is, that C99 guarantees that the name of the function is printed. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 15:08:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 340361065693 for ; Fri, 9 Jan 2009 15:08:14 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id B50DB8FC12 for ; Fri, 9 Jan 2009 15:08:13 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id DDDD69CB170; Fri, 9 Jan 2009 16:08:02 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVKWx-1vy9oi; Fri, 9 Jan 2009 16:07:51 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 00EFD9CB298; Fri, 9 Jan 2009 16:07:50 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n09F7oBm050803; Fri, 9 Jan 2009 16:07:50 +0100 (CET) (envelope-from rdivacky) Date: Fri, 9 Jan 2009 16:07:50 +0100 From: Roman Divacky To: Christoph Mallon Message-ID: <20090109150750.GA50331@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <20090109143339.GA45569@freebsd.org> <49676598.7040708@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49676598.7040708@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: Andrew Reilly , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 15:08:14 -0000 On Fri, Jan 09, 2009 at 03:56:24PM +0100, Christoph Mallon wrote: > Roman Divacky schrieb: > >On Fri, Jan 09, 2009 at 03:28:20PM +0100, Christoph Mallon wrote: > >>Roman Divacky schrieb: > >>>On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: > >>>>Roman Divacky schrieb: > >>>>>>I'm not saying it's wrong to look for alternatives, but you cannot > >>>>>>just change your system compiler like you change underwear. > >>>>>well... the first step is imho starting to compile world with C99... > >>>>>that might reveal some bugs, note that as of a few months ago > >>>>>8-current compiles cleanly with C99, that does not mean that it's > >>>>>working when you run those programs correctly :) > >>>>One step in the right direction is embracing the nice features modern C > >>>>offers you. For example declaring a variable right were you need it > >>>>instead of dozens of lines away is one such nice thing which improves > >>>>readability. Designated initializers improve readability, too. > >>>>But I'm not exactly sure what you mean by "compile world with C99". C99 > >>>>is pretty much backwards compatible to C89. > >>>sorry for the bad wording - I meant to turn C99 compilation on default. > >>>We compile in gnu89 mode now. > >>I still have no idea what you mean. Sure, you can specify -std=c99 (or > >>more likely gnu99), but an int is still an int - what do you expect? In > >>fact default mode of GCC accepts many C99 constructs like // comments > >>and mixed declarations and code, which are not valid C89. > > > >for example __restricted is C99 thing and there are others, I want this > > __restrict (not __restricted) is a GCC extension. The C99 spelling is > restrict. GCC also accepts __restrict__. Further, you should be *very* > careful with the restrict qualifier, because its exact semantic is > non-trivial (?6.7.3.1, it's one page of standardese speak). > But I see no problem for existing code in this respect. C99 mostly only > adds new language constructs. Only very few were removed. E.g. implicit > int was removed, but GCC still accepts it (and I guess clang too, > cpareser does). my point is that in C89 mode *restrict* (in whatever spelling) got expanded to nothing. we had a bug (typo in fact) related to *restrict* and we didnt catch it because of C89 compilation mode... thats my point (and the *restrict* thing is just an example) > >because clang for example defaults to C99 (in fact gnu99 as they support > >gnu extensions on default). By switching to default compilation in C99 > > >mode we can be sure we stay compatible with clang and others.... > > I'm pretty sure clang also accepts __restrict. > A compiler, which does not support most GCC extensions (inline assembler > being the most important) has no chance anyway. yes.... the problem is (was?) that clang is C99 on default while gcc is C89 on default. > >for example opensolaris seems to use C99 features which are not enabled > >in our world because of this (I found same assert() related stuff) etc. > > assert() predates C99. The only C99 specific aspect about assert(), that > I'm aware of, is, that C99 guarantees that the name of the function is > printed. they had code like #if C99 #define __assert(..) something #else #define __assert(..) something_else #endif my point is that we might have bugs in the C99 code that other (non-gcc) compilers expose and it's a good thing to unite on one standard. ie. C99 :) From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 15:11:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 674DB10656F3 for ; Fri, 9 Jan 2009 15:11:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 46B948FC12 for ; Fri, 9 Jan 2009 15:11:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n09FBNho098118; Fri, 9 Jan 2009 07:11:23 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n09FBN8p098117; Fri, 9 Jan 2009 07:11:23 -0800 (PST) (envelope-from sgk) Date: Fri, 9 Jan 2009 07:11:23 -0800 From: Steve Kargl To: Ollivier Robert Message-ID: <20090109151123.GA97988@troutmask.apl.washington.edu> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090109002133.GA92874@troutmask.apl.washington.edu> <20090109084908.GA76970@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090109084908.GA76970@keltia.freenix.fr> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 15:11:25 -0000 On Fri, Jan 09, 2009 at 09:49:11AM +0100, Ollivier Robert wrote: > According to Steve Kargl: > > Probably not for a very long time. gcc 4.3 requires both GMP and > > MPFR libraries. Neither library is in src. > > I do not know what MPFR is (something about FP, right?) but I wonder at why > GMP could be needed by a compiler... > http://www.mpfr.org/ The MPFR library is a C library for multiple-precision floating-point computations with correct rounding. It's used for constant folding. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 15:27:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D247106566B; Fri, 9 Jan 2009 15:27:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DE5D78FC16; Fri, 9 Jan 2009 15:27:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 807BC46B32; Fri, 9 Jan 2009 10:27:11 -0500 (EST) Date: Fri, 9 Jan 2009 15:27:11 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tim Kientzle In-Reply-To: <4965927D.1060507@freebsd.org> Message-ID: References: <4965927D.1060507@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "'freebsd-current@freebsd.org'" Subject: Re: Extattr portability? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 15:27:12 -0000 On Wed, 7 Jan 2009, Tim Kientzle wrote: > I'm trying to complete the extended attribute support in libarchive. There > are a handful of odd issues that arise which I think I could resolve if I > knew of good use cases. > > Anyone here actually use extended attributes? (Note that ACLs are handled > separately.) What software? What information do you store there? > > If you could benefit from being able to move extended attributes between > FreeBSD and other systems, I'm especially interested. Most (all) of the use of extended attributes that I'm aware of on FreeBSD relates to security extensions, be it ACLs, MAC labels (almost always in the system namespace) for various policies, etc. Mac OS X is now using extended attributes in quite a few more ways, however, so you may want to investigate a bit on that side. Most uses I'm aware of aren't intended to be portable. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 15:53:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BBFF106567A for ; Fri, 9 Jan 2009 15:53:13 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DD49E8FC29 for ; Fri, 9 Jan 2009 15:53:11 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 09 Jan 2009 15:53:10 -0000 Received: from p54A3E499.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.228.153] by mail.gmx.net (mp071) with SMTP; 09 Jan 2009 16:53:10 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/X0y8ffUzXn+JRZ0DRHkWp+uJdJXFztCxrOVOvfx HgWQeaL5vSAupf Message-ID: <496772E1.2050504@gmx.de> Date: Fri, 09 Jan 2009 16:53:05 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Roman Divacky References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <20090109143339.GA45569@freebsd.org> <49676598.7040708@gmx.de> <20090109150750.GA50331@freebsd.org> In-Reply-To: <20090109150750.GA50331@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: Andrew Reilly , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 15:53:13 -0000 Roman Divacky schrieb: > On Fri, Jan 09, 2009 at 03:56:24PM +0100, Christoph Mallon wrote: >> Roman Divacky schrieb: >>> On Fri, Jan 09, 2009 at 03:28:20PM +0100, Christoph Mallon wrote: >>>> Roman Divacky schrieb: >>>>> On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: >>>>>> Roman Divacky schrieb: >>>>>>>> I'm not saying it's wrong to look for alternatives, but you cannot >>>>>>>> just change your system compiler like you change underwear. >>>>>>> well... the first step is imho starting to compile world with C99... >>>>>>> that might reveal some bugs, note that as of a few months ago >>>>>>> 8-current compiles cleanly with C99, that does not mean that it's >>>>>>> working when you run those programs correctly :) >>>>>> One step in the right direction is embracing the nice features modern C >>>>>> offers you. For example declaring a variable right were you need it >>>>>> instead of dozens of lines away is one such nice thing which improves >>>>>> readability. Designated initializers improve readability, too. >>>>>> But I'm not exactly sure what you mean by "compile world with C99". C99 >>>>>> is pretty much backwards compatible to C89. >>>>> sorry for the bad wording - I meant to turn C99 compilation on default. >>>>> We compile in gnu89 mode now. >>>> I still have no idea what you mean. Sure, you can specify -std=c99 (or >>>> more likely gnu99), but an int is still an int - what do you expect? In >>>> fact default mode of GCC accepts many C99 constructs like // comments >>>> and mixed declarations and code, which are not valid C89. >>> for example __restricted is C99 thing and there are others, I want this >> __restrict (not __restricted) is a GCC extension. The C99 spelling is >> restrict. GCC also accepts __restrict__. Further, you should be *very* >> careful with the restrict qualifier, because its exact semantic is >> non-trivial (?6.7.3.1, it's one page of standardese speak). >> But I see no problem for existing code in this respect. C99 mostly only >> adds new language constructs. Only very few were removed. E.g. implicit >> int was removed, but GCC still accepts it (and I guess clang too, >> cpareser does). > > my point is that in C89 mode *restrict* (in whatever spelling) got expanded > to nothing. we had a bug (typo in fact) related to *restrict* and we didnt > catch it because of C89 compilation mode... Ah, you mean a simple syntax error like char __restrict* a instead of char* __restrict a. I thought you meant something serious like different behaviour between the standards. Why somebody would #define away __restrict (or #define away any other extension, which GCC accepts anyway) is beyond me. If the source code already contains distinctions between C89 and C99 then, imo, somebody did something wrong. > thats my point (and the *restrict* thing is just an example) > >>> because clang for example defaults to C99 (in fact gnu99 as they support >>> gnu extensions on default). By switching to default compilation in C99 >>> mode we can be sure we stay compatible with clang and others.... >> I'm pretty sure clang also accepts __restrict. >> A compiler, which does not support most GCC extensions (inline assembler >> being the most important) has no chance anyway. > > yes.... the problem is (was?) that clang is C99 on default while gcc is C89 > on default. > >>> for example opensolaris seems to use C99 features which are not enabled >>> in our world because of this (I found same assert() related stuff) etc. >> assert() predates C99. The only C99 specific aspect about assert(), that >> I'm aware of, is, that C99 guarantees that the name of the function is >> printed. > > they had code like > > > #if C99 > #define __assert(..) something > #else > #define __assert(..) something_else > #endif > This is probably, as mentioned above, because C89 does not have __func__. > my point is that we might have bugs in the C99 code that other (non-gcc) compilers > expose and it's a good thing to unite on one standard. ie. C99 :) In general I agree: C99 should be used as language standard for compilation. style(9) needs some updates for this, too. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 17:28:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 671D9106568F for ; Fri, 9 Jan 2009 17:28:15 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4938FC0A for ; Fri, 9 Jan 2009 17:28:14 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id DFD1C9CB170; Fri, 9 Jan 2009 18:28:02 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNdBQuhYMjt8; Fri, 9 Jan 2009 18:27:47 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id C506E9CB298; Fri, 9 Jan 2009 18:27:47 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n09HRl2v069611; Fri, 9 Jan 2009 18:27:47 +0100 (CET) (envelope-from rdivacky) Date: Fri, 9 Jan 2009 18:27:47 +0100 From: Roman Divacky To: Christoph Mallon Message-ID: <20090109172747.GA69471@freebsd.org> References: <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <20090109143339.GA45569@freebsd.org> <49676598.7040708@gmx.de> <20090109150750.GA50331@freebsd.org> <496772E1.2050504@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <496772E1.2050504@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: Andrew Reilly , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 17:28:15 -0000 > >my point is that in C89 mode *restrict* (in whatever spelling) got expanded > >to nothing. we had a bug (typo in fact) related to *restrict* and we didnt > >catch it because of C89 compilation mode... > > Ah, you mean a simple syntax error like char __restrict* a instead of > char* __restrict a. I thought you meant something serious like different > behaviour between the standards. Why somebody would #define away > __restrict (or #define away any other extension, which GCC accepts > anyway) is beyond me. If the source code already contains distinctions > between C89 and C99 then, imo, somebody did something wrong. my point was general - people expect C99 features and use them (it's 10 years old) but we dont compile in that mode - this mismatch may yield weird bugs > >my point is that we might have bugs in the C99 code that other (non-gcc) > >compilers > >expose and it's a good thing to unite on one standard. ie. C99 :) > > In general I agree: C99 should be used as language standard for > compilation. style(9) needs some updates for this, too. I hope we'll have C99 on default soon :) From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 19:59:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3FEA106566C; Fri, 9 Jan 2009 19:59:36 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 929068FC1B; Fri, 9 Jan 2009 19:59:36 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id E0714202CB9; Fri, 9 Jan 2009 14:59:35 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 09 Jan 2009 14:59:35 -0500 X-Sasl-enc: XYu0vKKq0mcv/M8jY01pTgWfONsqV96R9JRsGBaQX4Y4 1231531175 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id D66D62A0A0; Fri, 9 Jan 2009 14:59:34 -0500 (EST) Message-ID: <4967ACA5.6080502@incunabulum.net> Date: Fri, 09 Jan 2009 19:59:33 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Gerald Pfeifer References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tijl Coosemans , "Li, Qing" , freebsd-current@freebsd.org, Qing Li , freebsd-net@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 19:59:37 -0000 +1 for introducing RTF_LLINFO backwards compatibility. I had to sneak in a fix to XORP and pretty much broke release protocol to do so. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 20:43:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 757E710657F5 for ; Fri, 9 Jan 2009 20:43:39 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id 422DF8FC1E for ; Fri, 9 Jan 2009 20:43:38 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so10984951rvf.43 for ; Fri, 09 Jan 2009 12:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=mmWClVzD9D+m5nd3ZKUTc+x3l/uFzSkbcwfrUk79Adw=; b=u8qRBxrzgwyilRKQTNdz43Bg/yty4X4nbLK8+8LjHCqRXPMm1BY3m6MK5pqrDWaNmA RRmVtDTJ70JIITsRmSBCzQ09z4qCOaHz+CNtnuSrZaxfhWIlu/NNeMTIOrPZrx7IGAp8 dkG+fM2KmTQEaqwubWQZmrSe9ik93t055icyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=cqa9NQZgINQuJ0kFKDJvXirEaLR5yByO94i5G3VvRJkrir5MUxk7E6/CDACDjrG1kQ svgUOJCnbaoKc80KMlQ1lvvZc7GXEh9kt1N9c4zlGw2ioYcWIOf/jte2bCFhTrXUl1lB PSaIf724o3HL0wkD1d9XbJ9fjqWT+auSl3n5c= Received: by 10.142.132.2 with SMTP id f2mr10874941wfd.168.1231533818561; Fri, 09 Jan 2009 12:43:38 -0800 (PST) Received: by 10.142.142.10 with HTTP; Fri, 9 Jan 2009 12:43:38 -0800 (PST) Message-ID: <89dbfdc30901091243w1d01ab59mc2ade81e65e51c5d@mail.gmail.com> Date: Fri, 9 Jan 2009 15:43:38 -0500 From: "Kim Culhan" To: pyunyh@gmail.com In-Reply-To: <20090109061032.GF30747@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> <20090109061032.GF30747@cdnetworks.co.kr> Cc: freebsd-current@freebsd.org Subject: Re: msk Marvell Yukon 88E8038 hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 20:43:41 -0000 On Fri, Jan 9, 2009 at 1:10 AM, Pyun YongHyeon wrote: > On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote: > > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > > > On Thu, Jan 08, 2009 at 02:36:48AM -0500, Kim Culhan wrote: > > > > On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > > > > > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > > > > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > > > > > > > > > Not necessarily at each hang but sometimes coincident, this is > > > > > > intermittently output to the console: > > > > > > > > > > > > in_cksum_skip: out of data by 56952 > > > > > > > > > > > > The above is also output to the console at times when receiving a > > > > > > character through ssh > > > > > > to a shell. > > > > > > > > > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > > > > > running 7.1-RELEASE. [deleted] > Ok, then how about disabling TSO/Tx checksum offload? > (eg. ifconfig msk0 -tso -txcsum) This stops the messages: in_cksum_skip: out of data by 56952 -kim From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 20:58:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 098EE1065677 for ; Fri, 9 Jan 2009 20:58:11 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from cpsmtpo-eml01.kpnxchange.com (cpsmtpo-eml01.KPNXCHANGE.COM [213.75.38.150]) by mx1.freebsd.org (Postfix) with ESMTP id 917348FC08 for ; Fri, 9 Jan 2009 20:58:10 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from cpsmtp-eml109.kpnxchange.com ([213.75.84.109]) by cpsmtpo-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 21:46:06 +0100 Received: from uitsmijter.van-laarhoven.org ([81.207.207.222]) by cpsmtp-eml109.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 21:46:05 +0100 Received: from van-laarhoven.org (dhcp-10-251-2-198.awservice [10.251.2.198]) by uitsmijter.van-laarhoven.org (8.14.3/8.14.3) with SMTP id n09KkYol063053 for ; Fri, 9 Jan 2009 21:46:34 +0100 (CET) (envelope-from nick@van-laarhoven.org) Received: (nullmailer pid 6165 invoked by uid 1001); Fri, 09 Jan 2009 20:46:01 -0000 From: Nick Hibma To: freebsd-current@freebsd.org Date: Fri, 9 Jan 2009 21:46:00 +0100 User-Agent: KMail/1.9.10 References: <3994.1231494833@critter.freebsd.dk> In-Reply-To: <3994.1231494833@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901092146.01009.nick@van-laarhoven.org> X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, J_CHICKENPOX_35 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on uitsmijter.van-laarhoven.org X-OriginalArrivalTime: 09 Jan 2009 20:46:06.0023 (UTC) FILETIME=[4AFAFD70:01C9729B] Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 20:58:11 -0000 Poul-Henning, I have had many reports of devices working. I've also had several people report that the device failed miserably with similar problems like you are perceiving. I am talking oldusb here, as that is what I am familiar with. I've not been able to reproduce the problems reliably. But looking at the symptoms somehow buffering goes pear-shaped somewhere. There is no buffering being done in the u3g code.That's all handled by ucom, but to me that looks like cut&paste from other code. So I presume (wildly pointing fingers at code I do not yet understand) that the problem is somewhere in the combination of ucom and tty layer, or perhaps even in the TTY layer. Perhaps you have a clue as to where in the TTY layer we could look for problems? The usage patterns for the u3g devices is much different from other serial devices, as a) the speeds are much higher than other serial (USB) devices, and b) data arrives in large chunks of several kb in some cases. Any pointers would be appreciated. Nick > I tried using my 3g modem (Huawei E196) yesterday, with both the > old and the new USB stack, and it fails in slightly different > ways. > > With the old USB stack, it works until I actually try to get a packet > of more than approx 1024 bytes through, at which point it hangs with > ucom0: ucomreadcb: IOERROR > And I need to stop and start ppp(1) to get it working until the next > big packet comes around. > > It does not help to reduce the MRU because two small packets back to > back will also trigger this error. > > With the new USB stack, I am not able to talk to the modem at all > using the cuaU* devices. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 21:10:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9CF110656C3 for ; Fri, 9 Jan 2009 21:10:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6DBED8FC1A for ; Fri, 9 Jan 2009 21:10:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 6870C3F12F; Fri, 9 Jan 2009 21:10:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n09LABPj023655; Fri, 9 Jan 2009 21:10:11 GMT (envelope-from phk@critter.freebsd.dk) To: Nick Hibma From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Jan 2009 21:46:00 +0100." <200901092146.01009.nick@van-laarhoven.org> Date: Fri, 09 Jan 2009 21:10:10 +0000 Message-ID: <23654.1231535410@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 21:10:13 -0000 In message <200901092146.01009.nick@van-laarhoven.org>, Nick Hibma writes: >I've not been able to reproduce the problems reliably. But looking at the >symptoms somehow buffering goes pear-shaped somewhere. There is no >buffering being done in the u3g code.That's all handled by ucom, but to me >that looks like cut&paste from other code. So I presume (wildly pointing >fingers at code I do not yet understand) that the problem is somewhere in >the combination of ucom and tty layer, or perhaps even in the TTY layer. I can shoot that theory down right away: It worked great when I hacked the magic mode bit support into ubsa.c It must be a u3g issue. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 21:40:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97EBB106564A for ; Fri, 9 Jan 2009 21:40:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 254888FC0C for ; Fri, 9 Jan 2009 21:40:38 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 6258 invoked by uid 399); 9 Jan 2009 21:40:38 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Jan 2009 21:40:38 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4967C455.1040700@FreeBSD.org> Date: Fri, 09 Jan 2009 13:40:37 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.19 (X11/20090102) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <7d6fde3d0901090518j26dccc51v3f7be8e46ce0af77@mail.gmail.com> In-Reply-To: <7d6fde3d0901090518j26dccc51v3f7be8e46ce0af77@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 21:40:40 -0000 Garrett Cooper wrote: > Thanks for the tips Doug -- I'll give them a shot of course... Glad I could help. The one thing I forgot to mention is to try the nvidia-settings app if you have not already done so. There are various things there that you can tweak that might yield better results. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 21:45:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A15CB106568B for ; Fri, 9 Jan 2009 21:45:26 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.KPNXCHANGE.COM [213.75.38.85]) by mx1.freebsd.org (Postfix) with ESMTP id 34F588FC0C for ; Fri, 9 Jan 2009 21:45:25 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from cpsmtp-eml102.kpnxchange.com ([213.75.84.102]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 22:45:24 +0100 Received: from uitsmijter.van-laarhoven.org ([81.207.207.222]) by cpsmtp-eml102.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 22:45:24 +0100 Received: from van-laarhoven.org (dhcp-10-251-2-198.awservice [10.251.2.198]) by uitsmijter.van-laarhoven.org (8.14.3/8.14.3) with SMTP id n09LjnSZ063388; Fri, 9 Jan 2009 22:45:49 +0100 (CET) (envelope-from nick@van-laarhoven.org) Received: (nullmailer pid 6753 invoked by uid 1001); Fri, 09 Jan 2009 21:45:16 -0000 From: Nick Hibma To: Poul-Henning Kamp Date: Fri, 9 Jan 2009 22:45:15 +0100 User-Agent: KMail/1.9.10 References: <23654.1231535410@critter.freebsd.dk> In-Reply-To: <23654.1231535410@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901092245.16450.nick@van-laarhoven.org> X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, J_CHICKENPOX_35 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on uitsmijter.van-laarhoven.org X-OriginalArrivalTime: 09 Jan 2009 21:45:24.0301 (UTC) FILETIME=[93E11FD0:01C972A3] Cc: freebsd-current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 21:45:27 -0000 > >I've not been able to reproduce the problems reliably. But looking at > > the symptoms somehow buffering goes pear-shaped somewhere. There is no > > buffering being done in the u3g code.That's all handled by ucom, but to > > me that looks like cut&paste from other code. So I presume (wildly > > pointing fingers at code I do not yet understand) that the problem is > > somewhere in the combination of ucom and tty layer, or perhaps even in > > the TTY layer. > > I can shoot that theory down right away: It worked great when I hacked > the magic mode bit support into ubsa.c > > It must be a u3g issue. Explain that to the people that get great performance on u3g, which had big troubles using ubsa (the same problems you are seeing; me for one). So I am pretty sure I am right. Second: I've had reports of E220 working and the same device not working and choking on 'AT' on the second channel. It is most definitely a buffering issue. Perhaps the buffers are not properly configured, but making them larger or smaller does not change the symptoms in any case for these people. Would you know of a serial device using tty layer code with high speed serial links that I could look at to see what could be wrong in either u3g and/or ucom? Thanks. Nick From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 21:47:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C678E10656D6 for ; Fri, 9 Jan 2009 21:47:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 539218FC1B for ; Fri, 9 Jan 2009 21:47:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 15924 invoked by uid 399); 9 Jan 2009 21:47:02 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Jan 2009 21:47:02 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4967C5D5.7030608@FreeBSD.org> Date: Fri, 09 Jan 2009 13:47:01 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.19 (X11/20090102) MIME-Version: 1.0 To: "Svein Skogen (List Mail Account)" References: <49668763.8020705@mail.zedat.fu-berlin.de> <49671748.3030709@gmx.de> <4967259C.9090408@stillbilde.net> In-Reply-To: <4967259C.9090408@stillbilde.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 21:47:06 -0000 Svein Skogen (List Mail Account) wrote: > Would it be possible, as a "workaround" to have "system-CC" and > "ports-CC" defined in make.conf, making one CC the compiler for /usr/src > and another for ports, or would this just create debugging nightmares? You can do that now. Install ports-mgmt/portconf and set a global for CC accordingly. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 22:05:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AEF61065676; Fri, 9 Jan 2009 22:05:11 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id B78778FC2D; Fri, 9 Jan 2009 22:05:10 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id 326EB4ADA6; Fri, 9 Jan 2009 22:49:34 +0100 (CET) Date: Fri, 9 Jan 2009 22:49:34 +0100 From: Martin Wilke To: Volker Message-ID: <20090109214934.GC99849@bsdcrew.de> References: <49613379.8040901@vwsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <49613379.8040901@vwsoft.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: attilio@freebsd.org, uwe@grohnwaldt.eu, trasz@FreeBSD.org, freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: panic in bundirty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 22:05:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Any news here? On Sun, Jan 04, 2009 at 11:08:57PM +0100, Volker wrote: > Gentlemen, > > I've had the pleasure to inspect miwi's new tinderbox machine in a panic > situation. > > The debugging info we're able to get out of the box is the following: > > panic: bundirty: buffer 0xffffffff9a475438 still on queue 1 > > #9 0xffffffff8049f196 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:556 > #10 0xffffffff8050b540 in bundirty (bp=Variable "bp" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:1068 > #11 0xffffffff8050d684 in brelse (bp=0xffffffff9a475438) > at /usr/src/sys/kern/vfs_bio.c:1388 > #12 0xffffffff8050f07c in bufdone (bp=0xffffffff9a475438) > at /usr/src/sys/kern/vfs_bio.c:3157 > #13 0xffffffff8069cb6c in ffs_backgroundwritedone (bp=0xffffffff9a475438) > ---Type to continue, or q to quit--- > at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1679 > #14 0xffffffff8050f051 in bufdone (bp=0xffffffff9a475438) > at /usr/src/sys/kern/vfs_bio.c:3151 > #15 0xffffffff80452b51 in g_io_schedule_up (tp=Variable "tp" is not > available. > ) > at /usr/src/sys/geom/geom_io.c:587 > #16 0xffffffff8045323f in g_up_procbody () at > /usr/src/sys/geom/geom_kern.c:95 > #17 0xffffffff8048037a in fork_exit ( > callout=0xffffffff804531d0 , arg=0x0, > frame=0xffffffff80e63c80) at /usr/src/sys/kern/kern_fork.c:789 > > in frame 11, 'p *bp' gives: > $1 = {b_bufobj = 0xffffff00034fe958, b_bcount = 16384, b_caller1 = 0x0, > b_data = 0xffffffff9f4b7000 "", b_error = 5, b_iocmd = 2 '\002', > b_ioflags = 2 '\002', b_iooffset = 7127891968, b_resid = 16384, > b_iodone = 0, b_blkno = 13921664, b_offset = 7127891968, b_bobufs = { > tqe_next = 0xffffffff9a505a38, tqe_prev = 0xffffff00034fe9a8}, > b_left = 0x0, b_right = 0xffffffff9a505a38, b_vflags = 0, b_freelist = { > tqe_next = 0xffffffff9a472db8, tqe_prev = 0xffffffff80b56210}, > b_qindex = 1, b_flags = 41092, b_xflags = 33 '!', b_lock = > {lock_object = { > lo_name = 0xffffffff8083ce18 "bufwait", > lo_type = 0xffffffff8083ce18 "bufwait", lo_flags = 91947008, > lo_witness_data = {lod_list = {stqe_next = 0xffffffff80ae6f80}, > lod_witness = 0xffffffff80ae6f80}}, lk_lock = 18446744073709551608, > lk_recurse = 0, lk_timo = 0, lk_pri = 80}, b_bufsize = 16384, > b_runningbufspace = 0, b_kvabase = 0xffffffff9f4b7000 "", b_kvasize = > 16384, > b_lblkno = 13921664, b_vp = 0xffffff00034fe820, b_dirtyoff = 0, > b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, > b_saveaddr = 0xffffffff9f4b7000, b_pager = {pg_reqpage = 0}, b_cluster = { > cluster_head = {tqh_first = 0xffffffff9a479c68, > tqh_last = 0xffffffff9a4901b0}, cluster_entry = { > tqe_next = 0xffffffff9a479c68, tqe_prev = 0xffffffff9a4901b0}}, > b_pages = {0xffffff00de0eafa0, 0xffffff00de0eb010, 0xffffff00de0eb080, > 0xffffff00de0eb0f0, 0x0 }, b_npages = 4, b_dep = { > lh_first = 0x0}, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, > b_fsprivate3 = 0x0, b_pin_count = 0} > > This panic does not occur before commit 176708. > > The panic is in sys/kern/vfs_bio.c bundirty 1055: > KASSERT( bp->b_flags & B_REMFREE || bp->b_qindex == QUEUE_NONE ... > > bp->b_qindex = 0x01 (QUEUE_FREE) > bp->b_flags = 0xa084 (B_ASYNC | B_DELWRI | B_NOCACHE | B_INVAL) > > My assumption is: > > brele knows about the QUEUE_FREE but bundirty only wants to operate on > QUEUE_NONE. Either this is a race condition, brele should not call > bundirty or bundirty should operate not just on QUEUE_NONE buffers. > > As there have been some locking related commits in the changes in > question, this might also be caused by an unlocked operation. > > right before the panic, we're seeing DMA errors: > > ad6: setting up DMA failed > _vfs_done():ad6[WRITE(offset=5412487168, length=131072)]error = 5 > ad6: FAILURE - load data > ad6: setting up DMA failed > g_vfs_done():ad6[WRITE(offset=5044109312, length=131072)]error = 5 > g_vfs_done():ad6[WRITE(offset=5230985216, length=131072)]error = 5 > g_vfs_done():ad6[WRITE(offset=5231116288, length=131072)]error = 5 > g_vfs_done():ad6[WRITE(offset=5044240384, length=131072)]error = 5 > g_vfs_done():ad6[WRITE(offset=5412618240, length=131072)]error = 5 > g_vfs_done():ad4s1d[WRITE(offset=7127891968, length=16384)]error = 5 > > kgdb output can be found at: > http://www.bsdmeat.net/~lando/miwi/kgdb.txt > > Suggestions what the correct fix to this issue is? Change bundirty or > brele? Clean up locking? > > CC'ing those who committed to vfs_bio.c in the relevant time frame. > > Thanks > > Volker > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > - -- +-----------------------+-------------------------------+ | PGP : 0x05682353 | Jabber : miwi(at)BSDCrew.de | | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklnxm0ACgkQFwpycAVoI1OZ7wCdFQ5FxqVkFcROpBTe2ws79ARv 378An3ez8Zb8Z2vo7nq2WBwRaOe93zdz =hKtf -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 22:05:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47FC61065677; Fri, 9 Jan 2009 22:05:56 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id A4E5D8FC2C; Fri, 9 Jan 2009 22:05:55 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so58907ugs.39 for ; Fri, 09 Jan 2009 14:05:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=2pxCK2ZxQ5qwzUu6jbZMVhDzxzpOHeMayYTxGYOFWa0=; b=O4SaYSbQCPEyV/UExcbpk7k9wCdh1lKuDmty36wtulKBycRxizcispt45zeAAjixsT lS5i0rs033p7F0E20qrx2UrgPR/Qd4G2JPkv20UtiaWJU3zHCCBKkWJurUeZCQZQ2E9c 0XLD/6esCLuRCt+A8nGt5GjRo2CPW2a4o7ErQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=bUQ2GmKVKDeBxBjaVSB3RzRkyz41GB9l7SJnt7NYL9H+PC1+pKghlEtMarDStZct6I fVsfMtvX4JyMm20DQHX+RXG0aqQo/jATDrGy5ATFGhLpP4PynEunGeHoj1lMUv/wfVXQ DOy6FSvGD+DC8QBKv5icBl/OkDBvn0XBquNMg= Received: by 10.67.10.18 with SMTP id n18mr15252943ugi.45.1231538754648; Fri, 09 Jan 2009 14:05:54 -0800 (PST) Received: by 10.67.88.9 with HTTP; Fri, 9 Jan 2009 14:05:54 -0800 (PST) Message-ID: <7d6fde3d0901091405p1e3f61e4o166eb1acfa3aadcb@mail.gmail.com> Date: Fri, 9 Jan 2009 14:05:54 -0800 From: "Garrett Cooper" To: "Doug Barton" In-Reply-To: <4967C455.1040700@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <7d6fde3d0901090518j26dccc51v3f7be8e46ce0af77@mail.gmail.com> <4967C455.1040700@FreeBSD.org> Cc: FreeBSD Current Subject: Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 22:05:57 -0000 On Fri, Jan 9, 2009 at 1:40 PM, Doug Barton wrote: > Garrett Cooper wrote: >> Thanks for the tips Doug -- I'll give them a shot of course... > > Glad I could help. The one thing I forgot to mention is to try the > nvidia-settings app if you have not already done so. There are various > things there that you can tweak that might yield better results. > > Doug I did in fact set everything up via nvidia-settings. I'm running some stress tests right now to see whether or not I can simulate the issue -- it doesn't appear to be as straightforward as I thought.. -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 22:12:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95C0A1065921 for ; Fri, 9 Jan 2009 22:12:59 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id C8B0E8FC0A for ; Fri, 9 Jan 2009 22:12:58 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by ewy14 with SMTP id 14so11684736ewy.19 for ; Fri, 09 Jan 2009 14:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=hQJOFL5P3yZ8xs1bQSGlzrTj7Qyg/jLW9y4PEAi1zXQ=; b=ETfLFSbg0yk7EFBZcEWisMx3twAOFBpZ7tRKEtOeXvXihFpSdi9B9S52+E0qoVCiFr 0Ml3/c27VU9kBQ9Yfx0VhRNPs+zhGfhkW6hZqwNBaTk+9uBbg0E19Hbc4jSFlpgmh26Q k/WSOLOtA+FKku6yOtzywxjVtLthe5XxHec5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=kwfZmWkKMxHwxI6pV6RVxQYC9JAf0kI8nElYPzshOPEC6T9QSci+DvUcRpnBbXDacp sAI7hx04YHjzLfxJzuhxXDXKO5pRWrs24Gr6kmXVBWPbHGBz47zMuwOl2OrenrzJZjuW 3/Gr5a00dfzqPTH45n0D1ZhnkxZ4/g3FIwfGg= Received: by 10.210.105.20 with SMTP id d20mr23605417ebc.142.1231539177958; Fri, 09 Jan 2009 14:12:57 -0800 (PST) Received: by 10.210.58.4 with HTTP; Fri, 9 Jan 2009 14:12:57 -0800 (PST) Message-ID: <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> Date: Sat, 10 Jan 2009 01:12:57 +0300 From: "Alexander Churanov" To: "Christoph Mallon" In-Reply-To: <49675F04.20006@gmx.de> MIME-Version: 1.0 References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Andrew Reilly , Roman Divacky , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 22:13:01 -0000 Folks, The '-std=c99'' only instructs GCC to allow the whole of C99. This is clearly not enough, because this mode allows too many GCC extensions. If you compile your code in "default' mode or just specify '-std=c99', then it's very likely that you will eventually get stuck to GCC. Using this approach you are reducing chances to switch to another C99 compiler. Though I am not aware of any other open source compiler supporting C99, I beleive that there is great need for it. This discussion indicates that there is real necessity for BSD-licensed C99 compiler. That's why I am always propagandizing the following: "-Wall -Werror -std=c99 -pedantic". To my mind, this helps to prepear your code for eventual switching to another standard-compliant compiler. Alexander From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 22:22:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7494C106564A for ; Fri, 9 Jan 2009 22:22:36 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2968F8FC13 for ; Fri, 9 Jan 2009 22:22:35 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D71FE9CB199; Fri, 9 Jan 2009 23:22:24 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ky5S53MUnwlJ; Fri, 9 Jan 2009 23:22:12 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 7EEE29CB298; Fri, 9 Jan 2009 23:22:12 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n09MMBmR033542; Fri, 9 Jan 2009 23:22:11 +0100 (CET) (envelope-from rdivacky) Date: Fri, 9 Jan 2009 23:22:11 +0100 From: Roman Divacky To: Alexander Churanov Message-ID: <20090109222211.GA33145@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Andrew Reilly , Ollivier Robert , Christoph Mallon , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 22:22:36 -0000 On Sat, Jan 10, 2009 at 01:12:57AM +0300, Alexander Churanov wrote: > Folks, > > The '-std=c99'' only instructs GCC to allow the whole of C99. This is > clearly not enough, because this mode allows too many GCC extensions. If you > compile your code in "default' mode or just specify '-std=c99', then it's > very likely that you will eventually get stuck to GCC. Using this approach > you are reducing chances to switch to another C99 compiler. > > Though I am not aware of any other open source compiler supporting C99, I > beleive that there is great need for it. This discussion indicates that > there is real necessity for BSD-licensed C99 compiler. clang (clang.llvm.org) supports almost everything now and aims for full C99 support. pcc aims for full C99 too I believe Chris Mallon can comment better but I believe cparser is C99 too am I missing something? From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 22:28:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 304D91065670 for ; Fri, 9 Jan 2009 22:28:26 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id B31348FC0A for ; Fri, 9 Jan 2009 22:28:25 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz13 with SMTP id 13so3299359bwz.19 for ; Fri, 09 Jan 2009 14:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=ChIfF6WTiRiqG8+1dak3T1uojKAlDgsYe1aMa8Fbk9Y=; b=PYC2NHzlZ1Cp+OGBm6dKszFsHqse5+V9askx0H0VWMmjQ4CGPzSQxNKdwjnxLDB577 9o0OqnYb0N2Q83e5dBdWVyFmpqH0ks4czLmyvgWGsqhgQ7YYcrqcHu69OOfgsYhRyKG4 Ji0QIvgep+kRu82b8/7OoIl3bZcs785oyJUzM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=lkcSbjPl5EFR1G8HbtnTJLcyqOMQfyEgDhJQDxCvWbFoSzRJUFdE1H9vw9LYfYT4Sb 2sMsysEHaOLwSvgCpmhWKO56Qvx46rRWqDytScnQp+bY38zuic73dHuKlqi+f7Qydpkz Qw9pqMzqyoptNlZssupgRuEqswl6cxLNJz0Yg= Received: by 10.181.60.14 with SMTP id n14mr9899322bkk.23.1231540104656; Fri, 09 Jan 2009 14:28:24 -0800 (PST) Received: by 10.181.239.5 with HTTP; Fri, 9 Jan 2009 14:28:19 -0800 (PST) Message-ID: Date: Sat, 10 Jan 2009 01:28:19 +0300 From: pluknet To: freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: kernel doesn't boot when is built with ukbd/ums X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 22:28:26 -0000 Hi. Today I noticed that when kernel has build-in ums and ukbd support, it stops booting with the last seen messages (transcribed): ... uart0: [FILTER] atkbdc0: port 0x60,0x64 irq1 on acpi0 [stops here] ... It boots fine if kernel is built without ums and ukbd devices (and they loaded as modules). And I see in this case. ... atrtc0: port 0x70-0x71 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 ... In both cases I have in loader.conf: ums_load="YES" ukbd_load="YES" I would jump in ddb to see what's going on, but my USB keyboard begin to work only if I replug it close to the multiuser. Hence I can't. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 22:34:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CE571065675 for ; Fri, 9 Jan 2009 22:34:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 41CF68FC18 for ; Fri, 9 Jan 2009 22:34:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 363213F12F; Fri, 9 Jan 2009 22:34:03 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n09MY23x024545; Fri, 9 Jan 2009 22:34:03 GMT (envelope-from phk@critter.freebsd.dk) To: Nick Hibma From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Jan 2009 22:45:15 +0100." <200901092245.16450.nick@van-laarhoven.org> Date: Fri, 09 Jan 2009 22:34:02 +0000 Message-ID: <24544.1231540442@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: 3G modem and USB, old & new X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 22:34:04 -0000 In message <200901092245.16450.nick@van-laarhoven.org>, Nick Hibma writes: >Would you know of a serial device using tty layer code with high speed >serial links that I could look at to see what could be wrong in either u3g >and/or ucom? I have not had issues with any other ucom device, including for instance the USB-GPIB adapter from prologix.biz which gets to very high speeds with certain T&M instruments. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 22:49:06 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4953C1065672 for ; Fri, 9 Jan 2009 22:49:06 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 83AA98FC18 for ; Fri, 9 Jan 2009 22:49:05 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n09Mnc6l045601; Fri, 9 Jan 2009 17:49:39 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Richard Todd In-Reply-To: <20090109004853.GA34384@ichotolot.servalan.com> References: <20090109004853.GA34384@ichotolot.servalan.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nobRallXHZu+eaWhGxwh" Organization: FreeBSD, Inc. Date: Fri, 09 Jan 2009 17:49:02 -0500 Message-Id: <1231541342.56664.19.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, NO_RELAYS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: freebsd-current@FreeBSD.org Subject: Re: Recent changes to pseudofs causing panics -- leaking a vnode lock? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 22:49:06 -0000 --=-nobRallXHZu+eaWhGxwh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-01-08 at 18:48 -0600, Richard Todd wrote: > I've noticed that ever since updating to a kernel after the recent change= s > to the pseudofs code late last month, that I've occasionally gotten the=20 > following sort of panic: >=20 > System call readlink returning with the following locks held: > exclusive lockmgr pseudofs (pseudofs) r =3D 0 (0xffffff00ba581cc8) locked= @ /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:193 > panic: witness_warn >=20 > The line in question is the one I marked by an arrow in this chunk of the= =20 > pfs_vncache_alloc code:=20 > if ((pn->pn_flags & PFS_PROCDEP) !=3D 0) > (*vpp)->v_vflag |=3D VV_PROCDEP; > pvd->pvd_vnode =3D *vpp; > VN_LOCK_AREC(*vpp); > vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); <=3D=3D=3D=3D this lock h= ere > error =3D insmntque(*vpp, mp); >=20 > So somehow, a vnode is getting locked here and not getting unlocked. > I suspect the code in the retry2: loop later, simply because that's > the code that got added in the late December commits, but I'm not > clear on how exactly. I've tried littering the code with extra > printfs to try to clarify what's going on, but alas, I'm still not > really sure what's going on. I do have a good coredump that I can get > info out of, if someone can suggest to me what would be useful things > to dump. Anyway, here's the patch for the debugging printfs I added, > and the console messages produced by those printfs from the most > recent coredump/panic. The console msgs do seem to indicate some sort > of race condition going on, though, as they seem to show two or more proc= esses > simultaneously hitting the pseudofs code and hitting my debugging print > statements (alas, making the console log rather a confused mess.) I believe I have fixed this in HEAD. Kib gave his review and approval, and the fix really should prevent this hang. Please report back if you still see the problem. Joe >=20 > The debugging additions: > Index: pseudofs_vncache.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /usr/FreeBSDCVS/src/sys/fs/pseudofs/pseudofs_vncache.c,v > retrieving revision 1.44 > diff -u -r1.44 pseudofs_vncache.c > --- pseudofs_vncache.c 29 Dec 2008 13:25:58 -0000 1.44 > +++ pseudofs_vncache.c 8 Jan 2009 02:22:50 -0000 > @@ -129,6 +129,7 @@ > mtx_unlock(&pfs_vncache_mutex); > if (vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, curthread) =3D=3D 0) { > ++pfs_vncache_hits; > + vprint("XXX vncache 6", vp); > *vpp =3D vp; > /* > * Some callers cache_enter(vp) later, so > @@ -191,7 +192,9 @@ > pvd->pvd_vnode =3D *vpp; > VN_LOCK_AREC(*vpp); > vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); > + printf("XXX vncache 1 *vpp=3D%p\n", *vpp); > error =3D insmntque(*vpp, mp); > + printf("XXX vncache 2 *vpp=3D%p\n", *vpp); > if (error !=3D 0) { > *vpp =3D NULLVP; > return (error); > @@ -211,11 +214,14 @@ > mtx_unlock(&pfs_vncache_mutex); > if (vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, curthread) =3D=3D 0) { > ++pfs_vncache_hits; > + vprint("XXX vncache 3", *vpp); > vgone(*vpp); > + vprint("XXX vncache 4", *vpp); > *vpp =3D vp; > cache_purge(vp); > return (0); > } > + vprint("XXX vncache 5", *vpp); > goto retry2; > } > } > Index: pseudofs_vnops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /usr/FreeBSDCVS/src/sys/fs/pseudofs/pseudofs_vnops.c,v > retrieving revision 1.72 > diff -u -r1.72 pseudofs_vnops.c > --- pseudofs_vnops.c 30 Dec 2008 21:49:39 -0000 1.72 > +++ pseudofs_vnops.c 6 Jan 2009 23:12:40 -0000 > @@ -369,6 +369,7 @@ > VOP_UNLOCK(vp, 0); > =20 > error =3D pfs_vncache_alloc(mp, dvp, pn, pid); > + vprint("XXX vptocnp", *dvp); > if (error) { > vn_lock(vp, locked | LK_RETRY); > vfs_unbusy(mp); > @@ -502,6 +503,7 @@ > } > =20 > error =3D pfs_vncache_alloc(vn->v_mount, vpp, pn, pid); > + vprint("XXX lookup", *vpp); > if (error) > goto failed; > =20 > and the msgs from the most recent coredump: > Script started on Thu Jan 8 18:34:33 2009 > You have mail. > ichotolot# kgdb kernel.debug /var/crash/vmcore.206=20 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: > XXX vncache 1 *vpp=3D0xffffff00b0173c30 > XXX vncache 2 *vpp=3D0xffffff00b0173c30 > XXX vncache 1 *vpp=3D0xffffff000d420270XXX vncache 1 *vp > p=3D0xffXfXfX fvfn0cache 2 *vp0c6886750p=3D0xffffff000d420270 > XXX vncache 2 *vpp=3D0xffffff00c6886750 >=20 > XXX lookup > 0xffffff00c6886750: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff804cf473 at pfs_lookup+0x273 > #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #9 0xffffffff805a83d3 at lookup+0x513 > #10 0xffffffff805a928e at namei+0x53e > #11 0xffffffff805b6ffa at kern_readlinkat+0x7a > #12 0xffffffff805b7121 at kern_readlink+0x21 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #14 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX vncache 3 > 0xffffff000d420270: tag pseudofs, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_ROOT) > lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff805a885f at lookup+0x99f > #6 0xffffffff805a928e at namei+0x53e > #7 0xffffffff805b6ffa at kern_readlinkat+0x7a > #8 0xffffffff805b7121 at kern_readlink+0x21 > #9 0xffffffff807f16b7 at syscall+0x1e7 > #10 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX vncache 4 > 0xffffff000d420270: tag none, type VBAD > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_ROOT|VI_DOOMED) > lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff805a885f at lookup+0x99f > #6 0xffffffff805a928e at namei+0x53e > #7 0xffffffff805b6ffa at kern_readlinkat+0x7a > #8 0xffffffff805b7121 at kern_readlink+0x21 > #9 0xffffffff807f16b7 at syscall+0x1e7 > #10 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX vncache 6 > 0xffffff00c6886750: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff805b3fdb at vget+0x8b > #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 > #6 0xffffffff804cf473 at pfs_lookup+0x273 > #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #10 0xffffffff805a83d3 at lookup+0x513 > #11 0xffffffff805a928e at namei+0x53e > #12 0xffffffff805b6ffa at kern_readlinkat+0x7a > #13 0xffffffff805b7121 at kern_readlink+0x21 > #14 0xffffffff807f16b7 at syscall+0x1e7 > #15 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX lookup > 0xffffff00c6886750: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff805b3fdb at vget+0x8b > #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 > #6 0xffffffff804cf473 at pfs_lookup+0x273 > #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #10 0xffffffff805a83d3 at lookup+0x513 > #11 0xffffffff805a928e at namei+0x53e > #12 0xffffffff805b6ffa at kern_readlinkat+0x7a > #13 0xffffffff805b7121 at kern_readlink+0x21 > #14 0xffffffff807f16b7 at syscall+0x1e7 > #15 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX vncache 1 *vpp=3D0xffffff007af74270 > XXX vncache 2 *vpp=3D0xffffff007af74270 > XXX lookup > 0xffffff007af74270: tag pseudofs, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_PROCDEP) > lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff804cf473 at pfs_lookup+0x273 > #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #9 0xffffffff805a83d3 at lookup+0x513 > #10 0xffffffff805a928e at namei+0x53e > #11 0xffffffff805b6ffa at kern_readlinkat+0x7a > #12 0xffffffff805b7121 at kern_readlink+0x21 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #14 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX vncache 1 *vpp=3D0xffffff00cd4719c0 > XXX vncache 2 *vpp=3D0xffffff00cd4719c0 > XXX lookup > 0xffffff00cd4719c0: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_PROCDEP) > lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff804cf473 at pfs_lookup+0x273 > #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #9 0xffffffff805a83d3 at lookup+0x513 > #10 0xffffffff805a928e at namei+0x53e > #11 0xffffffff805b6ffa at kern_readlinkat+0x7a > #12 0xffffffff805b7121 at kern_readlink+0x21 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #14 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX vncache 6 > 0xffffff00b0173c30: tag pseudofs, type VDIR > usecount 2, writecount 0, refcount 3 mountedhere 0 > flags (VV_ROOT) > lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff805b3fdb at vget+0x8b > #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 > #6 0xffffffff805a885f at lookup+0x99f > #7 0xffffffff805a928e at namei+0x53e > #8 0xffffffff805b6ffa at kern_readlinkat+0x7a > #9 0xffffffff805b7121 at kern_readlink+0x21 > #10 0xffffffff807f16b7 at syscall+0x1e7 > #11 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX vncache 6 > 0xffffff00c6886750: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff805b3fdb at vget+0x8b > #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 > #6 0xffffffff804cf473 at pfs_lookup+0x273 > #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #10 0xffffffff805a83d3 at lookup+0x513 > #11 0xffffffff805a928e at namei+0x53e > #12 0xffffffff805b6ffa at kern_readlinkat+0x7a > #13 0xffffffff805b7121 at kern_readlink+0x21 > #14 0xffffffff807f16b7 at syscall+0x1e7 > #15 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX lookup > 0xffffff00c6886750: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff805b3fdb at vget+0x8b > #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 > #6 0xffffffff804cf473 at pfs_lookup+0x273 > #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #10 0xffffffff805a83d3 at lookup+0x513 > #11 0xffffffff805a928e at namei+0x53e > #12 0xffffffff805b6ffa at kern_readlinkat+0x7a > #13 0xffffffff805b7121 at kern_readlink+0x21 > #14 0xffffffff807f16b7 at syscall+0x1e7 > #15 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX vncache 1 *vpp=3D0xffffff0053e7a750 > XXX vncache 2 *vpp=3D0xffffff0053e7a750 > XXX lookup > 0xffffff0053e7a750: tag pseudofs, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_PROCDEP) > lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff804cf473 at pfs_lookup+0x273 > #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #9 0xffffffff805a83d3 at lookup+0x513 > #10 0xffffffff805a928e at namei+0x53e > #11 0xffffffff805b6ffa at kern_readlinkat+0x7a > #12 0xffffffff805b7121 at kern_readlink+0x21 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #14 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX vncache 1 *vpp=3D0xffffff00429cb4e0XXX vncache 1 *vpp=3D0xffffff007a9= 2a750 > XXX vncache 2 *vpp=3D0xffffff00429cb4e0 > XXX vncache 2 *vpp=3D0xffffff007a92a750 > XXX lookup > XXX lookup > 0xffffff00429cb4e0:=20 > 0xffffff007a92a750: tag pseudofs, type VLNKtag pseudofs, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_PROCDEP) > flags (VV_PROCDEP) > =20 > lock type ps eudofs: EXCL by thrleoacdk type0 pseudofs: EXCL by xft= fhfrfefafd0 0829099x3f9f0 f(pid 18860)fff00c625bab0 (pid 18865) >=20 > #0 0xffffffff80514c28 at __lockmgr_args+0x758#0=20 > 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b#2=20 > 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0x#f5f ffff0fxff8f0f4fcff473 at pfs_lookffufp8+004xc2f7473 at pfs_look= up+30x273 >=20 > #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf#6 0xffffffff8083543f a= t VOP_CACHEDLOOKUP_APV+0xaf >=20 > #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0#7 0xffffffff805a2220 at vf > s_cache_lookup+0xf0 > #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7#8 0xffffffff808378 > a7 at VOP_LOOKUP_APV+0xb7 > #9 0xffffffff805a83d3 at lookup+0x513 > #9 0xffffffff805a83d3 at lookup+0x513 > #10 0xffffff#ff8105a928e at namei+00 x53e0xffffffff805a928e at namei+0x53= e >=20 > #11 0xffffffff805b6ffa at kern_readlinkat+0x7a#11 0xffffffff805b6ffa at k= ern_readlinkat+0x7a >=20 > #12 0xffffffff805b7121 at kern_readlink+0x21#12 0xffffffff805b7121 at ker > n_readlink+0x21 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #14 0xffffffff807d41bb at Xfast_syscall+0xab >=20 > XXX vncache 1 *vpp=3D0xffffff007a357750#14 0xffffffff807d41bb at Xfast_sy= scall+0xab > XXX vncache 2 *vpp=3D0xffffff007a357750 >=20 > XXX looku > p > 0xffffff007a357750: tag pseudofs, type VLNKSystem call readlink returning > usecount 1, writecount 0, refcount 1 mountedhere 0 with the following > flags (VV_PROCDEP) locks held: > exclusive lockmgr pseudofs > lock type pseudofs: EXCL by thread 0xffffff00c625b a(b0 (ppid seu1d8= 865)ofs) > r =3D 0 (0xffffff000d420308) locked @ /usr/src/sys/fs/pseudofs/pseudofs_= vncache.c:194 > panic: witness_warn > cpuid =3D 0 > KDB: enter: panic > Physical memory: 4012 MB > Dumping 2401 MB: 2386 2370 2354 2338 2322 2306 2290 2274 2258 2242 2226 2= 210 2194 2178 2162 2146 2130 2114 2098 2082 2066 2050 2034 2018 2002 1986 1= 970 1954 1938 1922 1906 1890 1874 1858 1842 1826 1810 1794 1778 1762 1746 1= 730 1714 1698 1682 1666 1650 1634 1618 1602 1586 1570 1554 1538 1522 1506 1= 490 1474 1458 1442 1426 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 1= 250 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 1= 010 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722= 706 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 41= 8 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 1= 14 98 82 66 50 34 18 2 >=20 > Reading symbols from /boot/kernel/zfs.ko...done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...done. > Loaded symbols for /boot/kernel/opensolaris.ko > Reading symbols from /boot/kernel/geom_mirror.ko...done. > Loaded symbols for /boot/kernel/geom_mirror.ko > Reading symbols from /boot/kernel/snd_hda.ko...done. > Loaded symbols for /boot/kernel/snd_hda.ko > Reading symbols from /boot/kernel/sound.ko...done. > Loaded symbols for /boot/kernel/sound.ko > Reading symbols from /boot/kernel/coretemp.ko...done. > Loaded symbols for /boot/kernel/coretemp.ko > Reading symbols from /boot/kernel/atapicam.ko...done. > Loaded symbols for /boot/kernel/atapicam.ko > Reading symbols from /boot/kernel/tmpfs.ko...done. > Loaded symbols for /boot/kernel/tmpfs.ko > Reading symbols from /boot/kernel/linux.ko...done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /usr/local/modules/fuse.ko...done. > Loaded symbols for /usr/local/modules/fuse.ko > Reading symbols from /boot/modules/cpu.ko...done. > Loaded symbols for /boot/modules/cpu.ko > Reading symbols from /boot/kernel/green_saver.ko...done. > Loaded symbols for /boot/kernel/green_saver.ko > Reading symbols from /boot/kernel/radeon.ko...done. > Loaded symbols for /boot/kernel/radeon.ko > Reading symbols from /boot/kernel/drm.ko...done. > Loaded symbols for /boot/kernel/drm.ko > Reading symbols from /boot/kernel/nullfs.ko...done. > Loaded symbols for /boot/kernel/nullfs.ko > Reading symbols from /boot/kernel/linprocfs.ko...done. > Loaded symbols for /boot/kernel/linprocfs.ko > #0 doadump () at pcpu.h:196 > 196 __asm __volatile("movq %%gs:0,%0" : "=3Dr" (td)); > (kgdb) =08 =08p =08 =08=08 =08=08 =08=07bt > #0 doadump () at pcpu.h:196 > #1 0xffffffff801c752c in db_fncall (dummy1=3DVariable "dummy1" is not av= ailable. > ) > at /usr/src/sys/ddb/db_command.c:548 > #2 0xffffffff801c7861 in db_command (last_cmdp=3D0xffffffff80b547a0, cmd= _table=3DVariable "cmd_table" is not available. > ) > at /usr/src/sys/ddb/db_command.c:445 > #3 0xffffffff801c7ab0 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:498 > #4 0xffffffff801c9a59 in db_trap (type=3DVariable "type" is not availabl= e. > ) at /usr/src/sys/ddb/db_main.c:229 > #5 0xffffffff80558fd5 in kdb_trap (type=3D3, code=3D0, tf=3D0xffffffff2d= 73e840) > at /usr/src/sys/kern/subr_kdb.c:534 > #6 0xffffffff807f1e14 in trap (frame=3D0xffffffff2d73e840) > at /usr/src/sys/amd64/amd64/trap.c:533 > #7 0xffffffff807d3fae in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:217 > #8 0xffffffff805591ad in kdb_enter (why=3D0xffffffff808d5179 "panic",=20 > msg=3D0x1
) at cpufunc.h:63 > #9 0xffffffff80529c5b in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:559 > #10 0xffffffff8056c41e in witness_warn (flags=3DVariable "flags" is not a= vailable. > ) > at /usr/src/sys/kern/subr_witness.c:1655 > #11 0xffffffff807f175e in syscall (frame=3D0xffffffff2d73ec90) > at /usr/src/sys/amd64/amd64/trap.c:965 > #12 0xffffffff807d41bb in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:338 > #13 0x0000000018c1ec1c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) fr 11 > #11 0xffffffff807f175e in syscall (frame=3D0xffffffff2d73ec90) > at /usr/src/sys/amd64/amd64/trap.c:965 > 965 WITNESS_WARN(WARN_PANIC, NULL, "System call %s returning"= , > (kgdb) p td > $1 =3D (struct thread *) 0xffffff0082999390 > (kgdb) p td->td_proc > $2 =3D (struct proc *) 0xffffff0082ae4880 > (kgdb) p td->td_proc[0] > $3 =3D {p_list =3D {le_next =3D 0xffffff00c82e6440, le_prev =3D 0xffffff0= 07ac31000},=20 > p_threads =3D {tqh_first =3D 0xffffff0082999390, tqh_last =3D 0xffffff0= 0829993a0},=20 > p_slock =3D {lock_object =3D {lo_name =3D 0xffffffff808d3982 "process s= lock",=20 > lo_flags =3D 720896, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock = =3D 4},=20 > p_ucred =3D 0xffffff0010b4ec00, p_fd =3D 0xffffff00bdaac400, p_fdtol = =3D 0x0,=20 > p_stats =3D 0xffffff0082a83c00, p_limit =3D 0xffffff000ef56c00, p_limco= =3D { > c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0,=20 > tqe_prev =3D 0x0}}, c_time =3D 0, c_arg =3D 0x0, c_func =3D 0,=20 > c_lock =3D 0xffffff0082ae4978, c_flags =3D 0, c_cpu =3D 0},=20 > p_sigacts =3D 0xffffff00290e1000, p_flag =3D 268451840, p_state =3D PRS= _NORMAL,=20 > p_pid =3D 18860, p_hash =3D {le_next =3D 0x0, le_prev =3D 0xfffffffe402= 3fd60},=20 > p_pglist =3D {le_next =3D 0x0, le_prev =3D 0xffffff007ac57948},=20 > p_pptr =3D 0xffffff007ac57880, p_sibling =3D {le_next =3D 0x0,=20 > le_prev =3D 0xffffff007ac57970}, p_children =3D {lh_first =3D 0x0}, p= _mtx =3D { > lock_object =3D {lo_name =3D 0xffffffff808d3975 "process lock",=20 > lo_flags =3D 21168128, lo_data =3D 0, lo_witness =3D 0xfffffffe4021= a400},=20 > mtx_lock =3D 4}, p_ksi =3D 0xffffff000515e000, p_sigqueue =3D {sq_sig= nals =3D { > __bits =3D {0, 0, 0, 0}}, sq_kill =3D {__bits =3D {0, 0, 0, 0}}, sq= _list =3D { > tqh_first =3D 0x0, tqh_last =3D 0xffffff0082ae49c0},=20 > sq_proc =3D 0xffffff0082ae4880, sq_flags =3D 1}, p_oppid =3D 0,=20 > p_vmspace =3D 0xffffff0082315d38, p_swtick =3D 10457673, p_realtimer = =3D { > it_interval =3D {tv_sec =3D 0, tv_usec =3D 0}, it_value =3D {tv_sec = =3D 0,=20 > tv_usec =3D 0}}, p_ru =3D {ru_utime =3D {tv_sec =3D 0, tv_usec =3D = 0}, ru_stime =3D { > tv_sec =3D 0, tv_usec =3D 0}, ru_maxrss =3D 0, ru_ixrss =3D 0, ru_i= drss =3D 0,=20 > ru_isrss =3D 0, ru_minflt =3D 0, ru_majflt =3D 0, ru_nswap =3D 0, ru_= inblock =3D 0,=20 > ru_oublock =3D 0, ru_msgsnd =3D 0, ru_msgrcv =3D 0, ru_nsignals =3D 0= ,=20 > ru_nvcsw =3D 0, ru_nivcsw =3D 0}, p_rux =3D {rux_runtime =3D 0, rux_u= ticks =3D 0,=20 > rux_sticks =3D 0, rux_iticks =3D 0, rux_uu =3D 0, rux_su =3D 0, rux_t= u =3D 0},=20 > p_crux =3D {rux_runtime =3D 0, rux_uticks =3D 0, rux_sticks =3D 0, rux_= iticks =3D 0,=20 > rux_uu =3D 0, rux_su =3D 0, rux_tu =3D 0}, p_profthreads =3D 0, p_exi= tthreads =3D 0,=20 > p_traceflag =3D 0, p_tracevp =3D 0x0, p_tracecred =3D 0x0,=20 > p_textvp =3D 0xffffff001b02a750, p_lock =3D 0 '\0', p_sigiolst =3D { > slh_first =3D 0x0}, p_sigparent =3D 20, p_sig =3D 0, p_code =3D 0, p_= stops =3D 0,=20 > p_stype =3D 0, p_step =3D 0 '\0', p_pfsflags =3D 0 '\0', p_nlminfo =3D = 0x0,=20 > p_aioinfo =3D 0x0, p_singlethread =3D 0x0, p_suspcount =3D 0, p_xthread= =3D 0x0,=20 > p_boundary_count =3D 0, p_pendingcnt =3D 0, p_itimers =3D 0x0,=20 > p_magic =3D 3203398350, p_osrel =3D 800054,=20 > p_comm =3D "perl\000l", '\0' , p_pgrp =3D 0xffffff000= b06ec00,=20 > p_sysent =3D 0xffffffff80b30320, p_args =3D 0xffffff00bdceda80,=20 > p_cpulimit =3D 9223372036854775807, p_nice =3D 0 '\0', p_fibnum =3D 0,=20 > p_xstat =3D 0, p_klist =3D {kl_list =3D {slh_first =3D 0x0},=20 > kl_lock =3D 0xffffffff805008a0 ,=20 > kl_unlock =3D 0xffffffff805008c0 ,=20 > kl_locked =3D 0xffffffff80501ba0 ,=20 > kl_lockarg =3D 0xffffff0082ae4978}, p_numthreads =3D 1,=20 > p_md =3D , p_itcallout =3D {c_links =3D {sle =3D {sle_= next =3D 0x0},=20 > tqe =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}}, c_time =3D 0, c_arg = =3D 0x0,=20 > c_func =3D 0, c_lock =3D 0x0, c_flags =3D 16, c_cpu =3D 0}, p_acflag = =3D 0,=20 > p_peers =3D 0x0, p_leader =3D 0xffffff0082ae4880, p_emuldata =3D 0x0,=20 > p_label =3D 0x0, p_sched =3D 0xffffff0082ae4cc0, p_ktr =3D {stqh_first = =3D 0x0,=20 > stqh_last =3D 0xffffff0082ae4c90}, p_mqnotifier =3D {lh_first =3D 0x0= },=20 > p_dtrace =3D 0x0, p_pwait =3D {cv_description =3D 0xffffffff808d42c2 "p= pwait",=20 > cv_waiters =3D 0}} > (kgdb) =08 =08=07p *td > $4 =3D {td_lock =3D 0xffffffff80b91680, td_proc =3D 0xffffff0082ae4880, t= d_plist =3D { > tqe_next =3D 0x0, tqe_prev =3D 0xffffff0082ae4890}, td_runq =3D { > tqe_next =3D 0xffffff000549d720, tqe_prev =3D 0xffffffff80b918c8}, td= _slpq =3D { > tqe_next =3D 0x0, tqe_prev =3D 0xffffff000721e190}, td_lockq =3D { > tqe_next =3D 0x0, tqe_prev =3D 0xffffffff2cb3f750},=20 > td_cpuset =3D 0xffffff000288cdc8, td_sel =3D 0xffffff0082f7bb00,=20 > td_sleepqueue =3D 0xffffff000721e190, td_turnstile =3D 0xffffff00054699= 00,=20 > td_umtxq =3D 0xffffff008284b500, td_tid =3D 100316, td_sigqueue =3D {sq= _signals =3D { > __bits =3D {0, 0, 0, 0}}, sq_kill =3D {__bits =3D {0, 0, 0, 0}}, sq= _list =3D { > tqh_first =3D 0x0, tqh_last =3D 0xffffff0082999430},=20 > sq_proc =3D 0xffffff0082ae4880, sq_flags =3D 1}, td_flags =3D 4,=20 > td_inhibitors =3D 0, td_pflags =3D 0, td_dupfd =3D 0, td_sqqueue =3D 0,= =20 > td_wchan =3D 0x0, td_wmesg =3D 0x0, td_lastcpu =3D 0 '\0', td_oncpu =3D= 0 '\0',=20 > td_owepreempt =3D 0 '\0', td_tsqueue =3D 0 '\0', td_locks =3D 1, td_rw_= rlocks =3D 0,=20 > td_lk_slocks =3D 0, td_blocked =3D 0x0, td_lockname =3D 0x0, td_contest= ed =3D { > lh_first =3D 0x0}, td_sleeplocks =3D 0xffffffff80cebd40,=20 > td_intr_nesting_level =3D 0, td_pinned =3D 1, td_ucred =3D 0xffffff0010= b4ec00,=20 > td_estcpu =3D 0, td_slptick =3D 0, td_ru =3D {ru_utime =3D {tv_sec =3D = 0,=20 > tv_usec =3D 0}, ru_stime =3D {tv_sec =3D 0, tv_usec =3D 0}, ru_maxr= ss =3D 2044,=20 > ru_ixrss =3D 48, ru_idrss =3D 3352, ru_isrss =3D 512, ru_minflt =3D 1= 86,=20 > ru_majflt =3D 0, ru_nswap =3D 0, ru_inblock =3D 0, ru_oublock =3D 0,=20 > ru_msgsnd =3D 0, ru_msgrcv =3D 0, ru_nsignals =3D 0, ru_nvcsw =3D 13,= =20 > ru_nivcsw =3D 13}, td_incruntime =3D 61985988, td_runtime =3D 6198598= 8,=20 > td_pticks =3D 3, td_sticks =3D 4, td_iticks =3D 0, td_uticks =3D 0, td_= uuticks =3D 0,=20 > td_usticks =3D 0, td_intrval =3D 0, td_oldsigmask =3D {__bits =3D {0, 0= , 0, 0}},=20 > td_sigmask =3D {__bits =3D {0, 0, 0, 0}}, td_generation =3D 26, td_sigs= tk =3D { > ss_sp =3D 0x0, ss_size =3D 0, ss_flags =3D 4}, td_xsig =3D 0, td_prof= il_addr =3D 0,=20 > td_profil_ticks =3D 0, td_name =3D "perl\000l", '\0' = ,=20 > td_fpop =3D 0x0, td_dbgflags =3D 0, td_osd =3D {osd_nslots =3D 0, osd_s= lots =3D 0x0,=20 > osd_next =3D {le_next =3D 0x0, le_prev =3D 0x0}}, td_rqindex =3D 32 '= ',=20 > td_base_pri =3D 128 '\200', td_priority =3D 128 '\200', td_pri_class = =3D 3 '\003',=20 > td_user_pri =3D 129 '\201', td_base_user_pri =3D 129 '\201',=20 > td_pcb =3D 0xffffffff2d73ed50, td_state =3D TDS_RUNNING, td_retval =3D = {23, 1023},=20 > td_slpcallout =3D {c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tq= e_next =3D 0x0,=20 > tqe_prev =3D 0xffffffff0031d340}}, c_time =3D 9773098,=20 > c_arg =3D 0xffffff0082999390, c_func =3D 0xffffffff80561850 ,=20 > c_lock =3D 0x0, c_flags =3D 16, c_cpu =3D 0}, td_frame =3D 0xffffffff= 2d73ec90,=20 > td_kstack_obj =3D 0xffffff00c83a7c80, td_kstack =3D 1844674407017714073= 6,=20 > td_kstack_pages =3D 4, td_altkstack_obj =3D 0x0, td_altkstack =3D 0,=20 > td_altkstack_pages =3D 0, td_critnest =3D 1, td_md =3D {md_spinlock_cou= nt =3D 0,=20 > md_saved_flags =3D 70}, td_sched =3D 0xffffff00829996f0, td_ar =3D 0x= 0,=20 > td_syscalls =3D 1517973, td_lprof =3D {{lh_first =3D 0x0}, {lh_first = =3D 0x0}},=20 > td_dtrace =3D 0x0, td_errno =3D 0} > (kgdb) p td=08 =08=08 =08*td->td_lock > $5 =3D {lock_object =3D {lo_name =3D 0xffffffff80b922d8 "sched lock 0",=20 > lo_flags =3D 720896, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D= 4} > (kgdb) q > ichotolot#=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-nobRallXHZu+eaWhGxwh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkln1F0ACgkQb2iPiv4Uz4cNIwCfRhCIns5QLLoZiaRvVwTihsgb dxkAn0JVn7yk0H44B+SeHT1HtVrZUlND =ZAy3 -----END PGP SIGNATURE----- --=-nobRallXHZu+eaWhGxwh-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 22:53:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50F211065676; Fri, 9 Jan 2009 22:53:58 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id A6F0A8FC19; Fri, 9 Jan 2009 22:53:57 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by ey-out-2122.google.com with SMTP id d26so1039798eyd.7 for ; Fri, 09 Jan 2009 14:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=2SuzEdEipRuhhZGxs0cmrnAmXvHEpQxe36ymNyqEHH4=; b=cOoq2VAqYeQiWwiAmsmVpn34gpRsei6uRXJx8ZYcHIc1pWiF/l3YaOMXnmDroNFzuN sbaEMHoz3fWQYIZFqXGKFOWx92z9PTjlP2+OP8poUbfdR6X6ttBA+ijjCysTEyql0Fh0 LF46LP/w5ZN+aoAzd5QM4pHBNFZB94E3931mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=ZOtHw2SUPXBmdmWpWrshc66uN492lJT8y7mD2SGwI+d2sQBPUGP2hxfrblDZf4xYT4 zs1Lp0kOHM8mVEkwIubh9KdjclMOtJwLvH1wdrkpnqwPRUo1M+jJz5hH4MNg67BrJdXo deCe7WlPQtYlRlcIrXcDVaBLO/qY45+ABSWL8= Received: by 10.210.43.10 with SMTP id q10mr30890387ebq.59.1231541636658; Fri, 09 Jan 2009 14:53:56 -0800 (PST) Received: by 10.210.58.4 with HTTP; Fri, 9 Jan 2009 14:53:56 -0800 (PST) Message-ID: <3cb459ed0901091453i2144419fyede5894ae411a259@mail.gmail.com> Date: Sat, 10 Jan 2009 01:53:56 +0300 From: "Alexander Churanov" To: "Roman Divacky" In-Reply-To: <20090109222211.GA33145@freebsd.org> MIME-Version: 1.0 References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> <20090109222211.GA33145@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Andrew Reilly , Ollivier Robert , Christoph Mallon , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 22:53:58 -0000 Roman, > > clang (clang.llvm.org) supports almost everything now and aims for full > C99 > support. > > pcc aims for full C99 too I believe > > Chris Mallon can comment better but I believe cparser is C99 too > > am I missing something? > This means that I am missing something and that '-pedantic' is all the more important. Sincerely, Alexander Churanov From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 23:03:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2FD8106564A for ; Fri, 9 Jan 2009 23:03:09 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 80B8D8FC12 for ; Fri, 9 Jan 2009 23:03:09 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 1AF369CB1B7; Sat, 10 Jan 2009 00:02:59 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y11odaw7I2qi; Sat, 10 Jan 2009 00:02:52 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id B29B09CB298; Sat, 10 Jan 2009 00:02:52 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n09N2qS2038191; Sat, 10 Jan 2009 00:02:52 +0100 (CET) (envelope-from rdivacky) Date: Sat, 10 Jan 2009 00:02:52 +0100 From: Roman Divacky To: Alexander Churanov Message-ID: <20090109230252.GA37323@freebsd.org> References: <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> <20090109222211.GA33145@freebsd.org> <3cb459ed0901091453i2144419fyede5894ae411a259@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3cb459ed0901091453i2144419fyede5894ae411a259@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Andrew Reilly , Ollivier Robert , Christoph Mallon , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 23:03:10 -0000 On Sat, Jan 10, 2009 at 01:53:56AM +0300, Alexander Churanov wrote: > Roman, > > > > > clang (clang.llvm.org) supports almost everything now and aims for full > > C99 > > support. > > > > pcc aims for full C99 too I believe > > > > Chris Mallon can comment better but I believe cparser is C99 too > > > > am I missing something? > > > This means that I am missing something and that '-pedantic' is all the more > important. well.... clang DEFINITELY aims to be drop-in replacement for gcc, ie. it supports (aims to support) all the gcc extensions hence no -pedantic needed to be compatible with gcc and clang at the same time pcc discusses this now (http://pcc.ludd.ltu.se/jira/browse/PCC-18) from what Chris Mallon said I believe it's cparser's goal too to be drop-in replacement for gcc ie. no strong need for -pedantic as far as I can tell :) honestly... we need some of the gnu99 features and it's only a good thing that the alternative compilers support that, I also have a gut feeling that (as it was in the past) some of the gnu99 things might appear in the next C standard From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 23:37:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC2451065670; Fri, 9 Jan 2009 23:37:29 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id 19AE38FC0C; Fri, 9 Jan 2009 23:37:28 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by ewy14 with SMTP id 14so11718939ewy.19 for ; Fri, 09 Jan 2009 15:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=z1PqBseed8c1YmsZ/bYB9EGc12/8+wS8NvImibfBllg=; b=AzXfX7p7MxnE05feY8LQCKtzXGjdixLzv/hMmgTc2LzFxAqJC6xAr3XdAODvgBvhls 9pyNLJjY2E81/wGovcOHt6uYE5CwyV4EQOJGX0e+mplrmKDOz8oF/wWKkVW8XwpVcIjP 9D/bE1r8bCC3vuPYQKUoy5M27EHeIqrOSBOik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=X6r/9Dr6OoNrFldutf+4R/pdWWIucoBnmwDfVuaHuCkIkiH6NKuEt9PuZW+jXZruBM 0a8fHx8Q7JHJFkS7wuQcMXYFvdv8+G22QMF0SoJqn6E3pqGS1/vhnjupP7c6eRSKuYAz /oQj2oJSPCkfpioWJtuiizFSTQtSmNv0E0i+M= Received: by 10.210.109.10 with SMTP id h10mr30832368ebc.110.1231544248208; Fri, 09 Jan 2009 15:37:28 -0800 (PST) Received: by 10.210.58.4 with HTTP; Fri, 9 Jan 2009 15:37:28 -0800 (PST) Message-ID: <3cb459ed0901091537ld9858beq9a8428be9c900fab@mail.gmail.com> Date: Sat, 10 Jan 2009 02:37:28 +0300 From: "Alexander Churanov" To: "Roman Divacky" In-Reply-To: <20090109230252.GA37323@freebsd.org> MIME-Version: 1.0 References: <20090108233311.GA69883@keltia.freenix.fr> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> <20090109222211.GA33145@freebsd.org> <3cb459ed0901091453i2144419fyede5894ae411a259@mail.gmail.com> <20090109230252.GA37323@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Andrew Reilly , Ollivier Robert , Christoph Mallon , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 23:37:30 -0000 2009/1/10 Roman Divacky > ie. no strong need for -pedantic as far as I can tell :) > > honestly... we need some of the gnu99 features and it's only a good thing > that > the alternative compilers support that, I also have a gut feeling that (as > it > was in the past) some of the gnu99 things might appear in the next C > standard > > Well, since standards aim to document existing practice and not to invent things, your assumption sounds very reasonable. However, adoption of gcc extensions means that behavior of gcc is de-facto standard, more respected than ISO, for a group of developers. Sincerely, Alexander Churanov From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 00:46:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C943106564A for ; Sat, 10 Jan 2009 00:46:10 +0000 (UTC) (envelope-from rmtodd@servalan.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 08C918FC0A for ; Sat, 10 Jan 2009 00:46:09 +0000 (UTC) (envelope-from rmtodd@servalan.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 927C4CB1; Fri, 9 Jan 2009 19:46:09 -0500 (EST) Received: from rmtodd by servalan.servalan.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LLRLO-0003b8-PM; Fri, 09 Jan 2009 18:04:50 -0600 Date: Fri, 9 Jan 2009 18:04:50 -0600 From: Richard Todd To: Joe Marcus Clarke Message-ID: <20090110000450.GA13656@ichotolot.servalan.com> References: <20090109004853.GA34384@ichotolot.servalan.com> <1231541342.56664.19.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1231541342.56664.19.camel@shumai.marcuscom.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: Recent changes to pseudofs causing panics -- leaking a vnode lock? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 00:46:10 -0000 On Fri, Jan 09, 2009 at 05:49:02PM -0500, Joe Marcus Clarke wrote: > I believe I have fixed this in HEAD. Kib gave his review and approval, > and the fix really should prevent this hang. Please report back if you > still see the problem. Okay, I've gone ahead and booted a new kernel with the new pseudofs code, and will let you know if I see any problems. Richard From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 01:05:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88D46106566C; Sat, 10 Jan 2009 01:05:53 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id E99C18FC1A; Sat, 10 Jan 2009 01:05:52 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so65252ugs.39 for ; Fri, 09 Jan 2009 17:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=ZzA1Wz29aS3LAVQRKEa5MI+v4M9CzdAJPymEW2M9r5U=; b=tRs5z+NZAwjm/gTEK9IyO+IjqYFgW1PkhAXXiCVYHOfYxAWpkG5xIYxKFlF7CFiXti v7wb6PnSMKJZGIdKwkqakl6WSh2/r1BKaXMwnMBiVO5R6aYJSgUmDQjNpf81rOKb8Elf m9WCCEdkQ/GJBtIK6cEuwWNFt06xNRATiv+xA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=a7jQoTw5wZVgHXw94y7U8BvchFlNX2UKnf/lcFf9hLsE6Q2ASLsD21g3gUmhxUzKY3 1TiHP4uLCvzzhWRFa4GolnO6fMcXvTaihJ1jC7luui0r2qr+wfj2vZkJne9nVF/c28lg ZfN1AbR4pCfCZ9Twjg3TCtVzuQaAzrFte+2dQ= Received: by 10.67.89.1 with SMTP id r1mr7343213ugl.82.1231549551213; Fri, 09 Jan 2009 17:05:51 -0800 (PST) Received: by 10.67.88.9 with HTTP; Fri, 9 Jan 2009 17:05:51 -0800 (PST) Message-ID: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> Date: Fri, 9 Jan 2009 17:05:51 -0800 From: "Garrett Cooper" To: "Doug Barton" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: FreeBSD Current Subject: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 01:05:54 -0000 On Fri, Jan 9, 2009 at 2:05 PM, Garrett Cooper wrote: > On Fri, Jan 9, 2009 at 1:40 PM, Doug Barton wrote: >> Garrett Cooper wrote: >>> Thanks for the tips Doug -- I'll give them a shot of course... >> >> Glad I could help. The one thing I forgot to mention is to try the >> nvidia-settings app if you have not already done so. There are various >> things there that you can tweak that might yield better results. >> >> Doug > > I did in fact set everything up via nvidia-settings. I'm running > some stress tests right now to see whether or not I can simulate the > issue -- it doesn't appear to be as straightforward as I thought.. > -Garrett > I believe my actual problem with panicking is related to gdb, not X11. So the actual problem is two-fold: - X11 livelocks, where I can login via ssh and kill . - When I use gdb -p, it prints out the same message reported here: . The only thing is that if I press `y' on the first go-around, the machine hardlocks on the first try with hitting `y'. If I hit `n' so gdb coredumps, I can either go on my merry way, or go back to the confirmation dialog. If I hit it again, it doesn't hardlock. It does hardlock though, and for whatever reason my PC speaker beeps, and I have to warm boot it. I haven't been able to get a kernel dump though, so something else mysteriously is going on that I can't track. So, just to simplify: first_try := True while gdb is running: if prompt_for_coredump() and first_try is True: panic() first_try := False Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 01:07:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA94A106566C for ; Sat, 10 Jan 2009 01:07:43 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC168FC19 for ; Sat, 10 Jan 2009 01:07:42 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so3415908bwz.19 for ; Fri, 09 Jan 2009 17:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ARu64j6IKa0oCIRJd9AjOm9xPr4XNaDQV2+dVGwZHz4=; b=DaKme8GyFHJ9z0QdSefjYyootYvBARrzi5d6tegEdDm6TD4LO7fScbsOFK493JcIDt No9sNXVFjYe+/++Lbx32Jr7g3SiRZR9ynKgCsMxKZQZfU/XCTGL2oKbtKx0sJBUgJk3F PKTg0+caLPhjAP8Si8n8YoJ3Ahk9BFAPbudtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ocCfTku3JKJesJvWXaJWk9x+zlho0xpJHTyrSXNKSiD24fOGulrjNP+08ZoFTMRUCR RrQJvKSchYpgCs99JFRMA2KXkT34WEzuUpVKw4AF0OD3M392XeKs2ZlFJS4uQonDuiAL O34jxgN7jb8dZGBe8BqOiP93h9sG5UhoGPdRQ= Received: by 10.223.124.137 with SMTP id u9mr19115660far.96.1231549661951; Fri, 09 Jan 2009 17:07:41 -0800 (PST) Received: by 10.67.88.9 with HTTP; Fri, 9 Jan 2009 17:07:41 -0800 (PST) Message-ID: <7d6fde3d0901091707u7e2ee080l75d8567a4093144d@mail.gmail.com> Date: Fri, 9 Jan 2009 17:07:41 -0800 From: "Garrett Cooper" To: "Joe Marcus Clarke" In-Reply-To: <1231541342.56664.19.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20090109004853.GA34384@ichotolot.servalan.com> <1231541342.56664.19.camel@shumai.marcuscom.com> Cc: Richard Todd , freebsd-current@freebsd.org Subject: Re: Recent changes to pseudofs causing panics -- leaking a vnode lock? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 01:07:44 -0000 On Fri, Jan 9, 2009 at 2:49 PM, Joe Marcus Clarke wrote: > On Thu, 2009-01-08 at 18:48 -0600, Richard Todd wrote: >> I've noticed that ever since updating to a kernel after the recent changes >> to the pseudofs code late last month, that I've occasionally gotten the >> following sort of panic: >> >> System call readlink returning with the following locks held: >> exclusive lockmgr pseudofs (pseudofs) r = 0 (0xffffff00ba581cc8) locked @ /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:193 >> panic: witness_warn >> >> The line in question is the one I marked by an arrow in this chunk of the >> pfs_vncache_alloc code: >> if ((pn->pn_flags & PFS_PROCDEP) != 0) >> (*vpp)->v_vflag |= VV_PROCDEP; >> pvd->pvd_vnode = *vpp; >> VN_LOCK_AREC(*vpp); >> vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); <==== this lock here >> error = insmntque(*vpp, mp); >> >> So somehow, a vnode is getting locked here and not getting unlocked. >> I suspect the code in the retry2: loop later, simply because that's >> the code that got added in the late December commits, but I'm not >> clear on how exactly. I've tried littering the code with extra >> printfs to try to clarify what's going on, but alas, I'm still not >> really sure what's going on. I do have a good coredump that I can get >> info out of, if someone can suggest to me what would be useful things >> to dump. Anyway, here's the patch for the debugging printfs I added, >> and the console messages produced by those printfs from the most >> recent coredump/panic. The console msgs do seem to indicate some sort >> of race condition going on, though, as they seem to show two or more processes >> simultaneously hitting the pseudofs code and hitting my debugging print >> statements (alas, making the console log rather a confused mess.) > > I believe I have fixed this in HEAD. Kib gave his review and approval, > and the fix really should prevent this hang. Please report back if you > still see the problem. > > Joe Joe, When did you do this commit / what's the SVN revision #? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 01:23:06 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EE441065672 for ; Sat, 10 Jan 2009 01:23:06 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 10D6B8FC12 for ; Sat, 10 Jan 2009 01:23:05 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n0A1Nks8046803; Fri, 9 Jan 2009 20:23:46 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Garrett Cooper In-Reply-To: <7d6fde3d0901091707u7e2ee080l75d8567a4093144d@mail.gmail.com> References: <20090109004853.GA34384@ichotolot.servalan.com> <1231541342.56664.19.camel@shumai.marcuscom.com> <7d6fde3d0901091707u7e2ee080l75d8567a4093144d@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gzd4EhIH96+Zfc6NzyEY" Organization: FreeBSD, Inc. Date: Fri, 09 Jan 2009 20:23:10 -0500 Message-Id: <1231550590.56664.21.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: freebsd-current@FreeBSD.org, Richard Todd Subject: Re: Recent changes to pseudofs causing panics -- leaking a vnode lock? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 01:23:06 -0000 --=-gzd4EhIH96+Zfc6NzyEY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-01-09 at 17:07 -0800, Garrett Cooper wrote: > On Fri, Jan 9, 2009 at 2:49 PM, Joe Marcus Clarke wr= ote: > > On Thu, 2009-01-08 at 18:48 -0600, Richard Todd wrote: > >> I've noticed that ever since updating to a kernel after the recent cha= nges > >> to the pseudofs code late last month, that I've occasionally gotten th= e > >> following sort of panic: > >> > >> System call readlink returning with the following locks held: > >> exclusive lockmgr pseudofs (pseudofs) r =3D 0 (0xffffff00ba581cc8) loc= ked @ /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:193 > >> panic: witness_warn > >> > >> The line in question is the one I marked by an arrow in this chunk of = the > >> pfs_vncache_alloc code: > >> if ((pn->pn_flags & PFS_PROCDEP) !=3D 0) > >> (*vpp)->v_vflag |=3D VV_PROCDEP; > >> pvd->pvd_vnode =3D *vpp; > >> VN_LOCK_AREC(*vpp); > >> vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); <=3D=3D=3D=3D this loc= k here > >> error =3D insmntque(*vpp, mp); > >> > >> So somehow, a vnode is getting locked here and not getting unlocked. > >> I suspect the code in the retry2: loop later, simply because that's > >> the code that got added in the late December commits, but I'm not > >> clear on how exactly. I've tried littering the code with extra > >> printfs to try to clarify what's going on, but alas, I'm still not > >> really sure what's going on. I do have a good coredump that I can get > >> info out of, if someone can suggest to me what would be useful things > >> to dump. Anyway, here's the patch for the debugging printfs I added, > >> and the console messages produced by those printfs from the most > >> recent coredump/panic. The console msgs do seem to indicate some sort > >> of race condition going on, though, as they seem to show two or more p= rocesses > >> simultaneously hitting the pseudofs code and hitting my debugging prin= t > >> statements (alas, making the console log rather a confused mess.) > > > > I believe I have fixed this in HEAD. Kib gave his review and approval, > > and the fix really should prevent this hang. Please report back if you > > still see the problem. > > > > Joe >=20 > Joe, > When did you do this commit / what's the SVN revision #? $FreeBSD: head/sys/fs/pseudofs/pseudofs_vncache.c 186981 2009-01-09 22:06:48Z marcus $ Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-gzd4EhIH96+Zfc6NzyEY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkln+H0ACgkQb2iPiv4Uz4c3WgCgjKUq+jrxwm2JwAJLyRKqft02 K4wAoJh0N3Z4GFSYzTP0hQ8VpMyADYvy =S1zJ -----END PGP SIGNATURE----- --=-gzd4EhIH96+Zfc6NzyEY-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 01:25:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE24A1065670 for ; Sat, 10 Jan 2009 01:25:15 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id 40A2C8FC18 for ; Sat, 10 Jan 2009 01:25:14 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by ewy14 with SMTP id 14so11754166ewy.19 for ; Fri, 09 Jan 2009 17:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=R++fPP/FFVQeqGSEFZ8+VqSl6RksJQyXAlUmxJ1mj+c=; b=u+MLr3rcnKotUx822LOkWTcLevssXGB4TT/GV7h3xpJG5Lq1E9PP3sbaA5x9Yh0k0f tw25nzWLsIXJiPxHFiSrdHEzBMLhjaWvozUbB4IB1uBKqWh/OYsmi5ASuS6IE40BwgqA O7QxgB9lJp7PN4LFQuXVLSE62gev7FbdQbHqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=EYKdJRn1gY3vGWWIQ+ELWk8zcZH9HrGHUyS+IqWGYGshp3nY/Hg0K9M1y944oz3GrT iydl7rZlYdyS+0dEYvpEx95YN888kBpJmVRAkyEPylWevoX4lsTwW5UK+Rk+PHEN9atU fBxn0uv4TFO0NsNEo6O1cPUdAcOO2bNKakxPk= Received: by 10.210.76.19 with SMTP id y19mr30979295eba.52.1231550714166; Fri, 09 Jan 2009 17:25:14 -0800 (PST) Received: by 10.210.58.4 with HTTP; Fri, 9 Jan 2009 17:25:14 -0800 (PST) Message-ID: <3cb459ed0901091725p57e19768w16fdcc1ec3bde19@mail.gmail.com> Date: Sat, 10 Jan 2009 04:25:14 +0300 From: "Alexander Churanov" To: "Alexander Leidinger" In-Reply-To: <20081113080934.18107pb6oxoa9m74@webmail.leidinger.net> MIME-Version: 1.0 References: <3cb459ed0808221700w335b0906g6901d8b8bec4dad9@mail.gmail.com> <200808241415.31812.mitchell@wyatt672earp.force9.co.uk> <6a7033710808241239p1cbdc7adwd4f87814b428b10b@mail.gmail.com> <3cb459ed0808241958v552eafejf7841f0f9993928e@mail.gmail.com> <3cb459ed0811110616t76235e72n24f2411a324a9807@mail.gmail.com> <3cb459ed0811110629g5c7cef8ascb024a9c1a920efa@mail.gmail.com> <20081112083120.18545lxnzm0odc84@webmail.leidinger.net> <3cb459ed0811120652m363470e0i823c451803516e5f@mail.gmail.com> <20081113080934.18107pb6oxoa9m74@webmail.leidinger.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Unicode-based FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 01:25:16 -0000 Folks, This is a short status update on UTF-8 support for syscons. Mainly, output path works but is not customizable yet. Input path, APIs for user-mode and user-mode applications are not completed. I feel, however, that encoding the keyboard input to UTF-8 is the only real bottleneck for me. ioctls and user-mode applications require some routine and very predictable work. Probably, all of this is doable in 8.0 timeframe. I've updated the wiki with current status and brief description of unicode: http://wiki.freebsd.org/SysconsUnicodeProject Sincerely, Alexander Churanov From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 03:18:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81C991065673 for ; Sat, 10 Jan 2009 03:18:47 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 440258FC18 for ; Sat, 10 Jan 2009 03:18:47 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so11117273rvf.43 for ; Fri, 09 Jan 2009 19:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=CWqsLMTb1qJYg3hB9gl9SYusi+Pw3rzfHjq4nCtXct0=; b=vqtiDZPlL2YxXN2Gzq7qnnXOpdkJ4lNt8hr2D+dRodvWGW691zeLeID47xoaN16Wk7 Tbi5Q+qFgM56Nh2sZf6Ep3IFM1qoko3ji9T4k/eiiX/AmPVaCy7U3rnGQGwQirwZbi4M lySd/sVVAOF7E7ybeVzQJ/QqO/e2eg7SuuMII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=b8I+RuaOaekYK1ZrROLtp4NgqCQavb5cqieUWt3s4Hbr7hRewKIcolGho9Z/ReV4nh SQOukSN5zA8SkFmb8eS9NbyKhygHT3fewUjef/WZWOknKrYrY7s3enH5W/AMUf6sxrjj ooET8eRVauxXjvM49C8F3mcQiMD8Vhot09FWA= Received: by 10.141.116.17 with SMTP id t17mr13072621rvm.239.1231557526944; Fri, 09 Jan 2009 19:18:46 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id c20sm2884582rvf.8.2009.01.09.19.18.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Jan 2009 19:18:45 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.14.3/8.14.3) with ESMTP id n0A3Idsf039039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2009 12:18:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.14.3/8.14.3/Submit) id n0A3Id9J039038; Sat, 10 Jan 2009 12:18:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 10 Jan 2009 12:18:39 +0900 From: Pyun YongHyeon To: Kim Culhan Message-ID: <20090110031839.GK30747@cdnetworks.co.kr> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> <20090109061032.GF30747@cdnetworks.co.kr> <89dbfdc30901091243w1d01ab59mc2ade81e65e51c5d@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <89dbfdc30901091243w1d01ab59mc2ade81e65e51c5d@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: msk Marvell Yukon 88E8038 hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 03:18:48 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 09, 2009 at 03:43:38PM -0500, Kim Culhan wrote: > On Fri, Jan 9, 2009 at 1:10 AM, Pyun YongHyeon wrote: > > On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote: > > > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > > > > On Thu, Jan 08, 2009 at 02:36:48AM -0500, Kim Culhan wrote: > > > > > On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > > > > > > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > > > > > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > > > > > > > > > > > Not necessarily at each hang but sometimes coincident, this is > > > > > > > intermittently output to the console: > > > > > > > > > > > > > > in_cksum_skip: out of data by 56952 > > > > > > > > > > > > > > The above is also output to the console at times when receiving a > > > > > > > character through ssh > > > > > > > to a shell. > > > > > > > > > > > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > > > > > > running 7.1-RELEASE. > > [deleted] > > > Ok, then how about disabling TSO/Tx checksum offload? > > (eg. ifconfig msk0 -tso -txcsum) > > This stops the messages: in_cksum_skip: out of data by 56952 Ok, would you try attached patch? -- Regards, Pyun YongHyeon --YiEDa0DAkWCtVeE4 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="msk.csum.diff" Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 186998) +++ sys/dev/msk/if_msk.c (working copy) @@ -2608,17 +2608,14 @@ */ if (m->m_pkthdr.len < MSK_MIN_FRAMELEN && (m->m_pkthdr.csum_flags & CSUM_TCP) != 0) { - uint16_t csum; - m = m_pullup(m, offset + sizeof(struct tcphdr)); if (m == NULL) { *m_head = NULL; return (ENOBUFS); } - csum = in_cksum_skip(m, ntohs(ip->ip_len) + offset - - (ip->ip_hl << 2), offset); *(uint16_t *)(m->m_data + offset + - m->m_pkthdr.csum_data) = csum; + m->m_pkthdr.csum_data) = in_cksum_skip(m, + m->m_pkthdr.len, offset); m->m_pkthdr.csum_flags &= ~CSUM_TCP; } if ((m->m_pkthdr.csum_flags & CSUM_TSO) != 0) { --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 02:23:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F33B11065673 for ; Sat, 10 Jan 2009 02:23:44 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id DC7F98FC27 for ; Sat, 10 Jan 2009 02:23:44 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 8BBB733C6C; Fri, 9 Jan 2009 17:53:23 -0800 (PST) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 16B2333C64; Fri, 9 Jan 2009 17:53:23 -0800 (PST) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18791.65426.128568.526167@almost.alerce.com> Date: Fri, 9 Jan 2009 17:53:22 -0800 To: freebsd-current@freebsd.org In-Reply-To: <1de79840901080935s130f647r36815df468a9220b@mail.gmail.com> References: <1de79840901080935s130f647r36815df468a9220b@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 22.1.50.1 X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Sat, 10 Jan 2009 04:07:50 +0000 Cc: Michael Proto , Alexander Best Subject: Re: patch to fix burncd bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 02:23:45 -0000 Michael Proto writes: > On Thu, Jan 8, 2009 at 12:13 PM, Alexander Best < > alexbestms@math.uni-muenster.de> wrote: > > > could somebody please commit the following patch to dev/ata? it fixes a > > nasty > > bug during fixation in burncd. the bug exists in RELENG6, RELENG7 and HEAD > > (and maybe RELENG5): > > > > http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch > > > > the whole PR can be found here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 > > > > > > I second this request. A fix would be nice, this bug has bitten me in both > 7-STABLE and 8-CURRENT :) I have a mac pro running 7.1-PRERELEASE system (not sure when I last updated it) on which burncd seems to successfully burn the data but then fails while fixating. I applied the above patch by hand, with a little bit of fuzz, and now it fails to burn the data but fixating no longer bombs out. Here's a section of a script session (edited to remove the bulk of the written lines...). (delicious)[5:37pm]~>>sudo burncd -e data iso/7.0-RELEASE-amd64-livefs.iso fixate Password: next writeable LBA 0 writing from file iso/7.0-RELEASE-amd64-livefs.iso size 279174 KB written this track 32 KB (0%) total 32 KB written this track 64 KB (0%) total 64 KB [...] written this track 1152 KB (0%) total 1152 KB Input/output error fixating CD, please wait.. (delicious)[5:40pm]~>> I think that I got the patch applied properly, I wonder if something's changed to obsolete it? g. From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 03:22:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43AC2106566B for ; Sat, 10 Jan 2009 03:22:40 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from web32708.mail.mud.yahoo.com (web32708.mail.mud.yahoo.com [68.142.207.252]) by mx1.freebsd.org (Postfix) with SMTP id E72548FC0C for ; Sat, 10 Jan 2009 03:22:39 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: (qmail 72008 invoked by uid 60001); 10 Jan 2009 03:22:39 -0000 X-YMail-OSG: _ehTDHwVM1kWGh9iUNdJBi1eVY.PMq0ea9lECwHhcnL1jNPu07LZV402IvsfjoqAjZ4P4XW4E64evSbHeZ0za.kIKOyIZzGWMnPQ8OtvEvC9g9lA0cFFF9kseb_5MMq6qVTbZvpkwx8vR1ysSt.N7ZDYRFp1usm8_yk_rRsVhrCgzi3IZ2.z2uKW_sra Received: from [190.157.124.207] by web32708.mail.mud.yahoo.com via HTTP; Fri, 09 Jan 2009 19:22:38 PST X-RocketYMMF: giffunip X-Mailer: YahooMailRC/1156.77 YahooMailWebService/0.7.260.1 Date: Fri, 9 Jan 2009 19:22:38 -0800 (PST) From: "Pedro F. Giffuni" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <61484.71762.qm@web32708.mail.mud.yahoo.com> X-Mailman-Approved-At: Sat, 10 Jan 2009 04:19:15 +0000 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 03:22:41 -0000 FWIW, I had some informal talk with brooks@ about this at EuroBSDCon: - groff(1) needs a C++ compiler so clang is not (yet) an option for the time being we will have to live with GCC or llvm-gcc. Some things we should consider: - Replacing groff with something less restricted that doesn't require C++: Heirloom-doctools may be an option. - More extensive testing of gcc-llvm: A USE_GCC= llvm for the ports tree would be nice. - Remove gcc from the base and make the compilation depend on a packaged C.. somewhat like was made with perl. binutils is yet another issue: I am hoping this will be updated to the latest GPL2 version while a new alternative is developed. Perhaps a combination of RH elfutils and our own libelf efforts would make a viable alternative. just my $0.02, Pedro. From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 06:45:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66178106566C for ; Sat, 10 Jan 2009 06:45:35 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id ECA778FC12 for ; Sat, 10 Jan 2009 06:45:34 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.37,243,1231110000"; d="scan'208";a="266747226" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 10 Jan 2009 07:45:33 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 16BBC1B075D; Sat, 10 Jan 2009 07:45:33 +0100 (CET) Date: Sat, 10 Jan 2009 07:45:32 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: <18791.65426.128568.526167@almost.alerce.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: George Hartzell Subject: Re: patch to fix burncd bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 06:45:35 -0000 hmmm...that's odd because the only changes the patch makes deal with fixating the cd. maybe you could try updating your sources to either 7-STABLE or 7.1-RELEASE, apply the patch and recompile your kernel. it might be a good idea to also install a fresh version of burncd. i just downloaded ata-queue.c and atapi-cd.c that shipped with 7.1-RELEASE and the patch applies without any problems. so your revision of both files isn't up to date. please also keep in mind that this patch was made for 8-CURRENT. i don't think it's been tested under 7 so far. cheers. alex George Hartzell schrieb am 2009-01-10: > Michael Proto writes: > > On Thu, Jan 8, 2009 at 12:13 PM, Alexander Best < > > alexbestms@math.uni-muenster.de> wrote: > > > could somebody please commit the following patch to dev/ata? it > > > fixes a > > > nasty > > > bug during fixation in burncd. the bug exists in RELENG6, > > > RELENG7 and HEAD > > > (and maybe RELENG5): > > > http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch > > > the whole PR can be found here: > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 > > I second this request. A fix would be nice, this bug has bitten me > > in both > > 7-STABLE and 8-CURRENT :) > I have a mac pro running 7.1-PRERELEASE system (not sure when I last > updated it) on which burncd seems to successfully burn the data but > then fails while fixating. > I applied the above patch by hand, with a little bit of fuzz, and now > it fails to burn the data but fixating no longer bombs out. Here's a > section of a script session (edited to remove the bulk of the written > lines...). > (delicious)[5:37pm]~>>sudo burncd -e data > iso/7.0-RELEASE-amd64-livefs.iso fixate > Password: > next writeable LBA 0 > writing from file iso/7.0-RELEASE-amd64-livefs.iso size 279174 KB > written this track 32 KB (0%) total 32 KB > written this track 64 KB (0%) total 64 KB > [...] > written this track 1152 KB (0%) total 1152 KB > Input/output error > fixating CD, please wait.. > (delicious)[5:40pm]~>> > I think that I got the patch applied properly, I wonder if > something's > changed to obsolete it? > g. From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 06:58:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC05B106566B for ; Sat, 10 Jan 2009 06:58:52 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from istc.kiev.ua (wolf.istc.kiev.ua [193.108.236.1]) by mx1.freebsd.org (Postfix) with ESMTP id 974C88FC16 for ; Sat, 10 Jan 2009 06:58:52 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from [91.123.146.100] (helo=ravenloft.kiev.ua) by istc.kiev.ua with esmtp (Exim 4.52) id 1LLXo1-00025F-T1; Sat, 10 Jan 2009 08:58:50 +0200 Date: Sat, 10 Jan 2009 08:58:47 +0200 From: Alex Kozlov To: "Pedro F. Giffuni" , freebsd-current@freebsd.org, spam@rm-rf.kiev.ua Message-ID: <20090110065847.GA28029@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Spam-Report: Content analysis detailz: (0.0 points, 10.0 required) Cc: Subject: Re: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 06:58:53 -0000 On Fri, Jan 09, 2009 at 07:22:38PM -0800, Pedro F. Giffuni wrote: > - groff(1) needs a C++ compiler so clang is not (yet) an option Also devd. -- Adios From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 08:08:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65B4B106566C for ; Sat, 10 Jan 2009 08:08:36 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0818FC1C for ; Sat, 10 Jan 2009 08:08:35 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so4109289yxb.13 for ; Sat, 10 Jan 2009 00:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=TPM52Jl79eCOiyvf8CJBoiaxhd9aK6oIKWYyAsFEgHI=; b=bMfzXLNLIkH3+fTryYEMt/NxvDC7wHEmpuS8qJ61fQ2YMDOwGN5gp62N8Hb4J3786z PwGXMvueobuL0zaDVK761KpfCjHQto61pjnHMOIPP/lUY/HzuBmNIEfJuEm/QQUmhIc2 RqOF89RN1LmRfKPkvEQlTMJTZSFi+NF8N5XCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=mLQKF2Bq4OYpIEU1TBSmw958W1Zgq4Z6oq2jNoileewv6g/OTmRnAq2u/0ozV23GPF BPr0FZEBwxeGHnPN59kkEzDrg1an3Vux2FVI1d8QUngeRPUFkEi6GwtV5bLy6c6UCK0V /iEVW0rpJenb5gH2DvoTlcvkWIIyQ3hv/73uU= Received: by 10.90.68.20 with SMTP id q20mr12583692aga.75.1231573291413; Fri, 09 Jan 2009 23:41:31 -0800 (PST) Received: by 10.90.36.7 with HTTP; Fri, 9 Jan 2009 23:41:31 -0800 (PST) Message-ID: Date: Sat, 10 Jan 2009 02:41:31 -0500 From: "Dylan Cochran" Sender: heliocentric@gmail.com To: "Tim Kientzle" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4965927D.1060507@freebsd.org> X-Google-Sender-Auth: f4e0b8e47f27dc73 Cc: freebsd-current@freebsd.org Subject: Re: Extattr portability? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 08:08:36 -0000 On Fri, Jan 9, 2009 at 10:27 AM, Robert Watson wrote: > On Wed, 7 Jan 2009, Tim Kientzle wrote: > >> I'm trying to complete the extended attribute support in libarchive. >> There are a handful of odd issues that arise which I think I could resolve >> if I knew of good use cases. >> >> Anyone here actually use extended attributes? (Note that ACLs are handled >> separately.) What software? What information do you store there? >> >> If you could benefit from being able to move extended attributes between >> FreeBSD and other systems, I'm especially interested. > > Most (all) of the use of extended attributes that I'm aware of on FreeBSD > relates to security extensions, be it ACLs, MAC labels (almost always in the > system namespace) for various policies, etc. Mac OS X is now using extended > attributes in quite a few more ways, however, so you may want to investigate > a bit on that side. Most uses I'm aware of aren't intended to be portable. Another is BeOS/Haiku, which used attributes heavily. I have been waiting for this work for a while. What I don't really mind is whether it is portable, what I really care about is full retention of the user namespace. No silent truncating of an attribute because of perceived need for a size restriction, assuming the contents are only ASCII, etc. If setextattr can set it on a file, tar should be able to retain it as is, and extract it so getextattr later is identical. If that can be done using an already defined extended attribute format, great! If it can't, I can live with an incompatible tar format. That's my 2 cents on the matter, I use extended attributes now for storing cached mime-type, and sha256/md5 for checksum purposes. I have plans sometime in the future to create a patch for ROX-Filer to check for thumbnail and icon attributes, and use them instead of the current cache scheme. Being able to tar up the directory, and then extract it and keep the thumbnail/icon as expected, would greatly improve user experience, in my opinion. From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 08:40:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BAD31065670 for ; Sat, 10 Jan 2009 08:40:19 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by mx1.freebsd.org (Postfix) with ESMTP id D83C18FC12 for ; Sat, 10 Jan 2009 08:40:18 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh01-2.mail.saunalahti.fi (Postfix) with SMTP id CAE151AC54; Sat, 10 Jan 2009 10:40:17 +0200 (EET) Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A03810C814C; Sat, 10 Jan 2009 10:40:17 +0200 Received: from a91-153-125-115.elisa-laajakaista.fi (a91-153-125-115.elisa-laajakaista.fi [91.153.125.115]) by emh04.mail.saunalahti.fi (Postfix) with SMTP id 41A8C41BEB; Sat, 10 Jan 2009 10:40:13 +0200 (EET) Date: Sat, 10 Jan 2009 10:40:13 +0200 From: Jaakko Heinonen To: George Hartzell Message-ID: <20090110084012.GA1979@a91-153-125-115.elisa-laajakaista.fi> References: <1de79840901080935s130f647r36815df468a9220b@mail.gmail.com> <18791.65426.128568.526167@almost.alerce.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18791.65426.128568.526167@almost.alerce.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Antivirus: VAMS Cc: Michael Proto , Alexander Best , freebsd-current@freebsd.org Subject: Re: patch to fix burncd bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 08:40:19 -0000 Hi, On 2009-01-09, George Hartzell wrote: > I have a mac pro running 7.1-PRERELEASE system (not sure when I last > updated it) on which burncd seems to successfully burn the data but > then fails while fixating. > > I applied the above patch by hand, with a little bit of fuzz, and now > it fails to burn the data but fixating no longer bombs out. It can't see how it could be possible that the patch (correctly applied) causes this. Are you sure that this is repeatable behavior and burning always works with an unpatched kernel? Does dmesg show any error messages after failed burn? -- Jaakko From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 11:33:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8060A106564A for ; Sat, 10 Jan 2009 11:33:22 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9858FC14 for ; Sat, 10 Jan 2009 11:33:22 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 013D79CB204; Sat, 10 Jan 2009 12:33:10 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsKk76DdIAj6; Sat, 10 Jan 2009 12:33:08 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id BE4B59CB2CC; Sat, 10 Jan 2009 12:33:08 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n0ABX8x0026335; Sat, 10 Jan 2009 12:33:08 +0100 (CET) (envelope-from rdivacky) Date: Sat, 10 Jan 2009 12:33:08 +0100 From: Roman Divacky To: "Pedro F. Giffuni" Message-ID: <20090110113308.GA25584@freebsd.org> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61484.71762.qm@web32708.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 11:33:22 -0000 On Fri, Jan 09, 2009 at 07:22:38PM -0800, Pedro F. Giffuni wrote: > FWIW, > > I had some informal talk with brooks@ about this at EuroBSDCon: > > - groff(1) needs a C++ compiler so clang is not (yet) an option for the time being we will have to live with GCC or llvm-gcc. I guess once the switch happens we are going to live for some with both gcc and clang/llvm. I also guess that by the time the switch happens clang is going to be full C++ capable :) From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 11:47:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D78B1065680 for ; Sat, 10 Jan 2009 11:47:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id A661A8FC0A for ; Sat, 10 Jan 2009 11:47:44 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=rkKhwMqNWssA:10 a=TgyOnVPZ2v0A:10 a=nklthdr5v5AUSfVrlghuJA==:17 a=6I5d2MoRAAAA:8 a=m86m2A8C71dBUahhnLoA:9 a=k8ld-edfJHJW1HaPj36hZ2n7g3sA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1176053229; Sat, 10 Jan 2009 12:47:43 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 10 Jan 2009 12:50:04 +0100 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901101250.06293.hselasky@c2i.net> Cc: Alexander Best Subject: Re: fix tools/tools/usb/print-usb-if-vids.sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 11:47:46 -0000 On Friday 09 January 2009, Alexander Best wrote: > tools/tools/usb/print-usb-if-vids.sh I will take this into -current. http://perforce.freebsd.org/chv.cgi?CH=155902 Thanks for reporting. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 13:03:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B048106566C for ; Sat, 10 Jan 2009 13:03:10 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id C3E078FC16 for ; Sat, 10 Jan 2009 13:03:09 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.37,244,1231110000"; d="scan'208";a="208783574" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER02.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 10 Jan 2009 14:03:01 +0100 Received: by ZIVMAILUSER02.UNI-MUENSTER.DE (Postfix, from userid 149459) id A31F31B0871; Sat, 10 Jan 2009 14:03:01 +0100 (CET) Date: Sat, 10 Jan 2009 14:03:01 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: moving to a newer version of binutils X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 13:03:10 -0000 hi everybody, since there's a debate going on concerning moving to a different compiler or switching to a more recent version of gcc i'd like to ask what the binutils situation is right now? is somebody working on porting a more recent version? the current version of gas used in freebsd (2.15) e.g. doesn't support sse3/sse4. cheers. From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 13:19:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C17A8106566B for ; Sat, 10 Jan 2009 13:19:51 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8DBA88FC0A for ; Sat, 10 Jan 2009 13:19:51 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so12864838wfg.7 for ; Sat, 10 Jan 2009 05:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=HHW6WxB2/KGtZ/qk+8adzt5xLz7AN+Znmv29MB9/fPA=; b=C/00+j5iXDyCCacDWGXh8ZAhm3j0XzX/NULjSuNqx0O+V2y3bAUWTXBR5Q2dNWAWSc nbVolh4UMJC9qPKg8mqnczwLMiyiKmw/cagApq7pG8cN1u1em3srTXIgOxYLWhYXmxKM HIb+FqAbJdnQSlWkzRSgRcvnhAvA4WGVbMgHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=cZVogqUoRLgKaMNEMzZXzejcaXMUZacyZR2rn+WCgMQu3Oq5exC0aY5qOGNsrIYJvo TjmPMVPc+v9AbkdcTa+QZkBuvr8xDazjHwm+iuzl0LK1aZvkRx38Mdfefx1XzGFlmSDL yB5slEe9JqZuotvQU2BNTW+nq82+iha+8MPcg= Received: by 10.142.240.9 with SMTP id n9mr11200261wfh.1.1231593591040; Sat, 10 Jan 2009 05:19:51 -0800 (PST) Received: by 10.142.142.10 with HTTP; Sat, 10 Jan 2009 05:19:50 -0800 (PST) Message-ID: <89dbfdc30901100519x306d0eadicabe751b6e826c3@mail.gmail.com> Date: Sat, 10 Jan 2009 08:19:50 -0500 From: "Kim Culhan" To: pyunyh@gmail.com In-Reply-To: <20090110031839.GK30747@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> <20090109061032.GF30747@cdnetworks.co.kr> <89dbfdc30901091243w1d01ab59mc2ade81e65e51c5d@mail.gmail.com> <20090110031839.GK30747@cdnetworks.co.kr> Cc: freebsd-current@freebsd.org Subject: Re: msk Marvell Yukon 88E8038 hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 13:19:52 -0000 On Fri, Jan 9, 2009 at 10:18 PM, Pyun YongHyeon wrote: > On Fri, Jan 09, 2009 at 03:43:38PM -0500, Kim Culhan wrote: > > On Fri, Jan 9, 2009 at 1:10 AM, Pyun YongHyeon wrote: > > > On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote: > > > > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > > > Ok, then how about disabling TSO/Tx checksum offload? > > > (eg. ifconfig msk0 -tso -txcsum) > > > > This stops the messages: in_cksum_skip: out of data by 56952 > > Ok, would you try attached patch? With the patch there are no in_cksum_skip messages a cvsup session still has: Network write failure: Connection timed out There are some instances of LOR, maybe these are already known: lock order reversal: 1st 0xd9544090 bufwait (bufwait) @ kern/vfs_bio.c:2443 2nd 0xc5d72c00 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:263 KDB: stack backtrace: db_trace_self_wrapper(c0be4788,e8308778,c0871d75,4,c0bdfd93,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bdfd93,c55236d8,c5526528,e83087d4,...) at kdb_backtrace+0x29 _witness_debugger(c0be7442,c5d72c00,c0c06baa,c5526528,c0c06850,...) at _witness_debugger+0x25 witness_checkorder(c5d72c00,9,c0c06847,107,0,...) at witness_checkorder+0x839 _sx_xlock(c5d72c00,0,c0c06847,107,c5f7d7f8,...) at _sx_xlock+0x85 ufsdirhash_acquire(d9544030,e83088ec,30,da9360a4,e83088a4,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c5f7d7f8,e83088ec,30a4,e8308890,e8308894,...) at ufsdirhash_add+0x13 ufs_direnter(c5e13860,c6054648,e83088ec,e8308bd4,0,...) at ufs_direnter+0x729 ufs_makeinode(e8308bd4,e8308acc,e8308acc,e8308a34,c0b41375,...) at ufs_makeinode+0x519 ufs_create(e8308acc,e8308acc,0,e8308acc,e8308ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0ceb5a0,e8308acc,2,c0bda5a0,3,...) at VOP_CREATE_APV+0xa5 vn_open_cred(e8308ba8,e8308c5c,180,c5b05200,c595e498,...) at vn_open_cred+0x1d0 vn_open(e8308ba8,e8308c5c,180,c595e498,2e0013,...) at vn_open+0x33 kern_openat(c596cd80,ffffff9c,82561e0,0,603,...) at kern_openat+0x110 kern_open(c596cd80,82561e0,0,602,180,...) at kern_open+0x35 open(c596cd80,e8308cf8,c,c0be7c53,c0cc6918,...) at open+0x30 syscall(e8308d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2823b8d3, esp = 0x8202a60, ebp = 0x8202afc --- -- -kim From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 15:24:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38F601065678 for ; Sat, 10 Jan 2009 15:24:18 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id B5E468FC17 for ; Sat, 10 Jan 2009 15:24:17 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so1799602nfh.33 for ; Sat, 10 Jan 2009 07:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=nS79y0YybOOmS6h/ZOVQgwL1kXeytO7ZzVdRhtXMMW8=; b=gTuO1OcmrlWEMEQKLx82Sdfq8UysPpec7mtjx1VgFVF1/xSjxrwh5Og+ikU6X+Erg6 AIMFwWFJh7soHt3tzbvfQII/u+QVSvAfN7TydrMqTbeUUWThBV/ile7FrJMtSbM2iK2b iR4PeqU4+BF/rvCDi0NYv+u/dI0hsg187ALBI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=WZYB58hLQr78SULb34ZBISggFV+4KO5Hnt7o4NFHWaxV7g1m7EkQRGvhzKc5lw7d+i Tn2J77QYHfB9iIo2YKeFLz6Sikq5Dg/coil0dvMwO9SDxE3niEh4BfGHjh3LF8JP3hea cAV6Xm1E7ofCDLJvOmRYTBHZVQ8JTf5xpU77Y= Received: by 10.67.40.15 with SMTP id s15mr245658ugj.89.1231601056708; Sat, 10 Jan 2009 07:24:16 -0800 (PST) Received: by 10.67.88.9 with HTTP; Sat, 10 Jan 2009 07:24:16 -0800 (PST) Message-ID: <7d6fde3d0901100724la51365cp83ed94d917654605@mail.gmail.com> Date: Sat, 10 Jan 2009 07:24:16 -0800 From: "Garrett Cooper" To: "Andriy Gapon" In-Reply-To: <4968BCC4.7090708@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4968AE90.5010004@icyb.net.ua> <7d6fde3d0901100711p70e9a66ahadc3c2570fc6f94b@mail.gmail.com> <4968BB5D.8070909@icyb.net.ua> <7d6fde3d0901100716i552420ddja6a59a4938e70fc9@mail.gmail.com> <7d6fde3d0901100718s31ae9f38i5db870b7059bdfbe@mail.gmail.com> <4968BCC4.7090708@icyb.net.ua> Cc: FreeBSD Current Subject: Re: rc.d/mountd: confusing message (and behavior?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 15:24:18 -0000 On Sat, Jan 10, 2009 at 7:20 AM, Andriy Gapon wrote: > on 10/01/2009 17:18 Garrett Cooper said the following: >> >> s/same functionality/same basic functionality/. >> Mind you, NFS is a networking filesystem. ZFS is a filestore >> filesystem, more rooted to the local machine I thought, like UFS. > > I am well aware of this. The difference between UFS and ZFS is that for > the former you have to maintain /etc/exports by hand and for the latter > /etc/zfs/exports is automatically managed via zfs tools. > > Andriy Gapon Maybe a zmountd or equivalent script should be written for zfs and the common code should be factored out for both cases? -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 15:25:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E150106566B; Sat, 10 Jan 2009 15:25:24 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 078928FC0C; Sat, 10 Jan 2009 15:25:23 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so89029ugs.39 for ; Sat, 10 Jan 2009 07:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=3Jssyd5uCG9is4gHWRUK6SI1z8ZRvFSN3Pvz3RGb/Ik=; b=JEX9ZUVzmyuka3CCTtJljw21G19eku0s4qhvKm7ykvx3um1W6Sm147xQ07EJXFDxWe aJe6hlYqoMfyW27AZ3ij40dzWRkW5HNVcaf2Ml4+cDh0iTm+3pFN7xRPtzufDVToalXw R14QsfA4zlJyRZVo1SYT079hTPyC6tEf6QfgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=WNXmEcYI8tP+w5JaM6QYPPnY7ERTO9kzAvXwzAYS/vkFFrjCTcKWeDPXgM4bsS5cIf FlHxFBpRm/G76QG6U3Xk8mObT3wzDe8VQSmnwyYAxe2Q0EXdH0MN7x1ib5b8Im57K8Uc sq4mduYYlNgCXUYMjUFIv2hGh15sK5FVFedX4= Received: by 10.66.218.3 with SMTP id q3mr260592ugg.24.1231601123074; Sat, 10 Jan 2009 07:25:23 -0800 (PST) Received: by 10.67.88.9 with HTTP; Sat, 10 Jan 2009 07:25:23 -0800 (PST) Message-ID: <7d6fde3d0901100725q74c46bb1vf93379e075879bfd@mail.gmail.com> Date: Sat, 10 Jan 2009 07:25:23 -0800 From: "Garrett Cooper" To: "Andriy Gapon" In-Reply-To: <7d6fde3d0901100724la51365cp83ed94d917654605@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4968AE90.5010004@icyb.net.ua> <7d6fde3d0901100711p70e9a66ahadc3c2570fc6f94b@mail.gmail.com> <4968BB5D.8070909@icyb.net.ua> <7d6fde3d0901100716i552420ddja6a59a4938e70fc9@mail.gmail.com> <7d6fde3d0901100718s31ae9f38i5db870b7059bdfbe@mail.gmail.com> <4968BCC4.7090708@icyb.net.ua> <7d6fde3d0901100724la51365cp83ed94d917654605@mail.gmail.com> Cc: FreeBSD Current , FreeBSD Subject: Re: rc.d/mountd: confusing message (and behavior?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 15:25:25 -0000 On Sat, Jan 10, 2009 at 7:24 AM, Garrett Cooper wrote: > On Sat, Jan 10, 2009 at 7:20 AM, Andriy Gapon wrote: >> on 10/01/2009 17:18 Garrett Cooper said the following: >>> >>> s/same functionality/same basic functionality/. >>> Mind you, NFS is a networking filesystem. ZFS is a filestore >>> filesystem, more rooted to the local machine I thought, like UFS. >> >> I am well aware of this. The difference between UFS and ZFS is that for >> the former you have to maintain /etc/exports by hand and for the latter >> /etc/zfs/exports is automatically managed via zfs tools. >> >> Andriy Gapon > > Maybe a zmountd or equivalent script should be written for zfs and the > common code should be factored out for both cases? > -Garrett Sorry -- wrong list (current -> stable) ><. -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 16:03:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAFD51065675 for ; Sat, 10 Jan 2009 16:03:10 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id A37618FC0C for ; Sat, 10 Jan 2009 16:03:09 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 1B2569CB123; Sat, 10 Jan 2009 17:02:58 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxFj7DlUrGzc; Sat, 10 Jan 2009 17:02:55 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D04249CB2B7; Sat, 10 Jan 2009 17:02:55 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id n0AG2tOO063961; Sat, 10 Jan 2009 17:02:55 +0100 (CET) (envelope-from rdivacky) Date: Sat, 10 Jan 2009 17:02:55 +0100 From: Roman Divacky To: "Pedro F. Giffuni" Message-ID: <20090110160255.GA63803@freebsd.org> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090110113308.GA25584@freebsd.org> <54244.38350.qm@web32701.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54244.38350.qm@web32701.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 16:03:11 -0000 On Sat, Jan 10, 2009 at 06:33:53AM -0800, Pedro F. Giffuni wrote: > > > From: Roman Divacky > > > > On Fri, Jan 09, 2009 at 07:22:38PM -0800, Pedro F. Giffuni wrote: > > > FWIW, > > > > > > I had some informal talk with brooks@ about this at EuroBSDCon: > > > > > > - groff(1) needs a C++ compiler so clang is not (yet) an option? for the time > > being we will have to live with GCC or llvm-gcc. > > > > I guess once the switch happens we are going to live for some with both > > gcc and clang/llvm. I also guess that by the time the switch happens > > clang is going to be full C++ capable :) > > I think it's more realistic to move to gcc-llvm first and then to clang: testing gcc-llvm helps?test the llvm capabilities?that clang will require to be a viable replacement. In any case, before doing such a thing an experimental run of the ports tree with?the alternative compiler?would prove very valuable to the developers. I have already asked pav@ about this but I am waiting for clang to implement two features (designated initializers and wchars)... about the llvm-gcc... I dont know... it looks like a dead end to me... From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 14:33:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 035F710656E0 for ; Sat, 10 Jan 2009 14:33:54 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from web32701.mail.mud.yahoo.com (web32701.mail.mud.yahoo.com [68.142.207.245]) by mx1.freebsd.org (Postfix) with SMTP id A77158FC12 for ; Sat, 10 Jan 2009 14:33:53 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: (qmail 40542 invoked by uid 60001); 10 Jan 2009 14:33:53 -0000 X-YMail-OSG: dLY9qGsVM1mYzy9MBLtwRVGSWfkKSpwzGw8hC4NbekxuNEgIlPA7JfD6JFXzByyFgITdsJcWXzQoy10YTdeumMnVdowOg30zXqnWjHkeGIYSlOJnr9Kcsfl9OIjmBKLp6XUiWNg6xsTsLs7tDgjE.Xre_D1UdK61.qNj7xPt7OckIM.dFtNnVMjBsq6E Received: from [190.157.124.207] by web32701.mail.mud.yahoo.com via HTTP; Sat, 10 Jan 2009 06:33:53 PST X-RocketYMMF: giffunip X-Mailer: YahooMailRC/1156.77 YahooMailWebService/0.7.260.1 References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090110113308.GA25584@freebsd.org> Date: Sat, 10 Jan 2009 06:33:53 -0800 (PST) From: "Pedro F. Giffuni" To: Roman Divacky MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <54244.38350.qm@web32701.mail.mud.yahoo.com> X-Mailman-Approved-At: Sat, 10 Jan 2009 16:18:42 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 14:33:54 -0000 =0A> From: Roman Divacky=0A> =0A> On Fri, Jan 09, 2009 at 07:22:38PM -0800,= Pedro F. Giffuni wrote:=0A> > FWIW,=0A> > =0A> > I had some informal talk = with brooks@ about this at EuroBSDCon:=0A> > =0A> > - groff(1) needs a C++ = compiler so clang is not (yet) an option=A0 for the time =0A> being we will= have to live with GCC or llvm-gcc.=0A> =0A> I guess once the switch happen= s we are going to live for some with both=0A> gcc and clang/llvm. I also gu= ess that by the time the switch happens=0A> clang is going to be full C++ c= apable :)=0A=0AI think it's more realistic to move to gcc-llvm first and th= en to clang: testing gcc-llvm helps=A0test the llvm capabilities=A0that cla= ng will require to be a viable replacement. In any case, before doing such = a thing an experimental run of the ports tree with=A0the alternative compil= er=A0would prove very valuable to the developers.=0A=0APedro.=0A=0A=0A = From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 15:37:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E07FA106566B for ; Sat, 10 Jan 2009 15:37:55 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from web32708.mail.mud.yahoo.com (web32708.mail.mud.yahoo.com [68.142.207.252]) by mx1.freebsd.org (Postfix) with SMTP id 8EE238FC08 for ; Sat, 10 Jan 2009 15:37:54 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: (qmail 31772 invoked by uid 60001); 10 Jan 2009 15:37:54 -0000 X-YMail-OSG: zbrJ6c4VM1nnJJuulhsX7XzCI2RrjZcrwt3o_m7X2dPyMNS1sTk9mcpwkqVItZ9nV6Uc5djgpjOWgqPRiSKOg5o2gG5izJ7vHhjRPCNe8ZMkKVctytwIUKLNJ4mPAQuoP3Tnlq4icdFbhFNzvXz6_56Kng931F5ULmuljtdGdbbQGbNTf96Zh0ZM7g255itGXz7fCkE_RbPW6TgB7L3cEcH16q968aVH Received: from [190.157.124.207] by web32708.mail.mud.yahoo.com via HTTP; Sat, 10 Jan 2009 07:37:53 PST X-RocketYMMF: giffunip X-Mailer: YahooMailRC/1156.77 YahooMailWebService/0.7.260.1 Date: Sat, 10 Jan 2009 07:37:53 -0800 (PST) From: "Pedro F. Giffuni" To: Alexander Best MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <988010.31127.qm@web32708.mail.mud.yahoo.com> X-Mailman-Approved-At: Sat, 10 Jan 2009 16:19:20 +0000 Cc: freebsd-current@freebsd.org Subject: Re: moving to a newer version of binutils X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 15:37:56 -0000 AFAICT ... Anything under GPLv3 will have to live on the ports tree: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html cheers, Pedro. From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 16:52:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A89510656C6 for ; Sat, 10 Jan 2009 16:52:26 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mx1.freebsd.org (Postfix) with ESMTP id D1B018FC08 for ; Sat, 10 Jan 2009 16:52:25 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 407AD15B575 for ; Sat, 10 Jan 2009 17:52:24 +0100 (CET) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 2CCF72D377D for ; Sat, 10 Jan 2009 17:52:24 +0100 (CET) Received: from lorvorc.mips.inka.de (dslb-088-067-123-113.pools.arcor-ip.net [88.67.123.113]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 0042236E869 for ; Sat, 10 Jan 2009 17:52:21 +0100 (CET) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.3/8.14.3) with ESMTP id n0AGqLb4051079 for ; Sat, 10 Jan 2009 17:52:21 +0100 (CET) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.3/8.14.3/Submit) id n0AGqLrm051078 for freebsd-current@freebsd.org; Sat, 10 Jan 2009 17:52:21 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Sat, 10 Jan 2009 16:52:21 +0000 (UTC) Message-ID: References: <4965927D.1060507@freebsd.org> <4966A9AB.2040802@FreeBSD.org> <367b2c980901090244t64d33c2fx171cda607914189e@mail.gmail.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-current@freebsd.org X-Virus-Scanned: ClamAV 0.94.1/8849/Sat Jan 10 05:18:40 2009 on mail-in-02.arcor-online.net X-Virus-Status: Clean Subject: Re: bsdtar fan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 16:52:26 -0000 Olivier SMEDTS wrote: > Just fed up determining compression type of archives and using z/j > flags with non-bsd tar :) FWIW, gtar has supported this for some time now, too. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 18:32:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30D1F1065674 for ; Sat, 10 Jan 2009 18:32:33 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 8849A8FC3A for ; Sat, 10 Jan 2009 18:32:31 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 10 Jan 2009 18:32:29 -0000 Received: from p54A3D14A.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.209.74] by mail.gmx.net (mp008) with SMTP; 10 Jan 2009 19:32:29 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18hZxBhgDYhO9/KKobKv8AerM5mQ3wC4o8TEFDNSC ou9jk93dJvEBVu Message-ID: <4968E9BC.2070407@gmx.de> Date: Sat, 10 Jan 2009 19:32:28 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Roman Divacky References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> <20090109222211.GA33145@freebsd.org> In-Reply-To: <20090109222211.GA33145@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: Andrew Reilly , freebsd-current@freebsd.org, Alexander Churanov , Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 18:32:33 -0000 Roman Divacky schrieb: > On Sat, Jan 10, 2009 at 01:12:57AM +0300, Alexander Churanov wrote: >> Folks, >> >> The '-std=c99'' only instructs GCC to allow the whole of C99. This is >> clearly not enough, because this mode allows too many GCC extensions. If you >> compile your code in "default' mode or just specify '-std=c99', then it's >> very likely that you will eventually get stuck to GCC. Using this approach >> you are reducing chances to switch to another C99 compiler. >> >> Though I am not aware of any other open source compiler supporting C99, I >> beleive that there is great need for it. This discussion indicates that >> there is real necessity for BSD-licensed C99 compiler. > > clang (clang.llvm.org) supports almost everything now and aims for full C99 > support. > > pcc aims for full C99 too I believe > > Chris Mallon can comment better but I believe cparser is C99 too cparser already supports most C99 constructs (only complex arithmetic is missing, mostly because nobody needed it so far). The other fancy stuff, like designator initializers and compound literals, works. Wide characters are supported, too. It's not a C99 feature per se, but C99 allows concatenation of char and wide char string literals. Also cparser can generate warnings about incorrect wide character format strings (GCC cannot do that). Oh, btw, I'm Christoph. Chris (Lattner) is the LLVM guy. (; From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 18:34:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 036A21065673 for ; Sat, 10 Jan 2009 18:34:28 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 55DF88FC36 for ; Sat, 10 Jan 2009 18:34:27 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 10 Jan 2009 18:34:25 -0000 Received: from p54A3D14A.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.209.74] by mail.gmx.net (mp013) with SMTP; 10 Jan 2009 19:34:25 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18aHMc+hLgadBOw5yjicHSSNwL+DS0oO4wMz5OPCr 8Hiay/2zCDVo7X Message-ID: <4968EA30.4010608@gmx.de> Date: Sat, 10 Jan 2009 19:34:24 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Roman Divacky References: <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> <20090109222211.GA33145@freebsd.org> <3cb459ed0901091453i2144419fyede5894ae411a259@mail.gmail.com> <20090109230252.GA37323@freebsd.org> In-Reply-To: <20090109230252.GA37323@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: Andrew Reilly , freebsd-current@freebsd.org, Alexander Churanov , Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 18:34:28 -0000 Roman Divacky schrieb: > On Sat, Jan 10, 2009 at 01:53:56AM +0300, Alexander Churanov wrote: >> Roman, >> >>> clang (clang.llvm.org) supports almost everything now and aims for full >>> C99 >>> support. >>> >>> pcc aims for full C99 too I believe >>> >>> Chris Mallon can comment better but I believe cparser is C99 too >>> >>> am I missing something? >>> >> This means that I am missing something and that '-pedantic' is all the more >> important. > > well.... > > clang DEFINITELY aims to be drop-in replacement for gcc, ie. it supports (aims > to support) all the gcc extensions hence no -pedantic needed to be compatible > with gcc and clang at the same time > > pcc discusses this now (http://pcc.ludd.ltu.se/jira/browse/PCC-18) > > from what Chris Mallon said I believe it's cparser's goal too to be drop-in > replacement for gcc cparser supports GCC specific command line switches and language extensions. The most important GCC extensions are its inline assembler syntax, attributes (though only some of them, there are so many...), statement expressions (i.e. ({}), not to be confused with expression statements), thread local variables. We are adding command line switches when needed, because there are hundrends. The most important ones are already supported and the next release will support more. But making a drop-in replacement is not that easy, because sometimes people depend on specific GCC behaviour, which is just happens by coincidence. For example the first larger project (aside from SPEC2000), which we compiled with cparser, was ioquake3. It contains some inline assembler statements. The input/output parameter specification of them was wrong, but GCC accidently produced working code. cparser/libFIRM generated code, which was correct according to the specification, but did not work. So when you change the compiler and even if the compiler does everything right, things still might break, because the input was faulty and you just didn't notice so far. I resolved this specific problem by sending a patch to the ioquake3 maintainer. (: What I want to express is that you have to work very thoroughly when changing the compiler of such a large project especially because it also contains many hardware depedent parts. From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 18:57:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0EAF1065670 for ; Sat, 10 Jan 2009 18:57:05 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 96C8E8FC0C for ; Sat, 10 Jan 2009 18:57:05 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.123.2.23] (p53.kientzle.com [66.166.149.53]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n0AIv5tv069289; Sat, 10 Jan 2009 10:57:05 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <4968EF7E.5040002@freebsd.org> Date: Sat, 10 Jan 2009 10:57:02 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dylan Cochran References: <4965927D.1060507@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Extattr portability? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 18:57:06 -0000 Dylan Cochran wrote: > > Another is BeOS/Haiku, which used attributes heavily. I have been > waiting for this work for a while. What I don't really mind is whether > it is portable, what I really care about is full retention of the user > namespace. ... > > That's my 2 cents on the matter, I use extended attributes now for > storing cached mime-type, and sha256/md5 for checksum purposes. Wonderful! Care to help test? There's still a lot of open questions about the system namespace I'll have to figure out. Over on the GNU tar mailing list, the Linux filesystem folks have been agitating for GNU tar to support system extattrs that carry filesystem layout hints. The portability issues with this make my head hurt. Tim From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 20:21:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F2AF1065670; Sat, 10 Jan 2009 20:21:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id C40918FC16; Sat, 10 Jan 2009 20:21:16 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nklthdr5v5AUSfVrlghuJA==:17 a=6I5d2MoRAAAA:8 a=T2r-b28UR27u9Pe-CXoA:9 a=9DVhdBXz2dqI911dOU5VLCNHGccA:4 a=50e4U0PicR4A:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1176207362; Sat, 10 Jan 2009 21:21:14 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 10 Jan 2009 21:23:35 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901102123.36484.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: USB wiki page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 20:21:17 -0000 Hi, I've created a USB page at the FreeBSD wiki with some USB2/HPSUSB frequently asked questions. http://wiki.freebsd.org/USB --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 22:56:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29CA81065672; Sat, 10 Jan 2009 22:56:07 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.188]) by mx1.freebsd.org (Postfix) with ESMTP id B93328FC18; Sat, 10 Jan 2009 22:56:06 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so6774169rne.12 for ; Sat, 10 Jan 2009 14:56:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Qi613Rj49aemWFZuPpL47/K25bgPpzaK5qT3X80GVAQ=; b=i+Bzv0FhR8XUaaIyBXuFoXL1hX2TRYG1slD+9abitjggB1DEiszncgWMXpSidxFarb TN7PPZSrQP4lIZUsdWLbqbyUo5DC9snD+bWMWGHUnVCEiQLM1shesWVb5+X8fStL/GcQ JnLvESlEWYeaKfpiiiZB6Ec0uSFSdsmeaWan4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=QZU7Reog18N94vl/q7AuDTQWsfwwhdholFkvDmzr+Qrkqbvs0GAaEj8sFP39tTExG2 7EJylHUKxr4MRioQ6pK0C36/LC3crv9MqaKaFiTT76ligcsfgNLJt8ZHPic1ur5dgaiJ kuLz0PgejoA5+OCWKOwPEGdVhrucEEGAtgvTU= Received: by 10.90.102.8 with SMTP id z8mr12885934agb.56.1231628165879; Sat, 10 Jan 2009 14:56:05 -0800 (PST) Received: by 10.90.36.7 with HTTP; Sat, 10 Jan 2009 14:56:05 -0800 (PST) Message-ID: Date: Sat, 10 Jan 2009 17:56:05 -0500 From: a134qaed@gmail.com To: "Tim Kientzle" In-Reply-To: <4968EF7E.5040002@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4965927D.1060507@freebsd.org> <4968EF7E.5040002@freebsd.org> X-Mailman-Approved-At: Sat, 10 Jan 2009 23:38:26 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Extattr portability? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 22:56:07 -0000 On 1/10/09, Tim Kientzle wrote: > Dylan Cochran wrote: >> > > Wonderful! Care to help test? Absolutely. > > There's still a lot of open questions about the system > namespace I'll have to figure out. Over on the GNU tar > mailing list, the Linux filesystem folks have been agitating > for GNU tar to support system extattrs that carry filesystem > layout hints. The portability issues with this make my > head hurt. Yea, I think in the end it's going to be inherently un-portable, as in some systems, the system attributes could be filesystem or kernel specific. And I can forsee some dangerous reprocussions (a collision on an attribute name in the system namespace, which on one system is just a tag, like 'page=23', but on another, it's interpreted as a flagged hint to the dynamic linker, on how to page in the file..... > > Tim >