From david at catwhisker.org Fri May 1 02:28:28 2009 From: david at catwhisker.org (David Wolfskill) Date: Fri May 1 02:28:35 2009 Subject: Panic: witness_warn (r191682; shared rw udpinp (udpinp)...netinet6/udp6_usrreq.c:360) In-Reply-To: <49FA1B7E.7060201@incunabulum.net> References: <20090430155408.GX1387@albert.catwhisker.org> <20090430204828.GA6551@dchagin.static.corbina.ru> <20090430213621.GA61978@albert.catwhisker.org> <49FA1B7E.7060201@incunabulum.net> Message-ID: <20090501022826.GG61978@albert.catwhisker.org> On Thu, Apr 30, 2009 at 10:43:26PM +0100, Bruce Simpson wrote: > ... > Can you try this patch? This patch is probably more correct -- but you > can see my intent was to avoid thrashing the INP lock on mcast delivery. > INP lock use in that routine is goopy to read. That'll teach me to do > things from memory for IPv4... bah! :-) OK; that one works, too: lbert(7.1-S)[7] ssh -x freebeast uname -a FreeBSD freebeast.catwhisker.org 8.0-CURRENT FreeBSD 8.0-CURRENT #332 r191682M: Thu Apr 30 19:19:18 PDT 2009 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/FREEBEAST i386 albert(7.1-S)[8] Thanks for the patch! Peace, david -- 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090501/c1ea9052/attachment.pgp From pluknet at gmail.com Fri May 1 02:39:39 2009 From: pluknet at gmail.com (pluknet) Date: Fri May 1 02:39:46 2009 Subject: cannot compile sched_ule without options SMP In-Reply-To: References: <20090430013428.cb4f804b.nork@FreeBSD.org> Message-ID: 2009/5/1 Jeff Roberson : > On Thu, 30 Apr 2009, pluknet wrote: > >> 2009/4/30 Jeff Roberson : >>> >>> On SMP machines you should now see output like this: >>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >>> >>> If you detect any irregularities with kern.sched.topology_spec or this >>> dmesg >>> line please report them. >>> >> >> Hi, Jeff. >> >> I have such mismatch. This is an Intel E7200. >> >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP/HT): APIC ID: 1 >> >> So it should be instead: 1 package(s) x 2 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 > > Can you please repeat the following steps as I have done here: > (kgdb) p/x cpu_high $1 = 0x2 (kgdb) p/x cpu_cores $2 = 0x1 (kgdb) p/x cpu_logical $3 = 0x2 (kgdb) p/x cpu_feature $4 = 0xbfebfbff (kgdb) p/x logical_cpus $5 = 0x2 (kgdb) p/x hyperthreading_cpus $6 = 0x2 -- wbr, pluknet From pluknet at gmail.com Fri May 1 03:04:20 2009 From: pluknet at gmail.com (pluknet) Date: Fri May 1 03:04:27 2009 Subject: cannot compile sched_ule without options SMP In-Reply-To: References: <20090430013428.cb4f804b.nork@FreeBSD.org> Message-ID: 2009/5/1 pluknet : > 2009/5/1 Jeff Roberson : >> On Thu, 30 Apr 2009, pluknet wrote: >> >>> 2009/4/30 Jeff Roberson : >>>> >>>> On SMP machines you should now see output like this: >>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >>>> >>>> If you detect any irregularities with kern.sched.topology_spec or this >>>> dmesg >>>> line please report them. >>>> >>> >>> Hi, Jeff. >>> >>> I have such mismatch. This is an Intel E7200. >>> >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP/HT): APIC ID: 1 >>> >>> So it should be instead: 1 package(s) x 2 core(s) >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP): APIC ID: 1 >> >> Can you please repeat the following steps as I have done here: >> > > (kgdb) p/x cpu_high > $1 = 0x2 > (kgdb) p/x cpu_cores > $2 = 0x1 > (kgdb) p/x cpu_logical > $3 = 0x2 > (kgdb) p/x cpu_feature > $4 = 0xbfebfbff > (kgdb) p/x logical_cpus > $5 = 0x2 > (kgdb) p/x hyperthreading_cpus > $6 = 0x2 > Follow up myself: What is embarrassing me is HTT feature enabled. May the reason be in a buggy CPUID ? -- wbr, pluknet From jroberson at jroberson.net Fri May 1 05:12:42 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Fri May 1 05:12:49 2009 Subject: cannot compile sched_ule without options SMP In-Reply-To: References: <20090430013428.cb4f804b.nork@FreeBSD.org> Message-ID: On Fri, 1 May 2009, pluknet wrote: > 2009/5/1 pluknet : >> 2009/5/1 Jeff Roberson : >>> On Thu, 30 Apr 2009, pluknet wrote: >>> >>>> 2009/4/30 Jeff Roberson : >>>>> >>>>> On SMP machines you should now see output like this: >>>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >>>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >>>>> >>>>> If you detect any irregularities with kern.sched.topology_spec or this >>>>> dmesg >>>>> line please report them. >>>>> >>>> >>>> Hi, Jeff. >>>> >>>> I have such mismatch. This is an Intel E7200. >>>> >>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads >>>> cpu0 (BSP): APIC ID: 0 >>>> cpu1 (AP/HT): APIC ID: 1 >>>> >>>> So it should be instead: 1 package(s) x 2 core(s) >>>> cpu0 (BSP): APIC ID: 0 >>>> cpu1 (AP): APIC ID: 1 >>> >>> Can you please repeat the following steps as I have done here: >>> >> >> (kgdb) p/x cpu_high >> $1 = 0x2 >> (kgdb) p/x cpu_cores >> $2 = 0x1 >> (kgdb) p/x cpu_logical >> $3 = 0x2 >> (kgdb) p/x cpu_feature >> $4 = 0xbfebfbff >> (kgdb) p/x logical_cpus >> $5 = 0x2 >> (kgdb) p/x hyperthreading_cpus >> $6 = 0x2 >> > > Follow up myself: > > What is embarrassing me is HTT feature enabled. May the reason be in a > buggy CPUID ? This is very curious. With older revisions did the system believe your CPUs were HTT? You can tell if you had sysctl machdep.hyperthreading_allowed or via the ULE kern.sched.topology_spec sysctl. I didn't realize there were any core2 CPUs without leaf 4 of cpuid. However, I didn't write the earlier hyperthread detection code. I'll see if I can get jhb to chime in. The HTT feature bit is set on many processors that don't have hyperthreads. So we need a secondary way of differentiating. I don't know what that is in this case. Thanks, Jeff > > -- > wbr, > pluknet > From bms at incunabulum.net Fri May 1 11:06:10 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri May 1 11:06:18 2009 Subject: Panic: witness_warn (r191682; shared rw udpinp (udpinp)...netinet6/udp6_usrreq.c:360) In-Reply-To: <20090501022826.GG61978@albert.catwhisker.org> References: <20090430155408.GX1387@albert.catwhisker.org> <20090430204828.GA6551@dchagin.static.corbina.ru> <20090430213621.GA61978@albert.catwhisker.org> <49FA1B7E.7060201@incunabulum.net> <20090501022826.GG61978@albert.catwhisker.org> Message-ID: <49FAD7A0.8070507@incunabulum.net> David Wolfskill wrote: > On Thu, Apr 30, 2009 at 10:43:26PM +0100, Bruce Simpson wrote: > >> ... >> Can you try this patch? This patch is probably more correct -- but you >> can see my intent was to avoid thrashing the INP lock on mcast delivery. >> INP lock use in that routine is goopy to read. That'll teach me to do >> things from memory for IPv4... bah! :-) >> > > OK; that one works, too: > Thanks, I have checked it in. cheers BMS From bms at incunabulum.net Fri May 1 13:07:05 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri May 1 13:07:18 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 In-Reply-To: <49EDDD51.9040608@freebsd.org> References: <49E6DB25.2010601@sippysoft.com> <49E6FF8F.4070403@sippysoft.com> <49ED6AD2.4010006@incunabulum.net> <49EDDD51.9040608@freebsd.org> Message-ID: <49FAF3F5.5070609@incunabulum.net> Hi, Can you please try this patch? I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut. Sam Leffler wrote: > Bruce Simpson wrote: > >> Hi, >> >> Looks like I'm late to the party. I was responsible for committing these >> ath(4) changes to RELENG_7. >> I can't remember if I tested the kernel compile without the >> AH_SUPPORT_AR5416 option or not, I have been so incredibly busy. >> ... > ru had a change to fix this but decided not to; can't say why. > Otherwise there is a better way to fix this which I alluded to in > previous mail--use the config-generated #define that is generated for > the "ath_hal" device. thanks, BMS -------------- next part -------------- Index: UPDATING =================================================================== --- UPDATING (revision 191718) +++ UPDATING (working copy) @@ -8,6 +8,11 @@ /usr/ports/UPDATING. Please read that file before running portupgrade. +20090505: + The kernel compile-time option AH_SUPPORT_AR5416 has been + removed; it is now enabled by default as if_ath.c depends on it + in order to build. + 20090504: FreeBSD 7.2-RELEASE Index: sys/arm/conf/AVILA =================================================================== --- sys/arm/conf/AVILA (revision 191718) +++ sys/arm/conf/AVILA (working copy) @@ -133,7 +133,6 @@ #device wlan_tkip # 802.11 TKIP support device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) -options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors device ath_rate_sample # SampleRate tx rate control for ath options ATH_DEBUG Index: sys/sparc64/conf/GENERIC =================================================================== --- sys/sparc64/conf/GENERIC (revision 191718) +++ sys/sparc64/conf/GENERIC (working copy) @@ -191,7 +191,6 @@ device wlan_scan_sta # 802.11 STA mode scanning device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) -options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors device ath_rate_sample # SampleRate tx rate control for ath # Pseudo devices. Index: sys/conf/options =================================================================== --- sys/conf/options (revision 191718) +++ sys/conf/options (working copy) @@ -731,8 +731,6 @@ ATH_TX99_DIAG opt_ath.h # options for the Atheros hal -AH_SUPPORT_AR5416 opt_ah.h - AH_DEBUG opt_ah.h AH_ASSERT opt_ah.h AH_DEBUG_ALQ opt_ah.h Index: sys/modules/ath/Makefile =================================================================== --- sys/modules/ath/Makefile (revision 191718) +++ sys/modules/ath/Makefile (working copy) @@ -76,8 +76,9 @@ # # AR5416, AR9160 support; these are 11n parts but only really # supported (right now) operating in legacy mode. Note enabling -# this support requires defining AH_SUPPORT_AR5416 in opt_ah.h +# this support requires defining AH_SUPPORT_AR5416 # so the 11n tx/rx descriptor format is handled. +# This support is now enabled by default. # # NB: 9160 depends on 5416 but 5416 does not require 9160 # @@ -106,7 +107,4 @@ CFLAGS+= -I. -I${.CURDIR}/../../dev/ath -I${.CURDIR}/../../dev/ath/ath_hal -opt_ah.h: - echo '#define AH_SUPPORT_AR5416 1' > $@ - .include Index: sys/dev/ath/ath_hal/ah_desc.h =================================================================== --- sys/dev/ath/ath_hal/ah_desc.h (revision 191718) +++ sys/dev/ath/ath_hal/ah_desc.h (working copy) @@ -20,8 +20,12 @@ #ifndef _DEV_ATH_DESC_H #define _DEV_ATH_DESC_H -#include "opt_ah.h" /* NB: required for AH_SUPPORT_AR5416 */ +#include "opt_ah.h" +#ifndef AH_SUPPORT_AR5416 +#define AH_SUPPORT_AR5416 /* always support AR5416 */ +#endif + /* * Transmit descriptor status. This structure is filled * in only after the tx descriptor process method finds a Index: sys/dev/ath/if_ath.c =================================================================== --- sys/dev/ath/if_ath.c (revision 191718) +++ sys/dev/ath/if_ath.c (working copy) @@ -3399,7 +3399,7 @@ rix = rs->rs_rate; sc->sc_rx_th.wr_rate = sc->sc_hwmap[rix].ieeerate; sc->sc_rx_th.wr_flags = sc->sc_hwmap[rix].rxflags; -#if HAL_ABI_VERSION >= 0x07050400 +#if HAL_ABI_VERSION >= 0x07050400 && defined(AH_SUPPORT_AR5416) if (sc->sc_curchan.channelFlags & CHANNEL_HT) { /* * For HT operation we must specify the channel Index: sys/i386/conf/GENERIC =================================================================== --- sys/i386/conf/GENERIC (revision 191718) +++ sys/i386/conf/GENERIC (working copy) @@ -255,7 +255,6 @@ device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) -options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors device ath_rate_sample # SampleRate tx rate control for ath device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. Index: sys/amd64/conf/GENERIC =================================================================== --- sys/amd64/conf/GENERIC (revision 191718) +++ sys/amd64/conf/GENERIC (working copy) @@ -242,7 +242,6 @@ device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) -options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors device ath_rate_sample # SampleRate tx rate control for ath device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. From mike at jellydonut.org Fri May 1 14:52:45 2009 From: mike at jellydonut.org (Michael Proto) Date: Fri May 1 14:52:53 2009 Subject: syslogd with log files in /tmp In-Reply-To: <20090430121012.GB10553@rebelion.Sisis.de> References: <20090430094218.GA6800@rebelion.Sisis.de> <20090430121012.GB10553@rebelion.Sisis.de> Message-ID: <1de79840905010721n7dcf1b8fy8746590681d43f20@mail.gmail.com> On Thu, Apr 30, 2009 at 8:10 AM, Matthias Apitz wrote: > El d?a Thursday, April 30, 2009 a las 11:42:18AM +0200, Matthias Apitz escribi?: > >> syslogd_enable="YES" >> syslogd_flags="-s -C" >> >> on reboot it seems that syslogd has no logfiles (as I can see with >> lsof), but after I restart it with >> >> # /etc/rc.d/syslogd restart >> >> all is fine; maybe this is because syslogd is started before tmpmfs is >> ready? in RELENG_7 it worked exactly this way, now in CURRENT not; >> any idea how to solve this? > > it has todo with the order if rc files: > > CURRENT: > > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | cat -n | egrep 'syslogd|tmp' > 61 /etc/rc.d/syslogd > 76 /etc/rc.d/tmp > 77 /etc/rc.d/cleartmp > > 7.0-REL: > > # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | cat -n | egrep 'syslogd|tmp' > 56 /etc/rc.d/tmp > 57 /etc/rc.d/cleartmp > 64 /etc/rc.d/syslogd > > I will insert 'REQUIRE: tmp' in /etc/rc.d/syslogd > > matthias > -- > Matthias Apitz > Manager Technical Support - OCLC GmbH > Gruenwalder Weg 28g - 82041 Oberhaching - Germany > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.oclc.org/ http://www.UnixArea.de/ > People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. > _______________________________________________ > 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" > An alternative that doesn't require reordering or changes to the rc.d script is to setup your mfs in /etc/fstab instead of in /etc/rc.conf: md /tmp mfs rw,-s128m 2 0 -Proto From sam at freebsd.org Fri May 1 15:50:24 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri May 1 15:50:37 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 In-Reply-To: <49FAF3F5.5070609@incunabulum.net> References: <49E6DB25.2010601@sippysoft.com> <49E6FF8F.4070403@sippysoft.com> <49ED6AD2.4010006@incunabulum.net> <49EDDD51.9040608@freebsd.org> <49FAF3F5.5070609@incunabulum.net> Message-ID: <49FB1A3F.3000809@freebsd.org> Bruce Simpson wrote: > Hi, > > Can you please try this patch? > I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut. > > Sam Leffler wrote: >> Bruce Simpson wrote: >> >>> Hi, >>> >>> Looks like I'm late to the party. I was responsible for committing >>> these >>> ath(4) changes to RELENG_7. >>> I can't remember if I tested the kernel compile without the >>> AH_SUPPORT_AR5416 option or not, I have been so incredibly busy. >>> ... >> ru had a change to fix this but decided not to; can't say why. >> Otherwise there is a better way to fix this which I alluded to in >> previous mail--use the config-generated #define that is generated for >> the "ath_hal" device. Do not modify ah_desc.h like you've done. Add this to conf/options ATH_HAL opt_ah.h and use that to enable AH_SUPPORT_AR5416. Also changes must go in head first. Sam From sam at freebsd.org Fri May 1 15:57:26 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri May 1 15:57:32 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 In-Reply-To: <49FB1A3F.3000809@freebsd.org> References: <49E6DB25.2010601@sippysoft.com> <49E6FF8F.4070403@sippysoft.com> <49ED6AD2.4010006@incunabulum.net> <49EDDD51.9040608@freebsd.org> <49FAF3F5.5070609@incunabulum.net> <49FB1A3F.3000809@freebsd.org> Message-ID: <49FB1BE4.20502@freebsd.org> Sam Leffler wrote: > Bruce Simpson wrote: >> Hi, >> >> Can you please try this patch? >> I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut. >> >> Sam Leffler wrote: >>> Bruce Simpson wrote: >>> >>>> Hi, >>>> >>>> Looks like I'm late to the party. I was responsible for committing >>>> these >>>> ath(4) changes to RELENG_7. >>>> I can't remember if I tested the kernel compile without the >>>> AH_SUPPORT_AR5416 option or not, I have been so incredibly busy. >>>> ... >>> ru had a change to fix this but decided not to; can't say why. >>> Otherwise there is a better way to fix this which I alluded to in >>> previous mail--use the config-generated #define that is generated for >>> the "ath_hal" device. > Do not modify ah_desc.h like you've done. Add this to conf/options > > ATH_HAL opt_ah.h > > and use that to enable AH_SUPPORT_AR5416. > > Also changes must go in head first. To clarify the first comment: you've made it impossible to build code w/o the extended format descriptor; this is what I find unacceptable. Sam From bms at incunabulum.net Fri May 1 16:51:31 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri May 1 16:51:39 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 In-Reply-To: <49FB1BE4.20502@freebsd.org> References: <49E6DB25.2010601@sippysoft.com> <49E6FF8F.4070403@sippysoft.com> <49ED6AD2.4010006@incunabulum.net> <49EDDD51.9040608@freebsd.org> <49FAF3F5.5070609@incunabulum.net> <49FB1A3F.3000809@freebsd.org> <49FB1BE4.20502@freebsd.org> Message-ID: <49FB288E.7070402@incunabulum.net> Sam Leffler wrote: > ... >>>> the "ath_hal" device. >> Do not modify ah_desc.h like you've done. Add this to conf/options >> >> ATH_HAL opt_ah.h >> >> and use that to enable AH_SUPPORT_AR5416. >> > To clarify the first comment: you've made it impossible to build code > w/o the extended format descriptor; this is what I find unacceptable. Ah, of course, duh -- I forgot about the CaPiTalIzAtion of the device name gets pulled into config(5) with the 'device' keyword. Thanks for the reminder... This is a much cleaner fix for the issue than forcing the option to be set on always. It looks like HEAD has this issue too and this can go right in there. Are we happy with AH_SUPPORT_AR5416 being enabled in 7.x GENERIC? The 'out of box' config hasn't been broken by the change and this is identical to to the situation in HEAD as far as I can see. thanks, BMS From sam at freebsd.org Fri May 1 17:34:45 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri May 1 17:34:58 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 In-Reply-To: <49FB288E.7070402@incunabulum.net> References: <49E6DB25.2010601@sippysoft.com> <49E6FF8F.4070403@sippysoft.com> <49ED6AD2.4010006@incunabulum.net> <49EDDD51.9040608@freebsd.org> <49FAF3F5.5070609@incunabulum.net> <49FB1A3F.3000809@freebsd.org> <49FB1BE4.20502@freebsd.org> <49FB288E.7070402@incunabulum.net> Message-ID: <49FB32B3.1080707@freebsd.org> Bruce Simpson wrote: > Sam Leffler wrote: >> ... >>>>> the "ath_hal" device. >>> Do not modify ah_desc.h like you've done. Add this to conf/options >>> >>> ATH_HAL opt_ah.h >>> >>> and use that to enable AH_SUPPORT_AR5416. >>> >> To clarify the first comment: you've made it impossible to build code >> w/o the extended format descriptor; this is what I find unacceptable. > > Ah, of course, duh -- I forgot about the CaPiTalIzAtion of the device > name gets pulled into config(5) with the 'device' keyword. Thanks for > the reminder... > > This is a much cleaner fix for the issue than forcing the option to be > set on always. It looks like HEAD has this issue too and this can go > right in there. > > Are we happy with AH_SUPPORT_AR5416 being enabled in 7.x GENERIC? > The 'out of box' config hasn't been broken by the change and this is > identical to to the situation in HEAD as far as I can see. Not sure I understand your last question. If you fix the code so it's not dependent on "options AH_SUPPORT_AR5416" then you can just remove it from the GENERIC config files. Otherwise the intent was that "device ath_hal" would enable all available chip support so yes we want support for 5416 and later parts. In fact AH_SUPPORT_AR5416 is probably not needed at all; we can conditionalize the code according to the device config; e.g. #if defined(ATH_HAL) || defined(ATH_AR5416) || defined(ATH_AR9160) || defined(ATH_AR9280) or possibly consolidate this check in one spot and define something like AH_SUPPORT_AR5416 to enable the extended descriptor format support. Beware of driver code that depends on AH_SUPPORT_AR5416 (grep shows several uses). For now just fixing the immediate problem is sufficient; I'll get to cleaning this stuff up later (unless you care to deal with it). Sam From matheus at eternamente.info Fri May 1 18:18:55 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Fri May 1 18:19:03 2009 Subject: ata and seagate microdrive problems In-Reply-To: <1239874051.12971.1.camel@buffy.york.ac.uk> References: <00652174bdc7334a1a2d3d8db7c667a7.squirrel@10.1.1.10> <1239874051.12971.1.camel@buffy.york.ac.uk> Message-ID: On Thu, April 16, 2009 06:27, Gavin Atkinson wrote: > On Thu, 2009-04-09 at 19:03 -0300, Nenhum_de_Nos wrote: >> hail, >> >> I'm trying to install current on via itx using ide 44pin to cf adapter >> and >> a seagate 8GB microdrive. >> >> I thought it was to be ok, but just today when I received the adapter I >> got nowhere in this. I tried 7.1-STABLE and 8.0-CURRENT from 200902, and >> both fail to find it. the same thing in 7.1R. > > Can you boot in verbose mode, and post the dmesg somewhere please? > Also, can you confirm which ATA channel the drive should show up on? > > Thanks, > > Gavin sorry for the long delay, too busy :( but tell me how to boot in debug, as I can't boot it from itself, and I don't have any serial cable. just say what to do, and I'll try my best. I must run current for what I want to do with it, thats my only limit. thanks, matheus >> I found this http://forums.freebsd.org/archive/index.php/t-2733.html, >> but >> hw.ata.ata_dma_check_80pin=0 is no good :( >> >> and found this pr >> http://lists.freebsd.org/pipermail/freebsd-bugs/2007-March/022884.html >> as >> the only pr that mentions microdrive (I may be wrong). > > -- We will call you cygnus, The God of balance you shall be From jkim at FreeBSD.org Fri May 1 20:10:56 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Fri May 1 20:11:03 2009 Subject: cannot compile sched_ule without options SMP In-Reply-To: References: <20090430013428.cb4f804b.nork@FreeBSD.org> Message-ID: <200905011610.42613.jkim@FreeBSD.org> On Thursday 30 April 2009 11:04 pm, pluknet wrote: > 2009/5/1 pluknet : > > 2009/5/1 Jeff Roberson : > >> On Thu, 30 Apr 2009, pluknet wrote: > >>> 2009/4/30 Jeff Roberson : > >>>> On SMP machines you should now see output like this: > >>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > >>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads > >>>> > >>>> If you detect any irregularities with kern.sched.topology_spec > >>>> or this dmesg > >>>> line please report them. > >>> > >>> Hi, Jeff. > >>> > >>> I have such mismatch. This is an Intel E7200. > >>> > >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > >>> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads > >>> cpu0 (BSP): APIC ID: 0 > >>> cpu1 (AP/HT): APIC ID: 1 > >>> > >>> So it should be instead: 1 package(s) x 2 core(s) > >>> cpu0 (BSP): APIC ID: 0 > >>> cpu1 (AP): APIC ID: 1 > >> > >> Can you please repeat the following steps as I have done here: > > > > (kgdb) p/x cpu_high > > $1 = 0x2 > > (kgdb) p/x cpu_cores > > $2 = 0x1 > > (kgdb) p/x cpu_logical > > $3 = 0x2 > > (kgdb) p/x cpu_feature > > $4 = 0xbfebfbff > > (kgdb) p/x logical_cpus > > $5 = 0x2 > > (kgdb) p/x hyperthreading_cpus > > $6 = 0x2 > > Follow up myself: > > What is embarrassing me is HTT feature enabled. May the reason be > in a buggy CPUID ? No, the flag does not mean it supports Hyperthreading. It means more than one logical core is supported (multi-threading) although the name didn't change for historical reason. ;-) Can you try the attached patch? Thanks! Jung-uk Kim -------------- next part -------------- --- sys/amd64/amd64/identcpu.c 29 Apr 2009 06:54:40 -0000 1.172 +++ sys/amd64/amd64/identcpu.c 1 May 2009 20:00:59 -0000 @@ -472,6 +472,24 @@ cpu_feature = regs[3]; cpu_feature2 = regs[2]; + /* + * Clear "Limit CPUID Maxval" bit and get the highest + * basic CPUID function again if it is set from BIOS. + * It is necessary for probing correct CPU topology later. + * XXX This is only done on BSP. + */ + if (cpu_vendor_id == CPU_VENDOR_INTEL && + cpu_high > 0 && cpu_high < 4 && + (cpu_feature & CPUID_HTT) != 0) { + uint64_t msr; + msr = rdmsr(MSR_IA32_MISC_ENABLE); + if ((msr & 0x400000ULL) != 0) { + wrmsr(MSR_IA32_MISC_ENABLE, msr & ~0x400000ULL); + do_cpuid(0, regs); + cpu_high = regs[0]; + } + } + if (cpu_vendor_id == CPU_VENDOR_INTEL || cpu_vendor_id == CPU_VENDOR_AMD || cpu_vendor_id == CPU_VENDOR_CENTAUR) { --- sys/i386/i386/identcpu.c 29 Apr 2009 06:54:40 -0000 1.201 +++ sys/i386/i386/identcpu.c 1 May 2009 20:00:59 -0000 @@ -323,15 +323,6 @@ strcat(cpu_model, "Pentium 4"); cpu = CPU_P4; model = (cpu_id & 0x0f0) >> 4; - if (model == 3 || model == 4 || model == 6) { - uint64_t tmp; - - tmp = rdmsr(MSR_IA32_MISC_ENABLE); - wrmsr(MSR_IA32_MISC_ENABLE, - tmp & ~(1LL << 22)); - do_cpuid(0, regs); - cpu_high = regs[0]; - } break; default: strcat(cpu_model, "unknown"); @@ -1110,6 +1101,24 @@ cpu_vendor_id = find_cpu_vendor_id(); + /* + * Clear "Limit CPUID Maxval" bit and get the highest + * basic CPUID function again if it is set from BIOS. + * It is necessary for probing correct CPU topology later. + * XXX This is only done on BSP. + */ + if (cpu_vendor_id == CPU_VENDOR_INTEL && + cpu_high > 0 && cpu_high < 4 && + (cpu_feature & CPUID_HTT) != 0) { + uint64_t msr; + msr = rdmsr(MSR_IA32_MISC_ENABLE); + if ((msr & 0x400000ULL) != 0) { + wrmsr(MSR_IA32_MISC_ENABLE, msr & ~0x400000ULL); + do_cpuid(0, regs); + cpu_high = regs[0]; + } + } + /* Detect AMD features (PTE no-execute bit, 3dnow, 64 bit mode etc) */ if (cpu_vendor_id == CPU_VENDOR_INTEL || cpu_vendor_id == CPU_VENDOR_AMD) { From matheus at eternamente.info Fri May 1 21:12:10 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Fri May 1 21:12:18 2009 Subject: Any further progresss on Nvidia SATA? In-Reply-To: <49F80971.9070300@quip.cz> References: <20090428162926.3ea9f861@serene.no-ip-org> <49F80971.9070300@quip.cz> Message-ID: <9873873469b8064e7b9485cb24d1a45d.squirrel@10.1.1.10> On Wed, April 29, 2009 05:01, Miroslav Lachman wrote: > Conrad J. Sabatier wrote: >> I have't checked any of the more recent FreeBSD snapsots, but am just >> wondering if any further progress has been made on the functionality of >> the Nvidia SATA controller under AMD64. >> >> My last attempt to apply the patches Soren sent me did recognize both >> the controller and hard drive, but still no CD/DVD-ROM functionality. >> >> Also, why are the snapshots on the main FreeBSD server so out of date? >> Last I looked, the most recent was from Februrary 2009. >> >> Been making do with Ubuntu Linux, but...I miss my FreeBSD!!!! >> >> Please, anyone out there, could you offer some guidance or suggetions or >> more recent patches, so I can get back up and running with my Favorite >> OS of ALL TIME (tm)? > > I don't have answer to your questions, but there are almost daily > snapshots http://pub.allbsd.org/FreeBSD-snapshots/ > > Miroslav Lachman that saved my day !! I'm testing some hardware that depends on corrent, but current official snaps are too old for me :( and as this hardware of mine can't get to the point of building a new current, this repository is gold for me. thanks, this should be broadcasted ... :) matheus -- We will call you cygnus, The God of balance you shall be From ben at wanderview.com Sat May 2 04:49:49 2009 From: ben at wanderview.com (Ben Kelly) Date: Sat May 2 04:49:56 2009 Subject: [patch] zfs kmem fragmentation Message-ID: Hello all, Lately I've been looking into the "kmem too small" panics that often occur with zfs if you don't restrict the arc. What I found in my test environment was that everything works well until the kmem usage hits the 75% limit set in arc.c. At this point the arc is shrunk and slabs are reclaimed from uma. Unfortunately, every time this reclamation process runs the kmem space becomes more fragmented. The vast majority of the time my machine hits the "kmem too small" panic it has over 200MB of kmem space available, but the largest fragment is less than 128KB. Ideally things would be arranged to free memory without fragmentation. I have tried a few things along those lines, but none of them have been successful so far. I'm going to continue that work, but in the meantime I've put together a patch that tries to avoid fragmentation by slowing kmem growth before the aggressive reclamation process is required: http://www.wanderview.com/svn/public/misc/zfs/zfs_kmem_limit.diff It uses the following heuristics to do this: - Start arc_c at arc_c_min instead of arc_c_max. This causes the system to warm up more slowly. - Half the rate arc_c grows when kmem exceeds kmem_slow_growth_thresh - Stop arc_c growth when kmem exceeds kmem_target - Evict arc data when the kmem exceeds kmem_target - If kmem usage exceeds kmem_target then ask the pagedaemon to reclaim pages - If the largest kmem fragment is less than kmem_fragment_target then ask the pagedaemon to reclaim pages - If the largest kmem fragment is less than a kmem_fragment_thresh then force the aggressve kmem/arc reclamation process The defaults for the various targets and thresholds are: kmem_reclaim_threshold = 7/8 kmem kmem_target = 3/4 kmem kmem_slow_growth_threshold = 5/8 kmem kmem_fragment_target = 1/8 kmem kmem_fragment_thresh = 1/16 kmem With this patch I've been able to run my load tests with the default arc size with kmem values of 512MB to 700MB. I tried one loaded run with a 300MB kmem, but it panic'ed due to legitimate, non-fragmented kmem exhaustion. Please note that you may still encounter some fragmentation. Its possible for the system to get stuck in a degraded state where its constantly trying to free pages and memory in attempt to fix the fragmentation. If the system is in this state the kstat.zfs.misc.arcstats.fragmented_kmem_count sysctl will be increasing at a fairly rapid rate. Anyway, I just thought I would put this out there in case anyone wanted to try to test with it. I've mainly been loading it using rsync between two pools on a non-SMP, i386, with 2GB memory. Also, if anyone is interested in helping with the fragmentation problem please let me know. At this point I think the best odds are to modify UMA to allow some zones to use a custom slab size of 128KB (max zfs buffer size) so that most of the allocations from kmem are the same size. It also occurred to me that much of this mess would be simpler if kmem information were passed up through the vnode so that the top layer entities like pagedaemon could make better choices for the overall memory usage of the system. Right now we have a sub- system two or three layers down making decisions for everyone. Anyway, suggestions and insights are more than welcome. Thanks! - Ben From pluknet at gmail.com Sat May 2 07:50:54 2009 From: pluknet at gmail.com (pluknet) Date: Sat May 2 07:51:01 2009 Subject: cannot compile sched_ule without options SMP In-Reply-To: <200905011610.42613.jkim@FreeBSD.org> References: <20090430013428.cb4f804b.nork@FreeBSD.org> <200905011610.42613.jkim@FreeBSD.org> Message-ID: 2009/5/2 Jung-uk Kim : > On Thursday 30 April 2009 11:04 pm, pluknet wrote: >> 2009/5/1 pluknet : >> > 2009/5/1 Jeff Roberson : >> >> On Thu, 30 Apr 2009, pluknet wrote: >> >>> 2009/4/30 Jeff Roberson : >> >>>> On SMP machines you should now see output like this: >> >>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> >>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >> >>>> >> >>>> If you detect any irregularities with kern.sched.topology_spec >> >>>> or this dmesg >> >>>> line please report them. >> >>> >> >>> Hi, Jeff. >> >>> >> >>> I have such mismatch. This is an Intel E7200. >> >>> >> >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> >>> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads >> >>> cpu0 (BSP): APIC ID: 0 >> >>> cpu1 (AP/HT): APIC ID: 1 >> >>> >> >>> So it should be instead: 1 package(s) x 2 core(s) >> >>> cpu0 (BSP): APIC ID: 0 >> >>> cpu1 (AP): APIC ID: 1 >> >> >> >> Can you please repeat the following steps as I have done here: >> > >> > (kgdb) p/x cpu_high >> > $1 = 0x2 >> > (kgdb) p/x cpu_cores >> > $2 = 0x1 >> > (kgdb) p/x cpu_logical >> > $3 = 0x2 >> > (kgdb) p/x cpu_feature >> > $4 = 0xbfebfbff >> > (kgdb) p/x logical_cpus >> > $5 = 0x2 >> > (kgdb) p/x hyperthreading_cpus >> > $6 = 0x2 >> >> Follow up myself: >> >> What is embarrassing me is HTT feature enabled. May the reason be >> in a buggy CPUID ? > > No, the flag does not mean it supports Hyperthreading. It means more > than one logical core is supported (multi-threading) although the > name didn't change for historical reason. ;-) > I see now. > Can you try the attached patch? > Nice, it works! cpu_mp_probe(): mp_ncpus = 2 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 (kgdb) p/x cpu_high $1 = 0xa (kgdb) p/x cpu_cores $2 = 0x2 (kgdb) p/x cpu_logical $3 = 0x1 (kgdb) p/x cpu_feature $4 = 0xbfebfbff (kgdb) p/x logical_cpus $5 = 0x2 (kgdb) p/x hyperthreading_cpus $6 = 0x1 -- wbr, pluknet From pluknet at gmail.com Sat May 2 08:26:33 2009 From: pluknet at gmail.com (pluknet) Date: Sat May 2 08:26:40 2009 Subject: cannot compile sched_ule without options SMP In-Reply-To: References: <20090430013428.cb4f804b.nork@FreeBSD.org> Message-ID: 2009/5/1 Jeff Roberson : > > > On Fri, 1 May 2009, pluknet wrote: > >> 2009/5/1 pluknet : >>> [snip] >>> (kgdb) p/x cpu_high >>> $1 = 0x2 >>> (kgdb) p/x cpu_cores >>> $2 = 0x1 >>> (kgdb) p/x cpu_logical >>> $3 = 0x2 >>> (kgdb) p/x cpu_feature >>> $4 = 0xbfebfbff >>> (kgdb) p/x logical_cpus >>> $5 = 0x2 >>> (kgdb) p/x hyperthreading_cpus >>> $6 = 0x2 >>> >> >> Follow up myself: >> >> What is embarrassing me is HTT feature enabled. May the reason be in a >> buggy CPUID ? > > This is very curious. With older revisions did the system believe your CPUs > were HTT? You can tell if you had sysctl machdep.hyperthreading_allowed or > via the ULE kern.sched.topology_spec sysctl. > -current from February. I'm afraid it did. machdep.hyperthreading_allowed: 1 kern.sched.topology_spec: 0, 1 0, 1 HTT group FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 > I didn't realize there were any core2 CPUs without leaf 4 of cpuid. However, > I didn't write the earlier hyperthread detection code. I'll see if I can > get jhb to chime in. > > The HTT feature bit is set on many processors that don't have hyperthreads. > So we need a secondary way of differentiating. I don't know what that is > in this case. -- wbr, pluknet From julian at elischer.org Sat May 2 17:21:47 2009 From: julian at elischer.org (Julian Elischer) Date: Sat May 2 17:21:54 2009 Subject: VIMAGE status Message-ID: <49FC812B.2070305@elischer.org> The VIMAGE code is nearly all in the the kernel. One is now able to make VIMAGE kernels (add options VIMAGE) though they don't actually allow you to make multiple vimages instances yet.. The VIMAGE option enables all the low level changes needed throughout the kernel. The VIMAGE_GLOBALS option basically sets thing sback to how they were before. Having neither (the default) gives a kernel that is a kind of hybrid. The Hybrid state is what will go forward as 'NON-VIMAGE' mode and the VIMAGE_GLOBALS mode will probably go away in time as it complicates the code. The aim of this mail is to ask people to try add the VIMAGE option to their regular kernels and try use them as you woudl normally. You will not yet be able to use any new VIMAGE features but we should be fully compatible with previous kernels. Please report any concerns to the freebsd-virtualization@ mailing list. THEORETICALLY you should not see any changes in behaviour, however we have the following issues: * SCTP is not fully converted yet. add 'nooptions SCTP' for now if you are not using it yet. * An NFS (crash) issue was reported. This MAY have been fixed... Theory tells us that all three kernel options should behave about the same but if you do try this, and have any benchmarking facilities, it would be incredibly useful if you could let us know if you see any performance changes between the three. thanks, Julian (currently running a VIMAGE kernel myself) From tinderbox at freebsd.org Sat May 2 17:53:35 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat May 2 17:53:55 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090502175330.D0EEA7302F@freebsd-current.sentex.ca> TB --- 2009-05-02 16:13:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-02 16:13:58 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-02 16:13:58 - cleaning the object tree TB --- 2009-05-02 16:14:28 - cvsupping the source tree TB --- 2009-05-02 16:14:28 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-02 16:14:40 - building world TB --- 2009-05-02 16:14:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-02 16:14:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-02 16:14:40 - TARGET=pc98 TB --- 2009-05-02 16:14:40 - TARGET_ARCH=i386 TB --- 2009-05-02 16:14:40 - TZ=UTC TB --- 2009-05-02 16:14:40 - __MAKE_CONF=/dev/null TB --- 2009-05-02 16:14:40 - cd /src TB --- 2009-05-02 16:14:40 - /usr/bin/make -B buildworld >>> World build started on Sat May 2 16:14:42 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 2 17:36:46 UTC 2009 TB --- 2009-05-02 17:36:46 - generating LINT kernel config TB --- 2009-05-02 17:36:46 - cd /src/sys/pc98/conf TB --- 2009-05-02 17:36:46 - /usr/bin/make -B LINT TB --- 2009-05-02 17:36:46 - building LINT kernel TB --- 2009-05-02 17:36:46 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-02 17:36:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-02 17:36:46 - TARGET=pc98 TB --- 2009-05-02 17:36:46 - TARGET_ARCH=i386 TB --- 2009-05-02 17:36:46 - TZ=UTC TB --- 2009-05-02 17:36:46 - __MAKE_CONF=/dev/null TB --- 2009-05-02 17:36:46 - cd /src TB --- 2009-05-02 17:36:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 2 17:36:46 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel mp_machdep.o(.text+0x94c): In function `ipi_bitmap_handler': : undefined reference to `profclockintr' mp_machdep.o(.text+0x95d): In function `ipi_bitmap_handler': : undefined reference to `statclockintr' mp_machdep.o(.text+0x96a): In function `ipi_bitmap_handler': : undefined reference to `hardclockintr' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-02 17:53:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-02 17:53:30 - ERROR: failed to build lint kernel TB --- 2009-05-02 17:53:30 - 4701.91 user 451.92 system 5972.11 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From ivoras at freebsd.org Sat May 2 18:56:34 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat May 2 18:56:43 2009 Subject: VirtualBox Message-ID: In case there are people who haven't heard it yet: VirtualBox is apparently coming to FreeBSD! http://vbox.innotek.de/pipermail/vbox-dev/2009-April/001328.html Finally! They still need help, though. From matheus at eternamente.info Sat May 2 19:12:28 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Sat May 2 19:12:36 2009 Subject: ata and seagate microdrive problems In-Reply-To: References: <00652174bdc7334a1a2d3d8db7c667a7.squirrel@10.1.1.10> <1239874051.12971.1.camel@buffy.york.ac.uk> Message-ID: On Fri, May 1, 2009 15:18, Nenhum_de_Nos wrote: > > On Thu, April 16, 2009 06:27, Gavin Atkinson wrote: >> On Thu, 2009-04-09 at 19:03 -0300, Nenhum_de_Nos wrote: >>> hail, >>> >>> I'm trying to install current on via itx using ide 44pin to cf adapter >>> and >>> a seagate 8GB microdrive. >>> >>> I thought it was to be ok, but just today when I received the adapter I >>> got nowhere in this. I tried 7.1-STABLE and 8.0-CURRENT from 200902, >>> and >>> both fail to find it. the same thing in 7.1R. >> >> Can you boot in verbose mode, and post the dmesg somewhere please? >> Also, can you confirm which ATA channel the drive should show up on? >> >> Thanks, >> >> Gavin > > sorry for the long delay, too busy :( > > but tell me how to boot in debug, as I can't boot it from itself, and I > don't have any serial cable. just say what to do, and I'll try my best. > > I must run current for what I want to do with it, thats my only limit. > > thanks, > > matheus just for the record, I just tried current snapshot from http://pub.allbsd.org/FreeBSD-snapshots/i386/8.0-HEAD-20090501-JPSNAP/cdrom/8.0-HEAD-20090501-JPSNAP-i386-disc1.iso and no go. BTX loader finds it though ( BIOS drive c: is disk0). acpi on, no usb keyboard :( and no disk also. I have OpenBSD on this disk, which I'll willing to wipe out to have FreeBSD. but if I can get any info from OpenBSD that would help, just say so. also, I'm downloading the livefs from this very current snapsjot, just to see if I can save a verbose boot anyhow. matheus >>> I found this http://forums.freebsd.org/archive/index.php/t-2733.html, >>> but >>> hw.ata.ata_dma_check_80pin=0 is no good :( >>> >>> and found this pr >>> http://lists.freebsd.org/pipermail/freebsd-bugs/2007-March/022884.html >>> as >>> the only pr that mentions microdrive (I may be wrong). >> >> > > > -- > We will call you cygnus, > The God of balance you shall be > > _______________________________________________ > 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" > -- We will call you cygnus, The God of balance you shall be From tmclaugh at sdf.lonestar.org Sat May 2 21:12:43 2009 From: tmclaugh at sdf.lonestar.org (Tom McLaughlin) Date: Sat May 2 21:12:49 2009 Subject: NFS lockd/statd lock up network connection In-Reply-To: References: <49D851FC.4090103@sdf.lonestar.org> <49EBC778.7080305@sdf.lonestar.org> Message-ID: <49FCB742.2080502@sdf.lonestar.org> Ryan Stone wrote, On 04/20/2009 10:14 PM: > Well, that does confirm that your system is running out of clusters. > Because you lose all network connectivity I'd suspect a leak, probably > in code exercised by lockd. I'm afraid that I know absolutely nothing > about it so I can't offer any kind of solution. Hopefully somebody who > does know something is paying attention. > > One thing you could try is setting the tunable kern.ipc.nmbclusters > higher than 25600 -- maybe 40000? If it's a leak that won't help > anything but if your system just doesn't have enough clusters that will > fix it. Yup, upped the value to 40000 and it still runs out of mbuf clusters. Appears to be something lockd is triggering. I'll check with dfr. tom -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | From tmclaugh at sdf.lonestar.org Sat May 2 21:21:57 2009 From: tmclaugh at sdf.lonestar.org (Tom McLaughlin) Date: Sat May 2 21:22:03 2009 Subject: NFS lockd/statd lock up network connection In-Reply-To: References: <49D851FC.4090103@sdf.lonestar.org> Message-ID: <49FCB96E.1010604@sdf.lonestar.org> Doug Rabson wrote, On 04/08/2009 03:20 PM: > On 5 Apr 2009, at 07:38, Tom McLaughlin wrote: > >> Hey, I have a recent -CURRENT box which has a mount exported from an >> OpenBSD NFS server. Recently I enabled lockd and statd on the machine >> but this has started to cause the network connection on the machine >> to lockup. I find the following in dmesg: >> >> nfs server exports:/mnt/raid0/net/home: lockd not responding >> nfs server exports:/mnt/raid0/net/home: lockd not responding >> nfs server exports:/mnt/raid0/net/home: lockd not responding >> nfs server exports:/mnt/raid0/net/home: lockd not responding >> nfs server exports:/mnt/raid0/net/home: lockd not responding >> nfs server exports:/mnt/raid0/net/home: lockd not responding >> nfs server exports:/mnt/raid0/net/home: lockd not responding >> nfs server exports:/mnt/raid0/net/home: lockd not responding >> NLM: failed to contact remote rpcbind, stat = 5, port = 28416 >> >> Additionally I see this when trying to restart netif: >> >> em0: Could not setup receive structures >> >> I've tried building with NFS_LEGACYRPC but that has not changed >> anything. Additionally I've tested this on 7-STABLE and while lockd >> still does not work (so, looks like I'll still have to work around >> my need for NFS locking) the network connection at least does not >> lock up. Is what I'm seeing evidence of some further problem? > > It looks as if lockd is not running on the server. The NFS locking > protocol needs it enabled at both ends. Also, NFS_LEGACYRPC won't > affect this - the record locking code always uses the new RPC code. Hi Doug, lockd is runing on both ends. The problem appears to be with the system running out of mbuf clusters when using lockd. [1] For now I'm mounting the particular mount with nolockd as an option to get around this. I've gotten errors with my -STABLE box using this mount with lockd enabled but at least the system didn't run out of mbuf clusters and lose all network connectivity. tom [1] http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006433.html -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | From tinderbox at freebsd.org Sun May 3 03:33:27 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun May 3 03:33:39 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090503033323.BE8AE7302F@freebsd-current.sentex.ca> TB --- 2009-05-03 01:54:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-03 01:54:21 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-03 01:54:21 - cleaning the object tree TB --- 2009-05-03 01:54:42 - cvsupping the source tree TB --- 2009-05-03 01:54:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-03 01:54:49 - building world TB --- 2009-05-03 01:54:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-03 01:54:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-03 01:54:49 - TARGET=pc98 TB --- 2009-05-03 01:54:49 - TARGET_ARCH=i386 TB --- 2009-05-03 01:54:49 - TZ=UTC TB --- 2009-05-03 01:54:49 - __MAKE_CONF=/dev/null TB --- 2009-05-03 01:54:49 - cd /src TB --- 2009-05-03 01:54:49 - /usr/bin/make -B buildworld >>> World build started on Sun May 3 01:54:51 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 3 03:16:53 UTC 2009 TB --- 2009-05-03 03:16:53 - generating LINT kernel config TB --- 2009-05-03 03:16:53 - cd /src/sys/pc98/conf TB --- 2009-05-03 03:16:53 - /usr/bin/make -B LINT TB --- 2009-05-03 03:16:53 - building LINT kernel TB --- 2009-05-03 03:16:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-03 03:16:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-03 03:16:53 - TARGET=pc98 TB --- 2009-05-03 03:16:53 - TARGET_ARCH=i386 TB --- 2009-05-03 03:16:53 - TZ=UTC TB --- 2009-05-03 03:16:53 - __MAKE_CONF=/dev/null TB --- 2009-05-03 03:16:53 - cd /src TB --- 2009-05-03 03:16:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 3 03:16:53 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel mp_machdep.o(.text+0x94c): In function `ipi_bitmap_handler': : undefined reference to `profclockintr' mp_machdep.o(.text+0x95d): In function `ipi_bitmap_handler': : undefined reference to `statclockintr' mp_machdep.o(.text+0x96a): In function `ipi_bitmap_handler': : undefined reference to `hardclockintr' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-03 03:33:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-03 03:33:23 - ERROR: failed to build lint kernel TB --- 2009-05-03 03:33:23 - 4703.70 user 448.91 system 5942.20 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From mav at FreeBSD.org Sun May 3 22:18:25 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun May 3 22:18:32 2009 Subject: Fighting for the power. Message-ID: <49FE1826.4060000@FreeBSD.org> I would like to summarize some of my knowledge on reducing FreeBSD power consumption and describe some new things I have recently implemented in 8-CURRENT. The main character of this story is my 12" Acer TravelMate 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under amd64 8-CURRENT. Modern systems, especially laptops, are implementing big number of power-saving technologies. Some of them are working automatically, other have significant requirements and need special system tuning or trade-offs to be effectively used. So here is the steps: 1. CPU CPU is the most consuming part of the system. Under the full load it alone may consume more then 40W of power, but for real laptop usage the most important is idle consumption. Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: P-states and throttling Enabling powerd allows to effectively control CPU frequency/voltage depending on CPU load. powerd on recent system can handle it quite transparently. By default, frequency controlled via mix of EIST and throttling technologies. First one controls both core frequency and voltage, second - only core frequency. Both technologies give positive power-saving effect. But effect of throttling is small and can be completely hidden by using C2 state, that's why I recommend to disable throttling control by adding to /boot/loader.conf: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 In my case frequency/voltage control saves about 5W of idle power. C-states - C1 stops clock on some parts of CPU core during inactivity. It is safe, cheap and supported by CPUs for ages. System uses C1 state by default. - C2 state allows CPU to turn off all core clocks on idle. It is also cheap, but requires correct ACPI-chipset-CPU interoperation to be used. Use of C2 state can be enabled by adding to /etc/rc.conf: performance_cx_lowest="C2" economy_cx_lowest="C2" Effect from this state is not so big when powerd is used, but still noticeable, - C3 state allows CPU completely stop all internal clocks, reduce voltage and disconnect from system bus. This state gives additional power saving effect, but it is not cheap and require trade-offs. As soon as CPU is completely stopped in C3 state, local APIC timers in each CPU core, used by FreeBSD as event sources on SMP, are not functioning. It stops system time, breaks scheduling that makes system close to dead. The only solution for this problem is to use some external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to resurrect them for SMP systems. To use them, you can disable local APIC timers by adding to /boot/loader.conf: hint.apic.0.clock=0 Also, to drop/rise voltage on C3, CPU needs time (57us for my system). It means that C3 state can't be effectively used when system is waking up often. To increase inactivity periods we should reduce interrupt rate as much as possible by adding to loader.conf: kern.hz=100 It may increase system response time a bit, but it is not significant for laptop. Also we may avoid additional 128 interrupts per second per core, by the cost of scheduling precision, with using i8254 timer also for statistic collection purposes instead of RTC clock, by using another newly added option: hint.atrtc.0.clock=0 As result, system has only 100 interrupts per core and CPUs are using C3 with high efficiency: %sysctl dev.cpu |grep cx dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us Result of effective C3 state usage, comparing to C2+powerd, is about 2W. 2. PCI devices PCI bus provides method to control device power. For example, I have completely no use for my FireWire controller and most of time - EHCI USB controller. Disabling them allows me to save about 3W of power. To disable all unneeded PCI devices you should build kernel without their drivers and add to loader.conf: hw.pci.do_power_nodriver=3 To enable devices back all you need to do is just load their drivers as modules. 3. Radios WiFi and Bluetooth adapters can consume significant power when used (up to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling them with mechanical switch on laptop case saves energy even when they are not connected. 4. HDA modem I was surprised, but integrated HDA modem consumed about 1W of power even when not used. I have used the most radical solution - removed it mechanically from socket. Case surface in that area become much cooler. 5. HDA sound To reduce number of sound generated interrupts I have added to the loader.conf: hint.pcm.0.buffersize=65536 hint.pcm.1.buffersize=65536 hw.snd.feeder_buffersize=65536 hw.snd.latency=7 6. HDD First common recommendation is use tmpfs for temporary files. RAM is cheap, fast and anyway with you. Also you may try to setup automatic idle drive spin-down, but if it is the only system drive you should be careful, as every spin-up reduces drive's life time. For several months (until I have bought SATA SSD) I have successfully used SDHC card in built-in PCI sdhci card reader as main filesystem. On random read requests it is much faster then HDD, but it is very slow on random write. Same time it consumes almost nothing. USB drives could also be used, but effect is much less as EHCI USB controller consumes much power. Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Removing it completely saves 2W. 7. SATA Comparing to PATA, SATA interface uses differential signaling for data transfer. To work properly it has to transmit pseudo-random scrambled sequence even when idle. As you understand, that requires power. But SATA implements two power saving modes: PARTIAL and SLUMBER. These modes could be activated by either host or device if both sides support them. PARTIAL mode just stops scrambling, but keeps neutral link state, resume time is 50-100us. SLUMBER mode powers down interface completely, but respective resume time is 3-10ms. I have added minimal SATA power management to AHCI driver. There are hint.ata.X.pm_level loader tunables can be used to control it now. Setting it to 1 allows drive itself to initiate power saving, when it wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and SLUMBER transitions after every command completion. Note that SATA power saving is not compatible with drive hot-swap, as controller unable to detect drive presence when link is powered-down. In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. So what have I got? To monitor real system power consumption I am using information provided by ACPI battery via `acpiconf -i0` command: Original system: Design capacity: 4800 mAh Last full capacity: 4190 mAh Technology: secondary (rechargeable) Design voltage: 11100 mV Capacity (warn): 300 mAh Capacity (low): 167 mAh Low/warn granularity: 32 mAh Warn/full granularity: 32 mAh Model number: Victoria Serial number: 292 Type: LION OEM info: SIMPLO State: discharging Remaining capacity: 93% Remaining time: 2:24 Present rate: 1621 mA Voltage: 12033 mV Tuned system: %acpiconf -i0 Design capacity: 4800 mAh Last full capacity: 4190 mAh Technology: secondary (rechargeable) Design voltage: 11100 mV Capacity (warn): 300 mAh Capacity (low): 167 mAh Low/warn granularity: 32 mAh Warn/full granularity: 32 mAh Model number: Victoria Serial number: 292 Type: LION OEM info: SIMPLO State: discharging Remaining capacity: 94% Remaining time: 4:47 Present rate: 826 mA Voltage: 12231 mV So I have really doubled my on-battery time by this tuning - 4:47 hours instead of 2:24 with default settings. Preinstalled vendor-tuned Windows XP on the same system, provides maximum 3:20 hours. -- Alexander Motin From amdmi3 at amdmi3.ru Sun May 3 22:43:04 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Sun May 3 22:43:12 2009 Subject: geom_part Message-ID: <20090503224205.GB1414@hades.panopticon> Hi! I've upgraded one of my boxes to current recently and ran into some problems with new geom_part. First, it's impossible to edit bsd label online. # bsdlabel -e /dev/ad8 [edit] bsdlabel: Class not found re-edit the label? [y]: Setting sysctl kern.geom.debugflags to 16 helps. Next, it's no longer possible to use nested configuration. If I add bsd label to, say, /dev/ad8f, no subpartitions (ad8fa, ad8fd ...) will be shown. They pop up after loading geom_bsd. Finally, seems like bsd label support is broken: # bsdlabel /dev/ad8 # /dev/ad8: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2097152 0 4.2BSD 2048 16384 28528 b: 20971520 2097152 swap c: 390721968 0 unused 0 0 # "raw" part, don't edit d: 20971520 23068672 4.2BSD 2048 16384 28528 e: 2097152 44040192 4.2BSD 2048 16384 28528 f: 20971520 46137344 4.2BSD 2048 16384 28528 g: 41943040 67108864 unused 0 0 h: 281670064 109051904 unused 0 0 # ls /dev/ad8* /dev/ad8 /dev/ad8b /dev/ad8e /dev/ad8g /dev/ad8a /dev/ad8d /dev/ad8f No h partition! -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From tinderbox at freebsd.org Sun May 3 23:33:07 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun May 3 23:33:25 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090503233304.026677302F@freebsd-current.sentex.ca> TB --- 2009-05-03 21:53:53 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-03 21:53:53 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-03 21:53:53 - cleaning the object tree TB --- 2009-05-03 21:54:25 - cvsupping the source tree TB --- 2009-05-03 21:54:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-03 21:54:34 - building world TB --- 2009-05-03 21:54:34 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-03 21:54:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-03 21:54:34 - TARGET=pc98 TB --- 2009-05-03 21:54:34 - TARGET_ARCH=i386 TB --- 2009-05-03 21:54:34 - TZ=UTC TB --- 2009-05-03 21:54:34 - __MAKE_CONF=/dev/null TB --- 2009-05-03 21:54:34 - cd /src TB --- 2009-05-03 21:54:34 - /usr/bin/make -B buildworld >>> World build started on Sun May 3 21:54:36 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 3 23:16:33 UTC 2009 TB --- 2009-05-03 23:16:33 - generating LINT kernel config TB --- 2009-05-03 23:16:33 - cd /src/sys/pc98/conf TB --- 2009-05-03 23:16:33 - /usr/bin/make -B LINT TB --- 2009-05-03 23:16:33 - building LINT kernel TB --- 2009-05-03 23:16:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-03 23:16:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-03 23:16:33 - TARGET=pc98 TB --- 2009-05-03 23:16:33 - TARGET_ARCH=i386 TB --- 2009-05-03 23:16:33 - TZ=UTC TB --- 2009-05-03 23:16:33 - __MAKE_CONF=/dev/null TB --- 2009-05-03 23:16:33 - cd /src TB --- 2009-05-03 23:16:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 3 23:16:33 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel apm.o(.text+0x109a): In function `apm_attach': : undefined reference to `atrtcclock_disable' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-03 23:33:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-03 23:33:03 - ERROR: failed to build lint kernel TB --- 2009-05-03 23:33:03 - 4701.93 user 452.49 system 5950.70 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From nate at root.org Sun May 3 23:44:31 2009 From: nate at root.org (Nate Lawson) Date: Sun May 3 23:44:43 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <49FE29A4.30507@root.org> Alexander Motin wrote: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. Very nice summary. Thanks for doing the research. > P-states and throttling > Enabling powerd allows to effectively control CPU frequency/voltage > depending on CPU load. powerd on recent system can handle it quite > transparently. By default, frequency controlled via mix of EIST and > throttling technologies. First one controls both core frequency and > voltage, second - only core frequency. Both technologies give positive > power-saving effect. But effect of throttling is small and can be > completely hidden by using C2 state, that's why I recommend to disable > throttling control by adding to /boot/loader.conf: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 When I first wrote cpufreq, there was some question if vendors (even non-Intel) might use throttling for more than just cutting the duty cycle. It turns out they haven't, and have focused more on dropping the voltage with P-state transitions (EIST, PowerNow) and are treating throttling as a legacy feature. The time may have come to disable p4tcc and throttling by default, as long as it's easy for a user to enable them again. Perhaps just a change to boot/default/device.hints? > In my case frequency/voltage control saves about 5W of idle power. > C-states > - C1 stops clock on some parts of CPU core during inactivity. It is > safe, cheap and supported by CPUs for ages. System uses C1 state by > default. > - C2 state allows CPU to turn off all core clocks on idle. It is also > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > Use of C2 state can be enabled by adding to /etc/rc.conf: > performance_cx_lowest="C2" > economy_cx_lowest="C2" The default settings in rc.conf should allow the lowest Cx setting available to be used. Perhaps that changed? Really, we want C3+ to be enabled by default without the user doing anything. > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but it is not cheap and require trade-offs. > As soon as CPU is completely stopped in C3 state, local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. It stops system time, breaks scheduling that makes system > close to dead. The only solution for this problem is to use some > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > resurrect them for SMP systems. To use them, you can disable local APIC > timers by adding to /boot/loader.conf: > hint.apic.0.clock=0 > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > It means that C3 state can't be effectively used when system is waking > up often. To increase inactivity periods we should reduce interrupt rate > as much as possible by adding to loader.conf: > kern.hz=100 Yeah, hz=1000 doesn't make sense for laptops and I use hz=100 everywhere. > It may increase system response time a bit, but it is not significant > for laptop. Also we may avoid additional 128 interrupts per second per > core, by the cost of scheduling precision, with using i8254 timer also > for statistic collection purposes instead of RTC clock, by using another > newly added option: > hint.atrtc.0.clock=0 The real solution for C3 (and C4, etc.) is to implement tickless scheduling and to fix the current dependence on LAPIC for timer interrupts. Hopefully someone will do that soon. With that change, this change isn't needed. > 4. HDA modem > I was surprised, but integrated HDA modem consumed about 1W of power > even when not used. I have used the most radical solution - removed it > mechanically from socket. Case surface in that area become much cooler. Most modems support the ACPI Dx states, where D3 = device powered off. I'd think the PCI "power no driver option" would disable the soft modem since it's unlikely you have a driver for it. > 6. HDD > First common recommendation is use tmpfs for temporary files. RAM is > cheap, fast and anyway with you. > Also you may try to setup automatic idle drive spin-down, but if it is > the only system drive you should be careful, as every spin-up reduces > drive's life time. Did you increase the fsflush delay also? > So I have really doubled my on-battery time by this tuning - 4:47 hours > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows > XP on the same system, provides maximum 3:20 hours. Very nice. I think tickless scheduling is the single largest win for power mgmt we could get. Second best would be S4 (suspend to disk). -- Nate From mcdouga9 at egr.msu.edu Mon May 4 01:14:22 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Mon May 4 01:14:30 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <20090504011421.GI6901@egr.msu.edu> On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: I would like to summarize some of my knowledge on reducing FreeBSD power consumption and describe some new things I have recently implemented in 8-CURRENT. The main character of this story is my 12" Acer TravelMate 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under amd64 8-CURRENT. Great list! May I suggest screen brightness and DPMS as another tool to save power, I've measured a 5W difference from the screen draw. Keeping the brightness as low as tolerable helps considerably, but also using 'xset dpms 120 120 120' (modify to taste) in .xinitrc to turn off the screen after 2 minutes helps when the laptop isn't being used every second. May need this in xorg.conf: Option "dpms" From jamie at FreeBSD.org Mon May 4 02:50:37 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Mon May 4 02:51:00 2009 Subject: New jail framework - the userland side Message-ID: <49FE5387.3020503@FreeBSD.org> Hi all. I recently added some new jail-related system calls to extend the current jail system with an nmount-inspired name=value interface. This not only adds a new interface to the jail system, but allows for future extensions. For the first step, I've just added new system calls to set and read jail parameters. This is step 2: altering jail(8) and jls(8) to work with the new jails. With the included patch, the old "jail path hostname ip-number command..." command line turns to a more general "jail foo=bar baz=bletch ...". There's a set of core parameters to set the things jails can already do, plus the ability to set any parameters that other subsystems may want to tie to jails - work in progress includes the Linux MIB parameters, future ideas include separate namespaces for things like SYSV/Posix IPC. And of course, the plan is to use these new jails to tie in to the Vimage project. This patch is for the jail admin programs, and uses the current kernel as of r191673. You won't yet be able to do anything jails don't do already, but the interface is how I plan for things to look in the future. I'd appreciate comments from anyone who's interested in the future of lightweight virtualization. As a bonus, there are man pages included :-). - Jamie -------------- next part -------------- Index: usr.bin/killall/killall.1 =================================================================== --- usr.bin/killall/killall.1 (revision 191694) +++ usr.bin/killall/killall.1 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 9, 2007 +.Dd April 30, 2009 .Os .Dt KILLALL 1 .Sh NAME @@ -34,7 +34,7 @@ .Nm .Op Fl delmsvz .Op Fl help -.Op Fl j Ar jid +.Op Fl j Ar jail .Op Fl u Ar user .Op Fl t Ar tty .Op Fl c Ar procname @@ -91,9 +91,9 @@ (with or without a leading .Dq Li SIG ) , or numerically. -.It Fl j Ar jid -Kill processes in the jail specified by -.Ar jid . +.It Fl j Ar jail +Kill processes in the specified +.Ar jail . .It Fl u Ar user Limit potentially matching processes to those belonging to the specified Index: usr.bin/killall/killall.c =================================================================== --- usr.bin/killall/killall.c (revision 191694) +++ usr.bin/killall/killall.c (working copy) @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -51,7 +52,7 @@ usage(void) { - fprintf(stderr, "usage: killall [-delmsvz] [-help] [-j jid]\n"); + fprintf(stderr, "usage: killall [-delmsvz] [-help] [-j jail]\n"); fprintf(stderr, " [-u user] [-t tty] [-c cmd] [-SIGNAL] [cmd]...\n"); fprintf(stderr, "At least one option or argument to specify processes must be given.\n"); @@ -100,6 +101,7 @@ int main(int ac, char **av) { + struct iovec jparams[2]; struct kinfo_proc *procs = NULL, *newprocs; struct stat sb; struct passwd *pw; @@ -159,12 +161,21 @@ } jflag++; if (*av == NULL) - errx(1, "must specify jid"); - jid = strtol(*av, &ep, 10); - if (!*av || *ep) - errx(1, "illegal jid: %s", *av); + errx(1, "must specify jail"); + jid = strtoul(*av, &ep, 10); + if (!**av || *ep) { + *(const void **)&jparams[0].iov_base = + "name"; + jparams[0].iov_len = sizeof("name"); + jparams[1].iov_base = *av; + jparams[1].iov_len = strlen(*av) + 1; + jid = jail_get(jparams, 2, 0); + if (jid < 0) + errx(1, "unknown jail: %s", + *av); + } if (jail_attach(jid) == -1) - err(1, "jail_attach(): %d", jid); + err(1, "jail_attach(%d)", jid); break; case 'u': ++*av; Index: usr.sbin/jls/jls.c =================================================================== --- usr.sbin/jls/jls.c (revision 191694) +++ usr.sbin/jls/jls.c (working copy) @@ -1,6 +1,7 @@ /*- * Copyright (c) 2003 Mike Barcroft * Copyright (c) 2008 Bjoern A. Zeeb + * Copyright (c) 2009 James Gritton * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -23,18 +24,20 @@ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. - * - * $FreeBSD$ */ +#include +__FBSDID("$FreeBSD$"); + #include -#include #include +#include #include +#include -#include +#include #include -#include + #include #include #include @@ -43,215 +46,672 @@ #include #include -#define FLAG_A 0x00001 -#define FLAG_V 0x00002 +#define SJPARAM "security.jail.param" +#define ARRAY_SLOP 5 -#ifdef SUPPORT_OLD_XPRISON -static -char *print_xprison_v1(void *p, char *end, unsigned flags) +#define CTLTYPE_BOOL (CTLTYPE + 1) +#define CTLTYPE_NOBOOL (CTLTYPE + 2) +#define CTLTYPE_IPADDR (CTLTYPE + 3) +#define CTLTYPE_IP6ADDR (CTLTYPE + 4) + +#define PARAM_KEY 0x1 +#define PARAM_USER 0x2 +#define PARAM_ARRAY 0x4 +#define PARAM_OPT 0x8 + +#define PRINT_DEFAULT 0x01 +#define PRINT_VDEFAULT 0x02 +#define PRINT_HEADER 0x04 +#define PRINT_NAMEVAL 0x08 +#define PRINT_QUOTED 0x10 + +struct param { + char *name; + void *value; + size_t size; + int type; + unsigned flags; +}; + +struct iovec2 { + struct iovec name; + struct iovec value; +}; + +static struct param *params; +static int nparams; +static char errmsg[256]; + +static void add_param(const char *name, void *value, unsigned flags); +static int get_param(const char *name, struct param *param); +static int sort_param(const void *a, const void *b); +static char *noname(const char *name); +static char *nononame(const char *name); +static int print_jail(int pflags, int jflags); +static void quoted_print(char *str, int len); + +int +main(int argc, char **argv) { - struct xprison_v1 *xp; - struct in_addr in; + char *ep, *jname; + int c, i, jflags, jid, lastjid, pflags; - if ((char *)p + sizeof(struct xprison_v1) > end) - errx(1, "Invalid length for jail"); + jname = NULL; + pflags = jflags = jid = 0; + while ((c = getopt(argc, argv, "dj:hnqv")) >= 0) + switch (c) { + case 'd': + jflags |= JAIL_DYING; + break; + case 'j': + jid = strtoul(optarg, &ep, 10); + if (!*optarg || *ep) + jname = optarg; + break; + case 'h': + pflags |= PRINT_HEADER; + break; + case 'n': + pflags |= PRINT_NAMEVAL; + break; + case 'q': + pflags |= PRINT_QUOTED; + break; + case 'v': + pflags |= PRINT_VDEFAULT; + break; + default: + errx(1, "usage: jls [-dhnqv] [-j jail] [param ...]"); + } - xp = (struct xprison_v1 *)p; - if (flags & FLAG_V) { - printf("%6d %-29.29s %.74s\n", - xp->pr_id, xp->pr_host, xp->pr_path); - /* We are not printing an empty line here for state and name. */ - /* We are not printing an empty line here for cpusetid. */ - /* IPv4 address. */ - in.s_addr = htonl(xp->pr_ip); - printf("%6s %-15.15s\n", "", inet_ntoa(in)); + /* Add the parameters to print. */ + if (optind == argc) { + if (pflags & PRINT_VDEFAULT) { + add_param("jid", NULL, PARAM_USER); + add_param("host.hostname", NULL, PARAM_USER); + add_param("path", NULL, PARAM_USER); + add_param("name", NULL, PARAM_USER); + add_param("dying", NULL, PARAM_USER); + add_param("cpuset", NULL, PARAM_USER); + add_param("ip4.addr", NULL, PARAM_USER); + add_param("ip6.addr", NULL, PARAM_USER | PARAM_OPT); + } else { + pflags |= PRINT_DEFAULT; + add_param("jid", NULL, PARAM_USER); + add_param("ip4.addr", NULL, PARAM_USER); + add_param("host.hostname", NULL, PARAM_USER); + add_param("path", NULL, PARAM_USER); + } + } else + while (optind < argc) + add_param(argv[optind++], NULL, PARAM_USER); + + /* Add the index key and errmsg parameters. */ + if (jid != 0) + add_param("jid", &jid, PARAM_KEY); + else if (jname != NULL) + add_param("name", jname, PARAM_KEY); + else + add_param("lastjid", &lastjid, PARAM_KEY); + add_param("errmsg", errmsg, PARAM_KEY); + + /* Print a header line if requested. */ + if (pflags & PRINT_VDEFAULT) + printf(" JID Hostname Path\n" + " Name State\n" + " CPUSetID\n" + " IP Address(es)\n"); + else if (pflags & PRINT_DEFAULT) + printf(" JID IP Address " + "Hostname Path\n"); + else if (pflags & PRINT_HEADER) { + for (i = 0; i < nparams; i++) + if (params[i].flags & PARAM_USER) { + if (i > 0) + putchar(' '); + fputs(params[i].name, stdout); + } + putchar('\n'); + } + + /* Fetch the jail(s) and print the paramters. */ + if (jid != 0 || jname != NULL) { + if (print_jail(pflags, jflags) < 0) { + if (errmsg[0]) + errx(1, "%s", errmsg); + err(1, "jail_get"); + } } else { - printf("%6d %-15.15s %-29.29s %.74s\n", - xp->pr_id, inet_ntoa(in), xp->pr_host, xp->pr_path); + for (lastjid = 0; + (lastjid = print_jail(pflags, jflags)) >= 0; ) + ; + if (errno != 0 && errno != ENOENT) { + if (errmsg[0]) + errx(1, "%s", errmsg); + err(1, "jail_get"); + } } - return ((char *)(xp + 1)); + return (0); } -#endif -static -char *print_xprison_v3(void *p, char *end, unsigned flags) +static void +add_param(const char *name, void *value, unsigned flags) { - struct xprison *xp; - struct in_addr *iap, in; - struct in6_addr *ia6p; - char buf[INET6_ADDRSTRLEN]; - const char *state; - char *q; - uint32_t i; + struct param *param; + char *nname; + size_t mlen1, mlen2, buflen; + int mib1[CTL_MAXNAME], mib2[CTL_MAXNAME - 2]; + int i, tnparams; + char buf[MAXPATHLEN]; - if ((char *)p + sizeof(struct xprison) > end) - errx(1, "Invalid length for jail"); - xp = (struct xprison *)p; + static int paramlistsize; - if (xp->pr_state < 0 || xp->pr_state >= (int) - ((sizeof(prison_states) / sizeof(struct prison_state)))) - state = "(bogus)"; - else - state = prison_states[xp->pr_state].state_name; + /* The pseudo-parameter "all" scans the list of available parameters. */ + if (!strcmp(name, "all")) { + tnparams = nparams; + mib1[0] = 0; + mib1[1] = 2; + mlen1 = CTL_MAXNAME - 2; + if (sysctlnametomib(SJPARAM, mib1 + 2, &mlen1) < 0) + err(1, "sysctlnametomib(" SJPARAM ")"); + for (;;) { + /* Get the next parameter. */ + mlen2 = sizeof(mib2); + if (sysctl(mib1, mlen1 + 2, mib2, &mlen2, NULL, 0) < 0) + err(1, "sysctl(0.2)"); + if (mib2[0] != mib1[2] || mib2[1] != mib1[3] || + mib2[2] != mib1[4]) + break; + /* Convert it to an ascii name. */ + memcpy(mib1 + 2, mib2, mlen2); + mlen1 = mlen2 / sizeof(int); + mib1[1] = 1; + buflen = sizeof(buf); + if (sysctl(mib1, mlen1 + 2, buf, &buflen, NULL, 0) < 0) + err(1, "sysctl(0.1)"); + add_param(buf + sizeof(SJPARAM), NULL, flags); + /* + * Convert nobool parameters to bool if their + * counterpart is a node, ortherwise discard them. + */ + param = ¶ms[nparams - 1]; + if (param->type == CTLTYPE_NOBOOL) { + nname = nononame(param->name); + if (get_param(nname, param) >= 0 && + param->type != CTLTYPE_NODE) { + free(nname); + nparams--; + } else { + free(param->name); + param->name = nname; + param->type = CTLTYPE_BOOL; + param->size = sizeof(int); + param->value = NULL; + } + } + mib1[1] = 2; + } - /* See if we should print non-ACTIVE jails. No? */ - if ((flags & FLAG_A) == 0 && strcmp(state, "ALIVE")) { - q = (char *)(xp + 1); - q += (xp->pr_ip4s * sizeof(struct in_addr)); - if (q > end) - errx(1, "Invalid length for jail"); - q += (xp->pr_ip6s * sizeof(struct in6_addr)); - if (q > end) - errx(1, "Invalid length for jail"); - return (q); + qsort(params + tnparams, (size_t)(nparams - tnparams), + sizeof(struct param), sort_param); + return; } - if (flags & FLAG_V) - printf("%6d %-29.29s %.74s\n", - xp->pr_id, xp->pr_host, xp->pr_path); + /* Check for repeat parameters. */ + for (i = 0; i < nparams; i++) + if (!strcmp(name, params[i].name)) { + params[i].value = value; + params[i].flags |= flags; + return; + } - /* Jail state and name. */ - if (flags & FLAG_V) - printf("%6s %-29.29s %.74s\n", - "", (xp->pr_name[0] != '\0') ? xp->pr_name : "", state); + /* Make sure there is room for the new param record. */ + if (!nparams) { + paramlistsize = 32; + params = malloc(paramlistsize * sizeof(*params)); + if (params == NULL) + err(1, "malloc"); + } else if (nparams >= paramlistsize) { + paramlistsize *= 2; + params = realloc(params, paramlistsize * sizeof(*params)); + if (params == NULL) + err(1, "realloc"); + } - /* cpusetid. */ - if (flags & FLAG_V) - printf("%6s %-6d\n", - "", xp->pr_cpusetid); + /* Look up the parameter. */ + param = params + nparams++; + memset(param, 0, sizeof *param); + param->name = strdup(name); + if (param->name == NULL) + err(1, "strdup"); + param->flags = flags; + /* We have to know about pseudo-parameters without asking. */ + if (!strcmp(param->name, "lastjid")) { + param->type = CTLTYPE_INT; + param->size = sizeof(int); + goto got_type; + } + if (!strcmp(param->name, "errmsg")) { + param->type = CTLTYPE_STRING; + param->size = sizeof(errmsg); + goto got_type; + } + if (get_param(name, param) < 0) { + if (errno != ENOENT) + err(1, "sysctl(0.3.%s)", name); + /* See if this the "no" part of an existing boolean. */ + if ((nname = nononame(name))) { + i = get_param(nname, param); + free(nname); + if (i >= 0 && param->type == CTLTYPE_BOOL) { + param->type = CTLTYPE_NOBOOL; + goto got_type; + } + } + if (flags & PARAM_OPT) { + nparams--; + return; + } + errx(1, "unknown parameter: %s", name); + } + if (param->type == CTLTYPE_NODE) { + /* + * A node isn't normally a parameter, but may be a boolean + * if its "no" counterpart exists. + */ + nname = noname(name); + i = get_param(nname, param); + free(nname); + if (i >= 0 && param->type == CTLTYPE_NOBOOL) { + param->type = CTLTYPE_BOOL; + goto got_type; + } + errx(1, "unknown parameter: %s", name); + } - q = (char *)(xp + 1); - /* IPv4 addresses. */ - iap = (struct in_addr *)(void *)q; - q += (xp->pr_ip4s * sizeof(struct in_addr)); - if (q > end) - errx(1, "Invalid length for jail"); - in.s_addr = 0; - for (i = 0; i < xp->pr_ip4s; i++) { - if (i == 0 || flags & FLAG_V) - in.s_addr = iap[i].s_addr; - if (flags & FLAG_V) - printf("%6s %-15.15s\n", "", inet_ntoa(in)); + got_type: + param->value = value; +} + +static int +get_param(const char *name, struct param *param) +{ + char *bufi, *p; + size_t buflen, mlen; + int mib[CTL_MAXNAME]; + char buf[MAXPATHLEN]; + + /* Look up the MIB. */ + mib[0] = 0; + mib[1] = 3; + snprintf(buf, sizeof(buf), SJPARAM ".%s", name); + mlen = sizeof(mib) - 2 * sizeof(int); + if (sysctl(mib, 2, mib + 2, &mlen, buf, strlen(buf)) < 0) + return (-1); + /* Get the type and size. */ + mib[1] = 4; + buflen = sizeof(buf); + if (sysctl(mib, (mlen / sizeof(int)) + 2, buf, &buflen, NULL, 0) < 0) + err(1, "sysctl(0.4.%s)", name); + param->type = *(int *)buf & CTLTYPE; + bufi = buf + sizeof(int); + p = strchr(bufi, '\0'); + if (p - 2 >= bufi && !strcmp(p - 2, ",a")) { + p[-2] = 0; + param->flags |= PARAM_ARRAY; } - /* IPv6 addresses. */ - ia6p = (struct in6_addr *)(void *)q; - q += (xp->pr_ip6s * sizeof(struct in6_addr)); - if (q > end) - errx(1, "Invalid length for jail"); - for (i = 0; i < xp->pr_ip6s; i++) { - if (flags & FLAG_V) { - inet_ntop(AF_INET6, &ia6p[i], buf, sizeof(buf)); - printf("%6s %s\n", "", buf); + switch (param->type) { + case CTLTYPE_INT: + /* An integer parameter might be a boolean. */ + if (bufi[0] == 'B') + param->type = bufi[1] == 'N' + ? CTLTYPE_NOBOOL : CTLTYPE_BOOL; + case CTLTYPE_UINT: + param->size = sizeof(int); + break; + case CTLTYPE_LONG: + case CTLTYPE_ULONG: + param->size = sizeof(long); + break; + case CTLTYPE_STRUCT: + if (!strcmp(bufi, "S,in_addr")) { + param->type = CTLTYPE_IPADDR; + param->size = sizeof(struct in_addr); + } else if (!strcmp(bufi, "S,in6_addr")) { + param->type = CTLTYPE_IP6ADDR; + param->size = sizeof(struct in6_addr); } + break; + case CTLTYPE_STRING: + buf[0] = 0; + sysctl(mib + 2, mlen / sizeof(int), buf, &buflen, NULL, 0); + param->size = strtoul(buf, NULL, 10); + if (param->size == 0) + param->size = BUFSIZ; } + return (0); +} - /* If requested print the old style single line version. */ - if (!(flags & FLAG_V)) - printf("%6d %-15.15s %-29.29s %.74s\n", - xp->pr_id, (in.s_addr) ? inet_ntoa(in) : "", - xp->pr_host, xp->pr_path); +static int +sort_param(const void *a, const void *b) +{ + const struct param *parama, *paramb; + char *ap, *bp; - return (q); + /* Put top-level parameters first. */ + parama = a; + paramb = b; + ap = strchr(parama->name, '.'); + bp = strchr(paramb->name, '.'); + if (ap && !bp) + return (1); + if (bp && !ap) + return (-1); + return (strcmp(parama->name, paramb->name)); } -static void -usage(void) +static char * +noname(const char *name) { + char *nname, *p; - (void)fprintf(stderr, "usage: jls [-av]\n"); - exit(1); + nname = malloc(strlen(name) + 3); + if (nname == NULL) + err(1, "malloc"); + p = strrchr(name, '.'); + if (p != NULL) + sprintf(nname, "%.*s.no%s", p - name, name, p + 1); + else + sprintf(nname, "no%s", name); + return nname; } -int -main(int argc, char *argv[]) -{ - int ch, version; - unsigned flags; - size_t i, j, len; - void *p, *q; +static char * +nononame(const char *name) +{ + char *nname, *p; - flags = 0; - while ((ch = getopt(argc, argv, "av")) != -1) { - switch (ch) { - case 'a': - flags |= FLAG_A; - break; - case 'v': - flags |= FLAG_V; - break; - default: - usage(); - } - } - argc -= optind; - argv += optind; + p = strrchr(name, '.'); + if (strncmp(p ? p + 1 : name, "no", 2)) + return NULL; + nname = malloc(strlen(name) - 1); + if (nname == NULL) + err(1, "malloc"); + if (p != NULL) + sprintf(nname, "%.*s.%s", p - name, name, p + 3); + else + strcpy(nname, name + 2); + return nname; +} - if (sysctlbyname("security.jail.list", NULL, &len, NULL, 0) == -1) - err(1, "sysctlbyname(): security.jail.list"); +static int +print_jail(int pflags, int jflags) +{ + char *nname; + int i, ai, jid, count, sanity; + char ipbuf[INET6_ADDRSTRLEN]; - j = len; - for (i = 0; i < 4; i++) { - if (len <= 0) - exit(0); - p = q = malloc(len); - if (p == NULL) - err(1, "malloc()"); + static struct iovec2 *iov, *aiov; + static int narray, nkey; - if (sysctlbyname("security.jail.list", q, &len, NULL, 0) == -1) { - if (errno == ENOMEM) { - free(p); - p = NULL; - len += j; + /* Set up the parameter list(s) the first time around. */ + if (iov == NULL) { + iov = malloc(nparams * sizeof(struct iovec2)); + if (iov == NULL) + err(1, "malloc"); + for (i = narray = 0; i < nparams; i++) { + iov[i].name.iov_base = params[i].name; + iov[i].name.iov_len = strlen(params[i].name) + 1; + iov[i].value.iov_base = params[i].value; + iov[i].value.iov_len = + params[i].type == CTLTYPE_STRING && + params[i].value != NULL && + ((char *)params[i].value)[0] != '\0' + ? strlen(params[i].value) + 1 : params[i].size; + if (params[i].flags & (PARAM_KEY | PARAM_ARRAY)) { + narray++; + if (params[i].flags & PARAM_KEY) + nkey++; + } + } + if (narray > nkey) { + aiov = malloc(narray * sizeof(struct iovec2)); + if (aiov == NULL) + err(1, "malloc"); + for (i = ai = 0; i < nparams; i++) + if (params[i].flags & + (PARAM_KEY | PARAM_ARRAY)) + aiov[ai++] = iov[i]; + } + } + /* If there are array parameters, find their sizes. */ + if (aiov != NULL) { + for (ai = 0; ai < narray; ai++) + if (aiov[ai].value.iov_base == NULL) + aiov[ai].value.iov_len = 0; + if (jail_get((struct iovec *)aiov, 2 * narray, jflags) < 0) + return (-1); + } + /* Allocate storage for all parameters. */ + for (i = ai = 0; i < nparams; i++) { + if (params[i].flags & (PARAM_KEY | PARAM_ARRAY)) { + if (params[i].flags & PARAM_ARRAY) { + iov[i].value.iov_len = aiov[ai].value.iov_len + + ARRAY_SLOP * params[i].size; + iov[i].value.iov_base = + malloc(iov[i].value.iov_len); + } + ai++; + } else + iov[i].value.iov_base = malloc(params[i].size); + if (iov[i].value.iov_base == NULL) + err(1, "malloc"); + if (params[i].value == NULL) + memset(iov[i].value.iov_base, 0, iov[i].value.iov_len); + } + /* + * Get the actual prison. If there are array elements, retry a few + * times in case the size changed from under us. + */ + if ((jid = jail_get((struct iovec *)iov, 2 * nparams, jflags)) < 0) { + if (errno != EINVAL || aiov == NULL || errmsg[0]) + return (-1); + for (sanity = 0;; sanity++) { + if (sanity == 10) + return (-1); + for (ai = 0; ai < narray; ai++) + if (params[i].flags & PARAM_ARRAY) + aiov[ai].value.iov_len = 0; + if (jail_get((struct iovec *)iov, 2 * narray, jflags) < + 0) + return (-1); + for (i = ai = 0; i < nparams; i++) { + if (!(params[i].flags & + (PARAM_KEY | PARAM_ARRAY))) + continue; + if (params[i].flags & PARAM_ARRAY) { + iov[i].value.iov_len = + aiov[ai].value.iov_len + + ARRAY_SLOP * params[i].size; + iov[i].value.iov_base = + realloc(iov[i].value.iov_base, + iov[i].value.iov_len); + if (iov[i].value.iov_base == NULL) + err(1, "malloc"); + } + ai++; + } + } + } + if (pflags & PRINT_VDEFAULT) { + printf("%6d %-29.29s %.74s\n" + "%6s %-29.29s %.74s\n" + "%6s %-6d\n", + *(int *)iov[0].value.iov_base, + (char *)iov[1].value.iov_base, + (char *)iov[2].value.iov_base, + "", + (char *)iov[3].value.iov_base, + *(int *)iov[4].value.iov_base ? "DYING" : "ACTIVE", + "", + *(int *)iov[5].value.iov_base); + count = iov[6].value.iov_len / sizeof(struct in_addr); + for (ai = 0; ai < count; ai++) + if (inet_ntop(AF_INET, + &((struct in_addr *)iov[6].value.iov_base)[ai], + ipbuf, sizeof(ipbuf)) == NULL) + err(1, "inet_ntop"); + else + printf("%6s %-15.15s\n", "", ipbuf); + if (!strcmp(params[7].name, "ip6.addr")) { + count = iov[7].value.iov_len / sizeof(struct in6_addr); + for (ai = 0; ai < count; ai++) + if (inet_ntop(AF_INET6, &((struct in_addr *) + iov[7].value.iov_base)[ai], + ipbuf, sizeof(ipbuf)) == NULL) + err(1, "inet_ntop"); + else + printf("%6s %-15.15s\n", "", ipbuf); + } + } else if (pflags & PRINT_DEFAULT) + printf("%6d %-15.15s %-29.29s %.74s\n", + *(int *)iov[0].value.iov_base, + iov[1].value.iov_len == 0 ? "-" + : inet_ntoa(*(struct in_addr *)iov[1].value.iov_base), + (char *)iov[2].value.iov_base, + (char *)iov[3].value.iov_base); + else { + for (i = 0; i < nparams; i++) { + if (!(params[i].flags & PARAM_USER)) continue; + if (i > 0) + putchar(' '); + if (pflags & PRINT_NAMEVAL) { + /* + * Generally "name=value", but for booleans + * either "name" or "noname". + */ + switch (params[i].type) { + case CTLTYPE_BOOL: + if (*(int *)iov[i].value.iov_base) + printf("%s", params[i].name); + else { + nname = noname(params[i].name); + printf("%s", nname); + free(nname); + } + break; + case CTLTYPE_NOBOOL: + if (*(int *)iov[i].value.iov_base) + printf("%s", params[i].name); + else { + nname = + nononame(params[i].name); + printf("%s", nname); + free(nname); + } + break; + default: + printf("%s=", params[i].name); + } } - err(1, "sysctlbyname(): security.jail.list"); + count = params[i].flags & PARAM_ARRAY + ? iov[i].value.iov_len / params[i].size : 1; + if (count == 0) + putchar('-'); + for (ai = 0; ai < count; ai++) { + if (ai > 0) + putchar(','); + switch (params[i].type) { + case CTLTYPE_INT: + printf("%d", ((int *) + iov[i].value.iov_base)[ai]); + break; + case CTLTYPE_UINT: + printf("%u", ((int *) + iov[i].value.iov_base)[ai]); + break; + case CTLTYPE_IPADDR: + if (inet_ntop(AF_INET, + &((struct in_addr *) + iov[i].value.iov_base)[ai], + ipbuf, sizeof(ipbuf)) == NULL) + err(1, "inet_ntop"); + else + printf("%s", ipbuf); + break; + case CTLTYPE_IP6ADDR: + if (inet_ntop(AF_INET6, + &((struct in6_addr *) + iov[i].value.iov_base)[ai], + ipbuf, sizeof(ipbuf)) == NULL) + err(1, "inet_ntop"); + else + printf("%s", ipbuf); + break; + case CTLTYPE_LONG: + printf("%ld", ((long *) + iov[i].value.iov_base)[ai]); + case CTLTYPE_ULONG: + printf("%lu", ((long *) + iov[i].value.iov_base)[ai]); + break; + case CTLTYPE_STRING: + if (pflags & PRINT_QUOTED) + quoted_print((char *) + iov[i].value.iov_base, + params[i].size); + else + printf("%.*s", + params[i].size, (char *) + iov[i].value.iov_base); + break; + case CTLTYPE_BOOL: + case CTLTYPE_NOBOOL: + if (!(pflags & PRINT_NAMEVAL)) + printf(((int *) + iov[i].value.iov_base)[ai] + ? "true" : "false"); + } + } } - break; + putchar('\n'); } - if (p == NULL) - err(1, "sysctlbyname(): security.jail.list"); - if (len < sizeof(int)) - errx(1, "This is no prison. Kernel and userland out of sync?"); - version = *(int *)p; - if (version > XPRISON_VERSION) - errx(1, "Sci-Fi prison. Kernel/userland out of sync?"); + for (i = 0; i < nparams; i++) + if (params[i].value == NULL) + free(iov[i].value.iov_base); + return (jid); +} - if (flags & FLAG_V) { - printf(" JID Hostname Path\n"); - printf(" Name State\n"); - printf(" CPUSetID\n"); - printf(" IP Address(es)\n"); - } else { - printf(" JID IP Address Hostname" - " Path\n"); +static void +quoted_print(char *str, int len) +{ + int c, qc; + char *p = str; + char *ep = str + len; + + /* An empty string needs quoting. */ + if (!*p) { + fputs("\"\"", stdout); + return; } - for (; q != NULL && (char *)q + sizeof(int) < (char *)p + len;) { - version = *(int *)q; - if (version > XPRISON_VERSION) - errx(1, "Sci-Fi prison. Kernel/userland out of sync?"); - switch (version) { -#ifdef SUPPORT_OLD_XPRISON - case 1: - q = print_xprison_v1(q, (char *)p + len, flags); - break; - case 2: - errx(1, "Version 2 was used by multi-IPv4 jail " - "implementations that never made it into the " - "official kernel."); - /* NOTREACHED */ - break; -#endif - case 3: - q = print_xprison_v3(q, (char *)p + len, flags); - break; - default: - errx(1, "Prison unknown. Kernel/userland out of sync?"); - /* NOTREACHED */ - break; - } + + /* + * The value will be surrounded by quotes if it contains spaces + * or quotes. + */ + qc = strchr(p, '\'') ? '"' + : strchr(p, '"') ? '\'' + : strchr(p, ' ') || strchr(p, '\t') ? '"' + : 0; + if (qc) + putchar(qc); + while (p < ep && (c = *p++)) { + if (c == '\\' || c == qc) + putchar('\\'); + putchar(c); } - - free(p); - exit(0); + if (qc) + putchar(qc); } Index: usr.sbin/jls/Makefile =================================================================== --- usr.sbin/jls/Makefile (revision 191694) +++ usr.sbin/jls/Makefile (working copy) @@ -4,6 +4,4 @@ MAN= jls.8 WARNS?= 6 -CFLAGS+= -DSUPPORT_OLD_XPRISON - .include Index: usr.sbin/jls/jls.8 =================================================================== --- usr.sbin/jls/jls.8 (revision 191694) +++ usr.sbin/jls/jls.8 (working copy) @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 29, 2008 +.Dd April 30, 2009 .Dt JLS 8 .Os .Sh NAME @@ -33,38 +33,59 @@ .Nd "list jails" .Sh SYNOPSIS .Nm -.Op Fl av +.Op Fl dhnqv +.Op Fl j Ar jail +.Op Ar parameter ... .Sh DESCRIPTION The .Nm -utility lists all jails. -By default only active jails are listed. +utility lists all active jails, or the specified jail. +Each jail is represented by one row which contains space-separated values of +the listed +.Ar parameters , +including the pseudo-parameter +.Va all +which will show all available jail parameters. +A list of available parameters can be retrieved via +.Dq Nm sysctl Fl d Va security.jail.param . .Pp -The options are as follows: -.Bl -tag -width ".Fl a" -.It Fl a -Show jails in all states, not only active ones. +If no +.Ar parameters +are given, the following four columns will be printed: +jail identifier (jid), IP address (ip4.addr), hostname (host.hostname), +and path (path). +.Pp +The following options are available: +.Bl -tag -width indent +.It Fl d +List +.Va dying +as well as active jails. +.It Fl h +Print a header line containing the parameters listed. +If no parameters are given on the command line, the default four-column +output always contains a header. +.It Fl n +Print parameters in +.Dq name=value +format, where each parameter is preceded by its name. +This option is ignored for the default four-column output. +.It Fl q +Put quotes around string parameters if they contain spaces or quotes, or are +the empty string. .It Fl v -Show more verbose information. -This also lists cpusets, jail state, multi-IP, etc. instead of the -classic single-IP jail output. +Print a multiple-line summary per jail, with the following parameters: +jail identifier (jid), hostname (host.hostname), path (path), +jail name (name), jail state (dying), cpuset ID (cpuset), +IP address(es) (ip4.addr and ip6.addr). +.It Fl j Ar jail +The jid or name of the +.Ar jail +to list. +Without this option, all active jails will be listed. .El -.Pp -Each jail is represented by rows which, depending on -.Fl v , -contain the following columns: -.Bl -item -offset indent -compact -.It -jail identifier (JID), hostname and path -.It -jail state and name -.It -jail cpuset -.It -followed by one IP adddress per line. -.El .Sh SEE ALSO -.Xr jail 2 , +.Xr jail_get 2 , .Xr jail 8 , .Xr jexec 8 .Sh HISTORY @@ -72,3 +93,5 @@ .Nm utility was added in .Fx 5.1 . +Extensible jail parameters were introduced in +.Fx 8.0 . Index: usr.sbin/jexec/jexec.c =================================================================== --- usr.sbin/jexec/jexec.c (revision 191694) +++ usr.sbin/jexec/jexec.c (working copy) @@ -29,12 +29,16 @@ #include #include +#include #include +#include +#include #include #include #include +#include #include #include #include @@ -43,154 +47,8 @@ #include static void usage(void); +static int addr2jid(const char *addr); -#ifdef SUPPORT_OLD_XPRISON -static -char *lookup_xprison_v1(void *p, char *end, int *id) -{ - struct xprison_v1 *xp; - - if (id == NULL) - errx(1, "Internal error. Invalid ID pointer."); - - if ((char *)p + sizeof(struct xprison_v1) > end) - errx(1, "Invalid length for jail"); - - xp = (struct xprison_v1 *)p; - - *id = xp->pr_id; - return ((char *)(xp + 1)); -} -#endif - -static -char *lookup_xprison_v3(void *p, char *end, int *id, char *jailname) -{ - struct xprison *xp; - char *q; - int ok; - - if (id == NULL) - errx(1, "Internal error. Invalid ID pointer."); - - if ((char *)p + sizeof(struct xprison) > end) - errx(1, "Invalid length for jail"); - - xp = (struct xprison *)p; - ok = 1; - - /* Jail state and name. */ - if (xp->pr_state < 0 || xp->pr_state >= - (int)((sizeof(prison_states) / sizeof(struct prison_state)))) - errx(1, "Invalid jail state."); - else if (xp->pr_state != PRISON_STATE_ALIVE) - ok = 0; - if (jailname != NULL) { - if (xp->pr_name[0] == '\0') - ok = 0; - else if (strcmp(jailname, xp->pr_name) != 0) - ok = 0; - } - - q = (char *)(xp + 1); - /* IPv4 addresses. */ - q += (xp->pr_ip4s * sizeof(struct in_addr)); - if ((char *)q > end) - errx(1, "Invalid length for jail"); - /* IPv6 addresses. */ - q += (xp->pr_ip6s * sizeof(struct in6_addr)); - if ((char *)q > end) - errx(1, "Invalid length for jail"); - - if (ok) - *id = xp->pr_id; - return (q); -} - -static int -lookup_jail(int jid, char *jailname) -{ - size_t i, j, len; - void *p, *q; - int version, id, xid, count; - - if (sysctlbyname("security.jail.list", NULL, &len, NULL, 0) == -1) - err(1, "sysctlbyname(): security.jail.list"); - - j = len; - for (i = 0; i < 4; i++) { - if (len == 0) - return (-1); - p = q = malloc(len); - if (p == NULL) - err(1, "malloc()"); - - if (sysctlbyname("security.jail.list", q, &len, NULL, 0) == -1) { - if (errno == ENOMEM) { - free(p); - p = NULL; - len += j; - continue; - } - err(1, "sysctlbyname(): security.jail.list"); - } - break; - } - if (p == NULL) - err(1, "sysctlbyname(): security.jail.list"); - if (len < sizeof(int)) - errx(1, "This is no prison. Kernel and userland out of sync?"); - version = *(int *)p; - if (version > XPRISON_VERSION) - errx(1, "Sci-Fi prison. Kernel/userland out of sync?"); - - count = 0; - xid = -1; - for (; q != NULL && (char *)q + sizeof(int) < (char *)p + len;) { - version = *(int *)q; - if (version > XPRISON_VERSION) - errx(1, "Sci-Fi prison. Kernel/userland out of sync?"); - id = -1; - switch (version) { -#ifdef SUPPORT_OLD_XPRISON - case 1: - if (jailname != NULL) - errx(1, "Version 1 prisons did not " - "support jail names."); - q = lookup_xprison_v1(q, (char *)p + len, &id); - break; - case 2: - errx(1, "Version 2 was used by multi-IPv4 jail " - "implementations that never made it into the " - "official kernel."); - /* NOTREACHED */ - break; -#endif - case 3: - q = lookup_xprison_v3(q, (char *)p + len, &id, jailname); - break; - default: - errx(1, "Prison unknown. Kernel/userland out of sync?"); - /* NOTREACHED */ - break; - } - /* Possible match; see if we have a jail ID to match as well. */ - if (id > 0 && (jid <= 0 || id == jid)) { - xid = id; - count++; - } - } - - free(p); - - if (count == 1) - return (xid); - else if (count > 1) - errx(1, "Could not uniquely identify the jail."); - else - return (-1); -} - #define GET_USER_INFO do { \ pwd = getpwnam(username); \ if (pwd == NULL) { \ @@ -210,22 +68,18 @@ int main(int argc, char *argv[]) { + struct iovec params[2]; int jid; login_cap_t *lcap = NULL; struct passwd *pwd = NULL; gid_t groups[NGROUPS]; - int ch, ngroups, uflag, Uflag; - char *jailname, *username; + int ch, ngroups, uflag, Uflag, hflag; + char *ep, *username; + ch = uflag = Uflag = hflag = 0; + username = NULL; - ch = uflag = Uflag = 0; - jailname = username = NULL; - jid = -1; - - while ((ch = getopt(argc, argv, "i:n:u:U:")) != -1) { + while ((ch = getopt(argc, argv, "u:U:h")) != -1) { switch (ch) { - case 'n': - jailname = optarg; - break; case 'u': username = optarg; uflag = 1; @@ -234,6 +88,9 @@ username = optarg; Uflag = 1; break; + case 'h': + hflag = 1; + break; default: usage(); } @@ -242,22 +99,24 @@ argv += optind; if (argc < 2) usage(); - if (strlen(argv[0]) > 0) { - jid = (int)strtol(argv[0], NULL, 10); - if (errno) - err(1, "Unable to parse jail ID."); - } - if (jid <= 0 && jailname == NULL) { - fprintf(stderr, "Neither jail ID nor jail name given.\n"); - usage(); - } if (uflag && Uflag) usage(); if (uflag) GET_USER_INFO; - jid = lookup_jail(jid, jailname); - if (jid <= 0) - errx(1, "Cannot identify jail."); + if (hflag) + jid = addr2jid(argv[0]); + else { + jid = strtoul(argv[0], &ep, 10); + if (!*argv[0] || *ep) { + *(const void **)¶ms[0].iov_base = "name"; + params[0].iov_len = sizeof("name"); + params[1].iov_base = argv[0]; + params[1].iov_len = strlen(argv[0]) + 1; + jid = jail_get(params, 2, 0); + if (jid < 0) + errx(1, "Unknown jail: %s", argv[0]); + } + } if (jail_attach(jid) == -1) err(1, "jail_attach(): %d", jid); if (chdir("/") == -1) @@ -285,6 +144,108 @@ fprintf(stderr, "%s%s\n", "usage: jexec [-u username | -U username]", - " [-n jailname] jid command ..."); + " [-h hostname | -h ip-number | jail] command ..."); exit(1); } + +static int +addr2jid(const char *addr) +{ + struct iovec params[6]; + struct in_addr ia; + struct in6_addr ia6; + int cnt, doip, foundjid, ii, jid, lastjid, sanity; + char hostbuf[MAXHOSTNAMELEN]; + + if (inet_pton(AF_INET, addr, &ia) > 0) + doip = 4; + else if (inet_pton(AF_INET6, addr, &ia6) > 0) + doip = 6; + else + doip = 0; + + *(const void **)¶ms[0].iov_base = "lastjid"; + params[0].iov_len = sizeof("lastjid"); + params[1].iov_base = &lastjid; + params[1].iov_len = sizeof(lastjid); + switch (doip) { + case 4: + *(const void **)¶ms[2].iov_base = "ip4.addr"; + params[2].iov_len = sizeof("ip4.addr"); + *(const void **)¶ms[4].iov_base = "host.hostname"; + params[4].iov_len = sizeof("host.hostname"); + params[5].iov_base = hostbuf; + params[5].iov_len = MAXHOSTNAMELEN; + break; + case 6: + *(const void **)¶ms[2].iov_base = "ip6.addr"; + params[2].iov_len = sizeof("ip6.addr"); + *(const void **)¶ms[4].iov_base = "host.hostname"; + params[4].iov_len = sizeof("host.hostname"); + params[5].iov_base = hostbuf; + params[5].iov_len = MAXHOSTNAMELEN; + break; + default: + *(const void **)¶ms[2].iov_base = "host.hostname"; + params[2].iov_len = sizeof("host.hostname"); + params[3].iov_base = hostbuf; + params[3].iov_len = MAXHOSTNAMELEN; + } + + cnt = foundjid = sanity = 0; + for (jid = 0;; jid = lastjid) { + if (doip != 0) { + params[3].iov_base = NULL; + params[3].iov_len = 0; + if (jail_get(params, 4, 0) < 0) + break; + params[3].iov_len += 5 * sizeof(struct in6_addr); + params[3].iov_base = malloc(params[3].iov_len); + jid = jail_get(params, 6, 0); + } else + jid = jail_get(params, 4, 0); + if (jid > 0) { + sanity = 0; + if (!strcmp(hostbuf, addr)) { + cnt++; + foundjid = jid; + } else switch (doip) { + case 4: + for (ii = (params[3].iov_len / + sizeof(struct in_addr)) - 1; ii >= 0; ii--) + if (((struct in_addr *)params[3]. + iov_base)[ii].s_addr == ia.s_addr) { + cnt++; + foundjid = jid; + break; + } + break; + case 6: + for (ii = (params[3].iov_len / + sizeof(struct in6_addr)) - 1; ii >= 0; + ii--) + if (IN6_ARE_ADDR_EQUAL(&ia6, + &((struct in6_addr *) + params[3].iov_base)[ii])) { + cnt++; + foundjid = jid; + break; + } + } + } else if (errno == ENOENT || ++sanity > 10) + break; + else + jid = lastjid; + if (doip != 0) + free(params[3].iov_base); + } + switch (cnt) + { + case 0: + errx(1, "Unknown jail: %s", addr); + case 1: + return foundjid; + default: + errx(1, "Could not uniquely identify the jail: %s", addr); + } +} Index: usr.sbin/jexec/jexec.8 =================================================================== --- usr.sbin/jexec/jexec.8 (revision 191694) +++ usr.sbin/jexec/jexec.8 (working copy) @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 29, 2008 +.Dd April 30, 2009 .Dt JEXEC 8 .Os .Sh NAME @@ -34,36 +34,22 @@ .Sh SYNOPSIS .Nm .Op Fl u Ar username | Fl U Ar username -.Op Fl n Ar jailname -.Ar jid command ... +.Op Fl h Ar hostname | Fl h Ar ip | Ar jid | Ar name +.Ar command ... .Sh DESCRIPTION The .Nm utility executes .Ar command -inside the jail identified by either -.Ar jailname +inside the jail identified by +.Ar hostname , +.Ar ip , +.Ar jid , or -.Ar jid -or both. +.Ar name . .Pp -If the jail cannot be identified uniquely by the given parameters, -an error message is printed. -.Nm -will also check the state of the jail (once supported) to be -.Dv ALIVE -and ignore jails in other states. -The mandatory argument -.Ar jid -is the unique jail identifier as given by -.Xr jls 8 . -In case you only want to match on other criteria, give an empty string. -.Pp The following options are available: .Bl -tag -width indent -.It Fl n Ar jailname -The name of the jail, if given upon creation of the jail. -This is not the hostname of the jail. .It Fl u Ar username The user name from host environment as whom the .Ar command @@ -73,6 +59,9 @@ .Ar command should run. .El +.Sh "CAUTIONS" +Only a jail's jid or name is guaranteed to uniquely identify the jail. +Hostname or ip only work here if matched to one unique jail. .Sh SEE ALSO .Xr jail_attach 2 , .Xr jail 8 , Index: usr.sbin/jexec/Makefile =================================================================== --- usr.sbin/jexec/Makefile (revision 191694) +++ usr.sbin/jexec/Makefile (working copy) @@ -6,6 +6,4 @@ LDADD= -lutil WARNS?= 6 -CFLAGS+= -DSUPPORT_OLD_XPRISON - .include Index: usr.sbin/jail/jail.c =================================================================== --- usr.sbin/jail/jail.c (revision 191694) +++ usr.sbin/jail/jail.c (working copy) @@ -1,5 +1,6 @@ /*- * Copyright (c) 1999 Poul-Henning Kamp. + * Copyright (c) 2009 James Gritton * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -29,51 +30,43 @@ #include #include -#include #include #include -#include +#include +#include #include -#include -#include +#include #include #include #include #include +#include #include #include #include #include -#include #include #include -static void usage(void); -static int add_addresses(struct addrinfo *); -static struct in_addr *copy_addr4(void); -#ifdef INET6 -static struct in6_addr *copy_addr6(void); -#endif +#define SJPARAM "security.jail.param" +#define ERRMSG_SIZE 256 -extern char **environ; - -struct addr4entry { - STAILQ_ENTRY(addr4entry) addr4entries; - struct in_addr ip4; - int count; +struct param { + struct iovec name; + struct iovec value; }; -struct addr6entry { - STAILQ_ENTRY(addr6entry) addr6entries; -#ifdef INET6 - struct in6_addr ip6; -#endif - int count; -}; -STAILQ_HEAD(addr4head, addr4entry) addr4 = STAILQ_HEAD_INITIALIZER(addr4); -STAILQ_HEAD(addr6head, addr6entry) addr6 = STAILQ_HEAD_INITIALIZER(addr6); +static struct param *params; +static int nparams; + +static void set_param(const char *name, char *value); +static void set_param_ip_hostname(char *value, int family); +static void usage(void); + +extern char **environ; + #define GET_USER_INFO do { \ pwd = getpwnam(username); \ if (pwd == NULL) { \ @@ -94,27 +87,28 @@ main(int argc, char **argv) { login_cap_t *lcap = NULL; - struct jail j; + struct iovec rparams[2]; struct passwd *pwd = NULL; gid_t groups[NGROUPS]; - int ch, error, i, ngroups, securelevel; - int hflag, iflag, Jflag, lflag, uflag, Uflag; - char path[PATH_MAX], *jailname, *ep, *username, *JidFile, *ip; + int ch, cmdarg, i, jail_set_flags, jid, ngroups, oldargs, securelevel; + int iflag, Jflag, lflag, rflag, uflag, Uflag; + char *ep, *username, *JidFile; + char errmsg[ERRMSG_SIZE]; static char *cleanenv; const char *shell, *p = NULL; long ltmp; FILE *fp; - struct addrinfo hints, *res0; - hflag = iflag = Jflag = lflag = uflag = Uflag = 0; - securelevel = -1; - jailname = username = JidFile = cleanenv = NULL; + iflag = Jflag = lflag = rflag = uflag = Uflag = 0; + jail_set_flags = JAIL_CREATE | JAIL_UPDATE; + cmdarg = jid = securelevel = -1; + username = JidFile = cleanenv = NULL; fp = NULL; - while ((ch = getopt(argc, argv, "hiln:s:u:U:J:")) != -1) { + while ((ch = getopt(argc, argv, "cdilor:s:u:U:J:")) != -1) { switch (ch) { - case 'h': - hflag = 1; + case 'd': + jail_set_flags |= JAIL_DYING; break; case 'i': iflag = 1; @@ -123,9 +117,6 @@ JidFile = optarg; Jflag = 1; break; - case 'n': - jailname = optarg; - break; case 's': ltmp = strtol(optarg, &ep, 0); if (*ep || ep == optarg || ltmp > INT_MAX || !ltmp) @@ -143,13 +134,41 @@ case 'l': lflag = 1; break; + case 'c': + jail_set_flags = + (jail_set_flags & ~JAIL_UPDATE) | JAIL_CREATE; + break; + case 'o': + jail_set_flags = + (jail_set_flags & ~JAIL_CREATE) | JAIL_UPDATE; + break; + case 'r': + jid = strtoul(optarg, &ep, 10); + if (!*optarg || *ep) { + *(const void **)&rparams[0].iov_base = "name"; + rparams[0].iov_len = sizeof("name"); + rparams[1].iov_base = optarg; + rparams[1].iov_len = strlen(optarg) + 1; + jid = jail_get(rparams, 2, 0); + if (jid < 0) + errx(1, "unknown jail: %s", optarg); + } + rflag = 1; + break; default: usage(); } } argc -= optind; argv += optind; - if (argc < 4) + if (rflag) { + if (argc > 0 || iflag || Jflag || lflag || uflag || Uflag) + usage(); + if (jail_remove(jid) < 0) + err(1, "jail_remove"); + exit (0); + } + if (argc == 0) usage(); if (uflag && Uflag) usage(); @@ -157,92 +176,70 @@ usage(); if (uflag) GET_USER_INFO; - if (realpath(argv[0], path) == NULL) - err(1, "realpath: %s", argv[0]); - if (chdir(path) != 0) - err(1, "chdir: %s", path); - /* Initialize struct jail. */ - memset(&j, 0, sizeof(j)); - j.version = JAIL_API_VERSION; - j.path = path; - j.hostname = argv[1]; - if (jailname != NULL) - j.jailname = jailname; - /* Handle IP addresses. If requested resolve hostname too. */ - bzero(&hints, sizeof(struct addrinfo)); - hints.ai_protocol = IPPROTO_TCP; - hints.ai_socktype = SOCK_STREAM; - if (JAIL_API_VERSION < 2) - hints.ai_family = PF_INET; - else - hints.ai_family = PF_UNSPEC; - /* Handle hostname. */ - if (hflag != 0) { - error = getaddrinfo(j.hostname, NULL, &hints, &res0); - if (error != 0) - errx(1, "failed to handle hostname: %s", - gai_strerror(error)); - error = add_addresses(res0); - freeaddrinfo(res0); - if (error != 0) - errx(1, "failed to add addresses."); + /* + * If the first argument (path) starts with a slash, and the third + * argument (IP address) starts with a digit, it is likely to be + * an old-style fixed-parameter command line. + */ + oldargs = argc >= 4 && argv[0][0] == '/' && isdigit(argv[2][0]); + if (oldargs) { + if ((jail_set_flags & (JAIL_CREATE | JAIL_UPDATE)) != + (JAIL_CREATE | JAIL_UPDATE)) + usage(); + jail_set_flags = JAIL_CREATE | JAIL_ATTACH; + set_param("path", argv[0]); + set_param("host.hostname", argv[1]); + set_param("ip4.addr", argv[2]); + cmdarg = 3; + } else { + for (i = 0; i < argc; i++) + if (!strncmp(argv[i], "command=", 8)) { + cmdarg = i; + argv[cmdarg] += 8; + jail_set_flags |= JAIL_ATTACH; + break; + } else + set_param(NULL, argv[i]); } - /* Handle IP addresses. */ - hints.ai_flags = AI_NUMERICHOST; - ip = strtok(argv[2], ","); - while (ip != NULL) { - error = getaddrinfo(ip, NULL, &hints, &res0); - if (error != 0) - errx(1, "failed to handle ip: %s", gai_strerror(error)); - error = add_addresses(res0); - freeaddrinfo(res0); - if (error != 0) - errx(1, "failed to add addresses."); - ip = strtok(NULL, ","); - } - /* Count IP addresses and add them to struct jail. */ - if (!STAILQ_EMPTY(&addr4)) { - j.ip4s = STAILQ_FIRST(&addr4)->count; - j.ip4 = copy_addr4(); - if (j.ip4s > 0 && j.ip4 == NULL) - errx(1, "copy_addr4()"); - } -#ifdef INET6 - if (!STAILQ_EMPTY(&addr6)) { - j.ip6s = STAILQ_FIRST(&addr6)->count; - j.ip6 = copy_addr6(); - if (j.ip6s > 0 && j.ip6 == NULL) - errx(1, "copy_addr6()"); - } -#endif + errmsg[0] = 0; + set_param("errmsg", errmsg); if (Jflag) { fp = fopen(JidFile, "w"); if (fp == NULL) errx(1, "Could not create JidFile: %s", JidFile); } - i = jail(&j); - if (i == -1) - err(1, "syscall failed with"); + jid = jail_set(¶ms->name, 2 * nparams, jail_set_flags); + if (jid < 0) { + if (errmsg[0] != '\0') + errx(1, "%s", errmsg); + err(1, "jail_set"); + } if (iflag) { - printf("%d\n", i); + printf("%d\n", jid); fflush(stdout); } if (Jflag) { - if (fp != NULL) { + if (oldargs) fprintf(fp, "%d\t%s\t%s\t%s\t%s\n", - i, j.path, j.hostname, argv[2], argv[3]); - (void)fclose(fp); - } else { - errx(1, "Could not write JidFile: %s", JidFile); + jid, (char *)params[0].value.iov_base, + argv[1], argv[2], argv[3]); + else { + fprintf(fp, "%d", jid); + for (i = 0; i < argc; i++) + fprintf(fp, "\t%s", argv[i]); + fprintf(fp, "\n"); } + (void)fclose(fp); } if (securelevel > 0) { if (sysctlbyname("kern.securelevel", NULL, 0, &securelevel, sizeof(securelevel))) err(1, "Can not set securelevel to %d", securelevel); } + if (cmdarg < 0) + exit(0); if (username != NULL) { if (Uflag) GET_USER_INFO; @@ -272,158 +269,256 @@ if (p) setenv("TERM", p, 1); } - if (execv(argv[3], argv + 3) != 0) - err(1, "execv: %s", argv[3]); - exit(0); + execvp(argv[cmdarg], argv + cmdarg); + err(1, "execvp: %s", argv[cmdarg]); } static void -usage(void) +set_param(const char *name, char *value) { + struct param *param; + char *ep, *p; + size_t buflen, mlen; + int i, nval, mib[CTL_MAXNAME]; + char buf[MAXPATHLEN]; - (void)fprintf(stderr, "%s%s%s\n", - "usage: jail [-hi] [-n jailname] [-J jid_file] ", - "[-s securelevel] [-l -u username | -U username] ", - "path hostname [ip[,..]] command ..."); - exit(1); -} + static int paramlistsize; -static int -add_addresses(struct addrinfo *res0) -{ - int error; - struct addrinfo *res; - struct addr4entry *a4p; - struct sockaddr_in *sai; + /* Separate the name from the value, if not done already. */ + if (name == NULL) { + name = value; + if ((value = strchr(value, '='))) + *value++ = '\0'; + } + + /* Handle pseudo-parameters separately. */ + if (!strcmp(name, "ip4_hostname")) { + set_param_ip_hostname(value, AF_INET); + return; + } #ifdef INET6 - struct addr6entry *a6p; - struct sockaddr_in6 *sai6; + if (!strcmp(name, "ip6_hostname")) { + set_param_ip_hostname(value, AF_INET6); + return; + } #endif - int count; - error = 0; - for (res = res0; res && error == 0; res = res->ai_next) { - switch (res->ai_family) { - case AF_INET: - sai = (struct sockaddr_in *)(void *)res->ai_addr; - STAILQ_FOREACH(a4p, &addr4, addr4entries) { - if (bcmp(&sai->sin_addr, &a4p->ip4, - sizeof(struct in_addr)) == 0) { - err(1, "Ignoring duplicate IPv4 address."); - break; - } - } - a4p = (struct addr4entry *) malloc( - sizeof(struct addr4entry)); - if (a4p == NULL) { - error = 1; - break; - } - bzero(a4p, sizeof(struct addr4entry)); - bcopy(&sai->sin_addr, &a4p->ip4, - sizeof(struct in_addr)); - if (!STAILQ_EMPTY(&addr4)) - count = STAILQ_FIRST(&addr4)->count; - else - count = 0; - STAILQ_INSERT_TAIL(&addr4, a4p, addr4entries); - STAILQ_FIRST(&addr4)->count = count + 1; + /* Check for repeat parameters */ + for (i = 0; i < nparams; i++) + if (!strcmp(name, params[i].name.iov_base)) { + memcpy(params + i, params + i + 1, + (--nparams - i) * sizeof(struct param)); break; + } + + /* Make sure there is room for the new param record. */ + if (!nparams) { + paramlistsize = 32; + params = malloc(paramlistsize * sizeof(*params)); + if (params == NULL) + err(1, "malloc"); + } else if (nparams >= paramlistsize) { + paramlistsize *= 2; + params = realloc(params, paramlistsize * sizeof(*params)); + if (params == NULL) + err(1, "realloc"); + } + + /* Look up the paramter. */ + param = params + nparams++; + *(const void **)¶m->name.iov_base = name; + param->name.iov_len = strlen(name) + 1; + /* Trivial values - no value or errmsg. */ + if (value == NULL) { + param->value.iov_base = value; + param->value.iov_len = 0; + return; + } + if (!strcmp(name, "errmsg")) { + param->value.iov_base = value; + param->value.iov_len = ERRMSG_SIZE; + return; + } + mib[0] = 0; + mib[1] = 3; + snprintf(buf, sizeof(buf), SJPARAM ".%s", name); + mlen = sizeof(mib) - 2 * sizeof(int); + if (sysctl(mib, 2, mib + 2, &mlen, buf, strlen(buf)) < 0) + errx(1, "unknown parameter: %s", name); + mib[1] = 4; + buflen = sizeof(buf); + if (sysctl(mib, (mlen / sizeof(int)) + 2, buf, &buflen, NULL, 0) < 0) + err(1, "sysctl(0.4.%s)", name); + /* + * See if this is an array type. + * Treat non-arrays as an array of one. + */ + p = strchr(buf + sizeof(int), '\0'); + nval = 1; + if (p - 2 >= buf && !strcmp(p - 2, ",a")) { + if (value[0] == '\0' || + (value[0] == '-' && value[1] == '\0')) { + param->value.iov_base = value; + param->value.iov_len = 0; + return; + } + p[-2] = 0; + for (p = strchr(value, ','); p; p = strchr(p + 1, ',')) { + *p = 0; + nval++; + } + } + + /* Set the values according to the parameter type. */ + switch (*(int *)buf & CTLTYPE) { + case CTLTYPE_INT: + case CTLTYPE_UINT: + param->value.iov_len = nval * sizeof(int); + break; + case CTLTYPE_LONG: + case CTLTYPE_ULONG: + param->value.iov_len = nval * sizeof(long); + break; + case CTLTYPE_STRUCT: + if (!strcmp(buf + sizeof(int), "S,in_addr")) + param->value.iov_len = nval * sizeof(struct in_addr); #ifdef INET6 - case AF_INET6: - sai6 = (struct sockaddr_in6 *)(void *)res->ai_addr; - STAILQ_FOREACH(a6p, &addr6, addr6entries) { - if (bcmp(&sai6->sin6_addr, &a6p->ip6, - sizeof(struct in6_addr)) == 0) { - err(1, "Ignoring duplicate IPv6 address."); - break; - } + else if (!strcmp(buf + sizeof(int), "S,in6_addr")) + param->value.iov_len = nval * sizeof(struct in6_addr); +#endif + else + errx(1, "%s: unknown parameter structure (%s)", + name, buf + sizeof(int)); + break; + case CTLTYPE_STRING: + if (!strcmp(name, "path")) { + param->value.iov_base = malloc(MAXPATHLEN); + if (param->value.iov_base == NULL) + err(1, "malloc"); + if (realpath(value, param->value.iov_base) == NULL) + err(1, "%s: realpath(%s)", name, value); + if (chdir(param->value.iov_base) != 0) + err(1, "chdir: %s", + (char *)param->value.iov_base); + } else + param->value.iov_base = value; + param->value.iov_len = strlen(param->value.iov_base) + 1; + return; + default: + errx(1, "%s: unknown parameter type %d (%s)", + name, *(int *)buf, buf + sizeof(int)); + } + param->value.iov_base = malloc(param->value.iov_len); + for (i = 0; i < nval; i++) { + switch (*(int *)buf & CTLTYPE) { + case CTLTYPE_INT: + ((int *)param->value.iov_base)[i] = + strtol(value, &ep, 10); + if (ep[0] != '\0') + errx(1, "%s: non-integer value \"%s\"", + name, value); + break; + case CTLTYPE_UINT: + ((unsigned *)param->value.iov_base)[i] = + strtoul(value, &ep, 10); + if (ep[0] != '\0') + errx(1, "%s: non-integer value \"%s\"", + name, value); + break; + case CTLTYPE_LONG: + ((long *)param->value.iov_base)[i] = + strtol(value, &ep, 10); + if (ep[0] != '\0') + errx(1, "%s: non-integer value \"%s\"", + name, value); + break; + case CTLTYPE_ULONG: + ((unsigned long *)param->value.iov_base)[i] = + strtoul(value, &ep, 10); + if (ep[0] != '\0') + errx(1, "%s: non-integer value \"%s\"", + name, value); + break; + case CTLTYPE_STRUCT: + if (!strcmp(buf + sizeof(int), "S,in_addr")) { + if (inet_pton(AF_INET, value, + &((struct in_addr *) + param->value.iov_base)[i]) != 1) + errx(1, "%s: not an IPv4 address: %s", + name, value); } - a6p = (struct addr6entry *) malloc( - sizeof(struct addr6entry)); - if (a6p == NULL) { - error = 1; - break; +#ifdef INET6 + else if (!strcmp(buf + sizeof(int), "S,in6_addr")) { + if (inet_pton(AF_INET6, value, + &((struct in6_addr *) + param->value.iov_base)[i]) != 1) + errx(1, "%s: not an IPv6 address: %s", + name, value); } - bzero(a6p, sizeof(struct addr6entry)); - bcopy(&sai6->sin6_addr, &a6p->ip6, - sizeof(struct in6_addr)); - if (!STAILQ_EMPTY(&addr6)) - count = STAILQ_FIRST(&addr6)->count; - else - count = 0; - STAILQ_INSERT_TAIL(&addr6, a6p, addr6entries); - STAILQ_FIRST(&addr6)->count = count + 1; - break; #endif - default: - err(1, "Address family %d not supported. Ignoring.\n", - res->ai_family); - break; } + value = strchr(value, '\0') + 1; } - - return (error); } -static struct in_addr * -copy_addr4(void) +static void +set_param_ip_hostname(char *value, int family) { - size_t len; - struct in_addr *ip4s, *p, ia; - struct addr4entry *a4p; + struct addrinfo hints, *ai0, *ai; + char *avalue, *nextav; + socklen_t avlen; + int error; - if (STAILQ_EMPTY(&addr4)) - return NULL; + /* Look up the hostname in the specified address family. */ + memset(&hints, 0, sizeof(hints)); + hints.ai_family = family; + error = getaddrinfo(value, NULL, &hints, &ai0); + if (error != 0) + errx(1, "hostname %s: %s", value, gai_strerror(error)); - len = STAILQ_FIRST(&addr4)->count * sizeof(struct in_addr); - - ip4s = p = (struct in_addr *)malloc(len); - if (ip4s == NULL) - return (NULL); - - bzero(p, len); - - while (!STAILQ_EMPTY(&addr4)) { - a4p = STAILQ_FIRST(&addr4); - STAILQ_REMOVE_HEAD(&addr4, addr4entries); - ia.s_addr = a4p->ip4.s_addr; - bcopy(&ia, p, sizeof(struct in_addr)); - p++; - free(a4p); + /* Convert the addresses to ASCII so set_param can convert them back. */ + avlen = 0; + for (ai = ai0; ai; ai = ai->ai_next) + avlen++; + avlen *= +#ifdef INET6 + family == AF_INET6 ? INET6_ADDRSTRLEN : +#endif + INET_ADDRSTRLEN; + avalue = malloc(avlen); + if (avalue == NULL) + err(1, "malloc"); + avalue[0] = 0; + for (nextav = avalue, ai = ai0; ai; ai = ai->ai_next) { + if (inet_ntop(family, +#ifdef INET6 + family == AF_INET6 ? + (void *)&((struct sockaddr_in6 *)&ai->ai_addr)->sin6_addr : +#endif + (void *)&((struct sockaddr_in *)&ai->ai_addr)->sin_addr, + nextav, avlen - (nextav - avalue)) == NULL) + err(1, "inet_ntop"); + if (ai->ai_next) { + nextav = strchr(nextav, '\0'); + *nextav++ = ','; + } } - - return (ip4s); + set_param( +#ifdef INET6 + family == AF_INET6 ? "ip6.addr" : +#endif + "ip4.addr", avalue); } -#ifdef INET6 -static struct in6_addr * -copy_addr6(void) +static void +usage(void) { - size_t len; - struct in6_addr *ip6s, *p; - struct addr6entry *a6p; - if (STAILQ_EMPTY(&addr6)) - return NULL; - - len = STAILQ_FIRST(&addr6)->count * sizeof(struct in6_addr); - - ip6s = p = (struct in6_addr *)malloc(len); - if (ip6s == NULL) - return (NULL); - - bzero(p, len); - - while (!STAILQ_EMPTY(&addr6)) { - a6p = STAILQ_FIRST(&addr6); - STAILQ_REMOVE_HEAD(&addr6, addr6entries); - bcopy(&a6p->ip6, p, sizeof(struct in6_addr)); - p++; - free(a6p); - } - - return (ip6s); + (void)fprintf(stderr, + "usage: jail [-d] [-i] [-J jid_file] [-s securelevel]\n" + " [-l -u username | -U username]\n" + " [[-c | -o] param=value ... [command=command ...] |\n" + " path hostname ip command ...]\n" + " jail [-r jail]\n"); + exit(1); } -#endif - Index: usr.sbin/jail/jail.8 =================================================================== --- usr.sbin/jail/jail.8 (revision 191694) +++ usr.sbin/jail/jail.8 (working copy) @@ -1,5 +1,6 @@ .\" .\" Copyright (c) 2000, 2003 Robert N. M. Watson +.\" Copyright (c) 2008 James Gritton .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without @@ -33,49 +34,37 @@ .\" .\" $FreeBSD$ .\" -.Dd January 24, 2009 +.Dd April 30, 2009 .Dt JAIL 8 .Os .Sh NAME .Nm jail -.Nd "imprison process and its descendants" +.Nd "create or modify a system jail" .Sh SYNOPSIS .Nm -.Op Fl hi -.Op Fl n Ar jailname +.Op Fl di .Op Fl J Ar jid_file .Op Fl s Ar securelevel .Op Fl l u Ar username | Fl U Ar username -.Ar path hostname [ip[,..]] command ... +.Op Fl c | o +.Op Ar parameter=value ... | path hostname ip command ... +.Br +.Nm +.Op Fl r Ar jail .Sh DESCRIPTION The .Nm -utility imprisons a process and all future descendants. +utility creates a new jail or modifies an existing jail, optionally +imprisoning the current process (and future descendants) inside it. .Pp The options are as follows: -.Bl -tag -width ".Fl u Ar username" -.It Fl h -Resolve -.Va hostname -and add all IP addresses returned by the resolver -to the list of -.Va ip-addresses -for this prison. -This may affect default address selection for outgoing IPv4 connections -of prisons. -The address first returned by the resolver for each address family -will be used as primary address. -See -.Va ip-addresses -further down for details. +.Bl -tag -width indent +.It Fl d +Allow making changes to a +.Va +dying jail. .It Fl i Output the jail identifier of the newly created jail. -.It Fl n Ar jailname -Assign and administrative name to the jail that can be used for management -or auditing purposes. -The system will -.Sy not enforce -the name to be unique. .It Fl J Ar jid_file Write a .Ar jid_file @@ -100,7 +89,10 @@ .It Fl s Ar securelevel Sets the .Va kern.securelevel -sysctl variable to the specified value inside the newly created jail. +MIB entry to the specified value inside the newly created jail. +This is equivalent to setting the jail's +.Va securelevel +parameter. .It Fl u Ar username The user name from host environment as whom the .Ar command @@ -109,20 +101,156 @@ The user name from jailed environment as whom the .Ar command should run. -.It Ar path +.It Fl c +Create a new jail, but do not modify an existing one. +Default behavior is to allow modification if a +.Va jid +or +.Va name +parameter refers to an existing jail. +.It Fl o +Only modify an existing jail, but do not create one. +One of the +.Va jid +or +.Va name +parameters must exist and refer to an existing jail. +.It Fl r +Remove the +.Ar jail +specified by jid or name. +All jailed processes are killed. +.El +.Pp +.Ar Parameters +are listed in +.Dq name=value +form, following the options. +Some parameters are boolean, and do not have a value but are set by the +name alone with or without a +.Dq no +prefix, e.g. +.Va persist +or +.Va nopersist . +Any parameters not set will be given default values, generally based on the +current environment. +.Pp +The pseudo-parameter +.Va command +specifies that the current process should enter the new (or modified) jail, +and run the specified command. +It must be the last parameter specified, because it includes not only +the value following the +.Sq = +sign, but also passes the rest of the arguments to the command. +.Pp +Instead of supplying named +.Ar parameters , +four fixed parameters may be supplied in order on the command line: +.Ar path , +.Ar hostname , +.Ar ip , +and +.Ar command . +As the +.Va jid +and +.Va name +parameters aren't in this list, this mode will always create a new jail, and +the +.Fl c +and +.Fl o +options don't apply. +.Pp +Jails have a set a core parameters, and modules can add their own jail +parameters. +The current set of available parameters can be retrieved via +.Dq Nm sysctl Fl d Va security.jail.param . +Some of the notable core parameters include: +.Bl -tag -width indent +.It Va jid +The jail identifier. +This will be assigned automatically to a new jail (or can be explicitly +set), and can be used to identify the jail for later modification, or +for such commands as +.Xr jls 8 +or +.Xr jexec 8 . +.It Va name +The jail name. +This is an arbitrary string that identifies a jail. +Like the +.Va jid , +it can be passed to later +.Nm +commands, or to +.Xr jls 8 +or +.Xr jexec 8 . +If no +.Va name +is supplied, a default is assumed that is the same as the +.Va jid . +.It Va path Directory which is to be the root of the prison. -.It Ar hostname -Hostname of the prison. -.It Ar ip-addresses -None, one or more IPv4 and IPv6 addresses assigned to the prison. -The first address of each address family that was assigned to the jail will -be used as the source address in case source address selection on unbound -sockets cannot find a better match. +The +.Va command +(if any) is run from this directory, as are commands from +.Xr jexec 8 . +.It Va ip4.addr +A comma-separated list of IPv4 addresses assigned to the prison. +If this is set, the jail is restricted to using only these address. +Any attempts to use other addresses fail, and attempts to use wildcard +addresses silently use the jailed address instead. +For IPv4 the first address given will be kept used as the source address +in case source address selection on unbound sockets cannot find a better +match. It is only possible to start multiple jails with the same IP address, if none of the jails has more than this single overlapping IP address -assigned to itself for the address family in question. -.It Ar command -Pathname of the program which is to be executed. +assigned to itself. +.Pp +A list of zero elements (an empty string) will stop the jail from using IPv4 +entirely; setting the boolean parameter +.Ar noip4 +will not restrict the jail at all. +.It Va ip6.addr +A list of IPv6 addresses assigned to the prison, the counterpart to +.Ar ip4.addr +above. +.It Va host.hostname +Hostname of the prison. +If not specified, a jail will use the system hostname. +.It Va ip4_hostname +.It Va ip6_hostname +These psuedo-parameters actually set the jail's +.Va ip4 +and +.Va ip6 +parameters, but will get those addresses by resolving the supplied hostname. +.It Va securelevel +The value of the jail's +.Va kern.securelevel +sysctl. +A jail never has a lower securelevel than the default system, but by +setting this parameter it may have a higher one. +If the system securelevel is changed, any jail securelevels will be at +least as secure. +.It Va persist +Setting this boolean parameter allows a jail to exist without any +processes. +Normally, a jail is destroyed as its last process exits. +.It Va command +The command to run after creating or modifying the jail. +This command is run inside the jail, under the +.Va path +directory. +A new jail must have either the +.Va persist +or +.Va command +parameter set. .El .Pp Jails are typically set up using one of two philosophies: either to @@ -142,10 +270,6 @@ This manual page documents the configuration steps necessary to support either of these steps, although the configuration steps may be refined based on local requirements. -.Pp -Please see the -.Xr jail 2 -man page for further details. .Sh EXAMPLES .Ss "Setting up a Jail Directory Tree" To set up a jail directory tree containing an entire @@ -605,7 +729,7 @@ a jail. This functionality is disabled by default, but can be enabled by setting this MIB entry to 1. -.It Va security.jail.jail_max_af_ips +.It Va security.jail.max_af_ips This MIB entry determines how may address per address family a prison may have. The default is 255. .El @@ -641,7 +765,7 @@ .Xr ps 1 , .Xr quota 1 , .Xr chroot 2 , -.Xr jail 2 , +.Xr jail_set 2 , .Xr jail_attach 2 , .Xr procfs 5 , .Xr rc.conf 5 , @@ -665,6 +789,8 @@ .Nm utility appeared in .Fx 4.0 . +Extensible jail parameters were introduced in +.Fx 8.0 . .Sh AUTHORS .An -nosplit The jail feature was written by @@ -683,6 +809,9 @@ originally done by .An Pawel Jakub Dawidek for IPv4. +.Pp +.An James Gritton +added the extensible jail parameters. .Sh BUGS Jail currently lacks the ability to allow access to specific jail information via Index: sys/sys/jail.h =================================================================== --- sys/sys/jail.h (revision 191694) +++ sys/sys/jail.h (working copy) @@ -84,19 +84,11 @@ struct in6_addr pr_ip6[]; #endif }; -#define XPRISON_VERSION 3 +#define XPRISON_VERSION 3 -static const struct prison_state { - int pr_state; - const char * state_name; -} prison_states[] = { -#define PRISON_STATE_INVALID 0 - { PRISON_STATE_INVALID, "INVALID" }, -#define PRISON_STATE_ALIVE 1 - { PRISON_STATE_ALIVE, "ALIVE" }, -#define PRISON_STATE_DYING 2 - { PRISON_STATE_DYING, "DYING" }, -}; +#define PRISON_STATE_INVALID 0 +#define PRISON_STATE_ALIVE 1 +#define PRISON_STATE_DYING 2 /* * Flags for jail_set and jail_get. From mav at FreeBSD.org Mon May 4 03:19:42 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 4 03:19:55 2009 Subject: Fighting for the power. In-Reply-To: <49FE29A4.30507@root.org> References: <49FE1826.4060000@FreeBSD.org> <49FE29A4.30507@root.org> Message-ID: <49FE5EC8.3040205@FreeBSD.org> Nate Lawson wrote: > The time may have come to disable p4tcc and throttling by default, as > long as it's easy for a user to enable them again. Perhaps just a change > to boot/default/device.hints? They still could be effective for old P4 series which had no C1E/C2 idle states support yet. But probably their power consumption is not so interesting area now. > The default settings in rc.conf should allow the lowest Cx setting > available to be used. Perhaps that changed? Really, we want C3+ to be > enabled by default without the user doing anything. Present defaults are to use C1. Probably we can allow C2 use more or less safely. Due to default LAPIC timer problems, enabling C3+ by default will make system dead by default. > Yeah, hz=1000 doesn't make sense for laptops and I use hz=100 everywhere. Without using C3+ it is not so important. I haven't seen any power difference. C1/C2 have practically zero exit latency, while power consumed by interrupt handler itself is miserable. > The real solution for C3 (and C4, etc.) is to implement tickless > scheduling and to fix the current dependence on LAPIC for timer > interrupts. Hopefully someone will do that soon. With that change, this > change isn't needed. System will always have tons of waiting callouts and timeouts to be handled. So timer will be always needed. Working timer. >> 4. HDA modem >> I was surprised, but integrated HDA modem consumed about 1W of power >> even when not used. I have used the most radical solution - removed it >> mechanically from socket. Case surface in that area become much cooler. > > Most modems support the ACPI Dx states, where D3 = device powered off. > I'd think the PCI "power no driver option" would disable the soft modem > since it's unlikely you have a driver for it. Modem share HDA bus/controller with sound. So PCI D3 will kill sound also, that is not an option. snd_hda driver itself puts all non-audio codecs into the HDA D3 state, but in my case it was not effective. >> 6. HDD >> First common recommendation is use tmpfs for temporary files. RAM is >> cheap, fast and anyway with you. >> Also you may try to setup automatic idle drive spin-down, but if it is >> the only system drive you should be careful, as every spin-up reduces >> drive's life time. > > Did you increase the fsflush delay also? I don't, but how long can it delay requests? Several minutes? Hour? Then there is high probability of data loss. Actually I have tried to reduce number of idle disk write activity, but I haven't very succeeded. Even in my quite simple icewm X environment something was persistently writing something every several minutes. I have found and disabled some activity sources, but it was not enough. What would happen in some complicated KDE/Gnome environment I am just afraid to think. -- Alexander Motin From mav at FreeBSD.org Mon May 4 03:45:15 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 4 03:45:33 2009 Subject: Fighting for the power. In-Reply-To: <20090504011421.GI6901@egr.msu.edu> References: <49FE1826.4060000@FreeBSD.org> <20090504011421.GI6901@egr.msu.edu> Message-ID: <49FE64C5.2020507@FreeBSD.org> Adam McDougall wrote: > On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: > > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. > > Great list! May I suggest screen brightness and DPMS as another tool > to save power, I've measured a 5W difference from the screen draw. > Keeping the brightness as low as tolerable helps considerably, but > also using 'xset dpms 120 120 120' (modify to taste) in .xinitrc to > turn off the screen after 2 minutes helps when the laptop isn't being > used every second. May need this in xorg.conf: > Option "dpms" Yes, backlight is also important. But there is not so much things could be done. When I am leaving system for some time, I can just close the lid, if not put system into S3 state, which require very small power (at least I was unable to really measure it without all-day-long testing). Thanks to jkim@ we have more or less working S3 state for amd64 now. -- Alexander Motin From rea-fbsd at codelabs.ru Mon May 4 05:22:37 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon May 4 05:22:44 2009 Subject: Patch for "device_attach: estX attach returned 6" on half of the cores Message-ID: Good day. Recently I had filed a PR, http://www.freebsd.org/cgi/query-pr.cgi?pr=134192 that should heal the situation when estX isn't attached properly on the half of processor cores (the odd ones). I am seeing this only on Asus MBs, but this could show up on other hardware as well. If anyone sees such symptoms, I encourage them to test the patch. The patch itself contained in the PR, but for ease I had put it there, http://codelabs.ru/fbsd/patches/acpi/attach-children-without-aliases.diff and will sync PR's one and this one in the case of any changes. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From phk at phk.freebsd.dk Mon May 4 06:25:22 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon May 4 06:25:30 2009 Subject: New jail framework - the userland side In-Reply-To: Your message of "Sun, 03 May 2009 20:31:35 CST." <49FE5387.3020503@FreeBSD.org> Message-ID: <4424.1241418320@critter.freebsd.dk> In message <49FE5387.3020503@FreeBSD.org>, Jamie Gritton writes: >Hi all. I recently added some new jail-related system calls to extend >the current jail system with an nmount-inspired name=value interface. I think this is a great move in the right direction, my only concern is that we should try to share as much of the string-munging code between the nmount and jail implementations as possible. -- 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 rnoland at FreeBSD.org Mon May 4 06:28:35 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon May 4 06:28:54 2009 Subject: Patch for "device_attach: estX attach returned 6" on half of the cores In-Reply-To: References: Message-ID: <1241418372.78715.1.camel@balrog.2hip.net> On Mon, 2009-05-04 at 09:22 +0400, Eygene Ryabinkin wrote: > Good day. > > Recently I had filed a PR, > http://www.freebsd.org/cgi/query-pr.cgi?pr=134192 > that should heal the situation when estX isn't attached properly > on the half of processor cores (the odd ones). I am seeing this > only on Asus MBs, but this could show up on other hardware as well. > > If anyone sees such symptoms, I encourage them to test the patch. > The patch itself contained in the PR, but for ease I had put it > there, > http://codelabs.ru/fbsd/patches/acpi/attach-children-without-aliases.diff > and will sync PR's one and this one in the case of any changes. I'm seeing this on both an ASUS and an Intel board that I have. Both have core2duo E7400's in them. I have applied this patch to the Intel board so far, but unfortunately now both cores fail equally. cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2306004a23 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 6164a2306004a23 device_attach: est1 attach returned 6 p4tcc1: on cpu1 robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090504/bb23d079/attachment.pgp From rea-fbsd at codelabs.ru Mon May 4 06:34:50 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon May 4 06:34:56 2009 Subject: Patch for "device_attach: estX attach returned 6" on half of the cores In-Reply-To: <1241418372.78715.1.camel@balrog.2hip.net> References: <1241418372.78715.1.camel@balrog.2hip.net> Message-ID: Robert, good day. Mon, May 04, 2009 at 01:26:12AM -0500, Robert Noland wrote: > On Mon, 2009-05-04 at 09:22 +0400, Eygene Ryabinkin wrote: > > Good day. > > > > Recently I had filed a PR, > > http://www.freebsd.org/cgi/query-pr.cgi?pr=134192 > > that should heal the situation when estX isn't attached properly > > on the half of processor cores (the odd ones). I am seeing this > > only on Asus MBs, but this could show up on other hardware as well. > > > > If anyone sees such symptoms, I encourage them to test the patch. > > The patch itself contained in the PR, but for ease I had put it > > there, > > http://codelabs.ru/fbsd/patches/acpi/attach-children-without-aliases.diff > > and will sync PR's one and this one in the case of any changes. > > I'm seeing this on both an ASUS and an Intel board that I have. Both > have core2duo E7400's in them. I have applied this patch to the Intel > board so far, but unfortunately now both cores fail equally. > > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6164a2306004a23 > device_attach: est0 attach returned 6 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This means that most likely you don't have _PSS entries in your DSDT table at all. The patch helps in the case when some processor names are aliased _and_ half of processors are attached properly even without this patch. One could check if the patch will help by examining the output of 'apicdump -d' and looking for the Alias () directives for the Processor objects. Here's what I have for my laptop: ----- Scope (_PR) { Processor (P001, 0x01, 0x00000810, 0x06) {} Alias (P001, CPU1) } Scope (_PR) { Processor (P002, 0x02, 0x00000810, 0x06) {} Alias (P002, CPU2) } ----- So in this case we essentially have 4 Processor objects under _PR, but only two objects are real ones and only they should be attached. For the completeness, could you, please, show the output of 'acpidump -dt 2>&1' for both of your machines? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From hselasky at c2i.net Mon May 4 07:24:06 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon May 4 07:24:13 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <200905040926.38337.hselasky@c2i.net> > 2. PCI devices > PCI bus provides method to control device power. For example, I have > completely no use for my FireWire controller and most of time - EHCI USB > controller. Disabling them allows me to save about 3W of power. To > disable all unneeded PCI devices you should build kernel without their > drivers and add to loader.conf: > hw.pci.do_power_nodriver=3 > To enable devices back all you need to do is just load their drivers as > modules. The new USB stack should turn off USB HC's automatically when not in use. At least the schedules will get disabled. Did you do any research on this? --HPS From mav at FreeBSD.org Mon May 4 07:50:25 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 4 07:50:32 2009 Subject: Fighting for the power. In-Reply-To: <200905040926.38337.hselasky@c2i.net> References: <49FE1826.4060000@FreeBSD.org> <200905040926.38337.hselasky@c2i.net> Message-ID: <49FE9E3B.1050509@FreeBSD.org> Hans Petter Selasky wrote: >> 2. PCI devices >> PCI bus provides method to control device power. For example, I have >> completely no use for my FireWire controller and most of time - EHCI USB >> controller. Disabling them allows me to save about 3W of power. To >> disable all unneeded PCI devices you should build kernel without their >> drivers and add to loader.conf: >> hw.pci.do_power_nodriver=3 >> To enable devices back all you need to do is just load their drivers as >> modules. > > The new USB stack should turn off USB HC's automatically when not in use. At > least the schedules will get disabled. Did you do any research on this? Sorry, I really was testing it only with previous USB stack. Now I can acknowledge, that new ehci module loading adds only 0.2W for me by default and almost nothing if I power down built-in USB2 web cam connected to it using `usbconfig -u 5 -a 2 power_off`. Great! Thanks! -- Alexander Motin From tinderbox at freebsd.org Mon May 4 09:17:47 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon May 4 09:18:31 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090504091741.7D1BC7302F@freebsd-current.sentex.ca> TB --- 2009-05-04 07:37:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-04 07:37:33 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-04 07:37:33 - cleaning the object tree TB --- 2009-05-04 07:37:55 - cvsupping the source tree TB --- 2009-05-04 07:37:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-04 07:38:07 - building world TB --- 2009-05-04 07:38:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-04 07:38:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-04 07:38:07 - TARGET=pc98 TB --- 2009-05-04 07:38:07 - TARGET_ARCH=i386 TB --- 2009-05-04 07:38:07 - TZ=UTC TB --- 2009-05-04 07:38:07 - __MAKE_CONF=/dev/null TB --- 2009-05-04 07:38:07 - cd /src TB --- 2009-05-04 07:38:07 - /usr/bin/make -B buildworld >>> World build started on Mon May 4 07:38:09 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon May 4 09:01:09 UTC 2009 TB --- 2009-05-04 09:01:09 - generating LINT kernel config TB --- 2009-05-04 09:01:09 - cd /src/sys/pc98/conf TB --- 2009-05-04 09:01:09 - /usr/bin/make -B LINT TB --- 2009-05-04 09:01:09 - building LINT kernel TB --- 2009-05-04 09:01:09 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-04 09:01:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-04 09:01:09 - TARGET=pc98 TB --- 2009-05-04 09:01:09 - TARGET_ARCH=i386 TB --- 2009-05-04 09:01:09 - TZ=UTC TB --- 2009-05-04 09:01:09 - __MAKE_CONF=/dev/null TB --- 2009-05-04 09:01:09 - cd /src TB --- 2009-05-04 09:01:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon May 4 09:01:09 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel apm.o(.text+0x109a): In function `apm_attach': : undefined reference to `atrtcclock_disable' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-04 09:17:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-04 09:17:41 - ERROR: failed to build lint kernel TB --- 2009-05-04 09:17:41 - 4702.03 user 452.77 system 6008.14 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From onemda at gmail.com Mon May 4 09:28:53 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon May 4 09:29:00 2009 Subject: geom_part In-Reply-To: <20090503224205.GB1414@hades.panopticon> References: <20090503224205.GB1414@hades.panopticon> Message-ID: <3a142e750905040228m7b761be7r872de991c9cd811a@mail.gmail.com> On 5/4/09, Dmitry Marakasov wrote: > Hi! > > I've upgraded one of my boxes to current recently and ran into some > problems with new geom_part. > > First, it's impossible to edit bsd label online. > > # bsdlabel -e /dev/ad8 > [edit] > bsdlabel: Class not found > re-edit the label? [y]: > bsdlabel, fdisk and others no longer works correctly, use gpart(8) instead. If you really want to still use bsdlabel and fdisk you need custom kernel without geom_part* note that geom_bsd and geom_mbr are going to be removed soon from CURRENT(because they are not used anymore). > Setting sysctl kern.geom.debugflags to 16 helps. > > Next, it's no longer possible to use nested configuration. If I add > bsd label to, say, /dev/ad8f, no subpartitions (ad8fa, ad8fd ...) > will be shown. They pop up after loading geom_bsd. > > Finally, seems like bsd label support is broken: > > # bsdlabel /dev/ad8 > # /dev/ad8: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 2097152 0 4.2BSD 2048 16384 28528 > b: 20971520 2097152 swap > c: 390721968 0 unused 0 0 # "raw" part, don't > edit > d: 20971520 23068672 4.2BSD 2048 16384 28528 > e: 2097152 44040192 4.2BSD 2048 16384 28528 > f: 20971520 46137344 4.2BSD 2048 16384 28528 > g: 41943040 67108864 unused 0 0 > h: 281670064 109051904 unused 0 0 > > # ls /dev/ad8* > /dev/ad8 /dev/ad8b /dev/ad8e /dev/ad8g > /dev/ad8a /dev/ad8d /dev/ad8f > > No h partition! > > -- > Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D > amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru > _______________________________________________ > 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" > -- Paul From onemda at gmail.com Mon May 4 09:40:43 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon May 4 09:40:49 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> On 5/4/09, Alexander Motin wrote: > 2. PCI devices > PCI bus provides method to control device power. For example, I have > completely no use for my FireWire controller and most of time - EHCI USB > controller. Disabling them allows me to save about 3W of power. To > disable all unneeded PCI devices you should build kernel without their > drivers and add to loader.conf: > hw.pci.do_power_nodriver=3 > To enable devices back all you need to do is just load their drivers as > modules. Unloading modules doesnt put them back into into D3 state. You are forced to load some another module again to put wanted device into D3 state. -- Paul From mav at FreeBSD.org Mon May 4 09:51:11 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 4 09:51:18 2009 Subject: Fighting for the power. In-Reply-To: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> References: <49FE1826.4060000@FreeBSD.org> <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> Message-ID: <49FEBA89.4040609@FreeBSD.org> Paul B. Mahol wrote: > On 5/4/09, Alexander Motin wrote: >> 2. PCI devices >> PCI bus provides method to control device power. For example, I have >> completely no use for my FireWire controller and most of time - EHCI USB >> controller. Disabling them allows me to save about 3W of power. To >> disable all unneeded PCI devices you should build kernel without their >> drivers and add to loader.conf: >> hw.pci.do_power_nodriver=3 >> To enable devices back all you need to do is just load their drivers as >> modules. > > Unloading modules doesnt put them back into into D3 state. > You are forced to load some another module again to put wanted device > into D3 state. Yes. Resume also does not powers down unowned devices. Would be good to fix that also. -- Alexander Motin From quakelee at geekcn.org Mon May 4 10:00:41 2009 From: quakelee at geekcn.org (Chao Shin) Date: Mon May 4 10:00:49 2009 Subject: current couldn't attach usb mouse Message-ID: Hi, all I have a dell optiplex 745 box with a dell usb mouse. I update system from 7.1 to current today, after that the usb mouse could not recongnize. I got some message from dmesg like below: uhci_interrupt: host system error uhci_interrupt: host system error usb2_alloc_device:1574: set address 2 failed (USB_ERR_TIMEOUT, ignored) usb2_alloc_device:1612: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:417: could not allocate new device! my current is up to date current, [root@currentpark] ~# sysctl kern.osreldate kern.osreldate: 800085 [root@currentpark] ~# uname -a FreeBSD currentpark.intra.umessage.com.cn 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon May 4 17:46:54 CST 2009 root@currentpark.intra.umessage.com.cn:/usr/obj/usr/src/sys/GENERIC amd64 Is this a usb2.0's bug or I should configure something else? -- The Power to Serve From hselasky at c2i.net Mon May 4 10:35:58 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon May 4 10:36:06 2009 Subject: current couldn't attach usb mouse In-Reply-To: References: Message-ID: <200905041238.30304.hselasky@c2i.net> On Monday 04 May 2009, Chao Shin wrote: > Hi, all > > I have a dell optiplex 745 box with a dell usb mouse. I update system from > 7.1 to current today, > after that the usb mouse could not recongnize. I got some message from > dmesg like below: > > > Is this a usb2.0's bug or I should configure something else? Can you send complete dmesg ? --HPS From rea-fbsd at codelabs.ru Mon May 4 11:28:31 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon May 4 11:28:38 2009 Subject: Patch for "device_attach: estX attach returned 6" on half of the cores In-Reply-To: <1241419338.78715.8.camel@balrog.2hip.net> References: <1241418372.78715.1.camel@balrog.2hip.net> <1241419338.78715.8.camel@balrog.2hip.net> Message-ID: Robert, Mon, May 04, 2009 at 01:42:18AM -0500, Robert Noland wrote: > Without this patch, cpu0 does attach correctly. On the Intel MB? If yes and you'll be able to to some debugging, please, try the attached patch and send the output of 'dmesg', 'sysctl dev.cpu', 'sysctl dev.cpufreq' and 'sysctl dev.est'. > > One could check if the patch will help by examining the output of > > 'apicdump -d' and looking for the Alias () directives for the Processor > > objects. Here's what I have for my laptop: > > ----- > > Scope (_PR) > > { > > Processor (P001, 0x01, 0x00000810, 0x06) {} > > Alias (P001, CPU1) > > } > > > > Scope (_PR) > > { > > Processor (P002, 0x02, 0x00000810, 0x06) {} > > Alias (P002, CPU2) > > } > > ----- > > So in this case we essentially have 4 Processor objects under _PR, > > but only two objects are real ones and only they should be attached. > > > > For the completeness, could you, please, show the output of 'acpidump > > -dt 2>&1' for both of your machines? > > Attached. The Asus does appear to use aliases as you described. Then you should have est attached to cpu0/cpu2 and rejected on cpu1/cpu3, aren't you? The output of 'sysctl dev.cpu', 'sysctl dev.est' and 'sysctl dev.cpufreq' will be also helpful. Will you be able to try my original patch on the Asus system? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: acpi_perf-provide-debugging-statements.diff Type: text/x-diff Size: 4564 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090504/3403577a/acpi_perf-provide-debugging-statements.bin From mav at FreeBSD.org Mon May 4 12:24:33 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 4 12:24:50 2009 Subject: Fighting for the power. In-Reply-To: <1241438990.1280.6.camel@RabbitsDen> References: <49FE1826.4060000@FreeBSD.org> <1241438990.1280.6.camel@RabbitsDen> Message-ID: <49FEDE7B.30804@FreeBSD.org> Alexandre "Sunny" Kovalenko wrote: > On Mon, 2009-05-04 at 01:18 +0300, Alexander Motin wrote: >> - C3 state allows CPU completely stop all internal clocks, reduce >> voltage and disconnect from system bus. This state gives additional >> power saving effect, but it is not cheap and require trade-offs. >> As soon as CPU is completely stopped in C3 state, local APIC timers in >> each CPU core, used by FreeBSD as event sources on SMP, are not >> functioning. It stops system time, breaks scheduling that makes system >> close to dead. > Did you try to see whether putting one of the cores in C3 state by doing > something like > > dev.cpu.1.cx_lowest=C3 > > makes any difference? > > # sysctl dev.cpu | grep cx_usage > dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% > dev.cpu.1.cx_usage: 0.00% 5.18% 94.81% I did. As soon as first CPU core is not in C3 state, second core unable to enter C3 completely and disconnect from the bus, as cores are sharing common resources. Such technique allows to avoid LAPIC timer problems, but I haven't noticed any effect from this on CPU idle power. The only difference I have noticed was in the case, when first core is busy. C3 on second idle core then somehow reduces summary consumption a bit. In other words, C3 state should be active on both cores simultaneously to give real effect. -- Alexander Motin From odhiambo at gmail.com Mon May 4 12:32:54 2009 From: odhiambo at gmail.com (=?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?=) Date: Mon May 4 12:33:02 2009 Subject: VIMAGE status In-Reply-To: <49FC812B.2070305@elischer.org> References: <49FC812B.2070305@elischer.org> Message-ID: <991123400905040512s196ec51o3a084b9e1fc8a0e1@mail.gmail.com> On Sat, May 2, 2009 at 8:21 PM, Julian Elischer wrote: > The VIMAGE code is nearly all in the the kernel. > > One is now able to make VIMAGE kernels (add options VIMAGE) > though they don't actually allow you to make multiple > vimages instances yet.. > > The VIMAGE option enables all the low level changes needed > throughout the kernel. > > The VIMAGE_GLOBALS option basically sets thing sback to how they were > before. > > Having neither (the default) gives a kernel that is a kind of hybrid. > > The Hybrid state is what will go forward as 'NON-VIMAGE' mode > and the VIMAGE_GLOBALS mode will probably go away in time as > it complicates the code. > > The aim of this mail is to ask people to try add the VIMAGE option > to their regular kernels and try use them as you woudl normally. > You will not yet be able to use any new VIMAGE features but we > should be fully compatible with previous kernels. > > Please report any concerns to the freebsd-virtualization@ mailing list. > > THEORETICALLY you should not see any changes in behaviour, however we have > the following issues: > > * SCTP is not fully converted yet. add 'nooptions SCTP' for now if you > are not using it yet. > > * An NFS (crash) issue was reported. This MAY have been fixed... > > > Theory tells us that all three kernel options should behave about the same > but if you do try this, and have any benchmarking facilities, > it would be incredibly useful if you could let us know if you see any > performance changes between the three. > > > thanks, > > Julian (currently running a VIMAGE kernel myself) I am ignorant. What is this VIMAGE? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From onemda at gmail.com Mon May 4 12:53:50 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon May 4 12:53:57 2009 Subject: VIMAGE status In-Reply-To: <49FC812B.2070305@elischer.org> References: <49FC812B.2070305@elischer.org> Message-ID: <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> On 5/2/09, Julian Elischer wrote: > The VIMAGE code is nearly all in the the kernel. > > One is now able to make VIMAGE kernels (add options VIMAGE) > though they don't actually allow you to make multiple > vimages instances yet.. > > The VIMAGE option enables all the low level changes needed > throughout the kernel. > > The VIMAGE_GLOBALS option basically sets thing sback to how they were > before. > > Having neither (the default) gives a kernel that is a kind of hybrid. > > The Hybrid state is what will go forward as 'NON-VIMAGE' mode > and the VIMAGE_GLOBALS mode will probably go away in time as > it complicates the code. > > The aim of this mail is to ask people to try add the VIMAGE option > to their regular kernels and try use them as you woudl normally. > You will not yet be able to use any new VIMAGE features but we > should be fully compatible with previous kernels. > > Please report any concerns to the freebsd-virtualization@ mailing list. > > THEORETICALLY you should not see any changes in behaviour, however we > have the following issues: > > * SCTP is not fully converted yet. add 'nooptions SCTP' for now if you > are not using it yet. > > * An NFS (crash) issue was reported. This MAY have been fixed... > > > Theory tells us that all three kernel options should behave about the > same but if you do try this, and have any benchmarking facilities, > it would be incredibly useful if you could let us know if you see any > performance changes between the three. I'm experiencing strange 'netstat -r' output, perhaps I need to clean /usr/obj/? (I dont have VIMAGE enabled) -- Paul From gaijin.k at gmail.com Mon May 4 13:12:27 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Mon May 4 13:12:34 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <1241438990.1280.6.camel@RabbitsDen> On Mon, 2009-05-04 at 01:18 +0300, Alexander Motin wrote: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. > > Modern systems, especially laptops, are implementing big number of > power-saving technologies. Some of them are working automatically, other > have significant requirements and need special system tuning or > trade-offs to be effectively used. > > So here is the steps: > > 1. CPU > CPU is the most consuming part of the system. Under the full load it > alone may consume more then 40W of power, but for real laptop usage the > most important is idle consumption. > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: > P-states and throttling > Enabling powerd allows to effectively control CPU frequency/voltage > depending on CPU load. powerd on recent system can handle it quite > transparently. By default, frequency controlled via mix of EIST and > throttling technologies. First one controls both core frequency and > voltage, second - only core frequency. Both technologies give positive > power-saving effect. But effect of throttling is small and can be > completely hidden by using C2 state, that's why I recommend to disable > throttling control by adding to /boot/loader.conf: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > In my case frequency/voltage control saves about 5W of idle power. > C-states > - C1 stops clock on some parts of CPU core during inactivity. It is > safe, cheap and supported by CPUs for ages. System uses C1 state by default. > - C2 state allows CPU to turn off all core clocks on idle. It is also > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > Use of C2 state can be enabled by adding to /etc/rc.conf: > performance_cx_lowest="C2" > economy_cx_lowest="C2" > Effect from this state is not so big when powerd is used, but still > noticeable, > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but it is not cheap and require trade-offs. > As soon as CPU is completely stopped in C3 state, local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. It stops system time, breaks scheduling that makes system > close to dead. Did you try to see whether putting one of the cores in C3 state by doing something like dev.cpu.1.cx_lowest=C3 makes any difference? # sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% dev.cpu.1.cx_usage: 0.00% 5.18% 94.81% -- Alexandre Kovalenko (????????? ?????????) From jamie at FreeBSD.org Mon May 4 13:17:59 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Mon May 4 13:18:45 2009 Subject: New jail framework - the userland side In-Reply-To: <4424.1241418320@critter.freebsd.dk> References: <4424.1241418320@critter.freebsd.dk> Message-ID: <49FEEB03.7060908@FreeBSD.org> Poul-Henning Kamp wrote: > In message <49FE5387.3020503@FreeBSD.org>, Jamie Gritton writes: > >> Hi all. I recently added some new jail-related system calls to extend >> the current jail system with an nmount-inspired name=value interface. > > I think this is a great move in the right direction, my only concern is > that we should try to share as much of the string-munging code between > the nmount and jail implementations as possible. Most if it is shared - jail actually calls vfs_getopt and related calls from the family. I might want to spin those functions off into their own subsystem at some point, now that they're officially used outside of VFS. I did have to extend things somewhat for jail_get, as nmount is write- only and only had to deal with one module at a time (the filesystem type). Those extensions are available for use elsewhere, as I suspect filesystems and jails aren't the only place where we could use name- based extensibility. - Jamie From quakelee at geekcn.org Mon May 4 13:31:05 2009 From: quakelee at geekcn.org (Chao Shin) Date: Mon May 4 13:31:12 2009 Subject: current couldn't attach usb mouse In-Reply-To: <200905041238.30304.hselasky@c2i.net> References: <200905041238.30304.hselasky@c2i.net> Message-ID: ? Mon, 04 May 2009 18:38:29 +0800?Hans Petter Selasky ??: here it is, [root@currentpark] ~# cat /var/run/dmesg.boot 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 #1: Mon May 4 18:14:47 CST 2009 root@currentpark.intra.umessage.com.cn:/usr/obj/usr/src/sys/UMESSAGE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1795.51-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 1012514816 (965 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f00000 (3) failed acpi0: reservation of 1000000, 3e5ffc00 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xecb8-0xecbf mem 0xfea00000-0xfeafffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M vgapci1: mem 0xfeb00000-0xfebfffff at device 2.1 on pci0 uhci0: port 0xff20-0xff3f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f10 usbus0: on uhci0 uhci1: port 0xff00-0xff1f irq 17 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f10 usbus1: on uhci1 ehci0: mem 0xfe9fbc00-0xfe9fbfff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: waiting for BIOS to give up control usbus2: EHCI version 1.0 usbus2: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.4 on pci0 pci3: on pcib3 bge0: mem 0xfe6f0000-0xfe6fffff irq 16 at device 0.0 on pci3 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:1a:a0:e1:31:eb bge0: [ITHREAD] uhci2: port 0xff80-0xff9f irq 23 at device 29.0 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0000 usbus3: on uhci2 uhci3: port 0xff60-0xff7f irq 17 at device 29.1 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0000 usbus4: on uhci3 uhci4: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x0000 usbus5: on uhci4 ehci1: mem 0xff980800-0xff980bff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfec0-0xfecf,0xecc0-0xeccf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xfe40-0xfe47,0xfe50-0xfe53,0xfe60-0xfe67,0xfe70-0xfe73,0xfed0-0xfedf,0xecd0-0xecdf irq 20 at device 31.5 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atrtc0: port 0x70-0x7f irq 8 on acpi0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 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 928092806000928 device_attach: est1 attach returned 6 p4tcc1: on cpu1 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xccfff,0xcd000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 uhci_interrupt: host controller process error usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 uhci_interrupt: host system error usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ad0: 152587MB at ata0-master SATA300 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 GEOM: ad0: geometry does not match label (255h,63s != 16h,63s). GEOM_LABEL: Label for provider ad0a is ufsid/49f98454ff52b98f. GEOM_LABEL: Label for provider ad0a is ufs/root. GEOM_LABEL: Label for provider ad0d is ufsid/49f9845b4cbc1341. GEOM_LABEL: Label for provider ad0d is ufs/var. GEOM_LABEL: Label for provider ad0e is ufsid/49f98455b2c7e9e5. GEOM_LABEL: Label for provider ad0e is ufs/tmp. GEOM_LABEL: Label for provider ad0f is ufsid/49f9845405ff03de. GEOM_LABEL: Label for provider ad0f is ufs/home. GEOM_LABEL: Label for provider ad0g is ufsid/49f98456bbb9c493. GEOM_LABEL: Label for provider ad0g is ufs/usr. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub6: 6 ports with 6 removable, self powered uhci_interrupt: host system error acd0: DVDROM at ata1-master SATA150 lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! Root mount waiting for: usbus6 Trying to mount root from ufs:/dev/ufs/root uhci_interrupt: host system error GEOM_LABEL: Label ufsid/49f98454ff52b98f removed. GEOM_LABEL: Label ufsid/49f9845405ff03de removed. GEOM_LABEL: Label ufsid/49f98455b2c7e9e5 removed. GEOM_LABEL: Label fs id/49f98456bb c 493 removed. GEOM_LABEL: Label ufsid/49f9845b4cbc1341 removed. usb2_alloc_device:1574: set address 2 failed (USB_ERR_TIMEOUT, ignored) ugen4.2: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 usb2_alloc_device:1612: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > On Monday 04 May 2009, Chao Shin wrote: >> Hi, all >> >> I have a dell optiplex 745 box with a dell usb mouse. I update system >> from >> 7.1 to current today, >> after that the usb mouse could not recongnize. I got some message from >> dmesg like below: >> > >> >> Is this a usb2.0's bug or I should configure something else? > > Can you send complete dmesg ? > > --HPS > _______________________________________________ > 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" -- The Power to Serve From odhiambo at gmail.com Mon May 4 13:38:52 2009 From: odhiambo at gmail.com (=?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?=) Date: Mon May 4 13:38:59 2009 Subject: VIMAGE status In-Reply-To: <991123400905040512s196ec51o3a084b9e1fc8a0e1@mail.gmail.com> References: <49FC812B.2070305@elischer.org> <991123400905040512s196ec51o3a084b9e1fc8a0e1@mail.gmail.com> Message-ID: <991123400905040638v24070cb9rc067d5efab67010@mail.gmail.com> 2009/5/4 Odhiambo ????? > > > On Sat, May 2, 2009 at 8:21 PM, Julian Elischer wrote: > >> The VIMAGE code is nearly all in the the kernel. >> >> One is now able to make VIMAGE kernels (add options VIMAGE) >> though they don't actually allow you to make multiple >> vimages instances yet.. >> >> The VIMAGE option enables all the low level changes needed >> throughout the kernel. >> >> The VIMAGE_GLOBALS option basically sets thing sback to how they were >> before. >> >> Having neither (the default) gives a kernel that is a kind of hybrid. >> >> The Hybrid state is what will go forward as 'NON-VIMAGE' mode >> and the VIMAGE_GLOBALS mode will probably go away in time as >> it complicates the code. >> >> The aim of this mail is to ask people to try add the VIMAGE option >> to their regular kernels and try use them as you woudl normally. >> You will not yet be able to use any new VIMAGE features but we >> should be fully compatible with previous kernels. >> >> Please report any concerns to the freebsd-virtualization@ mailing list. >> >> THEORETICALLY you should not see any changes in behaviour, however we have >> the following issues: >> >> * SCTP is not fully converted yet. add 'nooptions SCTP' for now if you >> are not using it yet. >> >> * An NFS (crash) issue was reported. This MAY have been fixed... >> >> >> Theory tells us that all three kernel options should behave about the same >> but if you do try this, and have any benchmarking facilities, >> it would be incredibly useful if you could let us know if you see any >> performance changes between the three. >> >> >> thanks, >> >> Julian (currently running a VIMAGE kernel myself) > > > I am ignorant. What is this VIMAGE? > Pardon me for the stupid question. Google has given me the whipping I deserve! -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From hselasky at c2i.net Mon May 4 13:53:46 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon May 4 13:53:53 2009 Subject: current couldn't attach usb mouse In-Reply-To: References: <200905041238.30304.hselasky@c2i.net> Message-ID: <200905041556.18646.hselasky@c2i.net> On Monday 04 May 2009, Chao Shin wrote: > usbus0: 12Mbps Full Speed USB v1.0 > uhci_interrupt: host controller process error Hi, It appears your USB Host Controller Hardware has crashed. Could you boot having the following line in /boot/loader.conf: hw.usb2.uhci.debug=15 And send new dmesg. Patch you can try in the meanwhile: Edit /sys/dev/usb/controller/usb_controller.c: - usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, - dmat, &bus->bus_mtx, NULL, 32, USB_BUS_DMA_TAG_MAX); + usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, + dmat, &bus->bus_mtx, NULL, 30, USB_BUS_DMA_TAG_MAX); This will reduce the DMA bits to 30. --HPS From quakelee at geekcn.org Mon May 4 14:03:49 2009 From: quakelee at geekcn.org (Chao Shin) Date: Mon May 4 14:03:55 2009 Subject: current couldn't attach usb mouse In-Reply-To: <200905041556.18646.hselasky@c2i.net> References: <200905041238.30304.hselasky@c2i.net> <200905041556.18646.hselasky@c2i.net> Message-ID: > On Monday 04 May 2009, Chao Shin wrote: >> usbus0: 12Mbps Full Speed USB v1.0 >> uhci_interrupt: host controller process error > > Hi, > > It appears your USB Host Controller Hardware has crashed. > > Could you boot having the following line in /boot/loader.conf: > > hw.usb2.uhci.debug=15 > > And send new dmesg. > Thank you for your reply, I will get it tomorrow and send it to you. > > > Patch you can try in the meanwhile: > > Edit /sys/dev/usb/controller/usb_controller.c: > > - usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, > - dmat, &bus->bus_mtx, NULL, 32, USB_BUS_DMA_TAG_MAX); > > + usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, > + dmat, &bus->bus_mtx, NULL, 30, USB_BUS_DMA_TAG_MAX); > > This will reduce the DMA bits to 30. I will try this patch, thank you > > --HPS > > > _______________________________________________ > 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" -- The Power to Serve From zec at icir.org Mon May 4 14:45:16 2009 From: zec at icir.org (Marko Zec) Date: Mon May 4 14:45:24 2009 Subject: VIMAGE status In-Reply-To: <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> References: <49FC812B.2070305@elischer.org> <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> Message-ID: <200905041015.15332.zec@icir.org> On Monday 04 May 2009 08:53:48 Paul B. Mahol wrote: ... > I'm experiencing strange 'netstat -r' output, perhaps I need to clean > /usr/obj/? (I dont have VIMAGE enabled) You should rebuild your userland regardless whether options VIMAGE in the kernel has been enabled or not, see the UPDATING note for details. Marko From onemda at gmail.com Mon May 4 14:57:34 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon May 4 14:57:41 2009 Subject: VIMAGE status In-Reply-To: <200905041015.15332.zec@icir.org> References: <49FC812B.2070305@elischer.org> <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> <200905041015.15332.zec@icir.org> Message-ID: <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> On 5/4/09, Marko Zec wrote: > On Monday 04 May 2009 08:53:48 Paul B. Mahol wrote: > ... >> I'm experiencing strange 'netstat -r' output, perhaps I need to clean >> /usr/obj/? (I dont have VIMAGE enabled) > > You should rebuild your userland regardless whether options VIMAGE in the > kernel has been enabled or not, see the UPDATING note for details. I did, but I will ask again do I need to clean /usr/obj/? -- Paul From oberman at es.net Mon May 4 15:10:02 2009 From: oberman at es.net (Kevin Oberman) Date: Mon May 4 15:10:19 2009 Subject: Fighting for the power. In-Reply-To: Your message of "Mon, 04 May 2009 15:24:27 +0300." <49FEDE7B.30804@FreeBSD.org> Message-ID: <20090504150959.67BE91CC50@ptavv.es.net> > Date: Mon, 04 May 2009 15:24:27 +0300 > From: Alexander Motin > Sender: owner-freebsd-mobile@freebsd.org > > Alexandre "Sunny" Kovalenko wrote: > > On Mon, 2009-05-04 at 01:18 +0300, Alexander Motin wrote: > >> - C3 state allows CPU completely stop all internal clocks, reduce > >> voltage and disconnect from system bus. This state gives additional > >> power saving effect, but it is not cheap and require trade-offs. > >> As soon as CPU is completely stopped in C3 state, local APIC timers in > >> each CPU core, used by FreeBSD as event sources on SMP, are not > >> functioning. It stops system time, breaks scheduling that makes system > >> close to dead. > > Did you try to see whether putting one of the cores in C3 state by doing > > something like > > > > dev.cpu.1.cx_lowest=C3 > > > > makes any difference? > > > > # sysctl dev.cpu | grep cx_usage > > dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% > > dev.cpu.1.cx_usage: 0.00% 5.18% 94.81% > > I did. As soon as first CPU core is not in C3 state, second core unable > to enter C3 completely and disconnect from the bus, as cores are sharing > common resources. Such technique allows to avoid LAPIC timer problems, > but I haven't noticed any effect from this on CPU idle power. The only > difference I have noticed was in the case, when first core is busy. C3 > on second idle core then somehow reduces summary consumption a bit. > > In other words, C3 state should be active on both cores simultaneously > to give real effect. It is important to be aware that the presence of USB will keep a system from entering C3. Either build a kernel without USB and load it only whan needed or run 8-CURRENT with the USB2 stack which is purported to fix this problem. (I have no systems running CURRENT, so I can't confirm that USB2 fixes the problem.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From kientzle at freebsd.org Mon May 4 15:11:34 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon May 4 15:11:41 2009 Subject: geom_part In-Reply-To: <3a142e750905040228m7b761be7r872de991c9cd811a@mail.gmail.com> References: <20090503224205.GB1414@hades.panopticon> <3a142e750905040228m7b761be7r872de991c9cd811a@mail.gmail.com> Message-ID: <49FF057B.5000602@freebsd.org> Paul B. Mahol wrote: > On 5/4/09, Dmitry Marakasov wrote: >> >> I've upgraded one of my boxes to current recently and ran into some >> problems with new geom_part. >> >> First, it's impossible to edit bsd label online. >> >> # bsdlabel -e /dev/ad8 >> [edit] >> bsdlabel: Class not found >> re-edit the label? [y]: > > bsdlabel, fdisk and others no longer works correctly, use gpart(8) instead. What are the plans for 8.0? Will bsdlabel and fdisk be fixed? Or removed? Tim From rmacklem at uoguelph.ca Mon May 4 15:26:42 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon May 4 15:26:48 2009 Subject: [HEADSUP]: new nfs subdirs Message-ID: I've just committed three subdirs sys/fs/nfs, sys/fs/nfsclient and sys/fs/nfsserver, for a total of about 45,000 lines of C. Since the build glue is not there yet, the only impact you might experience is a slow "svn update". Hopefully the above doesn't cause you grief, rick From bms at incunabulum.net Mon May 4 15:57:38 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon May 4 15:57:48 2009 Subject: CARP and IPv6 SSM changes -- call for feedback Message-ID: <49FF106D.1060507@incunabulum.net> Hi, Could any CARP users tracking -current let me know if they see any issues with CARP since last week's merge of MLDv2 / SSM in IPv6? Please let me know, I have tried to convert its semantics to the SSM KPI's -- the most intrusive change to carp is to adapt it to how the SSM capable IPv6 stack tracks multicast memberships. This shouldn't impact the functionality of CARP, but if I've missed something, please let me know -- it was a fairly quick refactoring w/o knowing all of the internals of CARP as currently implemented. thanks, BMS From rnoland at FreeBSD.org Mon May 4 16:21:10 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon May 4 16:21:18 2009 Subject: Patch for "device_attach: estX attach returned 6" on half of the cores In-Reply-To: References: <1241418372.78715.1.camel@balrog.2hip.net> <1241419338.78715.8.camel@balrog.2hip.net> Message-ID: <1241453930.1788.10.camel@balrog.2hip.net> On Mon, 2009-05-04 at 15:28 +0400, Eygene Ryabinkin wrote: > Robert, > > Mon, May 04, 2009 at 01:42:18AM -0500, Robert Noland wrote: > > Without this patch, cpu0 does attach correctly. > > On the Intel MB? If yes and you'll be able to to some debugging, > please, try the attached patch and send the output of 'dmesg', > 'sysctl dev.cpu', 'sysctl dev.cpufreq' and 'sysctl dev.est'. Ok, just to publicly state that the Intel board apparently was not attaching to core0. I saw the failure and assumed that it was cpu related and would be the same as the Asus board. Should I still apply this patch? > > > One could check if the patch will help by examining the output of > > > 'apicdump -d' and looking for the Alias () directives for the Processor > > > objects. Here's what I have for my laptop: > > > ----- > > > Scope (_PR) > > > { > > > Processor (P001, 0x01, 0x00000810, 0x06) {} > > > Alias (P001, CPU1) > > > } > > > > > > Scope (_PR) > > > { > > > Processor (P002, 0x02, 0x00000810, 0x06) {} > > > Alias (P002, CPU2) > > > } > > > ----- > > > So in this case we essentially have 4 Processor objects under _PR, > > > but only two objects are real ones and only they should be attached. > > > > > > For the completeness, could you, please, show the output of 'acpidump > > > -dt 2>&1' for both of your machines? > > > > Attached. The Asus does appear to use aliases as you described. > > Then you should have est attached to cpu0/cpu2 and rejected on > cpu1/cpu3, aren't you? The output of 'sysctl dev.cpu', 'sysctl dev.est' > and 'sysctl dev.cpufreq' will be also helpful. Will you be able to try > my original patch on the Asus system? Ok, the patch is applied on the Asus board and it now appears to be working correctly. I've re-enabled powerd now, so we will see how that goes. When it was only attaching to core0 the board would hang at times with powerd enabled. robert. > Thanks! -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090504/41023dac/attachment.pgp From julian at elischer.org Mon May 4 17:32:47 2009 From: julian at elischer.org (Julian Elischer) Date: Mon May 4 17:32:54 2009 Subject: VIMAGE status In-Reply-To: <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> References: <49FC812B.2070305@elischer.org> <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> Message-ID: <49FF26C2.8080202@elischer.org> Paul B. Mahol wrote: > On 5/2/09, Julian Elischer wrote: >> The VIMAGE code is nearly all in the the kernel. >> >> One is now able to make VIMAGE kernels (add options VIMAGE) >> though they don't actually allow you to make multiple >> vimages instances yet.. >> >> The VIMAGE option enables all the low level changes needed >> throughout the kernel. >> >> The VIMAGE_GLOBALS option basically sets thing sback to how they were >> before. >> >> Having neither (the default) gives a kernel that is a kind of hybrid. >> >> The Hybrid state is what will go forward as 'NON-VIMAGE' mode >> and the VIMAGE_GLOBALS mode will probably go away in time as >> it complicates the code. >> >> The aim of this mail is to ask people to try add the VIMAGE option >> to their regular kernels and try use them as you woudl normally. >> You will not yet be able to use any new VIMAGE features but we >> should be fully compatible with previous kernels. >> >> Please report any concerns to the freebsd-virtualization@ mailing list. >> >> THEORETICALLY you should not see any changes in behaviour, however we >> have the following issues: >> >> * SCTP is not fully converted yet. add 'nooptions SCTP' for now if you >> are not using it yet. >> >> * An NFS (crash) issue was reported. This MAY have been fixed... >> >> >> Theory tells us that all three kernel options should behave about the >> same but if you do try this, and have any benchmarking facilities, >> it would be incredibly useful if you could let us know if you see any >> performance changes between the three. > > I'm experiencing strange 'netstat -r' output, perhaps I need to clean > /usr/obj/? (I dont have VIMAGE enabled) thanks if you do not have VIMAGE enabled then there should be no effect for you. I suggest you make sure that your userland and kernel are completely in sync. > From julian at elischer.org Mon May 4 17:34:39 2009 From: julian at elischer.org (Julian Elischer) Date: Mon May 4 17:34:46 2009 Subject: VIMAGE status In-Reply-To: <991123400905040638v24070cb9rc067d5efab67010@mail.gmail.com> References: <49FC812B.2070305@elischer.org> <991123400905040512s196ec51o3a084b9e1fc8a0e1@mail.gmail.com> <991123400905040638v24070cb9rc067d5efab67010@mail.gmail.com> Message-ID: <49FF2732.5090007@elischer.org> Odhiambo ????? wrote: > 2009/5/4 Odhiambo ????? > > > > > I am ignorant. What is this VIMAGE? > > > Pardon me for the stupid question. Google has given me the whipping I > deserve! > yes and a good one too I hope! :-) From julian at elischer.org Mon May 4 17:36:05 2009 From: julian at elischer.org (Julian Elischer) Date: Mon May 4 17:36:13 2009 Subject: VIMAGE status In-Reply-To: <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> References: <49FC812B.2070305@elischer.org> <3a142e750905040553p48f6384aseb48c2067463ada4@mail.gmail.com> <200905041015.15332.zec@icir.org> <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> Message-ID: <49FF2787.2060804@elischer.org> Paul B. Mahol wrote: > On 5/4/09, Marko Zec wrote: >> On Monday 04 May 2009 08:53:48 Paul B. Mahol wrote: >> ... >>> I'm experiencing strange 'netstat -r' output, perhaps I need to clean >>> /usr/obj/? (I dont have VIMAGE enabled) >> You should rebuild your userland regardless whether options VIMAGE in the >> kernel has been enabled or not, see the UPDATING note for details. > > I did, but I will ask again do I need to clean /usr/obj/? THEORETICALLY not, but it can't hurt. From sullrich at gmail.com Mon May 4 18:02:01 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Mon May 4 18:02:08 2009 Subject: geom_part In-Reply-To: <49FF057B.5000602@freebsd.org> References: <20090503224205.GB1414@hades.panopticon> <3a142e750905040228m7b761be7r872de991c9cd811a@mail.gmail.com> <49FF057B.5000602@freebsd.org> Message-ID: On Mon, May 4, 2009 at 11:10 AM, Tim Kientzle wrote: > What are the plans for 8.0? ?Will bsdlabel and fdisk > be fixed? ?Or removed? fdisk and bsdlabel are working fine as of a few days ago. We use both inside the BSDInstaller which still works OK. Paul, what exactly is broken? Scott From jkim at FreeBSD.org Mon May 4 18:08:09 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Mon May 4 18:08:17 2009 Subject: cannot compile sched_ule without options SMP In-Reply-To: References: <20090430013428.cb4f804b.nork@FreeBSD.org> <200905011610.42613.jkim@FreeBSD.org> Message-ID: <200905041407.56204.jkim@FreeBSD.org> On Saturday 02 May 2009 03:50 am, pluknet wrote: > 2009/5/2 Jung-uk Kim : > > On Thursday 30 April 2009 11:04 pm, pluknet wrote: > >> 2009/5/1 pluknet : > >> > 2009/5/1 Jeff Roberson : > >> >> On Thu, 30 Apr 2009, pluknet wrote: > >> >>> 2009/4/30 Jeff Roberson : > >> >>>> On SMP machines you should now see output like this: > >> >>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > >> >>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads > >> >>>> > >> >>>> If you detect any irregularities with > >> >>>> kern.sched.topology_spec or this dmesg > >> >>>> line please report them. > >> >>> > >> >>> Hi, Jeff. > >> >>> > >> >>> I have such mismatch. This is an Intel E7200. > >> >>> > >> >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > >> >>> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads > >> >>> cpu0 (BSP): APIC ID: 0 > >> >>> cpu1 (AP/HT): APIC ID: 1 > >> >>> > >> >>> So it should be instead: 1 package(s) x 2 core(s) > >> >>> cpu0 (BSP): APIC ID: 0 > >> >>> cpu1 (AP): APIC ID: 1 > >> >> > >> >> Can you please repeat the following steps as I have done > >> >> here: > >> > > >> > (kgdb) p/x cpu_high > >> > $1 = 0x2 > >> > (kgdb) p/x cpu_cores > >> > $2 = 0x1 > >> > (kgdb) p/x cpu_logical > >> > $3 = 0x2 > >> > (kgdb) p/x cpu_feature > >> > $4 = 0xbfebfbff > >> > (kgdb) p/x logical_cpus > >> > $5 = 0x2 > >> > (kgdb) p/x hyperthreading_cpus > >> > $6 = 0x2 > >> > >> Follow up myself: > >> > >> What is embarrassing me is HTT feature enabled. May the reason > >> be in a buggy CPUID ? > > > > No, the flag does not mean it supports Hyperthreading. It means > > more than one logical core is supported (multi-threading) > > although the name didn't change for historical reason. ;-) > > I see now. > > > Can you try the attached patch? > > Nice, it works! Committed slightly different version. http://svn.freebsd.org/viewvc/base?view=revision&revision=191788 Thanks! Jung-uk Kim From shuvaev at physik.uni-wuerzburg.de Mon May 4 18:40:31 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Mon May 4 18:40:38 2009 Subject: intel graphics loosing msi interrupt on subsequent starts Message-ID: <20090504184027.GA19125@wep4035.physik.uni-wuerzburg.de> Hello all! Sorry if it is already reported... I have recently upgaded X server from 1.4 to 1.6 (ports from ~23.01.2009 -> 03.05.2009). On the first start everything works ok (including [glx]gears). On the second and subsequent starts everything looks working but jerky, I need to move mouse around to get some windows redrawn, [glx]gears print warning message about not getting vblank interrupts and outputs something about 1-2 frames per 5 seconds. The inspectation with vmstat -i has shown that the card generates interrupts only during the first start of X server. If I set hw.pci.enable_msi="0" everything is working fine (start X server multiple times, switch consoles, [glx]gears, number of irq16-s is increasing, ...). I can't be sure it is only due to X upgrade, I have upgraded the base system also (~2 weeks old CURRENT -> 03.05.2009). Some quick to gather system details: ~> uname -a FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun May 3 03:04:41 CEST 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 (4 GB of RAM, Core2Duo, if it matters) >From pciconf -lv: vgapci0@pci0:0:2:0: class=0x030000 card=0x82761043 chip=0x29c28086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '(Bearlake) Integrated Graphics Controller' class = display subclass = VGA >From dmesg with hw.pci.enable_msi="0": vgapci0: port 0xbc00-0xbc07 mem 0xfe980000-0xfe9fffff,0xd0000000-0xdfffffff,0xfe800000-0xfe8fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7164k stolen memory agp0: aperture size is 256M drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 >From dmesg with default settings: vgapci0: port 0xbc00-0xbc07 mem 0xfe980000-0xfe9fffff,0xd0000000-0xdfffffff,0xfe800000-0xfe8fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7164k stolen memory agp0: aperture size is 256M drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 Thanks, Alexey. From lwindschuh at googlemail.com Mon May 4 18:40:42 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Mon May 4 18:41:21 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> 2009/5/4 Alexander Motin : > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. First, thank you for your report about power saving on current laptops. :-) > 1. CPU > [...] > ?- C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but it is not cheap and require trade-offs. > As soon as CPU is completely stopped in C3 state, local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. It stops system time, breaks scheduling that makes system > close to dead. The only solution for this problem is to use some > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > resurrect them for SMP systems. To use them, you can disable local APIC > timers by adding to /boot/loader.conf: > hint.apic.0.clock=0 I tried this on CURRENT@r191784 (i386) on a Thinkpad T400 (Intel(R) Core(TM)2 Duo CPU T9400) with INVARIANTS, etc. enabled. The result was a panic shortly before /sbin/init is called: panic: lapic1: zero divisor So, the KASSERT in sys/i386/local_apic.c:325 fired: KASSERT(lapic_timer_period != 0, ("lapic%u: zero divisor", lapic_id())); Did I forget something? My /boot/loader.conf: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 kern.hz=100 hint.atrtc.0.clock=0 hint.apic.0.clock=0 hint.ata.2.pm_level=2 hint.ata.3.pm_level=3 vm.pmap.pg_ps_enabled=1 dmesg: http://sites.google.com/site/lwfreebsd/Home/files/dmesg-T400-FreeBSD-CURRENT.txt kernel config: http://sites.google.com/site/lwfreebsd/Home/files/kernel-CURRENT.txt Regards Lucius From pluknet at gmail.com Mon May 4 19:03:26 2009 From: pluknet at gmail.com (pluknet) Date: Mon May 4 19:03:34 2009 Subject: cannot compile sched_ule without options SMP In-Reply-To: <200905041407.56204.jkim@FreeBSD.org> References: <20090430013428.cb4f804b.nork@FreeBSD.org> <200905011610.42613.jkim@FreeBSD.org> <200905041407.56204.jkim@FreeBSD.org> Message-ID: 2009/5/4 Jung-uk Kim : > On Saturday 02 May 2009 03:50 am, pluknet wrote: >> 2009/5/2 Jung-uk Kim : >> > On Thursday 30 April 2009 11:04 pm, pluknet wrote: >> >> 2009/5/1 pluknet : >> >> > 2009/5/1 Jeff Roberson : >> >> >> On Thu, 30 Apr 2009, pluknet wrote: >> >> >>> 2009/4/30 Jeff Roberson : >> >> >>>> On SMP machines you should now see output like this: >> >> >>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> >> >>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >> >> >>>> >> >> >>>> If you detect any irregularities with >> >> >>>> kern.sched.topology_spec or this dmesg >> >> >>>> line please report them. >> >> >>> >> >> >>> Hi, Jeff. >> >> >>> >> >> >>> I have such mismatch. This is an Intel E7200. >> >> >>> >> >> >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> >> >>> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads >> >> >>> cpu0 (BSP): APIC ID: 0 >> >> >>> cpu1 (AP/HT): APIC ID: 1 >> >> >>> >> >> >>> So it should be instead: 1 package(s) x 2 core(s) >> >> >>> cpu0 (BSP): APIC ID: 0 >> >> >>> cpu1 (AP): APIC ID: 1 >> >> >> >> >> >> Can you please repeat the following steps as I have done >> >> >> here: >> >> > >> >> > (kgdb) p/x cpu_high >> >> > $1 = 0x2 >> >> > (kgdb) p/x cpu_cores >> >> > $2 = 0x1 >> >> > (kgdb) p/x cpu_logical >> >> > $3 = 0x2 >> >> > (kgdb) p/x cpu_feature >> >> > $4 = 0xbfebfbff >> >> > (kgdb) p/x logical_cpus >> >> > $5 = 0x2 >> >> > (kgdb) p/x hyperthreading_cpus >> >> > $6 = 0x2 >> >> >> >> Follow up myself: >> >> >> >> What is embarrassing me is HTT feature enabled. May the reason >> >> be in a buggy CPUID ? >> > >> > No, the flag does not mean it supports Hyperthreading. It means >> > more than one logical core is supported (multi-threading) >> > although the name didn't change for historical reason. ;-) >> >> I see now. >> >> > Can you try the attached patch? >> >> Nice, it works! > > Committed slightly different version. > > http://svn.freebsd.org/viewvc/base?view=revision&revision=191788 > Thank you! Just checked again on fresh current. P.S. For archives: now topology_spec looks slightly different, according to the change: kern.sched.topology_spec: 0, 1 0, 1 -- wbr, pluknet From rnoland at FreeBSD.org Mon May 4 19:06:04 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon May 4 19:06:11 2009 Subject: intel graphics loosing msi interrupt on subsequent starts In-Reply-To: <20090504184027.GA19125@wep4035.physik.uni-wuerzburg.de> References: <20090504184027.GA19125@wep4035.physik.uni-wuerzburg.de> Message-ID: <1241463941.1788.31.camel@balrog.2hip.net> On Mon, 2009-05-04 at 20:40 +0200, Alexey Shuvaev wrote: > Hello all! > > Sorry if it is already reported... > > I have recently upgaded X server from 1.4 to 1.6 > (ports from ~23.01.2009 -> 03.05.2009). > On the first start everything works ok (including [glx]gears). > On the second and subsequent starts everything looks working but jerky, > I need to move mouse around to get some windows redrawn, > [glx]gears print warning message about not getting vblank interrupts > and outputs something about 1-2 frames per 5 seconds. > > The inspectation with vmstat -i has shown that the card generates > interrupts only during the first start of X server. > > If I set hw.pci.enable_msi="0" everything is working fine (start X server > multiple times, switch consoles, [glx]gears, number of irq16-s > is increasing, ...). irq16 is likely shared, so this may or may not be true... At least in some cases, I was seeing the interrupt handler processing events when some other device on the shared interrupt fired. Interrupts on Intel have been a real pain. There is a drm specific tuneable for disabling msi hw.drm.msi=0. I have a patch which I'm currently using on my g45 that overhauls the way that we handle interrupts. http://people.freebsd.org/~rnoland/drm-intel-050209.patch Reports have been mixed with this, but it is working for me... robert. > I can't be sure it is only due to X upgrade, > I have upgraded the base system also (~2 weeks old CURRENT -> 03.05.2009). > > Some quick to gather system details: > > ~> uname -a > FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun May 3 03:04:41 CEST 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 > (4 GB of RAM, Core2Duo, if it matters) I'm running the same. > >From pciconf -lv: > vgapci0@pci0:0:2:0: class=0x030000 card=0x82761043 chip=0x29c28086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '(Bearlake) Integrated Graphics Controller' > class = display > subclass = VGA > > >From dmesg with hw.pci.enable_msi="0": > vgapci0: port 0xbc00-0xbc07 mem 0xfe980000-0xfe9fffff,0xd0000000-0xdfffffff,0xfe800000-0xfe8fffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: detected 7164k stolen memory > agp0: aperture size is 256M > drm0: on vgapci0 > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] AGP at 0xd0000000 256MB > info: [drm] Initialized i915 1.6.0 20080730 > > >From dmesg with default settings: > vgapci0: port 0xbc00-0xbc07 mem 0xfe980000-0xfe9fffff,0xd0000000-0xdfffffff,0xfe800000-0xfe8fffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: detected 7164k stolen memory > agp0: aperture size is 256M > drm0: on vgapci0 > info: [drm] MSI enabled 1 message(s) > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] AGP at 0xd0000000 256MB > info: [drm] Initialized i915 1.6.0 20080730 > > Thanks, > Alexey. > _______________________________________________ > 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" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090504/4e446e04/attachment.pgp From jhb at freebsd.org Mon May 4 19:22:24 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon May 4 19:22:52 2009 Subject: [not completely SOLVED] acroread8 does not print any more In-Reply-To: <49F4A031.5010500@gwdg.de> References: <49E98C97.9080602@gwdg.de> <91071496@serv3.int.kfs.ru> <49F4A031.5010500@gwdg.de> Message-ID: <200905041055.17812.jhb@freebsd.org> On Sunday 26 April 2009 1:56:01 pm Rainer Hurling wrote: > A few days ago I reported about problems when I try to print from > acroread8. For all but one of my systems the problem is solved now, see > below. > > On one system I also totally cleaned up the linux emulator part and > installed everything from the scratch. Now when I try to print I get the > following message: > > --------------------------------------------------------------- > Beim Drucken ist folgender Fehler aufgetreten... > '/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version > GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/ > Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not > defined' > --------------------------------------------------------------- > > libc.so.6 is from misc/compat6x. I am not able to detect any relevant > differences between my systems. You need a Linux libc.so.6 in /compat/linux. You need to install an RPM that contains this into /compat/linux (probably called something like 'compat-libc'). Probably it would be nice to have a port for this (or include it in the linux base port) for acroread8 to depend on. I think this is a ports@ issue though. -- John Baldwin From rhurlin at gwdg.de Mon May 4 20:06:02 2009 From: rhurlin at gwdg.de (Rainer Hurling) Date: Mon May 4 20:06:10 2009 Subject: [not completely SOLVED] acroread8 does not print any more In-Reply-To: <200905041055.17812.jhb@freebsd.org> References: <49E98C97.9080602@gwdg.de> <91071496@serv3.int.kfs.ru> <49F4A031.5010500@gwdg.de> <200905041055.17812.jhb@freebsd.org> Message-ID: <49FF4A99.30605@gwdg.de> John, thank you for answering. On 04.05.2009 16:55 (UTC+2), John Baldwin wrote: > On Sunday 26 April 2009 1:56:01 pm Rainer Hurling wrote: >> A few days ago I reported about problems when I try to print from >> acroread8. For all but one of my systems the problem is solved now, see >> below. >> >> On one system I also totally cleaned up the linux emulator part and >> installed everything from the scratch. Now when I try to print I get the >> following message: >> >> --------------------------------------------------------------- >> Beim Drucken ist folgender Fehler aufgetreten... >> '/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version >> GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/ >> Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not >> defined' >> --------------------------------------------------------------- >> >> libc.so.6 is from misc/compat6x. I am not able to detect any relevant >> differences between my systems. > > You need a Linux libc.so.6 in /compat/linux. You need to install an RPM that > contains this into /compat/linux (probably called something > like 'compat-libc'). Probably it would be nice to have a port for this (or > include it in the linux base port) for acroread8 to depend on. I think this > is a ports@ issue though. > On /compat/linux/lib I have 'libc-2.7.so' and a link 'libc.so.6 -> libc-2.7.so'. #pkg_info -W /compat/linux/lib/libc-2.7.so /compat/linux/lib/libc-2.7.so was installed by package linux_base-f8-8_11 But there is another libc.so.6: #pkg_info -W /usr/local/lib/compat/libc.so.6 /usr/local/lib/compat/libc.so.6 was installed by package compat6x-i386-6.4.604000.200810 I have the CURRENT systems with, as far as I can see, exact the same configuration. On all my other systems printing from acroread8 is ok. Because of that I opened this thread :-( I have no idea where to look next, Rainer From bsam at ipt.ru Mon May 4 20:12:18 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Mon May 4 20:12:25 2009 Subject: [not completely SOLVED] acroread8 does not print any more In-Reply-To: <49FF4A99.30605@gwdg.de> (Rainer Hurling's message of "Mon\, 04 May 2009 22\:05\:45 +0200") References: <49E98C97.9080602@gwdg.de> <91071496@serv3.int.kfs.ru> <49F4A031.5010500@gwdg.de> <200905041055.17812.jhb@freebsd.org> <49FF4A99.30605@gwdg.de> Message-ID: <37287478@h30.sp.ipt.ru> On Mon, 04 May 2009 22:05:45 +0200 Rainer Hurling wrote: > John, thank you for answering. > On 04.05.2009 16:55 (UTC+2), John Baldwin wrote: > > On Sunday 26 April 2009 1:56:01 pm Rainer Hurling wrote: > >> A few days ago I reported about problems when I try to print from > >> acroread8. For all but one of my systems the problem is solved now, > >> see below. > >> > >> On one system I also totally cleaned up the linux emulator part and > >> installed everything from the scratch. Now when I try to print I > >> get the following message: > >> > >> --------------------------------------------------------------- > >> Beim Drucken ist folgender Fehler aufgetreten... > >> '/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version > >> GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/ > >> Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not > >> defined' > >> --------------------------------------------------------------- > >> > >> libc.so.6 is from misc/compat6x. I am not able to detect any > >> relevant differences between my systems. > > > > You need a Linux libc.so.6 in /compat/linux. You need to install an > > RPM that contains this into /compat/linux (probably called something > > like 'compat-libc'). Probably it would be nice to have a port for > > this (or include it in the linux base port) for acroread8 to depend > > on. I think this is a ports@ issue though. > > > On /compat/linux/lib I have 'libc-2.7.so' and a link 'libc.so.6 -> > libc-2.7.so'. > #pkg_info -W /compat/linux/lib/libc-2.7.so > /compat/linux/lib/libc-2.7.so was installed by package linux_base-f8-8_11 > But there is another libc.so.6: > #pkg_info -W /usr/local/lib/compat/libc.so.6 > /usr/local/lib/compat/libc.so.6 was installed by package > compat6x-i386-6.4.604000.200810 > I have the CURRENT systems with, as far as I can see, exact the same > configuration. On all my other systems printing from acroread8 is > ok. Because of that I opened this thread :-( > I have no idea where to look next, Did you compare ktrace/linux_kdump at a system w/o problems and a system with this problem? WBR -- bsam From rhurlin at gwdg.de Mon May 4 20:15:45 2009 From: rhurlin at gwdg.de (Rainer Hurling) Date: Mon May 4 20:15:52 2009 Subject: [not completely SOLVED] acroread8 does not print any more In-Reply-To: <200905041055.17812.jhb@freebsd.org> References: <49E98C97.9080602@gwdg.de> <91071496@serv3.int.kfs.ru> <49F4A031.5010500@gwdg.de> <200905041055.17812.jhb@freebsd.org> Message-ID: <49FF4CE5.3090307@gwdg.de> On 04.05.2009 16:55 (UTC+2), John Baldwin wrote: > On Sunday 26 April 2009 1:56:01 pm Rainer Hurling wrote: >> A few days ago I reported about problems when I try to print from >> acroread8. For all but one of my systems the problem is solved now, see >> below. >> >> On one system I also totally cleaned up the linux emulator part and >> installed everything from the scratch. Now when I try to print I get the >> following message: >> >> --------------------------------------------------------------- >> Beim Drucken ist folgender Fehler aufgetreten... >> '/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version >> GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/ >> Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not >> defined' >> --------------------------------------------------------------- >> >> libc.so.6 is from misc/compat6x. I am not able to detect any relevant >> differences between my systems. > > You need a Linux libc.so.6 in /compat/linux. You need to install an RPM that > contains this into /compat/linux (probably called something > like 'compat-libc'). Probably it would be nice to have a port for this (or > include it in the linux base port) for acroread8 to depend on. I think this > is a ports@ issue though. > I forgot to mention that Boris asked me to change from current@ to emulation@. So the follow up should be on emulation@ :-) Rainer Hurling From rhurlin at gwdg.de Mon May 4 20:20:52 2009 From: rhurlin at gwdg.de (Rainer Hurling) Date: Mon May 4 20:20:59 2009 Subject: [not completely SOLVED] acroread8 does not print any more In-Reply-To: <37287478@h30.sp.ipt.ru> References: <49E98C97.9080602@gwdg.de> <91071496@serv3.int.kfs.ru> <49F4A031.5010500@gwdg.de> <200905041055.17812.jhb@freebsd.org> <49FF4A99.30605@gwdg.de> <37287478@h30.sp.ipt.ru> Message-ID: <49FF4DFA.7050101@gwdg.de> On 04.05.2009 22:12 (UTC+2), Boris Samorodov wrote: > On Mon, 04 May 2009 22:05:45 +0200 Rainer Hurling wrote: > >> John, thank you for answering. > >> On 04.05.2009 16:55 (UTC+2), John Baldwin wrote: >>> On Sunday 26 April 2009 1:56:01 pm Rainer Hurling wrote: >>>> A few days ago I reported about problems when I try to print from >>>> acroread8. For all but one of my systems the problem is solved now, >>>> see below. >>>> >>>> On one system I also totally cleaned up the linux emulator part and >>>> installed everything from the scratch. Now when I try to print I >>>> get the following message: >>>> >>>> --------------------------------------------------------------- >>>> Beim Drucken ist folgender Fehler aufgetreten... >>>> '/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version >>>> GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/ >>>> Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not >>>> defined' >>>> --------------------------------------------------------------- >>>> >>>> libc.so.6 is from misc/compat6x. I am not able to detect any >>>> relevant differences between my systems. >>> You need a Linux libc.so.6 in /compat/linux. You need to install an >>> RPM that contains this into /compat/linux (probably called something >>> like 'compat-libc'). Probably it would be nice to have a port for >>> this (or include it in the linux base port) for acroread8 to depend >>> on. I think this is a ports@ issue though. >>> > >> On /compat/linux/lib I have 'libc-2.7.so' and a link 'libc.so.6 -> >> libc-2.7.so'. > >> #pkg_info -W /compat/linux/lib/libc-2.7.so >> /compat/linux/lib/libc-2.7.so was installed by package linux_base-f8-8_11 > >> But there is another libc.so.6: > >> #pkg_info -W /usr/local/lib/compat/libc.so.6 >> /usr/local/lib/compat/libc.so.6 was installed by package >> compat6x-i386-6.4.604000.200810 > >> I have the CURRENT systems with, as far as I can see, exact the same >> configuration. On all my other systems printing from acroread8 is >> ok. Because of that I opened this thread :-( > >> I have no idea where to look next, > > Did you compare ktrace/linux_kdump at a system w/o problems and > a system with this problem? Yes, I reported about it on emulation@ on May 1st. It was very difficult because the are so many places acroread is looking for or working with 'libc.so.6'. I listed many messages before the error message appears. Please see on emulation@. Rainer Hurling > WBR From onemda at gmail.com Mon May 4 21:08:00 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon May 4 21:08:06 2009 Subject: geom_part In-Reply-To: References: <20090503224205.GB1414@hades.panopticon> <3a142e750905040228m7b761be7r872de991c9cd811a@mail.gmail.com> <49FF057B.5000602@freebsd.org> Message-ID: <3a142e750905041407g30a5d31cj64e7e64e1f428d0d@mail.gmail.com> On 5/4/09, Scott Ullrich wrote: > On Mon, May 4, 2009 at 11:10 AM, Tim Kientzle wrote: >> What are the plans for 8.0? Will bsdlabel and fdisk >> be fixed? Or removed? They are going to be fixed. > fdisk and bsdlabel are working fine as of a few days ago. We use > both inside the BSDInstaller which still works OK. Then both OP and I live in alternate space :-) > Paul, what exactly is broken? -- Paul From alexbestms at math.uni-muenster.de Mon May 4 22:21:03 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Mon May 4 22:21:15 2009 Subject: timeout with pata dvd-drive Message-ID: hi everybody, i'm experiencing this issue for quite some time now. i already filed a PR about it and wrote several mails to various mailinglists without success. :( the problem is that my pata-dvddrive takes forever to access a cdr, because i get a lot of timeouts. booting with a cdr inserted takes > 5 minutes. you can find the PR here: http://www.freebsd.org/cgi/query-pr.cgi?pr=133122 i've attached a verbose dmesg. the problem seems to start in line 1389. right now i'm running r191768M. cheers. alex -------------- next part -------------- A non-text attachment was scrubbed... Name: messages Type: application/octet-stream Size: 114694 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090504/b283b6a0/messages-0001.obj From mav at FreeBSD.org Mon May 4 22:28:53 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 4 22:29:05 2009 Subject: Fighting for the power. In-Reply-To: <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> References: <49FE1826.4060000@FreeBSD.org> <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> Message-ID: <49FF6C11.5030607@FreeBSD.org> Lucius Windschuh wrote: > I tried this on CURRENT@r191784 (i386) on a Thinkpad T400 (Intel(R) > Core(TM)2 Duo CPU T9400) with INVARIANTS, etc. enabled. > The result was a panic shortly before /sbin/init is called: > > panic: lapic1: zero divisor > > So, the KASSERT in sys/i386/local_apic.c:325 fired: > KASSERT(lapic_timer_period != 0, ("lapic%u: zero divisor", > lapic_id())); > > Did I forget something? > > My /boot/loader.conf: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > kern.hz=100 > hint.atrtc.0.clock=0 > hint.apic.0.clock=0 > hint.ata.2.pm_level=2 > hint.ata.3.pm_level=3 > vm.pmap.pg_ps_enabled=1 > > dmesg: http://sites.google.com/site/lwfreebsd/Home/files/dmesg-T400-FreeBSD-CURRENT.txt > kernel config: http://sites.google.com/site/lwfreebsd/Home/files/kernel-CURRENT.txt Sorry, my fault. Try attached patch. -- Alexander Motin -------------- next part -------------- --- local_apic.c.prev 2009-05-01 23:53:37.000000000 +0300 +++ local_apic.c 2009-05-05 01:10:04.000000000 +0300 @@ -319,7 +319,7 @@ lapic_setup(int boot) } /* We don't setup the timer during boot on the BSP until later. */ - if (!(boot && PCPU_GET(cpuid) == 0)) { + if (!(boot && PCPU_GET(cpuid) == 0) && lapic_timer_hz != 0) { KASSERT(lapic_timer_period != 0, ("lapic%u: zero divisor", lapic_id())); lapic_timer_set_divisor(lapic_timer_divisor); From shuvaev at physik.uni-wuerzburg.de Mon May 4 22:32:04 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Mon May 4 22:32:12 2009 Subject: intel graphics loosing msi interrupt on subsequent starts In-Reply-To: <1241463941.1788.31.camel@balrog.2hip.net> References: <20090504184027.GA19125@wep4035.physik.uni-wuerzburg.de> <1241463941.1788.31.camel@balrog.2hip.net> Message-ID: <20090504223148.GA1659@wep4035.physik.uni-wuerzburg.de> On Mon, May 04, 2009 at 02:05:41PM -0500, Robert Noland wrote: > On Mon, 2009-05-04 at 20:40 +0200, Alexey Shuvaev wrote: > > Hello all! > > > > Sorry if it is already reported... > > > > I have recently upgaded X server from 1.4 to 1.6 > > (ports from ~23.01.2009 -> 03.05.2009). > > On the first start everything works ok (including [glx]gears). > > On the second and subsequent starts everything looks working but jerky, > > I need to move mouse around to get some windows redrawn, > > [glx]gears print warning message about not getting vblank interrupts > > and outputs something about 1-2 frames per 5 seconds. > > > > The inspectation with vmstat -i has shown that the card generates > > interrupts only during the first start of X server. > > > > If I set hw.pci.enable_msi="0" everything is working fine (start X server > > multiple times, switch consoles, [glx]gears, number of irq16-s > > is increasing, ...). > > irq16 is likely shared, so this may or may not be true... At least in > some cases, I was seeing the interrupt handler processing events when > some other device on the shared interrupt fired. Interrupts on Intel > have been a real pain. There is a drm specific tuneable for disabling > msi hw.drm.msi=0. I have a patch which I'm currently using on my g45 > that overhauls the way that we handle interrupts. > > http://people.freebsd.org/~rnoland/drm-intel-050209.patch > > Reports have been mixed with this, but it is working for me... > So far works for me too... irq256: vgapci0 7759 21 Thanks! :) Alexey. From jroberson at jroberson.net Mon May 4 22:34:58 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Mon May 4 22:35:10 2009 Subject: [patch] zfs kmem fragmentation In-Reply-To: References: Message-ID: On Sat, 2 May 2009, Ben Kelly wrote: > Hello all, > > Lately I've been looking into the "kmem too small" panics that often occur > with zfs if you don't restrict the arc. What I found in my test environment > was that everything works well until the kmem usage hits the 75% limit set in > arc.c. At this point the arc is shrunk and slabs are reclaimed from uma. > Unfortunately, every time this reclamation process runs the kmem space > becomes more fragmented. The vast majority of the time my machine hits the > "kmem too small" panic it has over 200MB of kmem space available, but the > largest fragment is less than 128KB. What consumers make requests of kmem for 128kb and over? What ultimately trips the panic? > > Ideally things would be arranged to free memory without fragmentation. I > have tried a few things along those lines, but none of them have been > successful so far. I'm going to continue that work, but in the meantime I've > put together a patch that tries to avoid fragmentation by slowing kmem growth > before the aggressive reclamation process is required: > > http://www.wanderview.com/svn/public/misc/zfs/zfs_kmem_limit.diff > > It uses the following heuristics to do this: > > - Start arc_c at arc_c_min instead of arc_c_max. This causes the system to > warm up more slowly. > - Half the rate arc_c grows when kmem exceeds kmem_slow_growth_thresh > - Stop arc_c growth when kmem exceeds kmem_target > - Evict arc data when the kmem exceeds kmem_target > - If kmem usage exceeds kmem_target then ask the pagedaemon to reclaim pages > - If the largest kmem fragment is less than kmem_fragment_target then ask > the pagedaemon to reclaim pages > - If the largest kmem fragment is less than a kmem_fragment_thresh then > force the aggressve kmem/arc reclamation process > > The defaults for the various targets and thresholds are: > > kmem_reclaim_threshold = 7/8 kmem > kmem_target = 3/4 kmem > kmem_slow_growth_threshold = 5/8 kmem > kmem_fragment_target = 1/8 kmem > kmem_fragment_thresh = 1/16 kmem > > With this patch I've been able to run my load tests with the default arc size > with kmem values of 512MB to 700MB. I tried one loaded run with a 300MB > kmem, but it panic'ed due to legitimate, non-fragmented kmem exhaustion. > May I suggest an alternate approach; Have you considered placing zfs in its own kernel submap? If all of its allocations are of a like size, fragmentation won't be an issue and it can be constrained to a fixed size without placing pressure on other kmem_map consumers. This is the approach taken for the buffer cache. It makes a good deal of sense. If arc can be taught to handle allocation failures we could eliminate the panic entirely by simply causing arc to run out of space and flush more buffers. Do you believe this would also address the problem? Thanks, Jeff > Please note that you may still encounter some fragmentation. Its possible > for the system to get stuck in a degraded state where its constantly trying > to free pages and memory in attempt to fix the fragmentation. If the system > is in this state the kstat.zfs.misc.arcstats.fragmented_kmem_count sysctl > will be increasing at a fairly rapid rate. > > Anyway, I just thought I would put this out there in case anyone wanted to > try to test with it. I've mainly been loading it using rsync between two > pools on a non-SMP, i386, with 2GB memory. > > Also, if anyone is interested in helping with the fragmentation problem > please let me know. At this point I think the best odds are to modify UMA to > allow some zones to use a custom slab size of 128KB (max zfs buffer size) so > that most of the allocations from kmem are the same size. It also occurred > to me that much of this mess would be simpler if kmem information were passed > up through the vnode so that the top layer entities like pagedaemon could > make better choices for the overall memory usage of the system. Right now we > have a sub-system two or three layers down making decisions for everyone. > Anyway, suggestions and insights are more than welcome. > > Thanks! > > - Ben > _______________________________________________ > 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 lwindschuh at googlemail.com Mon May 4 23:22:14 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Mon May 4 23:22:21 2009 Subject: Fighting for the power. In-Reply-To: <49FF6C11.5030607@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> <49FF6C11.5030607@FreeBSD.org> Message-ID: <90a5caac0905041622oaddd7cek52f28a9b018b3ea7@mail.gmail.com> 2009/5/5 Alexander Motin : > Lucius Windschuh wrote: >> [...] >> panic: lapic1: zero divisor > [...] > --- local_apic.c.prev ? 2009-05-01 23:53:37.000000000 +0300 > +++ local_apic.c ? ? ? ?2009-05-05 01:10:04.000000000 +0300 > @@ -319,7 +319,7 @@ lapic_setup(int boot) > ? ? ? ?} > > ? ? ? ?/* We don't setup the timer during boot on the BSP until later. */ > - ? ? ? if (!(boot && PCPU_GET(cpuid) == 0)) { > + ? ? ? if (!(boot && PCPU_GET(cpuid) == 0) && lapic_timer_hz != 0) { > ? ? ? ? ? ? ? ?KASSERT(lapic_timer_period != 0, ("lapic%u: zero divisor", > ? ? ? ? ? ? ? ? ? ?lapic_id())); > ? ? ? ? ? ? ? ?lapic_timer_set_divisor(lapic_timer_divisor); This patch solves the panic. C3 instead of C2 saves between 0.5 and 1.5 Watt here with some quick measurements. Thanks. Lucius From matheus at eternamente.info Tue May 5 01:17:52 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Tue May 5 01:18:05 2009 Subject: ata and seagate microdrive problems In-Reply-To: <1239874051.12971.1.camel@buffy.york.ac.uk> References: <00652174bdc7334a1a2d3d8db7c667a7.squirrel@10.1.1.10> <1239874051.12971.1.camel@buffy.york.ac.uk> Message-ID: <9b2ddf7fa0e24199c4d20aae92edbf67.squirrel@10.1.1.10> On Thu, April 16, 2009 06:27, Gavin Atkinson wrote: > On Thu, 2009-04-09 at 19:03 -0300, Nenhum_de_Nos wrote: >> hail, >> >> I'm trying to install current on via itx using ide 44pin to cf adapter >> and >> a seagate 8GB microdrive. >> >> I thought it was to be ok, but just today when I received the adapter I >> got nowhere in this. I tried 7.1-STABLE and 8.0-CURRENT from 200902, and >> both fail to find it. the same thing in 7.1R. > > Can you boot in verbose mode, and post the dmesg somewhere please? they're attached :) just remember the seagate is there, but I'm using and old samsung 6.4GB to boot, using SATA<>IDE adapter and SIL3112 sata controller. > Also, can you confirm which ATA channel the drive should show up on? I'd say first one, as it is in the onboard ide controller. I don't know much more to say, but that OpenBSD sees it as wd0. if any more info needed, just say so. almost forgot: FreeBSD xxx 8.0-HEAD-20090501-JPSNAP FreeBSD 8.0-HEAD-20090501-JPSNAP #0: Fri May 1 04:22:31 UTC 2009 root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386/usr/src/sys/GENERIC i386 thanks, matheus > Thanks, > > Gavin > >> I found this http://forums.freebsd.org/archive/index.php/t-2733.html, >> but >> hw.ata.ata_dma_check_80pin=0 is no good :( >> >> and found this pr >> http://lists.freebsd.org/pipermail/freebsd-bugs/2007-March/022884.html >> as >> the only pr that mentions microdrive (I may be wrong). > > -- We will call you cygnus, The God of balance you shall be -------------- next part -------------- A non-text attachment was scrubbed... Name: pciconv Type: application/octet-stream Size: 2954 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090505/55fd5c15/pciconv.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.verbose Type: application/octet-stream Size: 19385 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090505/55fd5c15/dmesg.obj From quakelee at geekcn.org Tue May 5 06:31:24 2009 From: quakelee at geekcn.org (Chao Shin) Date: Tue May 5 06:31:32 2009 Subject: current couldn't attach usb mouse In-Reply-To: <200905041556.18646.hselasky@c2i.net> References: <200905041238.30304.hselasky@c2i.net> <200905041556.18646.hselasky@c2i.net> Message-ID: Hi Hans, There is new dmesg with debug=15, but I can't catch difference... [root@currentpark] ~# dmesg 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 #4: Tue May 5 00:25:41 CST 2009 root@currentpark.intra.umessage.com.cn:/usr/obj/usr/src/sys/UMESSAGE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1795.51-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 1012195328 (965 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f00000 (3) failed acpi0: reservation of 1000000, 3e5ffc00 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xecb8-0xecbf mem 0xfea00000-0xfeafffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M vgapci1: mem 0xfeb00000-0xfebfffff at device 2.1 on pci0 uhci0: port 0xff20-0xff3f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f10 usbus0: on uhci0 uhci1: port 0xff00-0xff1f irq 17 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f10 usbus1: on uhci1 ehci0: mem 0xfe9fbc00-0xfe9fbfff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: waiting for BIOS to give up control usbus2: EHCI version 1.0 usbus2: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.4 on pci0 pci3: on pcib3 bge0: mem 0xfe6f0000-0xfe6fffff irq 16 at device 0.0 on pci3 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:1a:a0:e1:31:eb bge0: [ITHREAD] uhci2: port 0xff80-0xff9f irq 23 at device 29.0 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0000 usbus3: on uhci2 uhci3: port 0xff60-0xff7f irq 17 at device 29.1 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0000 usbus4: on uhci3 uhci4: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x0000 usbus5: on uhci4 ehci1: mem 0xff980800-0xff980bff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfec0-0xfecf,0xecc0-0xeccf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xfe40-0xfe47,0xfe50-0xfe53,0xfe60-0xfe67,0xfe70-0xfe73,0xfed0-0xfedf,0xecd0-0xecdf irq 20 at device 31.5 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atrtc0: port 0x70-0x7f irq 8 on acpi0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 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 928092806000928 device_attach: est1 attach returned 6 p4tcc1: on cpu1 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xccfff,0xcd000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 uhci_interrupt: host system error usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ad0: 152587MB at ata0-master SATA300 uhci_interrupt: host system error ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 GEOM: ad0: geometry does not match label (255h,63s != 16h,63s). GEOM_LABEL: Label for provider ad0a is ufsid/49f98454ff52b98f. GEOM_LABEL: Label for provider ad0a is ufs/root. GEOM_LABEL: Label for provider ad0d is ufsid/49f9845b4cbc1341. GEOM_LABEL: Label for provider ad0d is ufs/var. GEOM_LABEL: Label for provider ad0e is ufsid/49f98455b2c7e9e5. GEOM_LABEL: Label for provider ad0e is ufs/tmp. GEOM_LABEL: Label for provider ad0f is ufsid/49f9845405ff03de. GEOM_LABEL: Label for provider ad0f is ufs/home. GEOM_LABEL: Label for provider ad0g is ufsid/49f98456bbb9c493. GEOM_LABEL: Label for provider ad0g is ufs/usr. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub6: 6 ports with 6 removable, self powered uhci_interrupt: host system error acd0: DVDROM at ata1-master SATA150 lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! Root mount waiting for: usbus6 Trying to mount root from ufs:/dev/ufs/root uhci_interrupt: host system error GEOM_LABEL: Label ufsid/49f98454ff52b98f removed. GEOM_LABEL: Label ufsid/49f9845405ff03de removed. GEOM_LABEL: Label ufsid/49f98455b2c7e9e5 removed. GEOM_LABEL: Label ufsid/49f984 bb b9c493 removed. GEOM_LABEL: Label ufsid/49f9845b4cbc1341 removed. usb2_alloc_device:1574: set address 2 failed (USB_ERR_TIMEOUT, ignored) ugen4.2: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 usb2_alloc_device:1612: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) bge0: link state changed to UP fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:417: could not allocate new device! [root@currentpark] ~# cat /boot/loader.conf hw.usb2.uhci.debug=15 after I patched your patch, the mouse still couldn't recognize, there is nothing different than before usb2_alloc_device:1574: set address 2 failed (USB_ERR_TIMEOUT, ignored) ugen4.2: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 usb2_alloc_device:1612: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) bge0: link state changed to UP fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_interrupt: host system error usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:417: could not allocate new device! any idea? > On Monday 04 May 2009, Chao Shin wrote: >> usbus0: 12Mbps Full Speed USB v1.0 >> uhci_interrupt: host controller process error > > Hi, > > It appears your USB Host Controller Hardware has crashed. > > Could you boot having the following line in /boot/loader.conf: > > hw.usb2.uhci.debug=15 > > And send new dmesg. > > > > Patch you can try in the meanwhile: > > Edit /sys/dev/usb/controller/usb_controller.c: > > - usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, > - dmat, &bus->bus_mtx, NULL, 32, USB_BUS_DMA_TAG_MAX); > > + usb2_dma_tag_setup(bus->dma_parent_tag, bus->dma_tags, > + dmat, &bus->bus_mtx, NULL, 30, USB_BUS_DMA_TAG_MAX); > > This will reduce the DMA bits to 30. > > --HPS > > > _______________________________________________ > 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" -- The Power to Serve From hselasky at c2i.net Tue May 5 07:17:20 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue May 5 07:17:27 2009 Subject: current couldn't attach usb mouse In-Reply-To: References: <200905041556.18646.hselasky@c2i.net> Message-ID: <200905050919.51551.hselasky@c2i.net> On Tuesday 05 May 2009, Chao Shin wrote: > Hi Hans, > There is new dmesg with debug=15, but I can't catch difference... > If you type: ll /boot/kernel Do all the modules have the same date? There is a fuse4bsd module there which I suspect is out of date. --HPS From quakelee at geekcn.org Tue May 5 07:26:20 2009 From: quakelee at geekcn.org (Chao Shin) Date: Tue May 5 07:26:31 2009 Subject: current couldn't attach usb mouse In-Reply-To: <200905050919.51551.hselasky@c2i.net> References: <200905041556.18646.hselasky@c2i.net> <200905050919.51551.hselasky@c2i.net> Message-ID: Hi Hans, There is my modules' list as your guess, the fuse.ko is out of date, but is it can cause mouse defunction? I'll try to unload it. [root@currentpark] /usr/local/etc/rc.d# ll /usr/local/modules/fuse.ko -r-xr-xr-x 1 root wheel 83208 May 1 04:19 /usr/local/modules/fuse.ko* [root@currentpark] /usr/local/etc/rc.d# ll /boot/kernel/ total 159208 drwxr-xr-x 2 root wheel 27136 May 5 14:24 ./ drwxr-xr-x 9 root wheel 1024 May 5 14:24 ../ -r-xr-xr-x 1 root wheel 174856 May 5 14:24 aac.ko* -r-xr-xr-x 1 root wheel 134424 May 5 14:24 aac.ko.symbols* -r-xr-xr-x 1 root wheel 8744 May 5 14:24 accf_data.ko* -r-xr-xr-x 1 root wheel 8480 May 5 14:24 accf_data.ko.symbols* -r-xr-xr-x 1 root wheel 9976 May 5 14:24 accf_dns.ko* -r-xr-xr-x 1 root wheel 9552 May 5 14:24 accf_dns.ko.symbols* -r-xr-xr-x 1 root wheel 13712 May 5 14:24 accf_http.ko* -r-xr-xr-x 1 root wheel 11808 May 5 14:24 accf_http.ko.symbols* -r-xr-xr-x 1 root wheel 18520 May 5 14:24 acpi_aiboost.ko* -r-xr-xr-x 1 root wheel 15328 May 5 14:24 acpi_aiboost.ko.symbols* -r-xr-xr-x 1 root wheel 44912 May 5 14:24 acpi_asus.ko* -r-xr-xr-x 1 root wheel 30408 May 5 14:24 acpi_asus.ko.symbols* -r-xr-xr-x 1 root wheel 24144 May 5 14:24 acpi_dock.ko* -r-xr-xr-x 1 root wheel 19784 May 5 14:24 acpi_dock.ko.symbols* -r-xr-xr-x 1 root wheel 24080 May 5 14:24 acpi_fujitsu.ko* -r-xr-xr-x 1 root wheel 19408 May 5 14:24 acpi_fujitsu.ko.symbols* -r-xr-xr-x 1 root wheel 30904 May 5 14:24 acpi_ibm.ko* -r-xr-xr-x 1 root wheel 23456 May 5 14:24 acpi_ibm.ko.symbols* -r-xr-xr-x 1 root wheel 21928 May 5 14:24 acpi_panasonic.ko* -r-xr-xr-x 1 root wheel 18536 May 5 14:24 acpi_panasonic.ko.symbols* -r-xr-xr-x 1 root wheel 13216 May 5 14:24 acpi_sony.ko* -r-xr-xr-x 1 root wheel 11576 May 5 14:24 acpi_sony.ko.symbols* -r-xr-xr-x 1 root wheel 24472 May 5 14:24 acpi_toshiba.ko* -r-xr-xr-x 1 root wheel 20216 May 5 14:24 acpi_toshiba.ko.symbols* -r-xr-xr-x 1 root wheel 32984 May 5 14:24 acpi_video.ko* -r-xr-xr-x 1 root wheel 25152 May 5 14:24 acpi_video.ko.symbols* -r-xr-xr-x 1 root wheel 116544 May 5 14:24 agp.ko* -r-xr-xr-x 1 root wheel 86104 May 5 14:24 agp.ko.symbols* -r-xr-xr-x 1 root wheel 63080 May 5 14:24 aha.ko* -r-xr-xr-x 1 root wheel 46264 May 5 14:24 aha.ko.symbols* -r-xr-xr-x 1 root wheel 288808 May 5 14:24 ahc.ko* -r-xr-xr-x 1 root wheel 174232 May 5 14:24 ahc.ko.symbols* -r-xr-xr-x 1 root wheel 32136 May 5 14:24 ahc_eisa.ko* -r-xr-xr-x 1 root wheel 30328 May 5 14:24 ahc_eisa.ko.symbols* -r-xr-xr-x 1 root wheel 33408 May 5 14:24 ahc_isa.ko* -r-xr-xr-x 1 root wheel 31160 May 5 14:24 ahc_isa.ko.symbols* -r-xr-xr-x 1 root wheel 94216 May 5 14:24 ahc_pci.ko* -r-xr-xr-x 1 root wheel 68952 May 5 14:24 ahc_pci.ko.symbols* -r-xr-xr-x 1 root wheel 427168 May 5 14:24 ahd.ko* -r-xr-xr-x 1 root wheel 240920 May 5 14:24 ahd.ko.symbols* -r-xr-xr-x 1 root wheel 134064 May 5 14:24 aio.ko* -r-xr-xr-x 1 root wheel 104616 May 5 14:24 aio.ko.symbols* -r-xr-xr-x 1 root wheel 12168 May 5 14:24 alias_cuseeme.ko* -r-xr-xr-x 1 root wheel 11360 May 5 14:24 alias_cuseeme.ko.symbols* -r-xr-xr-x 1 root wheel 11152 May 5 14:24 alias_dummy.ko* -r-xr-xr-x 1 root wheel 10704 May 5 14:24 alias_dummy.ko.symbols* -r-xr-xr-x 1 root wheel 17048 May 5 14:24 alias_ftp.ko* -r-xr-xr-x 1 root wheel 13776 May 5 14:24 alias_ftp.ko.symbols* -r-xr-xr-x 1 root wheel 14264 May 5 14:24 alias_irc.ko* -r-xr-xr-x 1 root wheel 12112 May 5 14:24 alias_irc.ko.symbols* -r-xr-xr-x 1 root wheel 16064 May 5 14:24 alias_nbt.ko* -r-xr-xr-x 1 root wheel 13320 May 5 14:24 alias_nbt.ko.symbols* -r-xr-xr-x 1 root wheel 15040 May 5 14:24 alias_pptp.ko* -r-xr-xr-x 1 root wheel 13192 May 5 14:24 alias_pptp.ko.symbols* -r-xr-xr-x 1 root wheel 12792 May 5 14:24 alias_skinny.ko* -r-xr-xr-x 1 root wheel 11800 May 5 14:24 alias_skinny.ko.symbols* -r-xr-xr-x 1 root wheel 16120 May 5 14:24 alias_smedia.ko* -r-xr-xr-x 1 root wheel 13088 May 5 14:24 alias_smedia.ko.symbols* -r-xr-xr-x 1 root wheel 22472 May 5 14:24 alpm.ko* -r-xr-xr-x 1 root wheel 16760 May 5 14:24 alpm.ko.symbols* -r-xr-xr-x 1 root wheel 22400 May 5 14:24 amdpm.ko* -r-xr-xr-x 1 root wheel 16520 May 5 14:24 amdpm.ko.symbols* -r-xr-xr-x 1 root wheel 20960 May 5 14:24 amdsmb.ko* -r-xr-xr-x 1 root wheel 16128 May 5 14:24 amdsmb.ko.symbols* -r-xr-xr-x 1 root wheel 16856 May 5 14:24 amdtemp.ko* -r-xr-xr-x 1 root wheel 14040 May 5 14:24 amdtemp.ko.symbols* -r-xr-xr-x 1 root wheel 104712 May 5 14:24 amr.ko* -r-xr-xr-x 1 root wheel 82120 May 5 14:24 amr.ko.symbols* -r-xr-xr-x 1 root wheel 32744 May 5 14:24 amr_cam.ko* -r-xr-xr-x 1 root wheel 29672 May 5 14:24 amr_cam.ko.symbols* -r-xr-xr-x 1 root wheel 19408 May 5 14:24 amr_linux.ko* -r-xr-xr-x 1 root wheel 19008 May 5 14:24 amr_linux.ko.symbols* -r-xr-xr-x 1 root wheel 70832 May 5 14:24 arcmsr.ko* -r-xr-xr-x 1 root wheel 49904 May 5 14:24 arcmsr.ko.symbols* -r-xr-xr-x 1 root wheel 47952 May 5 14:24 asmc.ko* -r-xr-xr-x 1 root wheel 28192 May 5 14:24 asmc.ko.symbols* -r-xr-xr-x 1 root wheel 121264 May 5 14:24 ata.ko* -r-xr-xr-x 1 root wheel 86400 May 5 14:24 ata.ko.symbols* -r-xr-xr-x 1 root wheel 25296 May 5 14:24 ataacard.ko* -r-xr-xr-x 1 root wheel 21520 May 5 14:24 ataacard.ko.symbols* -r-xr-xr-x 1 root wheel 27712 May 5 14:24 ataacerlabs.ko* -r-xr-xr-x 1 root wheel 22848 May 5 14:24 ataacerlabs.ko.symbols* -r-xr-xr-x 1 root wheel 13544 May 5 14:24 ataadaptec.ko* -r-xr-xr-x 1 root wheel 12552 May 5 14:24 ataadaptec.ko.symbols* -r-xr-xr-x 1 root wheel 33808 May 5 14:24 ataahci.ko* -r-xr-xr-x 1 root wheel 24272 May 5 14:24 ataahci.ko.symbols* -r-xr-xr-x 1 root wheel 21976 May 5 14:24 ataamd.ko* -r-xr-xr-x 1 root wheel 19512 May 5 14:24 ataamd.ko.symbols* -r-xr-xr-x 1 root wheel 29408 May 5 14:24 ataati.ko* -r-xr-xr-x 1 root wheel 24824 May 5 14:24 ataati.ko.symbols* -r-xr-xr-x 1 root wheel 14896 May 5 14:24 atacard.ko* -r-xr-xr-x 1 root wheel 13184 May 5 14:24 atacard.ko.symbols* -r-xr-xr-x 1 root wheel 16024 May 5 14:24 atacenatek.ko* -r-xr-xr-x 1 root wheel 14928 May 5 14:24 atacenatek.ko.symbols* -r-xr-xr-x 1 root wheel 19904 May 5 14:24 atacypress.ko* -r-xr-xr-x 1 root wheel 18400 May 5 14:24 atacypress.ko.symbols* -r-xr-xr-x 1 root wheel 19416 May 5 14:24 atacyrix.ko* -r-xr-xr-x 1 root wheel 17912 May 5 14:24 atacyrix.ko.symbols* -r-xr-xr-x 1 root wheel 29280 May 5 14:24 atadisk.ko* -r-xr-xr-x 1 root wheel 24192 May 5 14:24 atadisk.ko.symbols* -r-xr-xr-x 1 root wheel 26768 May 5 14:24 atahighpoint.ko* -r-xr-xr-x 1 root wheel 22384 May 5 14:24 atahighpoint.ko.symbols* -r-xr-xr-x 1 root wheel 33536 May 5 14:24 ataintel.ko* -r-xr-xr-x 1 root wheel 25024 May 5 14:24 ataintel.ko.symbols* -r-xr-xr-x 1 root wheel 14464 May 5 14:24 ataisa.ko* -r-xr-xr-x 1 root wheel 12776 May 5 14:24 ataisa.ko.symbols* -r-xr-xr-x 1 root wheel 26792 May 5 14:24 ataite.ko* -r-xr-xr-x 1 root wheel 22080 May 5 14:24 ataite.ko.symbols* -r-xr-xr-x 1 root wheel 24248 May 5 14:24 atajmicron.ko* -r-xr-xr-x 1 root wheel 21176 May 5 14:24 atajmicron.ko.symbols* -r-xr-xr-x 1 root wheel 27056 May 5 14:24 atamarvell.ko* -r-xr-xr-x 1 root wheel 20880 May 5 14:24 atamarvell.ko.symbols* -r-xr-xr-x 1 root wheel 16216 May 5 14:24 atamicron.ko* -r-xr-xr-x 1 root wheel 15024 May 5 14:24 atamicron.ko.symbols* -r-xr-xr-x 1 root wheel 20520 May 5 14:24 atanational.ko* -r-xr-xr-x 1 root wheel 18696 May 5 14:24 atanational.ko.symbols* -r-xr-xr-x 1 root wheel 19168 May 5 14:24 atanetcell.ko* -r-xr-xr-x 1 root wheel 17984 May 5 14:24 atanetcell.ko.symbols* -r-xr-xr-x 1 root wheel 26632 May 5 14:24 atanvidia.ko* -r-xr-xr-x 1 root wheel 21536 May 5 14:24 atanvidia.ko.symbols* -r-xr-xr-x 1 root wheel 66968 May 5 14:24 atapci.ko* -r-xr-xr-x 1 root wheel 51200 May 5 14:24 atapci.ko.symbols* -r-xr-xr-x 1 root wheel 42056 May 5 14:24 atapicam.ko* -r-xr-xr-x 1 root wheel 35304 May 5 14:24 atapicam.ko.symbols* -r-xr-xr-x 1 root wheel 68392 May 5 14:24 atapicd.ko* -r-xr-xr-x 1 root wheel 49992 May 5 14:24 atapicd.ko.symbols* -r-xr-xr-x 1 root wheel 27176 May 5 14:24 atapifd.ko* -r-xr-xr-x 1 root wheel 23408 May 5 14:24 atapifd.ko.symbols* -r-xr-xr-x 1 root wheel 36856 May 5 14:24 atapist.ko* -r-xr-xr-x 1 root wheel 29752 May 5 14:24 atapist.ko.symbols* -r-xr-xr-x 1 root wheel 44208 May 5 14:24 atapromise.ko* -r-xr-xr-x 1 root wheel 28456 May 5 14:24 atapromise.ko.symbols* -r-xr-xr-x 1 root wheel 134960 May 5 14:24 ataraid.ko* -r-xr-xr-x 1 root wheel 76784 May 5 14:24 ataraid.ko.symbols* -r-xr-xr-x 1 root wheel 28152 May 5 14:24 ataserverworks.ko* -r-xr-xr-x 1 root wheel 22288 May 5 14:24 ataserverworks.ko.symbols* -r-xr-xr-x 1 root wheel 39752 May 5 14:24 atasiliconimage.ko* -r-xr-xr-x 1 root wheel 28360 May 5 14:24 atasiliconimage.ko.symbols* -r-xr-xr-x 1 root wheel 28960 May 5 14:24 atasis.ko* -r-xr-xr-x 1 root wheel 23344 May 5 14:24 atasis.ko.symbols* -r-xr-xr-x 1 root wheel 30552 May 5 14:24 atavia.ko* -r-xr-xr-x 1 root wheel 24272 May 5 14:24 atavia.ko.symbols* -r-xr-xr-x 1 root wheel 11368 May 5 14:24 blank_saver.ko* -r-xr-xr-x 1 root wheel 10976 May 5 14:24 blank_saver.ko.symbols* -r-xr-xr-x 1 root wheel 50568 May 5 14:24 bridgestp.ko* -r-xr-xr-x 1 root wheel 37248 May 5 14:24 bridgestp.ko.symbols* -r-xr-xr-x 1 root wheel 803448 May 5 14:24 cam.ko* -r-xr-xr-x 1 root wheel 583904 May 5 14:24 cam.ko.symbols* -r-xr-xr-x 1 root wheel 47816 May 5 14:24 cardbus.ko* -r-xr-xr-x 1 root wheel 37528 May 5 14:24 cardbus.ko.symbols* -r-xr-xr-x 1 root wheel 120632 May 5 14:24 cbb.ko* -r-xr-xr-x 1 root wheel 90928 May 5 14:24 cbb.ko.symbols* -r-xr-xr-x 1 root wheel 221688 May 5 14:24 cd9660.ko* -r-xr-xr-x 1 root wheel 198984 May 5 14:24 cd9660.ko.symbols* -r-xr-xr-x 1 root wheel 7632 May 5 14:24 cd9660_iconv.ko* -r-xr-xr-x 1 root wheel 7240 May 5 14:24 cd9660_iconv.ko.symbols* -r-xr-xr-x 1 root wheel 92088 May 5 14:24 ciss.ko* -r-xr-xr-x 1 root wheel 60456 May 5 14:24 ciss.ko.symbols* -r-xr-xr-x 1 root wheel 27048 May 5 14:24 cmx.ko* -r-xr-xr-x 1 root wheel 19896 May 5 14:24 cmx.ko.symbols* -r-xr-xr-x 1 root wheel 233768 May 5 14:24 coda.ko* -r-xr-xr-x 1 root wheel 199448 May 5 14:24 coda.ko.symbols* -r-xr-xr-x 1 root wheel 240040 May 5 14:24 coda5.ko* -r-xr-xr-x 1 root wheel 203328 May 5 14:24 coda5.ko.symbols* -r-xr-xr-x 1 root wheel 22488 May 5 14:24 coretemp.ko* -r-xr-xr-x 1 root wheel 20880 May 5 14:24 coretemp.ko.symbols* -r-xr-xr-x 1 root wheel 26136 May 5 14:24 cpuctl.ko* -r-xr-xr-x 1 root wheel 23248 May 5 14:24 cpuctl.ko.symbols* -r-xr-xr-x 1 root wheel 100872 May 5 14:24 cpufreq.ko* -r-xr-xr-x 1 root wheel 73360 May 5 14:24 cpufreq.ko.symbols* -r-xr-xr-x 1 root wheel 220744 May 5 14:24 crypto.ko* -r-xr-xr-x 1 root wheel 113552 May 5 14:24 crypto.ko.symbols* -r-xr-xr-x 1 root wheel 27744 May 5 14:24 cryptodev.ko* -r-xr-xr-x 1 root wheel 22128 May 5 14:24 cryptodev.ko.symbols* -r-xr-xr-x 1 root wheel 54584 May 5 14:24 cxgb_t3fw.ko* -r-xr-xr-x 1 root wheel 13248 May 5 14:24 cxgb_t3fw.ko.symbols* -r-xr-xr-x 1 root wheel 37520 May 5 14:24 cyclic.ko* -r-xr-xr-x 1 root wheel 30512 May 5 14:24 cyclic.ko.symbols* -r-xr-xr-x 1 root wheel 24728 May 5 14:24 daemon_saver.ko* -r-xr-xr-x 1 root wheel 20696 May 5 14:24 daemon_saver.ko.symbols* -r-xr-xr-x 1 root wheel 35000 May 5 14:24 dcons.ko* -r-xr-xr-x 1 root wheel 31440 May 5 14:24 dcons.ko.symbols* -r-xr-xr-x 1 root wheel 25952 May 5 14:24 dcons_crom.ko* -r-xr-xr-x 1 root wheel 23904 May 5 14:24 dcons_crom.ko.symbols* -r-xr-xr-x 1 root wheel 15672 May 5 14:24 dragon_saver.ko* -r-xr-xr-x 1 root wheel 13960 May 5 14:24 dragon_saver.ko.symbols* -r-xr-xr-x 1 root wheel 513384 May 5 14:24 drm.ko* -r-xr-xr-x 1 root wheel 454000 May 5 14:24 drm.ko.symbols* -r-xr-xr-x 1 root wheel 41552 May 5 14:24 dtmalloc.ko* -r-xr-xr-x 1 root wheel 40144 May 5 14:24 dtmalloc.ko.symbols* -r-xr-xr-x 1 root wheel 49808 May 5 14:24 dtnfsclient.ko* -r-xr-xr-x 1 root wheel 46176 May 5 14:24 dtnfsclient.ko.symbols* -r-xr-xr-x 1 root wheel 306704 May 5 14:24 dtrace.ko* -r-xr-xr-x 1 root wheel 689808 May 5 14:24 dtrace.ko.symbols* -r-xr-xr-x 1 root wheel 21896 May 5 14:24 dtrace_test.ko* -r-xr-xr-x 1 root wheel 21592 May 5 14:24 dtrace_test.ko.symbols* -r-xr-xr-x 1 root wheel 9840 May 5 14:24 dtraceall.ko* -r-xr-xr-x 1 root wheel 9104 May 5 14:24 dtraceall.ko.symbols* -r-xr-xr-x 1 root wheel 72824 May 5 14:24 dummynet.ko* -r-xr-xr-x 1 root wheel 53024 May 5 14:24 dummynet.ko.symbols* -r-xr-xr-x 1 root wheel 102232 May 5 14:24 ehci.ko* -r-xr-xr-x 1 root wheel 65816 May 5 14:24 ehci.ko.symbols* -r-xr-xr-x 1 root wheel 19192 May 5 14:24 exca.ko* -r-xr-xr-x 1 root wheel 13480 May 5 14:24 exca.ko.symbols* -r-xr-xr-x 1 root wheel 393200 May 5 14:24 ext2fs.ko* -r-xr-xr-x 1 root wheel 347320 May 5 14:24 ext2fs.ko.symbols* -r-xr-xr-x 1 root wheel 12192 May 5 14:24 fade_saver.ko* -r-xr-xr-x 1 root wheel 11464 May 5 14:24 fade_saver.ko.symbols* -r-xr-xr-x 1 root wheel 57672 May 5 14:24 fbt.ko* -r-xr-xr-x 1 root wheel 50600 May 5 14:24 fbt.ko.symbols* -r-xr-xr-x 1 root wheel 107536 May 5 14:24 fdc.ko* -r-xr-xr-x 1 root wheel 85864 May 5 14:24 fdc.ko.symbols* -r-xr-xr-x 1 root wheel 74440 May 5 14:24 fdescfs.ko* -r-xr-xr-x 1 root wheel 68752 May 5 14:24 fdescfs.ko.symbols* -r-xr-xr-x 1 root wheel 15056 May 5 14:24 fire_saver.ko* -r-xr-xr-x 1 root wheel 13440 May 5 14:24 fire_saver.ko.symbols* -r-xr-xr-x 1 root wheel 214520 May 5 14:24 firewire.ko* -r-xr-xr-x 1 root wheel 145664 May 5 14:24 firewire.ko.symbols* -r-xr-xr-x 1 root wheel 40608 May 5 14:24 firmware.ko* -r-xr-xr-x 1 root wheel 37096 May 5 14:24 firmware.ko.symbols* -r-xr-xr-x 1 root wheel 99608 May 5 14:24 geom_bde.ko* -r-xr-xr-x 1 root wheel 64312 May 5 14:24 geom_bde.ko.symbols* -r-xr-xr-x 1 root wheel 28024 May 5 14:24 geom_bsd.ko* -r-xr-xr-x 1 root wheel 20072 May 5 14:24 geom_bsd.ko.symbols* -r-xr-xr-x 1 root wheel 43088 May 5 14:24 geom_cache.ko* -r-xr-xr-x 1 root wheel 30720 May 5 14:24 geom_cache.ko.symbols* -r-xr-xr-x 1 root wheel 20216 May 5 14:24 geom_ccd.ko* -r-xr-xr-x 1 root wheel 14680 May 5 14:24 geom_ccd.ko.symbols* -r-xr-xr-x 1 root wheel 37080 May 5 14:24 geom_concat.ko* -r-xr-xr-x 1 root wheel 26952 May 5 14:24 geom_concat.ko.symbols* -r-xr-xr-x 1 root wheel 209448 May 5 14:24 geom_eli.ko* -r-xr-xr-x 1 root wheel 168864 May 5 14:24 geom_eli.ko.symbols* -r-xr-xr-x 1 root wheel 20328 May 5 14:24 geom_fox.ko* -r-xr-xr-x 1 root wheel 16328 May 5 14:24 geom_fox.ko.symbols* -r-xr-xr-x 1 root wheel 44976 May 5 14:24 geom_gate.ko* -r-xr-xr-x 1 root wheel 37064 May 5 14:24 geom_gate.ko.symbols* -r-xr-xr-x 1 root wheel 188544 May 5 14:24 geom_journal.ko* -r-xr-xr-x 1 root wheel 144672 May 5 14:24 geom_journal.ko.symbols* -r-xr-xr-x 1 root wheel 65328 May 5 14:24 geom_label.ko* -r-xr-xr-x 1 root wheel 54864 May 5 14:24 geom_label.ko.symbols* -r-xr-xr-x 1 root wheel 49104 May 5 14:24 geom_linux_lvm.ko* -r-xr-xr-x 1 root wheel 32896 May 5 14:24 geom_linux_lvm.ko.symbols* -r-xr-xr-x 1 root wheel 22080 May 5 14:24 geom_mbr.ko* -r-xr-xr-x 1 root wheel 17232 May 5 14:24 geom_mbr.ko.symbols* -r-xr-xr-x 1 root wheel 65320 May 5 14:24 geom_md.ko* -r-xr-xr-x 1 root wheel 54432 May 5 14:24 geom_md.ko.symbols* -r-xr-xr-x 1 root wheel 165944 May 5 14:24 geom_mirror.ko* -r-xr-xr-x 1 root wheel 114168 May 5 14:24 geom_mirror.ko.symbols* -r-xr-xr-x 1 root wheel 27336 May 5 14:24 geom_multipath.ko* -r-xr-xr-x 1 root wheel 20608 May 5 14:24 geom_multipath.ko.symbols* -r-xr-xr-x 1 root wheel 26672 May 5 14:24 geom_nop.ko* -r-xr-xr-x 1 root wheel 20104 May 5 14:24 geom_nop.ko.symbols* -r-xr-xr-x 1 root wheel 20712 May 5 14:24 geom_part_apm.ko* -r-xr-xr-x 1 root wheel 16440 May 5 14:24 geom_part_apm.ko.symbols* -r-xr-xr-x 1 root wheel 19160 May 5 14:24 geom_part_bsd.ko* -r-xr-xr-x 1 root wheel 15264 May 5 14:24 geom_part_bsd.ko.symbols* -r-xr-xr-x 1 root wheel 20392 May 5 14:24 geom_part_ebr.ko* -r-xr-xr-x 1 root wheel 16152 May 5 14:24 geom_part_ebr.ko.symbols* -r-xr-xr-x 1 root wheel 29592 May 5 14:24 geom_part_gpt.ko* -r-xr-xr-x 1 root wheel 20240 May 5 14:24 geom_part_gpt.ko.symbols* -r-xr-xr-x 1 root wheel 18848 May 5 14:24 geom_part_mbr.ko* -r-xr-xr-x 1 root wheel 15456 May 5 14:24 geom_part_mbr.ko.symbols* -r-xr-xr-x 1 root wheel 19008 May 5 14:24 geom_part_pc98.ko* -r-xr-xr-x 1 root wheel 15488 May 5 14:24 geom_part_pc98.ko.symbols* -r-xr-xr-x 1 root wheel 19368 May 5 14:24 geom_part_vtoc8.ko* -r-xr-xr-x 1 root wheel 15560 May 5 14:24 geom_part_vtoc8.ko.symbols* -r-xr-xr-x 1 root wheel 19232 May 5 14:24 geom_pc98.ko* -r-xr-xr-x 1 root wheel 15400 May 5 14:24 geom_pc98.ko.symbols* -r-xr-xr-x 1 root wheel 173392 May 5 14:24 geom_raid3.ko* -r-xr-xr-x 1 root wheel 118440 May 5 14:24 geom_raid3.ko.symbols* -r-xr-xr-x 1 root wheel 36128 May 5 14:24 geom_shsec.ko* -r-xr-xr-x 1 root wheel 26664 May 5 14:24 geom_shsec.ko.symbols* -r-xr-xr-x 1 root wheel 43848 May 5 14:24 geom_stripe.ko* -r-xr-xr-x 1 root wheel 30560 May 5 14:24 geom_stripe.ko.symbols* -r-xr-xr-x 1 root wheel 20808 May 5 14:24 geom_sunlabel.ko* -r-xr-xr-x 1 root wheel 17176 May 5 14:24 geom_sunlabel.ko.symbols* -r-xr-xr-x 1 root wheel 19936 May 5 14:24 geom_uzip.ko* -r-xr-xr-x 1 root wheel 16088 May 5 14:24 geom_uzip.ko.symbols* -r-xr-xr-x 1 root wheel 271344 May 5 14:24 geom_vinum.ko* -r-xr-xr-x 1 root wheel 196168 May 5 14:24 geom_vinum.ko.symbols* -r-xr-xr-x 1 root wheel 78408 May 5 14:24 geom_virstor.ko* -r-xr-xr-x 1 root wheel 55624 May 5 14:24 geom_virstor.ko.symbols* -r-xr-xr-x 1 root wheel 14320 May 5 14:24 geom_vol_ffs.ko* -r-xr-xr-x 1 root wheel 13304 May 5 14:24 geom_vol_ffs.ko.symbols* -r-xr-xr-x 1 root wheel 13088 May 5 14:24 geom_zero.ko* -r-xr-xr-x 1 root wheel 12056 May 5 14:24 geom_zero.ko.symbols* -r-xr-xr-x 1 root wheel 11368 May 5 14:24 green_saver.ko* -r-xr-xr-x 1 root wheel 10976 May 5 14:24 green_saver.ko.symbols* -r-xr-xr-x 1 root wheel 68168 May 5 14:24 hifn.ko* -r-xr-xr-x 1 root wheel 45160 May 5 14:24 hifn.ko.symbols* -r-xr-xr-x 1 root wheel 61664 May 5 14:24 hptiop.ko* -r-xr-xr-x 1 root wheel 43560 May 5 14:24 hptiop.ko.symbols* -r-xr-xr-x 1 root wheel 313456 May 5 14:24 hptmv.ko* -r-xr-xr-x 1 root wheel 194432 May 5 14:24 hptmv.ko.symbols* -r-xr-xr-x 1 root wheel 697512 May 5 14:24 hptrr.ko* -r-xr-xr-x 1 root wheel 267160 May 5 14:24 hptrr.ko.symbols* -r-xr-xr-x 1 root wheel 515608 May 5 14:24 hwpmc.ko* -r-xr-xr-x 1 root wheel 466096 May 5 14:24 hwpmc.ko.symbols* -r-xr-xr-x 1 root wheel 184688 May 5 14:24 i915.ko* -r-xr-xr-x 1 root wheel 158144 May 5 14:24 i915.ko.symbols* -r-xr-xr-x 1 root wheel 31552 May 5 14:24 ichsmb.ko* -r-xr-xr-x 1 root wheel 23728 May 5 14:24 ichsmb.ko.symbols* -r-xr-xr-x 1 root wheel 19920 May 5 14:24 ichwd.ko* -r-xr-xr-x 1 root wheel 14104 May 5 14:24 ichwd.ko.symbols* -r-xr-xr-x 1 root wheel 54544 May 5 14:24 ida.ko* -r-xr-xr-x 1 root wheel 45784 May 5 14:24 ida.ko.symbols* -r-xr-xr-x 1 root wheel 57016 May 5 14:24 if_ae.ko* -r-xr-xr-x 1 root wheel 37880 May 5 14:24 if_ae.ko.symbols* -r-xr-xr-x 1 root wheel 77392 May 5 14:24 if_age.ko* -r-xr-xr-x 1 root wheel 47168 May 5 14:24 if_age.ko.symbols* -r-xr-xr-x 1 root wheel 79928 May 5 14:24 if_ale.ko* -r-xr-xr-x 1 root wheel 49376 May 5 14:24 if_ale.ko.symbols* -r-xr-xr-x 1 root wheel 187184 May 5 14:24 if_an.ko* -r-xr-xr-x 1 root wheel 149752 May 5 14:24 if_an.ko.symbols* -r-xr-xr-x 1 root wheel 1671072 May 5 14:24 if_ath.ko* -r-xr-xr-x 1 root wheel 1343776 May 5 14:24 if_ath.ko.symbols* -r-xr-xr-x 1 root wheel 41448 May 5 14:24 if_aue.ko* -r-xr-xr-x 1 root wheel 32944 May 5 14:24 if_aue.ko.symbols* -r-xr-xr-x 1 root wheel 41240 May 5 14:24 if_axe.ko* -r-xr-xr-x 1 root wheel 33368 May 5 14:24 if_axe.ko.symbols* -r-xr-xr-x 1 root wheel 333408 May 5 14:24 if_bce.ko* -r-xr-xr-x 1 root wheel 78872 May 5 14:24 if_bce.ko.symbols* -r-xr-xr-x 1 root wheel 56072 May 5 14:24 if_bfe.ko* -r-xr-xr-x 1 root wheel 36816 May 5 14:24 if_bfe.ko.symbols* -r-xr-xr-x 1 root wheel 104248 May 5 14:24 if_bge.ko* -r-xr-xr-x 1 root wheel 58800 May 5 14:24 if_bge.ko.symbols* -r-xr-xr-x 1 root wheel 103672 May 5 14:24 if_bridge.ko* -r-xr-xr-x 1 root wheel 82344 May 5 14:24 if_bridge.ko.symbols* -r-xr-xr-x 1 root wheel 38496 May 5 14:24 if_cdce.ko* -r-xr-xr-x 1 root wheel 33080 May 5 14:24 if_cdce.ko.symbols* -r-xr-xr-x 1 root wheel 32600 May 5 14:24 if_cue.ko* -r-xr-xr-x 1 root wheel 28168 May 5 14:24 if_cue.ko.symbols* -r-xr-xr-x 1 root wheel 576568 May 5 14:24 if_cxgb.ko* -r-xr-xr-x 1 root wheel 431104 May 5 14:24 if_cxgb.ko.symbols* -r-xr-xr-x 1 root wheel 108624 May 5 14:24 if_dc.ko* -r-xr-xr-x 1 root wheel 72552 May 5 14:24 if_dc.ko.symbols* -r-xr-xr-x 1 root wheel 90864 May 5 14:24 if_de.ko* -r-xr-xr-x 1 root wheel 48816 May 5 14:24 if_de.ko.symbols* -r-xr-xr-x 1 root wheel 18784 May 5 14:24 if_disc.ko* -r-xr-xr-x 1 root wheel 17672 May 5 14:24 if_disc.ko.symbols* -r-xr-xr-x 1 root wheel 167592 May 5 14:24 if_ed.ko* -r-xr-xr-x 1 root wheel 126592 May 5 14:24 if_ed.ko.symbols* -r-xr-xr-x 1 root wheel 18456 May 5 14:24 if_edsc.ko* -r-xr-xr-x 1 root wheel 17248 May 5 14:24 if_edsc.ko.symbols* -r-xr-xr-x 1 root wheel 22016 May 5 14:24 if_ef.ko* -r-xr-xr-x 1 root wheel 19576 May 5 14:24 if_ef.ko.symbols* -r-xr-xr-x 1 root wheel 430576 May 5 14:24 if_em.ko* -r-xr-xr-x 1 root wheel 262416 May 5 14:24 if_em.ko.symbols* -r-xr-xr-x 1 root wheel 90968 May 5 14:24 if_en.ko* -r-xr-xr-x 1 root wheel 58024 May 5 14:24 if_en.ko.symbols* -r-xr-xr-x 1 root wheel 66120 May 5 14:24 if_et.ko* -r-xr-xr-x 1 root wheel 47112 May 5 14:24 if_et.ko.symbols* -r-xr-xr-x 1 root wheel 31048 May 5 14:24 if_faith.ko* -r-xr-xr-x 1 root wheel 29120 May 5 14:24 if_faith.ko.symbols* -r-xr-xr-x 1 root wheel 104648 May 5 14:24 if_fatm.ko* -r-xr-xr-x 1 root wheel 41800 May 5 14:24 if_fatm.ko.symbols* -r-xr-xr-x 1 root wheel 35712 May 5 14:24 if_fwe.ko* -r-xr-xr-x 1 root wheel 30168 May 5 14:24 if_fwe.ko.symbols* -r-xr-xr-x 1 root wheel 63072 May 5 14:24 if_fwip.ko* -r-xr-xr-x 1 root wheel 51424 May 5 14:24 if_fwip.ko.symbols* -r-xr-xr-x 1 root wheel 70432 May 5 14:24 if_fxp.ko* -r-xr-xr-x 1 root wheel 43320 May 5 14:24 if_fxp.ko.symbols* -r-xr-xr-x 1 root wheel 71968 May 5 14:24 if_gem.ko* -r-xr-xr-x 1 root wheel 49160 May 5 14:24 if_gem.ko.symbols* -r-xr-xr-x 1 root wheel 102016 May 5 14:24 if_gif.ko* -r-xr-xr-x 1 root wheel 91768 May 5 14:24 if_gif.ko.symbols* -r-xr-xr-x 1 root wheel 65792 May 5 14:24 if_gre.ko* -r-xr-xr-x 1 root wheel 59312 May 5 14:24 if_gre.ko.symbols* -r-xr-xr-x 1 root wheel 158472 May 5 14:24 if_hatm.ko* -r-xr-xr-x 1 root wheel 112528 May 5 14:24 if_hatm.ko.symbols* -r-xr-xr-x 1 root wheel 64880 May 5 14:24 if_hme.ko* -r-xr-xr-x 1 root wheel 48280 May 5 14:24 if_hme.ko.symbols* -r-xr-xr-x 1 root wheel 23432 May 5 14:24 if_ic.ko* -r-xr-xr-x 1 root wheel 20616 May 5 14:24 if_ic.ko.symbols* -r-xr-xr-x 1 root wheel 430408 May 5 14:24 if_igb.ko* -r-xr-xr-x 1 root wheel 263664 May 5 14:24 if_igb.ko.symbols* -r-xr-xr-x 1 root wheel 93408 May 5 14:24 if_ipw.ko* -r-xr-xr-x 1 root wheel 64784 May 5 14:24 if_ipw.ko.symbols* -r-xr-xr-x 1 root wheel 144368 May 5 14:24 if_iwn.ko* -r-xr-xr-x 1 root wheel 95680 May 5 14:24 if_iwn.ko.symbols* -r-xr-xr-x 1 root wheel 81792 May 5 14:24 if_ixgb.ko* -r-xr-xr-x 1 root wheel 54712 May 5 14:24 if_ixgb.ko.symbols* -r-xr-xr-x 1 root wheel 81968 May 5 14:24 if_jme.ko* -r-xr-xr-x 1 root wheel 53592 May 5 14:24 if_jme.ko.symbols* -r-xr-xr-x 1 root wheel 39576 May 5 14:24 if_kue.ko* -r-xr-xr-x 1 root wheel 29664 May 5 14:24 if_kue.ko.symbols* -r-xr-xr-x 1 root wheel 80512 May 5 14:24 if_lagg.ko* -r-xr-xr-x 1 root wheel 61904 May 5 14:24 if_lagg.ko.symbols* -r-xr-xr-x 1 root wheel 77960 May 5 14:24 if_le.ko* -r-xr-xr-x 1 root wheel 63088 May 5 14:24 if_le.ko.symbols* -r-xr-xr-x 1 root wheel 41024 May 5 14:24 if_lge.ko* -r-xr-xr-x 1 root wheel 29928 May 5 14:24 if_lge.ko.symbols* -r-xr-xr-x 1 root wheel 91480 May 5 14:24 if_lmc.ko* -r-xr-xr-x 1 root wheel 48872 May 5 14:24 if_lmc.ko.symbols* -r-xr-xr-x 1 root wheel 169992 May 5 14:24 if_malo.ko* -r-xr-xr-x 1 root wheel 141600 May 5 14:24 if_malo.ko.symbols* -r-xr-xr-x 1 root wheel 107664 May 5 14:24 if_msk.ko* -r-xr-xr-x 1 root wheel 56400 May 5 14:24 if_msk.ko.symbols* -r-xr-xr-x 1 root wheel 119920 May 5 14:24 if_mxge.ko* -r-xr-xr-x 1 root wheel 78112 May 5 14:24 if_mxge.ko.symbols* -r-xr-xr-x 1 root wheel 44544 May 5 14:24 if_my.ko* -r-xr-xr-x 1 root wheel 29752 May 5 14:24 if_my.ko.symbols* -r-xr-xr-x 1 root wheel 282792 May 5 14:24 if_ndis.ko* -r-xr-xr-x 1 root wheel 250648 May 5 14:24 if_ndis.ko.symbols* -r-xr-xr-x 1 root wheel 77840 May 5 14:24 if_nfe.ko* -r-xr-xr-x 1 root wheel 45816 May 5 14:24 if_nfe.ko.symbols* -r-xr-xr-x 1 root wheel 45128 May 5 14:24 if_nge.ko* -r-xr-xr-x 1 root wheel 29904 May 5 14:24 if_nge.ko.symbols* -r-xr-xr-x 1 root wheel 102088 May 5 14:24 if_nve.ko* -r-xr-xr-x 1 root wheel 56512 May 5 14:24 if_nve.ko.symbols* -r-xr-xr-x 1 root wheel 574792 May 5 14:24 if_nxge.ko* -r-xr-xr-x 1 root wheel 431496 May 5 14:24 if_nxge.ko.symbols* -r-xr-xr-x 1 root wheel 190544 May 5 14:24 if_patm.ko* -r-xr-xr-x 1 root wheel 119912 May 5 14:24 if_patm.ko.symbols* -r-xr-xr-x 1 root wheel 39568 May 5 14:24 if_pcn.ko* -r-xr-xr-x 1 root wheel 29936 May 5 14:24 if_pcn.ko.symbols* -r-xr-xr-x 1 root wheel 202192 May 5 14:24 if_ral.ko* -r-xr-xr-x 1 root wheel 147016 May 5 14:24 if_ral.ko.symbols* -r-xr-xr-x 1 root wheel 61304 May 5 14:24 if_re.ko* -r-xr-xr-x 1 root wheel 39096 May 5 14:24 if_re.ko.symbols* -r-xr-xr-x 1 root wheel 51888 May 5 14:24 if_rl.ko* -r-xr-xr-x 1 root wheel 36336 May 5 14:24 if_rl.ko.symbols* -r-xr-xr-x 1 root wheel 39168 May 5 14:24 if_rue.ko* -r-xr-xr-x 1 root wheel 32856 May 5 14:24 if_rue.ko.symbols* -r-xr-xr-x 1 root wheel 85040 May 5 14:24 if_rum.ko* -r-xr-xr-x 1 root wheel 62120 May 5 14:24 if_rum.ko.symbols* -r-xr-xr-x 1 root wheel 62480 May 5 14:24 if_sf.ko* -r-xr-xr-x 1 root wheel 39640 May 5 14:24 if_sf.ko.symbols* -r-xr-xr-x 1 root wheel 52496 May 5 14:24 if_sis.ko* -r-xr-xr-x 1 root wheel 33240 May 5 14:24 if_sis.ko.symbols* -r-xr-xr-x 1 root wheel 74456 May 5 14:24 if_sk.ko* -r-xr-xr-x 1 root wheel 44016 May 5 14:24 if_sk.ko.symbols* -r-xr-xr-x 1 root wheel 63896 May 5 14:24 if_sn.ko* -r-xr-xr-x 1 root wheel 50152 May 5 14:24 if_sn.ko.symbols* -r-xr-xr-x 1 root wheel 46032 May 5 14:24 if_ste.ko* -r-xr-xr-x 1 root wheel 32208 May 5 14:24 if_ste.ko.symbols* -r-xr-xr-x 1 root wheel 54136 May 5 14:24 if_stf.ko* -r-xr-xr-x 1 root wheel 49664 May 5 14:24 if_stf.ko.symbols* -r-xr-xr-x 1 root wheel 57704 May 5 14:24 if_stge.ko* -r-xr-xr-x 1 root wheel 36824 May 5 14:24 if_stge.ko.symbols* -r-xr-xr-x 1 root wheel 52232 May 5 14:24 if_tap.ko* -r-xr-xr-x 1 root wheel 43104 May 5 14:24 if_tap.ko.symbols* -r-xr-xr-x 1 root wheel 230056 May 5 14:24 if_ti.ko* -r-xr-xr-x 1 root wheel 45496 May 5 14:24 if_ti.ko.symbols* -r-xr-xr-x 1 root wheel 46920 May 5 14:24 if_tl.ko* -r-xr-xr-x 1 root wheel 32168 May 5 14:24 if_tl.ko.symbols* -r-xr-xr-x 1 root wheel 52912 May 5 14:24 if_tun.ko* -r-xr-xr-x 1 root wheel 43208 May 5 14:24 if_tun.ko.symbols* -r-xr-xr-x 1 root wheel 46296 May 5 14:24 if_tx.ko* -r-xr-xr-x 1 root wheel 32400 May 5 14:24 if_tx.ko.symbols* -r-xr-xr-x 1 root wheel 121320 May 5 14:24 if_txp.ko* -r-xr-xr-x 1 root wheel 43200 May 5 14:24 if_txp.ko.symbols* -r-xr-xr-x 1 root wheel 83336 May 5 14:24 if_uath.ko* -r-xr-xr-x 1 root wheel 62912 May 5 14:24 if_uath.ko.symbols* -r-xr-xr-x 1 root wheel 38432 May 5 14:24 if_udav.ko* -r-xr-xr-x 1 root wheel 32344 May 5 14:24 if_udav.ko.symbols* -r-xr-xr-x 1 root wheel 83600 May 5 14:24 if_ural.ko* -r-xr-xr-x 1 root wheel 63656 May 5 14:24 if_ural.ko.symbols* -r-xr-xr-x 1 root wheel 47424 May 5 14:24 if_vge.ko* -r-xr-xr-x 1 root wheel 31688 May 5 14:24 if_vge.ko.symbols* -r-xr-xr-x 1 root wheel 39720 May 5 14:24 if_vlan.ko* -r-xr-xr-x 1 root wheel 31032 May 5 14:24 if_vlan.ko.symbols* -r-xr-xr-x 1 root wheel 61664 May 5 14:24 if_vr.ko* -r-xr-xr-x 1 root wheel 38648 May 5 14:24 if_vr.ko.symbols* -r-xr-xr-x 1 root wheel 45152 May 5 14:24 if_vx.ko* -r-xr-xr-x 1 root wheel 34504 May 5 14:24 if_vx.ko.symbols* -r-xr-xr-x 1 root wheel 43976 May 5 14:24 if_wb.ko* -r-xr-xr-x 1 root wheel 30704 May 5 14:24 if_wb.ko.symbols* -r-xr-xr-x 1 root wheel 167272 May 5 14:24 if_wi.ko* -r-xr-xr-x 1 root wheel 137888 May 5 14:24 if_wi.ko.symbols* -r-xr-xr-x 1 root wheel 112944 May 5 14:24 if_wpi.ko* -r-xr-xr-x 1 root wheel 77504 May 5 14:24 if_wpi.ko.symbols* -r-xr-xr-x 1 root wheel 66688 May 5 14:24 if_xl.ko* -r-xr-xr-x 1 root wheel 38736 May 5 14:24 if_xl.ko.symbols* -r-xr-xr-x 1 root wheel 110504 May 5 14:24 if_zyd.ko* -r-xr-xr-x 1 root wheel 68872 May 5 14:24 if_zyd.ko.symbols* -r-xr-xr-x 1 root wheel 20040 May 5 14:24 iic.ko* -r-xr-xr-x 1 root wheel 16664 May 5 14:24 iic.ko.symbols* -r-xr-xr-x 1 root wheel 19640 May 5 14:24 iicbb.ko* -r-xr-xr-x 1 root wheel 15296 May 5 14:24 iicbb.ko.symbols* -r-xr-xr-x 1 root wheel 24280 May 5 14:24 iicbus.ko* -r-xr-xr-x 1 root wheel 20040 May 5 14:24 iicbus.ko.symbols* -r-xr-xr-x 1 root wheel 19744 May 5 14:24 iicsmb.ko* -r-xr-xr-x 1 root wheel 15792 May 5 14:24 iicsmb.ko.symbols* -r-xr-xr-x 1 root wheel 75336 May 5 14:24 iir.ko* -r-xr-xr-x 1 root wheel 57280 May 5 14:24 iir.ko.symbols* -r-xr-xr-x 1 root wheel 24176 May 5 14:24 intpm.ko* -r-xr-xr-x 1 root wheel 17400 May 5 14:24 intpm.ko.symbols* -r-xr-xr-x 1 root wheel 33544 May 5 14:24 io.ko* -r-xr-xr-x 1 root wheel 33000 May 5 14:24 io.ko.symbols* -r-xr-xr-x 1 root wheel 80984 May 5 14:24 ip_mroute.ko* -r-xr-xr-x 1 root wheel 63400 May 5 14:24 ip_mroute.ko.symbols* -r-xr-xr-x 1 root wheel 56280 May 5 14:24 ipdivert.ko* -r-xr-xr-x 1 root wheel 51240 May 5 14:24 ipdivert.ko.symbols* -r-xr-xr-x 1 root wheel 166040 May 5 14:24 ipfw.ko* -r-xr-xr-x 1 root wheel 127144 May 5 14:24 ipfw.ko.symbols* -r-xr-xr-x 1 root wheel 42504 May 5 14:24 ipfw_nat.ko* -r-xr-xr-x 1 root wheel 37800 May 5 14:24 ipfw_nat.ko.symbols* -r-xr-xr-x 1 root wheel 616112 May 5 14:24 ipl.ko* -r-xr-xr-x 1 root wheel 452752 May 5 14:24 ipl.ko.symbols* -r-xr-xr-x 1 root wheel 123160 May 5 14:24 ipmi.ko* -r-xr-xr-x 1 root wheel 96752 May 5 14:24 ipmi.ko.symbols* -r-xr-xr-x 1 root wheel 19472 May 5 14:24 ipmi_linux.ko* -r-xr-xr-x 1 root wheel 19040 May 5 14:24 ipmi_linux.ko.symbols* -r-xr-xr-x 1 root wheel 96640 May 5 14:24 ips.ko* -r-xr-xr-x 1 root wheel 76808 May 5 14:24 ips.ko.symbols* -r-xr-xr-x 1 root wheel 216696 May 5 14:24 ipw_bss.ko* -r-xr-xr-x 1 root wheel 6912 May 5 14:24 ipw_bss.ko.symbols* -r-xr-xr-x 1 root wheel 208688 May 5 14:24 ipw_ibss.ko* -r-xr-xr-x 1 root wheel 6928 May 5 14:24 ipw_ibss.ko.symbols* -r-xr-xr-x 1 root wheel 204048 May 5 14:24 ipw_monitor.ko* -r-xr-xr-x 1 root wheel 6984 May 5 14:24 ipw_monitor.ko.symbols* -r-xr-xr-x 1 root wheel 258648 May 5 14:24 iscsi_initiator.ko* -r-xr-xr-x 1 root wheel 217968 May 5 14:24 iscsi_initiator.ko.symbols* -r-xr-xr-x 1 root wheel 339928 May 5 14:24 isp.ko* -r-xr-xr-x 1 root wheel 216848 May 5 14:24 isp.ko.symbols* -r-xr-xr-x 1 root wheel 29864 May 5 14:24 isp_1040.ko* -r-xr-xr-x 1 root wheel 6408 May 5 14:24 isp_1040.ko.symbols* -r-xr-xr-x 1 root wheel 39896 May 5 14:24 isp_1040_it.ko* -r-xr-xr-x 1 root wheel 6440 May 5 14:24 isp_1040_it.ko.symbols* -r-xr-xr-x 1 root wheel 38264 May 5 14:24 isp_1080.ko* -r-xr-xr-x 1 root wheel 6408 May 5 14:24 isp_1080.ko.symbols* -r-xr-xr-x 1 root wheel 47592 May 5 14:24 isp_1080_it.ko* -r-xr-xr-x 1 root wheel 6440 May 5 14:24 isp_1080_it.ko.symbols* -r-xr-xr-x 1 root wheel 34984 May 5 14:24 isp_12160.ko* -r-xr-xr-x 1 root wheel 6424 May 5 14:24 isp_12160.ko.symbols* -r-xr-xr-x 1 root wheel 47584 May 5 14:24 isp_12160_it.ko* -r-xr-xr-x 1 root wheel 6448 May 5 14:24 isp_12160_it.ko.symbols* -r-xr-xr-x 1 root wheel 83696 May 5 14:24 isp_2100.ko* -r-xr-xr-x 1 root wheel 6416 May 5 14:24 isp_2100.ko.symbols* -r-xr-xr-x 1 root wheel 84144 May 5 14:24 isp_2200.ko* -r-xr-xr-x 1 root wheel 6416 May 5 14:24 isp_2200.ko.symbols* -r-xr-xr-x 1 root wheel 112000 May 5 14:24 isp_2300.ko* -r-xr-xr-x 1 root wheel 6416 May 5 14:24 isp_2300.ko.symbols* -r-xr-xr-x 1 root wheel 128704 May 5 14:24 isp_2322.ko* -r-xr-xr-x 1 root wheel 6416 May 5 14:24 isp_2322.ko.symbols* -r-xr-xr-x 1 root wheel 201904 May 5 14:24 isp_2400.ko* -r-xr-xr-x 1 root wheel 6352 May 5 14:24 isp_2400.ko.symbols* -r-xr-xr-x 1 root wheel 789128 May 5 14:24 ispfw.ko* -r-xr-xr-x 1 root wheel 13672 May 5 14:24 ispfw.ko.symbols* -r-xr-xr-x 1 root wheel 557360 May 5 14:24 iw_cxgb.ko* -r-xr-xr-x 1 root wheel 505384 May 5 14:24 iw_cxgb.ko.symbols* -r-xr-xr-x 1 root wheel 198136 May 5 14:24 iwnfw.ko* -r-xr-xr-x 1 root wheel 6496 May 5 14:24 iwnfw.ko.symbols* -r-xr-xr-x 1 root wheel 23000 May 5 14:24 joy.ko* -r-xr-xr-x 1 root wheel 20016 May 5 14:24 joy.ko.symbols* -r-xr-xr-x 1 root wheel 43984 May 5 14:24 kbdmux.ko* -r-xr-xr-x 1 root wheel 31200 May 5 14:24 kbdmux.ko.symbols* -r-xr-xr-x 1 root wheel 11502375 May 5 14:06 kernel* -r-xr-xr-x 1 root wheel 45085952 May 5 14:06 kernel.symbols* -r-xr-xr-x 1 root wheel 335232 May 5 14:24 krpc.ko* -r-xr-xr-x 1 root wheel 276928 May 5 14:24 krpc.ko.symbols* -r-xr-xr-x 1 root wheel 78704 May 5 14:24 krping.ko* -r-xr-xr-x 1 root wheel 59256 May 5 14:24 krping.ko.symbols* -r-xr-xr-x 1 root wheel 132296 May 5 14:24 libalias.ko* -r-xr-xr-x 1 root wheel 90280 May 5 14:24 libalias.ko.symbols* -r-xr-xr-x 1 root wheel 41624 May 5 14:24 libiconv.ko* -r-xr-xr-x 1 root wheel 34760 May 5 14:24 libiconv.ko.symbols* -r-xr-xr-x 1 root wheel 10808 May 5 14:24 libmbpool.ko* -r-xr-xr-x 1 root wheel 9152 May 5 14:24 libmbpool.ko.symbols* -r-xr-xr-x 1 root wheel 10720 May 5 14:24 libmchain.ko* -r-xr-xr-x 1 root wheel 7672 May 5 14:24 libmchain.ko.symbols* -rw-r--r-- 1 root wheel 44188 May 5 14:24 linker.hints -r-xr-xr-x 1 root wheel 93440 May 5 14:24 linprocfs.ko* -r-xr-xr-x 1 root wheel 78832 May 5 14:24 linprocfs.ko.symbols* -r-xr-xr-x 1 root wheel 48192 May 5 14:24 linsysfs.ko* -r-xr-xr-x 1 root wheel 45872 May 5 14:24 linsysfs.ko.symbols* -r-xr-xr-x 1 root wheel 671888 May 5 14:24 linux.ko* -r-xr-xr-x 1 root wheel 569296 May 5 14:24 linux.ko.symbols* -r-xr-xr-x 1 root wheel 23544 May 5 14:24 logo_saver.ko* -r-xr-xr-x 1 root wheel 13560 May 5 14:24 logo_saver.ko.symbols* -r-xr-xr-x 1 root wheel 16920 May 5 14:24 lpbb.ko* -r-xr-xr-x 1 root wheel 14104 May 5 14:24 lpbb.ko.symbols* -r-xr-xr-x 1 root wheel 26080 May 5 14:24 lpt.ko* -r-xr-xr-x 1 root wheel 19704 May 5 14:24 lpt.ko.symbols* -r-xr-xr-x 1 root wheel 127928 May 5 14:24 mac_biba.ko* -r-xr-xr-x 1 root wheel 105000 May 5 14:24 mac_biba.ko.symbols* -r-xr-xr-x 1 root wheel 107336 May 5 14:24 mac_bsdextended.ko* -r-xr-xr-x 1 root wheel 99944 May 5 14:24 mac_bsdextended.ko.symbols* -r-xr-xr-x 1 root wheel 44272 May 5 14:24 mac_ifoff.ko* -r-xr-xr-x 1 root wheel 40648 May 5 14:24 mac_ifoff.ko.symbols* -r-xr-xr-x 1 root wheel 120104 May 5 14:24 mac_lomac.ko* -r-xr-xr-x 1 root wheel 99304 May 5 14:24 mac_lomac.ko.symbols* -r-xr-xr-x 1 root wheel 122216 May 5 14:24 mac_mls.ko* -r-xr-xr-x 1 root wheel 101432 May 5 14:24 mac_mls.ko.symbols* -r-xr-xr-x 1 root wheel 25912 May 5 14:24 mac_none.ko* -r-xr-xr-x 1 root wheel 25576 May 5 14:24 mac_none.ko.symbols* -r-xr-xr-x 1 root wheel 49088 May 5 14:24 mac_partition.ko* -r-xr-xr-x 1 root wheel 45392 May 5 14:24 mac_partition.ko.symbols* -r-xr-xr-x 1 root wheel 56936 May 5 14:24 mac_portacl.ko* -r-xr-xr-x 1 root wheel 51496 May 5 14:24 mac_portacl.ko.symbols* -r-xr-xr-x 1 root wheel 48608 May 5 14:24 mac_seeotheruids.ko* -r-xr-xr-x 1 root wheel 45008 May 5 14:24 mac_seeotheruids.ko.symbols* -r-xr-xr-x 1 root wheel 90504 May 5 14:24 mac_stub.ko* -r-xr-xr-x 1 root wheel 84960 May 5 14:24 mac_stub.ko.symbols* -r-xr-xr-x 1 root wheel 235208 May 5 14:24 mac_test.ko* -r-xr-xr-x 1 root wheel 193336 May 5 14:24 mac_test.ko.symbols* -r-xr-xr-x 1 root wheel 179232 May 5 14:24 mach64.ko* -r-xr-xr-x 1 root wheel 135528 May 5 14:24 mach64.ko.symbols* -r-xr-xr-x 1 root wheel 43192 May 5 14:24 mcd.ko* -r-xr-xr-x 1 root wheel 29880 May 5 14:24 mcd.ko.symbols* -r-xr-xr-x 1 root wheel 51776 May 5 14:24 mem.ko* -r-xr-xr-x 1 root wheel 46384 May 5 14:24 mem.ko.symbols* -r-xr-xr-x 1 root wheel 119552 May 5 14:24 mfi.ko* -r-xr-xr-x 1 root wheel 93608 May 5 14:24 mfi.ko.symbols* -r-xr-xr-x 1 root wheel 22144 May 5 14:24 mfi_linux.ko* -r-xr-xr-x 1 root wheel 21496 May 5 14:24 mfi_linux.ko.symbols* -r-xr-xr-x 1 root wheel 41816 May 5 14:24 mfip.ko* -r-xr-xr-x 1 root wheel 39304 May 5 14:24 mfip.ko.symbols* -r-xr-xr-x 1 root wheel 213224 May 5 14:24 mga.ko* -r-xr-xr-x 1 root wheel 156320 May 5 14:24 mga.ko.symbols* -r-xr-xr-x 1 root wheel 657296 May 5 14:24 miibus.ko* -r-xr-xr-x 1 root wheel 559880 May 5 14:24 miibus.ko.symbols* -r-xr-xr-x 1 root wheel 84536 May 5 14:24 mlx.ko* -r-xr-xr-x 1 root wheel 59936 May 5 14:24 mlx.ko.symbols* -r-xr-xr-x 1 root wheel 79736 May 5 14:24 mly.ko* -r-xr-xr-x 1 root wheel 54864 May 5 14:24 mly.ko.symbols* -r-xr-xr-x 1 root wheel 51856 May 5 14:24 mmc.ko* -r-xr-xr-x 1 root wheel 32000 May 5 14:24 mmc.ko.symbols* -r-xr-xr-x 1 root wheel 25456 May 5 14:24 mmcsd.ko* -r-xr-xr-x 1 root wheel 19800 May 5 14:24 mmcsd.ko.symbols* -r-xr-xr-x 1 root wheel 418792 May 5 14:24 mpt.ko* -r-xr-xr-x 1 root wheel 319216 May 5 14:24 mpt.ko.symbols* -r-xr-xr-x 1 root wheel 83744 May 5 14:24 mqueuefs.ko* -r-xr-xr-x 1 root wheel 65208 May 5 14:24 mqueuefs.ko.symbols* -r-xr-xr-x 1 root wheel 255872 May 5 14:24 msdosfs.ko* -r-xr-xr-x 1 root wheel 208816 May 5 14:24 msdosfs.ko.symbols* -r-xr-xr-x 1 root wheel 7656 May 5 14:24 msdosfs_iconv.ko* -r-xr-xr-x 1 root wheel 7264 May 5 14:24 msdosfs_iconv.ko.symbols* -r-xr-xr-x 1 root wheel 47480 May 5 14:24 musb.ko* -r-xr-xr-x 1 root wheel 29456 May 5 14:24 musb.ko.symbols* -r-xr-xr-x 1 root wheel 117960 May 5 14:24 mxge_eth_z8e.ko* -r-xr-xr-x 1 root wheel 6568 May 5 14:24 mxge_eth_z8e.ko.symbols* -r-xr-xr-x 1 root wheel 118816 May 5 14:24 mxge_ethp_z8e.ko* -r-xr-xr-x 1 root wheel 6584 May 5 14:24 mxge_ethp_z8e.ko.symbols* -r-xr-xr-x 1 root wheel 155640 May 5 14:24 mxge_rss_eth_z8e.ko* -r-xr-xr-x 1 root wheel 6640 May 5 14:24 mxge_rss_eth_z8e.ko.symbols* -r-xr-xr-x 1 root wheel 156960 May 5 14:24 mxge_rss_ethp_z8e.ko* -r-xr-xr-x 1 root wheel 6656 May 5 14:24 mxge_rss_ethp_z8e.ko.symbols* -r-xr-xr-x 1 root wheel 400104 May 5 14:24 ndis.ko* -r-xr-xr-x 1 root wheel 326192 May 5 14:24 ndis.ko.symbols* -r-xr-xr-x 1 root wheel 104584 May 5 14:24 netgraph.ko* -r-xr-xr-x 1 root wheel 70840 May 5 14:24 netgraph.ko.symbols* -r-xr-xr-x 1 root wheel 980488 May 5 14:24 nfsclient.ko* -r-xr-xr-x 1 root wheel 822768 May 5 14:24 nfsclient.ko.symbols* -r-xr-xr-x 1 root wheel 210344 May 5 14:24 nfslockd.ko* -r-xr-xr-x 1 root wheel 170800 May 5 14:24 nfslockd.ko.symbols* -r-xr-xr-x 1 root wheel 24440 May 5 14:24 nfsmb.ko* -r-xr-xr-x 1 root wheel 18304 May 5 14:24 nfsmb.ko.symbols* -r-xr-xr-x 1 root wheel 327552 May 5 14:24 nfsserver.ko* -r-xr-xr-x 1 root wheel 261216 May 5 14:24 nfsserver.ko.symbols* -r-xr-xr-x 1 root wheel 20792 May 5 14:24 nfssvc.ko* -r-xr-xr-x 1 root wheel 20160 May 5 14:24 nfssvc.ko.symbols* -r-xr-xr-x 1 root wheel 13360 May 5 14:24 ng_UI.ko* -r-xr-xr-x 1 root wheel 12120 May 5 14:24 ng_UI.ko.symbols* -r-xr-xr-x 1 root wheel 21880 May 5 14:24 ng_async.ko* -r-xr-xr-x 1 root wheel 17136 May 5 14:24 ng_async.ko.symbols* -r-xr-xr-x 1 root wheel 48352 May 5 14:24 ng_atm.ko* -r-xr-xr-x 1 root wheel 36704 May 5 14:24 ng_atm.ko.symbols* -r-xr-xr-x 1 root wheel 19616 May 5 14:24 ng_atmllc.ko* -r-xr-xr-x 1 root wheel 17864 May 5 14:24 ng_atmllc.ko.symbols* -r-xr-xr-x 1 root wheel 15048 May 5 14:24 ng_bluetooth.ko* -r-xr-xr-x 1 root wheel 12576 May 5 14:24 ng_bluetooth.ko.symbols* -r-xr-xr-x 1 root wheel 30320 May 5 14:24 ng_bpf.ko* -r-xr-xr-x 1 root wheel 23536 May 5 14:24 ng_bpf.ko.symbols* -r-xr-xr-x 1 root wheel 33136 May 5 14:24 ng_bridge.ko* -r-xr-xr-x 1 root wheel 26440 May 5 14:24 ng_bridge.ko.symbols* -r-xr-xr-x 1 root wheel 43048 May 5 14:24 ng_bt3c.ko* -r-xr-xr-x 1 root wheel 31216 May 5 14:24 ng_bt3c.ko.symbols* -r-xr-xr-x 1 root wheel 305520 May 5 14:24 ng_btsocket.ko* -r-xr-xr-x 1 root wheel 215336 May 5 14:24 ng_btsocket.ko.symbols* -r-xr-xr-x 1 root wheel 22352 May 5 14:24 ng_car.ko* -r-xr-xr-x 1 root wheel 17432 May 5 14:24 ng_car.ko.symbols* -r-xr-xr-x 1 root wheel 253864 May 5 14:24 ng_ccatm.ko* -r-xr-xr-x 1 root wheel 193424 May 5 14:24 ng_ccatm.ko.symbols* -r-xr-xr-x 1 root wheel 25528 May 5 14:24 ng_cisco.ko* -r-xr-xr-x 1 root wheel 21600 May 5 14:24 ng_cisco.ko.symbols* -r-xr-xr-x 1 root wheel 22728 May 5 14:24 ng_deflate.ko* -r-xr-xr-x 1 root wheel 18208 May 5 14:24 ng_deflate.ko.symbols* -r-xr-xr-x 1 root wheel 26168 May 5 14:24 ng_device.ko* -r-xr-xr-x 1 root wheel 23400 May 5 14:24 ng_device.ko.symbols* -r-xr-xr-x 1 root wheel 11472 May 5 14:24 ng_echo.ko* -r-xr-xr-x 1 root wheel 10912 May 5 14:24 ng_echo.ko.symbols* -r-xr-xr-x 1 root wheel 25848 May 5 14:24 ng_eiface.ko* -r-xr-xr-x 1 root wheel 22840 May 5 14:24 ng_eiface.ko.symbols* -r-xr-xr-x 1 root wheel 17664 May 5 14:24 ng_etf.ko* -r-xr-xr-x 1 root wheel 15096 May 5 14:24 ng_etf.ko.symbols* -r-xr-xr-x 1 root wheel 32008 May 5 14:24 ng_ether.ko* -r-xr-xr-x 1 root wheel 27136 May 5 14:24 ng_ether.ko.symbols* -r-xr-xr-x 1 root wheel 12040 May 5 14:24 ng_ether_echo.ko* -r-xr-xr-x 1 root wheel 11312 May 5 14:24 ng_ether_echo.ko.symbols* -r-xr-xr-x 1 root wheel 33536 May 5 14:24 ng_fec.ko* -r-xr-xr-x 1 root wheel 27080 May 5 14:24 ng_fec.ko.symbols* -r-xr-xr-x 1 root wheel 15088 May 5 14:24 ng_frame_relay.ko* -r-xr-xr-x 1 root wheel 12728 May 5 14:24 ng_frame_relay.ko.symbols* -r-xr-xr-x 1 root wheel 26880 May 5 14:24 ng_gif.ko* -r-xr-xr-x 1 root wheel 24128 May 5 14:24 ng_gif.ko.symbols* -r-xr-xr-x 1 root wheel 15664 May 5 14:24 ng_gif_demux.ko* -r-xr-xr-x 1 root wheel 14056 May 5 14:24 ng_gif_demux.ko.symbols* -r-xr-xr-x 1 root wheel 118360 May 5 14:24 ng_hci.ko* -r-xr-xr-x 1 root wheel 83240 May 5 14:24 ng_hci.ko.symbols* -r-xr-xr-x 1 root wheel 14248 May 5 14:24 ng_hole.ko* -r-xr-xr-x 1 root wheel 13032 May 5 14:24 ng_hole.ko.symbols* -r-xr-xr-x 1 root wheel 11616 May 5 14:24 ng_hub.ko* -r-xr-xr-x 1 root wheel 10952 May 5 14:24 ng_hub.ko.symbols* -r-xr-xr-x 1 root wheel 30760 May 5 14:24 ng_iface.ko* -r-xr-xr-x 1 root wheel 25952 May 5 14:24 ng_iface.ko.symbols* -r-xr-xr-x 1 root wheel 16600 May 5 14:24 ng_ip_input.ko* -r-xr-xr-x 1 root wheel 16160 May 5 14:24 ng_ip_input.ko.symbols* -r-xr-xr-x 1 root wheel 24248 May 5 14:24 ng_ipfw.ko* -r-xr-xr-x 1 root wheel 22568 May 5 14:24 ng_ipfw.ko.symbols* -r-xr-xr-x 1 root wheel 44256 May 5 14:24 ng_ksocket.ko* -r-xr-xr-x 1 root wheel 36104 May 5 14:24 ng_ksocket.ko.symbols* -r-xr-xr-x 1 root wheel 136800 May 5 14:24 ng_l2cap.ko* -r-xr-xr-x 1 root wheel 91184 May 5 14:24 ng_l2cap.ko.symbols* -r-xr-xr-x 1 root wheel 34368 May 5 14:24 ng_l2tp.ko* -r-xr-xr-x 1 root wheel 23864 May 5 14:24 ng_l2tp.ko.symbols* -r-xr-xr-x 1 root wheel 25208 May 5 14:24 ng_lmi.ko* -r-xr-xr-x 1 root wheel 17432 May 5 14:24 ng_lmi.ko.symbols* -r-xr-xr-x 1 root wheel 23112 May 5 14:24 ng_mppc.ko* -r-xr-xr-x 1 root wheel 17224 May 5 14:24 ng_mppc.ko.symbols* -r-xr-xr-x 1 root wheel 26768 May 5 14:24 ng_nat.ko* -r-xr-xr-x 1 root wheel 20888 May 5 14:24 ng_nat.ko.symbols* -r-xr-xr-x 1 root wheel 55320 May 5 14:24 ng_netflow.ko* -r-xr-xr-x 1 root wheel 45728 May 5 14:24 ng_netflow.ko.symbols* -r-xr-xr-x 1 root wheel 19360 May 5 14:24 ng_one2many.ko* -r-xr-xr-x 1 root wheel 15912 May 5 14:24 ng_one2many.ko.symbols* -r-xr-xr-x 1 root wheel 44832 May 5 14:24 ng_ppp.ko* -r-xr-xr-x 1 root wheel 27128 May 5 14:24 ng_ppp.ko.symbols* -r-xr-xr-x 1 root wheel 37368 May 5 14:24 ng_pppoe.ko* -r-xr-xr-x 1 root wheel 24688 May 5 14:24 ng_pppoe.ko.symbols* -r-xr-xr-x 1 root wheel 26440 May 5 14:24 ng_pptpgre.ko* -r-xr-xr-x 1 root wheel 19792 May 5 14:24 ng_pptpgre.ko.symbols* -r-xr-xr-x 1 root wheel 21080 May 5 14:24 ng_pred1.ko* -r-xr-xr-x 1 root wheel 16504 May 5 14:24 ng_pred1.ko.symbols* -r-xr-xr-x 1 root wheel 22752 May 5 14:24 ng_rfc1490.ko* -r-xr-xr-x 1 root wheel 19496 May 5 14:24 ng_rfc1490.ko.symbols* -r-xr-xr-x 1 root wheel 34880 May 5 14:24 ng_socket.ko* -r-xr-xr-x 1 root wheel 28520 May 5 14:24 ng_socket.ko.symbols* -r-xr-xr-x 1 root wheel 30576 May 5 14:24 ng_source.ko* -r-xr-xr-x 1 root wheel 24584 May 5 14:24 ng_source.ko.symbols* -r-xr-xr-x 1 root wheel 12680 May 5 14:24 ng_split.ko* -r-xr-xr-x 1 root wheel 11800 May 5 14:24 ng_split.ko.symbols* -r-xr-xr-x 1 root wheel 25128 May 5 14:24 ng_sppp.ko* -r-xr-xr-x 1 root wheel 22976 May 5 14:24 ng_sppp.ko.symbols* -r-xr-xr-x 1 root wheel 34072 May 5 14:24 ng_sscfu.ko* -r-xr-xr-x 1 root wheel 26936 May 5 14:24 ng_sscfu.ko.symbols* -r-xr-xr-x 1 root wheel 131272 May 5 14:24 ng_sscop.ko* -r-xr-xr-x 1 root wheel 74696 May 5 14:24 ng_sscop.ko.symbols* -r-xr-xr-x 1 root wheel 20312 May 5 14:24 ng_tag.ko* -r-xr-xr-x 1 root wheel 16848 May 5 14:24 ng_tag.ko.symbols* -r-xr-xr-x 1 root wheel 16896 May 5 14:24 ng_tcpmss.ko* -r-xr-xr-x 1 root wheel 14472 May 5 14:24 ng_tcpmss.ko.symbols* -r-xr-xr-x 1 root wheel 17040 May 5 14:24 ng_tee.ko* -r-xr-xr-x 1 root wheel 14488 May 5 14:24 ng_tee.ko.symbols* -r-xr-xr-x 1 root wheel 37368 May 5 14:24 ng_tty.ko* -r-xr-xr-x 1 root wheel 33888 May 5 14:24 ng_tty.ko.symbols* -r-xr-xr-x 1 root wheel 45624 May 5 14:24 ng_ubt.ko* -r-xr-xr-x 1 root wheel 32896 May 5 14:24 ng_ubt.ko.symbols* -r-xr-xr-x 1 root wheel 438096 May 5 14:24 ng_uni.ko* -r-xr-xr-x 1 root wheel 322024 May 5 14:24 ng_uni.ko.symbols* -r-xr-xr-x 1 root wheel 29520 May 5 14:24 ng_vjc.ko* -r-xr-xr-x 1 root wheel 21816 May 5 14:24 ng_vjc.ko.symbols* -r-xr-xr-x 1 root wheel 23968 May 5 14:24 ng_vlan.ko* -r-xr-xr-x 1 root wheel 20672 May 5 14:24 ng_vlan.ko.symbols* -r-xr-xr-x 1 root wheel 319384 May 5 14:24 ngatmbase.ko* -r-xr-xr-x 1 root wheel 168896 May 5 14:24 ngatmbase.ko.symbols* -r-xr-xr-x 1 root wheel 27080 May 5 14:24 nmdm.ko* -r-xr-xr-x 1 root wheel 25096 May 5 14:24 nmdm.ko.symbols* -r-xr-xr-x 1 root wheel 203152 May 5 14:24 ntfs.ko* -r-xr-xr-x 1 root wheel 176360 May 5 14:24 ntfs.ko.symbols* -r-xr-xr-x 1 root wheel 7584 May 5 14:24 ntfs_iconv.ko* -r-xr-xr-x 1 root wheel 7184 May 5 14:24 ntfs_iconv.ko.symbols* -r-xr-xr-x 1 root wheel 98256 May 5 14:24 nullfs.ko* -r-xr-xr-x 1 root wheel 91192 May 5 14:24 nullfs.ko.symbols* -r-xr-xr-x 1 root wheel 21104 May 5 14:24 nvram.ko* -r-xr-xr-x 1 root wheel 20056 May 5 14:24 nvram.ko.symbols* -r-xr-xr-x 1 root wheel 83568 May 5 14:24 ohci.ko* -r-xr-xr-x 1 root wheel 56560 May 5 14:24 ohci.ko.symbols* -r-xr-xr-x 1 root wheel 21624 May 5 14:24 opensolaris.ko* -r-xr-xr-x 1 root wheel 20400 May 5 14:24 opensolaris.ko.symbols* -r-xr-xr-x 1 root wheel 30704 May 5 14:24 padlock.ko* -r-xr-xr-x 1 root wheel 24232 May 5 14:24 padlock.ko.symbols* -r-xr-xr-x 1 root wheel 95616 May 5 14:24 pccard.ko* -r-xr-xr-x 1 root wheel 57624 May 5 14:24 pccard.ko.symbols* -r-xr-xr-x 1 root wheel 15176 May 5 14:24 pcf.ko* -r-xr-xr-x 1 root wheel 11592 May 5 14:24 pcf.ko.symbols* -r-xr-xr-x 1 root wheel 495664 May 5 14:24 pf.ko* -r-xr-xr-x 1 root wheel 325264 May 5 14:24 pf.ko.symbols* -r-xr-xr-x 1 root wheel 37440 May 5 14:24 pflog.ko* -r-xr-xr-x 1 root wheel 35256 May 5 14:24 pflog.ko.symbols* -r-xr-xr-x 1 root wheel 46104 May 5 14:24 plip.ko* -r-xr-xr-x 1 root wheel 34080 May 5 14:24 plip.ko.symbols* -r-xr-xr-x 1 root wheel 76280 May 5 14:24 portalfs.ko* -r-xr-xr-x 1 root wheel 71752 May 5 14:24 portalfs.ko.symbols* -r-xr-xr-x 1 root wheel 51384 May 5 14:24 ppbus.ko* -r-xr-xr-x 1 root wheel 37624 May 5 14:24 ppbus.ko.symbols* -r-xr-xr-x 1 root wheel 54872 May 5 14:24 ppc.ko* -r-xr-xr-x 1 root wheel 40856 May 5 14:24 ppc.ko.symbols* -r-xr-xr-x 1 root wheel 33256 May 5 14:24 ppi.ko* -r-xr-xr-x 1 root wheel 24544 May 5 14:24 ppi.ko.symbols* -r-xr-xr-x 1 root wheel 22496 May 5 14:24 pps.ko* -r-xr-xr-x 1 root wheel 18064 May 5 14:24 pps.ko.symbols* -r-xr-xr-x 1 root wheel 218944 May 5 14:24 procfs.ko* -r-xr-xr-x 1 root wheel 207472 May 5 14:24 procfs.ko.symbols* -r-xr-xr-x 1 root wheel 46512 May 5 14:24 profile.ko* -r-xr-xr-x 1 root wheel 43504 May 5 14:24 profile.ko.symbols* -r-xr-xr-x 1 root wheel 39232 May 5 14:24 prototype.ko* -r-xr-xr-x 1 root wheel 38320 May 5 14:24 prototype.ko.symbols* -r-xr-xr-x 1 root wheel 131000 May 5 14:24 pseudofs.ko* -r-xr-xr-x 1 root wheel 118256 May 5 14:24 pseudofs.ko.symbols* -r-xr-xr-x 1 root wheel 65816 May 5 14:24 puc.ko* -r-xr-xr-x 1 root wheel 46888 May 5 14:24 puc.ko.symbols* -r-xr-xr-x 1 root wheel 167912 May 5 14:24 r128.ko* -r-xr-xr-x 1 root wheel 130368 May 5 14:24 r128.ko.symbols* -r-xr-xr-x 1 root wheel 632624 May 5 14:24 radeon.ko* -r-xr-xr-x 1 root wheel 284832 May 5 14:24 radeon.ko.symbols* -r-xr-xr-x 1 root wheel 14624 May 5 14:24 rain_saver.ko* -r-xr-xr-x 1 root wheel 13064 May 5 14:24 rain_saver.ko.symbols* -r-xr-xr-x 1 root wheel 100080 May 5 14:24 random.ko* -r-xr-xr-x 1 root wheel 69480 May 5 14:24 random.ko.symbols* -r-xr-xr-x 1 root wheel 6200 May 5 14:24 rc4.ko* -r-xr-xr-x 1 root wheel 5752 May 5 14:24 rc4.ko.symbols* -r-xr-xr-x 1 root wheel 33920 May 5 14:24 rdma_addr.ko* -r-xr-xr-x 1 root wheel 30632 May 5 14:24 rdma_addr.ko.symbols* -r-xr-xr-x 1 root wheel 88608 May 5 14:24 rdma_cma.ko* -r-xr-xr-x 1 root wheel 75984 May 5 14:24 rdma_cma.ko.symbols* -r-xr-xr-x 1 root wheel 77704 May 5 14:24 rdma_core.ko* -r-xr-xr-x 1 root wheel 62256 May 5 14:24 rdma_core.ko.symbols* -r-xr-xr-x 1 root wheel 49512 May 5 14:24 rdma_iwcm.ko* -r-xr-xr-x 1 root wheel 42464 May 5 14:24 rdma_iwcm.ko.symbols* -r-xr-xr-x 1 root wheel 315384 May 5 14:24 reiserfs.ko* -r-xr-xr-x 1 root wheel 291752 May 5 14:24 reiserfs.ko.symbols* -r-xr-xr-x 1 root wheel 15008 May 5 14:24 rt2561fw.ko* -r-xr-xr-x 1 root wheel 6504 May 5 14:24 rt2561fw.ko.symbols* -r-xr-xr-x 1 root wheel 15032 May 5 14:24 rt2561sfw.ko* -r-xr-xr-x 1 root wheel 6528 May 5 14:24 rt2561sfw.ko.symbols* -r-xr-xr-x 1 root wheel 15008 May 5 14:24 rt2661fw.ko* -r-xr-xr-x 1 root wheel 6504 May 5 14:24 rt2661fw.ko.symbols* -r-xr-xr-x 1 root wheel 53912 May 5 14:24 safe.ko* -r-xr-xr-x 1 root wheel 39200 May 5 14:24 safe.ko.symbols* -r-xr-xr-x 1 root wheel 126400 May 5 14:24 savage.ko* -r-xr-xr-x 1 root wheel 96056 May 5 14:24 savage.ko.symbols* -r-xr-xr-x 1 root wheel 88992 May 5 14:24 sbp.ko* -r-xr-xr-x 1 root wheel 61168 May 5 14:24 sbp.ko.symbols* -r-xr-xr-x 1 root wheel 66864 May 5 14:24 sbp_targ.ko* -r-xr-xr-x 1 root wheel 51280 May 5 14:24 sbp_targ.ko.symbols* -r-xr-xr-x 1 root wheel 35456 May 5 14:24 scc.ko* -r-xr-xr-x 1 root wheel 27888 May 5 14:24 scc.ko.symbols* -r-xr-xr-x 1 root wheel 38120 May 5 14:24 scd.ko* -r-xr-xr-x 1 root wheel 28144 May 5 14:24 scd.ko.symbols* -r-xr-xr-x 1 root wheel 112080 May 5 14:24 scsi_low.ko* -r-xr-xr-x 1 root wheel 86232 May 5 14:24 scsi_low.ko.symbols* -r-xr-xr-x 1 root wheel 41656 May 5 14:24 sdhci.ko* -r-xr-xr-x 1 root wheel 25664 May 5 14:24 sdhci.ko.symbols* -r-xr-xr-x 1 root wheel 41264 May 5 14:24 sdt.ko* -r-xr-xr-x 1 root wheel 39896 May 5 14:24 sdt.ko.symbols* -r-xr-xr-x 1 root wheel 56464 May 5 14:24 sem.ko* -r-xr-xr-x 1 root wheel 49776 May 5 14:24 sem.ko.symbols* -r-xr-xr-x 1 root wheel 65800 May 5 14:24 sis.ko* -r-xr-xr-x 1 root wheel 60288 May 5 14:24 sis.ko.symbols* -r-xr-xr-x 1 root wheel 18688 May 5 14:24 smb.ko* -r-xr-xr-x 1 root wheel 15664 May 5 14:24 smb.ko.symbols* -r-xr-xr-x 1 root wheel 557240 May 5 14:24 smbfs.ko* -r-xr-xr-x 1 root wheel 472168 May 5 14:24 smbfs.ko.symbols* -r-xr-xr-x 1 root wheel 13656 May 5 14:24 smbus.ko* -r-xr-xr-x 1 root wheel 11928 May 5 14:24 smbus.ko.symbols* -r-xr-xr-x 1 root wheel 17808 May 5 14:24 snake_saver.ko* -r-xr-xr-x 1 root wheel 16512 May 5 14:24 snake_saver.ko.symbols* -r-xr-xr-x 1 root wheel 41736 May 5 14:24 snd_ad1816.ko* -r-xr-xr-x 1 root wheel 35256 May 5 14:24 snd_ad1816.ko.symbols* -r-xr-xr-x 1 root wheel 44296 May 5 14:24 snd_als4000.ko* -r-xr-xr-x 1 root wheel 36624 May 5 14:24 snd_als4000.ko.symbols* -r-xr-xr-x 1 root wheel 52376 May 5 14:24 snd_atiixp.ko* -r-xr-xr-x 1 root wheel 40816 May 5 14:24 snd_atiixp.ko.symbols* -r-xr-xr-x 1 root wheel 44256 May 5 14:24 snd_cmi.ko* -r-xr-xr-x 1 root wheel 36192 May 5 14:24 snd_cmi.ko.symbols* -r-xr-xr-x 1 root wheel 43872 May 5 14:24 snd_cs4281.ko* -r-xr-xr-x 1 root wheel 35256 May 5 14:24 snd_cs4281.ko.symbols* -r-xr-xr-x 1 root wheel 67648 May 5 14:24 snd_csa.ko* -r-xr-xr-x 1 root wheel 50712 May 5 14:24 snd_csa.ko.symbols* -r-xr-xr-x 1 root wheel 17536 May 5 14:24 snd_driver.ko* -r-xr-xr-x 1 root wheel 15472 May 5 14:24 snd_driver.ko.symbols* -r-xr-xr-x 1 root wheel 74752 May 5 14:24 snd_ds1.ko* -r-xr-xr-x 1 root wheel 39248 May 5 14:24 snd_ds1.ko.symbols* -r-xr-xr-x 1 root wheel 58712 May 5 14:24 snd_emu10k1.ko* -r-xr-xr-x 1 root wheel 41272 May 5 14:24 snd_emu10k1.ko.symbols* -r-xr-xr-x 1 root wheel 155216 May 5 14:24 snd_emu10kx.ko* -r-xr-xr-x 1 root wheel 101496 May 5 14:24 snd_emu10kx.ko.symbols* -r-xr-xr-x 1 root wheel 64896 May 5 14:24 snd_envy24.ko* -r-xr-xr-x 1 root wheel 46432 May 5 14:24 snd_envy24.ko.symbols* -r-xr-xr-x 1 root wheel 61960 May 5 14:24 snd_envy24ht.ko* -r-xr-xr-x 1 root wheel 44816 May 5 14:24 snd_envy24ht.ko.symbols* -r-xr-xr-x 1 root wheel 65408 May 5 14:24 snd_es137x.ko* -r-xr-xr-x 1 root wheel 45904 May 5 14:24 snd_es137x.ko.symbols* -r-xr-xr-x 1 root wheel 45864 May 5 14:24 snd_ess.ko* -r-xr-xr-x 1 root wheel 37456 May 5 14:24 snd_ess.ko.symbols* -r-xr-xr-x 1 root wheel 39872 May 5 14:24 snd_fm801.ko* -r-xr-xr-x 1 root wheel 34168 May 5 14:24 snd_fm801.ko.symbols* -r-xr-xr-x 1 root wheel 168376 May 5 14:24 snd_hda.ko* -r-xr-xr-x 1 root wheel 88904 May 5 14:24 snd_hda.ko.symbols* -r-xr-xr-x 1 root wheel 51656 May 5 14:24 snd_ich.ko* -r-xr-xr-x 1 root wheel 40280 May 5 14:24 snd_ich.ko.symbols* -r-xr-xr-x 1 root wheel 63264 May 5 14:24 snd_maestro.ko* -r-xr-xr-x 1 root wheel 44936 May 5 14:24 snd_maestro.ko.symbols* -r-xr-xr-x 1 root wheel 70264 May 5 14:24 snd_maestro3.ko* -r-xr-xr-x 1 root wheel 42184 May 5 14:24 snd_maestro3.ko.symbols* -r-xr-xr-x 1 root wheel 92776 May 5 14:24 snd_mss.ko* -r-xr-xr-x 1 root wheel 65120 May 5 14:24 snd_mss.ko.symbols* -r-xr-xr-x 1 root wheel 92928 May 5 14:24 snd_neomagic.ko* -r-xr-xr-x 1 root wheel 34880 May 5 14:24 snd_neomagic.ko.symbols* -r-xr-xr-x 1 root wheel 41840 May 5 14:24 snd_sb16.ko* -r-xr-xr-x 1 root wheel 34640 May 5 14:24 snd_sb16.ko.symbols* -r-xr-xr-x 1 root wheel 40168 May 5 14:24 snd_sb8.ko* -r-xr-xr-x 1 root wheel 34272 May 5 14:24 snd_sb8.ko.symbols* -r-xr-xr-x 1 root wheel 25976 May 5 14:24 snd_sbc.ko* -r-xr-xr-x 1 root wheel 19728 May 5 14:24 snd_sbc.ko.symbols* -r-xr-xr-x 1 root wheel 46488 May 5 14:24 snd_solo.ko* -r-xr-xr-x 1 root wheel 36936 May 5 14:24 snd_solo.ko.symbols* -r-xr-xr-x 1 root wheel 12064 May 5 14:24 snd_spicds.ko* -r-xr-xr-x 1 root wheel 9408 May 5 14:24 snd_spicds.ko.symbols* -r-xr-xr-x 1 root wheel 44296 May 5 14:24 snd_t4dwave.ko* -r-xr-xr-x 1 root wheel 35680 May 5 14:24 snd_t4dwave.ko.symbols* -r-xr-xr-x 1 root wheel 136320 May 5 14:24 snd_uaudio.ko* -r-xr-xr-x 1 root wheel 102736 May 5 14:24 snd_uaudio.ko.symbols* -r-xr-xr-x 1 root wheel 57920 May 5 14:24 snd_via8233.ko* -r-xr-xr-x 1 root wheel 43712 May 5 14:24 snd_via8233.ko.symbols* -r-xr-xr-x 1 root wheel 41448 May 5 14:24 snd_via82c686.ko* -r-xr-xr-x 1 root wheel 35368 May 5 14:24 snd_via82c686.ko.symbols* -r-xr-xr-x 1 root wheel 45208 May 5 14:24 snd_vibes.ko* -r-xr-xr-x 1 root wheel 36568 May 5 14:24 snd_vibes.ko.symbols* -r-xr-xr-x 1 root wheel 28456 May 5 14:24 snp.ko* -r-xr-xr-x 1 root wheel 26224 May 5 14:24 snp.ko.symbols* -r-xr-xr-x 1 root wheel 750088 May 5 14:24 sound.ko* -r-xr-xr-x 1 root wheel 567280 May 5 14:24 sound.ko.symbols* -r-xr-xr-x 1 root wheel 18888 May 5 14:24 speaker.ko* -r-xr-xr-x 1 root wheel 14968 May 5 14:24 speaker.ko.symbols* -r-xr-xr-x 1 root wheel 132184 May 5 14:24 sppp.ko* -r-xr-xr-x 1 root wheel 82744 May 5 14:24 sppp.ko.symbols* -r-xr-xr-x 1 root wheel 16496 May 5 14:24 star_saver.ko* -r-xr-xr-x 1 root wheel 15616 May 5 14:24 star_saver.ko.symbols* -r-xr-xr-x 1 root wheel 108440 May 5 14:24 sym.ko* -r-xr-xr-x 1 root wheel 52632 May 5 14:24 sym.ko.symbols* -r-xr-xr-x 1 root wheel 160904 May 5 14:24 systrace.ko* -r-xr-xr-x 1 root wheel 124432 May 5 14:24 systrace.ko.symbols* -r-xr-xr-x 1 root wheel 46768 May 5 14:24 sysvmsg.ko* -r-xr-xr-x 1 root wheel 37504 May 5 14:24 sysvmsg.ko.symbols* -r-xr-xr-x 1 root wheel 51592 May 5 14:24 sysvsem.ko* -r-xr-xr-x 1 root wheel 40056 May 5 14:24 sysvsem.ko.symbols* -r-xr-xr-x 1 root wheel 47424 May 5 14:24 sysvshm.ko* -r-xr-xr-x 1 root wheel 39472 May 5 14:24 sysvshm.ko.symbols* -r-xr-xr-x 1 root wheel 30528 May 5 14:24 tdfx.ko* -r-xr-xr-x 1 root wheel 29520 May 5 14:24 tdfx.ko.symbols* -r-xr-xr-x 1 root wheel 156216 May 5 14:24 tmpfs.ko* -r-xr-xr-x 1 root wheel 137792 May 5 14:24 tmpfs.ko.symbols* -r-xr-xr-x 1 root wheel 29792 May 5 14:24 toecore.ko* -r-xr-xr-x 1 root wheel 27816 May 5 14:24 toecore.ko.symbols* -r-xr-xr-x 1 root wheel 56496 May 5 14:24 trm.ko* -r-xr-xr-x 1 root wheel 35672 May 5 14:24 trm.ko.symbols* -r-xr-xr-x 1 root wheel 151816 May 5 14:24 twa.ko* -r-xr-xr-x 1 root wheel 107408 May 5 14:24 twa.ko.symbols* -r-xr-xr-x 1 root wheel 73104 May 5 14:24 twe.ko* -r-xr-xr-x 1 root wheel 49680 May 5 14:24 twe.ko.symbols* -r-xr-xr-x 1 root wheel 32968 May 5 14:24 u3g.ko* -r-xr-xr-x 1 root wheel 27704 May 5 14:24 u3g.ko.symbols* -r-xr-xr-x 1 root wheel 23640 May 5 14:24 uark.ko* -r-xr-xr-x 1 root wheel 21304 May 5 14:24 uark.ko.symbols* -r-xr-xr-x 1 root wheel 179040 May 5 14:24 uart.ko* -r-xr-xr-x 1 root wheel 135552 May 5 14:24 uart.ko.symbols* -r-xr-xr-x 1 root wheel 29400 May 5 14:24 ubsa.ko* -r-xr-xr-x 1 root wheel 25136 May 5 14:24 ubsa.ko.symbols* -r-xr-xr-x 1 root wheel 69600 May 5 14:24 ubsec.ko* -r-xr-xr-x 1 root wheel 46936 May 5 14:24 ubsec.ko.symbols* -r-xr-xr-x 1 root wheel 29704 May 5 14:24 ubser.ko* -r-xr-xr-x 1 root wheel 26656 May 5 14:24 ubser.ko.symbols* -r-xr-xr-x 1 root wheel 42480 May 5 14:24 ubtbcmfw.ko* -r-xr-xr-x 1 root wheel 40656 May 5 14:24 ubtbcmfw.ko.symbols* -r-xr-xr-x 1 root wheel 31672 May 5 14:24 uchcom.ko* -r-xr-xr-x 1 root wheel 26512 May 5 14:24 uchcom.ko.symbols* -r-xr-xr-x 1 root wheel 27168 May 5 14:24 ucom.ko* -r-xr-xr-x 1 root wheel 19888 May 5 14:24 ucom.ko.symbols* -r-xr-xr-x 1 root wheel 26760 May 5 14:24 ucycom.ko* -r-xr-xr-x 1 root wheel 23368 May 5 14:24 ucycom.ko.symbols* -r-xr-xr-x 1 root wheel 31792 May 5 14:24 udbp.ko* -r-xr-xr-x 1 root wheel 26032 May 5 14:24 udbp.ko.symbols* -r-xr-xr-x 1 root wheel 108616 May 5 14:24 udf.ko* -r-xr-xr-x 1 root wheel 91576 May 5 14:24 udf.ko.symbols* -r-xr-xr-x 1 root wheel 7560 May 5 14:24 udf_iconv.ko* -r-xr-xr-x 1 root wheel 7160 May 5 14:24 udf_iconv.ko.symbols* -r-xr-xr-x 1 root wheel 29960 May 5 14:24 uether.ko* -r-xr-xr-x 1 root wheel 25808 May 5 14:24 uether.ko.symbols* -r-xr-xr-x 1 root wheel 40528 May 5 14:24 ufm.ko* -r-xr-xr-x 1 root wheel 38872 May 5 14:24 ufm.ko.symbols* -r-xr-xr-x 1 root wheel 38192 May 5 14:24 ufoma.ko* -r-xr-xr-x 1 root wheel 30608 May 5 14:24 ufoma.ko.symbols* -r-xr-xr-x 1 root wheel 30432 May 5 14:24 uftdi.ko* -r-xr-xr-x 1 root wheel 25080 May 5 14:24 uftdi.ko.symbols* -r-xr-xr-x 1 root wheel 25840 May 5 14:24 ugensa.ko* -r-xr-xr-x 1 root wheel 23696 May 5 14:24 ugensa.ko.symbols* -r-xr-xr-x 1 root wheel 86192 May 5 14:24 uhci.ko* -r-xr-xr-x 1 root wheel 57632 May 5 14:24 uhci.ko.symbols* -r-xr-xr-x 1 root wheel 51776 May 5 14:24 uhid.ko* -r-xr-xr-x 1 root wheel 46424 May 5 14:24 uhid.ko.symbols* -r-xr-xr-x 1 root wheel 34904 May 5 14:24 uipaq.ko* -r-xr-xr-x 1 root wheel 21848 May 5 14:24 uipaq.ko.symbols* -r-xr-xr-x 1 root wheel 41104 May 5 14:24 ukbd.ko* -r-xr-xr-x 1 root wheel 26872 May 5 14:24 ukbd.ko.symbols* -r-xr-xr-x 1 root wheel 50424 May 5 14:24 ulpt.ko* -r-xr-xr-x 1 root wheel 45784 May 5 14:24 ulpt.ko.symbols* -r-xr-xr-x 1 root wheel 84792 May 5 14:24 umass.ko* -r-xr-xr-x 1 root wheel 59088 May 5 14:24 umass.ko.symbols* -r-xr-xr-x 1 root wheel 28112 May 5 14:24 umct.ko* -r-xr-xr-x 1 root wheel 25168 May 5 14:24 umct.ko.symbols* -r-xr-xr-x 1 root wheel 36312 May 5 14:24 umodem.ko* -r-xr-xr-x 1 root wheel 30640 May 5 14:24 umodem.ko.symbols* -r-xr-xr-x 1 root wheel 29072 May 5 14:24 umoscom.ko* -r-xr-xr-x 1 root wheel 25224 May 5 14:24 umoscom.ko.symbols* -r-xr-xr-x 1 root wheel 57016 May 5 14:24 ums.ko* -r-xr-xr-x 1 root wheel 49784 May 5 14:24 ums.ko.symbols* -r-xr-xr-x 1 root wheel 155136 May 5 14:24 unionfs.ko* -r-xr-xr-x 1 root wheel 124600 May 5 14:24 unionfs.ko.symbols* -r-xr-xr-x 1 root wheel 33840 May 5 14:24 uplcom.ko* -r-xr-xr-x 1 root wheel 27816 May 5 14:24 uplcom.ko.symbols* -r-xr-xr-x 1 root wheel 46032 May 5 14:24 urio.ko* -r-xr-xr-x 1 root wheel 43152 May 5 14:24 urio.ko.symbols* -r-xr-xr-x 1 root wheel 678384 May 5 14:24 usb.ko* -r-xr-xr-x 1 root wheel 487936 May 5 14:24 usb.ko.symbols* -r-xr-xr-x 1 root wheel 17360 May 5 14:24 usb_quirk.ko* -r-xr-xr-x 1 root wheel 11920 May 5 14:24 usb_quirk.ko.symbols* -r-xr-xr-x 1 root wheel 44016 May 5 14:24 usb_template.ko* -r-xr-xr-x 1 root wheel 36336 May 5 14:24 usb_template.ko.symbols* -r-xr-xr-x 1 root wheel 38448 May 5 14:24 usfs.ko* -r-xr-xr-x 1 root wheel 28248 May 5 14:24 usfs.ko.symbols* -r-xr-xr-x 1 root wheel 30120 May 5 14:24 uslcom.ko* -r-xr-xr-x 1 root wheel 25704 May 5 14:24 uslcom.ko.symbols* -r-xr-xr-x 1 root wheel 43328 May 5 14:24 uss820dci.ko* -r-xr-xr-x 1 root wheel 28560 May 5 14:24 uss820dci.ko.symbols* -r-xr-xr-x 1 root wheel 84496 May 5 14:24 utopia.ko* -r-xr-xr-x 1 root wheel 73688 May 5 14:24 utopia.ko.symbols* -r-xr-xr-x 1 root wheel 29920 May 5 14:24 uvisor.ko* -r-xr-xr-x 1 root wheel 25344 May 5 14:24 uvisor.ko.symbols* -r-xr-xr-x 1 root wheel 30312 May 5 14:24 uvscom.ko* -r-xr-xr-x 1 root wheel 25952 May 5 14:24 uvscom.ko.symbols* -r-xr-xr-x 1 root wheel 36792 May 5 14:24 viapm.ko* -r-xr-xr-x 1 root wheel 26672 May 5 14:24 viapm.ko.symbols* -r-xr-xr-x 1 root wheel 45696 May 5 14:24 vkbd.ko* -r-xr-xr-x 1 root wheel 32176 May 5 14:24 vkbd.ko.symbols* -r-xr-xr-x 1 root wheel 48392 May 5 14:24 vpo.ko* -r-xr-xr-x 1 root wheel 33400 May 5 14:24 vpo.ko.symbols* -r-xr-xr-x 1 root wheel 14648 May 5 14:24 warp_saver.ko* -r-xr-xr-x 1 root wheel 12576 May 5 14:24 warp_saver.ko.symbols* -r-xr-xr-x 1 root wheel 1150544 May 5 14:24 wlan.ko* -r-xr-xr-x 1 root wheel 932616 May 5 14:24 wlan.ko.symbols* -r-xr-xr-x 1 root wheel 42320 May 5 14:24 wlan_acl.ko* -r-xr-xr-x 1 root wheel 39544 May 5 14:24 wlan_acl.ko.symbols* -r-xr-xr-x 1 root wheel 37888 May 5 14:24 wlan_amrr.ko* -r-xr-xr-x 1 root wheel 36264 May 5 14:24 wlan_amrr.ko.symbols* -r-xr-xr-x 1 root wheel 61912 May 5 14:24 wlan_ccmp.ko* -r-xr-xr-x 1 root wheel 43080 May 5 14:24 wlan_ccmp.ko.symbols* -r-xr-xr-x 1 root wheel 38552 May 5 14:24 wlan_rssadapt.ko* -r-xr-xr-x 1 root wheel 36616 May 5 14:24 wlan_rssadapt.ko.symbols* -r-xr-xr-x 1 root wheel 46480 May 5 14:24 wlan_tkip.ko* -r-xr-xr-x 1 root wheel 38416 May 5 14:24 wlan_tkip.ko.symbols* -r-xr-xr-x 1 root wheel 40408 May 5 14:24 wlan_wep.ko* -r-xr-xr-x 1 root wheel 36648 May 5 14:24 wlan_wep.ko.symbols* -r-xr-xr-x 1 root wheel 36184 May 5 14:24 wlan_xauth.ko* -r-xr-xr-x 1 root wheel 35744 May 5 14:24 wlan_xauth.ko.symbols* -r-xr-xr-x 1 root wheel 156456 May 5 14:24 wpifw.ko* -r-xr-xr-x 1 root wheel 6496 May 5 14:24 wpifw.ko.symbols* -r-xr-xr-x 1 root wheel 3549952 May 5 14:24 xfs.ko* -r-xr-xr-x 1 root wheel 3173032 May 5 14:24 xfs.ko.symbols* -r-xr-xr-x 1 root wheel 5075776 May 5 14:24 zfs.ko* -r-xr-xr-x 1 root wheel 4138392 May 5 14:24 zfs.ko.symbols* -r-xr-xr-x 1 root wheel 52080 May 5 14:24 zlib.ko* -r-xr-xr-x 1 root wheel 20920 May 5 14:24 zlib.ko.symbols* > On Tuesday 05 May 2009, Chao Shin wrote: >> Hi Hans, >> There is new dmesg with debug=15, but I can't catch difference... >> > > If you type: > > ll /boot/kernel > > Do all the modules have the same date? > > There is a fuse4bsd module there which I suspect is out of date. > > --HPS > _______________________________________________ > 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" -- The Power to Serve From quakelee at geekcn.org Tue May 5 07:28:02 2009 From: quakelee at geekcn.org (Chao Shin) Date: Tue May 5 07:28:09 2009 Subject: current couldn't attach usb mouse In-Reply-To: <200905050919.51551.hselasky@c2i.net> References: <200905041556.18646.hselasky@c2i.net> <200905050919.51551.hselasky@c2i.net> Message-ID: Hi Hans, I disabled fuse.ko and reboot box, nothing changed [root@currentpark] ~# kldstat Id Refs Address Size Name 1 1 0xffffffff80100000 c1b1e8 kernel > On Tuesday 05 May 2009, Chao Shin wrote: >> Hi Hans, >> There is new dmesg with debug=15, but I can't catch difference... >> > > If you type: > > ll /boot/kernel > > Do all the modules have the same date? > > There is a fuse4bsd module there which I suspect is out of date. > > --HPS > _______________________________________________ > 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" -- The Power to Serve From hselasky at c2i.net Tue May 5 07:35:48 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue May 5 07:35:54 2009 Subject: current couldn't attach usb mouse In-Reply-To: References: <200905050919.51551.hselasky@c2i.net> Message-ID: <200905050938.20963.hselasky@c2i.net> On Tuesday 05 May 2009, Chao Shin wrote: > Hi Hans, > > I disabled fuse.ko and reboot box, nothing changed > > [root@currentpark] ~# kldstat > Id Refs Address Size Name > 1 1 0xffffffff80100000 c1b1e8 kernel > Then you need to build a kernel with debugging and get a backtrace: options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. When you get to the debugger prompt at boot, type "bt" for backtrace. --HPS From 000.fbsd at quip.cz Tue May 5 07:49:21 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue May 5 07:49:29 2009 Subject: ata FLUSHCACHE timeout errors? [patch] In-Reply-To: <20090416104803.O88758@rust.salford.ac.uk> References: <49E4CED7.2040206@jrv.org> <49E69F7C.9020402@jrv.org> <20090416104803.O88758@rust.salford.ac.uk> Message-ID: <49FFEF7C.6030005@quip.cz> Mark Powell wrote: > On Wed, 15 Apr 2009, James R. Van Artsdalen wrote: > >> James R. Van Artsdalen wrote: >> >>> I am getting many FLUSHCACHE timeout errors during "zfs recv" >>> operations. >> >> >> This patch fixes this. PR to be filed. >> In addition this causes any ata request that times out to print the >> timeout, since it's going to be the timeout itself that's likely wrong. > > > This is well known and had been repeated ad. inf.. Problem is, it never > got addressed: > > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting > > Attached is an 8-CURRENT patch which makes the ata timeout a tuneable. > Shamelessy ripped off the FreeNAS patch on the above url. > Cheers. Is there any possibility to have it committed in to the tree? It seems useful, I have timeout problems [READ_DMA timed out] on few machines and this (tunable / longer timeout) should definitely fix it. Miroslav Lachman From quakelee at geekcn.org Tue May 5 07:50:45 2009 From: quakelee at geekcn.org (Chao Shin) Date: Tue May 5 07:50:52 2009 Subject: current couldn't attach usb mouse In-Reply-To: <200905050938.20963.hselasky@c2i.net> References: <200905050919.51551.hselasky@c2i.net> <200905050938.20963.hselasky@c2i.net> Message-ID: ? Tue, 05 May 2009 15:38:20 +0800?Hans Petter Selasky ??: > On Tuesday 05 May 2009, Chao Shin wrote: >> Hi Hans, >> >> I disabled fuse.ko and reboot box, nothing changed >> >> [root@currentpark] ~# kldstat >> Id Refs Address Size Name >> 1 1 0xffffffff80100000 c1b1e8 kernel >> > Because my box have no ps/2 mouse and keyborad interface, so after I entered kdb, the keyboard can not work any more... any idea? > Then you need to build a kernel with debugging and get a backtrace: > > options KDB # Enable kernel debugger support. > options DDB # Support DDB. > options GDB # Support remote GDB. > > When you get to the debugger prompt at boot, type "bt" for backtrace. > > --HPS > _______________________________________________ > 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" -- The Power to Serve From hselasky at c2i.net Tue May 5 07:54:29 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue May 5 07:54:36 2009 Subject: current couldn't attach usb mouse In-Reply-To: References: <200905050938.20963.hselasky@c2i.net> Message-ID: <200905050957.01216.hselasky@c2i.net> On Tuesday 05 May 2009, Chao Shin wrote: > ? Tue, 05 May 2009 15:38:20 +0800?Hans Petter Selasky > > ??: > > On Tuesday 05 May 2009, Chao Shin wrote: > >> Hi Hans, > >> > >> I disabled fuse.ko and reboot box, nothing changed > >> > >> [root@currentpark] ~# kldstat > >> Id Refs Address Size Name > >> 1 1 0xffffffff80100000 c1b1e8 kernel > > Because my box have no ps/2 mouse and keyborad interface, so after I > entered kdb, the keyboard can not work any more... > any idea? Hi Chao, What is printed on the screen? You can also try adding these options: options KDB_UNATTENDED # reboot by default options PANIC_REBOOT_WAIT_TIME=10 #seconds --HPS > > > Then you need to build a kernel with debugging and get a backtrace: > > > > options KDB # Enable kernel debugger support. > > options DDB # Support DDB. > > options GDB # Support remote GDB. > > > > When you get to the debugger prompt at boot, type "bt" for backtrace. > > > > --HPS > > _______________________________________________ > > 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 quakelee at geekcn.org Tue May 5 08:06:26 2009 From: quakelee at geekcn.org (Chao Shin) Date: Tue May 5 08:06:33 2009 Subject: current couldn't attach usb mouse In-Reply-To: <200905050957.01216.hselasky@c2i.net> References: <200905050938.20963.hselasky@c2i.net> <200905050957.01216.hselasky@c2i.net> Message-ID: >> > On Tuesday 05 May 2009, Chao Shin wrote: >> >> Hi Hans, >> >> >> >> I disabled fuse.ko and reboot box, nothing changed >> >> >> >> [root@currentpark] ~# kldstat >> >> Id Refs Address Size Name >> >> 1 1 0xffffffff80100000 c1b1e8 kernel >> >> Because my box have no ps/2 mouse and keyborad interface, so after I >> entered kdb, the keyboard can not work any more... >> any idea? > > Hi Chao, > > What is printed on the screen? > > You can also try adding these options: > > options KDB_UNATTENDED # reboot by default > options PANIC_REBOOT_WAIT_TIME=10 #seconds > > --HPS But my box didn't panic after booting, only usb mouse couldn't recognized. I don't understand what you want to see. > > >> >> > Then you need to build a kernel with debugging and get a backtrace: >> > >> > options KDB # Enable kernel debugger >> support. >> > options DDB # Support DDB. >> > options GDB # Support remote GDB. >> > >> > When you get to the debugger prompt at boot, type "bt" for backtrace. >> > >> > --HPS >> > _______________________________________________ >> > 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" > > > _______________________________________________ > 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" -- The Power to Serve From hselasky at c2i.net Tue May 5 08:38:20 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue May 5 08:38:27 2009 Subject: current couldn't attach usb mouse In-Reply-To: References: <200905050957.01216.hselasky@c2i.net> Message-ID: <200905051040.53708.hselasky@c2i.net> On Tuesday 05 May 2009, Chao Shin wrote: > >> > On Tuesday 05 May 2009, Chao Shin wrote: > >> >> Hi Hans, > >> >> > >> >> I disabled fuse.ko and reboot box, nothing changed > >> >> > >> >> [root@currentpark] ~# kldstat > >> >> Id Refs Address Size Name > >> >> 1 1 0xffffffff80100000 c1b1e8 kernel > >> > >> Because my box have no ps/2 mouse and keyborad interface, so after I > >> entered kdb, the keyboard can not work any more... > >> any idea? > > > > Hi Chao, > > > > What is printed on the screen? > > > > You can also try adding these options: > > > > options KDB_UNATTENDED # reboot by default > > options PANIC_REBOOT_WAIT_TIME=10 #seconds > > > > --HPS > > But my box didn't panic after booting, only usb mouse couldn't recognized. > I don't understand what you want to see. Sorry, I'm mixing with another error report. Try this: 1) Boot without the USB mouse plugged in. 2) Run: sysctl hw.usb2.uhci.debug=15 3) Plug your USB mouse. 4) Unplug your USB mouse. Send dmesg. --HPS From quakelee at geekcn.org Tue May 5 09:05:55 2009 From: quakelee at geekcn.org (Chao Shin) Date: Tue May 5 09:06:02 2009 Subject: current couldn't attach usb mouse In-Reply-To: <200905051040.53708.hselasky@c2i.net> References: <200905050957.01216.hselasky@c2i.net> <200905051040.53708.hselasky@c2i.net> Message-ID: ? Tue, 05 May 2009 16:40:53 +0800?Hans Petter Selasky ??: > sysctl hw.usb2.uhci.debug=15 This is my dmesg in attchement. -- The Power to Serve -------------- next part -------------- ?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 #5: Tue May 5 14:05:24 CST 2009 root@currentpark.intra.umessage.com.cn:/usr/obj/usr/src/sys/UMESSAGE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1795.51-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 1012195328 (965 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f00000 (3) failed acpi0: reservation of 1000000, 3e5ffc00 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xecb8-0xecbf mem 0xfea00000-0xfeafffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M vgapci1: mem 0xfeb00000-0xfebfffff at device 2.1 on pci0 uhci0: port 0xff20-0xff3f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f10 usbus0: on uhci0 uhci1: port 0xff00-0xff1f irq 17 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f10 usbus1: on uhci1 ehci0: mem 0xfe9fbc00-0xfe9fbfff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: waiting for BIOS to give up control usbus2: EHCI version 1.0 usbus2: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.4 on pci0 pci3: on pcib3 bge0: mem 0xfe6f0000-0xfe6fffff irq 16 at device 0.0 on pci3 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:1a:a0:e1:31:eb bge0: [ITHREAD] uhci2: port 0xff80-0xff9f irq 23 at device 29.0 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0000 usbus3: on uhci2 uhci3: port 0xff60-0xff7f irq 17 at device 29.1 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0000 usbus4: on uhci3 uhci4: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x0000 usbus5: on uhci4 ehci1: mem 0xff980800-0xff980bff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfec0-0xfecf,0xecc0-0xeccf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xfe40-0xfe47,0xfe50-0xfe53,0xfe60-0xfe67,0xfe70-0xfe73,0xfed0-0xfedf,0xecd0-0xecdf irq 20 at device 31.5 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atrtc0: port 0x70-0x7f irq 8 on acpi0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 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 928092806000928 device_attach: est1 attach returned 6 p4tcc1: on cpu1 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xccfff,0xcd000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 uhci_interrupt: host system error usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ad0: 152587MB at ata0-master SATA300 uhci_interrupt: host system error ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 GEOM: ad0: geometry does not match label (255h,63s != 16h,63s). GEOM_LABEL: Label for provider ad0a is ufsid/49f98454ff52b98f. GEOM_LABEL: Label for provider ad0a is ufs/root. GEOM_LABEL: Label for provider ad0d is ufsid/49f9845b4cbc1341. GEOM_LABEL: Label for provider ad0d is ufs/var. GEOM_LABEL: Label for provider ad0e is ufsid/49f98455b2c7e9e5. GEOM_LABEL: Label for provider ad0e is ufs/tmp. GEOM_LABEL: Label for provider ad0f is ufsid/49f9845405ff03de. GEOM_LABEL: Label for provider ad0f is ufs/home. GEOM_LABEL: Label for provider ad0g is ufsid/49f98456bbb9c493. GEOM_LABEL: Label for provider ad0g is ufs/usr. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub6: 6 ports with 6 removable, self powered acd0: DVDROM at ata1-master SATA150 lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! Root mount waiting for: usbus6 Trying to mount root from ufs:/dev/ufs/root GEOM_LABEL: Label ufsid/49f98454ff52b98f removed. GEOM_LABEL: Label ufsid/49f9845405ff03de removed. GEOM_LABEL: Label ufsid/49f98455b2c7e9e5 removed. GEOM_LABEL: L <11a8>/dev/ufs/home: FILE SYSTEM CLEbAN; SKIPPING CHECKS el ufsid/49f98456bbb9c493 removed. GEOM_LABEL: Label ufsid/49f9845b4c 13 41 removed. ugen4.2: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 bge0: link state changed to UP uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 3. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 4. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 5. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 3. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 4. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 5. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 3. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 4. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 5. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_roothub_exec:2514: type=0x23 request=0x01 wLen=0x0000 wValue=0x0010 wIndex=0x0002 uhci_roothub_exec:2624: UR_CLEAR_PORT_FEATURE port=2 feature=16 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_roothub_exec:2514: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2396: Activating SOFs! uhci_interrupt: host system error uhci_interrupt:1461: uhci_interrupt: host controller halted uhci_dumpregs:696: usbus1 regs: cmd=0080, sts=0028, intr=000f, frnum=0010, flbase=00000040, sof=0040, portsc1=0080, portsc2=0181 uhci_dump_qh:769: QH(0xffffff00013df800) at 0x013df802: h_next=0x013df782 e_next=0x00000001 uhci_dump_qh:769: QH(0xffffff00013df780) at 0x013df782: h_next=0x013df702 e_next=0x00000001 uhci_dump_qh:769: QH(0xffffff00013df700) at 0x013df702: h_next=0x013df682 e_next=0x00000001 uhci_dump_qh:769: QH(0xffffff00013df680) at 0x013df682: h_next=0x00000001 e_next=0x013df600 uhci_portreset:2411: uhci port 2 reset, status0 = 0x0280 uhci_portreset:2428: uhci port 2 reset, status1 = 0x0183 uhci_portreset:2441: uhci port 2 iteration 0, status = 0x0187 uhci_portreset:2441: uhci port 2 iteration 1, status = 0x0185 uhci_portreset:2479: uhci port 2 reset, status2 = 0x0185 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_roothub_exec:2514: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_roothub_exec:2624: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_pipe_init:3043: pipe=0xffffff0001a208d8, addr=0, endpt=0, mode=0 (1) uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 1. uhci_setup_standard_chain:1666: addr=0 endpt=0 sumlen=8 speed=1 uhci_setup_standard_chain:1827: nexttog=0; data before transfer: TD(0xffffff000168ad00) at 0x0168ad04 = link=0x00000001 status=0x1d8003ff token=0x00e0002d buffer=0x286f6260 TD(0xffffff000168ad00) td_next=-T td_status=-ACTIVE-IOC-LS, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:923: 0xffffff0001b3ab00 to 0xffffff00013df800 uhci_check_transfer:1391: xfer=0xfffffffe406f6148 is still active uhci_interrupt: host system error uhci_interrupt:1461: uhci_interrupt: host controller halted uhci_dumpregs:696: usbus1 regs: cmd=0080, sts=0028, intr=000f, frnum=0010, flbase=00000040, sof=0040, portsc1=0080, portsc2=0185 uhci_dump_qh:769: QH(0xffffff0001b3ab00) at 0x01b3ab02: h_next=0x013df782 e_next=0x0168ad04 uhci_dump_qh:769: QH(0xffffff00013df780) at 0x013df782: h_next=0x013df702 e_next=0x00000001 uhci_dump_qh:769: QH(0xffffff00013df700) at 0x013df702: h_next=0x013df682 e_next=0x00000001 uhci_dump_qh:769: QH(0xffffff00013df680) at 0x013df682: h_next=0x00000001 e_next=0x013df600 uhci_check_transfer:1391: xfer=0xfffffffe406f6148 is still active uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 3. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 4. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 5. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_timeout:1498: xfer=0xfffffffe406f6148 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=20 _uhci_remove_qh:979: 0xffffff0001b3ab00 from 0xffffff0001b3ab00 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=5 _uhci_remove_qh:979: 0xffffff0001b3ab00 from 0xffffff00013df800 usb2_alloc_device:1574: set address 2 failed (USB_ERR_TIMEOUT, ignored) uhci_setup_standard_chain:1666: addr=2 endpt=0 sumlen=16 speed=1 uhci_setup_standard_chain:1827: nexttog=0; data before transfer: TD(0xffffff000168ad00) at 0x0168ad04 = link=0x0168acc4 status=0x1c8003ff token=0x00e0022d buffer=0x286f6260 TD(0xffffff000168ad00) td_next=-VF td_status=-ACTIVE-LS, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 TD(0xffffff000168acc0) at 0x0168acc4 = link=0x0168ac84 status=0x3c8003ff token=0x00e80269 buffer=0x286f6268 TD(0xffffff000168acc0) td_next=-VF td_status=-ACTIVE-LS-SPD, errcnt=3, actlen=0 pid=69,addr=2,endpt=0,D=1,maxlen=8 TD(0xffffff000168ac80) at 0x0168ac84 = link=0x00000001 status=0x1d8003ff token=0xffe802e1 buffer=0x00000000 TD(0xffffff000168ac80) td_next=-T td_status=-ACTIVE-IOC-LS, errcnt=3, actlen=0 pid=e1,addr=2,endpt=0,D=1,maxlen=0 _uhci_append_qh:923: 0xffffff0001d40480 to 0xffffff00013df800 uhci_check_transfer:1391: xfer=0xfffffffe406f6148 is still active uhci_timeout:1498: xfer=0xfffffffe406f6148 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=20 _uhci_remove_qh:979: 0xffffff0001d40480 from 0xffffff0001d40480 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=5 _uhci_remove_qh:979: 0xffffff0001d40480 from 0xffffff00013df800 usb2_alloc_device:1612: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_roothub_exec:2514: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2396: Activating SOFs! uhci_interrupt: host system error uhci_interrupt:1461: uhci_interrupt: host controller halted uhci_dumpregs:696: usbus1 regs: cmd=0080, sts=0028, intr=000f, frnum=0010, flbase=00000040, sof=0040, portsc1=0080, portsc2=0185 uhci_dump_qh:769: QH(0xffffff00013df800) at 0x013df802: h_next=0x013df782 e_next=0x00000001 uhci_dump_qh:769: QH(0xffffff00013df780) at 0x013df782: h_next=0x013df702 e_next=0x00000001 uhci_dump_qh:769: QH(0xffffff00013df700) at 0x013df702: h_next=0x013df682 e_next=0x00000001 uhci_dump_qh:769: QH(0xffffff00013df680) at 0x013df682: h_next=0x00000001 e_next=0x013df600 uhci_portreset:2411: uhci port 2 reset, status0 = 0x0288 uhci_portreset:2428: uhci port 2 reset, status1 = 0x018b uhci_portreset:2441: uhci port 2 iteration 0, status = 0x018f uhci_portreset:2441: uhci port 2 iteration 1, status = 0x0185 uhci_portreset:2479: uhci port 2 reset, status2 = 0x0185 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_roothub_exec:2514: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_roothub_exec:2624: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_setup_standard_chain:1666: addr=0 endpt=0 sumlen=8 speed=1 uhci_setup_standard_chain:1827: nexttog=0; data before transfer: TD(0xffffff0001717100) at 0x01717104 = link=0x00000001 status=0x1d8003ff token=0x00e0002d buffer=0x286f6260 TD(0xffffff0001717100) td_next=-T td_status=-ACTIVE-IOC-LS, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:923: 0xffffff0001d41380 to 0xffffff00013df800 uhci_check_transfer:1391: xfer=0xfffffffe406f6148 is still active uhci_timeout:1498: xfer=0xfffffffe406f6148 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=20 _uhci_remove_qh:979: 0xffffff0001d41380 from 0xffffff0001d41380 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=5 _uhci_remove_qh:979: 0xffffff0001d41380 from 0xffffff00013df800 usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) uhci_setup_standard_chain:1666: addr=2 endpt=0 sumlen=16 speed=1 uhci_setup_standard_chain:1827: nexttog=0; data before transfer: TD(0xffffff00013ee900) at 0x013ee904 = link=0x013ee8c4 status=0x1c8003ff token=0x00e0022d buffer=0x286f6260 TD(0xffffff00013ee900) td_next=-VF td_status=-ACTIVE-LS, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 TD(0xffffff00013ee8c0) at 0x013ee8c4 = link=0x013ee884 status=0x3c8003ff token=0x00e80269 buffer=0x286f6268 TD(0xffffff00013ee8c0) td_next=-VF td_status=-ACTIVE-LS-SPD, errcnt=3, actlen=0 pid=69,addr=2,endpt=0,D=1,maxlen=8 TD(0xffffff00013ee880) at 0x013ee884 = link=0x00000001 status=0x1d8003ff token=0xffe802e1 buffer=0x00000000 TD(0xffffff00013ee880) td_next=-T td_status=-ACTIVE-IOC-LS, errcnt=3, actlen=0 pid=e1,addr=2,endpt=0,D=1,maxlen=0 _uhci_append_qh:923: 0xffffff0001d41280 to 0xffffff00013df800 uhci_check_transfer:1391: xfer=0xfffffffe406f6148 is still active uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 3. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 4. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 5. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_timeout:1498: xfer=0xfffffffe406f6148 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=20 _uhci_remove_qh:979: 0xffffff0001d41280 from 0xffffff0001d41280 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=5 _uhci_remove_qh:979: 0xffffff0001d41280 from 0xffffff00013df800 usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! uhci_roothub_exec:2514: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2396: Activating SOFs! uhci_interrupt: host system error uhci_interrupt:1461: uhci_interrupt: host controller halted uhci_dumpregs:696: usbus1 regs: cmd=0080, sts=0028, intr=000f, frnum=0010, flbase=00000040, sof=0040, portsc1=0080, portsc2=0185 uhci_dump_qh:769: QH(0xffffff00013df800) at 0x013df802: h_next=0x013df782 e_next=0x00000001 uhci_dump_qh:769: QH(0xffffff00013df780) at 0x013df782: h_next=0x013df702 e_next=0x00000001 uhci_dump_qh:769: QH(0xffffff00013df700) at 0x013df702: h_next=0x013df682 e_next=0x00000001 uhci_dump_qh:769: QH(0xffffff00013df680) at 0x013df682: h_next=0x00000001 e_next=0x013df600 uhci_portreset:2411: uhci port 2 reset, status0 = 0x0288 uhci_portreset:2428: uhci port 2 reset, status1 = 0x018b uhci_portreset:2441: uhci port 2 iteration 0, status = 0x018f uhci_portreset:2441: uhci port 2 iteration 1, status = 0x0185 uhci_portreset:2479: uhci port 2 reset, status2 = 0x0185 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_roothub_exec:2514: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_roothub_exec:2624: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_setup_standard_chain:1666: addr=0 endpt=0 sumlen=8 speed=1 uhci_setup_standard_chain:1827: nexttog=0; data before transfer: TD(0xffffff00013f0500) at 0x013f0504 = link=0x00000001 status=0x1d8003ff token=0x00e0002d buffer=0x286f6260 TD(0xffffff00013f0500) td_next=-T td_status=-ACTIVE-IOC-LS, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:923: 0xffffff0001d40200 to 0xffffff00013df800 uhci_check_transfer:1391: xfer=0xfffffffe406f6148 is still active uhci_timeout:1498: xfer=0xfffffffe406f6148 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=20 _uhci_remove_qh:979: 0xffffff0001d40200 from 0xffffff0001d40200 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=5 _uhci_remove_qh:979: 0xffffff0001d40200 from 0xffffff00013df800 usb2_req_re_enumerate:1519: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) uhci_setup_standard_chain:1666: addr=2 endpt=0 sumlen=16 speed=1 uhci_setup_standard_chain:1827: nexttog=0; data before transfer: TD(0xffffff0001440100) at 0x01440104 = link=0x014400c4 status=0x1c8003ff token=0x00e0022d buffer=0x286f6260 TD(0xffffff0001440100) td_next=-VF td_status=-ACTIVE-LS, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 TD(0xffffff00014400c0) at 0x014400c4 = link=0x01440084 status=0x3c8003ff token=0x00e80269 buffer=0x286f6268 TD(0xffffff00014400c0) td_next=-VF td_status=-ACTIVE-LS-SPD, errcnt=3, actlen=0 pid=69,addr=2,endpt=0,D=1,maxlen=8 TD(0xffffff0001440080) at 0x01440084 = link=0x00000001 status=0x1d8003ff token=0xffe802e1 buffer=0x00000000 TD(0xffffff0001440080) td_next=-T td_status=-ACTIVE-IOC-LS, errcnt=3, actlen=0 pid=e1,addr=2,endpt=0,D=1,maxlen=0 _uhci_append_qh:923: 0xffffff0001b3ac80 to 0xffffff00013df800 uhci_check_transfer:1391: xfer=0xfffffffe406f6148 is still active uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 3. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 4. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 5. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_timeout:1498: xfer=0xfffffffe406f6148 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=20 _uhci_remove_qh:979: 0xffffff0001b3ac80 from 0xffffff0001b3ac80 uhci_device_done:1848: xfer=0xfffffffe406f6148, pipe=0xffffff0001a208d8, error=5 _uhci_remove_qh:979: 0xffffff0001b3ac80 from 0xffffff00013df800 usb2_req_re_enumerate:1533: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:417: could not allocate new device! uhci_roothub_exec:2514: type=0x23 request=0x01 wLen=0x0000 wValue=0x0001 wIndex=0x0002 uhci_roothub_exec:2624: UR_CLEAR_PORT_FEATURE port=2 feature=1 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 3. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 4. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 5. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 3. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 4. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 5. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 3. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 4. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 5. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_roothub_exec:2514: type=0x23 request=0x01 wLen=0x0000 wValue=0x0010 wIndex=0x0002 uhci_roothub_exec:2624: UR_CLEAR_PORT_FEATURE port=2 feature=16 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 3. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 4. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 5. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 3. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3200: Some USB transfer is active on 4. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 5. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 0. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_set_hw_power:3182: uhci_set_hw_power:3204: Power save on 1. uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_roothub_exec:2514: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 From peterjeremy at optushome.com.au Tue May 5 09:19:19 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue May 5 09:19:45 2009 Subject: Fighting for the power. In-Reply-To: <49FE5EC8.3040205@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <49FE29A4.30507@root.org> <49FE5EC8.3040205@FreeBSD.org> Message-ID: <20090505091914.GA94521@server.vk2pj.dyndns.org> On 2009-May-04 06:19:36 +0300, Alexander Motin wrote: >System will always have tons of waiting callouts and timeouts to be >handled. So timer will be always needed. Working timer. Yes, but a tickless kernel will let the CPU stay asleep for longer since it doesn't need to wake up just to discover there's nothing to do. >number of idle disk write activity, but I haven't very succeeded. Even >in my quite simple icewm X environment something was persistently >writing something every several minutes. I have found and disabled some >activity sources, but it was not enough. I've recently (in the last few days) worked through minimising the write activity on the SSD in my laptop (I wrote a tool that monitors write transfers via devstat(3) and it would be possible to track down the actual modified files via kqueue(2) if necessary). I'm now down to about two chunks of about 13 transfers each per hour (due to entopy saving and ntp.drift updating). The changes I made were: 1) Mount the SSD filesystems as noatime 2) Turn off all local syslogging (syslog is directed to another system when my laptop is at home, lost otherwise). 3) Change maillog rotation to size instead of daily 4) Run save-entropy once per hour instead of every 11 minutes. 5) Patch the save-entropy script to reduce the write load when it's run (see PR bin/134225). 6) Use a swap-back /tmp By default, ntpd updates ntp.drift every hour. I might do some monitoring and see if the drift changes significantly over time. If it doesn't, hard-wiring the ntp.drift file will save some writes. (The other option would be to tweak the relevant timecounter until the actual drift is 0 and then stop ntpd and just run something like ntpdate regularly to compensate for the remaining drift). Experimentation shows that firefox3 generates a fairly heavy write load - continuously updating several internal databases whilst it is in use. Turning off the "Block reported attack sites" and "Block reported web forgeries" options under 'Security' stops it updating urlclassifier3.sqlite. Note that when you update a file, you implicitly update the associated inode and the filesystem superbock. > What would happen in some >complicated KDE/Gnome environment I am just afraid to think. I'd recommend avoiding a heavyweight window manager and using something like fwvm or vtwm. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090505/6bdcadd5/attachment.pgp From hselasky at c2i.net Tue May 5 10:19:28 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue May 5 10:19:35 2009 Subject: current couldn't attach usb mouse In-Reply-To: References: <200905051040.53708.hselasky@c2i.net> Message-ID: <200905051222.00887.hselasky@c2i.net> On Tuesday 05 May 2009, Chao Shin wrote: > ? Tue, 05 May 2009 16:40:53 +0800?Hans Petter Selasky > > ??: > > sysctl hw.usb2.uhci.debug=15 > > This is my dmesg in attchement. Try the attached patch to uhci.c. --HPS -------------- next part -------------- A non-text attachment was scrubbed... Name: uhci.c.diff Type: text/x-diff Size: 3648 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090505/a2f5bc41/uhci.c.bin From jimmiejaz at gmail.com Tue May 5 06:39:56 2009 From: jimmiejaz at gmail.com (Jimmie James) Date: Tue May 5 11:18:08 2009 Subject: pci regression: "panic: resource_list_alloc: resource entry is busy" References: 200903041011.24606.jhb@freebsd.org Message-ID: <49FFD81A.5040501@gmail.com> Why is this affecting 7.2-STABLE? Does anyone test anything before a release anymore? This doesn't apply to 7.2: atching file vga_pci.c using Plan A... Hunk #1 failed at 42. Hunk #2 succeeded at 118 (offset -20 lines). Hunk #3 succeeded at 146 (offset -20 lines). 1 out of 3 hunks failed--saving rejects to vga_pci.c.rej Hmm... Ignoring the trailing garbage. done > John Baldwin wrote: > Probably at some point the agp and drm drivers for Intel will be merged which > would fix this, but this patch should help for now. We used to be leaking > a small portion of KVA due to this problem before. > > --- //depot/vendor/freebsd/src/sys/dev/pci/vga_pci.c 2008/09/19 19:15:30 > +++ //depot/user/jhb/acpipci/dev/pci/vga_pci.c 2009/03/04 15:32:08 > @@ -42,12 +42,20 @@ > #include > #include > #include > +#include > +#include > > #include > #include > > +struct vga_resource { > + struct resource *vr_res; > + int vr_refs; > +}; > + > struct vga_pci_softc { > device_t vga_msi_child; /* Child driver using MSI. */ > + struct vga_resource vga_res[PCIR_MAX_BAR_0 + 1]; > }; > > static int > @@ -130,7 +138,27 @@ > vga_pci_alloc_resource(device_t dev, device_t child, int type, int *rid, > u_long start, u_long end, u_long count, u_int flags) > { > + struct vga_pci_softc *sc; > + int bar; > > + switch (type) { > + case SYS_RES_MEMORY: > + case SYS_RES_IOPORT: > + /* > + * For BARs, we cache the resource so that we only allocate it > + * from the PCI bus once. > + */ > + bar = PCI_RID2BAR(*rid); > + if (bar < 0 || bar > PCIR_MAX_BAR_0) > + return (NULL); > + sc = device_get_softc(dev); > + if (sc->vga_res[bar].vr_res == NULL) > + sc->vga_res[bar].vr_res = bus_alloc_resource(dev, type, > + rid, start, end, count, flags); > + if (sc->vga_res[bar].vr_res != NULL) > + sc->vga_res[bar].vr_refs++; > + return (sc->vga_res[bar].vr_res); > + } > return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); > } > > @@ -138,6 +166,37 @@ > vga_pci_release_resource(device_t dev, device_t child, int type, int rid, > struct resource *r) > { > + struct vga_pci_softc *sc; > + int bar, error; > + > + switch (type) { > + case SYS_RES_MEMORY: > + case SYS_RES_IOPORT: > + /* > + * For BARs, we release the resource from the PCI bus > + * when the last child reference goes away. > + */ > + bar = PCI_RID2BAR(rid); > + if (bar < 0 || bar > PCIR_MAX_BAR_0) > + return (EINVAL); > + sc = device_get_softc(dev); > + if (sc->vga_res[bar].vr_res == NULL) > + return (EINVAL); > + KASSERT(sc->vga_res[bar].vr_res == r, > + ("vga_pci resource mismatch")); > + if (sc->vga_res[bar].vr_refs > 1) { > + sc->vga_res[bar].vr_refs--; > + return (0); > + } > + KASSERT(sc->vga_res[bar].vr_refs > 0, > + ("vga_pci resource reference count underflow")); > + error = bus_release_resource(dev, type, rid, r); > + if (error == 0) { > + sc->vga_res[bar].vr_res = NULL; > + sc->vga_res[bar].vr_refs = 0; > + } > + return (error); > + } > > return (bus_release_resource(dev, type, rid, r)); > } > -- Over the years I've come to regard you as people I've met. From quakelee at geekcn.org Tue May 5 12:30:06 2009 From: quakelee at geekcn.org (Chao Shin) Date: Tue May 5 12:30:15 2009 Subject: current couldn't attach usb mouse In-Reply-To: <200905051222.00887.hselasky@c2i.net> References: <200905051040.53708.hselasky@c2i.net> <200905051222.00887.hselasky@c2i.net> Message-ID: Great! after patched my mouse can work now, there is new dmesg segment below: bge0: link state changed to UP ugen1.2: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 Thank you very much! Would you commit this patch to current? BTW: usb2.0 is great work, I have test umass device on current, it is 6 times faster than 1.0. Do you have any plan make usb2.0 to support kdb or mountroot> ? > On Tuesday 05 May 2009, Chao Shin wrote: >> ? Tue, 05 May 2009 16:40:53 +0800?Hans Petter Selasky >> >> >> ??: >> > sysctl hw.usb2.uhci.debug=15 >> >> This is my dmesg in attchement. > > Try the attached patch to uhci.c. > > --HPS -- The Power to Serve From hselasky at c2i.net Tue May 5 12:51:39 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue May 5 12:51:45 2009 Subject: current couldn't attach usb mouse In-Reply-To: References: <200905051222.00887.hselasky@c2i.net> Message-ID: <200905051454.11249.hselasky@c2i.net> Hi Chao, On Tuesday 05 May 2009, Chao Shin wrote: > Great! after patched my mouse can work now, there is new dmesg segment > below: > > bge0: link state changed to UP > ugen1.2: at usbus1 > ums0: on usbus1 > ums0: 3 buttons and [XYZ] coordinates ID=0 > > Thank you very much! > Would you commit this patch to current? Yes, it is going into -current soon. Final patch: http://perforce.freebsd.org/chv.cgi?CH=161615 > > BTW: > usb2.0 is great work, I have test umass device on current, it is 6 times > faster > than 1.0. Thanks. > > Do you have any plan make usb2.0 to support kdb or mountroot> ? Not yet. The problem is USB is multi threaded, while kdb requires single threaded operation. It is a little difficult. Also UKBD was Giant locked last time I checked due to some non-MPSAFE dependencies. This is another issue blocking USB keyboard in KDB. --HPS > > > On Tuesday 05 May 2009, Chao Shin wrote: > >> ? Tue, 05 May 2009 16:40:53 +0800?Hans Petter Selasky > >> > >> > >> ??: > >> > sysctl hw.usb2.uhci.debug=15 > >> > >> This is my dmesg in attchement. > > > > Try the attached patch to uhci.c. > > > > --HPS From paul at paulstewart.org Tue May 5 13:30:56 2009 From: paul at paulstewart.org (Paul Stewart) Date: Tue May 5 13:31:02 2009 Subject: 7.1 to 7.2 upgrade question Message-ID: <000001c9cd85$afe53b70$0fafb250$@org> Hi there. As I'm slowly getting used to FreeBSD (again), I recently upgraded three boxes to 7.2-RELEASE. Two of them were running 7.1-RELEASE and one was running 7.2-RC2 .. Anyways, I used freebsd-update to upgrade - in my previous experiences I would have to do a "make world" etc. etc. Which method is most preferred - source or binary upgrading? I don't mind source upgrading but is it really necessary anymore if using freebsd-update on a regular basis? Thanks, Paul From tinderbox at freebsd.org Tue May 5 13:44:42 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue May 5 13:45:06 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <20090505134439.4DB657302F@freebsd-current.sentex.ca> TB --- 2009-05-05 12:07:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 12:07:35 - starting HEAD tinderbox run for i386/i386 TB --- 2009-05-05 12:07:35 - cleaning the object tree TB --- 2009-05-05 12:08:13 - cvsupping the source tree TB --- 2009-05-05 12:08:13 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-05-05 12:08:23 - building world TB --- 2009-05-05 12:08:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 12:08:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 12:08:23 - TARGET=i386 TB --- 2009-05-05 12:08:23 - TARGET_ARCH=i386 TB --- 2009-05-05 12:08:23 - TZ=UTC TB --- 2009-05-05 12:08:23 - __MAKE_CONF=/dev/null TB --- 2009-05-05 12:08:23 - cd /src TB --- 2009-05-05 12:08:23 - /usr/bin/make -B buildworld >>> World build started on Tue May 5 12:08:25 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 5 13:30:01 UTC 2009 TB --- 2009-05-05 13:30:01 - generating LINT kernel config TB --- 2009-05-05 13:30:01 - cd /src/sys/i386/conf TB --- 2009-05-05 13:30:01 - /usr/bin/make -B LINT TB --- 2009-05-05 13:30:01 - building LINT kernel TB --- 2009-05-05 13:30:01 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 13:30:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 13:30:01 - TARGET=i386 TB --- 2009-05-05 13:30:01 - TARGET_ARCH=i386 TB --- 2009-05-05 13:30:01 - TZ=UTC TB --- 2009-05-05 13:30:01 - __MAKE_CONF=/dev/null TB --- 2009-05-05 13:30:01 - cd /src TB --- 2009-05-05 13:30:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 5 13:30:02 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_base.c cc1: warnings being treated as errors /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:143: warning: initialization makes integer from pointer without a cast /src/sys/netgraph/ng_base.c:144: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer /src/sys/netgraph/ng_base.c:145: warning: (near initialization for 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: initialization makes integer from pointer without a cast *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-05 13:44:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-05 13:44:38 - ERROR: failed to build lint kernel TB --- 2009-05-05 13:44:38 - 4621.52 user 440.46 system 5822.88 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From ben at wanderview.com Tue May 5 13:48:50 2009 From: ben at wanderview.com (Ben Kelly) Date: Tue May 5 13:48:58 2009 Subject: [patch] zfs kmem fragmentation In-Reply-To: References: Message-ID: <8FB38AF4-3464-45AA-A6B2-96308EC49407@wanderview.com> On May 4, 2009, at 6:17 PM, Jeff Roberson wrote: > On Sat, 2 May 2009, Ben Kelly wrote: >> Hello all, >> >> Lately I've been looking into the "kmem too small" panics that >> often occur with zfs if you don't restrict the arc. What I found >> in my test environment was that everything works well until the >> kmem usage hits the 75% limit set in arc.c. At this point the arc >> is shrunk and slabs are reclaimed from uma. Unfortunately, every >> time this reclamation process runs the kmem space becomes more >> fragmented. The vast majority of the time my machine hits the >> "kmem too small" panic it has over 200MB of kmem space available, >> but the largest fragment is less than 128KB. > > What consumers make requests of kmem for 128kb and over? What > ultimately trips the panic? ZFS buffers range from 512 bytes to 128KB. I don't know of any allocations above 128KB at the moment. In my workload the panic is usually caused by zfs attempting to allocate a 128KB buffer, although sometimes its only doing a 64KB buffer. At one point I hacked in some instrumentation to print the kmem_map vm_map_entry when I touched a sysctl mib. Here's a capture I made during my load test as the fragmentation was occurring: http://www.wanderview.com/svn/public/misc/zfs/fragmentation.txt I also added some debug later to show the consumers of the allocations. The vast majority of them were from the opensolaris subsystem. Unfortunately I don't have a capture of that output handy. >> Ideally things would be arranged to free memory without >> fragmentation. I have tried a few things along those lines, but >> none of them have been successful so far. I'm going to continue >> that work, but in the meantime I've put together a patch that tries >> to avoid fragmentation by slowing kmem growth before the aggressive >> reclamation process is required: >> >> http://www.wanderview.com/svn/public/misc/zfs/zfs_kmem_limit.diff >> >> It uses the following heuristics to do this: >> >> - Start arc_c at arc_c_min instead of arc_c_max. This causes the >> system to warm up more slowly. >> - Half the rate arc_c grows when kmem exceeds kmem_slow_growth_thresh >> - Stop arc_c growth when kmem exceeds kmem_target >> - Evict arc data when the kmem exceeds kmem_target >> - If kmem usage exceeds kmem_target then ask the pagedaemon to >> reclaim pages >> - If the largest kmem fragment is less than kmem_fragment_target >> then ask the pagedaemon to reclaim pages >> - If the largest kmem fragment is less than a kmem_fragment_thresh >> then force the aggressve kmem/arc reclamation process >> >> The defaults for the various targets and thresholds are: >> >> kmem_reclaim_threshold = 7/8 kmem >> kmem_target = 3/4 kmem >> kmem_slow_growth_threshold = 5/8 kmem >> kmem_fragment_target = 1/8 kmem >> kmem_fragment_thresh = 1/16 kmem >> >> With this patch I've been able to run my load tests with the >> default arc size with kmem values of 512MB to 700MB. I tried one >> loaded run with a 300MB kmem, but it panic'ed due to legitimate, >> non-fragmented kmem exhaustion. >> > > May I suggest an alternate approach; Have you considered placing > zfs in its own kernel submap? If all of its allocations are of a > like size, fragmentation won't be an issue and it can be constrained > to a fixed size without placing pressure on other kmem_map > consumers. This is the approach taken for the buffer cache. It > makes a good deal of sense. If arc can be taught to handle > allocation failures we could eliminate the panic entirely by simply > causing arc to run out of space and flush more buffers. > > Do you believe this would also address the problem? Using a separate submap might help. It seems that the fragmentation is occurring due to the interaction of the smaller and larger buffers within zfs. I believe in opensolaris data buffers and meta-data buffers are allocated from separate arenas. We don't do this currently and it may be the cause of some of the fragmentation. It also occurred to me that it might be nice if the arc could somehow share the buffer cache directly. Unfortunately I am moving this Friday and probably will be unable to really look at this for the next couple weeks. Thanks. - Ben From ben at wanderview.com Tue May 5 14:18:33 2009 From: ben at wanderview.com (Ben Kelly) Date: Tue May 5 14:18:40 2009 Subject: [patch] corrupt memstat_kvm_malloc(3) output and dtrace Message-ID: <9A637B27-7C89-49BA-8385-A5B2D5D54BB3@wanderview.com> Hi all, While debugging a problem recently with Alexander Leidinger we noticed that crashinfo(8) was producing corrupt vmstat -m output. After doing some digging it appears that memstat_kvm_malloc(3) might have been broken by this commit: http://svn.freebsd.org/viewvc/base?view=revision&revision=179222 The problem is that memstat_kvm_malloc(3) assumes that malloc_type_internal starts with an array of malloc_types_stats structures. This assumption is no longer true, though, as mti_probes was inserted at the start of the structure. It appears that this (untested) patch might fix the problem: http://www.wanderview.com/svn/public/misc/zfs/vmstat_kvm_malloc.diff I'm not very familiar with dtrace, though. Does anyone know if this would cause problems? Thanks. - Ben From ohartman at zedat.fu-berlin.de Tue May 5 14:41:59 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Tue May 5 14:42:11 2009 Subject: Weird slowlyness of subversion-freebsd with current Message-ID: <4A004FE3.2070702@zedat.fu-berlin.de> Hello, since the last portupgrade when dev/subversion-freebsd got updates, I realize a drastic slowdown since then on FreeBSD 8.0-CURRENT/amd64 boxes. Is there any known issue and if, how to circumvent ... Regards, Oliver From tinderbox at freebsd.org Tue May 5 15:19:20 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue May 5 15:19:27 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090505151915.955DA7302F@freebsd-current.sentex.ca> TB --- 2009-05-05 13:44:39 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 13:44:39 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-05 13:44:39 - cleaning the object tree TB --- 2009-05-05 13:45:17 - cvsupping the source tree TB --- 2009-05-05 13:45:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-05 13:45:28 - building world TB --- 2009-05-05 13:45:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 13:45:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 13:45:28 - TARGET=pc98 TB --- 2009-05-05 13:45:28 - TARGET_ARCH=i386 TB --- 2009-05-05 13:45:28 - TZ=UTC TB --- 2009-05-05 13:45:28 - __MAKE_CONF=/dev/null TB --- 2009-05-05 13:45:28 - cd /src TB --- 2009-05-05 13:45:28 - /usr/bin/make -B buildworld >>> World build started on Tue May 5 13:45:30 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 5 15:06:56 UTC 2009 TB --- 2009-05-05 15:06:56 - generating LINT kernel config TB --- 2009-05-05 15:06:56 - cd /src/sys/pc98/conf TB --- 2009-05-05 15:06:56 - /usr/bin/make -B LINT TB --- 2009-05-05 15:06:56 - building LINT kernel TB --- 2009-05-05 15:06:56 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 15:06:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 15:06:56 - TARGET=pc98 TB --- 2009-05-05 15:06:56 - TARGET_ARCH=i386 TB --- 2009-05-05 15:06:56 - TZ=UTC TB --- 2009-05-05 15:06:56 - __MAKE_CONF=/dev/null TB --- 2009-05-05 15:06:56 - cd /src TB --- 2009-05-05 15:06:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 5 15:06:56 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_base.c cc1: warnings being treated as errors /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:143: warning: initialization makes integer from pointer without a cast /src/sys/netgraph/ng_base.c:144: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer /src/sys/netgraph/ng_base.c:145: warning: (near initialization for 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: initialization makes integer from pointer without a cast *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-05 15:19:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-05 15:19:15 - ERROR: failed to build lint kernel TB --- 2009-05-05 15:19:15 - 4480.66 user 442.88 system 5675.99 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From thompsa at FreeBSD.org Tue May 5 15:42:46 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Tue May 5 15:42:52 2009 Subject: current couldn't attach usb mouse In-Reply-To: References: <200905051040.53708.hselasky@c2i.net> <200905051222.00887.hselasky@c2i.net> Message-ID: <20090505154239.GE40769@citylink.fud.org.nz> This has been committed, thanks for reporting and Hans for fixing. On Tue, May 05, 2009 at 08:28:49PM +0800, Chao Shin wrote: > Great! after patched my mouse can work now, there is new dmesg segment > below: > > bge0: link state changed to UP > ugen1.2: at usbus1 > ums0: on usbus1 > ums0: 3 buttons and [XYZ] coordinates ID=0 > > Thank you very much! > Would you commit this patch to current? > > BTW: > usb2.0 is great work, I have test umass device on current, it is 6 times > faster > than 1.0. > > Do you have any plan make usb2.0 to support kdb or mountroot> ? > > >> On Tuesday 05 May 2009, Chao Shin wrote: >>> ??? Tue, 05 May 2009 16:40:53 +0800???Hans Petter Selasky >>> >>> >>> ??????: >>> > sysctl hw.usb2.uhci.debug=15 >>> >>> This is my dmesg in attchement. >> >> Try the attached patch to uhci.c. >> >> --HPS > > > > -- > The Power to Serve > _______________________________________________ > 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 tinderbox at freebsd.org Tue May 5 15:59:23 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue May 5 15:59:41 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090505155919.EF3677302F@freebsd-current.sentex.ca> TB --- 2009-05-05 13:54:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 13:54:24 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-05-05 13:54:24 - cleaning the object tree TB --- 2009-05-05 13:54:55 - cvsupping the source tree TB --- 2009-05-05 13:54:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-05-05 13:55:05 - building world TB --- 2009-05-05 13:55:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 13:55:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 13:55:05 - TARGET=ia64 TB --- 2009-05-05 13:55:05 - TARGET_ARCH=ia64 TB --- 2009-05-05 13:55:05 - TZ=UTC TB --- 2009-05-05 13:55:05 - __MAKE_CONF=/dev/null TB --- 2009-05-05 13:55:05 - cd /src TB --- 2009-05-05 13:55:05 - /usr/bin/make -B buildworld >>> World build started on Tue May 5 13:55:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 5 15:42:36 UTC 2009 TB --- 2009-05-05 15:42:36 - generating LINT kernel config TB --- 2009-05-05 15:42:36 - cd /src/sys/ia64/conf TB --- 2009-05-05 15:42:36 - /usr/bin/make -B LINT TB --- 2009-05-05 15:42:36 - building LINT kernel TB --- 2009-05-05 15:42:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 15:42:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 15:42:36 - TARGET=ia64 TB --- 2009-05-05 15:42:36 - TARGET_ARCH=ia64 TB --- 2009-05-05 15:42:36 - TZ=UTC TB --- 2009-05-05 15:42:36 - __MAKE_CONF=/dev/null TB --- 2009-05-05 15:42:36 - cd /src TB --- 2009-05-05 15:42:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 5 15:42:36 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:143: warning: initialization makes integer from pointer without a cast /src/sys/netgraph/ng_base.c:143: error: initializer element is not computable at load time /src/sys/netgraph/ng_base.c:143: error: (near initialization for 'ng_deadnode.nd_magic') /src/sys/netgraph/ng_base.c:144: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer /src/sys/netgraph/ng_base.c:145: warning: (near initialization for 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: initialization makes integer from pointer without a cast *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-05 15:59:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-05 15:59:19 - ERROR: failed to build lint kernel TB --- 2009-05-05 15:59:19 - 6189.92 user 448.20 system 7495.84 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From sam at freebsd.org Tue May 5 16:17:32 2009 From: sam at freebsd.org (Sam Leffler) Date: Tue May 5 16:17:38 2009 Subject: Fighting for the power. [syslogd] In-Reply-To: <20090505091914.GA94521@server.vk2pj.dyndns.org> References: <49FE1826.4060000@FreeBSD.org> <49FE29A4.30507@root.org> <49FE5EC8.3040205@FreeBSD.org> <20090505091914.GA94521@server.vk2pj.dyndns.org> Message-ID: <4A00669A.10105@freebsd.org> Peter Jeremy wrote: > On 2009-May-04 06:19:36 +0300, Alexander Motin wrote: > ...snip... >> number of idle disk write activity, but I haven't very succeeded. Even >> in my quite simple icewm X environment something was persistently >> writing something every several minutes. I have found and disabled some >> activity sources, but it was not enough. >> > > I've recently (in the last few days) worked through minimising the > write activity on the SSD in my laptop (I wrote a tool that monitors > write transfers via devstat(3) and it would be possible to track down > the actual modified files via kqueue(2) if necessary). I'm now down > to about two chunks of about 13 transfers each per hour (due to entopy > saving and ntp.drift updating). The changes I made were: > 1) Mount the SSD filesystems as noatime > 2) Turn off all local syslogging (syslog is directed to another > system when my laptop is at home, lost otherwise). > Regarding syslogd, I've considered adding support to batch/buffer writes to workaround a problem that I consider rather important: syslogd is not started early enough in the boot so it's not available to log msgs from other applications. In particular I hit this because wpa_supplicant logs via syslog but when it's started at boot syslogd isn't available and since wpa_supplicant operates in a chroot'd environment it cannot defer connecting until syslogd has started up so nothing is ever logged. I think we want syslogd to start very early and deal with the case where the local filesystem is not present. My plan was to buffer msgs and then flush them at a later time. But this might also be used to buffer log activity so local disk activity is staged (e.g. for the laptop or embedded use). Maybe someone else has a better idea but I think we need to do something soon. Sam From zec at freebsd.org Tue May 5 16:51:58 2009 From: zec at freebsd.org (Marko Zec) Date: Tue May 5 16:52:46 2009 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <20090505155919.EF3677302F@freebsd-current.sentex.ca> References: <20090505155919.EF3677302F@freebsd-current.sentex.ca> Message-ID: <200905051227.51590.zec@freebsd.org> Mea culpa, should be fixed by r191827 now. Marko On Tuesday 05 May 2009 11:59:19 FreeBSD Tinderbox wrote: > TB --- 2009-05-05 13:54:24 - tinderbox 2.6 running on > freebsd-current.sentex.ca TB --- 2009-05-05 13:54:24 - starting HEAD > tinderbox run for ia64/ia64 TB --- 2009-05-05 13:54:24 - cleaning the > object tree > TB --- 2009-05-05 13:54:55 - cvsupping the source tree > TB --- 2009-05-05 13:54:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s > /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-05-05 13:55:05 - building > world > TB --- 2009-05-05 13:55:05 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-05-05 13:55:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-05-05 13:55:05 - TARGET=ia64 > TB --- 2009-05-05 13:55:05 - TARGET_ARCH=ia64 > TB --- 2009-05-05 13:55:05 - TZ=UTC > TB --- 2009-05-05 13:55:05 - __MAKE_CONF=/dev/null > TB --- 2009-05-05 13:55:05 - cd /src > TB --- 2009-05-05 13:55:05 - /usr/bin/make -B buildworld > > >>> World build started on Tue May 5 13:55:06 UTC 2009 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> World build completed on Tue May 5 15:42:36 UTC 2009 > > TB --- 2009-05-05 15:42:36 - generating LINT kernel config > TB --- 2009-05-05 15:42:36 - cd /src/sys/ia64/conf > TB --- 2009-05-05 15:42:36 - /usr/bin/make -B LINT > TB --- 2009-05-05 15:42:36 - building LINT kernel > TB --- 2009-05-05 15:42:36 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-05-05 15:42:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-05-05 15:42:36 - TARGET=ia64 > TB --- 2009-05-05 15:42:36 - TARGET_ARCH=ia64 > TB --- 2009-05-05 15:42:36 - TZ=UTC > TB --- 2009-05-05 15:42:36 - __MAKE_CONF=/dev/null > TB --- 2009-05-05 15:42:36 - cd /src > TB --- 2009-05-05 15:42:36 - /usr/bin/make -B buildkernel KERNCONF=LINT > > >>> Kernel build for LINT started on Tue May 5 15:42:36 UTC 2009 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > > [...] > /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from > integer without a cast /src/sys/netgraph/ng_base.c:143: warning: > initialization makes integer from pointer without a cast > /src/sys/netgraph/ng_base.c:143: error: initializer element is not > computable at load time /src/sys/netgraph/ng_base.c:143: error: (near > initialization for 'ng_deadnode.nd_magic') /src/sys/netgraph/ng_base.c:144: > warning: initialization makes pointer from integer without a cast > /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer > /src/sys/netgraph/ng_base.c:145: warning: (near initialization for > 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: > initialization makes integer from pointer without a cast *** Error code 1 > > Stop in /obj/ia64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-05-05 15:59:19 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2009-05-05 15:59:19 - ERROR: failed to build lint kernel > TB --- 2009-05-05 15:59:19 - 6189.92 user 448.20 system 7495.84 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full > _______________________________________________ > 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 tinderbox at freebsd.org Tue May 5 17:36:07 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue May 5 17:36:14 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20090505173603.D96C67302F@freebsd-current.sentex.ca> TB --- 2009-05-05 15:59:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 15:59:20 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-05-05 15:59:20 - cleaning the object tree TB --- 2009-05-05 15:59:52 - cvsupping the source tree TB --- 2009-05-05 15:59:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-05-05 16:00:04 - building world TB --- 2009-05-05 16:00:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 16:00:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 16:00:04 - TARGET=powerpc TB --- 2009-05-05 16:00:04 - TARGET_ARCH=powerpc TB --- 2009-05-05 16:00:04 - TZ=UTC TB --- 2009-05-05 16:00:04 - __MAKE_CONF=/dev/null TB --- 2009-05-05 16:00:04 - cd /src TB --- 2009-05-05 16:00:04 - /usr/bin/make -B buildworld >>> World build started on Tue May 5 16:00:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 5 17:24:24 UTC 2009 TB --- 2009-05-05 17:24:24 - generating LINT kernel config TB --- 2009-05-05 17:24:24 - cd /src/sys/powerpc/conf TB --- 2009-05-05 17:24:24 - /usr/bin/make -B LINT TB --- 2009-05-05 17:24:24 - building LINT kernel TB --- 2009-05-05 17:24:24 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 17:24:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 17:24:24 - TARGET=powerpc TB --- 2009-05-05 17:24:24 - TARGET_ARCH=powerpc TB --- 2009-05-05 17:24:24 - TZ=UTC TB --- 2009-05-05 17:24:24 - __MAKE_CONF=/dev/null TB --- 2009-05-05 17:24:24 - cd /src TB --- 2009-05-05 17:24:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 5 17:24:24 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/netgraph/ng_base.c cc1: warnings being treated as errors /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:143: warning: initialization makes integer from pointer without a cast /src/sys/netgraph/ng_base.c:144: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer /src/sys/netgraph/ng_base.c:145: warning: (near initialization for 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: initialization makes integer from pointer without a cast *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-05 17:36:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-05 17:36:03 - ERROR: failed to build lint kernel TB --- 2009-05-05 17:36:03 - 4650.95 user 428.40 system 5803.43 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From shuvaev at physik.uni-wuerzburg.de Tue May 5 17:48:36 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Tue May 5 17:48:43 2009 Subject: gunzip | tar reports broken pipe during OOO build on amd64. Message-ID: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> Hello all! I was trying to upgrade editors/openoffice.org-2 recently and build failed for me at: -------------------------------------------------------------- packimages -- version: 1.16 packimages: packing ../unxfbsdx.pro/bin/images_industrial.zip finished. cd ../unxfbsdx.pro/misc && gunzip -c /usr/ports/editors/openoffice.org-2/work/OOH680_m18/external_images/ooo_crystal_images-1.tar.gz | ( tar -xf - ) && touch crystal.flag ---* tg_merge.mk *--- Running processes: 0 1 module(s): instsetoo_native need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /usr/ports/editors/openoffice.org-2/work/OOH680_m18/instsetoo_native/packimages Attention: if you build and deliver the above module(s) you may prolongue your the build issuing command "build --from instsetoo_native" *** Error code 1 Stop in /usr/ports/editors/openoffice.org-2. -------------------------------------------------------------- The reason appeared to be the first part of the command "gunzip -c ... | ( tar -xf - ) && touch ..." which exited with non-zero exit status (141) and "touch ..." was not called. Running the command manually has showed that gunzip was complaining about broken pipe (however the archive was extracted successfully). The attached patch has fixed the problem however I don't feel it is the proper solution. The problem seems to be in that specific archive but I'm not sure... ~> uname -a FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue May 5 00:16:39 CEST 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 My 0.02$, Alexey. -------------- next part -------------- --- instsetoo_native/packimages/makefile.mk.orig 2007-06-06 16:20:38.000000000 +0200 +++ instsetoo_native/packimages/makefile.mk 2009-05-05 17:01:57.000000000 +0200 @@ -79,7 +79,7 @@ # unpack the Crystal icon set $(MISC)$/crystal.flag : $(CRYSTAL_TARBALL) - cd $(MISC) && gunzip -c $(CRYSTAL_TARBALL) | ( tar -xf - ) && $(TOUCH) $(@:f) + cd $(MISC) && tar -xf $(CRYSTAL_TARBALL) && $(TOUCH) $(@:f) .IF "$(GUI)"=="UNX" chmod -R g+w $(MISC)$/crystal .ENDIF From keramida at ceid.upatras.gr Tue May 5 17:53:21 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Tue May 5 17:53:29 2009 Subject: 7.1 to 7.2 upgrade question In-Reply-To: <000001c9cd85$afe53b70$0fafb250$@org> (Paul Stewart's message of "Tue, 5 May 2009 09:30:41 -0400") References: <000001c9cd85$afe53b70$0fafb250$@org> Message-ID: <87ljpbwi5v.fsf@kobe.laptop> On Tue, 5 May 2009 09:30:41 -0400, "Paul Stewart" wrote: > Hi there. > > As I'm slowly getting used to FreeBSD (again), I recently upgraded > three boxes to 7.2-RELEASE. Two of them were running 7.1-RELEASE and > one was running 7.2-RC2 .. > > Anyways, I used freebsd-update to upgrade - in my previous experiences > I would have to do a "make world" etc. etc. > > Which method is most preferred - source or binary upgrading? I don't > mind source upgrading but is it really necessary anymore if using > freebsd-update on a regular basis? If you don't need local patches or a custom kernel, and you can use the GENERIC kernel configured to match your hardware setup, then it probably makes a lot of sense to use freebsd-update. It will usually be much faster than compiling everything from source. From tinderbox at freebsd.org Tue May 5 17:58:54 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue May 5 17:59:01 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090505175851.0EE1B7302F@freebsd-current.sentex.ca> TB --- 2009-05-05 16:25:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 16:25:09 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-05-05 16:25:10 - cleaning the object tree TB --- 2009-05-05 16:25:42 - cvsupping the source tree TB --- 2009-05-05 16:25:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-05-05 16:25:52 - building world TB --- 2009-05-05 16:25:52 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 16:25:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 16:25:52 - TARGET=sparc64 TB --- 2009-05-05 16:25:52 - TARGET_ARCH=sparc64 TB --- 2009-05-05 16:25:52 - TZ=UTC TB --- 2009-05-05 16:25:52 - __MAKE_CONF=/dev/null TB --- 2009-05-05 16:25:52 - cd /src TB --- 2009-05-05 16:25:52 - /usr/bin/make -B buildworld >>> World build started on Tue May 5 16:25:53 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 5 17:46:14 UTC 2009 TB --- 2009-05-05 17:46:14 - generating LINT kernel config TB --- 2009-05-05 17:46:14 - cd /src/sys/sparc64/conf TB --- 2009-05-05 17:46:14 - /usr/bin/make -B LINT TB --- 2009-05-05 17:46:14 - building LINT kernel TB --- 2009-05-05 17:46:14 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 17:46:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-05 17:46:14 - TARGET=sparc64 TB --- 2009-05-05 17:46:14 - TARGET_ARCH=sparc64 TB --- 2009-05-05 17:46:14 - TZ=UTC TB --- 2009-05-05 17:46:14 - __MAKE_CONF=/dev/null TB --- 2009-05-05 17:46:14 - cd /src TB --- 2009-05-05 17:46:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 5 17:46:14 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/netgraph/ng_base.c:142: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:143: warning: initialization makes integer from pointer without a cast /src/sys/netgraph/ng_base.c:143: error: initializer element is not computable at load time /src/sys/netgraph/ng_base.c:143: error: (near initialization for 'ng_deadnode.nd_magic') /src/sys/netgraph/ng_base.c:144: warning: initialization makes pointer from integer without a cast /src/sys/netgraph/ng_base.c:145: warning: braces around scalar initializer /src/sys/netgraph/ng_base.c:145: warning: (near initialization for 'ng_deadnode.lastline') /src/sys/netgraph/ng_base.c:145: warning: initialization makes integer from pointer without a cast *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-05 17:58:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-05 17:58:51 - ERROR: failed to build lint kernel TB --- 2009-05-05 17:58:51 - 4436.18 user 419.07 system 5621.04 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From rea-fbsd at codelabs.ru Tue May 5 18:59:06 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue May 5 18:59:12 2009 Subject: gunzip | tar reports broken pipe during OOO build on amd64. In-Reply-To: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> Message-ID: <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> Alexey, good day. Tue, May 05, 2009 at 07:48:31PM +0200, Alexey Shuvaev wrote: > The reason appeared to be the first part of the command > "gunzip -c ... | ( tar -xf - ) && touch ..." > which exited with non-zero exit status (141) and "touch ..." was not called. > Running the command manually has showed that gunzip was complaining about > broken pipe (however the archive was extracted successfully). Yes, 141 means that SIGPIPE was delivered. This in turn means that 'tar -xf -' exited before gunzip had finished its job and gunzip had tried to write more data to the pipe. Could I ask to do some debugging: 1. run 'gunzip -c ooo_crystal_images-1.tar.gz > crystal.tar' 2. run 'cat crystal.tar | (tar -xf -) && echo OK' and look for the results. 3. do 'md5 ooo_crystal_images-1.tar.gz' For the last point, I have ----- MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 ----- but this tar.gz was taken from OOO 3.x. If yours have some other checksum, could you place it somewhere where I can download it? My .tar.gz unpacks without any errors, but my -CURRENT is from 3rd of May. Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From rbgarga at gmail.com Tue May 5 19:55:32 2009 From: rbgarga at gmail.com (Renato Botelho) Date: Tue May 5 19:55:38 2009 Subject: 7.1 to 7.2 upgrade question In-Reply-To: <87ljpbwi5v.fsf@kobe.laptop> References: <000001c9cd85$afe53b70$0fafb250$@org> <87ljpbwi5v.fsf@kobe.laptop> Message-ID: <747dc8f30905051255j79b11662v716c2456c01d2b8a@mail.gmail.com> On Tue, May 5, 2009 at 2:53 PM, Giorgos Keramidas wrote: > On Tue, 5 May 2009 09:30:41 -0400, "Paul Stewart" wrote: >> Hi there. >> >> As I'm slowly getting used to FreeBSD (again), I recently upgraded >> three boxes to 7.2-RELEASE. ?Two of them were running 7.1-RELEASE and >> one was running 7.2-RC2 .. >> >> Anyways, I used freebsd-update to upgrade - in my previous experiences >> I would have to do a "make world" etc. etc. >> >> Which method is most preferred - source or binary upgrading? ?I don't >> mind source upgrading but is it really necessary anymore if using >> freebsd-update on a regular basis? > > If you don't need local patches or a custom kernel, and you can use the > GENERIC kernel configured to match your hardware setup, then it probably > makes a lot of sense to use freebsd-update. ?It will usually be much > faster than compiling everything from source. I don't know if it's officially supported, but I did an hybrid upgrade using freebsd-update for the base and building the custom kernel from sources, it worked fine and is still much faster than build everything. -- Renato Botelho From jhb at FreeBSD.org Tue May 5 20:26:22 2009 From: jhb at FreeBSD.org (John Baldwin) Date: Tue May 5 20:26:28 2009 Subject: pci regression: "panic: resource_list_alloc: resource entry is busy" In-Reply-To: <49FFD81A.5040501@gmail.com> References: 200903041011.24606.jhb@freebsd.org <49FFD81A.5040501@gmail.com> Message-ID: <4A00A0ED.7000003@FreeBSD.org> Jimmie James wrote: > Why is this affecting 7.2-STABLE? Does anyone test anything before a > release anymore? > This doesn't apply to 7.2: > > atching file vga_pci.c using Plan A... > Hunk #1 failed at 42. > Hunk #2 succeeded at 118 (offset -20 lines). > Hunk #3 succeeded at 146 (offset -20 lines). > 1 out of 3 hunks failed--saving rejects to vga_pci.c.rej > Hmm... Ignoring the trailing garbage. > done It affects -stable because I merged some changes to the PCI bus code after the release (thus, 7.2-release is not affected as you seem to imply). Note that the machine I tested the merge on is a server box that doesn't use DRM (and drm(4) isn't in GENERIC) so I didn't run into this during testing. If you update your tree it should be fixed now. -- John Baldwin From rea-fbsd at codelabs.ru Tue May 5 21:07:29 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue May 5 21:07:36 2009 Subject: 7.1 to 7.2 upgrade question In-Reply-To: <747dc8f30905051255j79b11662v716c2456c01d2b8a@mail.gmail.com> References: <000001c9cd85$afe53b70$0fafb250$@org> <87ljpbwi5v.fsf@kobe.laptop> <747dc8f30905051255j79b11662v716c2456c01d2b8a@mail.gmail.com> Message-ID: Renato, Tue, May 05, 2009 at 04:55:15PM -0300, Renato Botelho wrote: > On Tue, May 5, 2009 at 2:53 PM, Giorgos Keramidas > wrote: > > If you don't need local patches or a custom kernel, and you can use the > > GENERIC kernel configured to match your hardware setup, then it probably > > makes a lot of sense to use freebsd-update. ?It will usually be much > > faster than compiling everything from source. > > I don't know if it's officially supported, but I did an hybrid upgrade > using freebsd-update for the base and building the custom kernel > from sources, it worked fine and is still much faster than build > everything. In principle, you can run into some errors, like KVM size mismatches (and other ABI changes) if your kernel (that you build from sources) and updated base will differ. But you'll immediately notice it ;)) And for most cases such way should work fine. My two cents. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From eitanadlerlist at gmail.com Tue May 5 21:55:56 2009 From: eitanadlerlist at gmail.com (Eitan Adler) Date: Tue May 5 21:56:03 2009 Subject: Fighting for the power. In-Reply-To: <20090504011421.GI6901@egr.msu.edu> References: <49FE1826.4060000@FreeBSD.org> <20090504011421.GI6901@egr.msu.edu> Message-ID: <4A00AFEB.7010001@gmail.com> Adam McDougall wrote: > On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: > > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. > Could some of these tips get added to 11.15 Power and Resource Management? I'm sure many people who don't regularly read the mailing lists would like to use these tips. -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen From alex.wilkinson at dsto.defence.gov.au Tue May 5 22:31:54 2009 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Tue May 5 22:32:01 2009 Subject: Fighting for the power. In-Reply-To: <4A00AFEB.7010001@gmail.com> References: <49FE1826.4060000@FreeBSD.org> <20090504011421.GI6901@egr.msu.edu> <4A00AFEB.7010001@gmail.com> Message-ID: <20090505222958.GK12123@stlux503.dsto.defence.gov.au> 0n Tue, May 05, 2009 at 05:30:19PM -0400, Eitan Adler wrote: >Adam McDougall wrote: >> On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: >> >> I would like to summarize some of my knowledge on reducing FreeBSD power >> consumption and describe some new things I have recently implemented in >> 8-CURRENT. The main character of this story is my 12" Acer TravelMate >> 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under >> amd64 8-CURRENT. >> >Could some of these tips get added to 11.15 Power and Resource >Management? I'm sure many people who don't regularly read the mailing >lists would like to use these tips. I agree. This was an extremely useful and informative thread of discussion to read. (Now how to remember it all ?) -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From bazerka at beardz.net Wed May 6 00:48:06 2009 From: bazerka at beardz.net (Jase Thew) Date: Wed May 6 00:48:14 2009 Subject: Another USB mouse failing to attach with current, post-USB2 Message-ID: <4A00DACA.1010500@beardz.net> Hi, I installed 8.0-CURRENT a few months ago to test it with the hardware in my machine. Everything worked fine until USB2 replaced USB in the tree, and upon a rebuild, my Razer Copperhead USB mouse stopped attaching to ums. I've updated my sources and rebuilt everything around 3 hours ago to ensure that I'm up-to-date with HEAD. Please find attached the relevant lines from my verbose dmesg.boot and also usbconfig outputs for the device. The mouse itself doesn't conform to the HID spec somewhat ( see usb/118670 [1] for some history ) so it has to rely on the hid_is_collection test rather than reading the descriptor direct in the ums probe routine. However, the hid_is_collection test now fails since USB2 replaced USB. I've tested with my kludge patch from usb/118670 and the mouse works perfectly with it, so USB2 supports the mouse fine apart from the hid_is_collection test no longer recognising it. If any additional info is required, I'll be happy to supply it. Thanks in advance, Jase. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/118670 -------------- next part -------------- uhci0: port 0xd000-0xd01f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd000 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x0f10 usbus0: on uhci0 uhci1: port 0xd100-0xd11f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd100 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x0f10 usbus1: on uhci1 uhci2: port 0xd500-0xd51f irq 18 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd500 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x0f10 usbus2: on uhci2 ehci0: mem 0xea205000-0xea2053ff irq 18 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xea205000 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 uhci3: port 0xd200-0xd21f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd200 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x003a usbus4: on uhci3 uhci4: port 0xd300-0xd31f irq 19 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd300 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup = 0x0010 usbus5: on uhci4 uhci5: port 0xd400-0xd41f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd400 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup = 0x0010 usbus6: on uhci5 ehci1: mem 0xea204000-0xea2043ff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xea204000 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen0.2: at usbus0 uhub8: on usbus0 ugen1.2: at usbus1 uhid0: on usbus1 uhub8: 3 ports with 0 removable, bus powered ugen2.2: at usbus2 uhid1: on usbus2 ukbd0: on usbus2 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 ukbd_set_leds_callback:554: error=USB_ERR_STALLED ugen0.3: at usbus0 ukbd1: on usbus0 kbd3 at ukbd1 kbd3: ukbd1, generic (0), config:0x0, flags:0x3d0000 ugen0.4: at usbus0 ums0: on usbus0 ums0: 3 buttons and [XY] coordinates ID=2 ugen2.3: at usbus2 uhub9: on usbus2 ugen0.5: at usbus0 uhub9: 4 ports with 2 removable, bus powered ugen2.4: at usbus2 ukbd2: on usbus2 kbd: new array size 8 kbd4 at ukbd2 kbd4: ukbd2, generic (0), config:0x0, flags:0x3d0000 uhid2: on usbus2 -------------- next part -------------- sheesh8# usbconfig -u 2 -a 2 do_request 0x81 0x06 0x2200 0 0x100 REQUEST = <0x05 0x01 0x09 0x02 0xa1 0x01 0x09 0x01 0xa1 0x00 0x05 0x09 0x19 0x01 0x29 0x07 0x15 0x00 0x25 0x01 0x95 0x08 0x75 0x01 0x81 0x02 0x06 0x00 0xff 0x09 0x40 0x95 0x02 0x75 0x08 0x15 0x81 0x25 0x7f 0x81 0x02 0x05 0x01 0x09 0x38 0x15 0x81 0x25 0x7f 0x75 0x08 0x95 0x01 0x81 0x06 0x09 0x30 0x09 0x31 0x16 0x00 0x80 0x26 0xff 0x7f 0x75 0x10 0x95 0x02 0x81 0x06 0xc0 0xc0><)%u@u%8%u01&u> -------------- next part -------------- ugen2.2: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0008 idVendor = 0x1532 idProduct = 0x0101 bcdDevice = 0x2100 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0000 bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x003b bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x0000 bmAttributes = 0x00a0 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0001 bInterfaceClass = 0x0003 bInterfaceSubClass = 0x0000 bInterfaceProtocol = 0x0002 iInterface = 0x0000 Additional Descriptor bLength = 0x09 bDescriptorType = 0x21 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x09, 0x21, 0x01, 0x10, 0x00, 0x01, 0x22, 0x49, 0x08 | 0x00 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0003 wMaxPacketSize = 0x0010 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x0000 bNumEndpoints = 0x0001 bInterfaceClass = 0x0003 bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x0001 iInterface = 0x0000 Additional Descriptor bLength = 0x09 bDescriptorType = 0x21 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x09, 0x21, 0x01, 0x10, 0x00, 0x01, 0x22, 0x2f, 0x08 | 0x00 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0003 wMaxPacketSize = 0x0010 bInterval = 0x0008 bRefresh = 0x0000 bSynchAddress = 0x0000 From robillard.etienne at gmail.com Wed May 6 01:54:54 2009 From: robillard.etienne at gmail.com (Etienne Robillard) Date: Wed May 6 01:55:00 2009 Subject: Upgrading to gnome 2.26 problem Message-ID: <20090505212704.411fac32@marina> Hi, I have some problems running gnome-session 2.26 on freebsd8. It appears that dbus is missing a required library and so makes gnome-session unusable. I also have some difficulties building hal, and thought it might be related. Plus, it was running fine on 2.24. Problems started when upgrading with portupgrade gnome to 2.26. So I was thinking that perhaps i need to make another buildworld since it might depends on recent libusb changes, but I'm just guessing. Would there be an alternative or quick fix for avoiding the buildworld/installworld step or is there something in -CURRENT that is required for upgrading fully to gnome 2.26 ? Thanks in advance for your help, erob N.B: I have the following packages installed: libusb-0.1.12_4 xorg-server-1.5.3_6,1 gnome-session-2.26.1 dbus-1.2.4.4 dbus-glib-0.80 X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-CURRENT i386 Current Operating System: FreeBSD marina 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Feb 25 22:26:21 EST 2009 root@marina:/usr/src/sys/i386/compile/GENERIC i386 Build Date: 07 March 2009 04:15:25PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat May 2 00:31:50 2009 (==) Using config file: "/etc/X11/xorg.conf" encoder: 0x4 encoder: 0x2 encoder: 0x5 XRANDR name: VGA-0 Connector: VGA CRT1: INTERNAL_DAC1 DDC reg: 0x64 XRANDR name: DVI-0 Connector: DVI-I CRT2: INTERNAL_DAC2 DFP1: INTERNAL_TMDS1 DDC reg: 0x68 finished output detect: 0 Dac detection success Unhandled monitor type 0 finished output detect: 1 finished all detect before xf86InitialConfiguration Dac detection success Unhandled monitor type 0 after xf86InitialConfiguration Entering TV Save Save TV timing tables saveTimingTables: reading timing tables TV Save done disable primary dac disable primary dac disable primary dac init memmap init common init crtc1 init pll1 freq: 135000000 best_freq: 135000000 best_feedback_div: 20 best_ref_div: 2 best_post_div: 2 restore memmap restore common restore crtc1 restore pll1 finished PLL1 set RMX set primary dac enable primary dac The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". gnome-session[15174]: WARNING: Could not connect to ConsoleKit: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory gnome-session[15174]: CRITICAL: dbus_g_connection_get_connection: assertion `gconnection' failed process 15174: arguments to dbus_connection_send_with_reply_and_block() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 3298. This is normally a bug in some application using the D-Bus library. D-Bus not compiled with backtrace support so unable to print a backtrace gnome-session[15174]: ******************* START ******************************** gnome-session[15174]: Frame 0: 0x805f7d3 <_init+70079> at gnome-session gnome-session[15174]: Frame 1: 0xbfbfffb4 gnome-session[15174]: Frame 2: 0x2903440a at /lib/libc.so.7 gnome-session[15174]: Frame 3: 0x286a8f85 <_dbus_abort+53> at /usr/local/lib/libdbus-1.so.3 gnome-session[15174]: Frame 4: 0x286a4b56 <_dbus_warn_check_failed+134> at /usr/local/lib/libdbus-1.so.3 gnome-session[15174]: Frame 5: 0x2868d528 at /usr/local/lib/libdbus-1.so.3 gnome-session[15174]: Frame 6: 0x8057a2b <_init+37911> at gnome-session gnome-session[15174]: Frame 7: 0x8057b0a <_init+38134> at gnome-session gnome-session[15174]: Frame 8: 0x8060a5c <_init+74824> at gnome-session gnome-session[15174]: Frame 9: 0x8060fd4 <_init+76224> at gnome-session gnome-session[15174]: Frame 10: 0x80503c9 <_init+7605> at gnome-session gnome-session[15174]: ******************* END ********************************** waiting for X server to shut down disable primary dac finished PLL2 finished PLL1 Entering Restore TV Restore TV PLL Restore TVHV Restore TV Restarts Restore Timing Tables Restore TV standard Leaving Restore TV From shuvaev at physik.uni-wuerzburg.de Wed May 6 03:28:40 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Wed May 6 03:28:47 2009 Subject: gunzip | tar reports broken pipe during OOO build on amd64. In-Reply-To: <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> Message-ID: <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> On Tue, May 05, 2009 at 10:59:01PM +0400, Eygene Ryabinkin wrote: > Alexey, good day. > > Tue, May 05, 2009 at 07:48:31PM +0200, Alexey Shuvaev wrote: > > The reason appeared to be the first part of the command > > "gunzip -c ... | ( tar -xf - ) && touch ..." > > which exited with non-zero exit status (141) and "touch ..." was not called. > > Running the command manually has showed that gunzip was complaining about > > broken pipe (however the archive was extracted successfully). > > Yes, 141 means that SIGPIPE was delivered. This in turn means that > 'tar -xf -' exited before gunzip had finished its job and gunzip had > tried to write more data to the pipe. > > Could I ask to do some debugging: > > 1. run 'gunzip -c ooo_crystal_images-1.tar.gz > crystal.tar' > Ok so far. > 2. run 'cat crystal.tar | (tar -xf -) && echo OK' and look for the results. > Ok: ~/tmp> cat crystal.tar | ( tar -xf - ) && echo OK OK > 3. do 'md5 ooo_crystal_images-1.tar.gz' > ~/tmp> md5 crystal.tar MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a > For the last point, I have > ----- > MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 > ----- > but this tar.gz was taken from OOO 3.x. If yours have some other > checksum, could you place it somewhere where I can download it? > Mmmm... not so easy... German universities are not so internet friendly... fsck... But it was taken from official openoffice.org2/OOo_OOH680_m18_source.tar.bz2 tarball... Ping me if it is download error. > My .tar.gz unpacks without any errors, but my -CURRENT is from 3rd of May. > > Thanks! > I'm running amd64 Core2Duo processor with SMP kernel. Can it be that 2 processes (gunzip and tar) are running on different cpu-s and this is some race condition? Not triggered before? > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # > _______________________________________________ > 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 ben at wanderview.com Wed May 6 05:00:21 2009 From: ben at wanderview.com (Ben Kelly) Date: Wed May 6 05:00:28 2009 Subject: [patch] corrupt memstat_kvm_malloc(3) output and dtrace In-Reply-To: <9A637B27-7C89-49BA-8385-A5B2D5D54BB3@wanderview.com> References: <9A637B27-7C89-49BA-8385-A5B2D5D54BB3@wanderview.com> Message-ID: On May 5, 2009, at 10:18 AM, Ben Kelly wrote: > While debugging a problem recently with Alexander Leidinger we > noticed that crashinfo(8) was producing corrupt vmstat -m output. > After doing some digging it appears that memstat_kvm_malloc(3) might > have been broken by this commit: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=179222 > > The problem is that memstat_kvm_malloc(3) assumes that > malloc_type_internal starts with an array of malloc_types_stats > structures. This assumption is no longer true, though, as > mti_probes was inserted at the start of the structure. > > It appears that this (untested) patch might fix the problem: > > http://www.wanderview.com/svn/public/misc/zfs/vmstat_kvm_malloc.diff > > I'm not very familiar with dtrace, though. Does anyone know if this > would cause problems? Just FYI, I was able to recompile and test this patch tonight. It seems to have fixed vmstat -M $core -m output on my machine. - Ben From Achim_Leubner at adaptec.com Wed May 6 08:22:41 2009 From: Achim_Leubner at adaptec.com (Leubner, Achim) Date: Wed May 6 08:22:48 2009 Subject: softdep_move_dependencies panic Message-ID: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> Hi Ed, Hi Scott, We run into a problem if a RAID array goes into an "error" state and is marked "offline". The new aac driver removes the device in this case with device_delete_child() and all commands to that device will be answered using biodone() with flag BIO_ERROR and error EINVAL. But this causes a "softdep_move_dependencies: need merge code" panic in the filesystem. Is there any possibility to avoid this panic? We see it under FreeBSD 7.1 too. Any help is greatly appreciated. Thanks & Regards, Achim =========================== Achim Leubner Software Engineer / RAID drivers ICP vortex GmbH / Adaptec Inc. Phone: +49-351-8718291 From zec at icir.org Wed May 6 09:19:32 2009 From: zec at icir.org (Marko Zec) Date: Wed May 6 09:19:39 2009 Subject: VIMAGE status In-Reply-To: <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> References: <49FC812B.2070305@elischer.org> <200905041015.15332.zec@icir.org> <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> Message-ID: <200905060519.10151.zec@icir.org> On Monday 04 May 2009 10:57:32 Paul B. Mahol wrote: > On 5/4/09, Marko Zec wrote: > > On Monday 04 May 2009 08:53:48 Paul B. Mahol wrote: > > ... > > > >> I'm experiencing strange 'netstat -r' output, perhaps I need to clean > >> /usr/obj/? (I dont have VIMAGE enabled) > > > > You should rebuild your userland regardless whether options VIMAGE in the > > kernel has been enabled or not, see the UPDATING note for details. > > I did, but I will ask again do I need to clean /usr/obj/? No you don't. Could you post the output from 'netstat -r' with pre- and post-r191816 kernel + world builds? Marko From onemda at gmail.com Wed May 6 09:50:14 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed May 6 09:50:20 2009 Subject: VIMAGE status In-Reply-To: <200905060519.10151.zec@icir.org> References: <49FC812B.2070305@elischer.org> <200905041015.15332.zec@icir.org> <3a142e750905040757t5abe64c6m4666bb4eab1abe5d@mail.gmail.com> <200905060519.10151.zec@icir.org> Message-ID: <3a142e750905060250t394ada5bl2798c79b18855746@mail.gmail.com> On 5/6/09, Marko Zec wrote: > On Monday 04 May 2009 10:57:32 Paul B. Mahol wrote: >> On 5/4/09, Marko Zec wrote: >> > On Monday 04 May 2009 08:53:48 Paul B. Mahol wrote: >> > ... >> > >> >> I'm experiencing strange 'netstat -r' output, perhaps I need to clean >> >> /usr/obj/? (I dont have VIMAGE enabled) >> > >> > You should rebuild your userland regardless whether options VIMAGE in >> > the >> > kernel has been enabled or not, see the UPDATING note for details. >> >> I did, but I will ask again do I need to clean /usr/obj/? > > No you don't. > > Could you post the output from 'netstat -r' with pre- and post-r191816 > kernel > + world builds? It was caused by NO_CLEAN=1 option in make.conf(I guess) or I broke it with some other "make install" command under /usr/src .... Clearing /usr/obj/ fixed it. -- Paul From odhiambo at gmail.com Wed May 6 10:06:11 2009 From: odhiambo at gmail.com (=?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?=) Date: Wed May 6 10:06:18 2009 Subject: VIMAGE status In-Reply-To: <49FC812B.2070305@elischer.org> References: <49FC812B.2070305@elischer.org> Message-ID: <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> On Sat, May 2, 2009 at 8:21 PM, Julian Elischer wrote: > The VIMAGE code is nearly all in the the kernel. > > One is now able to make VIMAGE kernels (add options VIMAGE) > though they don't actually allow you to make multiple > vimages instances yet.. > > The VIMAGE option enables all the low level changes needed > throughout the kernel. > > The VIMAGE_GLOBALS option basically sets thing sback to how they were > before. > > Having neither (the default) gives a kernel that is a kind of hybrid. > > The Hybrid state is what will go forward as 'NON-VIMAGE' mode > and the VIMAGE_GLOBALS mode will probably go away in time as > it complicates the code. > > The aim of this mail is to ask people to try add the VIMAGE option > to their regular kernels and try use them as you woudl normally. > You will not yet be able to use any new VIMAGE features but we > should be fully compatible with previous kernels. How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boyz :) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From peterjeremy at optushome.com.au Wed May 6 10:13:07 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed May 6 10:13:15 2009 Subject: hardclock() sources Message-ID: <20090506101301.GA17874@server.vk2pj.dyndns.org> Currently, FreeBSD uses the LAPIC timer to derive both hardclock() and statclock()/profclock() if it exists, otherwise it uses the 8254 and RTC. This presents a problem for using C3 - which stops the LAPIC clock. Some time ago, ariff@ produced a patch to work around a similar problem with C1E on some AMD Turion CPUs: http://people.freebsd.org/~ariff/misc/idlecpu_apic_5.diff A better solution would seem to be to use a HPET periodic timer. Is there a particular reason why code to (at least optionally) support HPET as the timer interrupt hasn't been written? Looking back through the archives, pkh@ has made disparaging remarks about the actual usefulness of HPET (as against the Intel documentation) but I can't find anything that actually talks about using it. Note that supporting HPET as a timer source would provide at least some of the infrastructure that will be needed for a future tickless kernel. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090506/7218f811/attachment.pgp From phk at phk.freebsd.dk Wed May 6 10:16:29 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed May 6 10:16:37 2009 Subject: hardclock() sources In-Reply-To: Your message of "Wed, 06 May 2009 20:13:02 +1000." <20090506101301.GA17874@server.vk2pj.dyndns.org> Message-ID: <6172.1241604986@critter.freebsd.dk> In message <20090506101301.GA17874@server.vk2pj.dyndns.org>, Peter Jeremy write s: >A better solution would seem to be to use a HPET periodic timer. Part of the problem is discovering the timers location early enough. We have long (10 years) talked about doing (at least) two scans of the busses: First scan to allocate missing resources Second scan to get "important" hardware (console, timers) Third scan to find the rest. -- 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 julian at elischer.org Wed May 6 10:47:59 2009 From: julian at elischer.org (Julian Elischer) Date: Wed May 6 10:48:06 2009 Subject: VIMAGE status In-Reply-To: <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> References: <49FC812B.2070305@elischer.org> <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> Message-ID: <4A016ADD.3060004@elischer.org> Odhiambo ????? wrote: > > > On Sat, May 2, 2009 at 8:21 PM, Julian Elischer > wrote: > > The VIMAGE code is nearly all in the the kernel. > > One is now able to make VIMAGE kernels (add options VIMAGE) > though they don't actually allow you to make multiple > vimages instances yet.. > > The VIMAGE option enables all the low level changes needed > throughout the kernel. > > The VIMAGE_GLOBALS option basically sets thing sback to how they > were before. > > Having neither (the default) gives a kernel that is a kind of hybrid. > > The Hybrid state is what will go forward as 'NON-VIMAGE' mode > and the VIMAGE_GLOBALS mode will probably go away in time as > it complicates the code. > > The aim of this mail is to ask people to try add the VIMAGE option > to their regular kernels and try use them as you woudl normally. > You will not yet be able to use any new VIMAGE features but we > should be fully compatible with previous kernels. > > > How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boyz :) VImage code is in -current (hence the -current mailing list) so it is not in 7.2. HOWEVER you can pick up 7.2(ish) kernel sourcce tree which will allow you to substitute in a 7.2 VIMAGE kernel and play with it.. I'll let Marko give you the details. > > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254733744121/+254722743223 > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > "Clothes make the man. Naked people have little or no influence on > society." > -- Mark Twain From guru at unixarea.de Wed May 6 10:50:53 2009 From: guru at unixarea.de (Matthias Apitz) Date: Wed May 6 10:51:01 2009 Subject: problems with BTX loader booting -CURRENT from USB key Message-ID: <20090506101932.GA7414@rebelion.Sisis.de> Hello, I've just got a new laptop Dell Precision M4400 and will install -CURRENT on it from a prepared USB key. While booting from the USB the BTX loader (1.00, BTX version 1.02) brings up as usual the menu with the numbers 1-6 for the boot form and counts down the time; until here total normal; but: - when you let it count to zero it tries to start the kernel and only one char of the rotating -/|\ is printed, nothing more happens; - when you just press any of the numbers it gives the same result; - when you press SPACE to stop the countdown and then any number it boots fine; any idea what is wrong of what could I check for more information? Thanks in advance matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From odhiambo at gmail.com Wed May 6 11:37:26 2009 From: odhiambo at gmail.com (=?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?=) Date: Wed May 6 11:37:33 2009 Subject: VIMAGE status In-Reply-To: <4A016ADD.3060004@elischer.org> References: <49FC812B.2070305@elischer.org> <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> <4A016ADD.3060004@elischer.org> Message-ID: <991123400905060437n56cacd9fk12ad1fc0b851b47c@mail.gmail.com> 2009/5/6 Julian Elischer > Odhiambo ????? wrote: > >> >> >> On Sat, May 2, 2009 at 8:21 PM, Julian Elischer > julian@elischer.org>> wrote: >> >> The VIMAGE code is nearly all in the the kernel. >> >> One is now able to make VIMAGE kernels (add options VIMAGE) >> though they don't actually allow you to make multiple >> vimages instances yet.. >> >> The VIMAGE option enables all the low level changes needed >> throughout the kernel. >> >> The VIMAGE_GLOBALS option basically sets thing sback to how they >> were before. >> >> Having neither (the default) gives a kernel that is a kind of hybrid. >> >> The Hybrid state is what will go forward as 'NON-VIMAGE' mode >> and the VIMAGE_GLOBALS mode will probably go away in time as >> it complicates the code. >> >> The aim of this mail is to ask people to try add the VIMAGE option >> to their regular kernels and try use them as you woudl normally. >> You will not yet be able to use any new VIMAGE features but we >> should be fully compatible with previous kernels. >> >> >> How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boyz :) >> > > > VImage code is in -current (hence the -current mailing list) > so it is not in 7.2. > > HOWEVER you can pick up 7.2(ish) kernel sourcce tree which will allow you > to substitute in a 7.2 VIMAGE kernel and play with it.. > I'll let Marko give you the details. > Looking forward to that. Thanks in advance. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From zec at freebsd.org Wed May 6 11:43:59 2009 From: zec at freebsd.org (Marko Zec) Date: Wed May 6 11:44:06 2009 Subject: VIMAGE status In-Reply-To: <4A016ADD.3060004@elischer.org> References: <49FC812B.2070305@elischer.org> <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> <4A016ADD.3060004@elischer.org> Message-ID: <200905060743.33045.zec@freebsd.org> On Wednesday 06 May 2009 06:47:57 Julian Elischer wrote: > Odhiambo ????? wrote: ... > > How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boyz :) > > VImage code is in -current (hence the -current mailing list) > so it is not in 7.2. > > HOWEVER you can pick up 7.2(ish) kernel sourcce tree which will allow > you to substitute in a 7.2 VIMAGE kernel and play with it.. > I'll let Marko give you the details. Hi, you should throw a look at this page for more details: http://imunes.tel.fer.hr/virtnet More specifically, you should download this tarball: http://imunes.tel.fer.hr/virtnet/vimage_7_20090505.tgz and then do the following: tpx32% cd src/sys/i386/conf/ tpx32% config VIMAGE tpx32% cd ../compile/VIMAGE/ tpx32% make depend; make tpx32% sudo make install tpx32% cd ~/tmp/src/usr.sbin/vimage/ tpx32% make clean; make tpx32% sudo make install Good luck, Marko From zec at freebsd.org Wed May 6 12:06:11 2009 From: zec at freebsd.org (Marko Zec) Date: Wed May 6 12:06:18 2009 Subject: VIMAGE status In-Reply-To: <991123400905060501h4d2248aaw60a59b9f83fe3501@mail.gmail.com> References: <49FC812B.2070305@elischer.org> <200905060743.33045.zec@freebsd.org> <991123400905060501h4d2248aaw60a59b9f83fe3501@mail.gmail.com> Message-ID: <200905060805.43835.zec@freebsd.org> On Wednesday 06 May 2009 08:01:24 Odhiambo ????? wrote: > 2009/5/6 Marko Zec ... > > Hi Marko, > > Thank you. I am gonna play with this. I had seen this page - > http://imunes.tel.fer.hr/virtnet/ but there is a static link there that > points only to vimage_7_20090401.tgz, so perhaps you can change that to > point the others to a location with the latest sources? I've updated the link already when I uploaded the new tarball, so perhaps you've been looking at a cached page? Anyhow, both vimage_7_20090401.tgz and vimage_7_200900505.tgz should work equally well with FreeBSD 7.2 userland. Marko From odhiambo at gmail.com Wed May 6 12:19:45 2009 From: odhiambo at gmail.com (=?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?=) Date: Wed May 6 12:19:51 2009 Subject: VIMAGE status In-Reply-To: <200905060743.33045.zec@freebsd.org> References: <49FC812B.2070305@elischer.org> <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> <4A016ADD.3060004@elischer.org> <200905060743.33045.zec@freebsd.org> Message-ID: <991123400905060519y635de314qe56e82972a9ee05a@mail.gmail.com> 2009/5/6 Marko Zec > On Wednesday 06 May 2009 06:47:57 Julian Elischer wrote: > > Odhiambo ????? wrote: > ... > > > How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boyz > :) > > > > VImage code is in -current (hence the -current mailing list) > > so it is not in 7.2. > > > > HOWEVER you can pick up 7.2(ish) kernel sourcce tree which will allow > > you to substitute in a 7.2 VIMAGE kernel and play with it.. > > I'll let Marko give you the details. > > Hi, > > you should throw a look at this page for more details: > > http://imunes.tel.fer.hr/virtnet > > More specifically, you should download this tarball: > > http://imunes.tel.fer.hr/virtnet/vimage_7_20090505.tgz > > and then do the following: > > tpx32% cd src/sys/i386/conf/ > tpx32% config VIMAGE > tpx32% cd ../compile/VIMAGE/ > tpx32% make depend; make > tpx32% sudo make install > tpx32% cd ~/tmp/src/usr.sbin/vimage/ > tpx32% make clean; make > tpx32% sudo make install > > Good luck, > > Marko > Okay. I found something that looks like a problem but that could be me as well. I have a custom kernel config file named BEASTIE-7.x (I hope there is nothing wrong with that naming as I have used it ever since FreeBSD 3.x). Now after diff-ing the GENERIC with BEASTIE-7x, I decided to edit VIMAGE to "include BEASTIE-7.x" instead of GENERIC. Here is what happens: FreeBSD-7# pwd /usr/home/wash/VIMAGE/src/sys/i386/conf FreeBSD-7# config VIMAGE config: VIMAGE:8: syntax error Alright, I wonder what is happening but line 8 has: include BEASTIE-7.x So I decided to cp BEASTIE-7.x BEASTIE Then I edited line 8 to remove the "-7.x" and... FreeBSD-7# config VIMAGE Kernel build directory is ../compile/VIMAGE Don't forget to do ``make cleandepend && make depend'' Now, again I looked further and I find that the problem actually is the ".x" in the file name, because "include BEASTIE-7" does not give any error. Maybe it's not a problem at all. It's not a big problem for me, but maybe it's something known/unknown that can be fixed? Sorry to bug you this early:) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From odhiambo at gmail.com Wed May 6 12:21:52 2009 From: odhiambo at gmail.com (=?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?=) Date: Wed May 6 12:21:58 2009 Subject: VIMAGE status In-Reply-To: <200905060743.33045.zec@freebsd.org> References: <49FC812B.2070305@elischer.org> <991123400905060306h573b6b28x1c7fc0497ef28472@mail.gmail.com> <4A016ADD.3060004@elischer.org> <200905060743.33045.zec@freebsd.org> Message-ID: <991123400905060501h4d2248aaw60a59b9f83fe3501@mail.gmail.com> 2009/5/6 Marko Zec > On Wednesday 06 May 2009 06:47:57 Julian Elischer wrote: > > Odhiambo ????? wrote: > ... > > > How do I use VIMAGE in 7.2-RELEASE? I'd like to play with the BIG boyz > :) > > > > VImage code is in -current (hence the -current mailing list) > > so it is not in 7.2. > > > > HOWEVER you can pick up 7.2(ish) kernel sourcce tree which will allow > > you to substitute in a 7.2 VIMAGE kernel and play with it.. > > I'll let Marko give you the details. > > Hi, > > you should throw a look at this page for more details: > > http://imunes.tel.fer.hr/virtnet > > More specifically, you should download this tarball: > > http://imunes.tel.fer.hr/virtnet/vimage_7_20090505.tgz > > and then do the following: > > tpx32% cd src/sys/i386/conf/ > tpx32% config VIMAGE > tpx32% cd ../compile/VIMAGE/ > tpx32% make depend; make > tpx32% sudo make install > tpx32% cd ~/tmp/src/usr.sbin/vimage/ > tpx32% make clean; make > tpx32% sudo make install Hi Marko, Thank you. I am gonna play with this. I had seen this page - http://imunes.tel.fer.hr/virtnet/ but there is a static link there that points only to vimage_7_20090401.tgz, so perhaps you can change that to point the others to a location with the latest sources? Thank you. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From odhiambo at gmail.com Wed May 6 12:55:06 2009 From: odhiambo at gmail.com (=?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?=) Date: Wed May 6 12:55:14 2009 Subject: VIMAGE status In-Reply-To: <200905060805.43835.zec@freebsd.org> References: <49FC812B.2070305@elischer.org> <200905060743.33045.zec@freebsd.org> <991123400905060501h4d2248aaw60a59b9f83fe3501@mail.gmail.com> <200905060805.43835.zec@freebsd.org> Message-ID: <991123400905060555l580ed589peacccdaeaab0335@mail.gmail.com> 2009/5/6 Marko Zec > On Wednesday 06 May 2009 08:01:24 Odhiambo ????? wrote: > > 2009/5/6 Marko Zec > ... > > > > Hi Marko, > > > > Thank you. I am gonna play with this. I had seen this page - > > http://imunes.tel.fer.hr/virtnet/ but there is a static link there that > > points only to vimage_7_20090401.tgz, so perhaps you can change that to > > point the others to a location with the latest sources? > > I've updated the link already when I uploaded the new tarball, so perhaps > you've been looking at a cached page? Anyhow, both vimage_7_20090401.tgz > and > vimage_7_200900505.tgz should work equally well with FreeBSD 7.2 userland. I reloaded the link today and it's fine. Now, if only you can help me further, with the failure: ===> zyd (depend) cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror ../../../netinet/in_proto.c -I../../../contrib/pf In file included from ../../../netinet/in_proto.c:88: ../../../contrib/pf/net/if_pfsync.h:42: error: two or more data types in declaration specifiers *** Error code 1 Stop in /usr/home/wash/VIMAGE/src/sys/i386/compile/VIMAGE. My kernel file is here: http://gw.kictanet.or.ke/~wash/BEASTIE-7.txt -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From 000.fbsd at quip.cz Wed May 6 13:08:08 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed May 6 13:08:15 2009 Subject: 7.1 to 7.2 upgrade question In-Reply-To: References: <000001c9cd85$afe53b70$0fafb250$@org> <87ljpbwi5v.fsf@kobe.laptop> <747dc8f30905051255j79b11662v716c2456c01d2b8a@mail.gmail.com> Message-ID: <4A018BB3.80302@quip.cz> Eygene Ryabinkin wrote: > Renato, [...] >>I don't know if it's officially supported, but I did an hybrid upgrade >>using freebsd-update for the base and building the custom kernel >>from sources, it worked fine and is still much faster than build >>everything. > > > In principle, you can run into some errors, like KVM size mismatches > (and other ABI changes) if your kernel (that you build from sources) and > updated base will differ. But you'll immediately notice it ;)) And for > most cases such way should work fine. Just a question: How can kernel be different, if it is build from the same sources (7.2-RELEASE)? freebsd-update updates the sources too (if old sources are installed in /usr/src), or am I wrong? Miroslav Lachman From rea-fbsd at codelabs.ru Wed May 6 13:14:00 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed May 6 13:14:07 2009 Subject: 7.1 to 7.2 upgrade question In-Reply-To: <4A018BB3.80302@quip.cz> References: <000001c9cd85$afe53b70$0fafb250$@org> <87ljpbwi5v.fsf@kobe.laptop> <747dc8f30905051255j79b11662v716c2456c01d2b8a@mail.gmail.com> <4A018BB3.80302@quip.cz> Message-ID: Wed, May 06, 2009 at 03:08:03PM +0200, Miroslav Lachman wrote: > Eygene Ryabinkin wrote: > > In principle, you can run into some errors, like KVM size mismatches > > (and other ABI changes) if your kernel (that you build from sources) and > > updated base will differ. But you'll immediately notice it ;)) And for > > most cases such way should work fine. > > Just a question: How can kernel be different, if it is build from the > same sources (7.2-RELEASE)? freebsd-update updates the sources too (if > old sources are installed in /usr/src), or am I wrong? If you are really checking out 7.2-RELEASE, then no, they can't be different. But you could checkout 7-STABLE and thus kernel might diverge from the world. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From zec at freebsd.org Wed May 6 13:28:08 2009 From: zec at freebsd.org (Marko Zec) Date: Wed May 6 13:28:15 2009 Subject: VIMAGE status In-Reply-To: <991123400905060555l580ed589peacccdaeaab0335@mail.gmail.com> References: <49FC812B.2070305@elischer.org> <200905060805.43835.zec@freebsd.org> <991123400905060555l580ed589peacccdaeaab0335@mail.gmail.com> Message-ID: <200905060927.42540.zec@freebsd.org> On Wednesday 06 May 2009 08:55:02 Odhiambo ????? wrote: > 2009/5/6 Marko Zec > > > On Wednesday 06 May 2009 08:01:24 Odhiambo ????? wrote: > > > 2009/5/6 Marko Zec > > > > ... > > > > > Hi Marko, > > > > > > Thank you. I am gonna play with this. I had seen this page - > > > http://imunes.tel.fer.hr/virtnet/ but there is a static link there that > > > points only to vimage_7_20090401.tgz, so perhaps you can change that to > > > point the others to a location with the latest sources? > > > > I've updated the link already when I uploaded the new tarball, so perhaps > > you've been looking at a cached page? Anyhow, both vimage_7_20090401.tgz > > and > > vimage_7_200900505.tgz should work equally well with FreeBSD 7.2 > > userland. > > I reloaded the link today and it's fine. > Now, if only you can help me further, with the failure: > > ===> zyd (depend) > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. > -I../../.. -I../../../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 > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror > ../../../netinet/in_proto.c -I../../../contrib/pf > In file included from ../../../netinet/in_proto.c:88: > ../../../contrib/pf/net/if_pfsync.h:42: error: two or more data types in > declaration specifiers > *** Error code 1 > > Stop in /usr/home/wash/VIMAGE/src/sys/i386/compile/VIMAGE. > > My kernel file is here: > http://gw.kictanet.or.ke/~wash/BEASTIE-7.txtsh/BEASTIE-7.txt> IPFILTER, ALTQ and most of the things that you have in your config file, but are not normally in GENERIC, are not yet supported with options VIMAGE. Marko From odhiambo at gmail.com Wed May 6 13:59:56 2009 From: odhiambo at gmail.com (=?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?=) Date: Wed May 6 14:00:03 2009 Subject: VIMAGE status In-Reply-To: <200905060927.42540.zec@freebsd.org> References: <49FC812B.2070305@elischer.org> <200905060805.43835.zec@freebsd.org> <991123400905060555l580ed589peacccdaeaab0335@mail.gmail.com> <200905060927.42540.zec@freebsd.org> Message-ID: <991123400905060659g1bccd99i7bfc36a39999f900@mail.gmail.com> 2009/5/6 Marko Zec > On Wednesday 06 May 2009 08:55:02 Odhiambo ????? wrote: > > 2009/5/6 Marko Zec > > > > > On Wednesday 06 May 2009 08:01:24 Odhiambo ????? wrote: > > > > 2009/5/6 Marko Zec > > > > > > ... > > > > > > > Hi Marko, > > > > > > > > Thank you. I am gonna play with this. I had seen this page - > > > > http://imunes.tel.fer.hr/virtnet/ but there is a static link there > that > > > > points only to vimage_7_20090401.tgz, so perhaps you can change that > to > > > > point the others to a location with the latest sources? > > > > > > I've updated the link already when I uploaded the new tarball, so > perhaps > > > you've been looking at a cached page? Anyhow, both > vimage_7_20090401.tgz > > > and > > > vimage_7_200900505.tgz should work equally well with FreeBSD 7.2 > > > userland. > > > > I reloaded the link today and it's fine. > > Now, if only you can help me further, with the failure: > > > > ===> zyd (depend) > > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. > > -I../../.. -I../../../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 > > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror > > ../../../netinet/in_proto.c -I../../../contrib/pf > > In file included from ../../../netinet/in_proto.c:88: > > ../../../contrib/pf/net/if_pfsync.h:42: error: two or more data types in > > declaration specifiers > > *** Error code 1 > > > > Stop in /usr/home/wash/VIMAGE/src/sys/i386/compile/VIMAGE. > > > > My kernel file is here: > > http://gw.kictanet.or.ke/~wash/BEASTIE-7.txt > >sh/BEASTIE-7.txt> > > IPFILTER, ALTQ and most of the things that you have in your config file, > but > are not normally in GENERIC, are not yet supported with options VIMAGE. > So no firewall at all when using VIMAGE, right? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From zec at freebsd.org Wed May 6 14:03:21 2009 From: zec at freebsd.org (Marko Zec) Date: Wed May 6 14:03:28 2009 Subject: VIMAGE status In-Reply-To: <991123400905060659g1bccd99i7bfc36a39999f900@mail.gmail.com> References: <49FC812B.2070305@elischer.org> <200905060927.42540.zec@freebsd.org> <991123400905060659g1bccd99i7bfc36a39999f900@mail.gmail.com> Message-ID: <200905061002.49019.zec@freebsd.org> On Wednesday 06 May 2009 09:59:54 Odhiambo ????? wrote: ... > > IPFILTER, ALTQ and most of the things that you have in your config file, > > but > > are not normally in GENERIC, are not yet supported with options VIMAGE. > > So no firewall at all when using VIMAGE, right? ipfw should work, at least to some extent. Marko From mister.olli at googlemail.com Wed May 6 15:21:02 2009 From: mister.olli at googlemail.com (Mister Olli) Date: Wed May 6 15:21:09 2009 Subject: Assign IP address and hostname via kernel parameter Message-ID: <1241623255.12407.6.camel@phoenix.blechhirn.net> Hi, is there a way to configure IP address and hostname on freebsd systems via kernel command line parameters? I have some freebsd systems in as xen domU's and it would be really great to be able to set the ip address & hostname within the configuration file for the domU. I'm aware that I could configure a static mac address and use DHCP, but with several layer2 segments on different XEN hosts setting up DHCP correctly would be a real pain ;-) --- Regards Mr. Olli From jt at 0xabadba.be Wed May 6 15:47:43 2009 From: jt at 0xabadba.be (jt@0xabadba.be) Date: Wed May 6 15:47:51 2009 Subject: Assign IP address and hostname via kernel parameter In-Reply-To: <1241623255.12407.6.camel@phoenix.blechhirn.net> References: <1241623255.12407.6.camel@phoenix.blechhirn.net> Message-ID: Hi, I would take a look at sysctl this system takes care of kernel parameters. There are a few man pages that delineate what is read only. I'm sure you are aware of setting the hostname at boot time. It seemed like you were more curious about on the fly. I'm not familiar with xen domU's hope this helps, =jt On Wed, May 6, 2009 at 11:20 AM, Mister Olli wrote: > Hi, > > is there a way to configure IP address and hostname on freebsd systems > via kernel command line parameters? > > I have some freebsd systems in as xen domU's and it would be really > great to be able to set the ip address & hostname within the > configuration file for the domU. > > I'm aware that I could configure a static mac address and use DHCP, but > with several layer2 segments on different XEN hosts setting up DHCP > correctly would be a real pain ;-) > > --- > Regards > Mr. Olli > > _______________________________________________ > 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 scottl at samsco.org Wed May 6 16:55:54 2009 From: scottl at samsco.org (Scott Long) Date: Wed May 6 16:56:01 2009 Subject: softdep_move_dependencies panic In-Reply-To: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> References: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> Message-ID: <4A01C10F.4060805@samsco.org> No, there is no fix for this. FreeBSD doesn't handle this case very well. What I would suggest doing is keeping the logical representation of the device around, but indicate that it has failed. Then complete all i/o with good status. This is something that is being worked on, but I have no information on when it might be fixed. Scott Leubner, Achim wrote: > Hi Ed, Hi Scott, > > > > We run into a problem if a RAID array goes into an ?error? state and is > marked ?offline?. The new aac driver removes the device in this case > with device_delete_child() and all commands to that device will be > answered using biodone() with flag BIO_ERROR and error EINVAL. But this > causes a ?softdep_move_dependencies: need merge code? panic in the > filesystem. Is there any possibility to avoid this panic? We see it > under FreeBSD 7.1 too. > > Any help is greatly appreciated. > > > > Thanks & Regards, > > Achim > > > > =========================== > > Achim Leubner > > Software Engineer / RAID drivers > > ICP vortex GmbH / Adaptec Inc. > > Phone: +49-351-8718291 > > > From jakub_lach at mailplus.pl Wed May 6 17:04:59 2009 From: jakub_lach at mailplus.pl (Jakub Lach) Date: Wed May 6 17:05:06 2009 Subject: Fighting for the power. In-Reply-To: <49FF6C11.5030607@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> <49FF6C11.5030607@FreeBSD.org> Message-ID: <23411239.post@talk.nabble.com> Hello. Is this patch commited yet? -best regards, Jakub Lach Alexander Motin-3 wrote: > > > Sorry, my fault. Try attached patch. > > -- > Alexander Motin > > --- local_apic.c.prev 2009-05-01 23:53:37.000000000 +0300 > +++ local_apic.c 2009-05-05 01:10:04.000000000 +0300 > @@ -319,7 +319,7 @@ lapic_setup(int boot) > } > > /* We don't setup the timer during boot on the BSP until later. */ > - if (!(boot && PCPU_GET(cpuid) == 0)) { > + if (!(boot && PCPU_GET(cpuid) == 0) && lapic_timer_hz != 0) { > KASSERT(lapic_timer_period != 0, ("lapic%u: zero divisor", > lapic_id())); > lapic_timer_set_divisor(lapic_timer_divisor); > > _______________________________________________ > 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" > -- View this message in context: http://www.nabble.com/Fighting-for-the-power.-tp23360518p23411239.html Sent from the freebsd-current mailing list archive at Nabble.com. From rb at gid.co.uk Wed May 6 17:08:41 2009 From: rb at gid.co.uk (Bob Bishop) Date: Wed May 6 17:08:48 2009 Subject: Assign IP address and hostname via kernel parameter In-Reply-To: <1241623255.12407.6.camel@phoenix.blechhirn.net> References: <1241623255.12407.6.camel@phoenix.blechhirn.net> Message-ID: <57A9FCBA-CBCB-45D2-9B95-5E5DBC0DB964@gid.co.uk> Hi, On 6 May 2009, at 16:20, Mister Olli wrote: > is there a way to configure IP address and hostname on freebsd systems > via kernel command line parameters? [etc] When running diskless, the loader sets kernel variables like: boot.netif.gateway="192.168.198.1" boot.netif.hwaddr="00:15:17:47:14:fc" boot.netif.ip="192.168.198.8" boot.netif.netmask="255.255.255.0" to values obtained from BOOTP or DHCP, and the right things happen. I guess you could just set these in loader.conf or at the loader prompt. -- Bob Bishop rb@gid.co.uk From gb at unistra.fr Wed May 6 18:46:15 2009 From: gb at unistra.fr (Guy Brand) Date: Wed May 6 18:46:22 2009 Subject: amd64 suspend/resume broken on current Message-ID: <20090506184130.GA1878@unistra.fr> Hello, Suspend/resume (S3) was working like a charm and it is now broken with FreeBSD 8.0-CURRENT #1: Wed May 6 18:27:21 CEST 2009 GENERIC amd64. I can suspend the laptop, but when resuming it I'm in a console which gets a lot of "fwohci0: device physically ejected?" messages and the system is dead. -- bug From peterjeremy at optushome.com.au Wed May 6 19:07:51 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed May 6 19:08:04 2009 Subject: Fighting for the power. In-Reply-To: <23411239.post@talk.nabble.com> References: <49FE1826.4060000@FreeBSD.org> <90a5caac0905041119h70101d12i56863e57b27d2e55@mail.gmail.com> <49FF6C11.5030607@FreeBSD.org> <23411239.post@talk.nabble.com> Message-ID: <20090506190745.GA91670@server.vk2pj.dyndns.org> On 2009-May-06 10:04:57 -0700, Jakub Lach wrote: >Is this patch commited yet? Yes as r191803. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090506/50fc99cc/attachment.pgp From shuvaev at physik.uni-wuerzburg.de Wed May 6 19:26:06 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Wed May 6 19:26:14 2009 Subject: gunzip | tar reports broken pipe during OOO build on amd64. In-Reply-To: <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> Message-ID: <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> On Wed, May 06, 2009 at 05:01:23AM -0700, Tim Kientzle wrote: > No, this is simply tar not being very friendly to gunzip. bsdtar is a > little quick to shutdown when it sees the end of the archive, even though > gunzip is still decompressing some end-of-archive padding. I'll look at > this; tar should notice when it's reading from a pipe and read the final > padding in this case, which would allow gunzip to shut down cleanly. > Thanks for looking at it! > Your workaround looks like a good change, though. The separate gunzip is > unnecessary. > On freebsd yes, but this patch is against makefile (deep) in the OOO sources. I don't think OOO people will accept the patch, then it should live in ports, which is not very desirable. (I'm not the maintainer of OOO, though.) > > On Tue, May 5, 2009 at 8:28 PM, Alexey Shuvaev < > shuvaev@physik.uni-wuerzburg.de> wrote: > > > On Tue, May 05, 2009 at 10:59:01PM +0400, Eygene Ryabinkin wrote: > > > Alexey, good day. > > > > > > Tue, May 05, 2009 at 07:48:31PM +0200, Alexey Shuvaev wrote: > > > > The reason appeared to be the first part of the command > > > > "gunzip -c ... | ( tar -xf - ) && touch ..." > > > > which exited with non-zero exit status (141) and "touch ..." was not > > called. > > > > Running the command manually has showed that gunzip was complaining > > about > > > > broken pipe (however the archive was extracted successfully). > > > > > > Yes, 141 means that SIGPIPE was delivered. This in turn means that > > > 'tar -xf -' exited before gunzip had finished its job and gunzip had > > > tried to write more data to the pipe. > > > > > > Could I ask to do some debugging: > > > > > > 1. run 'gunzip -c ooo_crystal_images-1.tar.gz > crystal.tar' > > > > > Ok so far. > > > > > 2. run 'cat crystal.tar | (tar -xf -) && echo OK' and look for the > > results. > > > > > Ok: > > ~/tmp> cat crystal.tar | ( tar -xf - ) && echo OK > > OK > > > > > 3. do 'md5 ooo_crystal_images-1.tar.gz' > > > > > ~/tmp> md5 crystal.tar > > MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a > > > > > For the last point, I have > > > ----- > > > MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 > > > ----- > > > but this tar.gz was taken from OOO 3.x. If yours have some other > > > checksum, could you place it somewhere where I can download it? > > > > > Mmmm... not so easy... German universities are not so internet friendly... > > fsck... > > But it was taken from official > > openoffice.org2/OOo_OOH680_m18_source.tar.bz2 > > tarball... > > Ping me if it is download error. > > > > > My .tar.gz unpacks without any errors, but my -CURRENT is from 3rd of > > May. > > > > > > Thanks! > > > > > I'm running amd64 Core2Duo processor with SMP kernel. Can it be that > > 2 processes (gunzip and tar) are running on different cpu-s and this is > > some race condition? Not triggered before? > > > -- > > > Eygene > > > _ ___ _.--. # > > > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > > > / ' ` , __.--' # to read the on-line manual > > > )/' _/ \ `-_, / # while single-stepping the kernel. > > > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > > > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > > > {_.-``-' {_/ # > > > _______________________________________________ > > > 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" > > _______________________________________________ > > 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 hselasky at c2i.net Wed May 6 20:06:36 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed May 6 20:06:43 2009 Subject: Another USB mouse failing to attach with current, post-USB2 In-Reply-To: <4A00DACA.1010500@beardz.net> References: <4A00DACA.1010500@beardz.net> Message-ID: <200905062209.08113.hselasky@c2i.net> On Wednesday 06 May 2009, Jase Thew wrote: > Hi, > I'm working on a fix for this issue. --HPS From olivier at gid0.org Wed May 6 20:48:53 2009 From: olivier at gid0.org (Olivier SMEDTS) Date: Wed May 6 20:49:00 2009 Subject: can't build kernel without atkbd Message-ID: <367b2c980905061318j3618bd1cpf2ed4619fd5a3b37@mail.gmail.com> Hello list, I'm trying to build a -CURRENT amd64 kernel but it fails if I don't have "device atkbd" in my kernel config file : # make buildkernel [...] linking kernel kbd.o(.text+0x14c): In function `kbd_configure': : undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x152): In function `kbd_configure': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x177): In function `kbd_configure': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x11f9): In function `kbd_get_switch': : undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x11ff): In function `kbd_get_switch': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x1217): In function `kbd_get_switch': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x1495): In function `kbd_register': : undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x149b): In function `kbd_register': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x14ad): In function `kbd_register': : undefined reference to `__stop_set_kbddriver_set' *** Error code 1 Here's the kernel config : cpu HAMMER ident QUAD options SCHED_ULE options PREEMPTION options IPI_PREEMPTION options INET options INET6 options FFS options SOFTUPDATES options UFS_DIRHASH options COMPAT_IA32 options SYSVSHM options SYSVMSG options SYSVSEM options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV options STOP_NMI options AUDIT options VIMAGE options PRINTF_BUFR_SIZE=128 options SMP device acpi device pci device vga device sc device loop device ether device pty device bpf If I add "makeoptions DEBUG=-g" like I have usually, here is the error : [...] MAKE=make sh /work/src/sys/conf/newvers.sh QUAD cc -c -O2 -pipe -march=native -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/work/src/sys -I/work/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 -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 vers.c linking kernel.debug kbd.o(.text+0x14c): In function `kbd_configure': /work/src/sys/dev/kbd/kbd.c:446: undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x152):/work/src/sys/dev/kbd/kbd.c:446: undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x177):/work/src/sys/dev/kbd/kbd.c:446: undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x11f9): In function `kbd_get_switch': /work/src/sys/dev/kbd/kbd.c:293: undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x11ff):/work/src/sys/dev/kbd/kbd.c:293: undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x1217):/work/src/sys/dev/kbd/kbd.c:293: undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x1495): In function `kbd_register': /work/src/sys/dev/kbd/kbd.c:229: undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x149b):/work/src/sys/dev/kbd/kbd.c:229: undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x14ad):/work/src/sys/dev/kbd/kbd.c:229: undefined reference to `__stop_set_kbddriver_set' *** Error code 1 I don't think that's expected because, citing ukbd(4) : If you want to use a USB keyboard as your default and not use an AT key- board at all, you will have to remove the device atkbd line from the ker- nel configuration file. NOTE?:?I'm using USB2. Any hints ? Thanks, Olivier -- 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 Cristi.Magherusan at net.utcluj.ro Wed May 6 22:05:16 2009 From: Cristi.Magherusan at net.utcluj.ro (Cristi Magherusan) Date: Wed May 6 22:05:23 2009 Subject: trivial patch commit request/reminder Message-ID: <1241645643.23197.7.camel@hyperion> Hi, Please anyone in charge (David Christensen?) review and commit to the tree the trivial patch that fixes the issue discussed in this thread: http://www.freebsd.org/cgi/query-pr.cgi?pr=118238 It's a shame that it didn't make it in 7.2, but hopefully it will in 8.0. Regards, Cristi -- Ing. Cristi M?gheru?an, System/Network Engineer Technical University of Cluj-Napoca, Romania http://cc.utcluj.ro +40264 401247 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090506/8c480ae8/attachment.pgp From mav at mavhome.dp.ua Wed May 6 23:37:18 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Wed May 6 23:42:01 2009 Subject: amd64 suspend/resume broken on current In-Reply-To: References: Message-ID: <4A021118.2030106@mavhome.dp.ua> Guy Brand wrote: > Suspend/resume (S3) was working like a charm and it is now broken with > FreeBSD 8.0-CURRENT #1: Wed May 6 18:27:21 CEST 2009 GENERIC amd64. > > I can suspend the laptop, but when resuming it I'm in a console which > gets a lot of "fwohci0: device physically ejected?" messages and the > system is dead. Looking onto the message, problem may be FireWire related. We have tested FireWire with Sean Bruno on my laptop, and even as system resumed successfully, FireWire was not working after resume, until we reloaded the driver. So there are definitely some problems exist. We can try to check it more, but could you try to unload FireWire drivers and try again? -- Alexander Motin From rmtodd at ichotolot.servalan.com Wed May 6 23:46:32 2009 From: rmtodd at ichotolot.servalan.com (Richard Todd) Date: Wed May 6 23:46:39 2009 Subject: Panic: wrong vnode type 0xffffff009b7719c0 on yesterday's current. Message-ID: <20090506234631.231A5CD8@mx1.synetsystems.com> Hi. I updated my main -current box to the current sources as of yesterday, and I've managed to twice get the "wrong vnode panic" out of the cache_enter code. As you can see from the backtrace down at cache_enter at frame 11, the code is apparently expecting vp to point to a VDIR vnode, but instead it's pointing to a VLNK. (I've got another, similar, dump where vp is pointing to a VREG node.) In both cases, I was running tinderbox to build packages, with resulting heavy use of both zfs (the underlying filesystem) and nullfs, if that's relevant. Script started on Wed May 6 17:41:35 2009 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 conditions. 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: panic: wrong vnode type 0xffffff011885b4e0 cpuid = 0 KDB: enter: panic exclusive rw Name Cache (Name Cache) r = 0 (0xffffffff80db98e0) locked @ /usr/src/sys/kern/vfs_cache.c:674 shared lockmgr zfs (zfs) r = 0 (0xffffff010c019098) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1201 exclusive lockmgr zfs (zfs) r = 0 (0xffffff011885b578) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1199 exclusive rw Name Cache (Name Cache) r = 0 (0xffffffff80db98e0) locked @ /usr/src/sys/kern/vfs_cache.c:674 shared lockmgr zfs (zfs) r = 0 (0xffffff010c019098) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1201 exclusive lockmgr zfs (zfs) r = 0 (0xffffff011885b578) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1199 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff010c479b10) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff006a338378) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive lockmgr bufwait (bufwait) r = 0 (0xffffffff003abe48) locked @ /usr/src/sys/vm/vm_pager.c:310 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff006a338b10) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff00ad503600) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 0xffffff010c019000: tag zfs, type VDIR usecount 5, writecount 0, refcount 6 mountedhere 0 flags () v_object 0xffffff00bd665708 ref 0 pages 0 lock type zfs: SHARED (count 1) #0 0xffffffff8054a4fa at __lockmgr_args+0x51a #1 0xffffffff805dbad9 at vop_stdlock+0x39 #2 0xffffffff8088a47b at VOP_LOCK1_APV+0x9b #3 0xffffffff805f7cb7 at _vn_lock+0x57 #4 0xffffffff81049b53 at zfs_lookup+0x303 #5 0xffffffff81049f51 at zfs_freebsd_lookup+0x81 #6 0xffffffff80888fef at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805d9880 at vfs_cache_lookup+0xf0 #8 0xffffffff8088b347 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805e0324 at lookup+0x4d4 #10 0xffffffff805e1285 at namei+0x545 #11 0xffffffff805f78e2 at vn_open_cred+0x1b2 #12 0xffffffff805dc184 at vop_stdvptocnp+0x174 #13 0xffffffff80889139 at VOP_VPTOCNP_APV+0xb9 #14 0xffffffff805d86fb at vn_vptocnp+0xdb #15 0xffffffff805d8a54 at vn_fullpath1+0x244 #16 0xffffffff805d8eb4 at kern___getcwd+0xd4 #17 0xffffffff808419d7 at syscall+0x1e7 0xffffff011885b4e0: tag zfs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type zfs: EXCL by thread 0xffffff0051e05000 (pid 55596) #0 0xffffffff8054a738 at __lockmgr_args+0x758 #1 0xffffffff805dbad9 at vop_stdlock+0x39 #2 0xffffffff8088a47b at VOP_LOCK1_APV+0x9b #3 0xffffffff805f7cb7 at _vn_lock+0x57 #4 0xffffffff81049b28 at zfs_lookup+0x2d8 #5 0xffffffff81049f51 at zfs_freebsd_lookup+0x81 #6 0xffffffff80888fef at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805d9880 at vfs_cache_lookup+0xf0 #8 0xffffffff8088b347 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805e0324 at lookup+0x4d4 #10 0xffffffff805e1285 at namei+0x545 #11 0xffffffff805f78e2 at vn_open_cred+0x1b2 #12 0xffffffff805dc184 at vop_stdvptocnp+0x174 #13 0xffffffff80889139 at VOP_VPTOCNP_APV+0xb9 #14 0xffffffff805d86fb at vn_vptocnp+0xdb #15 0xffffffff805d8a54 at vn_fullpath1+0x244 #16 0xffffffff805d8eb4 at kern___getcwd+0xd4 #17 0xffffffff808419d7 at syscall+0x1e7 Physical memory: 4012 MB Dumping 2299 MB: 2284 2268 2252 2236 2220 2204 2188 2172 2156 2140 2124 2108 2092 2076 2060 2044 2028 2012 1996 1980 1964 1948 1932 1916 1900 1884 1868 1852 1836 1820 1804 1788 1772 1756 1740 1724 1708 1692 1676 1660 1644 1628 1612 1596 1580 1564 1548 1532 1516 1500 1484 1468 1452 1436 1420 1404 1388 1372 1356 1340 1324 1308 1292 1276 1260 1244 1228 1212 1196 1180 1164 1148 1132 1116 1100 1084 1068 1052 1036 1020 1004 988 972 956 940 924 908 892 876 860 844 828 812 796 780 764 748 732 716 700 684 668 652 636 620 604 588 572 556 540 524 508 492 476 460 444 428 412 396 380 364 348 332 316 300 284 268 252 236 220 204 188 172 156 140 124 108 92 76 60 44 28 12 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/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:223 223 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff801cc59c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801cc84d in db_command (last_cmdp=0xffffffff80bc36a0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801d1043 in db_script_exec ( scriptname=0xffffffff2d7d9d50 "kdb.enter.panic", warnifnotfound=0) at /usr/src/sys/ddb/db_script.c:302 #4 0xffffffff801d1112 in db_script_kdbenter (eventname=Variable "eventname" is not available. ) at /usr/src/sys/ddb/db_script.c:324 #5 0xffffffff801ceac4 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:228 #6 0xffffffff8058f5d5 in kdb_trap (type=3, code=0, tf=0xffffffff2d7d9f70) at /usr/src/sys/kern/subr_kdb.c:534 #7 0xffffffff80842125 in trap (frame=0xffffffff2d7d9f70) at /usr/src/sys/amd64/amd64/trap.c:606 #8 0xffffffff8081cef3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #9 0xffffffff8058f7ad in kdb_enter (why=0xffffffff80946c99 "panic", msg=0xa
) at cpufunc.h:63 #10 0xffffffff8055fe5b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:559 #11 0xffffffff805d8542 in cache_enter (dvp=0xffffff010c019000, vp=0xffffff011885b4e0, cnp=0xffffffff2d7da908) at /usr/src/sys/kern/vfs_cache.c:702 #12 0xffffffff81049b95 in zfs_lookup (dvp=0xffffff010c019000, nm=0xffffffff2d7da230 "..", vpp=0xffffffff2d7da8e0, cnp=0xffffffff2d7da908, nameiop=0, cr=0xffffff0032a08a00, td=0xffffff0051e05000, flags=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1221 #13 0xffffffff81049f51 in zfs_freebsd_lookup (ap=0xffffffff2d7da390) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:3988 #14 0xffffffff80888fef in VOP_CACHEDLOOKUP_APV (vop=0xffffffff810b22e0, a=0xffffffff2d7da390) at vnode_if.c:187 #15 0xffffffff805d9880 in vfs_cache_lookup (ap=Variable "ap" is not available. ) at vnode_if.h:80 #16 0xffffffff8088b347 in VOP_LOOKUP_APV (vop=0xffffffff810b22e0, a=0xffffffff2d7da460) at vnode_if.c:123 #17 0xffffffff805e0324 in lookup (ndp=0xffffffff2d7da8b0) at vnode_if.h:54 #18 0xffffffff805e1285 in namei (ndp=0xffffffff2d7da8b0) at /usr/src/sys/kern/vfs_lookup.c:256 #19 0xffffffff805f78e2 in vn_open_cred (ndp=0xffffffff2d7da8b0, flagp=0xffffffff2d7da9b8, cmode=0, cred=0xffffff0032a08a00, fp=0x0) at /usr/src/sys/kern/vfs_vnops.c:189 #20 0xffffffff805dc184 in vop_stdvptocnp (ap=Variable "ap" is not available. ) at /usr/src/sys/kern/vfs_default.c:707 #21 0xffffffff80889139 in VOP_VPTOCNP_APV (vop=0xffffffff80b7f560, a=0xffffffff2d7daa30) at vnode_if.c:3353 #22 0xffffffff805d86fb in vn_vptocnp (vp=0xffffffff2d7daab0, ---Type to continue, or q to quit--- bp=0xffffffff2d7daac0, buf=0xffffff00059ed800 'p' ..., buflen=0xffffffff2d7daaac) at vnode_if.h:1512 #23 0xffffffff805d8a54 in vn_fullpath1 (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_cache.c:1168 #24 0xffffffff805d8eb4 in kern___getcwd (td=0xffffff0051e05000, buf=0x7fffffffe390
, bufseg=UIO_USERSPACE, buflen=1024) at /usr/src/sys/kern/vfs_cache.c:936 #25 0xffffffff808419d7 in syscall (frame=0xffffffff2d7dac90) at /usr/src/sys/amd64/amd64/trap.c:977 #26 0xffffffff8081d180 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #27 0x000000001892dcec in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 11 #11 0xffffffff805d8542 in cache_enter (dvp=0xffffff010c019000, vp=0xffffff011885b4e0, cnp=0xffffffff2d7da908) at /usr/src/sys/kern/vfs_cache.c:702 702 KASSERT(vp == NULL || vp->v_type == VDIR, (kgdb) p *vp $1 = {v_type = VLNK, v_tag = 0xffffffff810ad73d "zfs", v_op = 0xffffffff810b22e0, v_data = 0xffffff006cfe9178, v_mount = 0xffffff00058e9388, v_nmntvnodes = {tqe_next = 0xffffff00c6b53750, tqe_prev = 0xffffff00c6b60c58}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = { le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xffffff00a6675770, tqh_last = 0xffffff00a6675790}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = { lo_name = 0xffffffff810ad73d "zfs", lo_flags = 91947009, lo_data = 0, lo_witness = 0xfffffffe40223200}, lk_lock = 18446742975571578880, lk_timo = 16, lk_pri = 80, lk_stack = {depth = 18, pcs = { 18446744071567615800, 18446744071568210649, 18446744071571022971, 18446744071568325815, 18446744071579147048, 18446744071579148113, 18446744071571017711, 18446744071568201856, 18446744071571026759, 18446744071568229156, 18446744071568233093, 18446744071568324834, 18446744071568212356, 18446744071571018041, 18446744071568197371, 18446744071568198228, 18446744071568199348, 18446744071570725335}}}, v_interlock = {lock_object = { lo_name = 0xffffffff8094debe "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe4021b680}, mtx_lock = 4}, v_vnlock = 0xffffff011885b578, v_holdcnt = 1, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0xffffff00c6b53750, tqe_prev = 0xffffff00c6b60dd0}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0xffffffff80956a86 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe40220c80}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff011885b6b0}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff011885b6d0}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff80b7d9e0, bo_bsize = 131072, bo_object = 0x0, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xffffff011885b4e0, __bo_vnode = 0xffffff011885b4e0}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} (kgdb) l 697 if (dvp->v_cache_dd != NULL) { 698 CACHE_WUNLOCK(); 699 cache_free(ncp); 700 return; 701 } 702 KASSERT(vp == NULL || vp->v_type == VDIR, 703 ("wrong vnode type %p", vp)); 704 dvp->v_cache_dd = ncp; 705 } 706 (kgdb) fr 12 #12 0xffffffff81049b95 in zfs_lookup (dvp=0xffffff010c019000, nm=0xffffffff2d7da230 "..", vpp=0xffffffff2d7da8e0, cnp=0xffffffff2d7da908, nameiop=0, cr=0xffffff0032a08a00, td=0xffffff0051e05000, flags=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1221 1221 cache_enter(dvp, *vpp, cnp); (kgdb) l 1216 * Insert name into cache if appropriate. 1217 */ 1218 if (error == 0 && (cnp->cn_flags & MAKEENTRY)) { 1219 if (!(cnp->cn_flags & ISLASTCN) || 1220 (nameiop != DELETE && nameiop != RENAME)) { 1221 cache_enter(dvp, *vpp, cnp); 1222 } 1223 } 1224 #endif 1225 (kgdb) p *dvp $2 = {v_type = VDIR, v_tag = 0xffffffff810ad73d "zfs", v_op = 0xffffffff810b22e0, v_data = 0xffffff00b7a99bc0, v_mount = 0xffffff00058e9388, v_nmntvnodes = {tqe_next = 0xffffff001fee1270, tqe_prev = 0xffffff00c1c9c508}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = { le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xffffff010c019060}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = {lo_name = 0xffffffff810ad73d "zfs", lo_flags = 91947009, lo_data = 0, lo_witness = 0xfffffffe40223200}, lk_lock = 9, lk_timo = 16, lk_pri = 80, lk_stack = {depth = 18, pcs = { 18446744071567615226, 18446744071568210649, 18446744071571022971, 18446744071568325815, 18446744071579147091, 18446744071579148113, 18446744071571017711, 18446744071568201856, 18446744071571026759, 18446744071568229156, 18446744071568233093, 18446744071568324834, 18446744071568212356, 18446744071571018041, 18446744071568197371, 18446744071568198228, 18446744071568199348, 18446744071570725335}}}, v_interlock = {lock_object = { lo_name = 0xffffffff8094debe "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe4021b680}, mtx_lock = 4}, v_vnlock = 0xffffff010c019098, v_holdcnt = 6, v_usecount = 5, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0x0, tqe_prev = 0xffffff010c0701a0}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0xffffffff80956a86 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe40220c80}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff010c0191d0}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff010c0191f0}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff80b7d9e0, bo_bsize = 131072, bo_object = 0xffffff00bd665708, bo_synclist = { le_next = 0x0, le_prev = 0x0}, bo_private = 0xffffff010c019000, __bo_vnode = 0xffffff010c019000}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} (kgdb) p **vpp $3 = {v_type = VLNK, v_tag = 0xffffffff810ad73d "zfs", v_op = 0xffffffff810b22e0, v_data = 0xffffff006cfe9178, v_mount = 0xffffff00058e9388, v_nmntvnodes = {tqe_next = 0xffffff00c6b53750, tqe_prev = 0xffffff00c6b60c58}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = { le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xffffff00a6675770, tqh_last = 0xffffff00a6675790}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = { lo_name = 0xffffffff810ad73d "zfs", lo_flags = 91947009, lo_data = 0, lo_witness = 0xfffffffe40223200}, lk_lock = 18446742975571578880, lk_timo = 16, lk_pri = 80, lk_stack = {depth = 18, pcs = { 18446744071567615800, 18446744071568210649, 18446744071571022971, 18446744071568325815, 18446744071579147048, 18446744071579148113, 18446744071571017711, 18446744071568201856, 18446744071571026759, 18446744071568229156, 18446744071568233093, 18446744071568324834, 18446744071568212356, 18446744071571018041, 18446744071568197371, 18446744071568198228, 18446744071568199348, 18446744071570725335}}}, v_interlock = {lock_object = { lo_name = 0xffffffff8094debe "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe4021b680}, mtx_lock = 4}, v_vnlock = 0xffffff011885b578, v_holdcnt = 1, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0xffffff00c6b53750, tqe_prev = 0xffffff00c6b60dd0}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0xffffffff80956a86 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xfffffffe40220c80}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff011885b6b0}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff011885b6d0}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff80b7d9e0, bo_bsize = 131072, bo_object = 0x0, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xffffff011885b4e0, __bo_vnode = 0xffffff011885b4e0}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} (kgdb) q Script done on Wed May 6 17:42:37 2009 From barney_cordoba at yahoo.com Thu May 7 00:54:37 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Thu May 7 01:39:32 2009 Subject: Hypertherading Message-ID: <270637.78561.qm@web63905.mail.re1.yahoo.com> I just got a shiny new nehalem box and it comes up with 16 processors with dual quads installed. Is there any benefit or should hyperthreading be disabled? From pluknet at gmail.com Thu May 7 02:55:19 2009 From: pluknet at gmail.com (pluknet) Date: Thu May 7 02:55:26 2009 Subject: Hypertherading In-Reply-To: <270637.78561.qm@web63905.mail.re1.yahoo.com> References: <270637.78561.qm@web63905.mail.re1.yahoo.com> Message-ID: 2009/5/7 Barney Cordoba : > > I just got a shiny new nehalem box and it comes up with 16 processors with dual quads installed. Is there any benefit or should hyperthreading be disabled? > Hi. There is a measurable win if hyperthreading is enabled [1]. You can switch it off via machdep.hyperthreading_enabled loader tunable. [1] http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html -- wbr, pluknet From kientzle at freebsd.org Thu May 7 04:39:11 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Thu May 7 04:39:18 2009 Subject: gunzip | tar reports broken pipe during OOO build on amd64. In-Reply-To: <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> Message-ID: <4A0265ED.4070407@freebsd.org> Alexey Shuvaev wrote: > On Wed, May 06, 2009 at 05:01:23AM -0700, Tim Kientzle wrote: >> No, this is simply tar not being very friendly to gunzip. bsdtar is a >> little quick to shutdown when it sees the end of the archive, even though >> gunzip is still decompressing some end-of-archive padding. I'll look at >> this; tar should notice when it's reading from a pipe and read the final >> padding in this case, which would allow gunzip to shut down cleanly. >> > Thanks for looking at it! I did look; bsdtar does do the right thing. (I think I was remembering a bug that got fixed years ago.) I tried but could not reproduce your bug using a recent -CURRENT. I downloaded this file: http://ftp.cse.yzu.edu.tw/pub/FreeBSD/distfiles/openoffice.org2/OOo_OOH680_m18_source.tar.bz2 and extracted ooo_crystal_images-1.tar.gz and got the same MD5 that Eygene reported. $ md5 ooo_crystal_images-1.tar.gz MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 Where did you download your file from? Tim From rea-fbsd at codelabs.ru Thu May 7 06:05:45 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu May 7 06:05:53 2009 Subject: gunzip | tar reports broken pipe during OOO build on amd64. In-Reply-To: <4A0265ED.4070407@freebsd.org> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> <4A0265ED.4070407@freebsd.org> Message-ID: Wed, May 06, 2009 at 09:39:09PM -0700, Tim Kientzle wrote: > I tried but could not reproduce your bug using > a recent -CURRENT. I downloaded this file: > > http://ftp.cse.yzu.edu.tw/pub/FreeBSD/distfiles/openoffice.org2/OOo_OOH680_m18_source.tar.bz2 > > and extracted ooo_crystal_images-1.tar.gz > and got the same MD5 that Eygene reported. > > $ md5 ooo_crystal_images-1.tar.gz > MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 > > Where did you download your file from? Alexey's .tar.gz file should be also fine: he reported the checksum from the .tar file, not .tar.gz one: ----- ~/tmp> md5 crystal.tar MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a ----- I have the same MD5 for the .tar file: ----- $ md5 crystal.tar MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a ----- I am not able to reproduce the bug too, so perhaps the output from ktrace, ----- ktrace -f gunzip.trace gunzip -c ooo_crystal_images-1.tar.gz | (ktrace -f tar.trace tar -xf -) ----- will be useful for diagnostics. The files of interest will be gunzip.trace and tar.trace. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From imp at bsdimp.com Thu May 7 06:14:20 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu May 7 06:14:32 2009 Subject: Fighting for the power. In-Reply-To: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> References: <49FE1826.4060000@FreeBSD.org> <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> Message-ID: <20090507.001059.-1558772981.imp@bsdimp.com> In message: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> "Paul B. Mahol" writes: : On 5/4/09, Alexander Motin wrote: : > 2. PCI devices : > PCI bus provides method to control device power. For example, I have : > completely no use for my FireWire controller and most of time - EHCI USB : > controller. Disabling them allows me to save about 3W of power. To : > disable all unneeded PCI devices you should build kernel without their : > drivers and add to loader.conf: : > hw.pci.do_power_nodriver=3 : > To enable devices back all you need to do is just load their drivers as : > modules. : : Unloading modules doesnt put them back into into D3 state. : You are forced to load some another module again to put wanted device : into D3 state. It should. If it isn't, that's a bug. Warner From rb at gid.co.uk Thu May 7 08:39:38 2009 From: rb at gid.co.uk (Bob Bishop) Date: Thu May 7 08:39:45 2009 Subject: Hypertherading In-Reply-To: References: <270637.78561.qm@web63905.mail.re1.yahoo.com> Message-ID: <32413E83-2059-4A47-AB45-EA7A1A509DD6@gid.co.uk> Hi, On 7 May 2009, at 03:55, pluknet wrote: > 2009/5/7 Barney Cordoba : >> >> I just got a shiny new nehalem box and it comes up with 16 >> processors with dual quads installed. Is there any benefit or >> should hyperthreading be disabled? >> > > Hi. There is a measurable win if hyperthreading is enabled [1]. AFAICS the reference doesn't support that conclusion at all. > You can switch it off via machdep.hyperthreading_enabled loader > tunable. > > [1] http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html -- Bob Bishop rb@gid.co.uk From barney_cordoba at yahoo.com Thu May 7 09:26:51 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Thu May 7 09:27:00 2009 Subject: Hypertherading In-Reply-To: Message-ID: <758865.1091.qm@web63907.mail.re1.yahoo.com> --- On Wed, 5/6/09, pluknet wrote: > From: pluknet > Subject: Re: Hypertherading > To: "Barney Cordoba" > Cc: "Current@freebsd.org" > Date: Wednesday, May 6, 2009, 10:55 PM > 2009/5/7 Barney Cordoba : > > > > I just got a shiny new nehalem box and it comes up > with 16 processors with dual quads installed. Is there any > benefit or should hyperthreading be disabled? > > > > Hi. There is a measurable win if hyperthreading is enabled > [1]. > You can switch it off via machdep.hyperthreading_enabled > loader tunable. > > [1] > http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html > I wouldn't call varying the number of jobs a very good test of hyperthreading. I'd want to see the exact same test with hyperthreading enabled and disabled. Its pretty naive to assume that running 16 jobs causes them to all be run on a different cpu. Barney From olivier at gid0.org Thu May 7 09:31:12 2009 From: olivier at gid0.org (Olivier SMEDTS) Date: Thu May 7 09:31:19 2009 Subject: Hypertherading In-Reply-To: <758865.1091.qm@web63907.mail.re1.yahoo.com> References: <758865.1091.qm@web63907.mail.re1.yahoo.com> Message-ID: <367b2c980905070231r37a94eack399f5afed742247f@mail.gmail.com> 2009/5/7 Barney Cordoba : > > > > > --- On Wed, 5/6/09, pluknet wrote: > >> From: pluknet >> Subject: Re: Hypertherading >> To: "Barney Cordoba" >> Cc: "Current@freebsd.org" >> Date: Wednesday, May 6, 2009, 10:55 PM >> 2009/5/7 Barney Cordoba : >> > >> > I just got a shiny new nehalem box and it comes up >> with 16 processors with dual quads installed. Is there any >> benefit or should hyperthreading be disabled? There can be some benefit if the scheduler is aware of the topoly of CPUs and Hyperthreading (shared cache). I don't know how SCHED_ULE handles this on -CURRENT. If it doesn't see any difference between CPU cores and "HT" cores, you should disable HT in BIOS. >> > >> >> Hi. There is a measurable win if hyperthreading is enabled >> [1]. >> You can switch it off via machdep.hyperthreading_enabled >> loader tunable. >> >> [1] >> http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html >> > > I wouldn't call varying the number of jobs a very good test > of hyperthreading. I'd want to see the exact same test with > hyperthreading enabled and disabled. Its pretty naive > to assume that running 16 jobs causes them to all be run on > a different cpu. > > Barney > > > > _______________________________________________ > 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 astrodog at gmail.com Thu May 7 10:04:48 2009 From: astrodog at gmail.com (Astrodog) Date: Thu May 7 10:04:55 2009 Subject: Hypertherading In-Reply-To: <758865.1091.qm@web63907.mail.re1.yahoo.com> References: <758865.1091.qm@web63907.mail.re1.yahoo.com> Message-ID: <2fd864e0905070236m4ff62796y3839a1d21c1ed610@mail.gmail.com> The big thing I've seen in all of the tests of HT is that it's incredibly dependent on the type of load one's trying to run. Loads which consist largely of mathematical calculations and very latency-sensitive loads seem to be hurt by it, and desktop loads seem to see either nothing, or a mild improvement. The scheduler is better at handling this kind of decision than the CPU is, in most cases. (To say nothing of the annoyance HT causes for the scheduler, imo) JeffR can probably explain what actually happens with HT enabled (as far as scheduling decisions go) better than I can. --- Harrison From hselasky at c2i.net Thu May 7 11:17:46 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu May 7 11:17:58 2009 Subject: Another USB mouse failing to attach with current, post-USB2 In-Reply-To: <4A00DACA.1010500@beardz.net> References: <4A00DACA.1010500@beardz.net> Message-ID: <200905071320.17310.hselasky@c2i.net> On Wednesday 06 May 2009, Jase Thew wrote: > Hi, > Hi, Can you try the following patch: http://perforce.freebsd.org/chv.cgi?CH=161718 BTW: Thanks for reporting! --HPS From igor at kharin.org Thu May 7 11:57:22 2009 From: igor at kharin.org (Igor Kharin) Date: Thu May 7 11:57:29 2009 Subject: can't build kernel without atkbd In-Reply-To: <367b2c980905061318j3618bd1cpf2ed4619fd5a3b37@mail.gmail.com> References: <367b2c980905061318j3618bd1cpf2ed4619fd5a3b37@mail.gmail.com> Message-ID: 2009/5/7 Olivier SMEDTS : > Here's the kernel config : > > cpu HAMMER > ident QUAD > options SCHED_ULE > options PREEMPTION > options IPI_PREEMPTION > options INET > options INET6 > options FFS > options SOFTUPDATES > options UFS_DIRHASH > options COMPAT_IA32 > options SYSVSHM > options SYSVMSG > options SYSVSEM > options _KPOSIX_PRIORITY_SCHEDULING > options KBD_INSTALL_CDEV > options STOP_NMI > options AUDIT > options VIMAGE > options PRINTF_BUFR_SIZE=128 > options SMP > device acpi > device pci > device vga > device sc > device loop > device ether > device pty > device bpf It's OK, just atkbd is required by syscons (man 4 sc): > The syscons driver is implemented on top of the keyboard driver > (atkbd(4)) and the video card driver (vga(4)) and so requires both of > them to be configured in the system. From ben at wanderview.com Thu May 7 12:59:49 2009 From: ben at wanderview.com (Ben Kelly) Date: Thu May 7 12:59:56 2009 Subject: Panic: wrong vnode type 0xffffff009b7719c0 on yesterday's current. In-Reply-To: <20090506234631.231A5CD8@mx1.synetsystems.com> References: <20090506234631.231A5CD8@mx1.synetsystems.com> Message-ID: <619B386D-9FF5-4296-BB83-245881CA9C41@wanderview.com> On May 6, 2009, at 6:54 PM, Richard Todd wrote: > Hi. I updated my main -current box to the current sources as of > yesterday, > and I've managed to twice get the "wrong vnode panic" out of the > cache_enter > code. As you can see from the backtrace down at cache_enter at > frame 11, > the code is apparently expecting vp to point to a VDIR vnode, but > instead > it's pointing to a VLNK. (I've got another, similar, dump where vp > is > pointing to a VREG node.) In both cases, I was running tinderbox to > build > packages, with resulting heavy use of both zfs (the underlying > filesystem) > and nullfs, if that's relevant. > (kgdb) l > 697 if (dvp->v_cache_dd != NULL) { > 698 CACHE_WUNLOCK(); > 699 cache_free(ncp); > 700 return; > 701 } > 702 KASSERT(vp == NULL || vp->v_type == VDIR, > 703 ("wrong vnode type %p", vp)); > 704 dvp->v_cache_dd = ncp; > 705 } > 706 It looks like this KASSERT was added relatively recently as part of the dotdot changes to the namecache: http://svn.freebsd.org/viewvc/base?view=revision&revision=190945 Perhaps there is further fallout from the changes that only occur with ZFS? - Ben From bsam at ipt.ru Thu May 7 13:11:48 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Thu May 7 13:11:54 2009 Subject: make -jN stalls Message-ID: <47975645@bb.ipt.ru> Hello List, I should have done something stupid, but any command "make -jN", (where N > 1) stalls the process after some time, even with blank /etc/make.conf. I use i386-CURRENT as of yesterday. Hereis a truss log from "make -C /usr/ports -j5 index" (it is really small): ftp://ftp.ipt.ru/pub/tmp/make.jN.log The directory /usr/ports is a link to /m/ports. Other than that is pretty default. What should be done, how to diagnose, etc... Thanks. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From jroberson at jroberson.net Thu May 7 13:13:12 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Thu May 7 13:13:19 2009 Subject: Hypertherading In-Reply-To: <367b2c980905070231r37a94eack399f5afed742247f@mail.gmail.com> References: <758865.1091.qm@web63907.mail.re1.yahoo.com> <367b2c980905070231r37a94eack399f5afed742247f@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Olivier SMEDTS wrote: > 2009/5/7 Barney Cordoba : >> >> >> >> >> --- On Wed, 5/6/09, pluknet wrote: >> >>> From: pluknet >>> Subject: Re: Hypertherading >>> To: "Barney Cordoba" >>> Cc: "Current@freebsd.org" >>> Date: Wednesday, May 6, 2009, 10:55 PM >>> 2009/5/7 Barney Cordoba : >>>> >>>> I just got a shiny new nehalem box and it comes up >>> with 16 processors with dual quads installed. Is there any >>> benefit or should hyperthreading be disabled? > > There can be some benefit if the scheduler is aware of the topoly of > CPUs and Hyperthreading (shared cache). I don't know how SCHED_ULE > handles this on -CURRENT. If it doesn't see any difference between CPU > cores and "HT" cores, you should disable HT in BIOS. ULE is topology aware and most machines are probed properly. ULE will prefer not to use hyperthreaded cores if there is available time on an unloaded core. ULE will also freely share threads among hyperthreaded neighbors. I have found the hyperthreaded cores on nehalem to be significantly improved over the older version. On one packet forwarding test a 50% improvement was seen by enabling htt cores. I believe this is because the amount of memory bandwidth and is sufficient to support these cores where it was not before. Depending on how populated your memories are you may have less memory bandwidth and see less good results. You can always safely disable these cores by using cpuset to modify the default group, group 1, and experiment at run-time. Thanks, Jeff > >>>> >>> >>> Hi. There is a measurable win if hyperthreading is enabled >>> [1]. >>> You can switch it off via machdep.hyperthreading_enabled >>> loader tunable. >>> >>> [1] >>> http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html >>> >> >> I wouldn't call varying the number of jobs a very good test >> of hyperthreading. I'd want to see the exact same test with >> hyperthreading enabled and disabled. Its pretty naive >> to assume that running 16 jobs causes them to all be run on >> a different cpu. >> >> Barney >> >> >> >> _______________________________________________ >> 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." > _______________________________________________ > 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 jroberson at jroberson.net Thu May 7 13:17:04 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Thu May 7 13:17:10 2009 Subject: softdep_move_dependencies panic In-Reply-To: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> References: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> Message-ID: On Wed, 6 May 2009, Leubner, Achim wrote: > Hi Ed, Hi Scott, > > We run into a problem if a RAID array goes into an "error" state and is marked "offline". The new aac driver removes the device in this case with device_delete_child() and all commands to that device will be answered using biodone() with flag BIO_ERROR and error EINVAL. But this causes a "softdep_move_dependencies: need merge code" panic in the filesystem. Is there any possibility to avoid this panic? We see it under FreeBSD 7.1 too. > Any help is greatly appreciated. Hi Achim, Can you post the entire stack trace from the panic? Thanks, Jeff > > Thanks & Regards, > Achim > > > =========================== > > Achim Leubner > > Software Engineer / RAID drivers > > ICP vortex GmbH / Adaptec Inc. > > Phone: +49-351-8718291 > > _______________________________________________ > 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 Achim_Leubner at adaptec.com Thu May 7 13:27:50 2009 From: Achim_Leubner at adaptec.com (Leubner, Achim) Date: Thu May 7 13:28:03 2009 Subject: softdep_move_dependencies panic In-Reply-To: References: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> Message-ID: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B6D33F1@ADPE2K703.adaptec.com> Hi Jeff, I'm currently on business trip. I'll send the stack trace next Monday. Thanks, Achim -----Original Message----- From: Jeff Roberson [mailto:jroberson@jroberson.net] Sent: Thursday, May 07, 2009 3:20 PM To: Leubner, Achim Cc: Ed Maste; Scott Long; current@freebsd.org; Sridaran, Gana Subject: Re: softdep_move_dependencies panic On Wed, 6 May 2009, Leubner, Achim wrote: > Hi Ed, Hi Scott, > > We run into a problem if a RAID array goes into an "error" state and is marked "offline". The new aac driver removes the device in this case with device_delete_child() and all commands to that device will be answered using biodone() with flag BIO_ERROR and error EINVAL. But this causes a "softdep_move_dependencies: need merge code" panic in the filesystem. Is there any possibility to avoid this panic? We see it under FreeBSD 7.1 too. > Any help is greatly appreciated. Hi Achim, Can you post the entire stack trace from the panic? Thanks, Jeff > > Thanks & Regards, > Achim > > > =========================== > > Achim Leubner > > Software Engineer / RAID drivers > > ICP vortex GmbH / Adaptec Inc. > > Phone: +49-351-8718291 > > _______________________________________________ > 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 barney_cordoba at yahoo.com Thu May 7 13:57:45 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Thu May 7 13:57:52 2009 Subject: Hypertherading In-Reply-To: Message-ID: <418018.46727.qm@web63901.mail.re1.yahoo.com> --- On Wed, 5/6/09, pluknet wrote: > From: pluknet > Subject: Re: Hypertherading > To: "Barney Cordoba" > Cc: "Current@freebsd.org" > Date: Wednesday, May 6, 2009, 10:55 PM > 2009/5/7 Barney Cordoba : > > > > I just got a shiny new nehalem box and it comes up > with 16 processors with dual quads installed. Is there any > benefit or should hyperthreading be disabled? > > > > Hi. There is a measurable win if hyperthreading is enabled > [1]. > You can switch it off via machdep.hyperthreading_enabled > loader tunable. > > [1] > http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html > > > -- > wbr, > pluknet I assume you mean hyperthreading-allowed? I set sysctl -a | grep hyper machdep.hyperthreading_allowed: 0 but it still launches 16 cpus. Is that expected? It doesn't seem correct. Barney From bazerka at beardz.net Thu May 7 14:31:54 2009 From: bazerka at beardz.net (Jase Thew) Date: Thu May 7 14:32:48 2009 Subject: Another USB mouse failing to attach with current, post-USB2 In-Reply-To: <200905071320.17310.hselasky@c2i.net> References: <4A00DACA.1010500@beardz.net> <200905071320.17310.hselasky@c2i.net> Message-ID: <4A02F0D0.50205@beardz.net> Hans Petter Selasky wrote: > On Wednesday 06 May 2009, Jase Thew wrote: >> Hi, >> > > Hi, > > Can you try the following patch: > > http://perforce.freebsd.org/chv.cgi?CH=161718 > > BTW: Thanks for reporting! > > --HPS Hi Hans, The patch works perfectly - the mouse is now attaching successfully : ugen2.2: at usbus2 ums0: on usbus2 ums0: 7 buttons and [XYZ] coordinates ID=0 Thanks very much for fixing this issue. Regards, Jase. From shuvaev at physik.uni-wuerzburg.de Thu May 7 14:42:46 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Thu May 7 14:42:55 2009 Subject: gunzip | tar reports broken pipe during OOO build on amd64. In-Reply-To: References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> <4A0265ED.4070407@freebsd.org> Message-ID: <20090507144240.GA68128@wep4035.physik.uni-wuerzburg.de> On Thu, May 07, 2009 at 10:05:40AM +0400, Eygene Ryabinkin wrote: > Wed, May 06, 2009 at 09:39:09PM -0700, Tim Kientzle wrote: > > I tried but could not reproduce your bug using > > a recent -CURRENT. I downloaded this file: > > > > http://ftp.cse.yzu.edu.tw/pub/FreeBSD/distfiles/openoffice.org2/OOo_OOH680_m18_source.tar.bz2 > > > > and extracted ooo_crystal_images-1.tar.gz > > and got the same MD5 that Eygene reported. > > > > $ md5 ooo_crystal_images-1.tar.gz > > MD5 (ooo_crystal_images-1.tar.gz) = ff0d576d4b0e71c268b1516095a3d085 > > > > Where did you download your file from? > > Alexey's .tar.gz file should be also fine: he reported the checksum from > the .tar file, not .tar.gz one: > ----- > ~/tmp> md5 crystal.tar > MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a > ----- > I have the same MD5 for the .tar file: > ----- > $ md5 crystal.tar > MD5 (crystal.tar) = f9d09511003da0f59d943311a678b94a > ----- > > I am not able to reproduce the bug too, so perhaps the output from > ktrace, > ----- > ktrace -f gunzip.trace gunzip -c ooo_crystal_images-1.tar.gz | (ktrace -f tar.trace tar -xf -) > ----- > will be useful for diagnostics. The files of interest will be > gunzip.trace and tar.trace. > Ok, ktraces/kdumps on my system show that tar is exiting before the last gunzip's write :( gunzip.dump.human shows the last successful write on gunzip side and tar.dump.human shows the read sequence on tar side. gunzip has written 65536 bytes whereas tar has read 6 x 10240 = 61440 bytes and has exited thereafter. gunzip has got successful write operation (65536 bytes). At last gunzip tries to write 4932 zeros and fails... The command is exactly as above. FWIW: ~> echo $SHELL /bin/tcsh Alexey. -------------- next part -------------- [snip] 0x0fd0 0603 87f9 1773 ae4b 2b37 a19e ce15 52bc |.....s.K+7....R.| 0x0fe0 62b6 b026 c61f acf8 6fbe 1afc 89fe b3fd |b..&....o.......| 0x0ff0 7cfd ff8f fc9f 9999 83f5 0fff f74b ff7f ||............K..| 64841 gunzip 1241690009.435989 RET read 30608/0x7790 64841 gunzip 1241690009.436242 CALL write(0x1,0x800b02000,0x10000) 64841 gunzip 1241690009.444528 GIO fd 1 wrote 4096 bytes 0x0000 e15b a552 0104 0010 6b0f 00e5 dddd dd14 |.[.R....k.......| 0x0010 1403 a328 4011 deca 181e 0a24 4088 1840 |...(@......$@..@| 0x0020 310a 58bc 668e 018d 8e8e 1aa4 d702 2546 |1.X.f.........%F| [snip] 0x0fd0 3036 3534 3637 3600 3031 3435 3335 0020 |0654676.014535. | 0x0fe0 3000 0000 0000 0000 0000 0000 0000 0000 |0...............| 0x0ff0 0000 0000 0000 0000 0000 0000 0000 0000 |................| 64841 gunzip 1241690009.444537 RET write 65536/0x10000 64841 gunzip 1241690009.444627 CALL write(0x1,0x800b02000,0x1344) 64841 gunzip 1241690009.444638 RET write -1 errno 32 Broken pipe 64841 gunzip 1241690009.444722 PSIG SIGPIPE SIG_DFL -------------- next part -------------- [snip] 0x0290 1f47 1090 009a 9a9a 62df 1e00 0280 2814 |.G......b.....(.| 0x02a0 0acc a0c5 00e7 1840 2983 bc13 253c 4319 |.......@)...%....]:| [snip] 0x0fd0 77f7 98cd 4624 3140 28fe 8432 0c6f 8665 |w...F$1@(..2.o.e| 0x0fe0 0d4c 8a97 4624 8f30 c886 bb6f dffe b1b0 |.L..F$.0...o....| 0x0ff0 b0f0 411c 632c 1249 7df2 c557 f527 8f52 |..A.c,.I}..W.'.R| 64842 bsdtar 1241690009.439197 RET read 10240/0x2800 [snip] /* 4-th read. */ 64842 bsdtar 1241690009.439945 CALL read(0,0x801069000,0x2800) 64842 bsdtar 1241690009.439955 GIO fd 0 read 4096 bytes 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0010 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0020 0000 0000 0000 0000 0000 0000 0000 0000 |................| [snip] 0x0fd0 c5e9 d4df e60b 2f9e e1e6 6894 0251 b486 |....../...h..Q..| 0x0fe0 cd50 d522 b4d6 62a5 1a60 664c e59b 5fd2 |.P."..b..`fL.._.| 0x0ff0 7979 56a1 6d5a d84e 4356 d713 ff0d bdbe |yyV.mZ.NCV......| 64842 bsdtar 1241690009.439962 RET read 10240/0x2800 [snip] /* 5-th read. */ 64842 bsdtar 1241690009.441049 CALL read(0,0x801069000,0x2800) 64842 bsdtar 1241690009.441059 GIO fd 0 read 4096 bytes 0x0000 71f1 e5b8 e9e9 993b 667c 56c1 47b8 b6c5 |q......;f|V.G...| 0x0010 361b fc38 687d affb 4c9d 0a8f 8951 1b05 |6..8h}..L....Q..| 0x0020 52f1 95b8 0d7c 1930 1ee2 993e 243e ade0 |R....|.0...>$>..| [snip] 0x0fd0 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0fe0 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0ff0 0000 0000 0000 0000 0000 0000 0000 0000 |................| 64842 bsdtar 1241690009.441065 RET read 10240/0x2800 [snip] /* 6-th read. */ 64842 bsdtar 1241690009.442445 CALL read(0,0x801069000,0x2800) 64842 bsdtar 1241690009.442455 GIO fd 0 read 4096 bytes 0x0000 d357 8185 7ed3 ae16 c5d2 c425 b41c af2f |.W..~......%.../| 0x0010 31b8 471e aacc 5053 53eb 7e4d 6dc3 e8d9 |1.G...PSS.~Mm...| 0x0020 53f5 6f3f 3e8a 94b1 9000 e6af 03cf af11 |S.o?>...........| [snip] 0x0fd0 71b9 94bc 06e8 3b15 82e2 13a4 3ced c2af |q.....;.....<...| 0x0fe0 f258 57a0 c20b 4081 8069 f18e 7938 334e |.XW...@..i..y83N| 0x0ff0 72a0 abca 9f59 10ee 3e12 8a01 b3f7 c13d |r....Y..>......=| 64842 bsdtar 1241690009.442462 RET read 10240/0x2800 [snip] 64842 bsdtar 1241690009.443046 CALL futimes(0x3,0x7fffffffe3b0) 64842 bsdtar 1241690009.443056 RET futimes 0 64842 bsdtar 1241690009.443062 CALL close(0x3) 64842 bsdtar 1241690009.443069 RET close 0 64842 bsdtar 1241690009.443097 CALL lutimes(0x80101b320,0x7fffffffe3c0) 64842 bsdtar 1241690009.443104 NAMI "crystal/vcl/source/src/" 64842 bsdtar 1241690009.443121 RET lutimes 0 64842 bsdtar 1241690009.443128 CALL lutimes(0x80101b300,0x7fffffffe3c0) 64842 bsdtar 1241690009.443135 NAMI "crystal/vcl/source/" 64842 bsdtar 1241690009.443150 RET lutimes 0 64842 bsdtar 1241690009.443156 CALL lutimes(0x80108e0d0,0x7fffffffe3c0) 64842 bsdtar 1241690009.443162 NAMI "crystal/vcl/" 64842 bsdtar 1241690009.443176 RET lutimes 0 [snip] 64842 bsdtar 1241690009.444351 CALL lutimes(0x80108e060,0x7fffffffe3c0) 64842 bsdtar 1241690009.444357 NAMI "crystal/" 64842 bsdtar 1241690009.444369 RET lutimes 0 64842 bsdtar 1241690009.444398 CALL sigaction(SIG29,0x7fffffffe520,0x7fffffffe500) 64842 bsdtar 1241690009.444407 RET sigaction 0 64842 bsdtar 1241690009.444413 CALL sigaction(SIGUSR1,0x7fffffffe520,0x7fffffffe500) 64842 bsdtar 1241690009.444419 RET sigaction 0 64842 bsdtar 1241690009.444440 CALL sigprocmask(SIG_BLOCK,0x8006417e0,0x7fffffffe690) 64842 bsdtar 1241690009.444448 RET sigprocmask 0 64842 bsdtar 1241690009.444455 CALL sigprocmask(SIG_SETMASK,0x8006417f0,0) 64842 bsdtar 1241690009.444461 RET sigprocmask 0 64842 bsdtar 1241690009.444476 CALL sigprocmask(SIG_BLOCK,0x8006417e0,0x7fffffffe660) 64842 bsdtar 1241690009.444482 RET sigprocmask 0 64842 bsdtar 1241690009.444488 CALL sigprocmask(SIG_SETMASK,0x8006417f0,0) 64842 bsdtar 1241690009.444494 RET sigprocmask 0 64842 bsdtar 1241690009.444510 CALL exit(0) From roberto at keltia.freenix.fr Thu May 7 16:22:57 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Thu May 7 16:23:29 2009 Subject: Hypertherading In-Reply-To: <32413E83-2059-4A47-AB45-EA7A1A509DD6@gid.co.uk> References: <270637.78561.qm@web63905.mail.re1.yahoo.com> <32413E83-2059-4A47-AB45-EA7A1A509DD6@gid.co.uk> Message-ID: <4A030ADB.9050802@keltia.freenix.fr> On 7/05/2009 10:17, Bob Bishop wrote: > AFAICS the reference doesn't support that conclusion at all. Nehalem CPUs'HT feature is significantly different from the one present in previous P4 CPUs. Apparently, Nehalem's HT works. Memory bandwidth being much higher helps too. -- Ollivier Robert -=- roberto@keltia.freenix.fr From scottl at samsco.org Thu May 7 16:26:12 2009 From: scottl at samsco.org (Scott Long) Date: Thu May 7 16:26:21 2009 Subject: Hypertherading In-Reply-To: <4A030ADB.9050802@keltia.freenix.fr> References: <270637.78561.qm@web63905.mail.re1.yahoo.com> <32413E83-2059-4A47-AB45-EA7A1A509DD6@gid.co.uk> <4A030ADB.9050802@keltia.freenix.fr> Message-ID: <4A030BA1.8070709@samsco.org> Ollivier Robert wrote: > On 7/05/2009 10:17, Bob Bishop wrote: >> AFAICS the reference doesn't support that conclusion at all. > Nehalem CPUs'HT feature is significantly different from the one present > in previous P4 CPUs. Apparently, Nehalem's HT works. Memory bandwidth > being much higher helps too. > I keep here the anecdote that "it's better". Is there a good reference somewhere that describes exactly how it works? Scott From spawk at acm.poly.edu Thu May 7 16:38:13 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Thu May 7 16:38:19 2009 Subject: Hypertherading In-Reply-To: <418018.46727.qm@web63901.mail.re1.yahoo.com> References: <418018.46727.qm@web63901.mail.re1.yahoo.com> Message-ID: <4A0307F7.6000403@acm.poly.edu> Barney Cordoba wrote: > > > --- On Wed, 5/6/09, pluknet wrote: > > >> From: pluknet >> Subject: Re: Hypertherading >> To: "Barney Cordoba" >> Cc: "Current@freebsd.org" >> Date: Wednesday, May 6, 2009, 10:55 PM >> 2009/5/7 Barney Cordoba : >> >>> I just got a shiny new nehalem box and it comes up >>> >> with 16 processors with dual quads installed. Is there any >> benefit or should hyperthreading be disabled? >> >> Hi. There is a measurable win if hyperthreading is enabled >> [1]. >> You can switch it off via machdep.hyperthreading_enabled >> loader tunable. >> >> [1] >> http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047460.html >> >> >> -- >> wbr, >> pluknet >> > > I assume you mean hyperthreading-allowed? > > I set > > sysctl -a | grep hyper > > machdep.hyperthreading_allowed: 0 > > > but it still launches 16 cpus. Is that expected? It doesn't seem correct. > > Barney > > > > _______________________________________________ > 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" > If I recall correctly, that sysctl only prevents processes from being scheduled on the "virtual" hyper-threaded CPUs, and does not affect their discovery by the kernel. -Boris From kientzle at freebsd.org Thu May 7 17:51:52 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Thu May 7 17:51:59 2009 Subject: gunzip | tar reports broken pipe during OOO build on amd64. In-Reply-To: <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> Message-ID: <4A031FB6.2050907@freebsd.org> >>>> Tue, May 05, 2009 at 07:48:31PM +0200, Alexey Shuvaev wrote: >>>>> The reason appeared to be the first part of the command >>>>> "gunzip -c ... | ( tar -xf - ) && touch ..." >>>>> which exited with non-zero exit status (141) and "touch ..." was not >>> called. >>>>> Running the command manually has showed that gunzip was complaining >>> about >>>>> broken pipe (however the archive was extracted successfully). >>>> Yes, 141 means that SIGPIPE was delivered. This in turn means that >>>> 'tar -xf -' exited before gunzip had finished its job and gunzip had >>>> tried to write more data to the pipe. I finally reproduced this; it seems to only happen with /bin/csh. It does not happen with /bin/sh or bash. Also, in /bin/csh, this works: (gunzip -c ooo_crystal_images-1.tar.gz | tar xf -) && echo OK and this fails: gunzip -c ooo_crystal_images-1.tar.gz | (tar xf -) && echo OK Tim From nakal at web.de Thu May 7 19:06:23 2009 From: nakal at web.de (Martin) Date: Thu May 7 19:06:31 2009 Subject: ZFS panic space_map.c line 110 Message-ID: <20090507210516.06331fb2@zelda.local> Hi, I have a file server running ZFS on -CURRENT. Someone has tried to transfer a file with several gigabytes onto the system. The kernel crashed with a panic and freezed up during spewing the panic. I've only written down the most important messages: solaris assert ss==NULL zfs/space_map.c line 110 process: 160 spa_zio I've heard that I can try to move the zpool cache away and import the zpool with force once again. Will this help? I am asking because I don't know if the panic is caused by a corrupt cache or corrupt file system metadata. Maybe someone can explain it. (I had to switch the server off very ungently and the underlying RAID is rebuilding, so I can try it out later.) Is this issue with inconsistent zpools well known? I've seen some posts from 2007 and January 2009 that reported similar problems. Apparently some people have lost their entire zpools multiple times already, as far as I understood it. One more piece of information I can give is that every hour the ZFS file systems create snapshots. Maybe it triggered some inconsistency between the writes to a file system and the snapshot, I cannot tell, because I don't understand the condition. -- Martin From dfr at rabson.org Thu May 7 19:42:45 2009 From: dfr at rabson.org (Doug Rabson) Date: Thu May 7 19:42:59 2009 Subject: NFS lockd/statd lock up network connection In-Reply-To: <49FCB96E.1010604@sdf.lonestar.org> References: <49D851FC.4090103@sdf.lonestar.org> <49FCB96E.1010604@sdf.lonestar.org> Message-ID: <05FB85E2-1BB9-4EA7-9ED2-C92CB1014783@rabson.org> On 2 May 2009, at 17:21, Tom McLaughlin wrote: > Doug Rabson wrote, On 04/08/2009 03:20 PM: >> On 5 Apr 2009, at 07:38, Tom McLaughlin wrote: >>> Hey, I have a recent -CURRENT box which has a mount exported from an >>> OpenBSD NFS server. Recently I enabled lockd and statd on the >>> machine >>> but this has started to cause the network connection on the >>> machine to lockup. I find the following in dmesg: >>> >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> nfs server exports:/mnt/raid0/net/home: lockd not responding >>> NLM: failed to contact remote rpcbind, stat = 5, port = 28416 >>> >>> Additionally I see this when trying to restart netif: >>> >>> em0: Could not setup receive structures >>> >>> I've tried building with NFS_LEGACYRPC but that has not changed >>> anything. Additionally I've tested this on 7-STABLE and while >>> lockd still does not work (so, looks like I'll still have to work >>> around my need for NFS locking) the network connection at least >>> does not lock up. Is what I'm seeing evidence of some further >>> problem? >> It looks as if lockd is not running on the server. The NFS locking >> protocol needs it enabled at both ends. Also, NFS_LEGACYRPC won't >> affect this - the record locking code always uses the new RPC code. > > Hi Doug, lockd is runing on both ends. The problem appears to be > with the system running out of mbuf clusters when using lockd. [1] > For now I'm mounting the particular mount with nolockd as an option > to get around this. I've gotten errors with my -STABLE box using > this mount with lockd enabled but at least the system didn't run out > of mbuf clusters and lose all network connectivity. Could you please try the attached (unfortunately untested - I'm at BSDCan) patch and see if it affects your problem. This patch attempts to fix PR 130628 which appears similar to your issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: rpc-deadlock.diff Type: application/octet-stream Size: 10744 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090507/a54c192d/rpc-deadlock.obj -------------- next part -------------- From kientzle at freebsd.org Thu May 7 20:33:25 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Thu May 7 20:33:32 2009 Subject: gunzip | tar reports broken pipe during OOO build on amd64. In-Reply-To: <20090507193213.GC70931@wep4035.physik.uni-wuerzburg.de> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> <3GBQgy9AhtC1kpgclCTM4BIxKP8@AbNt2aYVonA6XSQc9As8EVwIk24> <20090506032832.GB45796@wep4035.physik.uni-wuerzburg.de> <92cd2ff70905060501vaaf67bdnaee1be72e04f1ef8@mail.gmail.com> <20090506192603.GA56228@wep4035.physik.uni-wuerzburg.de> <4A031FB6.2050907@freebsd.org> <20090507184121.GA70931@wep4035.physik.uni-wuerzburg.de> <20090507193213.GC70931@wep4035.physik.uni-wuerzburg.de> Message-ID: <4A034594.4010405@freebsd.org> Alexey Shuvaev wrote: > On Thu, May 07, 2009 at 08:41:21PM +0200, Alexey Shuvaev wrote: >> On Thu, May 07, 2009 at 10:51:50AM -0700, Tim Kientzle wrote: >>> I finally reproduced this; it seems to only happen with >>> /bin/csh. It does not happen with /bin/sh or bash. >>> >>> Also, in /bin/csh, this works: >>> >>> (gunzip -c ooo_crystal_images-1.tar.gz | tar xf -) && echo OK >>> >>> and this fails: >>> >>> gunzip -c ooo_crystal_images-1.tar.gz | (tar xf -) && echo OK >>> >> Do you mean it is a bug in [t]csh? No, this is definitely a bug in tar. I finally found the place where tar was not always reading beyond end-of-archive on a pipe. This doesn't show up under /bin/sh or bash because for those shells, the return status of "gunzip|tar" is the exit status of the last command ("tar"). For csh, the return status of the pipeline is the return status of the first command. So for other shells, the SIGPIPE exit from gunzip doesn't cause the whole sequence to fail (because "tar" exits with success). I'm testing a fix now; it will be committed later today. Tim From tinderbox at freebsd.org Thu May 7 22:03:39 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu May 7 22:03:47 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090507220336.10EBA7302F@freebsd-current.sentex.ca> TB --- 2009-05-07 21:18:13 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-07 21:18:13 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-05-07 21:18:13 - cleaning the object tree TB --- 2009-05-07 21:18:46 - cvsupping the source tree TB --- 2009-05-07 21:18:46 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-05-07 21:19:00 - building world TB --- 2009-05-07 21:19:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-07 21:19:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-07 21:19:00 - TARGET=sun4v TB --- 2009-05-07 21:19:00 - TARGET_ARCH=sparc64 TB --- 2009-05-07 21:19:00 - TZ=UTC TB --- 2009-05-07 21:19:00 - __MAKE_CONF=/dev/null TB --- 2009-05-07 21:19:00 - cd /src TB --- 2009-05-07 21:19:00 - /usr/bin/make -B buildworld >>> World build started on Thu May 7 21:19:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool /obj/sun4v/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini' *** Error code 1 Stop in /src/cddl/usr.bin/zinject. *** Error code 1 Stop in /src/cddl/usr.bin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-07 22:03:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-07 22:03:35 - ERROR: failed to build world TB --- 2009-05-07 22:03:35 - 2232.81 user 262.47 system 2722.11 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Thu May 7 23:03:36 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu May 7 23:03:53 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <20090507230331.1C16E7302F@freebsd-current.sentex.ca> TB --- 2009-05-07 22:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-07 22:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-05-07 22:20:00 - cleaning the object tree TB --- 2009-05-07 22:20:48 - cvsupping the source tree TB --- 2009-05-07 22:20:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-05-07 22:20:58 - building world TB --- 2009-05-07 22:20:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-07 22:20:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-07 22:20:58 - TARGET=arm TB --- 2009-05-07 22:20:58 - TARGET_ARCH=arm TB --- 2009-05-07 22:20:58 - TZ=UTC TB --- 2009-05-07 22:20:58 - __MAKE_CONF=/dev/null TB --- 2009-05-07 22:20:58 - cd /src TB --- 2009-05-07 22:20:58 - /usr/bin/make -B buildworld >>> World build started on Thu May 7 22:21:00 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool /obj/arm/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini' *** Error code 1 Stop in /src/cddl/usr.bin/zinject. *** Error code 1 Stop in /src/cddl/usr.bin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-07 23:03:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-07 23:03:30 - ERROR: failed to build world TB --- 2009-05-07 23:03:30 - 1926.59 user 271.18 system 2610.58 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From kientzle at freebsd.org Thu May 7 23:09:38 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Thu May 7 23:09:45 2009 Subject: gunzip | tar reports broken pipe during OOO build on amd64. In-Reply-To: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> References: <20090505174831.GA40305@wep4035.physik.uni-wuerzburg.de> Message-ID: <4A036A2C.1070606@freebsd.org> Alexey Shuvaev wrote: > Hello all! > > I was trying to upgrade editors/openoffice.org-2 recently and > build failed for me at: ... > The reason appeared to be the first part of the command > "gunzip -c ... | ( tar -xf - ) && touch ..." > which exited with non-zero exit status (141) and "touch ..." was not called. > Running the command manually has showed that gunzip was complaining about > broken pipe (however the archive was extracted successfully). I just committed r191904, which should fix the tar problem (actually, a libarchive problem) that caused this. This problem was introduced in r191171 on 2009-04-16 when I went a little too far trying to eliminate some duplicated code. As a result, tar was no longer flushing the pipe after it hit end-of-archive, which caused gunzip to receive SIGPIPE for the final writes. This only causes problems with /bin/csh, which reports the exit status of the first command in a pipeline (unlike /bin/sh, which reports the exit status of the last command). Tim From tinderbox at freebsd.org Thu May 7 23:14:13 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu May 7 23:14:20 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090507231408.D1B3A7302F@freebsd-current.sentex.ca> TB --- 2009-05-07 22:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-07 22:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-05-07 22:20:00 - cleaning the object tree TB --- 2009-05-07 22:21:25 - cvsupping the source tree TB --- 2009-05-07 22:21:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-05-07 22:21:33 - building world TB --- 2009-05-07 22:21:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-07 22:21:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-07 22:21:33 - TARGET=amd64 TB --- 2009-05-07 22:21:33 - TARGET_ARCH=amd64 TB --- 2009-05-07 22:21:33 - TZ=UTC TB --- 2009-05-07 22:21:33 - __MAKE_CONF=/dev/null TB --- 2009-05-07 22:21:33 - cd /src TB --- 2009-05-07 22:21:33 - /usr/bin/make -B buildworld >>> World build started on Thu May 7 22:21:34 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool /obj/amd64/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini' *** Error code 1 Stop in /src/cddl/usr.bin/zinject. *** Error code 1 Stop in /src/cddl/usr.bin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-07 23:14:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-07 23:14:08 - ERROR: failed to build world TB --- 2009-05-07 23:14:08 - 2356.94 user 283.40 system 3248.40 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From kip.macy at gmail.com Thu May 7 23:42:54 2009 From: kip.macy at gmail.com (Kip Macy) Date: Thu May 7 23:43:02 2009 Subject: [head tinderbox] failure on amd64/amd64 In-Reply-To: <20090507231408.D1B3A7302F@freebsd-current.sentex.ca> References: <20090507231408.D1B3A7302F@freebsd-current.sentex.ca> Message-ID: <3c1674c90905071642g5aa13b69t8ba74ca53007bfc@mail.gmail.com> Fixed, sorry. I didn't realize the user version of ZFS was being compiled. -Kip On Thu, May 7, 2009 at 4:14 PM, FreeBSD Tinderbox wrote: > TB --- 2009-05-07 22:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-05-07 22:20:00 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2009-05-07 22:20:00 - cleaning the object tree > TB --- 2009-05-07 22:21:25 - cvsupping the source tree > TB --- 2009-05-07 22:21:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile > TB --- 2009-05-07 22:21:33 - building world > TB --- 2009-05-07 22:21:33 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-05-07 22:21:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-05-07 22:21:33 - TARGET=amd64 > TB --- 2009-05-07 22:21:33 - TARGET_ARCH=amd64 > TB --- 2009-05-07 22:21:33 - TZ=UTC > TB --- 2009-05-07 22:21:33 - __MAKE_CONF=/dev/null > TB --- 2009-05-07 22:21:33 - cd /src > TB --- 2009-05-07 22:21:33 - /usr/bin/make -B buildworld >>>> World build started on Thu May ?7 22:21:34 UTC 2009 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything > [...] > cc -O2 -pipe ?-DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris ?-I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include ?-I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include ?-I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas ?-o sgsmsg avl.o sgsmsg.o string_table.o findprime.o > ===> cddl/usr.bin/zinject (all) > cc -O2 -pipe ?-I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c > cc -O2 -pipe ?-I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c > /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': > /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type > cc -O2 -pipe ?-I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas ?-o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool > /obj/amd64/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini' > *** Error code 1 > > Stop in /src/cddl/usr.bin/zinject. > *** Error code 1 > > Stop in /src/cddl/usr.bin. > *** Error code 1 > > Stop in /src/cddl. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-05-07 23:14:08 - WARNING: /usr/bin/make returned exit code ?1 > TB --- 2009-05-07 23:14:08 - ERROR: failed to build world > TB --- 2009-05-07 23:14:08 - 2356.94 user 283.40 system 3248.40 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full > _______________________________________________ > 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" > -- All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke From tinderbox at freebsd.org Thu May 7 23:54:23 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu May 7 23:54:30 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <20090507235420.6CB2A7302F@freebsd-current.sentex.ca> TB --- 2009-05-07 23:03:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-07 23:03:31 - starting HEAD tinderbox run for i386/i386 TB --- 2009-05-07 23:03:31 - cleaning the object tree TB --- 2009-05-07 23:04:11 - cvsupping the source tree TB --- 2009-05-07 23:04:11 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-05-07 23:04:18 - building world TB --- 2009-05-07 23:04:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-07 23:04:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-07 23:04:18 - TARGET=i386 TB --- 2009-05-07 23:04:18 - TARGET_ARCH=i386 TB --- 2009-05-07 23:04:18 - TZ=UTC TB --- 2009-05-07 23:04:18 - __MAKE_CONF=/dev/null TB --- 2009-05-07 23:04:18 - cd /src TB --- 2009-05-07 23:04:18 - /usr/bin/make -B buildworld >>> World build started on Thu May 7 23:04:20 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool /obj/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini' *** Error code 1 Stop in /src/cddl/usr.bin/zinject. *** Error code 1 Stop in /src/cddl/usr.bin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-07 23:54:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-07 23:54:20 - ERROR: failed to build world TB --- 2009-05-07 23:54:20 - 2296.38 user 268.37 system 3049.07 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From tinderbox at freebsd.org Fri May 8 00:05:39 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri May 8 00:05:52 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090508000535.C52817302F@freebsd-current.sentex.ca> TB --- 2009-05-07 23:14:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-07 23:14:09 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-07 23:14:09 - cleaning the object tree TB --- 2009-05-07 23:14:41 - cvsupping the source tree TB --- 2009-05-07 23:14:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-07 23:14:50 - building world TB --- 2009-05-07 23:14:50 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-07 23:14:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-07 23:14:50 - TARGET=pc98 TB --- 2009-05-07 23:14:50 - TARGET_ARCH=i386 TB --- 2009-05-07 23:14:50 - TZ=UTC TB --- 2009-05-07 23:14:50 - __MAKE_CONF=/dev/null TB --- 2009-05-07 23:14:50 - cd /src TB --- 2009-05-07 23:14:50 - /usr/bin/make -B buildworld >>> World build started on Thu May 7 23:14:52 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool /obj/pc98/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini' *** Error code 1 Stop in /src/cddl/usr.bin/zinject. *** Error code 1 Stop in /src/cddl/usr.bin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-08 00:05:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-08 00:05:35 - ERROR: failed to build world TB --- 2009-05-08 00:05:35 - 2292.02 user 280.10 system 3086.78 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From kmacy at freebsd.org Fri May 8 02:19:42 2009 From: kmacy at freebsd.org (Kip Macy) Date: Fri May 8 02:19:49 2009 Subject: ZFS panic space_map.c line 110 In-Reply-To: <20090507210516.06331fb2@zelda.local> References: <20090507210516.06331fb2@zelda.local> Message-ID: <3c1674c90905071919k55e1bf86yc64b54a10b142c8d@mail.gmail.com> This panic indicates that the caller expected there to be free space between start and (start + size), but none was found. This could be a locking bug or a space map corruption (depressing). There really isn't enough context here for me to go on. If you can't get a core, please at least provide us with a backtrace from ddb. Thanks, Kip On Thu, May 7, 2009 at 12:05 PM, Martin wrote: > > Hi, > > I have a file server running ZFS on -CURRENT. Someone has tried to > transfer a file with several gigabytes onto the system. The kernel > crashed with a panic and freezed up during spewing the panic. I've only > written down the most important messages: > > solaris assert ss==NULL > zfs/space_map.c line 110 > > process: 160 spa_zio > > I've heard that I can try to move the zpool cache away and import the > zpool with force once again. Will this help? I am asking because I > don't know if the panic is caused by a corrupt cache or corrupt > file system metadata. Maybe someone can explain it. (I had to switch the > server off very ungently and the underlying RAID is rebuilding, so I > can try it out later.) > > Is this issue with inconsistent zpools well known? I've seen some posts > from 2007 and January 2009 that reported similar problems. Apparently > some people have lost their entire zpools multiple times already, as > far as I understood it. > > One more piece of information I can give is that every hour the ZFS file > systems create snapshots. Maybe it triggered some inconsistency between > the writes to a file system and the snapshot, I cannot tell, because I > don't understand the condition. > > -- > Martin > _______________________________________________ > 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" > -- All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke From rmtodd at ichotolot.servalan.com Fri May 8 03:46:11 2009 From: rmtodd at ichotolot.servalan.com (Richard Todd) Date: Fri May 8 03:46:20 2009 Subject: ZFS panic space_map.c line 110 In-Reply-To: (Martin's message of "Thu, 7 May 2009 21:05:16 +0200") References: <20090507210516.06331fb2@zelda.local> Message-ID: Martin writes: > Hi, > > I have a file server running ZFS on -CURRENT. Someone has tried to > transfer a file with several gigabytes onto the system. The kernel > crashed with a panic and freezed up during spewing the panic. I've only > written down the most important messages: > > solaris assert ss==NULL > zfs/space_map.c line 110 > > process: 160 spa_zio > > I've heard that I can try to move the zpool cache away and import the > zpool with force once again. Will this help? I kinda doubt it. > zpool with force once again. Will this help? I am asking because I > don't know if the panic is caused by a corrupt cache or corrupt > file system metadata. Maybe someone can explain it. (I had to switch the This panic wouldn't have anything to do with zpool.cache (that's just a file to help the system find which devices it should expect to find zpools on during boot). This is a problem with the free space map, which is part of the filesystem metadata. If you're lucky, it's just the in-core copy of the free space map that was bogus and there's a valid map on disk. If you're unlucky, the map on disk is trashed, and there's no really easy way to recover that pool. > Is this issue with inconsistent zpools well known? I've seen some posts > from 2007 and January 2009 that reported similar problems. Apparently > some people have lost their entire zpools multiple times already, as > far as I understood it. Mine was probably one of those messages; I managed to get an error like that once, through Seriously Provoking the system (repeatedly unmounting and mounting the main filesystem on one pool) while attempting to debug a different, unrelated problem. It's not something I've ever seen in any sort of "normal" usage, and just copying a few gig to the FS shouldn't cause this sort of problem. I managed to recover the data without having to resort to backups, by hacking the kernel to disable some of the asserts in space_map.c, iterating until I reached a point where I got a kernel that could import the pool without panicing. Once I did that I managed to mount the fs readonly and copy everything off to a different device. Like I said, not an *easy* way to recover that data. > One more piece of information I can give is that every hour the ZFS file > systems create snapshots. Maybe it triggered some inconsistency between > the writes to a file system and the snapshot, I cannot tell, because I > don't understand the condition. I doubt this had anything to do with the problem. From Benjamin.Close at clearchain.com Fri May 8 03:50:58 2009 From: Benjamin.Close at clearchain.com (Benjamin Close) Date: Fri May 8 03:51:05 2009 Subject: zfsboot, MBR/partition table based setup, zfs loader issues Message-ID: <4A03A3C9.3060503@clearchain.com> Hi Folks, I've been trying to setup zfs on root without a ufs partition. Not using gpt but using a standard mbr/partition table. After digging through the code I found having it on a bsd slice (aka a,b,d,e,f etc) is impossible. Though having it on a partition should be possible. I've got most of the way but now have hit a point where there's something not quite working and I don't know how to debug it further. The setup is: amd64 ad4s1 - winxp ad4s2 - zpool:data I'm using the -current snapshot fixit cdrom from 200902 I've successfully installed boot1/2 using: # dd if=/mnt2/boot/zfsboot of=/dev/da0s1 count=1 # dd if=/mnt2/boot/zfsboot of=/dev/da0s1 skip=1 seek=1024 and created a pool using: # cd /mnt2/boot/kernel # kldload ./opensolaris.ko # kldload ./zfs.ko # zpool create data /dev/ad4s2 # cp -a /dist/boot /data/boot Most the setup is working. Boot2 is starting the loader but the loader is unable to see any zfs pools (even though it's built with LOADER_WITH_ZFS on another box). I've been trying to narrow down the issue with the loader. Turns out the loader gets the correct guid for the pool from boot2 but when loader reprobes the bios disks via: zfsimpl.c:837:zio_read_phy: rc=vdev->v_read(vdev,vdev->vread_priv, offset, buf,psize) zfsimpl.c:644:vdev_probe : zio_read_phys(&vtmp,&bp,vdev_label,off) zfs.c :438:zfs_dev_init: vdev_probe(vdev_read, (void *)(uintptr_t)fd, 0)) main.c :167:main : devsw[i]->dv_init() the resultant read succeeds but the following call to zio_checksum_error confirms the checksum is wrong. I've destroyed the pool and recreated it just incase the sum was wrong. However, I suspect the ldr is reading the wrong data from the disk. vdev->v_read is the function: vdev_read( vdev_t *vdev, void *priv, off_t offset, void *buf, size_t size), being called with: vdev_read( tempstruct built in vdev_probe, fd = 0 opened in vdev_probe for ad4s2, offset = 0x4000 from offsetof(vdev_label_t, vl_vdevphys) in vdev_probe, a buffer - vdev_label (which = zscratch), 113800 - sizeof(vdev_phys_t), via get/set BP_PSIZE in vdev_probe) The read is successful. What I question is the following: o Why do all devices return fd=0 on an open call, is this because it's loader code and there's no unique numbering? If so do offsets have to be applied for slices? Ie is it 0x4000 + some slice offset? o Does the read (based on asm in zfsldr.S) actually have valid data at offset 0x4000 - The comment in the file seems to indicate data is only valid above 0x8000 or am I mixing up memory/vs disk addressing? /* * Ok, we have a slice and drive in %dx now, so use that to locate and * load boot2. %si references the start of the slice we are looking * for, so go ahead and load up the 64 sectors starting at sector 1024 * (i.e. after the two vdev labels). We don't have do anything fancy * here to allow for an extra copy of boot1 and a partition table * (compare to this section of the UFS bootstrap) so we just load it * all at 0x8000. The first part of boot2 is BTX, which wants to run * at 0x9000. The boot2.bin binary starts right after the end of BTX, * so we have to figure out where the start of it is and then move the * binary to 0xc000. After we have moved the client, we relocate BTX * itself to 0x9000 - doing it in this order means that none of the * memcpy regions overlap which would corrupt the copy. Normally, BTX * clients start at MEM_USR, or 0xa000, but when we use btxld to * create boot2, we use an entry point of 0x2000. That entry point is * relative to MEM_USR; thus boot2.bin starts at 0xc000. Any help would be appreciated in getting this working as having FBSD boot off zfs natively is a huge win. Cheers, Benjamin From kabaev at gmail.com Fri May 8 03:59:47 2009 From: kabaev at gmail.com (Alexander Kabaev) Date: Fri May 8 03:59:53 2009 Subject: Panic: wrong vnode type 0xffffff009b7719c0 on yesterday's current. In-Reply-To: <619B386D-9FF5-4296-BB83-245881CA9C41@wanderview.com> References: <20090506234631.231A5CD8@mx1.synetsystems.com> <619B386D-9FF5-4296-BB83-245881CA9C41@wanderview.com> Message-ID: <8e5ef5f70905072059u51dcdbe8nd5b66f6fb5c124e4@mail.gmail.com> > On May 6, 2009, at 6:54 PM, Richard Todd wrote: > It looks like this KASSERT was added relatively recently as part of the > dotdot changes to the namecache: > > ?http://svn.freebsd.org/viewvc/base?view=revision&revision=190945 > > Perhaps there is further fallout from the changes that only occur with ZFS? > > - Ben Up to recently dotdot caching in VFS was quite broken and did pay any attention to vnode types FSes did feed to it. >From backtrace and analysis provided by original poster it is evident that ZFS is trying to cache_enter(VDIR, "..", VLNK), which cannot possibly make any sense. kib@ has recently committed fixes to FFS to avoid races with vnodes being reused from under ffs_lookup, and I would not be surprised if ZFS was broken is similar fashion. -- Alexander Kabaev From nakal at web.de Fri May 8 07:20:42 2009 From: nakal at web.de (Martin) Date: Fri May 8 07:20:49 2009 Subject: ZFS panic space_map.c line 110 In-Reply-To: References: <20090507210516.06331fb2@zelda.local> Message-ID: <20090508092033.299daab6@zelda.local> Hi Richard and Kip, @Richard: > This panic wouldn't have anything to do with zpool.cache (that's just > a file to help the system find which devices it should expect to find > zpools on during boot). This is a problem with the free space map, > which is part of the filesystem metadata. If you're lucky, it's just > the in-core copy of the free space map that was bogus and there's a > valid map on disk. If you're unlucky, the map on disk is trashed, > and there's no really easy way to recover that pool. I really cannot tell. I thought it would be nice to have ZFS for jail managements, so I can create one file system for one jail that's why I installed -CURRENT with version 13 of ZFS on a server in production. > > One more piece of information I can give is that every hour the ZFS > > file systems create snapshots. Maybe it triggered some > > inconsistency between the writes to a file system and the snapshot, > > I cannot tell, because I don't understand the condition. > > I doubt this had anything to do with the problem. Well, you said you provoked the panic by mounting and unmounting very often. The zfs-snapshot-mgmt port that I used shows similar behavior in certain situations. @Kip: > This could be a locking bug or a space map corruption (depressing). > There really isn't enough context here for me to go on. If you can't > get a core, please at least provide us with a backtrace from ddb. It does not look like a locking bug to me. I tried several times to get the pool running, also with an older kernel. It paniced in the same way. I could get past the panic the first time, when I removed zfs_enable="YES" from rc.conf. ZFS really made we worried and I removed the pools now, created UFS partition and restored all data from backup. Sorry, I did not investigate the problem deeper because I wanted to get the file server running and thought that the exact panic line number and mentioning the situation (during importing the pool) would be enough to make the problem clear. Nothing was lost, this ZFS data corruption just ended my ZFS experiment for now. I will use the good old UFS2 for now and check it at a later time again. Thanks to you both for your advice. -- Martin From onemda at gmail.com Fri May 8 10:34:55 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Fri May 8 10:35:06 2009 Subject: Fighting for the power. In-Reply-To: <20090507.001059.-1558772981.imp@bsdimp.com> References: <49FE1826.4060000@FreeBSD.org> <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> <20090507.001059.-1558772981.imp@bsdimp.com> Message-ID: <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> On 5/7/09, M. Warner Losh wrote: > In message: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> > "Paul B. Mahol" writes: > : On 5/4/09, Alexander Motin wrote: > : > 2. PCI devices > : > PCI bus provides method to control device power. For example, I have > : > completely no use for my FireWire controller and most of time - EHCI USB > : > controller. Disabling them allows me to save about 3W of power. To > : > disable all unneeded PCI devices you should build kernel without their > : > drivers and add to loader.conf: > : > hw.pci.do_power_nodriver=3 > : > To enable devices back all you need to do is just load their drivers as > : > modules. > : > : Unloading modules doesnt put them back into into D3 state. > : You are forced to load some another module again to put wanted device > : into D3 state. > > It should. If it isn't, that's a bug. It's a bug. On machine resume(pci_resume), pci_cfg_restore() is called causing D3 -> D0 for all devices(including not attached ones). Unloading module/detaching device doesn't call pci_cfg_save. Should device_detach routine be used or new one like pci_driver_removed() implemented? -- Paul From pluknet at gmail.com Fri May 8 11:13:52 2009 From: pluknet at gmail.com (pluknet) Date: Fri May 8 11:14:04 2009 Subject: Hypertherading In-Reply-To: <4A030BA1.8070709@samsco.org> References: <270637.78561.qm@web63905.mail.re1.yahoo.com> <32413E83-2059-4A47-AB45-EA7A1A509DD6@gid.co.uk> <4A030ADB.9050802@keltia.freenix.fr> <4A030BA1.8070709@samsco.org> Message-ID: 2009/5/7 Scott Long : > Ollivier Robert wrote: >> >> On 7/05/2009 10:17, Bob Bishop wrote: >>> >>> AFAICS the reference doesn't support that conclusion at all. >> >> Nehalem CPUs'HT feature is significantly different from the one present in >> previous P4 CPUs. ?Apparently, Nehalem's HT works. ?Memory bandwidth being >> much higher helps too. >> > > I keep here the anecdote that "it's better". ?Is there a good reference > somewhere that describes exactly how it works? > > Scott Hi. There is a number of synthetic, low-level, and h/level application nehalem tests flowing around in Russian. Also, not far ago (31.12.2008 18:09) Intel has published the Intel Optimization Reference Manual for x32/64. (see ch. 8). It might be useful. http://download.intel.com/design/processor/manuals/248966.pdf. -- wbr, pluknet From barney_cordoba at yahoo.com Fri May 8 12:22:20 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Fri May 8 12:22:27 2009 Subject: Hypertherading In-Reply-To: Message-ID: <484220.40675.qm@web63907.mail.re1.yahoo.com> --- On Fri, 5/8/09, pluknet wrote: > From: pluknet > Subject: Re: Hypertherading > To: "Scott Long" > Cc: "Ollivier Robert" , freebsd-current@freebsd.org > Date: Friday, May 8, 2009, 7:13 AM > 2009/5/7 Scott Long : > > Ollivier Robert wrote: > >> > >> On 7/05/2009 10:17, Bob Bishop wrote: > >>> > >>> AFAICS the reference doesn't support that > conclusion at all. > >> > >> Nehalem CPUs'HT feature is significantly > different from the one present in > >> previous P4 CPUs. ?Apparently, Nehalem's HT > works. ?Memory bandwidth being > >> much higher helps too. > >> > > > > I keep here the anecdote that "it's > better". ?Is there a good reference > > somewhere that describes exactly how it works? > > > > Scott > > Hi. > > There is a number of synthetic, low-level, and h/level > application > nehalem tests flowing around in Russian. > Also, not far ago (31.12.2008 18:09) Intel has published > the Intel > Optimization Reference Manual for x32/64. > (see ch. 8). It might be useful. > http://download.intel.com/design/processor/manuals/248966.pdf. > Ah, Intel says that its higher priced processors are better than their lower priced processors. There's evidence you can take to the bank. Barney From imp at bsdimp.com Fri May 8 13:10:39 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri May 8 13:10:57 2009 Subject: Fighting for the power. In-Reply-To: <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> References: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> <20090507.001059.-1558772981.imp@bsdimp.com> <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> Message-ID: <20090508.070659.1622573996.imp@bsdimp.com> In message: <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> "Paul B. Mahol" writes: : On 5/7/09, M. Warner Losh wrote: : > In message: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> : > "Paul B. Mahol" writes: : > : On 5/4/09, Alexander Motin wrote: : > : > 2. PCI devices : > : > PCI bus provides method to control device power. For example, I have : > : > completely no use for my FireWire controller and most of time - EHCI USB : > : > controller. Disabling them allows me to save about 3W of power. To : > : > disable all unneeded PCI devices you should build kernel without their : > : > drivers and add to loader.conf: : > : > hw.pci.do_power_nodriver=3 : > : > To enable devices back all you need to do is just load their drivers as : > : > modules. : > : : > : Unloading modules doesnt put them back into into D3 state. : > : You are forced to load some another module again to put wanted device : > : into D3 state. : > : > It should. If it isn't, that's a bug. : : It's a bug. : : On machine resume(pci_resume), pci_cfg_restore() is called causing D3 -> D0 for : all devices(including not attached ones). : Unloading module/detaching device doesn't call pci_cfg_save. : : Should device_detach routine be used or new one like : pci_driver_removed() implemented? No. device_detach shouldn't be used for this. This should happen all in the PCI bus code when do_power_nodriver is > 0. Warner From avg at icyb.net.ua Fri May 8 13:49:43 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri May 8 13:49:50 2009 Subject: zfsboot, MBR/partition table based setup, zfs loader issues In-Reply-To: <4A03A3C9.3060503@clearchain.com> References: <4A03A3C9.3060503@clearchain.com> Message-ID: <4A04386B.5050201@icyb.net.ua> on 08/05/2009 06:15 Benjamin Close said the following: > Hi Folks, > I've been trying to setup zfs on root without a ufs partition. Not > using gpt but using a standard mbr/partition table. > After digging through the code I found having it on a bsd slice (aka > a,b,d,e,f etc) is impossible. Though having it on a partition should be > possible. No real help here, but I think you mixed the terms. ad0s1 is a slice, as0s1a is a partition. This is in (Free)BSD conventional terms. -- Andriy Gapon From guru at unixarea.de Fri May 8 14:17:59 2009 From: guru at unixarea.de (Matthias Apitz) Date: Fri May 8 14:18:05 2009 Subject: laptop Dell M4400 with -CURRENT? In-Reply-To: <20090428083627.GA3621@rebelion.Sisis.de> References: <20090428083627.GA3621@rebelion.Sisis.de> Message-ID: <20090508141755.GB13584@rebelion.Sisis.de> El d?a Tuesday, April 28, 2009 a las 10:36:27AM +0200, Matthias Apitz escribi?: > > Hello, > > I'm planning to order a new laptop and got an offer for a Dell M4400 > with the following main details: > > Precision M4400 : Intel Core 2 Extreme X9100 (3.06GHz,1066MHz,6MB) > Base Option : 512MB Discrete nVidia FX770M Graphics Card (with 512MB dedicated memory) > Palmrest : UPEK Swipe Fingerprint Reader Biometric > Display : 15.4in Widescreen WUXGA (1920X1200) with Dual CCFL > Camera : Integrated 0.3 Mega Pixel Camera with Microphone for 2CCFL LCD Panel > LCD Back Cover : 2CCFL > Memory : 4096MB (2x2048) 800MHz DDR2 Dual Channel > disk : 250GB Serial ATA (7200 1/min) Festplatte (Free-Fall-Sensor) > Optical Drive : Roxio Creator 9.0 Software and Media Included > Optisches Laufwerk : 8x DVD+/-RW Laufwerk ohne Software > Battery : Primary 9-cell 85 W/HR LI-ION 451-10589 > Battery : Additional 6-Cell 56 W/HR LI-ION 451-10590 > Wireless : EMEA Dell Wireless 1510 (802.11a/b/g/n 2X3) MiniCard for Core 2 Extreme ONLY > Wireless : EMEA Dell Wireless 370 Bluetooth 2.1 MiniCard > Keyboard : Internal German Qwertz Keyboard I have now installed CURRENT in that Precision M4400; shrinked the Vista partition to 50 GByte and installed in the remaining 170 GByte FreeBSD CURRENT from a prepared USB key. It seems that the Quadro FX 770M Graphics Card is not supported by the NVIDIA driver in Xorg 1.6. -- any idea how to solve this? Thx in advance matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From rnoland at FreeBSD.org Fri May 8 15:28:39 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri May 8 15:28:46 2009 Subject: laptop Dell M4400 with -CURRENT? In-Reply-To: <20090508141755.GB13584@rebelion.Sisis.de> References: <20090428083627.GA3621@rebelion.Sisis.de> <20090508141755.GB13584@rebelion.Sisis.de> Message-ID: <1241796489.1733.25.camel@balrog.2hip.net> On Fri, 2009-05-08 at 16:17 +0200, Matthias Apitz wrote: > El d?a Tuesday, April 28, 2009 a las 10:36:27AM +0200, Matthias Apitz escribi?: > > > > > Hello, > > > > I'm planning to order a new laptop and got an offer for a Dell M4400 > > with the following main details: > > > > Precision M4400 : Intel Core 2 Extreme X9100 (3.06GHz,1066MHz,6MB) > > Base Option : 512MB Discrete nVidia FX770M Graphics Card (with 512MB dedicated memory) > > Palmrest : UPEK Swipe Fingerprint Reader Biometric > > Display : 15.4in Widescreen WUXGA (1920X1200) with Dual CCFL > > Camera : Integrated 0.3 Mega Pixel Camera with Microphone for 2CCFL LCD Panel > > LCD Back Cover : 2CCFL > > Memory : 4096MB (2x2048) 800MHz DDR2 Dual Channel > > disk : 250GB Serial ATA (7200 1/min) Festplatte (Free-Fall-Sensor) > > Optical Drive : Roxio Creator 9.0 Software and Media Included > > Optisches Laufwerk : 8x DVD+/-RW Laufwerk ohne Software > > Battery : Primary 9-cell 85 W/HR LI-ION 451-10589 > > Battery : Additional 6-Cell 56 W/HR LI-ION 451-10590 > > Wireless : EMEA Dell Wireless 1510 (802.11a/b/g/n 2X3) MiniCard for Core 2 Extreme ONLY > > Wireless : EMEA Dell Wireless 370 Bluetooth 2.1 MiniCard > > Keyboard : Internal German Qwertz Keyboard > > I have now installed CURRENT in that Precision M4400; shrinked the Vista > partition to 50 GByte and installed in the remaining 170 GByte FreeBSD > CURRENT from a prepared USB key. > > It seems that the Quadro FX 770M Graphics Card is not supported by the > NVIDIA driver in Xorg 1.6. -- any idea how to solve this? I have ported the nouveau drm driver. http://people.freebsd.org/~rnoland/drm-nouveau-043009.patch It is working on NV50 cards, NV40 was working, but with WITNESS enabled I seem to be getting a panic on NV40. My NV40 card seems to be having memory issues so I haven't been able to get and/or see the backtrace. I think it is just a locking issue which should be pretty easily solved if I can get a clear backtrace. You will need current libdrm and xf86-video-nouveau from ports. This won't get you 3d right now, but should get you EXA + Xv. robert. > Thx in advance > > matthias -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090508/cab440e6/attachment.pgp From fbsdlist at src.cx Fri May 8 22:04:29 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Fri May 8 22:04:38 2009 Subject: [patch] zfs.ko loading failure In-Reply-To: References: Message-ID: Hi, After recent changes (r191915) opensolaris.ko refers to utsname variable that's actually compiled into zfs.ko zfs.ko itself requires symbols from opensolaris.ko and this circular dependency leads to failure to load zfs.ko. Attached patch moves opensolaris_misc.c to modules/opensolaris and fixes the issue --Artem -------------- next part -------------- A non-text attachment was scrubbed... Name: zfs-utsname.diff Type: application/octet-stream Size: 1540 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090508/f7f02599/zfs-utsname.obj From artemb at gmail.com Fri May 8 22:01:17 2009 From: artemb at gmail.com (Artem Belevich) Date: Fri May 8 22:04:39 2009 Subject: [patch] zfs.ko loading failure Message-ID: Hi, After recent changes (r191915) opensolaris.ko refers to utsname variable that's actually compiled into zfs.ko In turn zfs.ko requires symbols from opensolaris.ko and this circular dependency leads to failure to load zfs.ko. Following patch moves opensolaris_misc.c to modules/opensolaris and fixes the issue --Artem diff -r fae94895cc67 sys/modules/opensolaris/Makefile --- a/sys/modules/opensolaris/Makefile Fri May 08 12:22:10 2009 -0700 +++ b/sys/modules/opensolaris/Makefile Fri May 08 14:59:51 2009 -0700 @@ -1,15 +1,16 @@ # $FreeBSD: head/sys/modules/opensolaris/Makefile 190374 2009-03-24 15:48:35Z marius $ .PATH: ${.CURDIR}/../../cddl/compat/opensolaris/kern KMOD= opensolaris SRCS= opensolaris.c \ opensolaris_cmn_err.c \ + opensolaris_misc.c \ opensolaris_kmem.c .if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "ia64" || ${MACHINE_ARCH} == "sparc64" .PATH: ${.CURDIR}/../../cddl/contrib/opensolaris/common/atomic/${MACHINE_ARCH} SRCS+= atomic.S .else SRCS+= opensolaris_atomic.c .endif diff -r fae94895cc67 sys/modules/zfs/Makefile --- a/sys/modules/zfs/Makefile Fri May 08 12:22:10 2009 -0700 +++ b/sys/modules/zfs/Makefile Fri May 08 14:59:51 2009 -0700 @@ -15,17 +15,16 @@ SRCS+= nvpair.c .PATH: ${.CURDIR}/../../cddl/contrib/opensolaris/common/unicode SRCS+= u8_textprep.c .PATH: ${.CURDIR}/../../cddl/compat/opensolaris/kern SRCS+= opensolaris_kmem.c SRCS+= opensolaris_kobj.c SRCS+= opensolaris_kstat.c SRCS+= opensolaris_lookup.c -SRCS+= opensolaris_misc.c SRCS+= opensolaris_policy.c SRCS+= opensolaris_string.c SRCS+= opensolaris_vfs.c SRCS+= opensolaris_zone.c .if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "ia64" || ${MACHINE_ARCH} == "sparc64" .PATH: ${SUNW}/common/atomic/${MACHINE_ARCH} SRCS+= atomic.S From m.e.sanliturk at gmail.com Sat May 9 01:03:35 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Sat May 9 01:03:42 2009 Subject: Installation of FreeBSD 8.0-Current-2009-amd64-dvd Message-ID: Dear All , A few days ago I have downloaded and installed 8.-Current-2009-05-amd64-dvd on an Intel DG965WHMKR main board with 2 GB RAM and 250 GB SATA II hard disk , PS/2 mouse and key board . Installation has been completed successfully and the PC booted well . (1) I tried to use X but X was completely missing . (2) Trying to add X with pkg_add did not worked because it could not find it in FreeBSD repositories . (3) I did not understand what can I do with that release sufficiently well , because I could not find a ReadMe about What to Do with this snapshot ( Perhaps there is one within installed OS but there is no any reminder about it with respect to my knowledge ( I could not check it now because I have installed another OS on its hard disk . ) . My ideas are following : (i) A ReadMe file set like supplied by releases would be very useful . Assume that these will be drafts of the release 8.0 . People will be able to work and make comments on them . A ReadMe about how to use and test the snapshot and supply feedback about its usage ( I think general bug reports are not very suitable for current development activities ) . (ii) Up to now I did not see any test program which can be applied by the installers and then send results back to FreeBSD release and current developers . Such a program would test an overall structure of the installed components and would sent a report to FreeBSD current developers . (iii) Some Linux distributions are collecting computer profile data for successful installations , for example , Fedora is collecting profile information and summaries are published in www.smolts.org . FreeBSD installations may include a similarly profile collection step . I do not know the relationship between www.bsdstats.org and www.freebsd.org, but a detailed hardware profile list such as the following sample pages would be very useful : http://hcl.mandriva.com/ http://en.opensuse.org/Hardware http://wiki.freespire.org/index.php/Hardware_Compatibility_List http://www.ubuntuhcl.org/ http://www.turbolinux.com/products/compatibility/index.html https://hardware.redhat.com/ http://www.smolts.org/ http://www.armorlogic.com/openbsd_information_server_compatibility_list.html http://www.sun.com/bigadmin/hcl/ How to Certify hardware : http://www.sun.com/bigadmin/hcl/hcts/ Submit Hardware to the Solaris HCL : http://www.sun.com/bigadmin/hcl/submittal/submit.jsp http://www.microsoft.com/whdc/hcl/default.mspx Some others : http://www.networkupstools.org/compat/stable.html ( UPS ) http://hcl.xensource.com/ ( Xen Server ) http://wiki.xensource.com/xenwiki/HardwareCompatibilityList (iv) A structured form in a page in FreeBSD web site to collect information about failed installations and their hardware profiles ( because failed installation can not send any profile mail ) . (v) Handbook is only showing last active releases , the others are replaced by latest release related handbook . For users it is no more possible to access removed handbooks . It is possible to use a structure like following : ... Handbook 6.4 ... Handbook 7.0 Handbook 7.1 Handbook 7.2 ... Handbook 8.0 During current development phase it is possible also to get proposals about current Handbook and it may be possible to synchronize it with current OS . In that way , it becomes possible to ( NOT to revise release Handbook for the active releases ) . Each Handbook develops in its own course . Previous Handbooks will not be lost due to new releases . Current Handbook will be initialized by copying a previous Handbook and then will be modified with respect to developed current . Thank you very much . Mehmet Erol Sanliturk From kientzle at freebsd.org Sat May 9 02:28:24 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sat May 9 02:28:30 2009 Subject: Installation of FreeBSD 8.0-Current-2009-amd64-dvd In-Reply-To: References: Message-ID: <4A04EA46.20106@freebsd.org> Mehmet Erol Sanliturk wrote: > > A few days ago I have downloaded and installed 8.-Current-2009-05-amd64-dvd > on ... > > (1) I tried to use X but X was completely missing . > (2) Trying to add X with pkg_add did not worked... > (3) I did not understand what can I do with that release... FreeBSD-CURRENT is for people who are helping to develop FreeBSD itself. In order to use -CURRENT, you need to be able to build software without using packages. Because -CURRENT is in development, pre-built packages are not available (they would break very quickly as the system changes). Remember that X is just another set of packages. You can build and install X from ports: $ cd /usr/ports/x11-servers/xorg-server $ make $ make install Is there a particular reason you wanted to run FreeBSD-CURRENT? It sounds like you might be happier using the latest -STABLE release, which is FreeBSD 7.2. Cheers, Tim Kientzle From tinderbox at freebsd.org Sat May 9 03:36:08 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat May 9 03:36:16 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <20090509033605.23A347302F@freebsd-current.sentex.ca> TB --- 2009-05-09 03:07:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-09 03:07:29 - starting HEAD tinderbox run for i386/i386 TB --- 2009-05-09 03:07:29 - cleaning the object tree TB --- 2009-05-09 03:08:05 - cvsupping the source tree TB --- 2009-05-09 03:08:05 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-05-09 03:08:19 - building world TB --- 2009-05-09 03:08:19 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-09 03:08:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-09 03:08:19 - TARGET=i386 TB --- 2009-05-09 03:08:19 - TARGET_ARCH=i386 TB --- 2009-05-09 03:08:19 - TZ=UTC TB --- 2009-05-09 03:08:19 - __MAKE_CONF=/dev/null TB --- 2009-05-09 03:08:19 - cd /src TB --- 2009-05-09 03:08:19 - /usr/bin/make -B buildworld >>> World build started on Sat May 9 03:08:21 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] rm -f .depend mkdep -f .depend -a -DNATIVE_BUILD -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head -DNEED_SOLARIS_BOOLEAN /src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_alloc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_dprintf.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_ident.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_list.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuut il/common/uu_misc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_open.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_pname.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_strtoint.c ===> cddl/lib/libzfs (depend) rm -f .depend mkdep -f .depend -a -DZFS_NO_ACL -I/src/cddl/lib/libzfs/../../../sbin/mount -I/src/cddl/lib/libzfs/../../../cddl/lib/libumem -I/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libnvpair -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common -DNEED_SO LARIS_BOOLEAN /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/deviceid.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/fsshare.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mkdirp.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mnttab.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zmount.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zone.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_deleg.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_namecheck.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zpool_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zprop_common.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/ libzfs/common/libzfs_util.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_graph.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_mount.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_changelist.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_config.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c echo libzfs.so.1: /obj/src/tmp/usr/lib/libutil.a >> .depend ===> cddl/lib/libzpool (depend) make: don't know how to make atomic.S. Stop *** Error code 2 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-09 03:36:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-09 03:36:04 - ERROR: failed to build world TB --- 2009-05-09 03:36:04 - 1316.71 user 145.48 system 1715.12 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From m.e.sanliturk at gmail.com Sat May 9 03:39:59 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Sat May 9 03:40:06 2009 Subject: Installation of FreeBSD 8.0-Current-2009-amd64-dvd In-Reply-To: <4A04EA46.20106@freebsd.org> References: <4A04EA46.20106@freebsd.org> Message-ID: On Fri, May 8, 2009 at 10:28 PM, Tim Kientzle wrote: > Mehmet Erol Sanliturk wrote: > >> >> A few days ago I have downloaded and installed >> 8.-Current-2009-05-amd64-dvd >> on ... >> >> (1) I tried to use X but X was completely missing . >> (2) Trying to add X with pkg_add did not worked... >> (3) I did not understand what can I do with that release... >> > > FreeBSD-CURRENT is for people who are helping to develop > FreeBSD itself. In order to use -CURRENT, you > need to be able to build software without using > packages. Because -CURRENT is in development, > pre-built packages are not available (they would break > very quickly as the system changes). Remember > that X is just another set of packages. > > You can build and install X from ports: > $ cd /usr/ports/x11-servers/xorg-server > $ make > $ make install > > Is there a particular reason you wanted to run > FreeBSD-CURRENT? It sounds like you might be > happier using the latest -STABLE release, which > is FreeBSD 7.2. > > Cheers, > > Tim Kientzle > > Dear Tim , I know that current snapshots should not be used in any production purposes . My intention was only to install it , run some programs , and if I get a feeling that supplying an information to current developers may be useful to send an e-mail about my experiences . I think such installation and test results would be useful to current developers if I am not wrongly assumed that . Thank you very much . Mehmet eErol Sanliturk From tinderbox at freebsd.org Sat May 9 04:04:50 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat May 9 04:04:56 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090509040446.3E86F7302F@freebsd-current.sentex.ca> TB --- 2009-05-09 03:36:05 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-09 03:36:05 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-09 03:36:05 - cleaning the object tree TB --- 2009-05-09 03:36:35 - cvsupping the source tree TB --- 2009-05-09 03:36:35 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-09 03:36:44 - building world TB --- 2009-05-09 03:36:44 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-09 03:36:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-09 03:36:44 - TARGET=pc98 TB --- 2009-05-09 03:36:44 - TARGET_ARCH=i386 TB --- 2009-05-09 03:36:44 - TZ=UTC TB --- 2009-05-09 03:36:44 - __MAKE_CONF=/dev/null TB --- 2009-05-09 03:36:44 - cd /src TB --- 2009-05-09 03:36:44 - /usr/bin/make -B buildworld >>> World build started on Sat May 9 03:36:46 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] rm -f .depend mkdep -f .depend -a -DNATIVE_BUILD -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head -DNEED_SOLARIS_BOOLEAN /src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_alloc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_dprintf.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_ident.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_list.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuut il/common/uu_misc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_open.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_pname.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_strtoint.c ===> cddl/lib/libzfs (depend) rm -f .depend mkdep -f .depend -a -DZFS_NO_ACL -I/src/cddl/lib/libzfs/../../../sbin/mount -I/src/cddl/lib/libzfs/../../../cddl/lib/libumem -I/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libnvpair -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common -DNEED_SO LARIS_BOOLEAN /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/deviceid.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/fsshare.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mkdirp.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mnttab.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zmount.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zone.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_deleg.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_namecheck.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zpool_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zprop_common.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/ libzfs/common/libzfs_util.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_graph.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_mount.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_changelist.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_config.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c echo libzfs.so.1: /obj/pc98/src/tmp/usr/lib/libutil.a >> .depend ===> cddl/lib/libzpool (depend) make: don't know how to make atomic.S. Stop *** Error code 2 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-09 04:04:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-09 04:04:46 - ERROR: failed to build world TB --- 2009-05-09 04:04:46 - 1315.56 user 150.86 system 1720.84 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From tinderbox at freebsd.org Sat May 9 04:36:52 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat May 9 04:37:05 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090509043649.37BE07302F@freebsd-current.sentex.ca> TB --- 2009-05-09 04:04:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-09 04:04:46 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-05-09 04:04:46 - cleaning the object tree TB --- 2009-05-09 04:05:23 - cvsupping the source tree TB --- 2009-05-09 04:05:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-05-09 04:05:33 - building world TB --- 2009-05-09 04:05:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-09 04:05:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-09 04:05:33 - TARGET=ia64 TB --- 2009-05-09 04:05:33 - TARGET_ARCH=ia64 TB --- 2009-05-09 04:05:33 - TZ=UTC TB --- 2009-05-09 04:05:33 - __MAKE_CONF=/dev/null TB --- 2009-05-09 04:05:33 - cd /src TB --- 2009-05-09 04:05:33 - /usr/bin/make -B buildworld >>> World build started on Sat May 9 04:05:36 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] rm -f .depend mkdep -f .depend -a -DNATIVE_BUILD -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head -DNEED_SOLARIS_BOOLEAN /src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_alloc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_avl.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_dprintf.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_ident.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_list.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuut il/common/uu_misc.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_open.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_pname.c /src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_strtoint.c ===> cddl/lib/libzfs (depend) rm -f .depend mkdep -f .depend -a -DZFS_NO_ACL -I/src/cddl/lib/libzfs/../../../sbin/mount -I/src/cddl/lib/libzfs/../../../cddl/lib/libumem -I/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libnvpair -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common -DNEED_SO LARIS_BOOLEAN /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/deviceid.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/fsshare.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mkdirp.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/mnttab.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zmount.c /src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/misc/zone.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_deleg.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_namecheck.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zpool_prop.c /src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zprop_common.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/ libzfs/common/libzfs_util.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_graph.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_mount.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_changelist.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_config.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c /src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c echo libzfs.so.1: /obj/ia64/src/tmp/usr/lib/libutil.a >> .depend ===> cddl/lib/libzpool (depend) make: don't know how to make atomic.S. Stop *** Error code 2 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-09 04:36:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-09 04:36:49 - ERROR: failed to build world TB --- 2009-05-09 04:36:49 - 1513.34 user 147.44 system 1922.70 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From tinderbox at freebsd.org Sat May 9 07:09:45 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat May 9 07:09:57 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090509070941.13C967302F@freebsd-current.sentex.ca> TB --- 2009-05-09 05:43:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-09 05:43:11 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-05-09 05:43:12 - cleaning the object tree TB --- 2009-05-09 05:43:49 - cvsupping the source tree TB --- 2009-05-09 05:43:49 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-05-09 05:43:59 - building world TB --- 2009-05-09 05:43:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-09 05:43:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-09 05:43:59 - TARGET=sparc64 TB --- 2009-05-09 05:43:59 - TARGET_ARCH=sparc64 TB --- 2009-05-09 05:43:59 - TZ=UTC TB --- 2009-05-09 05:43:59 - __MAKE_CONF=/dev/null TB --- 2009-05-09 05:43:59 - cd /src TB --- 2009-05-09 05:43:59 - /usr/bin/make -B buildworld >>> World build started on Sat May 9 05:44:03 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 9 07:05:13 UTC 2009 TB --- 2009-05-09 07:05:13 - generating LINT kernel config TB --- 2009-05-09 07:05:13 - cd /src/sys/sparc64/conf TB --- 2009-05-09 07:05:13 - /usr/bin/make -B LINT TB --- 2009-05-09 07:05:13 - building LINT kernel TB --- 2009-05-09 07:05:13 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-09 07:05:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-09 07:05:13 - TARGET=sparc64 TB --- 2009-05-09 07:05:13 - TARGET_ARCH=sparc64 TB --- 2009-05-09 07:05:13 - TZ=UTC TB --- 2009-05-09 07:05:13 - __MAKE_CONF=/dev/null TB --- 2009-05-09 07:05:13 - cd /src TB --- 2009-05-09 07:05:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 9 07:05:14 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/sparc64/src/sys/LINT /src/sys/modules/nullfs/../../fs/nullfs/null_subr.c /src/sys/modules/nullfs/../../fs/nullfs/null_vfsops.c /src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c ===> opensolaris (depend) @ -> /src/sys machine -> /src/sys/sparc64/include make: don't know how to make atomic.S. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-09 07:09:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-09 07:09:40 - ERROR: failed to build lint kernel TB --- 2009-05-09 07:09:40 - 3921.31 user 392.82 system 5188.72 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From mav at FreeBSD.org Sat May 9 14:55:49 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sat May 9 14:56:21 2009 Subject: [Fwd: Re: amd64 suspend/resume broken on current] Message-ID: <4A058B5C.3010707@FreeBSD.org> -------- Original Message -------- Subject: Re: amd64 suspend/resume broken on current Date: Fri, 8 May 2009 21:52:45 +0200 From: Guy Brand Organization: Direction Informatique, Universit? de Strasbourg, France To: Alexander Motin References: <4A021118.2030106@mavhome.dp.ua> <20090508111024.GK4922@unistra.fr> <4A041DC2.90106@mavhome.dp.ua> <20090508144551.GA1599@unistra.fr> <4A047925.6060301@mavhome.dp.ua> Guy Brand wrote: > Alexander Motin wrote: > > Done. No firewire issue of course, but a kernel panic on resume. Bad > > karma since yesterday :-) > > Where is this panic happens now? Just after resuming: Fatal trap 12: page fault while in kernel mode ... current process = 1415 (acpiconf) The backtrace says: intr_execute_handlers() at intr_execute_handlers+0x21 lapic_handle_intr() at lapic_handle_intr+0x37 Xapic_isr1() at Xapic_isr1+0xa4 acpi_sleep_machdep() at acpi_sleep_machdep+0x3b2 acpi_EnterSleepState() at acpi_EnterSleepState+0x3fe acpi_AckSleepState() at acpi_AckSleepState+0x163 devfs_ioctl() at devfs_ioctl_f+0x77 kern_ioctl() at kern_ioctl+0xb0 ioctl() at ioctl+0xfd syscall() at syscal+0x246 Xfast_syscall() at Xfast_syscall+0xd0 -- bug -- Alexander Motin From ler at lerctr.org Sat May 9 15:33:54 2009 From: ler at lerctr.org (Larry Rosenman) Date: Sat May 9 15:34:01 2009 Subject: sysctl -a crash on todays current Message-ID: I hit the following page-fault panic on todays -CURRENT, when running sysctl -a: I have the core and kernel. Script started on Sat May 9 10:20:26 2009 # kgdb /boot/kernel/kernel.symbols vmcore.4 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 conditions. 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: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803b9996 stack pointer = 0x28:0xfffffffeb9f228d0 frame pointer = 0x28:0xfffffffeb9f228e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1712 (sysctl) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x2ad trap_pfault() at trap_pfault+0x294 trap() at trap+0x29a calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff803b9996, rsp = 0xfffffffeb9f228d0, rbp = 0xfffffffeb9f228e0 --- strlcpy() at strlcpy+0x16 sysctl_kern_malloc_stats() at sysctl_kern_malloc_stats+0x20e sysctl_root() at sysctl_root+0xfd userland_sysctl() at userland_sysctl+0x14f __sysctl() at __sysctl+0xaa syscall() at syscall+0x246 Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x80073024c, rsp = 0x7fffffffd878, rbp = 0x2 --- Uptime: 1h7m20s Physical memory: 4084 MB Dumping 535 MB: 520 504 488 472 456 440 424 408 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. done. Loaded symbols for /boot/kernel/cpuctl.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/modules/cpu.ko...done. Loaded symbols for /boot/modules/cpu.ko #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff8031f599 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xffffffff8031f9ec in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xffffffff8057c4cd in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:845 #4 0xffffffff8057c8b4 in trap_pfault (frame=0xfffffffeb9f22820, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:761 #5 0xffffffff8057d1ca in trap (frame=0xfffffffeb9f22820) at /usr/src/sys/amd64/amd64/trap.c:487 #6 0xffffffff80557e13 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #7 0xffffffff803b9996 in strlcpy (dst=0xfffffffeb9f22930 "", src=0x0, siz=Variable "siz" is not available. ) at /usr/src/sys/libkern/strlcpy.c:54 #8 0xffffffff8030e1ee in sysctl_kern_malloc_stats (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_malloc.c:808 #9 0xffffffff80328c4d in sysctl_root (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1514 #10 0xffffffff80328e9f in userland_sysctl (td=0x0, name=0xfffffffeb9f22ab0, namelen=2, old=0x0, oldlenp=0x7fffffffd920, inkernel=0, new=0x0, newlen=0, retval=0xfffffffeb9f22b18, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1613 #11 0xffffffff8032906a in __sysctl (td=0xffffff004861cab0, uap=0xfffffffeb9f22c00) at /usr/src/sys/kern/kern_sysctl.c:1544 #12 0xffffffff8057cb26 in syscall (frame=0xfffffffeb9f22c90) at /usr/src/sys/amd64/amd64/trap.c:977 #13 0xffffffff805580a0 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #14 0x000000080073024c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) # ^D Script done on Sat May 9 10:21:03 2009 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From mel.flynn+fbsd.current at mailing.thruhere.net Sat May 9 17:12:20 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Sat May 9 17:12:27 2009 Subject: sysctl -a crash on todays current In-Reply-To: References: Message-ID: <200905091912.17911.mel.flynn+fbsd.current@mailing.thruhere.net> On Saturday 09 May 2009 17:23:25 Larry Rosenman wrote: > I hit the following page-fault panic on todays -CURRENT, when running > sysctl -a: I have the core and kernel. > Reading symbols from /boot/modules/cpu.ko...done. > Loaded symbols for /boot/modules/cpu.ko Recompile that module and search archive for the why. -- Mel From ler at lerctr.org Sat May 9 17:21:16 2009 From: ler at lerctr.org (Larry Rosenman) Date: Sat May 9 17:21:32 2009 Subject: sysctl -a crash on todays current In-Reply-To: <200905091912.17911.mel.flynn+fbsd.current@mailing.thruhere.net> References: <200905091912.17911.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: On Sat, 9 May 2009, Mel Flynn wrote: > On Saturday 09 May 2009 17:23:25 Larry Rosenman wrote: >> I hit the following page-fault panic on todays -CURRENT, when running >> sysctl -a: I have the core and kernel. > > > >> Reading symbols from /boot/modules/cpu.ko...done. >> Loaded symbols for /boot/modules/cpu.ko > > Recompile that module and search archive for the why. Thanks. It actually doesn't compile at the moment due to kernel tree changes. (Maintainer CC'd). I've removed that KLD from the system and we're fine. # cd /usr/ports/sysutils/devcpu # make ===> Found saved configuration for devcpu-0.8.1 ===> Extracting for devcpu-0.8.3 => MD5 Checksum OK for devcpu-0.8.3.tar.bz2. => SHA256 Checksum OK for devcpu-0.8.3.tar.bz2. ===> Patching for devcpu-0.8.3 /usr/bin/sed -i.bak -e "s,%%PREFIX%%,/usr/local,g" /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu_microcode_tool/cpu_microcode_tool.8 ===> Configuring for devcpu-0.8.3 ===> Building for devcpu-0.8.3 ===> cpu (all) Warning: Object directory not changed from original /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -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 -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c cpu.c cpu.c: In function 'cpu_ioctl': cpu.c:158: error: invalid operands to binary & cpu.c: In function 'cpu_open': cpu.c:427: error: invalid operands to binary & *** Error code 1 Stop in /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu. *** Error code 1 Stop in /usr/ports/sysutils/devcpu/work/devcpu-0.8.3. *** Error code 1 Stop in /usr/ports/sysutils/devcpu. *** Error code 1 Stop in /usr/ports/sysutils/devcpu. # > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From stas at FreeBSD.org Sat May 9 19:04:03 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Sat May 9 19:04:11 2009 Subject: sysctl -a crash on todays current In-Reply-To: References: <200905091912.17911.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <20090509230325.278241e0.stas@FreeBSD.org> On Sat, 9 May 2009 12:21:00 -0500 (CDT) Larry Rosenman mentioned: > On Sat, 9 May 2009, Mel Flynn wrote: > > > On Saturday 09 May 2009 17:23:25 Larry Rosenman wrote: > >> I hit the following page-fault panic on todays -CURRENT, when running > >> sysctl -a: I have the core and kernel. > > > > > > > >> Reading symbols from /boot/modules/cpu.ko...done. > >> Loaded symbols for /boot/modules/cpu.ko > > > > Recompile that module and search archive for the why. > Thanks. It actually doesn't compile at the moment due to kernel tree changes. > (Maintainer CC'd). > > I've removed that KLD from the system and we're fine. > > # cd /usr/ports/sysutils/devcpu > # make > ===> Found saved configuration for devcpu-0.8.1 > ===> Extracting for devcpu-0.8.3 > => MD5 Checksum OK for devcpu-0.8.3.tar.bz2. > => SHA256 Checksum OK for devcpu-0.8.3.tar.bz2. > ===> Patching for devcpu-0.8.3 > /usr/bin/sed -i.bak -e "s,%%PREFIX%%,/usr/local,g" /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu_microcode_tool/cpu_microcode_tool.8 > ===> Configuring for devcpu-0.8.3 > ===> Building for devcpu-0.8.3 > ===> cpu (all) > Warning: Object directory not changed from original /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu > @ -> /usr/src/sys > machine -> /usr/src/sys/amd64/include > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -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 -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c cpu.c > cpu.c: In function 'cpu_ioctl': > cpu.c:158: error: invalid operands to binary & > cpu.c: In function 'cpu_open': > cpu.c:427: error: invalid operands to binary & > *** Error code 1 > > Stop in /usr/ports/sysutils/devcpu/work/devcpu-0.8.3/cpu. > *** Error code 1 > > Stop in /usr/ports/sysutils/devcpu/work/devcpu-0.8.3. > *** Error code 1 > > Stop in /usr/ports/sysutils/devcpu. > *** Error code 1 > > Stop in /usr/ports/sysutils/devcpu. > # > You should not use devcpu port on CURRENT. This code is already included both into STABLE and HEAD branches (sys/modules/cpuctl). -- Stanislav Sedov ST4096-RIPE !DSPAM:4a05d398994291470650666! From brd at FreeBSD.org Sat May 9 19:13:25 2009 From: brd at FreeBSD.org (Brad Davis) Date: Sat May 9 19:13:33 2009 Subject: FreeBSD Status Reports January - March, 2009 Message-ID: <20090509191253.GD40521@valentine.liquidneon.com> FreeBSD Quarterly Status Report Introduction Since the last Status Reports there has been interesting progress in FreeBSD Development. FreeBSD 7.2 was released just a few days ago. Some of the highlights include: Support for superpages in the FreeBSD Virtual Memory subsystem. The FreeBSD Kernel Virtual Address space has been increased to 6GB on amd64. An updated jail(8) subsystem that supports multi-IPv4/IPv6/noIP and much more. Lots of FreeBSD Developers are in Ottawa, Canada attending the FreeBSD Developer Summit that is before BSDCan. BSDCan officially starts tomorrow and should cover lots of interesting topics, see the BSDCan Website for more information. Thanks to all the reporters for the excellent work! We hope you enjoy reading. __________________________________________________________________ Projects * Clang replacing GCC in the base system * Device mmap() Extensions * OpenBSM * Release Engineering * Sysinfo - a set of scripts which document your system * TrustedBSD MAC Framework in GENERIC * VFS/NFS DTrace Probes * VirtualBox on FreeBSD FreeBSD Team Reports * FreeBSD BugBusting Team Architectures * FreeBSD/powerpc G5 Support * FreeBSD/sparc64 UltraSPARC III support Documentation * Dutch Documentation Project * German Documentation Project * Hungarian Documentation Project Google Summer of Code * BSD-licensed text-processing tools __________________________________________________________________ BSD-licensed text-processing tools URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/ soc2008/gabor_textproc Contact: G?bor K?vesd?n Currently, grep is finished and is only waiting for a portbuild test. It is known to be more or less feature complete, while it is much smaller than the GNU version. As for sort, there has been some progress with the complete rewrite and it is lacking few options. Performance is to be measured, as well. Open tasks: 1. Test grep on pointyhat. 2. Complete sort with the missing features. 3. Do performance measurements for sort and look for possible optimization opportunities. 4. Test sort on pointyhat. __________________________________________________________________ Clang replacing GCC in the base system URL: http://wiki.freebsd.org/BuildingFreeBSDWithClang URL: http://git.hoeg.nl/?p=llvm-bmake URL: http://clang.llvm.org/ Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach The last 3-4 months we've been working together with the LLVM developers to discuss any bugs and issues we are experiencing with their Clang compiler frontend. The FreeBSD project is looking at the possibility to replace GCC with Clang as a system compiler. It can compile 99% of the FreeBSD world and can compile booting kernel on i386/amd64 but it still contains bugs and its C++ support is still immature. Ed is maintaining a patchset for the FreeBSD sources to replace cc(1) by a Clang binary and bootstrap almost all sources with the Clang compiler. The LLVM developers are very helpful fixing most of the bugs we've reported (over 100). Unfortunately we are currently blocked on some bug reports that prevent us from building libc, libm, libcrypto and various CDDL libraries with Clang but the FreeBSD kernel itself compiles and boots. Open tasks: 1. Testing Clang with compilation of various applications and reporting bugs. 2. Testing the llvm-bmake branch to find more bugs. 3. Arranging an experimental ports build. __________________________________________________________________ Device mmap() Extensions URL: http://www.FreeBSD.org/~jhb/pat/ Contact: John Baldwin GPU device drivers are increasingly requiring more sophisticated support for mapping objects into both userland and the kernel. For example, memory used for textures often needs to be mapped Write-Combining rather than Write-Back. I have recently created three patches to provide several extensions. The first patch allows device drivers to use a different VM object to back specific mmap() calls instead of always using the device pager. The second patch introduces a new VM object type that can map an arbitrary set of physical address ranges. This can be used to let userland mmap PCI BARs, etc. The third patch allows memory mappings to use different caching modes (e.g. Write-Combining or Uncacheable). Together I believe these patches provide the remaining pieces needed for an Nvidia amd64 driver. They will also be useful for future Xorg DRM support as well. The current set of patches can be safely merged back to 7.x as well. Currently I am waiting for review and feedback from several folks. I am hopeful that these patches will be in HEAD soon, prior to the 8.0 freeze. __________________________________________________________________ Dutch Documentation Project URL: http://wiki.freebsd.org/DutchDocumentationProject URL: http://www.freebsd.org/doc/nl/ URL: http://p4web.freebsd.org/@md=d&cd=//&c=pFl@//depot/projects/docproj_nl/ ?ac=83 Contact: Remko Lodder Contact: Ren? Ladan The FreeBSD Dutch Documentation Project is an ongoing project to translate FreeBSD Documentation into the Dutch language. The translation of the Handbook was completed last January. It is kept up-to-date with the English version. Furthermore five articles and the flyer have been translated. Some initial work has been done to translate the website, but most likely more translators are needed to fully realize it. Open tasks: 1. Recruit more translators. 2. Keep the translations up-to-date with the English versions. 3. Finish the translation of the FAQ. 4. Translate more articles and maybe some books. __________________________________________________________________ FreeBSD BugBusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.freebsd.org/~linimon/studies/prs/recommended_prs.html Contact: Mark Linimon Contact: Remko Lodder We continue to classify PRs as they arrive, with 'tags' corresponding to the kernel subsystem, or man page references for userland PRs. These tags, in turn, produce lists of PRs sorted both by tag and by manpage Mark Linimon (linimon@) has created special reports for the Release Engineering Team to help focus on regressions and other areas of interest relating to the release of FreeBSD 7.2 in the coming weeks. This is a refinement of the 'customized reports for developers' announced in the last status report. A full list of all the automatically generated reports is also available. Any recommendations for reports which do not currently exist but which would be beneficial are welcomed. Mark Linimon also continues attempting to define the general problem and investigating possible new work flow models, and will be presenting on the subject at BSDCan. The list of PRs recommended for committer evaluation by the BugBusting team continues to receive new additions. This list contains PRs, mostly with patches, that the BugBusting team feel are probably ready to be committed as-is, or are probably trivially resolved in the hands of a committer with knowledge of the particular subsystem. All committers are invited to take a look at this list whenever they have a spare 5 minutes and wish to close a PR. Since the last status report, the number of open bugs continued to hover around the 5600 mark, although has began to rise with the 7.2 ports freeze. As always, more help is appreciated, and committers and non-committers alike are invited to join us on #freebsd-bugbusters on EFnet and help close stale PRs or commit patches from valid PRs. Open tasks: 1. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. 2. Think of some way for committers to only view PRs that have been in some way 'vetted' or 'confirmed'. 3. Generate more publicity for what we've already got in place, and for what we intend to do next. 4. Define new categories, classifications, and states for PRs, that will better match our work flow (in progress). __________________________________________________________________ FreeBSD/powerpc G5 Support Contact: Nathan Whitehorn FreeBSD 8.0-CURRENT now has support for PowerPC CPUs operating in the 64-bit bridge mode. This includes the PowerPC 970 (G5) as well as the POWER3 and POWER4. Currently only Apple systems are known to work. Open tasks: 1. IBM systems currently are not supported due to missing northbridge support. 2. Software fan control on SMU-based Apple G5 systems (G5 iMac, later Powermac G5) is not available. __________________________________________________________________ FreeBSD/sparc64 UltraSPARC III support Contact: Marius Strobl Like announced in the previous status report, support for sun4u-machines based on UltraSPARC III and beyond has been MFC'ed to stable/7 (the last missing piece was r190297) and thus will be present in the upcoming 7.2-RELEASE and can be already tested with 7.2-RC1. Additionally, as of r191076 machfb(4) has been fixed to work with UltraSPARC III and beyond, that fix unfortunately did not make it into 7.2-RC1 but will be in the final version. The X.Org 7.4 and Firefox ports as well as some other gecko-based ones like Seamonkey once again have been fixed to also work and package on sparc64, including on UltraSPARC III and UltraSPARC IIIi based machines equipped with cards driven by creator(4) or machfb(4). The driver for the Sun Cassini/Cassini+ as well as National Semiconductor DP83065 Saturn Gigabit NICs found on-board for example in Fire V440 and as add-on cards is coming along nicely, the last thing which needs to be implemented before it can hit CURRENT is support for jumbo frames. __________________________________________________________________ German Documentation Project URL: https://doc.bsdgroup.de Contact: Johann Kois Contact: Martin Wilke In February 2009 the German version of the FreeBSD Developer's handbook went online. Additionally we managed to update large areas of the FAQ thanks to the contributions of Benedict Reuschling. The website (at least the areas we see as relevant for a translation) is translated and updated constantly. More volunteers are always welcome of course, as there is still plenty of work to be done. Open tasks: 1. Update the existing documentation set (especially the handbook). 2. Read the translations. Check for problems/mistakes. Send feedback. __________________________________________________________________ Hungarian Documentation Project URL: http://www.FreeBSD.org/hu URL: http://www.FreeBSD.org/doc/hu URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: G?bor K?vesd?n Contact: G?bor P?li We are proud to announce that the FreeBSD Hungarian web pages have been extended by the following items: * Project news entries, staring from 2009 (HTML, RSS, RDF) * Press releases, starting from 2008 (HTML, RSS) * Events, starting from 2009 (HTML, RSS) * Security advisories (HTML, RSS) We are still hoping that having the FDP Primer translated will encourage others to help our work. Feel free to contribute, every submitted line of translation or feedback is appreciated and is highly welcome. For more information on how to contribute, please read the project's introduction (in Hungarian). Open tasks: 1. Translate news entries, press releases. 2. Translate Release Notes for -CURRENT and 8.X. 3. Translate articles. 4. Translate web pages. 5. Read the translations, send feedback. __________________________________________________________________ OpenBSM URL: http://www.openbsm.org/ Contact: Robert Watson Contact: TrustedBSD audit mailing list The TrustedBSD Project has now released OpenBSM 1.1, the second production release of the OpenBSM code base. OpenBSM 1.1 has been merged to FreeBSD 8-CURRENT, and will be merged to 7-STABLE before FreeBSD 7.3. Major changes since OpenBSM 1.0 include: * Trail files now include the host where the trail is generated. Crash recovery has been improved. Trail expiration based on size and date is now supported; by default trail files will be expired after 10MB of trails. The default individual trail limit is now 2MB. * Mac OS X Snow Leopard is now a fully supported platform; launchd(8) can now be used to launchd auditd(8). Command line tools and libraries are now supported on Mac OS X Leopard. * Extended header tokens are now supported, allowing audit trails to be tagged with a host identifier. IPv6 addresses are now supported in subject tokens. BSM token and record types have been further synchronized to OpenSolaris; support for many new system calls has been added. Local errors and socket types are mapped to and from BSM values. Since the last test release, OpenBSM 1.1 beta 1, 32/64-bit compatibility has been fixed for the auditon(2) system call. A default "expire-after" of 10MB is now set in audit_control(5). Local fcntl(2) arguments are now mapped to wire BSM versions using new APIs. The audit_submit(3) man page has been fixed. A new audit event class has been added for post-login authentication and access control events. Open tasks: 1. Migrate to sbufs in token-encoding. 2. Support for auditing NFS RPCs. __________________________________________________________________ Release Engineering URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team (with lots of help from lots of other people) released FreeBSD 7.2 on May 4th, 2009. During this period we have also begun reminding developers of the upcoming FreeBSD 8.0 release cycle which is scheduled to begin in early June 2009 with release targeted at early September 2009. __________________________________________________________________ Sysinfo - a set of scripts which document your system URL: http://danger.rulez.sk/index.php/2009/04/14/sysinfo-a-set-of-scripts-wh ich-document-your-freebsd-system/ URL: https://forums.freebsd.org/showthread.php?p=19321 Contact: Daniel Gerzo Sysinfo a shell script which purpose is to automatically gather system information and document hardware and software configuration of the given host system. The goal is to provide a system operator with descriptive information about an unknown FreeBSD installation. It consists of several modules (also shell scripts), thus is easily extensible and provides an easy way to inspect overall system configuration. It has been written as part of my Bachelor thesis and its development is a work in progress. Therefore, I would appreciate if you could provide me with some feedback as I will defend my thesis soon. Your feedback is welcome at the forums , or alternatively you can send me a private email. The tool itself can now be installed using the Ports tree from the sysutils/sysinfo port. Open tasks: 1. Receive additional feedback. 2. Perform more testing. 3. Extend and improve the tool. __________________________________________________________________ TrustedBSD MAC Framework in GENERIC URL: http://www.trustedBSD.org/mac.html Contact: Robert Watson Contact: TrustedBSD discussion mailing list There is on-going work to allow "options MAC" to be included in the GENERIC kernel for 8.0. This primarily consists of performance work to reduce overhead when policies are used, and eliminate when none are configured. Work to date includes: * The MAC Framework now detects which object types are labeled by policies, and MAC label storage is not allocated when it won't be used. * Add MAC Framework DTrace probes so allow more easy analysis of MAC Framework and policy interactions. * Eliminate mutex-protected reference count used to prevent module unload during entry point invocation, and replace with an sx lock and an rwlock, respectively for long-sleepable and short-sleepable entry points, significantly lowering the overhead of entering the MAC Framework. If no dynamic policies are loaded, no locking overhead is taken. Open tasks: 1. Move to rmlocks for non-sleepable entry points to reduce cache line thrashing under load. 2. Macroize invocation of MAC Framework entry points from the kernel, and perform caller-side determination of whether MAC is enabled in order to avoid additional function call overhead in the caller path if MAC is disabled. __________________________________________________________________ VFS/NFS DTrace Probes Contact: Robert Watson A new DTrace provider, dtnfsclient, has been added to the FreeBSD 8.x kernel, and will be merged to 7.x before 7.3. The following probes are available: * nfsclient:{nfs2,nfs3}:{procname}:start - NFSv2 and NFSv3 RPC start probes * nfsclient:{nfs2,nfs3}:{procname}:done - NFSv2 and NFSv3 RPC done probes * nfsclient:accesscache:: - NFS access cache flush/hit/miss/load probes * nfsclient:attrcache:: - NFS attribute cache flush/hit/miss/done In addition, a number of VFS probes have been added: * vfs:vop:{vopname}:entry - VOP entry probe * vfs:vop:{vopname}:return - VOP return probe * vfs:namei:lookup:entry - VFS name lookup entry probe * vfs:namei:lookup:return - VFS name lookup return probe * vfs:namecache:*:* - VFS namecache enter/enter_negative/fullpath_enter/fullpath_hit/fullpath_miss/full path_return/lookup_hit/lookup_hit_negative/lookup_miss/purge/purge_ negative/purgevfs/zap/zap_negative probes These probes make it much easier to trace NFS and VFS events. Open tasks: 1. Add VFSOP tracing. 2. Add RPC-layer tracing, such as RPC retransmits. 3. Provide decoded NFS RPCs in order to expose transaction IDs and file handles. __________________________________________________________________ VirtualBox on FreeBSD URL: http://miwi.bsdcrew.de/2009/05/virtualbox-on-freebsd/ URL: http://miwi.bsdcrew.de/2009/05/virtualbox-on-freebsd-first-screenshots/ URL: http://vbox.innotek.de/pipermail/vbox-dev/2009-May/001369.html Contact: Beat Gaetzi Contact: Bernhard Froehlich Contact: Dennis Herrmann Contact: Martin Wilke After the first mail from Alexander Eichner on the vbox-dev mailinglist, we started the work on a VirtualBox port. 6 Days was needed to get VirtualBox to start with over 20 patches. We'd like to say thanks to Alexander Eichner, all the VirtualBox Developers, Gustau Perez and Ulf Lilleengen. If you like to play with the current port you can checkout the port here. Please do not ping us about any problems, we know about a lot and are still working to get them all solved before we do an official call for testing. Open tasks: 1. Fix kernel crashes on 7.2-RELEASE. 2. Code cleanup. 3. Fix errors on AMD64. 4. Fix user/permission problems. From keramida at ceid.upatras.gr Sat May 9 22:00:31 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Sat May 9 22:00:38 2009 Subject: bug in perl 5.10 on 8.0? Message-ID: <87bpq288e5.fsf@kobe.laptop> I've recently enabled kern.sugid_coredump=1 to debug a problem in a problem of my own and noticed this too: $ ls -ld /*core -rw------- 1 root wheel - 11612160 May 9 12:13 /perl5.10.0.core # gdb /usr/local/bin/perl5 /perl*core ... (gdb) bt #0 0x283136a7 in kill () at kill.S:2 #1 0x282243f7 in _raise (sig=6) at /usr/src/lib/libthr/thread/thr_sig.c:185 #2 0x2831222a in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #3 0x282f8756 in __assert (func=0xbfbfeb24 "\006", file=0x3
, line=0, failedexpr=0x2831bcb0 "(run->regs_mask[elm] & (1U << bit)) == 0") at /usr/src/lib/libc/gen/assert.c:54 #4 0x28299c4a in arena_dalloc_small (arena=0x8049c40, chunk=0x28400000, ptr=Variable "ptr" is not available. ) at /usr/src/lib/libc/stdlib/malloc.c:2543 #5 0x2829a020 in idalloc (ptr=0x284d7ec0) at /usr/src/lib/libc/stdlib/malloc.c:3871 #6 0x2829a757 in free (ptr=0x284d7ec0) at /usr/src/lib/libc/stdlib/malloc.c:5454 #7 0x2830cefb in __clean_env (freeVars=true) at /usr/src/lib/libc/stdlib/getenv.c:236 #8 0x2824dde0 in ?? () from /lib/libc.so.7 #9 0x28325800 in ?? () from /lib/libc.so.7 #10 0x280782d8 in ?? () from /libexec/ld-elf.so.1 #11 0xbfbfecf8 in ?? () #12 0x28316dcc in _fini () from /lib/libc.so.7 #13 0x28088380 in ?? () #14 0x280782d8 in ?? () from /libexec/ld-elf.so.1 #15 0xbfbfecf8 in ?? () #16 0x2804ec6f in objlist_call_fini (list=Variable "list" is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:1620 Previous frame inner to this frame (corrupt stack?) (gdb) x/100b 0x284d7ec0 0x284d7ec0: 0x44 0x42 0x55 0x53 0x5f 0x53 0x54 0x41 0x284d7ec8: 0x52 0x54 0x45 0x52 0x5f 0x42 0x55 0x53 0x284d7ed0: 0x5f 0x54 0x59 0x50 0x45 0x3d 0x73 0x79 0x284d7ed8: 0x73 0x74 0x65 0x6d 0x00 0x70 0x72 0x69 0x284d7ee0: 0xc0 0x7e 0x4d 0x28 0x80 0x70 0xe6 0x28 0x284d7ee8: 0x00 0x00 0x00 0x00 0x75 0x73 0x65 0x72 0x284d7ef0: 0x5b 0x31 0x5d 0x5c 0x6e 0x22 0x3b 0x0a 0x284d7ef8: 0x20 0x20 0x20 0x20 0x20 0x20 0x70 0x72 0x284d7f00: 0x00 0x00 0x00 0x00 0xc0 0x58 0x1d 0x28 0x284d7f08: 0x00 0x00 0x63 0x00 0x0c 0x00 0x00 0x00 0x284d7f10: 0x00 0x00 0x00 0x00 0x70 0xee 0xe6 0x28 0x284d7f18: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x284d7f20: 0x0c 0x00 0x00 0x00 Current language: auto; currently asm (gdb) x/s 0x284d7ec0 0x284d7ec0: "DBUS_STARTER_BUS_TYPE=system" Has anyone else seen something similar? Is this an already known bug in Perl or an artifact of the way __clean_env() works in 8.0-CURRENT? From jeremie at le-hen.org Sun May 10 11:28:05 2009 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Sun May 10 11:28:12 2009 Subject: Bug in mergemaster(8) when used in service jails (scheme described in chapter 15.6.1 of the handbook) Message-ID: <20090510111110.GA88857@obiwan.tataz.chchile.org> Hi Doug, In the chapter 15.6.1 of the handbook, "Service jails", the last part explains how to upgrade jails. The last step is to run mergmaster(8) in each jail. The problem is that in service jails /etc is a symlink to /s/etc, /s being the readable/writable filesystem. mtree(8) stumbles on /etc being a symlink instead of a directory and doesn't proceed futher down into /etc to check files. Consequently, ${CHANGED} is empty and all customized configuration are overwritten with their default version. I've fixed mergemaster(8) with the following patch: % Index: mergemaster.sh % =================================================================== % RCS file: /mnt/space/cvsroot/src/usr.sbin/mergemaster/mergemaster.sh,v % retrieving revision 1.69 % diff -u -r1.69 mergemaster.sh % --- mergemaster.sh 23 Mar 2009 14:42:41 -0000 1.69 % +++ mergemaster.sh 10 May 2009 11:05:32 -0000 % @@ -461,7 +461,7 @@ % # % CHANGED= % if [ -n "${AUTO_UPGRADE}" -a -f "${DESTDIR}${MTREEFILE}" ]; then % - for file in `mtree -eq -f ${DESTDIR}${MTREEFILE} -p ${DESTDIR}/ \ % + for file in `mtree -eqL -f ${DESTDIR}${MTREEFILE} -p ${DESTDIR}/ \ % 2>/dev/null | awk '($2 == "changed") {print $1}'`; do % if [ -f "${DESTDIR}/$file" ]; then % CHANGED="${CHANGED} ${DESTDIR}/$file" Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From jeremie at le-hen.org Sun May 10 16:58:30 2009 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Sun May 10 16:58:38 2009 Subject: New mergemaster option -I, failsafe install files Message-ID: <20090510165737.GB88857@obiwan.tataz.chchile.org> Hi Doug, As you may guess from my multiple emails, I'm in the process of upgrading my jails :-). Since I have one jail per service, a very few number of configuration files are modified on each jail. As most of user of FreeBSD I think, I'm used to run "mergemaster -iU" to automate the process as much as possible. The problem with service jails (chapter 15.6.1 of the handbook) is that / is read-only mounted on all jails, /etc /var /root and a few other places being symlinks to /s, the private read-write space of each jail. Thus when mergemaster tries to update /boot/devices.hints it fails and abort. Therefore I've implemented a new -I option that does the same thing as -i except that it will proceed on failure. At the end of the process, it will also show an informational message about files that could not be installed. This patch along with the fix I sent you a few hours ago allows to use mergemaster(8) in service jails flawlessly. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > -------------- next part -------------- A non-text attachment was scrubbed... Name: mergemaster-I.diff Type: text/x-diff Size: 4152 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090510/2f25c56e/mergemaster-I.bin From jlalarcon at gmx.com Sun May 10 17:11:24 2009 From: jlalarcon at gmx.com (Jose Luis Alarcon Sanchez) Date: Sun May 10 17:11:32 2009 Subject: ethernet interface ed1 Message-ID: <20090510171111.GA1516@Harvard.lordofunix.org> Hello. my computer have only one ethernet interface, only one card attached. But FreeBSD-CURRENT detect it like ed1. Why this interface, and not ed0?. All the RELEASES installed in the same computer, detected the ethernet card like ed0. Thanks in advance. Regards. Jose. -- Not Registered GNU/Hurd User. Registered BSD User 51101. Registered Linux User #213309. Memories..... You are talking about memories. Rick Deckard. Blade Runner. From saifi.khan at twincling.org Sun May 10 17:12:47 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Sun May 10 17:12:54 2009 Subject: FreeBSD 8.0 i386 200905 snapshot DVD does not boot Message-ID: Hi all: The FreeBSD 8.0 i386 200905 snapshot DVD does not boot up. I'm on a normal Celeron 1.6GHz Presario C300TU laptop with 160GB HDD and 2GB DDR2 RAM. The system just whirrs up the DVD drive, the LEDs blink for a few moments and then the installed FreeBSD 7.1 screen is presented. I tested the DVD drive by putting in the old FreeBSD 7.1 DVD and it works fine. As an additional investigation i wrote another DVD with -J -R flags (unnecessary though in my opinion) and even this DVD does not get booted up. The first thing i did was do a md5sum on the downloaded .ISO image and that is fine. Has anybody tried FreeBSD 8.0 i386 200905 DVD and could get it to boot ? Is there something that i'm missing here ? Any pointers are appreciated. thanks Saifi. From venture37 at gmail.com Sun May 10 19:54:28 2009 From: venture37 at gmail.com (Sevan / Venture37) Date: Sun May 10 19:54:34 2009 Subject: rum(4) not working on 8-CURRENT Message-ID: <4A072AF0.2000903@gmail.com> Hi I've installed a fresh copy of 8-CURRENT 05/09 AMD64 snapshot on my laptop which has a ralink pci express mini card, the device is detected by the kernel correctly & the rum driver attaches however the card doesn't work, ifconfig rum0 scan or list scan results in: ifconfig: unable to get scan results. I've only just signed up to this list but I've had a brief look through the archive for the last month or so & I see that rwatson@ posted about drivers which are flagged with IFF_NEEDSGIANT are to be removed & rum(4) is one of them, looking at repository it looks like a new rum driver was put into place 8 days ago, http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/wlan/if_rum.c Sevan / Venture37 From hselasky at c2i.net Sun May 10 20:17:32 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun May 10 20:17:39 2009 Subject: rum(4) not working on 8-CURRENT In-Reply-To: <4A072AF0.2000903@gmail.com> References: <4A072AF0.2000903@gmail.com> Message-ID: <200905102220.04364.hselasky@c2i.net> On Sunday 10 May 2009, Sevan / Venture37 wrote: > Hi > I've installed a fresh copy of 8-CURRENT 05/09 AMD64 snapshot on my > laptop which has a ralink pci express mini card, the device is detected > by the kernel correctly & the rum driver attaches however the card > doesn't work, ifconfig rum0 scan or list scan results in: > ifconfig: unable to get scan results. > I've only just signed up to this list but I've had a brief look through > the archive for the last month or so & I see that rwatson@ posted about > drivers which are flagged with IFF_NEEDSGIANT are to be removed & rum(4) > is one of them, looking at repository it looks like a new rum driver was > put into place 8 days ago, > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/wlan/if_rum.c > The USB WLAN drivers work if you use wpa_supplicant. --HPS From thompsa at FreeBSD.org Sun May 10 20:48:03 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Sun May 10 20:48:10 2009 Subject: rum(4) not working on 8-CURRENT In-Reply-To: <4A072AF0.2000903@gmail.com> References: <4A072AF0.2000903@gmail.com> Message-ID: <20090510204757.GA45375@citylink.fud.org.nz> On Sun, May 10, 2009 at 08:28:48PM +0100, Sevan / Venture37 wrote: > Hi > I've installed a fresh copy of 8-CURRENT 05/09 AMD64 snapshot on my laptop > which has a ralink pci express mini card, the device is detected by the > kernel correctly & the rum driver attaches however the card doesn't work, > ifconfig rum0 scan or list scan results in: ^^^^^^^^^^^^^^^^^^ You need to create a wlan pseudo device and operate on that # ifconfig wlan0 create wlandev rum0 up If you still have problems then enable debugging with 'wlandebug state+scan' and then down/up the interface. Andrew From jdl at jdl.com Sun May 10 22:17:57 2009 From: jdl at jdl.com (Jon Loeliger) Date: Sun May 10 22:18:05 2009 Subject: Feedback and Questions Updating to CURRENT Message-ID: Folks, I started with a 7.2-RC2 install and have been converting it to CURRENT over the past few days. I've been following the bouncing ball over in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html and I think I was (mostly) successful. One pretty darn confusing aspect of this web site page is that, in outline, basically reads: - You should follow these 8 instructions - Here's a review of the 8 steps. - Now, in detail, here are the steps. The problem is, the whole page is indexex as if the outline was really this: - Here are the 8 steps you should take step 1 ... step 8 quick review of the steps - Do some more reading - Do some /etc updates, which, incidentally is step 5 - Do 'make installworld', which, incidentally is step 6, - Remove /usr/obj, which we really didn't mention as an earlier step - Compile the Base System Wait. Again? Wasn't this done as Step 1 already? Maybe this is again, maybe this is "detailed info" now... - Compile and insall a new kernel... Wait. Again? Wasn't this done as step 2 already? Maybe this is again, maybe this is "detailed info" now... - ...rest of the same steps either "again", or "in detail"... - Youre done. Except I don't think I am. First, dmesg had this to say, and appeared not to be too pleased near the end: (I used GENERIC, minus all the RAID options to build this kernel.) ---------------------------------------------------------------- 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 #1: Sun May 10 08:52:22 CDT 2009 jdl@freebie.austin.rr.com:/usr/obj/usr/src/sys/FREEBIE WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (1109.89-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440800,MMX+,3DNow!+,3DNow!> real memory = 536870912 (512 MB) avail memory = 773992448 (738 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 2ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 256M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xd6000000-0xd6ffffff,0xd8000000-0xdfffffff irq 11 at device 0.0 on pci1 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 4.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] rl0: port 0xa400-0xa4ff mem 0xd5800000-0xd58000ff irq 9 at device 9.0 on pci0 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:e0:29:74:1c:4c rl0: [ITHREAD] pci0: at device 13.0 (no driver attached) atapci1: port 0x9800-0x9807,0x9400-0x9403,0x9000-0x9007,0x8800-0x8803,0x8400-0x843f mem 0xd5000000-0xd501ffff irq 10 at device 17.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atrtc0: port 0x70-0x73 irq 8 on acpi0 fdc1: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc1: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 cpu0: on acpi0 acpi_throttle0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0: No FDOUT register! ppc0: parallel port not found. Timecounter "TSC" frequency 1109893249 Hz quality 800 Timecounters tick every 1.000 msec ad0: 39083MB at ata0-master UDMA66 acd0: CDRW at ata1-master PIO4 acd1: CDROM at ata1-slave PIO4 WARNING: WITNESS option enabled, expect reduced performance. GEOM_LABEL: Label for provider ad0s1a is ufsid/49f8a3e1ab5cc6ca. GEOM_LABEL: Label for provider ad0s1d is ufsid/49f8a3e53ba41565. GEOM_LABEL: Label for provider ad0s1e is ufsid/49f8a3e136e4ee3d. GEOM_LABEL: Label for provider ad0s1f is ufsid/49f8a3e175f2b211. Trying to mount root from ufs:/dev/ad0s1a GEOM_LABEL: Label ufsid/49f8a3e1ab5cc6ca removed. GEOM_LABEL: Label for provider ad0s1a is ufsid/49f8a3e1ab5cc6ca. GEOM_LABEL: Label ufsid/49f8a3e136e4ee3d removed. GEOM_LABEL: Label for provider ad0s1e is ufsid/49f8a3e136e4ee3d. GEOM_LABEL: Label ufsid/49f8a3e175f2b211 removed. GEOM_LABEL: Label for provider ad0s1f is ufsid/49f8a3e175f2b211. GEOM_LABEL: Label ufsid/49f8a3e53ba41565 removed. GEOM_LABEL: Label for provider ad0s1d is ufsid/49f8a3e53ba41565. GEOM_LABEL: Label ufsid/49f8a3e1ab5cc6ca removed. GEOM_LABEL: Label ufsid/49f8a3e136e4ee3d removed. GEOM_LABEL: Label ufsid/49f8a3e175f2b211 removed. GEOM_LABEL: Label ufsid/49f8a3e53ba41565 removed. lock order reversal: 1st 0xc39e7a60 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2555 2nd 0xc3ffee00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 KDB: stack backtrace: db_trace_self_wrapper(c0b84a8f,df3aaa78,c08576d5,c08495db,c0b87874,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08495db,c0b87874,c3d1fae8,c3d225f8,df3aaad4,...) at kdb_backtrace+0x29 _witness_debugger(c0b87874,c3ffee00,c0ba7492,c3d225f8,c0ba712b,...) at _witness_debugger+0x25 witness_checkorder(c3ffee00,9,c0ba712b,113,0,...) at witness_checkorder+0x839 _sx_xlock(c3ffee00,0,c0ba712b,113,d33946cc,...) at _sx_xlock+0x85 ufsdirhash_acquire(0,e,c3ea0000,c39e7a00,d33946cc,...) at ufsdirhash_acquire+0x35 ufsdirhash_remove(c4035d24,d33946cc,6cc,df3aab64,df3aab60,...) at ufsdirhash_remove+0x14 ufs_dirremove(c3ec7648,c4228e0c,500800c,0,c3ec7648,...) at ufs_dirremove+0xe5 ufs_remove(df3aac34,df3aac44,0,0,c422610c,...) at ufs_remove+0x6e VOP_REMOVE_APV(c0c7d520,df3aac34,2,df3aac00,bfbfef62,...) at VOP_REMOVE_APV+0xa5 kern_unlinkat(c3eb4d80,ffffff9c,bfbfef62,0,df3aac80,...) at kern_unlinkat+0x152 kern_unlink(c3eb4d80,bfbfef62,0,df3aad2c,c0ac2fd3,...) at kern_unlink+0x27 unlink(c3eb4d80,df3aacf8,4,c0b88129,c0c5e110,...) at unlink+0x22 syscall(df3aad38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (10, FreeBSD ELF32, unlink), eip = 0x2815e5af, esp = 0xbfbfe50c, ebp = 0xbfbfeda8 --- lock order reversal: 1st 0xc4224164 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1050 2nd 0xc4224df4 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2101 KDB: stack backtrace: db_trace_self_wrapper(c0b84a8f,df385814,c08576d5,c08495db,c0b87874,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08495db,c0b87874,c3d22590,c3d224c0,df385870,...) at kdb_backtrace+0x29 _witness_debugger(c0b87874,c4224df4,c0b7702e,c3d224c0,c0b8e6bd,...) at _witness_debugger+0x25 witness_checkorder(c4224df4,9,c0b8e6bd,835,0,...) at witness_checkorder+0x839 __lockmgr_args(c4224df4,80100,c4224e10,0,0,...) at __lockmgr_args+0x797 vop_stdlock(df385978,c085747b,c0b7725f,80100,c4224d9c,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0c5ac80,df385978,c403ee24,c0c94700,c4224d9c,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4224d9c,80100,c0b8e6bd,835,8,...) at _vn_lock+0x5e vget(c4224d9c,80100,c403ed80,160,c0b77181,...) at vget+0xc9 devfs_allocv(c40ee380,c402d280,df385a10,c403ed80,c0e21fb8,...) at devfs_allocv+0x11a devfs_root(c402d280,80000,df385c2c,c403ed80,0,...) at devfs_root+0x51 vfs_donmount(c403ed80,0,c40ee480,c40ee480,bfbfde39,...) at vfs_donmount+0x14d0 nmount(c403ed80,df385cf8,c,c,c0c60390,...) at nmount+0x72 syscall(df385d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e3edb, esp = 0xbfbfde0c, ebp = 0xbfbfe368 --- lock order reversal: 1st 0xc44edc2c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1076 2nd 0xc4a9737c ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4109 KDB: stack backtrace: db_trace_self_wrapper(c0b84a8f,df44aa2c,c08576d5,c08495db,c0b87874,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08495db,c0b87874,c3d1fd58,c3d22590,df44aa88,...) at kdb_backtrace+0x29 _witness_debugger(c0b87874,c4a9737c,c0b7aba2,c3d22590,c0b8e6bd,...) at _witness_debugger+0x25 witness_checkorder(c4a9737c,9,c0b8e6bd,100d,c4a97398,...) at witness_checkorder+0x839 __lockmgr_args(c4a9737c,80400,c4a97398,0,0,...) at __lockmgr_args+0x797 ffs_lock(df44ab98,c,0,80400,c4a97324,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0c7d520,df44ab98,df44aba0,c0c94700,c4a97324,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4a97324,80400,c0b8e6bd,100d,df44abf4,...) at _vn_lock+0x5e vfs_knllock(c4a97324,0,c0b7cd90,68c,c4a66154,...) at vfs_knllock+0x29 knlist_remove_kq(0,df44ac14,c089e909,c4a542f4,c4a66154,...) at knlist_remove_kq+0xad knlist_remove(c4a542f4,c4a66154,0,df44ac40,c07ebc85,...) at knlist_remove+0x1b filt_vfsdetach(c4a66154,0,c0b7cd90,75c,f,...) at filt_vfsdetach+0x39 knote_fdclose(c4443240,12af,c0b7c8d3,434,c44edc2c,...) at knote_fdclose+0xf5 kern_close(c4443240,12af,df44ad2c,c0ac2fd3,c4443240,...) at kern_close+0xd2 close(c4443240,df44acf8,4,c0b88115,c0c5e0b0,...) at close+0x1a syscall(df44ad38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x28370a73, esp = 0xbfbfe71c, ebp = 0xbfbfe738 --- pid 1712 (perl5.8.9), uid 0: exited on signal 6 (core dumped) pid 1713 (perl5.8.9), uid 0: exited on signal 6 (core dumped) pid 1771 (perl5.8.9), uid 0: exited on signal 6 (core dumped) ---------------------------------------------------------------- I rebooted and while X came back up via gdm, I had no keyboard under X. The whole system was running fine otherwise. Network was up, etc. So I ssh'ed in and things are running. I tried to stop gdb and I got a blank (black) screen and no console output or keyboard input. No virt screen anywhere. So, I wonder if X was hosed and also needed to be updated, etc. In fact, shouldn't I have to re-install a bunch of ports now? Shouldn't a pointer a the end of Chapter 24 suggest going and redoing some packages or ports? So, I want to re-install correctly installed ports and packages. So I "porsnap fetch", and, despite the end of Chapter 24.3, it appears to have also already done the "extract" step: # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found. Fetching public key from portsnap1.FreeBSD.org... done. Fetching snapshot tag from portsnap1.FreeBSD.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Sat May 9 19:53:40 CDT 2009: 711cd4d0113f1163f35f6897c249aaee03563c991e5901100% of 56 MB 920 kBps 00m00s Extracting snapshot... done. Verifying snapshot integrity... done. Fetching snapshot tag from portsnap1.FreeBSD.org... done. Fetching snapshot metadata... done. Updating from Sat May 9 19:53:40 CDT 2009 to Sun May 10 13:48:13 CDT 2009. Fetching 3 metadata patches.. done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 70 patches.....10....20....30....40....50....60....70 done. Applying patches... done. Fetching 8 new ports or files... done. # I also get told: # pkg_add -r xorg Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/Latest/xorg.tbz... Done. pkg_add: package 'xorg-7.4_1' or its older version already installed But I confess, I am dubious that the 7.2-RC2 to 8.0-CURRENT doesn't mandate a few recompiles of some X packages or libraries. Is there a way to force all those dependencies for already installed packages to be updated or recompiled in the new 8.0 world view? As needed, pointers to a web page, clue-by-four, etc., all appreciated! Thanks, jdl From venture37 at gmail.com Sun May 10 22:25:28 2009 From: venture37 at gmail.com (Sevan / Venture37) Date: Sun May 10 22:25:39 2009 Subject: rum(4) not working on 8-CURRENT In-Reply-To: <20090510204757.GA45375@citylink.fud.org.nz> References: <4A072AF0.2000903@gmail.com> <20090510204757.GA45375@citylink.fud.org.nz> Message-ID: <4A075451.2070001@gmail.com> Andrew Thompson wrote: > You need to create a wlan pseudo device and operate on that > > # ifconfig wlan0 create wlandev rum0 up > > If you still have problems then enable debugging with 'wlandebug > state+scan' and then down/up the interface. Thanks for the tip, that sorted it, for the mailing list archive: I added wlans_rum0="wlan0" create_args_wlan0="wlanmode sta country GB" ifconfig_wlan0="DHCP" to /etc/rc.conf & that sorted out ipv4 connectivity, to get ipv6 working I had to add ipv6_network_interfaces="wlan0" aswell as ipv6_enable="YES" otherwise rtsol would not automatically run on the interface & you're left with a local link address on wlan0. Sevan / Venture37 From keramida at ceid.upatras.gr Sun May 10 22:35:30 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Sun May 10 22:35:37 2009 Subject: Feedback and Questions Updating to CURRENT In-Reply-To: (Jon Loeliger's message of "Sun, 10 May 2009 16:34:28 -0500") References: Message-ID: <87vdo8powi.fsf@kobe.laptop> On Sun, 10 May 2009 16:34:28 -0500, Jon Loeliger wrote: > Folks, > > I started with a 7.2-RC2 install and have been converting > it to CURRENT over the past few days. I've been following > the bouncing ball over in > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > and I think I was (mostly) successful. > > One pretty darn confusing aspect of this web site page is that, in > outline, basically reads: > > - You should follow these 8 instructions > - Here's a review of the 8 steps. > - Now, in detail, here are the steps. You are right that there is a fair bit of improvement we could make to the 'make world from scratch' chapter. I've thought a bit about this and I think we need to split this in at least a few more parts: - How to update from X.0-RELEASE to a newer Y.0-RELEASE. - How to upgrade from X.0-RELEASE to RELENG_X (for security updates only). - How to upgrade across major releases (from X.0-RELEASE to some newer Y.0-RELEASE or later code). - How to upgrade from X-STABLE to Y-CURRENT. There is inevitably some amount of repetition in these four upgrade procedures, but it may be more intuitive to have *all* the steps for each one of them in a consecutive section. If that sounds like something that would simplify things and make the upgrade steps more useful, please help us organize the documentation to match a better shape by posting any ideas to freebsd-doc. > But I confess, I am dubious that the 7.2-RC2 to 8.0-CURRENT doesn't > mandate a few recompiles of some X packages or libraries. Is there a > way to force all those dependencies for already installed packages to > be updated or recompiled in the new 8.0 world view? If you upgrade from 7.X-RELEASE to CURRENT it is probably a good idea to rebuild all ports with: pkgdb -Fu && portupgrade -fa or: portmaster -fa Every time you `portsnap fetch' and `portsnap update' you should look at `/usr/ports/UPDATING' too. Some the `UPDATING' file lists important upgrade steps that have to be performed manually. From kientzle at freebsd.org Sun May 10 23:35:18 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sun May 10 23:35:25 2009 Subject: Feedback and Questions Updating to CURRENT In-Reply-To: References: Message-ID: <4A0764B3.1070407@freebsd.org> Jon Loeliger wrote: > > So, I wonder if X was hosed and also needed to be updated, etc. > In fact, shouldn't I have to re-install a bunch of ports now? > Shouldn't a pointer a the end of Chapter 24 suggest going and > redoing some packages or ports? In theory, your old software should run fine, even with a new world and kernel, although a few things may need slight reconfiguration due to changed device/driver names, etc. But it does probably make sense to update everything. /usr/ports/ports-mgmt/portupgrade is your friend here: $ portupgrade -af --batch shouldn't take more than a day or two, depending on what you have installed. Caveat: If you update anything, you'll probably have to update everything. Otherwise, you'll end up with some things linked against old libc and others linked against new libc, which breaks badly. Tim From jdl at jdl.com Mon May 11 00:29:40 2009 From: jdl at jdl.com (Jon Loeliger) Date: Mon May 11 00:29:47 2009 Subject: Feedback and Questions Updating to CURRENT In-Reply-To: <87vdo8powi.fsf@kobe.laptop> References: <87vdo8powi.fsf@kobe.laptop> Message-ID: Hi Giorgos, Thanks for your help here! > You are right that there is a fair bit of improvement we could make to > the 'make world from scratch' chapter. I've thought a bit about this > and I think we need to split this in at least a few more parts: > > - How to update from X.0-RELEASE to a newer Y.0-RELEASE. > > - How to upgrade from X.0-RELEASE to RELENG_X (for security updates > only). > > - How to upgrade across major releases (from X.0-RELEASE to some > newer Y.0-RELEASE or later code). > > - How to upgrade from X-STABLE to Y-CURRENT. > > There is inevitably some amount of repetition in these four upgrade > procedures, but it may be more intuitive to have *all* the steps for > each one of them in a consecutive section. > > If that sounds like something that would simplify things and make the > upgrade steps more useful, please help us organize the documentation to > match a better shape by posting any ideas to freebsd-doc. That wasn't the issue for me. My confusion stemmed from the fact that it was the *same* material just repeated 3 times. By the time I had read hrough the first set, I was baffled to stumble onto the second and third set. I think that if early in the page it had said something like Here's the overview of the steps we'll take:... In the next section, we'll progress through each of these steps in more detail... > If you upgrade from 7.X-RELEASE to CURRENT it is probably a good idea to > rebuild all ports with: Check. I found the Handbook chapter that covered this. It's all coming back to me slowly... > pkgdb -Fu && portupgrade -fa > > or: > > portmaster -fa And confusingly here, there's no indication as to why I might pick one or the other, nor the pros and cons of either, nor if having picked one, I could use the other later. So I set the first of those commands into motion and went to dinner. I was totally frustrated to find that some potentially large portion of that time was wasted waiting for an interactive response to some question that had a single-already-checked question that just needed to be confirmed or unchecked. Hrm. A "use the defaults" configuration for totally non-interactive build would have been my expectation here. Will I need to babysit this whole build now? Yep. > Every time you `portsnap fetch' and `portsnap update' you should look at > `/usr/ports/UPDATING' too. Some the `UPDATING' file lists important > upgrade steps that have to be performed manually. That's the one thing that's been clear so far. :-) jdl From jdl at jdl.com Mon May 11 00:37:05 2009 From: jdl at jdl.com (Jon Loeliger) Date: Mon May 11 00:37:11 2009 Subject: Feedback and Questions Updating to CURRENT In-Reply-To: <4A0764B3.1070407@freebsd.org> References: <4A0764B3.1070407@freebsd.org> Message-ID: > > In theory, your old software should run > fine, even with a new world and kernel, although > a few things may need slight reconfiguration > due to changed device/driver names, etc. Well, that's sort of what I was thinking too. But clearly some X or keyboard thing wasn't happy. > But it does probably make sense to update everything. Right. And a "pkgdb -f" suggested there were some updates that could be made anyway.... > /usr/ports/ports-mgmt/portupgrade is your friend > here: > $ portupgrade -af --batch Aha! --batch That seems like the ticket! Mentioning that on the "portupgrade -a" command would have been stellar! I should interrupt this "portupgrade" to add the --batch flag.... > shouldn't take more than a day or two, depending > on what you have installed. Only X.org, Gnome, Gnome-friends, Firefox and friends, the entire XML series, PDF, and emacsen, GCC, etc. On a 1.0GHz box with a gig of memory, what?, maybe two days. > Caveat: If you update anything, you'll probably > have to update everything. Otherwise, you'll > end up with some things linked against old libc > and others linked against new libc, which breaks > badly. Yeah, familiar with that one! Thanks! jdl From dougb at FreeBSD.org Mon May 11 04:50:05 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon May 11 04:50:11 2009 Subject: Bug in mergemaster(8) when used in service jails (scheme described in chapter 15.6.1 of the handbook) In-Reply-To: <20090510111110.GA88857@obiwan.tataz.chchile.org> References: <20090510111110.GA88857@obiwan.tataz.chchile.org> Message-ID: <4A07AE77.2080006@FreeBSD.org> Very interesting, thanks. I will have to educate myself a little bit more about this issue. Doug Jeremie Le Hen wrote: > Hi Doug, > > In the chapter 15.6.1 of the handbook, "Service jails", the last part > explains how to upgrade jails. The last step is to run mergmaster(8) in > each jail. > > The problem is that in service jails /etc is a symlink to /s/etc, /s > being the readable/writable filesystem. mtree(8) stumbles on /etc being a > symlink instead of a directory and doesn't proceed futher down into /etc to > check files. Consequently, ${CHANGED} is empty and all customized > configuration are overwritten with their default version. > > I've fixed mergemaster(8) with the following patch: > > % Index: mergemaster.sh > % =================================================================== > % RCS file: /mnt/space/cvsroot/src/usr.sbin/mergemaster/mergemaster.sh,v > % retrieving revision 1.69 > % diff -u -r1.69 mergemaster.sh > % --- mergemaster.sh 23 Mar 2009 14:42:41 -0000 1.69 > % +++ mergemaster.sh 10 May 2009 11:05:32 -0000 > % @@ -461,7 +461,7 @@ > % # > % CHANGED= > % if [ -n "${AUTO_UPGRADE}" -a -f "${DESTDIR}${MTREEFILE}" ]; then > % - for file in `mtree -eq -f ${DESTDIR}${MTREEFILE} -p ${DESTDIR}/ \ > % + for file in `mtree -eqL -f ${DESTDIR}${MTREEFILE} -p ${DESTDIR}/ \ > % 2>/dev/null | awk '($2 == "changed") {print $1}'`; do > % if [ -f "${DESTDIR}/$file" ]; then > % CHANGED="${CHANGED} ${DESTDIR}/$file" > > Regards, From dougb at FreeBSD.org Mon May 11 04:54:53 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon May 11 04:56:39 2009 Subject: New mergemaster option -I, failsafe install files In-Reply-To: <20090510165737.GB88857@obiwan.tataz.chchile.org> References: <20090510165737.GB88857@obiwan.tataz.chchile.org> Message-ID: <4A07AF92.1040309@FreeBSD.org> Jeremie Le Hen wrote: > Hi Doug, > > As you may guess from my multiple emails, I'm in the process of > upgrading my jails :-). > > Since I have one jail per service, a very few number of configuration > files are modified on each jail. As most of user of FreeBSD I think, > I'm used to run "mergemaster -iU" to automate the process as much as > possible. The problem with service jails (chapter 15.6.1 of the > handbook) is that / is read-only mounted on all jails, /etc /var /root > and a few other places being symlinks to /s, the private read-write > space of each jail. Thus when mergemaster tries to update > /boot/devices.hints it fails and abort. I think the way to solve this problem would be with an MM_PRE_COMPARE_SCRIPT that deletes /boot/device.hints (and any other relevant files) from the temproot. If they are not present in that directory when the comparison starts then it's a non-issue. > Therefore I've implemented a new -I option that does the same thing as > -i except that it will proceed on failure. ewwww, scary. :) Seriously though, I have very strong feelings about not blasting through errors since I have no way of determining which errors are/should be show stoppers, and which are merely annoying. And even if I thought I could write code to do that, the real answer would depend heavily on local policy in any case. Thanks for thinking about this issue in any case, Doug From saifi.khan at twincling.org Mon May 11 05:12:37 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Mon May 11 05:12:50 2009 Subject: Unable to find device node for /dev/ad4s1b in /dev ! Message-ID: Hi all: Issue faced Installer on 'Commit' step shows Unable to find device node for /dev/ad4s1b in /dev! The creation of filesystems will be aborted. System Intel Celeron M 1.6 GHz Intel 945GM board 2GB DDR2 160GB SATA Seagate HDD i'm using FreeBSD 8.0 200905 i386 DVD to try and install the OS. Using the FreeBSD 7.1 DVD, i'm able to make the partition, define the slices and install a 'minimal' distribution set. However with FreeBSD 8.0 200905 snapshot i'm getting the above mentioned error. Any pointers or workarounds ? thanks Saifi. From saifi.khan at twincling.org Mon May 11 05:16:05 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Mon May 11 05:16:17 2009 Subject: howto sidestep sysinstall during installation Message-ID: Hi all: Is there a way to sidestep the sysinstall during the installation process, beyond selecting the 'location' ? i'm using FreeBSD 8.0 200905 i386 snapshot DVD and looking for an approach to drive the entire installation from the Fixit# command line console. i'm a experienced Gentoo Linux user. Any suggestions, pointers or observations ? thanks Saifi. From saifi.khan at twincling.org Mon May 11 05:45:00 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Mon May 11 05:45:08 2009 Subject: fdisk: class not found Message-ID: Hi all: Trying to write a partition table using fdisk supplied in the installation DVD of FreeBSD 8.0 i386 200905 snapshot. Should we write new partition table ? [n] y fdisk: Class not found When i again run 'fdisk' it should the old partition table. What exactly does 'Class not found' mean ? There is no mention of the 'Class' in fdisk man page at http://www.freebsd.org/cgi/man.cgi?query=fdisk&sektion=8 Can the experienced BSD guys explain ? thanks Saifi. From kientzle at freebsd.org Mon May 11 05:49:02 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon May 11 05:49:09 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <4A07BC4D.7080604@freebsd.org> Alexander Motin wrote: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. ... This is great work! > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but .... local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. ... Originally, before SMP era, FreeBSD used i8254 (for HZ) > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > resurrect them for SMP systems. To use them, you can disable local APIC > timers by adding to /boot/loader.conf: > hint.apic.0.clock=0 I experimented a little bit with this and had a few odd experiences: sysctl hw.acpi.cpu.cx_lowest=C3 did drop power consumption significantly but made the system pretty unresponsive. In particular, the system completely hung at shutdown. I presume the hang was the APIC timer problem you mentioned. I started to try the "hint.apic.0.clock", but noticed in your commit r191720: > Add hint.apic.0.clock tunable. Setting it 0 disables using > LAPIC timers as hard-/stat-/profclock sources falling back > to using i8254 and rtc timers. > ... > This technique is not working for SMP yet, as only one CPU > receives timer interrupts. But I think that problem could > be fixed by forwarding interrupts to other CPUs with IPI. Is anyone looking at this yet? Tim From doconnor at gsoft.com.au Mon May 11 06:15:17 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon May 11 06:15:25 2009 Subject: howto sidestep sysinstall during installation In-Reply-To: References: Message-ID: <200905111545.11696.doconnor@gsoft.com.au> On Mon, 11 May 2009, Saifi Khan wrote: > Is there a way to sidestep the sysinstall during the > installation process, beyond selecting the 'location' ? > > i'm using FreeBSD 8.0 200905 i386 snapshot DVD and looking > for an approach to drive the entire installation from the > Fixit# command line console. > > i'm a experienced Gentoo Linux user. > > Any suggestions, pointers or observations ? You won't be able to partition the disk from the command line because the install MFS doesn't have any of the requisite tools to do so. You could do it from a livefs disk however. As for observations.. I think you're wasting your time :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090511/c0ea4f59/attachment.pgp From anti_spam256 at yahoo.ca Mon May 11 06:51:01 2009 From: anti_spam256 at yahoo.ca (James Phillips) Date: Mon May 11 06:51:07 2009 Subject: Fw: Re: Unable to find device node for /dev/ad4s1b in /dev ! Message-ID: <481597.59422.qm@web65506.mail.ac4.yahoo.com> Oops, didn't cc the list :P --- On Mon, 5/11/09, James Phillips wrote: From: James Phillips Subject: Re: Unable to find device node for /dev/ad4s1b in /dev ! To: "Saifi Khan" Received: Monday, May 11, 2009, 2:20 AM --- On Mon, 5/11/09, Saifi Khan wrote: > From: Saifi Khan > Subject: Unable to find device node for /dev/ad4s1b in /dev ! > To: freebsd-current@freebsd.org, "FreeBSD Questions" > Received: Monday, May 11, 2009, 6:45 AM > Hi all: > > Issue faced > Installer on 'Commit' step shows > Unable to find device node for /dev/ad4s1b in /dev! > The creation of filesystems will be aborted. I am missing some context, but for me ad4 refers to the first drive on an add-on card. (ad0,1 -> Primary IDE controller, ad2,3 -> Secondary IDE controller) handbook reference: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-steps.html (Rule out the situation described in: 2.6.1 BIOS Drive Numbering) Your hardware in newer than mine: you have only one PATA port and 2 SATA ports. While having your drive labeled as ad4 strikes me as weird, I don't have enough BSD experience to know if it is a symptom of a problem or not. (I know my drive is on ad4 because the on-board controllers are slower than my add-on card. After a BIOS update booting is no problem. (I initially tried to forcibly disable the on-board controller: now, I ignore it.)) Do you think you may have come across an installer bug? If so, I suspect we will need more information about exactly what you were trying to do. Regards, James Phillips > > System > Intel Celeron M 1.6 GHz > Intel 945GM board Mobile chipset apparently. > 2GB DDR2 > 160GB SATA Seagate HDD > > > Any pointers or workarounds ? > > > thanks > Saifi. > _______________________________________________ > 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" > __________________________________________________________________ > Make your browsing faster, safer, and easier with the new > Internet Explorer? 8. Optimized for Yahoo! Get it Now for > Free! at http://downloads.yahoo.com/ca/internetexplorer/ __________________________________________________________________ The new Internet Explorer? 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ From saifi.khan at twincling.org Mon May 11 07:31:25 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Mon May 11 07:31:40 2009 Subject: Unable to find device node for /dev/ad4s1b in /dev ! In-Reply-To: <184059.72466.qm@web65505.mail.ac4.yahoo.com> References: <184059.72466.qm@web65505.mail.ac4.yahoo.com> Message-ID: On Sun, 10 May 2009, James Phillips wrote: > > --- On Mon, 5/11/09, Saifi Khan wrote: > > > From: Saifi Khan > > Subject: Unable to find device node for /dev/ad4s1b in /dev ! > > To: freebsd-current@freebsd.org, "FreeBSD Questions" > > Received: Monday, May 11, 2009, 6:45 AM > > Hi all: > > > > Issue faced > > Installer on 'Commit' step shows > > Unable to find device node for /dev/ad4s1b in /dev! > > The creation of filesystems will be aborted. > > I am missing some context, but for me ad4 refers to the first drive on an add-on card. (ad0,1 -> Primary IDE controller, ad2,3 -> Secondary IDE controller) > > handbook reference: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-steps.html > (Rule out the situation described in: > 2.6.1 BIOS Drive Numbering) > > Your hardware in newer than mine: you have only one PATA port and 2 SATA ports. While having your drive labeled as ad4 strikes me as weird, I don't have enough BSD experience to know if it is a symptom of a problem or not. (I know my drive is on ad4 because the on-board controllers are slower than my add-on card. After a BIOS update booting is no problem. (I initially tried to forcibly disable the on-board controller: now, I ignore it.)) > > > Do you think you may have come across an installer bug? > If so, I suspect we will need more information about exactly what you were trying to do. > > Regards, > > James Phillips > > > > > System > > Intel Celeron M 1.6 GHz > > Intel 945GM board > Mobile chipset apparently. > > > 2GB DDR2 > > 160GB SATA Seagate HDD > > > > > > > Any pointers or workarounds ? > > > > Thank you for your kind reply. Thank you for the handbook reference, i did read the section. In fact, there is only one SATA HDD in my laptop. PCI information 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 06:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01) 08:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) I've got two identical Compaq Presario C300TU laptops - one running Gentoo Linux and other "would" run FreeBSD 8.0 (when it gets) Additionally, from the BIOS i've activated . Wireless Radio (Broadcom chipset) . Native SATA Controller . Realtek Netboot agent There is only ONE SATA Seagate HDD of 160GB in the system. Currently, i'm struggling to get the installation work from the Fixit# command line. Any suggestions ? thanks Saifi. From vince at unsane.co.uk Mon May 11 09:01:30 2009 From: vince at unsane.co.uk (Vincent Hoffman) Date: Mon May 11 09:01:46 2009 Subject: howto sidestep sysinstall during installation In-Reply-To: References: Message-ID: <4A07E966.60503@unsane.co.uk> On 11/5/09 11:48, Saifi Khan wrote: > Hi all: > > Is there a way to sidestep the sysinstall during the > installation process, beyond selecting the 'location' ? > > i'm using FreeBSD 8.0 200905 i386 snapshot DVD and looking > for an approach to drive the entire installation from the > Fixit# command line console. > > i'm a experienced Gentoo Linux user. > > Any suggestions, pointers or observations ? > > Since you are using the snapshot DVD you should have the live/fixit environment which is very handy for this. I would suggest a combination of LOTS of reading and understanding of the pages at http://typo.submonkey.net/articles/2006/04/13/installing-freebsd-on-usb-stick-episode-2 (which goes though the steps for partitoning and installing using fdisk and bsdlabel, adjust paths to your dvd-rom) and if you want zfs http://lulf.geeknest.org/blog/freebsd/Setting_up_a_zfs-only_system/ (goes though using gpart instead of fdisk and bsdlabel if you want to use zfs on root) should be enough to get you started. I assume you dont need too much hand holding since you want to install -CURRENT. Vince > thanks > Saifi. > _______________________________________________ > 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 guru at unixarea.de Mon May 11 12:21:27 2009 From: guru at unixarea.de (Matthias Apitz) Date: Mon May 11 12:21:42 2009 Subject: laptop Dell M4400 with -CURRENT? In-Reply-To: <1241796489.1733.25.camel@balrog.2hip.net> References: <20090428083627.GA3621@rebelion.Sisis.de> <20090508141755.GB13584@rebelion.Sisis.de> <1241796489.1733.25.camel@balrog.2hip.net> Message-ID: <20090511122121.GA9961@rebelion.Sisis.de> El d?a Friday, May 08, 2009 a las 10:28:09AM -0500, Robert Noland escribi?: > I have ported the nouveau drm driver. > > http://people.freebsd.org/~rnoland/drm-nouveau-043009.patch > > It is working on NV50 cards, NV40 was working, but with WITNESS enabled > I seem to be getting a panic on NV40. My NV40 card seems to be having > memory issues so I haven't been able to get and/or see the backtrace. I > think it is just a locking issue which should be pretty easily solved if > I can get a clear backtrace. > > You will need current libdrm and xf86-video-nouveau from ports. > > This won't get you 3d right now, but should get you EXA + Xv. Hello Robert, I have applied your patch and ported xf86-video-nouveau from ports; all is fine now and the display comes up with 1920x1200 resolution; I'm attaching Xorg.0.log so you can see what kind of chips the nouveau driver is detecting. Thanks again for your work and help matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. -------------- next part -------------- X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-CURRENT i386 Current Operating System: FreeBSD current 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Mon May 11 13:31:04 UTC 2009 guru@current:/usr/obj/usr/src/sys/REBELION-CURRENT i386 Build Date: 28 April 2009 11:44:04AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon May 11 14:07:21 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "AllowEmptyInput" "false" (==) Automatically adding devices (==) Automatically enabling devices (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, built-ins (**) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x6a0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on freebsd (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (--) PCI:*(0@1:0:0) nVidia Corporation Quadro FX 770M rev 161, Mem @ 0xf5000000/16777216, 0xe0000000/268435456, 0xf2000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536 (II) System resource ranges: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) "dri2" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "nouveau" (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so (II) Module nouveau: vendor="X.Org Foundation" compiled for 1.6.0, module version = 0.0.10 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (II) NOUVEAU driver 20090408.d8545e6 (II) NOUVEAU driver for NVIDIA chipset families : RIVA TNT (NV04) RIVA TNT2 (NV05) GeForce 256 (NV10) GeForce 2 (NV11, NV15) GeForce 4MX (NV17, NV18) GeForce 3 (NV20) GeForce 4Ti (NV25, NV28) GeForce FX (NV3x) GeForce 6 (NV4x) GeForce 7 (G7x) GeForce 8 (G8x) (II) Primary Device is: PCI 01@00:00:0 (II) resource ranges after probing: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (--) NOUVEAU(0): Chipset: "NVIDIA NV96" (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) NOUVEAU(0): Initializing int10 (==) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was already clear (==) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was already clear (II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000 (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear (II) Loading sub module "dri" (II) LoadModule: "dri" (II) Reloading /usr/local/lib/xorg/modules/extensions//libdri.so (II) NOUVEAU(0): Loaded DRI module drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) [drm] loaded kernel module for "nouveau" driver. (II) [drm] DRM interface version 1.2 (II) [drm] DRM open master succeeded. (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12 (--) NOUVEAU(0): [drm] kernel modesetting not available (--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3 (==) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32 (==) NOUVEAU(0): RGB weight 888 (==) NOUVEAU(0): Default visual is TrueColor (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/local/lib/xorg/modules//libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 1.6.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 5.0 (==) NOUVEAU(0): Randr1.2 support enabled (==) NOUVEAU(0): Using HW cursor (--) NOUVEAU(0): Linear framebuffer at 0xE0000000 (--) NOUVEAU(0): MMIO registers at 0xF5000000 (II) NOUVEAU(0): Initial CRTC_OWNER is 0 (II) NOUVEAU(0): Attempting to load BIOS image from PROM (!!) NOUVEAU(0): ... BIOS signature not found (II) NOUVEAU(0): Attempting to load BIOS image from PRAMIN (II) NOUVEAU(0): ... appears to be valid (II) NOUVEAU(0): BIT BIOS found (II) NOUVEAU(0): Bios version 62.94.34.00 (WW) NOUVEAU(0): TMDS table revision 2.0 not currently supported (II) NOUVEAU(0): Found Display Configuration Block version 4.0 (!!) NOUVEAU(0): Raw DCB entry 0: 01000323 00010034 (WW) NOUVEAU(0): G80+ LVDS not initialized by driver; ignoring conf bits (!!) NOUVEAU(0): Raw DCB entry 1: 02011300 00000028 (!!) NOUVEAU(0): Raw DCB entry 2: 02022386 0f200010 (WW) NOUVEAU(0): DCB I2C table has port type 6 (!!) NOUVEAU(0): Raw DCB entry 3: 02022332 00020010 (!!) NOUVEAU(0): Raw DCB entry 4: 040333a6 0f200010 (WW) NOUVEAU(0): DCB I2C table has port type 6 (!!) NOUVEAU(0): Raw DCB entry 5: 04033312 00020010 (--) NOUVEAU(0): Parsing VBIOS init table 0 at offset 0xD1CE (EE) NOUVEAU(0): ========== unknown reg 0x00021220 ========== (EE) NOUVEAU(0): ========== unknown reg 0x0002121C ========== (EE) NOUVEAU(0): 0xD2D6: Init table command not found: 0x97 (--) NOUVEAU(0): Parsing VBIOS init table 1 at offset 0xD5D6 (--) NOUVEAU(0): Parsing VBIOS init table 2 at offset 0xE59F (--) NOUVEAU(0): Parsing VBIOS init table 3 at offset 0xE6E8 (--) NOUVEAU(0): Parsing VBIOS init table 4 at offset 0xE924 (II) NOUVEAU(0): LVDS clock seems to be 151700 KHz. (II) NOUVEAU(0): Found 0 modes, this is not useful (II) NOUVEAU(0): NV50DispPreInit is called. (--) NOUVEAU(0): DCB entry 0: type: 3, i2c_index: 2, heads: 3, bus: 0, or: 1 (II) NOUVEAU(0): I2C bus "LVDS-0" initialized. (II) NOUVEAU(0): SOR-0 attached with index 0 to LVDS-0 (--) NOUVEAU(0): DCB entry 1: type: 0, i2c_index: 0, heads: 3, bus: 1, or: 2 (II) NOUVEAU(0): I2C bus "VGA-0" initialized. (II) NOUVEAU(0): DAC-1 attached with index 0 to VGA-0 (--) NOUVEAU(0): DCB entry 2: type: 6, i2c_index: 8, heads: 3, bus: 2, or: 2 (WW) NOUVEAU(0): DCB type 6 not known (--) NOUVEAU(0): DCB entry 3: type: 2, i2c_index: 3, heads: 3, bus: 2, or: 2 (II) NOUVEAU(0): I2C bus "DVI-0" initialized. (II) NOUVEAU(0): SOR-1 attached with index 0 to DVI-0 (--) NOUVEAU(0): DCB entry 4: type: 6, i2c_index: 10, heads: 3, bus: 3, or: 4 (WW) NOUVEAU(0): DCB type 6 not known (--) NOUVEAU(0): DCB entry 5: type: 2, i2c_index: 1, heads: 3, bus: 3, or: 4 (II) NOUVEAU(0): I2C bus "DVI-1" initialized. (II) NOUVEAU(0): SOR-2 attached with index 0 to DVI-1 (II) NOUVEAU(0): Output LVDS-0 using monitor section Monitor0 (II) NOUVEAU(0): Output VGA-0 has no monitor section (II) NOUVEAU(0): Output DVI-0 has no monitor section (II) NOUVEAU(0): Output DVI-1 has no monitor section (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): I2C device "LVDS-0:E-EDID segment register" registered at address 0x60. (II) NOUVEAU(0): I2C device "LVDS-0:ddc2" registered at address 0xA0. (II) NOUVEAU(0): Detected a Digital output on LVDS-0 (II) NOUVEAU(0): Found a suitable output, index 0 (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): EDID vendor "LGD", prod id 399 (II) NOUVEAU(0): Printing DDC gathered Modelines: (II) NOUVEAU(0): Modeline "1920x1200"x0.0 151.70 1920 1950 1980 2014 1200 1203 1209 1256 +hsync -vsync (75.3 kHz) (II) NOUVEAU(0): Modeline "1920x1200"x0.0 151.70 1920 1950 1980 2014 1200 1203 1209 1884 -hsync -vsync (75.3 kHz) (II) NOUVEAU(0): NV50ConnectorGetDDCModes is called. (II) NOUVEAU(0): EDID vendor "LGD", prod id 399 (II) NOUVEAU(0): LVDS-0: preferred mode is 1920x1200 (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): I2C device "VGA-0:E-EDID segment register" registered at address 0x60. (II) NOUVEAU(0): I2C device "VGA-0:ddc2" registered at address 0xA0. (II) NOUVEAU(0): Using bios provided load value of 506 (--) NOUVEAU(0): No Load present on DAC-1 (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): I2C device "DVI-0:E-EDID segment register" registered at address 0x60. (II) NOUVEAU(0): I2C device "DVI-0:ddc2" registered at address 0xA0. (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): I2C device "DVI-1:E-EDID segment register" registered at address 0x60. (II) NOUVEAU(0): I2C device "DVI-1:ddc2" registered at address 0xA0. (II) NOUVEAU(0): Output LVDS-0 connected (II) NOUVEAU(0): Output VGA-0 disconnected (II) NOUVEAU(0): Output DVI-0 disconnected (II) NOUVEAU(0): Output DVI-1 disconnected (II) NOUVEAU(0): Using exact sizes for initial modes (II) NOUVEAU(0): Output LVDS-0 using initial mode 1920x1200 (--) NOUVEAU(0): VideoRAM: 262144 kBytes (==) NOUVEAU(0): Using gamma correction (1.0, 1.0, 1.0) (--) NOUVEAU(0): Virtual size is 1920x1920 (pitch 1920) (**) NOUVEAU(0): Driver mode "1920x1200": 151.7 MHz (scaled from 0.0 MHz), 75.3 kHz, 60.0 Hz (II) NOUVEAU(0): Modeline "1920x1200"x60.0 151.70 1920 1950 1980 2014 1200 1203 1209 1256 +hsync -vsync (75.3 kHz) (**) NOUVEAU(0): Driver mode "1920x1200": 151.7 MHz (scaled from 0.0 MHz), 75.3 kHz, 40.0 Hz (II) NOUVEAU(0): Modeline "1920x1200"x40.0 151.70 1920 1950 1980 2014 1200 1203 1209 1884 -hsync -vsync (75.3 kHz) (**) NOUVEAU(0): Default mode "1600x1200": 229.5 MHz (scaled from 0.0 MHz), 106.2 kHz, 85.0 Hz (II) NOUVEAU(0): Modeline "1600x1200"x85.0 229.50 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (106.2 kHz) (**) NOUVEAU(0): Default mode "1600x1200": 202.5 MHz (scaled from 0.0 MHz), 93.8 kHz, 75.0 Hz (II) NOUVEAU(0): Modeline "1600x1200"x75.0 202.50 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (93.8 kHz) (**) NOUVEAU(0): Default mode "1600x1200": 189.0 MHz (scaled from 0.0 MHz), 87.5 kHz, 70.0 Hz (II) NOUVEAU(0): Modeline "1600x1200"x70.0 189.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (87.5 kHz) (**) NOUVEAU(0): Default mode "1600x1200": 175.5 MHz (scaled from 0.0 MHz), 81.2 kHz, 65.0 Hz (II) NOUVEAU(0): Modeline "1600x1200"x65.0 175.50 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (81.2 kHz) (**) NOUVEAU(0): Default mode "1600x1200": 162.0 MHz (scaled from 0.0 MHz), 75.0 kHz, 60.0 Hz (II) NOUVEAU(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (**) NOUVEAU(0): Default mode "1400x1050": 155.8 MHz (scaled from 0.0 MHz), 81.5 kHz, 74.8 Hz (II) NOUVEAU(0): Modeline "1400x1050"x74.8 155.80 1400 1464 1784 1912 1050 1052 1064 1090 +hsync +vsync (81.5 kHz) (**) NOUVEAU(0): Default mode "1400x1050": 122.0 MHz (scaled from 0.0 MHz), 64.9 kHz, 60.0 Hz (II) NOUVEAU(0): Modeline "1400x1050"x60.0 122.00 1400 1488 1640 1880 1050 1052 1064 1082 +hsync +vsync (64.9 kHz) (**) NOUVEAU(0): Default mode "1280x1024": 157.5 MHz (scaled from 0.0 MHz), 91.1 kHz, 85.0 Hz (II) NOUVEAU(0): Modeline "1280x1024"x85.0 157.50 1280 1344 1504 1728 1024 1025 1028 1072 +hsync +vsync (91.1 kHz) (**) NOUVEAU(0): Default mode "1280x1024": 135.0 MHz (scaled from 0.0 MHz), 80.0 kHz, 75.0 Hz (II) NOUVEAU(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (**) NOUVEAU(0): Default mode "1280x1024": 108.0 MHz (scaled from 0.0 MHz), 64.0 kHz, 60.0 Hz (II) NOUVEAU(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (**) NOUVEAU(0): Default mode "1280x960": 148.5 MHz (scaled from 0.0 MHz), 85.9 kHz, 85.0 Hz (II) NOUVEAU(0): Modeline "1280x960"x85.0 148.50 1280 1344 1504 1728 960 961 964 1011 +hsync +vsync (85.9 kHz) (**) NOUVEAU(0): Default mode "1280x960": 108.0 MHz (scaled from 0.0 MHz), 60.0 kHz, 60.0 Hz (II) NOUVEAU(0): Modeline "1280x960"x60.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) (**) NOUVEAU(0): Default mode "1152x864": 108.0 MHz (scaled from 0.0 MHz), 67.5 kHz, 75.0 Hz (II) NOUVEAU(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (**) NOUVEAU(0): Default mode "1024x768": 94.5 MHz (scaled from 0.0 MHz), 68.7 kHz, 85.0 Hz (II) NOUVEAU(0): Modeline "1024x768"x85.0 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (68.7 kHz) (**) NOUVEAU(0): Default mode "1024x768": 78.8 MHz (scaled from 0.0 MHz), 60.0 kHz, 75.0 Hz (II) NOUVEAU(0): Modeline "1024x768"x75.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (**) NOUVEAU(0): Default mode "1024x768": 75.0 MHz (scaled from 0.0 MHz), 56.5 kHz, 70.1 Hz (II) NOUVEAU(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (**) NOUVEAU(0): Default mode "1024x768": 65.0 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz (II) NOUVEAU(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (**) NOUVEAU(0): Default mode "832x624": 57.3 MHz (scaled from 0.0 MHz), 49.7 kHz, 74.6 Hz (II) NOUVEAU(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (**) NOUVEAU(0): Default mode "800x600": 56.3 MHz (scaled from 0.0 MHz), 53.7 kHz, 85.1 Hz (II) NOUVEAU(0): Modeline "800x600"x85.1 56.30 800 832 896 1048 600 601 604 631 +hsync +vsync (53.7 kHz) (**) NOUVEAU(0): Default mode "800x600": 50.0 MHz (scaled from 0.0 MHz), 48.1 kHz, 72.2 Hz (II) NOUVEAU(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (**) NOUVEAU(0): Default mode "800x600": 49.5 MHz (scaled from 0.0 MHz), 46.9 kHz, 75.0 Hz (II) NOUVEAU(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (**) NOUVEAU(0): Default mode "800x600": 40.0 MHz (scaled from 0.0 MHz), 37.9 kHz, 60.3 Hz (II) NOUVEAU(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (**) NOUVEAU(0): Default mode "800x600": 36.0 MHz (scaled from 0.0 MHz), 35.2 kHz, 56.2 Hz (II) NOUVEAU(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (**) NOUVEAU(0): Default mode "640x480": 36.0 MHz (scaled from 0.0 MHz), 43.3 kHz, 85.0 Hz (II) NOUVEAU(0): Modeline "640x480"x85.0 36.00 640 696 752 832 480 481 484 509 -hsync -vsync (43.3 kHz) (**) NOUVEAU(0): Default mode "640x480": 31.5 MHz (scaled from 0.0 MHz), 37.9 kHz, 72.8 Hz (II) NOUVEAU(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (**) NOUVEAU(0): Default mode "640x480": 31.5 MHz (scaled from 0.0 MHz), 37.5 kHz, 75.0 Hz (II) NOUVEAU(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (**) NOUVEAU(0): Default mode "640x480": 25.2 MHz (scaled from 0.0 MHz), 31.5 kHz, 59.9 Hz (II) NOUVEAU(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (**) NOUVEAU(0): Default mode "720x400": 35.5 MHz (scaled from 0.0 MHz), 37.9 kHz, 85.0 Hz (II) NOUVEAU(0): Modeline "720x400"x85.0 35.50 720 756 828 936 400 401 404 446 -hsync +vsync (37.9 kHz) (**) NOUVEAU(0): Default mode "640x400": 31.5 MHz (scaled from 0.0 MHz), 37.9 kHz, 85.1 Hz (II) NOUVEAU(0): Modeline "640x400"x85.1 31.50 640 672 736 832 400 401 404 445 -hsync +vsync (37.9 kHz) (**) NOUVEAU(0): Default mode "640x350": 31.5 MHz (scaled from 0.0 MHz), 37.9 kHz, 85.1 Hz (II) NOUVEAU(0): Modeline "640x350"x85.1 31.50 640 672 736 832 350 382 385 445 +hsync -vsync (37.9 kHz) (**) NOUVEAU(0): Display dimensions: (330, 210) mm (**) NOUVEAU(0): DPI set to (147, 232) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) Loading sub module "exa" (II) LoadModule: "exa" (II) Loading /usr/local/lib/xorg/modules//libexa.so (II) Module exa: vendor="X.Org Foundation" compiled for 1.6.0, module version = 2.4.0 ABI class: X.Org Video Driver, version 5.0 (II) Loading sub module "shadowfb" (II) LoadModule: "shadowfb" (II) Loading /usr/local/lib/xorg/modules//libshadowfb.so (II) Module shadowfb: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (==) NOUVEAU(0): Write-combining range (0xa0000,0x10000) was already clear (II) NOUVEAU(0): Allocated 128MiB VRAM for framebuffer + offscreen pixmaps, at offset 0x20000000 (II) NOUVEAU(0): AGPGART: 32MiB available (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer (II) NOUVEAU(0): [drm] Using the DRM lock SAREA also for drawables. (II) NOUVEAU(0): [drm] framebuffer handle = 0xe0000000 (II) NOUVEAU(0): [drm] added 1 reserved context for kernel (II) NOUVEAU(0): X context handle = 0x1 (II) NOUVEAU(0): [drm] installed DRM signal handler (II) NOUVEAU(0): Opened GPU channel 2 (II) EXA(0): Offscreen pixmap area of 119472128 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (II) UploadToScreen (II) DownloadFromScreen (==) NOUVEAU(0): Backing store disabled (==) NOUVEAU(0): Silken mouse enabled (II) NOUVEAU(0): [DRI] installation complete (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video. (II) NOUVEAU(0): [XvMC] Extension initialized. (II) NOUVEAU(0): NVEnterVT is called. (II) NOUVEAU(0): NV50DispInit is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50DacGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50DacSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50DacGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_crtc_dpms is called with mode 3 for CRTC0. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50DacGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_crtc_dpms is called with mode 3 for CRTC1. (II) NOUVEAU(0): nv50_output_prepare is called. (II) NOUVEAU(0): nv50_crtc_prepare is called for CRTC0. (II) NOUVEAU(0): NV50DacModeSet is called. (II) NOUVEAU(0): Disconnecting DAC. (II) NOUVEAU(0): NV50SorModeSet is called. (II) NOUVEAU(0): Disconnecting SOR. (II) NOUVEAU(0): NV50SorModeSet is called. (II) NOUVEAU(0): Disconnecting SOR. (II) NOUVEAU(0): nv50_crtc_mode_set is called for CRTC0. (II) NOUVEAU(0): NV50CrtcModeSet is called for CRTC0. (II) NOUVEAU(0): NV50CrtcSetDither is called (no update). (II) NOUVEAU(0): NV50CrtcBlank is called (unblanked) for CRTC0. (II) NOUVEAU(0): nv50_output_mode_set is called. (II) NOUVEAU(0): NV50SorModeSet is called. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 0. (II) NOUVEAU(0): NV50CrtcSetScale is called with mode 2 for CRTC0. (II) NOUVEAU(0): nv50_crtc_commit is called for CRTC0. (II) NOUVEAU(0): NV50CrtcBlank is called (blanked) for CRTC1. (II) NOUVEAU(0): NV50CrtcSetPixelClock is called for CRTC0. (II) NOUVEAU(0): NV50CrtcSetClockMode is called for CRTC0. (II) NOUVEAU(0): nv50_output_commit is called. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50DacSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_crtc_dpms is called with mode 3 for CRTC1. (II) NOUVEAU(0): DPMS enabled (II) NOUVEAU(0): RandR 1.2 enabled, ignore the following RandR disabled message. (II) NOUVEAU(0): nv50_crtc_gamma_set is called for CRTC0. (II) NOUVEAU(0): NV50CrtcGammaSet is called for CRTC0. (II) NOUVEAU(0): nv50_crtc_gamma_set is called for CRTC1. (II) NOUVEAU(0): NV50CrtcGammaSet is called for CRTC1. (--) RandR disabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (II) NOUVEAU(0): Setting screen physical size to 331 x 207 (**) Option "Protocol" "auto" (**) Mouse0: Device: "/dev/sysmouse" (**) Mouse0: Protocol: "auto" (**) Option "CorePointer" (**) Mouse0: always reports core events (**) Option "Device" "/dev/sysmouse" (==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5 6 7" (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7 (**) Mouse0: Buttons: 11 (**) Mouse0: Sensitivity: 1 (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (**) Mouse0: (accel) keeping acceleration scheme 1 (**) Mouse0: (accel) filter chain progression: 2.00 (**) Mouse0: (accel) filter stage 0: 20.00 ms (**) Mouse0: (accel) set acceleration profile 0 (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse (**) Option "CoreKeyboard" (**) Keyboard0: always reports core events (**) Option "Protocol" "standard" (**) Keyboard0: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard0: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard0: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard0: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Keyboard0: CustomKeycodes disabled (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) exaCopyDirty: Pending damage region empty! (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): Detected a Digital output on LVDS-0 (II) NOUVEAU(0): Found a suitable output, index 0 (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): EDID vendor "LGD", prod id 399 (II) NOUVEAU(0): Printing DDC gathered Modelines: (II) NOUVEAU(0): Modeline "1920x1200"x0.0 151.70 1920 1950 1980 2014 1200 1203 1209 1256 +hsync -vsync (75.3 kHz) (II) NOUVEAU(0): Modeline "1920x1200"x0.0 151.70 1920 1950 1980 2014 1200 1203 1209 1884 -hsync -vsync (75.3 kHz) (II) NOUVEAU(0): NV50ConnectorGetDDCModes is called. (II) NOUVEAU(0): EDID vendor "LGD", prod id 399 (II) NOUVEAU(0): LVDS-0: preferred mode is 1920x1200 (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): Using bios provided load value of 506 (--) NOUVEAU(0): No Load present on DAC-1 (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): Detected a Digital output on LVDS-0 (II) NOUVEAU(0): Found a suitable output, index 0 (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): EDID vendor "LGD", prod id 399 (II) NOUVEAU(0): Printing DDC gathered Modelines: (II) NOUVEAU(0): Modeline "1920x1200"x0.0 151.70 1920 1950 1980 2014 1200 1203 1209 1256 +hsync -vsync (75.3 kHz) (II) NOUVEAU(0): Modeline "1920x1200"x0.0 151.70 1920 1950 1980 2014 1200 1203 1209 1884 -hsync -vsync (75.3 kHz) (II) NOUVEAU(0): NV50ConnectorGetDDCModes is called. (II) NOUVEAU(0): EDID vendor "LGD", prod id 399 (II) NOUVEAU(0): LVDS-0: preferred mode is 1920x1200 (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_mode_valid is called. (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): Using bios provided load value of 506 (--) NOUVEAU(0): No Load present on DAC-1 (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): nv50_crtc_gamma_set is called for CRTC0. (II) NOUVEAU(0): NV50CrtcGammaSet is called for CRTC0. (II) NOUVEAU(0): nv50_crtc_gamma_set is called for CRTC1. (II) NOUVEAU(0): NV50CrtcGammaSet is called for CRTC1. (II) NOUVEAU(0): nv50_crtc_gamma_set is called for CRTC0. (II) NOUVEAU(0): NV50CrtcGammaSet is called for CRTC0. (II) NOUVEAU(0): nv50_crtc_gamma_set is called for CRTC1. (II) NOUVEAU(0): NV50CrtcGammaSet is called for CRTC1. (II) NOUVEAU(0): NVLeaveVT is called. (II) NOUVEAU(0): NV50DispShutdown is called. (II) NOUVEAU(0): NV50CrtcBlank is called (blanked) for CRTC0. (II) NOUVEAU(0): NV50CrtcBlank is called (blanked) for CRTC1. (II) NOUVEAU(0): NVEnterVT is called. (II) NOUVEAU(0): NV50DispInit is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50DacGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50DacSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50DacGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_crtc_dpms is called with mode 3 for CRTC0. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50DacGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_output_get_crtc is called. (II) NOUVEAU(0): NV50SorGetCurrentCrtc is called. (II) NOUVEAU(0): nv50_crtc_dpms is called with mode 3 for CRTC1. (II) NOUVEAU(0): nv50_output_prepare is called. (II) NOUVEAU(0): nv50_crtc_prepare is called for CRTC0. (II) NOUVEAU(0): NV50DacModeSet is called. (II) NOUVEAU(0): Disconnecting DAC. (II) NOUVEAU(0): NV50SorModeSet is called. (II) NOUVEAU(0): Disconnecting SOR. (II) NOUVEAU(0): NV50SorModeSet is called. (II) NOUVEAU(0): Disconnecting SOR. (II) NOUVEAU(0): nv50_crtc_mode_set is called for CRTC0. (II) NOUVEAU(0): NV50CrtcModeSet is called for CRTC0. (II) NOUVEAU(0): NV50CrtcSetDither is called (no update). (II) NOUVEAU(0): NV50CrtcBlank is called (unblanked) for CRTC0. (II) NOUVEAU(0): nv50_output_mode_set is called. (II) NOUVEAU(0): NV50SorModeSet is called. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 0. (II) NOUVEAU(0): NV50CrtcSetScale is called with mode 2 for CRTC0. (II) NOUVEAU(0): nv50_crtc_commit is called for CRTC0. (II) NOUVEAU(0): NV50CrtcBlank is called (blanked) for CRTC1. (II) NOUVEAU(0): NV50CrtcSetPixelClock is called for CRTC0. (II) NOUVEAU(0): NV50CrtcSetClockMode is called for CRTC0. (II) NOUVEAU(0): nv50_output_commit is called. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50DacSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_output_dpms is called with mode 3. (II) NOUVEAU(0): NV50SorSetPowerMode is called with mode 3. (II) NOUVEAU(0): nv50_crtc_dpms is called with mode 3 for CRTC1. (II) NOUVEAU(0): nv50_crtc_gamma_set is called for CRTC0. (II) NOUVEAU(0): NV50CrtcGammaSet is called for CRTC0. (II) NOUVEAU(0): nv50_crtc_gamma_set is called for CRTC1. (II) NOUVEAU(0): NV50CrtcGammaSet is called for CRTC1. (**) Option "BaudRate" "1200" (**) Option "StopBits" "2" (**) Option "DataBits" "8" (**) Option "Parity" "None" (**) Option "Vmin" "1" (**) Option "Vtime" "0" (**) Option "FlowControl" "None" From mav at FreeBSD.org Mon May 11 12:22:11 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 11 12:22:18 2009 Subject: Fighting for the power. In-Reply-To: <4A07BC4D.7080604@freebsd.org> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> Message-ID: <4A081868.6010906@FreeBSD.org> Tim Kientzle wrote: > I started to try the "hint.apic.0.clock", but noticed > in your commit r191720: > Alexander Motin wrote: >> Add hint.apic.0.clock tunable. Setting it 0 disables using >> LAPIC timers as hard-/stat-/profclock sources falling back >> to using i8254 and rtc timers. >> ... >> This technique is not working for SMP yet, as only one CPU >> receives timer interrupts. But I think that problem could >> be fixed by forwarding interrupts to other CPUs with IPI. > > Is anyone looking at this yet? I have implemented SMP support for i386 and amd64 in some of my later commits. -- Alexander Motin From saifi.khan at twincling.org Mon May 11 12:47:36 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Mon May 11 12:47:43 2009 Subject: howto sidestep sysinstall during installation In-Reply-To: <4A07E966.60503@unsane.co.uk> References: <4A07E966.60503@unsane.co.uk> Message-ID: On Mon, 11 May 2009, Vincent Hoffman wrote: > On 11/5/09 11:48, Saifi Khan wrote: > > Hi all: > > > > Is there a way to sidestep the sysinstall during the > > installation process, beyond selecting the 'location' ? > > > > i'm using FreeBSD 8.0 200905 i386 snapshot DVD and looking > > for an approach to drive the entire installation from the > > Fixit# command line console. > > > > i'm a experienced Gentoo Linux user. > > > > Any suggestions, pointers or observations ? > > > > > Since you are using the snapshot DVD you should have the live/fixit > environment which is very handy for this. > I would suggest a combination of LOTS of reading and understanding of > the pages at > http://typo.submonkey.net/articles/2006/04/13/installing-freebsd-on-usb-stick-episode-2 > (which goes though the steps for partitoning and installing using fdisk > and bsdlabel, adjust paths to your dvd-rom) > and if you want zfs > http://lulf.geeknest.org/blog/freebsd/Setting_up_a_zfs-only_system/ > (goes though using gpart instead of fdisk and bsdlabel if you want to > use zfs on root) > should be enough to get you started. I assume you dont need too much > hand holding since you want to install -CURRENT. > > > Vince > Vince, thanks for the freebsd-on-usb link. i really appreciate your help. "Unknown giant" i still wonder why a snapshot should have a dysfunctional installer ? stable slice and partition support is key to trying or helping or contributing towards testing/coding for an evolving "unknown giant". Oh well :) Check this out http://www.twincling.org/node/237 If you scan this page for a minute, you will appreciate the overall flow of installation of Gentoo Linux. Even if you haven't tried the weekly Gentoo build, you may be encouraged to try this out ! Putting out a monthly snapshot is nice and if the people are going to not find info about 'Fixit#' and commands in the legendary handbook, that is not very helpful. thanks Saifi. the time has come ... 1227. From kostikbel at gmail.com Mon May 11 13:30:39 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon May 11 13:30:46 2009 Subject: Feedback and Questions Updating to CURRENT In-Reply-To: <4A0764B3.1070407@freebsd.org> References: <4A0764B3.1070407@freebsd.org> Message-ID: <20090511133019.GT1948@deviant.kiev.zoral.com.ua> On Sun, May 10, 2009 at 04:35:15PM -0700, Tim Kientzle wrote: > Caveat: If you update anything, you'll probably > have to update everything. Otherwise, you'll > end up with some things linked against old libc > and others linked against new libc, which breaks > badly. Hopefully, this is much less a concern with 7->8 transition, because our libc, libpthread and libm have symbol versions. I expect that these three libraries will not get the bump when 8 is going to be released. Probably, libutil may be exempt from the bump too. On the other hand, most if not all other system libraries are not converted to versioned symbols. I am not sure whether the full ports rebuild is actually needed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090511/2eceb307/attachment.pgp From jerrymc at msu.edu Mon May 11 13:35:45 2009 From: jerrymc at msu.edu (Jerry McAllister) Date: Mon May 11 13:44:46 2009 Subject: howto sidestep sysinstall during installation In-Reply-To: <200905111545.11696.doconnor@gsoft.com.au> References: <200905111545.11696.doconnor@gsoft.com.au> Message-ID: <20090511130405.GB20271@gizmo.acns.msu.edu> On Mon, May 11, 2009 at 03:45:03PM +0930, Daniel O'Connor wrote: > On Mon, 11 May 2009, Saifi Khan wrote: > > Is there a way to sidestep the sysinstall during the > > installation process, beyond selecting the 'location' ? > > > > i'm using FreeBSD 8.0 200905 i386 snapshot DVD and looking > > for an approach to drive the entire installation from the > > Fixit# command line console. > > > > i'm a experienced Gentoo Linux user. > > > > Any suggestions, pointers or observations ? > > You won't be able to partition the disk from the command line because > the install MFS doesn't have any of the requisite tools to do so. ??????? I don't understand this comment. Recreating a disk - slice/parttion/newfs - is one of the main things to do under a fixit. You should have fdisk, bsdlabel and newfs there as well as restore for sucking dumps back in. The only thing to remember is that the running writable root file system under fixit is in memory. You have to make sure that what you do is to the disk and that the fstab you create is on the disk. It is easy to lose track and make an /etc/fstab modification or a mount point in the MFS and then find it is no longer there when you reboot. But, you just have to pay attention to where you are doing things. ////jerry > > You could do it from a livefs disk however. > > As for observations.. I think you're wasting your time :) > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From doconnor at gsoft.com.au Mon May 11 13:47:35 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon May 11 13:47:42 2009 Subject: howto sidestep sysinstall during installation In-Reply-To: <20090511130405.GB20271@gizmo.acns.msu.edu> References: <200905111545.11696.doconnor@gsoft.com.au> <20090511130405.GB20271@gizmo.acns.msu.edu> Message-ID: <200905112317.17225.doconnor@gsoft.com.au> On Mon, 11 May 2009, Jerry McAllister wrote: > On Mon, May 11, 2009 at 03:45:03PM +0930, Daniel O'Connor wrote: > > On Mon, 11 May 2009, Saifi Khan wrote: > > > Is there a way to sidestep the sysinstall during the > > > installation process, beyond selecting the 'location' ? > > > > > > i'm using FreeBSD 8.0 200905 i386 snapshot DVD and looking > > > for an approach to drive the entire installation from the > > > Fixit# command line console. > > > > > > i'm a experienced Gentoo Linux user. > > > > > > Any suggestions, pointers or observations ? > > > > You won't be able to partition the disk from the command line > > because the install MFS doesn't have any of the requisite tools to > > do so. > > ??????? I don't understand this comment. > Recreating a disk - slice/parttion/newfs - is one of the main things > to do under a fixit. You should have fdisk, bsdlabel and newfs > there as well as restore for sucking dumps back in. Depends what sort of fixit you have. A holographic shell won't have it, but the others will. It's pretty easy to do a minimal install on your new disk and then go into the fixit shell, then you will have the full suite of tools (although if you're doing a full restore you should use the /rescue version or odd things will happen when you overwrite the binary you're using). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090511/efa1a0a1/attachment.pgp From doconnor at gsoft.com.au Mon May 11 14:04:09 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon May 11 14:04:15 2009 Subject: howto sidestep sysinstall during installation In-Reply-To: References: <4A07E966.60503@unsane.co.uk> Message-ID: <200905112334.03387.doconnor@gsoft.com.au> On Tue, 12 May 2009, Saifi Khan wrote: > "Unknown giant" > i still wonder why a snapshot should have a dysfunctional installer ? > > stable slice and partition support is key to trying or helping > or contributing towards testing/coding for an evolving "unknown > giant". Oh well :) I think you're missing the point of a -current snapshot. It is _not_ designed for someone to come along and go "hey I'd like to get into developing FreeBSD, I'll install it". It is there as a "system test" (ie make sure make release works) and to provide a handy ISO for gurus if they need to bootstrap something. The fact the installer is broken should be reported as a bug though (ie send-pr). > Check this out > http://www.twincling.org/node/237 > > If you scan this page for a minute, you will appreciate the > overall flow of installation of Gentoo Linux. Even if you > haven't tried the weekly Gentoo build, you may be encouraged to > try this out ! > > Putting out a monthly snapshot is nice and if the people are > going to not find info about 'Fixit#' and commands in the > legendary handbook, that is not very helpful. FreeBSD doesn't work this way, you are trying to fit FreeBSD into your Gentoo way of thinking. Obviously this causes pain, please stop. If you want to try FreeBSD, start with a release, if that works then you can update to HEAD and install that way. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090511/af366f8c/attachment.pgp From saifi.khan at twincling.org Mon May 11 14:06:05 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Mon May 11 14:06:18 2009 Subject: single SATA disk and yet identified as 'ad4' Message-ID: Hi all: The system has just one SATA disk and yet bootloader process identified it as 'ad4'. Ideally, it should be ad1. Here is the PCI information 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 06:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01) 08:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) How does the labelling logic work ? thanks Saifi. From kvedulv at kvedulv.de Mon May 11 14:07:32 2009 From: kvedulv at kvedulv.de (Michael Moll) Date: Mon May 11 14:07:39 2009 Subject: Problems with VIA VB8001 (and probably other VIA Nano boards/laptops) Message-ID: <20090511134925.GA66775@darkthrone.kvedulv.de> Hello All, some days ago I migrated my home-server from a VIA PC2500E (with C7 CPU) to a VIA VB8001 (with VIA Nano). Overall it went quite good, I see only two remaining problems. - 1. SATA Controller With the patch found here: http://lists.freebsd.org/pipermail/freebsd-current/2009-February/003568.html the controller is detected correctly and negotiates SATA300 with the harddisks. It would be nice to have this (or a similar patch) commited. - 2. Power Management The est driver fails to attach to the CPU. This is somewhat OK, as the necessary table in est.c for this specific CPU is missing at the moment. When powerd is started, it usually takes about 3-5 seconds and the system panics. I guess, powerd tries to throttle the CPU down via ACPI oder P4TCC, as there are some levels recognized: dev.cpu.0.freq_levels: 1615/-1 1413/-1 1211/-1 1009/-1 807/-1 605/-1 403/-1 201/-1 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 The kernel configuration file, crashinfo output and verbose dmesg can be found at http://space.kvedulv.de/vb8001/ if someone wants to look into this. Best Regards -- Michael Moll From jdl at jdl.com Mon May 11 14:11:06 2009 From: jdl at jdl.com (Jon Loeliger) Date: Mon May 11 14:11:13 2009 Subject: Lock order reversal Message-ID: Folks, Curious if anyone saw the lock order reversal in my post from yesterday? Known issues? There appear to be 3 cases, highlighted below: 1st 0xc39e7a60 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2555 2nd 0xc3ffee00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 1st 0xc4224164 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1050 2nd 0xc4224df4 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2101 1st 0xc44edc2c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1076 2nd 0xc4a9737c ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4109 Thanks, jdl ------- Forwarded Message To: freebsd-current@freebsd.org Date: Sun, 10 May 2009 16:34:28 -0500 From: Jon Loeliger Message-Id: Subject: Feedback and Questions Updating to CURRENT [snip] First, dmesg had this to say, and appeared not to be too pleased near the end: (I used GENERIC, minus all the RAID options to build this kernel.) (Oh, and I use i686 only) ---------------------------------------------------------------- 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 #1: Sun May 10 08:52:22 CDT 2009 jdl@freebie.austin.rr.com:/usr/obj/usr/src/sys/FREEBIE WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (1109.89-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440800,MMX+,3DNow!+,3DNow!> real memory = 536870912 (512 MB) avail memory = 773992448 (738 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 2ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 256M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xd6000000-0xd6ffffff,0xd8000000-0xdfffffff irq 11 at device 0.0 on pci1 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 4.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] rl0: port 0xa400-0xa4ff mem 0xd5800000-0xd58000ff irq 9 at device 9.0 on pci0 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:e0:29:74:1c:4c rl0: [ITHREAD] pci0: at device 13.0 (no driver attached) atapci1: port 0x9800-0x9807,0x9400-0x9403,0x9000-0x9007,0x8800-0x8803,0x8400-0x843f mem 0xd5000000-0xd501ffff irq 10 at device 17.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atrtc0: port 0x70-0x73 irq 8 on acpi0 fdc1: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc1: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 cpu0: on acpi0 acpi_throttle0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0: No FDOUT register! ppc0: parallel port not found. Timecounter "TSC" frequency 1109893249 Hz quality 800 Timecounters tick every 1.000 msec ad0: 39083MB at ata0-master UDMA66 acd0: CDRW at ata1-master PIO4 acd1: CDROM at ata1-slave PIO4 WARNING: WITNESS option enabled, expect reduced performance. GEOM_LABEL: Label for provider ad0s1a is ufsid/49f8a3e1ab5cc6ca. GEOM_LABEL: Label for provider ad0s1d is ufsid/49f8a3e53ba41565. GEOM_LABEL: Label for provider ad0s1e is ufsid/49f8a3e136e4ee3d. GEOM_LABEL: Label for provider ad0s1f is ufsid/49f8a3e175f2b211. Trying to mount root from ufs:/dev/ad0s1a GEOM_LABEL: Label ufsid/49f8a3e1ab5cc6ca removed. GEOM_LABEL: Label for provider ad0s1a is ufsid/49f8a3e1ab5cc6ca. GEOM_LABEL: Label ufsid/49f8a3e136e4ee3d removed. GEOM_LABEL: Label for provider ad0s1e is ufsid/49f8a3e136e4ee3d. GEOM_LABEL: Label ufsid/49f8a3e175f2b211 removed. GEOM_LABEL: Label for provider ad0s1f is ufsid/49f8a3e175f2b211. GEOM_LABEL: Label ufsid/49f8a3e53ba41565 removed. GEOM_LABEL: Label for provider ad0s1d is ufsid/49f8a3e53ba41565. GEOM_LABEL: Label ufsid/49f8a3e1ab5cc6ca removed. GEOM_LABEL: Label ufsid/49f8a3e136e4ee3d removed. GEOM_LABEL: Label ufsid/49f8a3e175f2b211 removed. GEOM_LABEL: Label ufsid/49f8a3e53ba41565 removed. ---------------- lock order reversal: 1st 0xc39e7a60 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2555 2nd 0xc3ffee00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 KDB: stack backtrace: db_trace_self_wrapper(c0b84a8f,df3aaa78,c08576d5,c08495db,c0b87874,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08495db,c0b87874,c3d1fae8,c3d225f8,df3aaad4,...) at kdb_backtrace+0x29 _witness_debugger(c0b87874,c3ffee00,c0ba7492,c3d225f8,c0ba712b,...) at _witness_debugger+0x25 witness_checkorder(c3ffee00,9,c0ba712b,113,0,...) at witness_checkorder+0x839 _sx_xlock(c3ffee00,0,c0ba712b,113,d33946cc,...) at _sx_xlock+0x85 ufsdirhash_acquire(0,e,c3ea0000,c39e7a00,d33946cc,...) at ufsdirhash_acquire+0x35 ufsdirhash_remove(c4035d24,d33946cc,6cc,df3aab64,df3aab60,...) at ufsdirhash_remove+0x14 ufs_dirremove(c3ec7648,c4228e0c,500800c,0,c3ec7648,...) at ufs_dirremove+0xe5 ufs_remove(df3aac34,df3aac44,0,0,c422610c,...) at ufs_remove+0x6e VOP_REMOVE_APV(c0c7d520,df3aac34,2,df3aac00,bfbfef62,...) at VOP_REMOVE_APV+0xa5 kern_unlinkat(c3eb4d80,ffffff9c,bfbfef62,0,df3aac80,...) at kern_unlinkat+0x152 kern_unlink(c3eb4d80,bfbfef62,0,df3aad2c,c0ac2fd3,...) at kern_unlink+0x27 unlink(c3eb4d80,df3aacf8,4,c0b88129,c0c5e110,...) at unlink+0x22 syscall(df3aad38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 - --- syscall (10, FreeBSD ELF32, unlink), eip = 0x2815e5af, esp = 0xbfbfe50c, ebp = 0xbfbfeda8 --- ---------------- lock order reversal: 1st 0xc4224164 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1050 2nd 0xc4224df4 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2101 KDB: stack backtrace: db_trace_self_wrapper(c0b84a8f,df385814,c08576d5,c08495db,c0b87874,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08495db,c0b87874,c3d22590,c3d224c0,df385870,...) at kdb_backtrace+0x29 _witness_debugger(c0b87874,c4224df4,c0b7702e,c3d224c0,c0b8e6bd,...) at _witness_debugger+0x25 witness_checkorder(c4224df4,9,c0b8e6bd,835,0,...) at witness_checkorder+0x839 __lockmgr_args(c4224df4,80100,c4224e10,0,0,...) at __lockmgr_args+0x797 vop_stdlock(df385978,c085747b,c0b7725f,80100,c4224d9c,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0c5ac80,df385978,c403ee24,c0c94700,c4224d9c,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4224d9c,80100,c0b8e6bd,835,8,...) at _vn_lock+0x5e vget(c4224d9c,80100,c403ed80,160,c0b77181,...) at vget+0xc9 devfs_allocv(c40ee380,c402d280,df385a10,c403ed80,c0e21fb8,...) at devfs_allocv+0x11a devfs_root(c402d280,80000,df385c2c,c403ed80,0,...) at devfs_root+0x51 vfs_donmount(c403ed80,0,c40ee480,c40ee480,bfbfde39,...) at vfs_donmount+0x14d0 nmount(c403ed80,df385cf8,c,c,c0c60390,...) at nmount+0x72 syscall(df385d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 - --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e3edb, esp = 0xbfbfde0c, ebp = 0xbfbfe368 --- ---------------- lock order reversal: 1st 0xc44edc2c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1076 2nd 0xc4a9737c ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4109 KDB: stack backtrace: db_trace_self_wrapper(c0b84a8f,df44aa2c,c08576d5,c08495db,c0b87874,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08495db,c0b87874,c3d1fd58,c3d22590,df44aa88,...) at kdb_backtrace+0x29 _witness_debugger(c0b87874,c4a9737c,c0b7aba2,c3d22590,c0b8e6bd,...) at _witness_debugger+0x25 witness_checkorder(c4a9737c,9,c0b8e6bd,100d,c4a97398,...) at witness_checkorder+0x839 __lockmgr_args(c4a9737c,80400,c4a97398,0,0,...) at __lockmgr_args+0x797 ffs_lock(df44ab98,c,0,80400,c4a97324,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0c7d520,df44ab98,df44aba0,c0c94700,c4a97324,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4a97324,80400,c0b8e6bd,100d,df44abf4,...) at _vn_lock+0x5e vfs_knllock(c4a97324,0,c0b7cd90,68c,c4a66154,...) at vfs_knllock+0x29 knlist_remove_kq(0,df44ac14,c089e909,c4a542f4,c4a66154,...) at knlist_remove_kq+0xad knlist_remove(c4a542f4,c4a66154,0,df44ac40,c07ebc85,...) at knlist_remove+0x1b filt_vfsdetach(c4a66154,0,c0b7cd90,75c,f,...) at filt_vfsdetach+0x39 knote_fdclose(c4443240,12af,c0b7c8d3,434,c44edc2c,...) at knote_fdclose+0xf5 kern_close(c4443240,12af,df44ad2c,c0ac2fd3,c4443240,...) at kern_close+0xd2 close(c4443240,df44acf8,4,c0b88115,c0c5e0b0,...) at close+0x1a syscall(df44ad38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x28370a73, esp = 0xbfbfe71c, ebp = 0xbfbfe738 --- ---------------- pid 1712 (perl5.8.9), uid 0: exited on signal 6 (core dumped) pid 1713 (perl5.8.9), uid 0: exited on signal 6 (core dumped) pid 1771 (perl5.8.9), uid 0: exited on signal 6 (core dumped) ---------------------------------------------------------------- ------- End of Forwarded Message From saifi.khan at twincling.org Mon May 11 14:12:39 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Mon May 11 14:12:51 2009 Subject: howto sidestep sysinstall during installation In-Reply-To: <200905112334.03387.doconnor@gsoft.com.au> References: <4A07E966.60503@unsane.co.uk> <200905112334.03387.doconnor@gsoft.com.au> Message-ID: On Mon, 11 May 2009, Daniel O'Connor wrote: > > > > Putting out a monthly snapshot is nice and if the people are > > going to not find info about 'Fixit#' and commands in the > > legendary handbook, that is not very helpful. > > FreeBSD doesn't work this way, you are trying to fit FreeBSD into your > Gentoo way of thinking. Obviously this causes pain, please stop. > i'll be highly obliged, if you could share some nuggets of wisdom on 'the FreeBSD way' ! Please. thanks Saifi. From spawk at acm.poly.edu Mon May 11 14:44:51 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Mon May 11 14:45:07 2009 Subject: single SATA disk and yet identified as 'ad4' In-Reply-To: References: Message-ID: <4A083356.6020100@acm.poly.edu> By default, ATA disks are assigned numbers based on the ATA controller they are on, and whether they are primary or secondary on the controller. For example, the primary disk on the first controller would be ad0, the secondary disk on the first controller would be ad1, the primary disk on the second controller would be ad2, etc. This is the ATA_STATIC_ID kernel option. I expect that there are two ATA controllers before the one your disk is on. You may confirm this by running "atacontrol list". -Boris Saifi Khan wrote: > Hi all: > > The system has just one SATA disk and yet bootloader process > identified it as 'ad4'. Ideally, it should be ad1. > > Here is the PCI information > > 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) > 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) > 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) > 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) > 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) > 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) > 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) > 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) > 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) > 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) > 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) > 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 01) > 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) > 06:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01) > 08:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) > > How does the labelling logic work ? > > > thanks > Saifi. > _______________________________________________ > 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 mister.olli at googlemail.com Mon May 11 16:17:01 2009 From: mister.olli at googlemail.com (Mister Olli) Date: Mon May 11 16:17:10 2009 Subject: Assign IP address and hostname via kernel parameter In-Reply-To: <57A9FCBA-CBCB-45D2-9B95-5E5DBC0DB964@gid.co.uk> References: <1241623255.12407.6.camel@phoenix.blechhirn.net> <57A9FCBA-CBCB-45D2-9B95-5E5DBC0DB964@gid.co.uk> Message-ID: <1242058599.25870.26.camel@phoenix.blechhirn.net> Hi, I had a short look on google for this parameters, and from my understanding the NFS diskless client is using the informations out of it to set the appropriate settings on the network interface. So no luck when supplying them as kernel parameters. Oh and btw I'm not sure how to setup kernel options. Normally this is done in 'loader.conf', but since para-virtualized xen does start the kernel directly there's no way to do this via loader.conf. Does anyone have some idea or hints how to solve this problem? Regards, --- Mr. Olli On Wed, 2009-05-06 at 17:52 +0100, Bob Bishop wrote: > Hi, > > On 6 May 2009, at 16:20, Mister Olli wrote: > > > is there a way to configure IP address and hostname on freebsd systems > > via kernel command line parameters? [etc] > > When running diskless, the loader sets kernel variables like: > > boot.netif.gateway="192.168.198.1" > boot.netif.hwaddr="00:15:17:47:14:fc" > boot.netif.ip="192.168.198.8" > boot.netif.netmask="255.255.255.0" > > to values obtained from BOOTP or DHCP, and the right things happen. I > guess you could just set these in loader.conf or at the loader prompt. > > -- > Bob Bishop > rb@gid.co.uk > > > > From lars.engels at 0x20.net Mon May 11 17:16:51 2009 From: lars.engels at 0x20.net (Lars Engels) Date: Mon May 11 17:16:58 2009 Subject: Lock order reversal In-Reply-To: References: Message-ID: <20090511170051.GQ56667@e.0x20.net> On Mon, May 11, 2009 at 09:10:54AM -0500, Jon Loeliger wrote: > > Folks, > > Curious if anyone saw the lock order reversal in my > post from yesterday? Known issues? > > There appear to be 3 cases, highlighted below: > > 1st 0xc39e7a60 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2555 > 2nd 0xc3ffee00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 > > 1st 0xc4224164 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1050 > 2nd 0xc4224df4 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2101 > > 1st 0xc44edc2c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1076 > 2nd 0xc4a9737c ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4109 > > Thanks, > jdl Hi Jon, all three LORs are well known and listed here: http://sources.zabbadoz.net/freebsd/lor.html Cheers Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090511/ca4b234f/attachment.pgp From tinderbox at freebsd.org Mon May 11 17:59:23 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon May 11 17:59:35 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090511175919.96B057302F@freebsd-current.sentex.ca> TB --- 2009-05-11 15:54:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-11 15:54:19 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-05-11 15:54:19 - cleaning the object tree TB --- 2009-05-11 15:54:55 - cvsupping the source tree TB --- 2009-05-11 15:54:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-05-11 15:55:05 - building world TB --- 2009-05-11 15:55:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-11 15:55:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-11 15:55:05 - TARGET=ia64 TB --- 2009-05-11 15:55:05 - TARGET_ARCH=ia64 TB --- 2009-05-11 15:55:05 - TZ=UTC TB --- 2009-05-11 15:55:05 - __MAKE_CONF=/dev/null TB --- 2009-05-11 15:55:05 - cd /src TB --- 2009-05-11 15:55:05 - /usr/bin/make -B buildworld >>> World build started on Mon May 11 15:55:07 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon May 11 17:44:04 UTC 2009 TB --- 2009-05-11 17:44:04 - generating LINT kernel config TB --- 2009-05-11 17:44:04 - cd /src/sys/ia64/conf TB --- 2009-05-11 17:44:04 - /usr/bin/make -B LINT TB --- 2009-05-11 17:44:04 - building LINT kernel TB --- 2009-05-11 17:44:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-11 17:44:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-11 17:44:04 - TARGET=ia64 TB --- 2009-05-11 17:44:04 - TARGET_ARCH=ia64 TB --- 2009-05-11 17:44:04 - TZ=UTC TB --- 2009-05-11 17:44:04 - __MAKE_CONF=/dev/null TB --- 2009-05-11 17:44:04 - cd /src TB --- 2009-05-11 17:44:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon May 11 17:44:04 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/vfs_extattr.c cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/vfs_hash.c cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/vfs_init.c cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/vfs_lookup.c /src/sys/kern/vfs_lookup.c: In function 'lookup': /src/sys/kern/vfs_lookup.c:570: error: 'td' undeclared (first use in this function) /src/sys/kern/vfs_lookup.c:570: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_lookup.c:570: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-11 17:59:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-11 17:59:19 - ERROR: failed to build lint kernel TB --- 2009-05-11 17:59:19 - 6125.21 user 442.26 system 7499.83 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From tinderbox at freebsd.org Mon May 11 19:17:16 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon May 11 19:17:22 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20090511191712.962EB7302F@freebsd-current.sentex.ca> TB --- 2009-05-11 17:59:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-11 17:59:19 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-05-11 17:59:19 - cleaning the object tree TB --- 2009-05-11 17:59:51 - cvsupping the source tree TB --- 2009-05-11 17:59:51 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-05-11 18:00:02 - building world TB --- 2009-05-11 18:00:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-11 18:00:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-11 18:00:02 - TARGET=powerpc TB --- 2009-05-11 18:00:02 - TARGET_ARCH=powerpc TB --- 2009-05-11 18:00:02 - TZ=UTC TB --- 2009-05-11 18:00:02 - __MAKE_CONF=/dev/null TB --- 2009-05-11 18:00:02 - cd /src TB --- 2009-05-11 18:00:02 - /usr/bin/make -B buildworld >>> World build started on Mon May 11 18:00:03 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.bin/mail/vars.c cc -O2 -pipe -std=gnu99 -fstack-protector -o mail version.o cmd1.o cmd2.o cmd3.o cmdtab.o collect.o edit.o fio.o getname.o head.o v7.local.o lex.o list.o main.o names.o popen.o quit.o send.o strings.o temp.o tty.o util.o vars.o gzip -cn /src/usr.bin/mail/mail.1 > mail.1.gz ===> usr.bin/make (all) cc -O2 -pipe -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/arch.c cc1: warnings being treated as errors /src/usr.bin/make/arch.c: In function 'Arch_ParseArchive': /src/usr.bin/make/arch.c:402: warning: the address of 'members' will never be NULL *** Error code 1 Stop in /src/usr.bin/make. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-11 19:17:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-11 19:17:12 - ERROR: failed to build world TB --- 2009-05-11 19:17:12 - 3696.13 user 361.65 system 4672.78 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From jkim at FreeBSD.org Mon May 11 19:29:25 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Mon May 11 19:29:31 2009 Subject: [Fwd: Re: amd64 suspend/resume broken on current] In-Reply-To: <4A058B5C.3010707@FreeBSD.org> References: <4A058B5C.3010707@FreeBSD.org> Message-ID: <200905111529.12808.jkim@FreeBSD.org> [CC added] On Saturday 09 May 2009 09:55 am, Alexander Motin wrote: > -------- Original Message -------- > Subject: Re: amd64 suspend/resume broken on current > Date: Fri, 8 May 2009 21:52:45 +0200 > From: Guy Brand > Organization: Direction Informatique, Université de Strasbourg, > France To: Alexander Motin > References: > <4A021118.2030106@mavhome.dp.ua> <20090508111024.GK4922@unistra.fr> > <4A041DC2.90106@mavhome.dp.ua> <20090508144551.GA1599@unistra.fr> > <4A047925.6060301@mavhome.dp.ua> > > Guy Brand wrote: > > Alexander Motin wrote: > > > Done. No firewire issue of course, but a kernel panic on > > > resume. Bad karma since yesterday :-) > > > > Where is this panic happens now? > > Just after resuming: > > Fatal trap 12: page fault while in kernel mode > ... > current process = 1415 (acpiconf) > > The backtrace says: > > intr_execute_handlers() at intr_execute_handlers+0x21 > lapic_handle_intr() at lapic_handle_intr+0x37 > Xapic_isr1() at Xapic_isr1+0xa4 > > acpi_sleep_machdep() at acpi_sleep_machdep+0x3b2 > acpi_EnterSleepState() at acpi_EnterSleepState+0x3fe > acpi_AckSleepState() at acpi_AckSleepState+0x163 > devfs_ioctl() at devfs_ioctl_f+0x77 > kern_ioctl() at kern_ioctl+0xb0 > ioctl() at ioctl+0xfd > syscall() at syscal+0x246 > Xfast_syscall() at Xfast_syscall+0xd0 So, that means the interrupt handler is executed *before* device is completely resumed. In fact, the interrupts are not disabled for dcons(4), it seems: #if 0 /* Let dcons(4) be accessed */ /* Stop interrupt */ OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_EN | OHCI_INT_ERR | OHCI_INT_PHY_SID | OHCI_INT_PHY_INT | OHCI_INT_DMA_ATRQ | OHCI_INT_DMA_ATRS | OHCI_INT_DMA_PRRQ | OHCI_INT_DMA_PRRS | OHCI_INT_DMA_ARRQ | OHCI_INT_DMA_ARRS | OHCI_INT_PHY_BUS_R); /* FLUSH FIFO and reset Transmitter/Reciever */ OWRITE(sc, OHCI_HCCCTL, OHCI_HCC_RESET); #endif I guess firewire(4) should differentiate suspend and shutdown properly. Jung-uk Kim From cswiger at mac.com Mon May 11 19:39:06 2009 From: cswiger at mac.com (Chuck Swiger) Date: Mon May 11 19:39:37 2009 Subject: Fighting for the power. [syslogd] In-Reply-To: <4A00669A.10105@freebsd.org> References: <49FE1826.4060000@FreeBSD.org> <49FE29A4.30507@root.org> <49FE5EC8.3040205@FreeBSD.org> <20090505091914.GA94521@server.vk2pj.dyndns.org> <4A00669A.10105@freebsd.org> Message-ID: Hi-- On May 5, 2009, at 9:17 AM, Sam Leffler wrote: > Regarding syslogd, I've considered adding support to batch/buffer > writes to workaround a problem that I consider rather important: > syslogd is not started early enough in the boot so it's not > available to log msgs from other applications. In particular I hit > this because wpa_supplicant logs via syslog but when it's started at > boot syslogd isn't available and since wpa_supplicant operates in a > chroot'd environment it cannot defer connecting until syslogd has > started up so nothing is ever logged. > [ ... ] You can use -l flag to syslogd to create additional logging sockets under your chroot'ed filesystem tree, similar to the way named & ntpd uses it; see syslogd_precmd() in /etc/rc.d/syslogd.... Regards, -- -Chuck From tinderbox at freebsd.org Mon May 11 19:44:59 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon May 11 19:45:06 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090511194455.3A0017302F@freebsd-current.sentex.ca> TB --- 2009-05-11 18:30:43 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-11 18:30:43 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-05-11 18:30:43 - cleaning the object tree TB --- 2009-05-11 18:31:18 - cvsupping the source tree TB --- 2009-05-11 18:31:18 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-05-11 18:31:27 - building world TB --- 2009-05-11 18:31:27 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-11 18:31:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-11 18:31:27 - TARGET=sparc64 TB --- 2009-05-11 18:31:27 - TARGET_ARCH=sparc64 TB --- 2009-05-11 18:31:27 - TZ=UTC TB --- 2009-05-11 18:31:27 - __MAKE_CONF=/dev/null TB --- 2009-05-11 18:31:27 - cd /src TB --- 2009-05-11 18:31:27 - /usr/bin/make -B buildworld >>> World build started on Mon May 11 18:31:29 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.bin/mail/vars.c cc -O2 -pipe -std=gnu99 -fstack-protector -o mail version.o cmd1.o cmd2.o cmd3.o cmdtab.o collect.o edit.o fio.o getname.o head.o v7.local.o lex.o list.o main.o names.o popen.o quit.o send.o strings.o temp.o tty.o util.o vars.o gzip -cn /src/usr.bin/mail/mail.1 > mail.1.gz ===> usr.bin/make (all) cc -O2 -pipe -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/arch.c cc1: warnings being treated as errors /src/usr.bin/make/arch.c: In function 'Arch_ParseArchive': /src/usr.bin/make/arch.c:402: warning: the address of 'members' will never be NULL *** Error code 1 Stop in /src/usr.bin/make. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-11 19:44:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-11 19:44:55 - ERROR: failed to build world TB --- 2009-05-11 19:44:55 - 3463.61 user 345.80 system 4451.57 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From kientzle at freebsd.org Mon May 11 20:00:01 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon May 11 20:00:14 2009 Subject: single SATA disk and yet identified as 'ad4' In-Reply-To: References: Message-ID: <4A0883BC.9050505@freebsd.org> Saifi Khan wrote: > > The system has just one SATA disk and yet bootloader process > identified it as 'ad4'. Ideally, it should be ad1. > > 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) > 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 01) The ide interface gets ad0, ad1, ad2, ad3, the sata controller numbering starts with ad4. Tim From jkim at FreeBSD.org Mon May 11 20:02:36 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Mon May 11 20:02:49 2009 Subject: [Fwd: Re: amd64 suspend/resume broken on current] In-Reply-To: <200905111529.12808.jkim@FreeBSD.org> References: <4A058B5C.3010707@FreeBSD.org> <200905111529.12808.jkim@FreeBSD.org> Message-ID: <200905111602.20462.jkim@FreeBSD.org> On Monday 11 May 2009 03:29 pm, Jung-uk Kim wrote: > [CC added] > > On Saturday 09 May 2009 09:55 am, Alexander Motin wrote: > > -------- Original Message -------- > > Subject: Re: amd64 suspend/resume broken on current > > Date: Fri, 8 May 2009 21:52:45 +0200 > > From: Guy Brand > > Organization: Direction Informatique, Université de Strasbourg, > > France To: Alexander Motin > > References: > > <4A021118.2030106@mavhome.dp.ua> > > <20090508111024.GK4922@unistra.fr> <4A041DC2.90106@mavhome.dp.ua> > > <20090508144551.GA1599@unistra.fr> > > <4A047925.6060301@mavhome.dp.ua> > > > > Guy Brand wrote: > > > Alexander Motin wrote: > > > > Done. No firewire issue of course, but a kernel panic on > > > > resume. Bad karma since yesterday :-) > > > > > > Where is this panic happens now? > > > > Just after resuming: > > > > Fatal trap 12: page fault while in kernel mode > > ... > > current process = 1415 (acpiconf) > > > > The backtrace says: > > > > intr_execute_handlers() at intr_execute_handlers+0x21 > > lapic_handle_intr() at lapic_handle_intr+0x37 > > Xapic_isr1() at Xapic_isr1+0xa4 > > > > acpi_sleep_machdep() at acpi_sleep_machdep+0x3b2 > > acpi_EnterSleepState() at acpi_EnterSleepState+0x3fe > > acpi_AckSleepState() at acpi_AckSleepState+0x163 > > devfs_ioctl() at devfs_ioctl_f+0x77 > > kern_ioctl() at kern_ioctl+0xb0 > > ioctl() at ioctl+0xfd > > syscall() at syscal+0x246 > > Xfast_syscall() at Xfast_syscall+0xd0 > > So, that means the interrupt handler is executed *before* device is > completely resumed. In fact, the interrupts are not disabled for > dcons(4), it seems: > > #if 0 /* Let dcons(4) be accessed */ > /* Stop interrupt */ > OWRITE(sc, FWOHCI_INTMASKCLR, > OHCI_INT_EN | OHCI_INT_ERR | > OHCI_INT_PHY_SID > > | OHCI_INT_PHY_INT > | OHCI_INT_DMA_ATRQ | OHCI_INT_DMA_ATRS > | OHCI_INT_DMA_PRRQ | OHCI_INT_DMA_PRRS > | OHCI_INT_DMA_ARRQ | OHCI_INT_DMA_ARRS > | OHCI_INT_PHY_BUS_R); > > /* FLUSH FIFO and reset Transmitter/Reciever */ > OWRITE(sc, OHCI_HCCCTL, OHCI_HCC_RESET); > #endif > > I guess firewire(4) should differentiate suspend and shutdown > properly. Can you try the attached patch? I may be wrong cause I am not a firewire guru, though. Thanks! Jung-uk Kim -------------- next part -------------- --- sys/dev/firewire/fwohci.c 13 Feb 2009 17:44:07 -0000 1.98 +++ sys/dev/firewire/fwohci.c 11 May 2009 19:46:24 -0000 @@ -1742,7 +1742,7 @@ } int -fwohci_stop(struct fwohci_softc *sc, device_t dev) +fwohci_stop(struct fwohci_softc *sc, device_t dev, int suspend) { u_int i; @@ -1759,9 +1759,10 @@ OWRITE(sc, OHCI_ITCTLCLR(i), OHCI_CNTL_DMA_RUN); } -#if 0 /* Let dcons(4) be accessed */ -/* Stop interrupt */ - OWRITE(sc, FWOHCI_INTMASKCLR, + /* Let dcons(4) be accessed if it is not suspending. */ + if (suspend) { + /* Stop interrupt */ + OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_EN | OHCI_INT_ERR | OHCI_INT_PHY_SID | OHCI_INT_PHY_INT | OHCI_INT_DMA_ATRQ | OHCI_INT_DMA_ATRS @@ -1769,9 +1770,9 @@ | OHCI_INT_DMA_ARRQ | OHCI_INT_DMA_ARRS | OHCI_INT_PHY_BUS_R); -/* FLUSH FIFO and reset Transmitter/Reciever */ - OWRITE(sc, OHCI_HCCCTL, OHCI_HCC_RESET); -#endif + /* FLUSH FIFO and reset Transmitter/Reciever */ + OWRITE(sc, OHCI_HCCCTL, OHCI_HCC_RESET); + } /* XXX Link down? Bus reset? */ return 0; --- sys/dev/firewire/fwohci_pci.c 9 Mar 2009 13:23:54 -0000 1.62 +++ sys/dev/firewire/fwohci_pci.c 11 May 2009 19:46:24 -0000 @@ -408,7 +408,7 @@ s = splfw(); if (sc->bsr) - fwohci_stop(sc, self); + fwohci_stop(sc, self, 0); bus_generic_detach(self); if (sc->fc.bdev) { @@ -462,7 +462,7 @@ err = bus_generic_suspend(dev); if (err) return err; - fwohci_stop(sc, dev); + fwohci_stop(sc, dev, 1); return 0; } @@ -482,7 +482,7 @@ fwohci_softc_t *sc = device_get_softc(dev); bus_generic_shutdown(dev); - fwohci_stop(sc, dev); + fwohci_stop(sc, dev, 0); return 0; } --- sys/dev/firewire/fwohcivar.h 3 Feb 2009 17:13:37 -0000 1.18 +++ sys/dev/firewire/fwohcivar.h 11 May 2009 19:46:24 -0000 @@ -83,4 +83,4 @@ void fwohci_reset (struct fwohci_softc *, device_t); int fwohci_detach (struct fwohci_softc *, device_t); int fwohci_resume (struct fwohci_softc *, device_t); -int fwohci_stop (struct fwohci_softc *, device_t dev); +int fwohci_stop (struct fwohci_softc *, device_t, int); From onemda at gmail.com Mon May 11 20:08:51 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon May 11 20:09:08 2009 Subject: Fighting for the power. In-Reply-To: <4A081868.6010906@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> Message-ID: <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> On 5/11/09, Alexander Motin wrote: > Tim Kientzle wrote: >> I started to try the "hint.apic.0.clock", but noticed >> in your commit r191720: >> Alexander Motin wrote: >>> Add hint.apic.0.clock tunable. Setting it 0 disables using >>> LAPIC timers as hard-/stat-/profclock sources falling back >>> to using i8254 and rtc timers. >>> ... >>> This technique is not working for SMP yet, as only one CPU >>> receives timer interrupts. But I think that problem could >>> be fixed by forwarding interrupts to other CPUs with IPI. >> >> Is anyone looking at this yet? > > I have implemented SMP support for i386 and amd64 in some of my later > commits. And all those hacks helps verry little in my case, most gain I get when laptop monitor is switched off. Even switching hard disk off improves battery life very little. interrupt total rate irq1: atkbd0 5206 3 irq0: clk 156008 99 irq9: acpi0 1152 0 irq12: psm0 16092 10 irq14: ata0 6587 4 irq15: ata1 1 0 irq17: ndis0 28646 18 irq256: hdac0 18 0 Total 213710 136 -- Paul From kientzle at freebsd.org Mon May 11 20:10:44 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon May 11 20:10:50 2009 Subject: Installation of FreeBSD 8.0-Current-2009-amd64-dvd In-Reply-To: References: <4A04EA46.20106@freebsd.org> Message-ID: <4A088642.3030402@freebsd.org> Mehmet Erol Sanliturk wrote: > > I know that current snapshots should not be used in any production purposes > . > > My intention was only to install it , run some programs , and if I get a > feeling that supplying an information to current developers may be useful to > send an e-mail about my experiences . > > I think such installation and test results would be useful to current > developers if I am not wrongly assumed that . Feedback is always appreciated. If you'd like to work with -CURRENT, you should definitely learn how to use the FreeBSD "ports" system, which builds third-party software from source. As I mentioned earlier, "packages" are not always available for -CURRENT. The FreeBSD -CURRENT snapshot DVDs are actually a pretty tough place to start. They are automatically generated from whatever happens to be in SVN that day; as a result, they're mostly useful as a regular test of the release-building scripts and somewhat useful for testing the installer. For testing the rest of the system, I suggest that you learn how to update the core system from source code. There are quite a few articles and blog posts explaining how to do this. It also helps to watch the freebsd-current mailing list so you know when things are relatively calm. Tim From sam at freebsd.org Mon May 11 20:13:38 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon May 11 20:13:45 2009 Subject: Fighting for the power. [syslogd] In-Reply-To: References: <49FE1826.4060000@FreeBSD.org> <49FE29A4.30507@root.org> <49FE5EC8.3040205@FreeBSD.org> <20090505091914.GA94521@server.vk2pj.dyndns.org> <4A00669A.10105@freebsd.org> Message-ID: <4A0886F0.6030605@freebsd.org> Chuck Swiger wrote: > Hi-- > > On May 5, 2009, at 9:17 AM, Sam Leffler wrote: >> Regarding syslogd, I've considered adding support to batch/buffer >> writes to workaround a problem that I consider rather important: >> syslogd is not started early enough in the boot so it's not available >> to log msgs from other applications. In particular I hit this >> because wpa_supplicant logs via syslog but when it's started at boot >> syslogd isn't available and since wpa_supplicant operates in a >> chroot'd environment it cannot defer connecting until syslogd has >> started up so nothing is ever logged. >> [ ... ] > > > You can use -l flag to syslogd to create additional logging sockets > under your chroot'ed filesystem tree, similar to the way named & ntpd > uses it; see syslogd_precmd() in /etc/rc.d/syslogd.... > > Regards, Blech, thanks. That might be a stopgap solution but it still doesn't allow syslogd to be started earlier which is what is needed for many/most setups. syslogd has mountcritremote as REQUIRE to handle diskless setups but IMO this should be (at least) configurable. But rather than argue this nonsense I think the better solution is to do what I suggest so syslogd can be started very early and capture everything available (e.g. your suggestion still loses msgs logged while setting up nfs mounts). Sam From tinderbox at freebsd.org Mon May 11 20:26:22 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon May 11 20:26:34 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090511202619.349E27302F@freebsd-current.sentex.ca> TB --- 2009-05-11 19:17:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-11 19:17:12 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-05-11 19:17:12 - cleaning the object tree TB --- 2009-05-11 19:17:54 - cvsupping the source tree TB --- 2009-05-11 19:17:54 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-05-11 19:18:07 - building world TB --- 2009-05-11 19:18:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-11 19:18:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-11 19:18:07 - TARGET=sun4v TB --- 2009-05-11 19:18:07 - TARGET_ARCH=sparc64 TB --- 2009-05-11 19:18:07 - TZ=UTC TB --- 2009-05-11 19:18:07 - __MAKE_CONF=/dev/null TB --- 2009-05-11 19:18:07 - cd /src TB --- 2009-05-11 19:18:07 - /usr/bin/make -B buildworld >>> World build started on Mon May 11 19:18:09 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.bin/mail/vars.c cc -O2 -pipe -std=gnu99 -fstack-protector -o mail version.o cmd1.o cmd2.o cmd3.o cmdtab.o collect.o edit.o fio.o getname.o head.o v7.local.o lex.o list.o main.o names.o popen.o quit.o send.o strings.o temp.o tty.o util.o vars.o gzip -cn /src/usr.bin/mail/mail.1 > mail.1.gz ===> usr.bin/make (all) cc -O2 -pipe -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/arch.c cc1: warnings being treated as errors /src/usr.bin/make/arch.c: In function 'Arch_ParseArchive': /src/usr.bin/make/arch.c:402: warning: the address of 'members' will never be NULL *** Error code 1 Stop in /src/usr.bin/make. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-11 20:26:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-11 20:26:19 - ERROR: failed to build world TB --- 2009-05-11 20:26:19 - 3464.46 user 344.03 system 4146.30 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From pav at FreeBSD.org Mon May 11 21:25:07 2009 From: pav at FreeBSD.org (Pav Lucistnik) Date: Mon May 11 21:25:15 2009 Subject: pointyhat panic Message-ID: <1242075474.72992.118.camel@hood.oook.cz> panic: mtx_lock() of destroyed mutex @ /usr/src/sys/rpc/clnt_vc.c:953 cpuid = 2 KDB: enter: panic [thread pid 0 tid 100029 ] Stopped at kdb_enter+0x3d: movq $0,0x3f5fb8(%rip) db> bt Tracing pid 0 tid 100029 td 0xffffff00018e1000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b _mtx_lock_flags() at _mtx_lock_flags+0xc5 clnt_vc_soupcall() at clnt_vc_soupcall+0x273 sowakeup() at sowakeup+0xf8 tcp_do_segment() at tcp_do_segment+0x23c9 tcp_input() at tcp_input+0x9ec ip_input() at ip_input+0xbc ether_demux() at ether_demux+0x1ed ether_input() at ether_input+0x171 em_rxeof() at em_rxeof+0x201 em_handle_rxtx() at em_handle_rxtx+0x4b taskqueue_run() at taskqueue_run+0x96 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffff240a6d40, rbp = 0 --- The box is in kdb on serial console for now. May 9 -CURRENT, I think. -- Pav Lucistnik A spoonful of curry, garlic and mustard helps the medicine go down... and come straight back up again. -- JLE on #angband -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090511/60359d84/attachment.pgp From andrey.kosachenko at gmail.com Mon May 11 21:32:34 2009 From: andrey.kosachenko at gmail.com (Andrey) Date: Mon May 11 21:32:41 2009 Subject: system panics on USB-mouse detachment Message-ID: <4A089216.1050701@gmail.com> Hello, After recent sources upgrade ( __FreeBSD_version 800086, sources were updated on 11.05.2009) and world/kernel rebuild system freezes/panics on USB-mouse detachment. Issue is constantly reproducible. The only difference whether system just freezes (only power off helps) or (more seldom) it panics (page fault). However, mouse attachment never leads to panic/freeze (well, I didn't manage to catch such a case). So, I put debug stuff into kernel and managed to get some back-trace. There is various info taken from the system below. Please, let me know if more info is required. --- <> --- [silent@beastie][/home/silent]uname -a FreeBSD beastie.lan 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon May 11 19:18:35 EEST 2009 root@beastie.lan:/usr/obj/usr/src/sys/BEASTIE-SMP-ULE-20090511-debug-v1 i386 --- <> --- FreeBSD 8.0-CURRENT #0: Mon May 11 19:18:35 EEST 2009 root@beastie.lan:/usr/obj/usr/src/sys/BEASTIE-SMP-ULE-20090511-debug-v1 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fa Stepping = 10 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20000000 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3140399104 (2994 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 netsmb_dev: loaded acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bf700000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x4000-0x4007 mem 0xe4300000-0xe43fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M vgapci1: mem 0xe4400000-0xe44fffff at device 2.1 on pci0 uhci0: port 0x4020-0x403f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0x4040-0x405f irq 17 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 ehci0: mem 0xe4500000-0xe45003ff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 hdac0: mem 0xe4504000-0xe4507fff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090401_0132 hdac0: [ITHREAD] pcib1: irq 16 at device 28.0 on pci0 pci8: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci16: on pcib2 wpi0: mem 0xe4100000-0xe4100fff irq 17 at device 0.0 on pci16 wpi0: Driver Revision 20071127 wpi0: Hardware Revision (0x1) adding chan 1 (2412MHz) flags=0x2b maxpwr=15 passive=0, offset 2 adding chan 2 (2417MHz) flags=0x2b maxpwr=15 passive=0, offset 4 adding chan 3 (2422MHz) flags=0x2b maxpwr=15 passive=0, offset 6 adding chan 4 (2427MHz) flags=0x2b maxpwr=15 passive=0, offset 8 adding chan 5 (2432MHz) flags=0x2b maxpwr=15 passive=0, offset 10 adding chan 6 (2437MHz) flags=0x2b maxpwr=15 passive=0, offset 12 adding chan 7 (2442MHz) flags=0x2b maxpwr=15 passive=0, offset 14 adding chan 8 (2447MHz) flags=0x2b maxpwr=15 passive=0, offset 16 adding chan 9 (2452MHz) flags=0x2b maxpwr=15 passive=0, offset 18 adding chan 10 (2457MHz) flags=0x2b maxpwr=15 passive=0, offset 20 adding chan 11 (2462MHz) flags=0x2b maxpwr=15 passive=0, offset 22 adding chan 12 (2467MHz) flags=0x21 maxpwr=15 passive=1, offset 24 adding chan 13 (2472MHz) flags=0x21 maxpwr=15 passive=1, offset 26 adding chan 34 (5170MHz) flags=0x21 maxpwr=15 passive=1, offset 27 adding chan 36 (5180MHz) flags=0xab maxpwr=15 passive=0, offset 28 adding chan 38 (5190MHz) flags=0x21 maxpwr=15 passive=1, offset 29 adding chan 40 (5200MHz) flags=0xab maxpwr=15 passive=0, offset 30 adding chan 42 (5210MHz) flags=0x21 maxpwr=15 passive=1, offset 31 adding chan 44 (5220MHz) flags=0xab maxpwr=15 passive=0, offset 32 adding chan 46 (5230MHz) flags=0x21 maxpwr=15 passive=1, offset 33 adding chan 48 (5240MHz) flags=0xab maxpwr=15 passive=0, offset 34 adding chan 52 (5260MHz) flags=0xb1 maxpwr=15 passive=1, offset 35 adding chan 56 (5280MHz) flags=0xb1 maxpwr=15 passive=1, offset 36 adding chan 60 (5300MHz) flags=0xb1 maxpwr=15 passive=1, offset 37 adding chan 64 (5320MHz) flags=0xb1 maxpwr=15 passive=1, offset 38 adding chan 100 (5500MHz) flags=0xb1 maxpwr=16 passive=1, offset 39 adding chan 104 (5520MHz) flags=0xb1 maxpwr=16 passive=1, offset 40 adding chan 108 (5540MHz) flags=0xb1 maxpwr=16 passive=1, offset 41 adding chan 112 (5560MHz) flags=0xb1 maxpwr=16 passive=1, offset 42 adding chan 116 (5580MHz) flags=0xb1 maxpwr=16 passive=1, offset 43 adding chan 120 (5600MHz) flags=0xb1 maxpwr=16 passive=1, offset 44 adding chan 124 (5620MHz) flags=0xb1 maxpwr=16 passive=1, offset 45 adding chan 128 (5640MHz) flags=0xb1 maxpwr=16 passive=1, offset 46 adding chan 132 (5660MHz) flags=0xb1 maxpwr=16 passive=1, offset 47 adding chan 136 (5680MHz) flags=0xb1 maxpwr=16 passive=1, offset 48 adding chan 140 (5700MHz) flags=0xb1 maxpwr=16 passive=1, offset 49 power group 0: chan=1 maxpwr=48 temp=-191 sample 0: index=13 power=43 sample 1: index=29 power=32 sample 2: index=47 power=12 sample 3: index=58 power=1 sample 4: index=77 power=-17 power group 1: chan=44 maxpwr=51 temp=-195 sample 0: index=12 power=43 sample 1: index=19 power=36 sample 2: index=32 power=23 sample 3: index=43 power=13 sample 4: index=77 power=-20 power group 2: chan=64 maxpwr=50 temp=-194 sample 0: index=12 power=43 sample 1: index=20 power=36 sample 2: index=33 power=24 sample 3: index=44 power=14 sample 4: index=77 power=-17 power group 3: chan=116 maxpwr=46 temp=-192 sample 0: index=12 power=33 sample 1: index=20 power=24 sample 2: index=36 power=8 sample 3: index=48 power=-2 sample 4: index=77 power=-29 power group 4: chan=153 maxpwr=44 temp=-191 sample 0: index=10 power=32 sample 1: index=20 power=20 sample 2: index=32 power=8 sample 3: index=42 power=0 sample 4: index=77 power=-31 wpi0: Regulatory Domain: MoW2 wpi0: Hardware Type: B wpi0: Hardware Revision: ? wpi0: SKU does support 802.11a wpi0: [ITHREAD] pcib3: irq 18 at device 28.2 on pci0 pci24: on pcib3 pci0:24:0:0: failed to read VPD data. bge0: mem 0xe4000000-0xe400ffff irq 18 at device 0.0 on pci24 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:1a:4b:66:1b:0e bge0: [ITHREAD] pcib4: irq 16 at device 28.4 on pci0 pci40: on pcib4 uhci2: port 0x4060-0x407f irq 20 at device 29.0 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus3: on uhci2 uhci3: port 0x4080-0x409f irq 21 at device 29.1 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus4: on uhci3 uhci4: port 0x40a0-0x40bf irq 18 at device 29.2 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 ehci1: mem 0xe4508000-0xe45083ff irq 20 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib5: at device 30.0 on pci0 pci2: on pcib5 cbb0: mem 0xe4200000-0xe4200fff irq 16 at device 4.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x40c0-0x40cf irq 16 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x13f0-0x13f7,0x15f4-0x15f7,0x1370-0x1377,0x1574-0x1577,0x4100-0x411f mem 0xe4509000-0xe45097ff irq 17 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI called from vendor specific driver atapci1: AHCI Version 01.10 controller with 3 ports PM not supported ata2: on atapci1 ata2: [ITHREAD] battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 acpi_tz3: on acpi0 acpi_tz3: _CRT value is absurd, ignored (256.0C) acpi_tz4: on acpi0 atrtc0: port 0x70-0x71,0x72-0x73 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Synaptics Touchpad, device ID 3 ppc0: port 0x378-0x37f,0x778-0x77a irq 7 drq 1 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 10.000 msec ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based forwarding enabled, default to deny, logging limited to 20 packets/entry by default usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 acd0: DVDR at ata0-master PIO4 ad4: 152627MB at ata2-master SATA150 hdac0: HDA Codec #0: Analog Devices AD1981HD hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown) pcm0: at cad 0 nid 1 on hdac0 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). GEOM_LABEL: Label for provider ad4s1a is ufsid/49e9bbedb8fda52e. GEOM_JOURNAL: Journal 1268608653: ad4s1d contains journal. GEOM_JOURNAL: Journal 267406393: ad4s1e contains journal. GEOM_LABEL: Label for provider ad4s1f is ufsid/49e9bbedc9aaa62a. GEOM_JOURNAL: Journal 1268608653: ad4s1g contains data. GEOM_LABEL: Label for provider ad4s1g is ufsid/49e9bbee67fce2f3. GEOM_JOURNAL: Journal ad4s1g consistent. GEOM_JOURNAL: Journal 267406393: ad4s1h contains data. GEOM_LABEL: Label for provider ad4s1h is ufsid/49e9bbed0b0f22ca. GEOM_JOURNAL: Journal ad4s1h consistent. GEOM_JOURNAL: Journal 3676591063: ad4s3d contains journal. GEOM_JOURNAL: Journal 3676591063: ad4s3e contains data. GEOM_LABEL: Label for provider ad4s3e is ufsid/49ea306910707f00. GEOM_JOURNAL: Journal ad4s3e consistent. Root mount waiting for: usbus6 usbus2 uhub2: 4 ports with 4 removable, self powered uhub6: 6 ports with 6 removable, self powered Root mount waiting for: usbus6 Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 (probe0:ata0:0:0:0): Medium not present (probe0:ata0:0:0:0): Unretryable error cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present ugen3.2: at usbus3 GEOM_LABEL: Label ufsid/49e9bbedb8fda52e removed. GEOM_LABEL: Label for provider ad4s1a is ufsid/49e9bbedb8fda52e. GEOM_LABEL: Label ufsid/49e9bbedb8fda52e removed. WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. tap0: Ethernet address: 00:bd:45:04:00:00 tap1: Ethernet address: 00:bd:45:04:00:01 tap2: Ethernet address: 00:bd:46:04:00:02 tap3: Ethernet address: 00:bd:47:04:00:03 tap4: Ethernet address: 00:bd:47:04:00:04 tap5: Ethernet address: 00:bd:48:04:00:05 wlan0: Ethernet address: 00:1b:77:c0:a1:16 lock order reversal: 1st 0xda0f5340 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2555 2nd 0xc66d7000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 KDB: stack backtrace: db_trace_self_wrapper(c091d5a4,e901c778,c0634285,c062618b,c09203b9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c062618b,c09203b9,c6122bb8,c6126500,e901c7d4,...) at kdb_backtrace+0x29 _witness_debugger(c09203b9,c66d7000,c0942631,c6126500,c09422ca,...) at _witness_debugger+0x25 witness_checkorder(c66d7000,9,c09422ca,113,0,...) at witness_checkorder+0x839 _sx_xlock(c66d7000,0,c09422ca,113,c66e3d24,...) at _sx_xlock+0x85 ufsdirhash_acquire(da0f52e0,e901c8ec,10c,da62f910,e901c8a4,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c66e3d24,e901c8ec,910,e901c890,e901c894,...) at ufsdirhash_add+0x13 ufs_direnter(c644c96c,c697d96c,e901c8ec,e901cbd4,0,...) at ufs_direnter+0x729 ufs_makeinode(e901cbd4,0,e901cacc,e901ca34,c08bcab5,...) at ufs_makeinode+0x4af ufs_create(e901cacc,e901cae4,0,0,e901cba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0993e40,e901cacc,2,c0912cef,3,...) at VOP_CREATE_APV+0xa5 vn_open_cred(e901cba8,e901cc5c,1a4,c613b900,c66f2b98,...) at vn_open_cred+0x19e vn_open(e901cba8,e901cc5c,1a4,c66f2b98,281a1000,...) at vn_open+0x33 kern_openat(c6973480,ffffff9c,80516e0,0,602,...) at kern_openat+0x108 kern_open(c6973480,80516e0,0,601,1b6,...) at kern_open+0x35 open(c6973480,e901ccf8,c,c,c09734b8,...) at open+0x30 syscall(e901cd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x28165fb3, esp = 0xbfbfeb1c, ebp = 0xbfbfeb58 --- WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] ugen3.3: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 ukbd_set_leds_callback:554: error=USB_ERR_STALLED ums0: on usbus3 ums0: 3 buttons and [XYZ] coordinates ID=1 --- <> --- [root@beastie][/var/crash]kgdb /boot/kernel.debug/kernel.symbols /var/crash/vmcore.8 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 conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex uhci3 (uhci3) r = 0 (0xc63bae4c) locked @ /usr/src/sys/dev/usb/usb_request.c:104 exclusive sleep mutex USB device mutex (USB device mutex) r = 0 (0xc615c050) locked @ /usr/src/sys/dev/usb/usb_transfer.c:1826 KDB: stack backtrace: db_trace_self_wrapper(c091d5a4,e6cfcb10,c0634285,c090e306,722,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c090e306,722,ffffffff,c0b02d7c,e6cfcb48,...) at kdb_backtrace+0x29 _witness_debugger(c091f965,e6cfcb5c,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0950f99,110,c642c6c0,...) at witness_warn+0x1fd trap(e6cfcbe8) at trap+0x153 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc05675f7, esp = 0xe6cfcc28, ebp = 0xe6cfcc54 --- usb2_do_clear_stall_callback(c6d99568,ffffffff,c090e306,9b2,c0b02d78,...) at usb2_do_clear_stall_callback+0xd7 usb2_callback_wrapper(c6d99030,723,0,c6d99000,c6d99000,...) at usb2_callback_wrapper+0x607 usb2_command_wrapper(c6d99030,0,c090e306,723,c6d99044,...) at usb2_command_wrapper+0x116 usb2_callback_proc(c6d99044,c63bae4c,c090de6c,51,c09c6680,...) at usb2_callback_proc+0x98 usb2_process(c63bada4,e6cfcd38,c0915da6,336,c661c2a4,...) at usb2_process+0xde fork_exit(c05654e0,c63bada4,e6cfcd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6cfcd70, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xdeadc0e0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05675f7 stack pointer = 0x28:0xe6cfcc28 frame pointer = 0x28:0xe6cfcc54 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 35 (usbus4) panic: from debugger cpuid = 1 KDB: stack backtrace: panic: vm_fault: fault on nofault entry, addr: deadc000 cpuid = 1 KDB: enter: panic Uptime: 24m39s Physical memory: 3051 MB Dumping 200 MB: 185 169 153 137 121 105 89 73 57 41 25 9 Reading symbols from /boot/kernel.debug/geom_journal.ko...Reading symbols from /boot/kernel.debug/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/geom_journal.ko Reading symbols from /boot/kernel.debug/if_wpi.ko...Reading symbols from /boot/kernel.debug/if_wpi.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/if_wpi.ko Reading symbols from /boot/kernel.debug/snd_hda.ko...Reading symbols from /boot/kernel.debug/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/snd_hda.ko Reading symbols from /boot/kernel.debug/sound.ko...Reading symbols from /boot/kernel.debug/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/sound.ko Reading symbols from /boot/kernel.debug/tmpfs.ko...Reading symbols from /boot/kernel.debug/tmpfs.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/tmpfs.ko Reading symbols from /boot/kernel.debug/linprocfs.ko...Reading symbols from /boot/kernel.debug/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/linprocfs.ko Reading symbols from /boot/kernel.debug/linux.ko...Reading symbols from /boot/kernel.debug/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/linux.ko Reading symbols from /boot/kernel.debug/if_tap.ko...Reading symbols from /boot/kernel.debug/if_tap.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/if_tap.ko Reading symbols from /boot/kernel.debug/ng_btsocket.ko...Reading symbols from /boot/kernel.debug/ng_btsocket.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/ng_btsocket.ko Reading symbols from /boot/kernel.debug/netgraph.ko...Reading symbols from /boot/kernel.debug/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/netgraph.ko Reading symbols from /boot/kernel.debug/ng_bluetooth.ko...Reading symbols from /boot/kernel.debug/ng_bluetooth.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/ng_bluetooth.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /usr/local/modules/rtc.ko...done. Loaded symbols for /usr/local/modules/rtc.ko Reading symbols from /boot/kernel.debug/i915.ko...Reading symbols from /boot/kernel.debug/i915.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/i915.ko Reading symbols from /boot/kernel.debug/drm.ko...Reading symbols from /boot/kernel.debug/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel.debug/drm.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc05f34ce in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc05f37a2 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc084bf47 in vm_fault (map=0xc1490000, vaddr=3735928832, fault_type=Variable "fault_type" is not available. ) at /usr/src/sys/vm/vm_fault.c:283 #4 0xc08aefb7 in trap_pfault (frame=0xe6cfcbe8, usermode=0, eva=3735929056) at /usr/src/sys/i386/i386/trap.c:828 #5 0xc08af9e3 in trap (frame=0xe6cfcbe8) at /usr/src/sys/i386/i386/trap.c:521 #6 0xc0893d6b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc05675f7 in usb2_do_clear_stall_callback (xfer=0xc6d99568) at /usr/src/sys/dev/usb/usb_request.c:140 #8 0xc056a427 in usb2_callback_wrapper (pq=0xc6d99030) at /usr/src/sys/dev/usb/usb_transfer.c:1958 #9 0xc0567e16 in usb2_command_wrapper (pq=0xc6d99030, xfer=0x0) at /usr/src/sys/dev/usb/usb_transfer.c:2534 #10 0xc0567ef8 in usb2_callback_proc (_pm=0xc6d99044) at /usr/src/sys/dev/usb/usb_transfer.c:1830 #11 0xc05655be in usb2_process (arg=0xc63bada4) at /usr/src/sys/dev/usb/usb_process.c:139 #12 0xc05cd588 in fork_exit (callout=0xc05654e0 , arg=0xc63bada4, frame=0xe6cfcd38) at /usr/src/sys/kern/kern_fork.c:830 #13 0xc0893de0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 --- <> --- [silent@beastie][/home/silent]pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x30c0103c chip=0x2a008086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile PM965/GM965/GL960 Express Processor to DRAM Controller' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x030000 card=0x30c0103c chip=0x2a028086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 965 Express Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x30c0103c chip=0x2a038086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 965 Express Integrated Graphics Controller' class = display uhci0@pci0:0:26:0: class=0x0c0300 card=0x30c0103c chip=0x28348086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB uhci1@pci0:0:26:1: class=0x0c0300 card=0x30c0103c chip=0x28358086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB ehci0@pci0:0:26:7: class=0x0c0320 card=0x30c0103c chip=0x283a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '81EC1043 (?) ICH8 Enhanced USB2 Enhanced Host Controller' class = serial bus subclass = USB hdac0@pci0:0:27:0: class=0x040300 card=0x30c0103c chip=0x284b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H &SUBSYS_81EC1043&REV_02\3&11583659&0&D8' class = multimedia subclass = HDA pcib1@pci0:0:28:0: class=0x060400 card=0x30c0103c chip=0x283f8086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 1' class = bridge subclass = PCI-PCI pcib2@pci0:0:28:1: class=0x060400 card=0x30c0103c chip=0x28418086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 2' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:2: class=0x060400 card=0x30c0103c chip=0x28438086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 3' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:4: class=0x060400 card=0x30c0103c chip=0x28478086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 5' class = bridge subclass = PCI-PCI uhci2@pci0:0:29:0: class=0x0c0300 card=0x30c0103c chip=0x28308086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB uhci3@pci0:0:29:1: class=0x0c0300 card=0x30c0103c chip=0x28318086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB uhci4@pci0:0:29:2: class=0x0c0300 card=0x30c0103c chip=0x28328086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB ehci1@pci0:0:29:7: class=0x0c0320 card=0x30c0103c chip=0x28368086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB2 EHCI' class = serial bus subclass = USB pcib5@pci0:0:30:0: class=0x060401 card=0x30c0103c chip=0x24488086 rev=0xf3 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x30c0103c chip=0x28158086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'ICH8M-E (ICH8 Family) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x30c0103c chip=0x28508086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) Ultra ATA Storage Controllers' class = mass storage subclass = ATA atapci1@pci0:0:31:2: class=0x010601 card=0x30c0103c chip=0x28298086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801 Intel(R) 82801HEM/HBM SATA AHCI Controller' class = mass storage subclass = SATA wpi0@pci0:16:0:0: class=0x028000 card=0x135c103c chip=0x42228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '10418086 Intel 3945ABG Wireless LAN controller' class = network bge0@pci0:24:0:0: class=0x020000 card=0x30c0103c chip=0x169314e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM 5787A Ethernet Controller Broadcom Netlink Gigabit' class = network subclass = ethernet cbb0@pci0:2:4:0: class=0x060700 card=0x30c0103c chip=0x04761180 rev=0xb6 hdr=0x02 vendor = 'Ricoh Company, Ltd.' device = 'unknown Ricoh R/RL/5C476(II)' class = bridge subclass = PCI-CardBus -- WBR, Andrey From cswiger at mac.com Mon May 11 21:37:27 2009 From: cswiger at mac.com (Chuck Swiger) Date: Mon May 11 21:37:34 2009 Subject: Fighting for the power. [syslogd] In-Reply-To: <4A0886F0.6030605@freebsd.org> References: <49FE1826.4060000@FreeBSD.org> <49FE29A4.30507@root.org> <49FE5EC8.3040205@FreeBSD.org> <20090505091914.GA94521@server.vk2pj.dyndns.org> <4A00669A.10105@freebsd.org> <4A0886F0.6030605@freebsd.org> Message-ID: On May 11, 2009, at 1:13 PM, Sam Leffler wrote: >> You can use -l flag to syslogd to create additional logging sockets >> under your chroot'ed filesystem tree, similar to the way named & >> ntpd uses it; see syslogd_precmd() in /etc/rc.d/syslogd.... >> > > Blech, thanks. That might be a stopgap solution but it still > doesn't allow syslogd to be started earlier which is what is needed > for many/most setups. Something that's imperfect but available today is much more usable than the perfect solution tomorrow. :-) > syslogd has mountcritremote as REQUIRE to handle diskless setups but > IMO this should be (at least) configurable. But rather than argue > this nonsense I think the better solution is to do what I suggest so > syslogd can be started very early and capture everything available > (e.g. your suggestion still loses msgs logged while setting up nfs > mounts). True. I'm not sure I'd really want to set up a machine such that critical filesystems depend upon wireless networking to be up before they can be mounted, but if you've really got something which needs to run before syslogd is allowed to run, then that something needs to be able to do it's own logging. Fortunately, it's not terribly hard to write some wrappers which will log either via syslog or to a file (or both, if needed): /* initialize logging to a file, via syslog, or both... */ void init_logging() { setlogfacility(syslog_level); if (enable_syslog) logmask |= LF_SYSLOG; else logmask &= ~LF_SYSLOG; if (logfile) logmask |= LF_LOGFILE; else logmask &= ~LF_LOGFILE; if (logmask & LF_SYSLOG) { openlog("myprogram", LOG_PID|LOG_CONS, fac); } if (debug) { syslog((fac | LOG_NOTICE), "logging subsystem started..."); setlogmask(LOG_UPTO(LOG_DEBUG)); } else { if (verbose > 1) setlogmask(LOG_UPTO(LOG_DEBUG)); else setlogmask(LOG_UPTO(LOG_INFO)); } } if ((logmask & LF_LOGFILE) && logfile) { if ((ofp = fopen(logfile, "a+")) == NULL) { fprintf(stderr, "Fatal Error: unable to open and append to logfile '%s'.\n", logfile); terminate(EX_CANTCREAT); } } else if (debug) { ofp = stdout; } } /* output a message to syslog and/or the logfile/stdout */ void logdebug(char *message) { if (message == NULL) message = strerror(errno); if (logmask & LF_SYSLOG) syslog((fac | LOG_DEBUG), "%s", message); if (ofp) { fputs(message, ofp); fflush(ofp); } } [ ...repeat for loginfo(), logwarn(), etc... ] The above is triggered off of getopt() parsing flags and setting enable_syslog and/or logfile variables, but you could check whether a syslogd socket is available to scribble to or not, and decide for yourself to do your own logging to a file or not. Come to think of it, are you familiar with sending LOG_CONS to openlog()? Perhaps that would be a reasonable compromise, as you wouldn't need to move over to logging via a wrapper rather than calling syslog() directly.... Regards, -- -Chuck From tinderbox at freebsd.org Mon May 11 21:42:44 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon May 11 21:42:57 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <20090511214241.03B367302F@freebsd-current.sentex.ca> TB --- 2009-05-11 20:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-11 20:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-05-11 20:40:00 - cleaning the object tree TB --- 2009-05-11 20:40:46 - cvsupping the source tree TB --- 2009-05-11 20:40:46 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-05-11 20:40:57 - building world TB --- 2009-05-11 20:40:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-11 20:40:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-11 20:40:57 - TARGET=arm TB --- 2009-05-11 20:40:57 - TARGET_ARCH=arm TB --- 2009-05-11 20:40:57 - TZ=UTC TB --- 2009-05-11 20:40:57 - __MAKE_CONF=/dev/null TB --- 2009-05-11 20:40:57 - cd /src TB --- 2009-05-11 20:40:57 - /usr/bin/make -B buildworld >>> World build started on Mon May 11 20:41:00 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -std=gnu99 -c /src/usr.bin/mail/vars.c cc -O -pipe -std=gnu99 -o mail version.o cmd1.o cmd2.o cmd3.o cmdtab.o collect.o edit.o fio.o getname.o head.o v7.local.o lex.o list.o main.o names.o popen.o quit.o send.o strings.o temp.o tty.o util.o vars.o gzip -cn /src/usr.bin/mail/mail.1 > mail.1.gz ===> usr.bin/make (all) cc -O -pipe -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/arch.c cc1: warnings being treated as errors /src/usr.bin/make/arch.c: In function 'Arch_ParseArchive': /src/usr.bin/make/arch.c:402: warning: the address of 'members' will never be NULL *** Error code 1 Stop in /src/usr.bin/make. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-11 21:42:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-11 21:42:40 - ERROR: failed to build world TB --- 2009-05-11 21:42:40 - 2860.98 user 355.03 system 3760.12 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Mon May 11 21:59:12 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon May 11 21:59:19 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090511215909.E04B67302F@freebsd-current.sentex.ca> TB --- 2009-05-11 20:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-11 20:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-05-11 20:40:00 - cleaning the object tree TB --- 2009-05-11 20:41:19 - cvsupping the source tree TB --- 2009-05-11 20:41:19 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-05-11 20:41:27 - building world TB --- 2009-05-11 20:41:27 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-11 20:41:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-11 20:41:27 - TARGET=amd64 TB --- 2009-05-11 20:41:27 - TARGET_ARCH=amd64 TB --- 2009-05-11 20:41:27 - TZ=UTC TB --- 2009-05-11 20:41:27 - __MAKE_CONF=/dev/null TB --- 2009-05-11 20:41:27 - cd /src TB --- 2009-05-11 20:41:27 - /usr/bin/make -B buildworld >>> World build started on Mon May 11 20:41:30 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.bin/mail/vars.c cc -O2 -pipe -std=gnu99 -fstack-protector -o mail version.o cmd1.o cmd2.o cmd3.o cmdtab.o collect.o edit.o fio.o getname.o head.o v7.local.o lex.o list.o main.o names.o popen.o quit.o send.o strings.o temp.o tty.o util.o vars.o gzip -cn /src/usr.bin/mail/mail.1 > mail.1.gz ===> usr.bin/make (all) cc -O2 -pipe -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/arch.c cc1: warnings being treated as errors /src/usr.bin/make/arch.c: In function 'Arch_ParseArchive': /src/usr.bin/make/arch.c:402: warning: the address of 'members' will never be NULL *** Error code 1 Stop in /src/usr.bin/make. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-11 21:59:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-11 21:59:09 - ERROR: failed to build world TB --- 2009-05-11 21:59:09 - 3610.87 user 369.91 system 4749.23 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From fbsdlist at src.cx Mon May 11 22:52:04 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Mon May 11 22:52:11 2009 Subject: pointyhat panic In-Reply-To: <1242075474.72992.118.camel@hood.oook.cz> References: <1242075474.72992.118.camel@hood.oook.cz> Message-ID: Last Friday I've got a crash in sowakeup as well, though the stack trace looks different. I'm unable to reproduce it, but I do have core saved, if someone wants me to do some post-mortem investigation. Box is quad-core amd64 running -current as of May 8th. The crash was observed when I attempted to interrupt parallel make that did access fair amount of stuff over NFS. --Artem Tracing pid 12 tid 100012 td 0xffffff0004460390 _mtx_lock_sleep() at _mtx_lock_sleep+0x4e clnt_dg_soupcall() at clnt_dg_soupcall+0x168 sowakeup() at sowakeup+0xd9 udp_append() at udp_append+0x20b udp_input() at udp_input+0x6b5 ip_input() at ip_input+0xaa swi_net() at swi_net+0xf7 intr_event_execute_handlers() at intr_event_execute_handlers+0x100 ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffff800063d40, rbp = 0 --- 2009/5/11 Pav Lucistnik : > panic: mtx_lock() of destroyed mutex @ /usr/src/sys/rpc/clnt_vc.c:953 > cpuid = 2 > KDB: enter: panic > [thread pid 0 tid 100029 ] > Stopped at ? ? ?kdb_enter+0x3d: movq ? ?$0,0x3f5fb8(%rip) > db> bt > Tracing pid 0 tid 100029 td 0xffffff00018e1000 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > _mtx_lock_flags() at _mtx_lock_flags+0xc5 > clnt_vc_soupcall() at clnt_vc_soupcall+0x273 > sowakeup() at sowakeup+0xf8 > tcp_do_segment() at tcp_do_segment+0x23c9 > tcp_input() at tcp_input+0x9ec > ip_input() at ip_input+0xbc > ether_demux() at ether_demux+0x1ed > ether_input() at ether_input+0x171 > em_rxeof() at em_rxeof+0x201 > em_handle_rxtx() at em_handle_rxtx+0x4b > taskqueue_run() at taskqueue_run+0x96 > taskqueue_thread_loop() at taskqueue_thread_loop+0x3f > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffffff240a6d40, rbp = 0 --- > > The box is in kdb on serial console for now. May 9 -CURRENT, I think. > > -- > Pav Lucistnik > ? ? ? ? ? ? ? > A spoonful of curry, garlic and mustard helps the medicine go down... > and come straight back up again. -- JLE on #angband > From kmacy at freebsd.org Mon May 11 23:06:18 2009 From: kmacy at freebsd.org (Kip Macy) Date: Mon May 11 23:06:25 2009 Subject: pointyhat panic In-Reply-To: References: <1242075474.72992.118.camel@hood.oook.cz> Message-ID: <3c1674c90905111606g2205674bpa34808e761ab08d8@mail.gmail.com> yup this is a residual issue with the new rpc stuff - so_upcall locking is somewhat deficient On Mon, May 11, 2009 at 2:37 PM, Artem Belevich wrote: > Last Friday I've got a crash in sowakeup as well, though the stack > trace looks different. I'm unable to reproduce it, but I do have core > saved, if someone wants me to do some post-mortem investigation. Box > is quad-core amd64 running -current as of May 8th. The crash was > observed when I attempted to interrupt parallel make that did access > fair amount of stuff over NFS. > > --Artem > > Tracing pid 12 tid 100012 td 0xffffff0004460390 > _mtx_lock_sleep() at _mtx_lock_sleep+0x4e > clnt_dg_soupcall() at clnt_dg_soupcall+0x168 > sowakeup() at sowakeup+0xd9 > udp_append() at udp_append+0x20b > udp_input() at udp_input+0x6b5 > ip_input() at ip_input+0xaa > swi_net() at swi_net+0xf7 > intr_event_execute_handlers() at intr_event_execute_handlers+0x100 > ithread_loop() at ithread_loop+0x8e > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xfffffff800063d40, rbp = 0 --- > > > 2009/5/11 Pav Lucistnik : >> panic: mtx_lock() of destroyed mutex @ /usr/src/sys/rpc/clnt_vc.c:953 >> cpuid = 2 >> KDB: enter: panic >> [thread pid 0 tid 100029 ] >> Stopped at ? ? ?kdb_enter+0x3d: movq ? ?$0,0x3f5fb8(%rip) >> db> bt >> Tracing pid 0 tid 100029 td 0xffffff00018e1000 >> kdb_enter() at kdb_enter+0x3d >> panic() at panic+0x17b >> _mtx_lock_flags() at _mtx_lock_flags+0xc5 >> clnt_vc_soupcall() at clnt_vc_soupcall+0x273 >> sowakeup() at sowakeup+0xf8 >> tcp_do_segment() at tcp_do_segment+0x23c9 >> tcp_input() at tcp_input+0x9ec >> ip_input() at ip_input+0xbc >> ether_demux() at ether_demux+0x1ed >> ether_input() at ether_input+0x171 >> em_rxeof() at em_rxeof+0x201 >> em_handle_rxtx() at em_handle_rxtx+0x4b >> taskqueue_run() at taskqueue_run+0x96 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x3f >> fork_exit() at fork_exit+0x12a >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip = 0, rsp = 0xffffffff240a6d40, rbp = 0 --- >> >> The box is in kdb on serial console for now. May 9 -CURRENT, I think. >> >> -- >> Pav Lucistnik >> ? ? ? ? ? ? ? >> A spoonful of curry, garlic and mustard helps the medicine go down... >> and come straight back up again. -- JLE on #angband >> > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From doconnor at gsoft.com.au Mon May 11 23:10:13 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon May 11 23:10:26 2009 Subject: howto sidestep sysinstall during installation In-Reply-To: References: <200905112334.03387.doconnor@gsoft.com.au> Message-ID: <200905120840.02575.doconnor@gsoft.com.au> On Tue, 12 May 2009, Saifi Khan wrote: > On Mon, 11 May 2009, Daniel O'Connor wrote: > > > Putting out a monthly snapshot is nice and if the people are > > > going to not find info about 'Fixit#' and commands in the > > > legendary handbook, that is not very helpful. > > > > FreeBSD doesn't work this way, you are trying to fit FreeBSD into > > your Gentoo way of thinking. Obviously this causes pain, please > > stop. > > i'll be highly obliged, if you could share some nuggets of > wisdom on 'the FreeBSD way' ! Please. Like I said, install a release and upgrade that. You could try finding a -current snap that does work, but it's probably going to be quicker to just get the latest 7 release, install and then cvsup/csup to HEAD then build & install. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090511/46287cec/attachment.pgp From mav at FreeBSD.org Mon May 11 23:13:39 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 11 23:13:47 2009 Subject: Fighting for the power. In-Reply-To: <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> Message-ID: <4A08B10E.4040702@FreeBSD.org> Paul B. Mahol wrote: > On 5/11/09, Alexander Motin wrote: >> Tim Kientzle wrote: >>> I started to try the "hint.apic.0.clock", but noticed >>> in your commit r191720: >>> Alexander Motin wrote: >>>> Add hint.apic.0.clock tunable. Setting it 0 disables using >>>> LAPIC timers as hard-/stat-/profclock sources falling back >>>> to using i8254 and rtc timers. >>>> ... >>>> This technique is not working for SMP yet, as only one CPU >>>> receives timer interrupts. But I think that problem could >>>> be fixed by forwarding interrupts to other CPUs with IPI. >>> Is anyone looking at this yet? >> I have implemented SMP support for i386 and amd64 in some of my later >> commits. > > And all those hacks helps verry little in my case, most gain I get when > laptop monitor is switched off. Even switching hard disk off improves battery > life very little. Monitor is surely one of major power consumers, but there are not so much things which you can do about it, as without power there will be no backlight. All you can do is tune backlight to minimum level required in every specific situation. What's about general effect, the main idea here is the same as in audio processing: result mostly depends on quality of the worst component. Your system may just have some other consumers which I don't have. For example, desktop CPU instead of mobile, desktop chipset instead of mobile, powerful external video instead of (or even in addition to) built-in, and so on. -- Alexander Motin From glen.j.barber at gmail.com Tue May 12 03:48:46 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Tue May 12 03:48:52 2009 Subject: LOR Reporting Message-ID: <4ad871310905112021s32a803b9h5257840b2d46fa14@mail.gmail.com> Hi, list. I see occasional reports about lock order reversals on this list and was wondering when it is appropriate to report them. Obviously, there must be something going on, but I don't want to unnecessarily post what may not be a problem. What are the "best practices" on this, if any? Thanks. -- Glen Barber From swhetzel at gmail.com Tue May 12 04:34:42 2009 From: swhetzel at gmail.com (Scot Hetzel) Date: Tue May 12 04:34:49 2009 Subject: LOR Reporting In-Reply-To: <4ad871310905112021s32a803b9h5257840b2d46fa14@mail.gmail.com> References: <4ad871310905112021s32a803b9h5257840b2d46fa14@mail.gmail.com> Message-ID: <790a9fff0905112134v3d444213k9a42da6ceb2a8313@mail.gmail.com> On 5/11/09, Glen Barber wrote: > Hi, list. > > I see occasional reports about lock order reversals on this list and > was wondering when it is appropriate to report them. Obviously, there > must be something going on, but I don't want to unnecessarily post > what may not be a problem. > > What are the "best practices" on this, if any? > Before reporting any LOR's check this site for instructions on reporting them: http://sources.zabbadoz.net/freebsd/lor.html Scot From jdl at jdl.com Tue May 12 05:18:00 2009 From: jdl at jdl.com (Jon Loeliger) Date: Tue May 12 05:18:07 2009 Subject: LOR Reporting In-Reply-To: <4ad871310905112021s32a803b9h5257840b2d46fa14@mail.gmail.com> References: <4ad871310905112021s32a803b9h5257840b2d46fa14@mail.gmail.com> Message-ID: > Hi, list. > > I see occasional reports about lock order reversals on this list and > was wondering when it is appropriate to report them. Obviously, there > must be something going on, but I don't want to unnecessarily post > what may not be a problem. > > What are the "best practices" on this, if any? > > Thanks. I've recently learned that reading this: http://sources.zabbadoz.net/freebsd/lor.html is at least a good start. jdl From m.e.sanliturk at gmail.com Tue May 12 05:47:53 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Tue May 12 05:48:00 2009 Subject: Installation of FreeBSD 8.0-Current-2009-amd64-dvd In-Reply-To: <4A088642.3030402@freebsd.org> References: <4A04EA46.20106@freebsd.org> <4A088642.3030402@freebsd.org> Message-ID: On Mon, May 11, 2009 at 4:10 PM, Tim Kientzle wrote: > Mehmet Erol Sanliturk wrote: > >> >> I know that current snapshots should not be used in any production >> purposes >> . >> >> My intention was only to install it , run some programs , and if I get a >> feeling that supplying an information to current developers may be useful >> to >> send an e-mail about my experiences . >> >> I think such installation and test results would be useful to current >> developers if I am not wrongly assumed that . >> > > Feedback is always appreciated. > > If you'd like to work with -CURRENT, you should > definitely learn how to use the FreeBSD "ports" > system, which builds third-party software from > source. As I mentioned earlier, "packages" are not > always available for -CURRENT. > > The FreeBSD -CURRENT snapshot DVDs are actually a pretty > tough place to start. They are automatically generated > from whatever happens to be in SVN that day; as a result, > they're mostly useful as a regular test of the release-building > scripts and somewhat useful for testing the installer. For > testing the rest of the system, I suggest that you learn > how to update the core system from source code. There are > quite a few articles and blog posts explaining how to do > this. It also helps to watch the freebsd-current mailing > list so you know when things are relatively calm. > > Tim Personally I would be very happy to be able to contribute to development of FreeBSD as much as possible . Up to now I could not be able to establish a working system as a network which is suitable for my needs , but I am working toward this . Actually my expertise is not on operating systems but I want to learn as much as possible . My main ideas are as follows : (1) There is Tinderbox . Its messages are coming to me regularly . A similar system my be established for the development of current FreeBSD . As an example , I want to mention other operating systems : Debian : When an update is available an icon is appearing and saying that an update is available . When it is accepted the update is applied . At present my Debian 5.0.0 is up to date in that way . In the following sentences 8.0 is used as having X.x Current for any Current version . Assume that we installed 8.0 Current and we want to participate in its development . We are not sufficiently experts to manage details . A system installed with our 8.0 Current may manage these issues . When a part is modified and it requires a test , all of the participating related systems may be notified by the automatic testing system . If we accept by clicking okay (or even automatically if we set it in that way like Windows updates which my Windows XP Home is updated in that way ) the new parts are downloaded and executed and a report is send back ( We know that such executions my crash our computer , but we know that we are trying to help to develop the FreeBSD and such crashes are possible and our 8.0 Current is NOT for a production use ) . FreeBSD developers by analyzing these reports may obtain a good profile of effect about the new modification and they will be able to test their works on hardware platforms that they do not have at hand . The only requirements will be that tests will not crash the complete installations at to the points that the system will not be even able to boot any more which it will not be able to send any message back about test results . As an example : In one of my Linux computer , to reclaim file space yesterday I wanted to delete a package ( an un-used text editor ) , it listed some other package names as related to be deleted ( without any explanation about their requirements and their names actually meaningless ) , I clicked yes to delete , it completely deleted operating system parts making the system completely unbootable , unable to rescue current contents , unable to upgrade the system by repair . Actually such a case is a good working clue to prevent such meaninless deletions paralyzing the operating system completely . Test result profiles may be distributed to users if they want to get such messages . Such a work may not be very difficult for the participating users because setting a testing partition consuming a sufficiently minimal amount of hard disk is easy in those days because hard disks are large per drive or a dedicated hard drive around 160 GB is around US $ 50 ( US dollars ) which I think many users would use such an option . In a multi-boot system , booting the 8.0 Current and applying tests and send reports back may not be difficult for the participating users ( at least they are willing to apply such steps ) . The hardest problem is to have such a testing environment . The present model is difficult to participate . It is very flexible , but requires much knowledge . To make it a more structured will reduce required amount of knowledge but will increase possible participation and back contribution . (2) Solutions to such problems may be very interesting project works for computing science students . Writing specifications and requirements and then opening it to academic environments may attract interest . I think one of the most important aspect is copyright and license of such specifications . BSD-styled copyrights and licenses will allow both instructors and students to work easily on such problems . In the wiki.freebsd.org ToDo page there are some problems to be worked on them . Opening a similar page in www. frebsd.org , and publishing more detailed specifications and requirements would be much contributory to improve the FreeBSD . As an an example : In here yesterday ( 2009 , May , 11 ) I saw a very interesting ToDo problem in wiki.freebsd.org about simulation of ( IBM , ... ) Cell BE processor . Porting its Linux sources to FreeBSD may be a very attractive project for computing science students . And seeing that result of their efforts are used in a production environment is another source of please . Thank you very much . Mehmet Erol Sanliturk From hselasky at c2i.net Tue May 12 06:40:40 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue May 12 06:40:47 2009 Subject: system panics on USB-mouse detachment In-Reply-To: <4A089216.1050701@gmail.com> References: <4A089216.1050701@gmail.com> Message-ID: <200905120843.12065.hselasky@c2i.net> On Monday 11 May 2009, Andrey wrote: > Andrey Hi Andrey, Thanks for reporting. I suspect the patch below will fix your problem: http://perforce.freebsd.org/chv.cgi?CH=161961 --HPS From gperez at entel.upc.edu Tue May 12 08:17:35 2009 From: gperez at entel.upc.edu (=?windows-1251?Q?Gustau_Pe=27rez?=) Date: Tue May 12 08:17:42 2009 Subject: system panics on USB-mouse detachment In-Reply-To: <200905120843.12065.hselasky@c2i.net> References: <4A089216.1050701@gmail.com> <200905120843.12065.hselasky@c2i.net> Message-ID: <4A093013.1080504@entel.upc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Hi Andrey, > > Thanks for reporting. I suspect the patch below will fix your problem: > > http://perforce.freebsd.org/chv.cgi?CH=161961 > Hi, I was having the same problem and I was about to send a trace when I saw your response. I tried the patch and fixed the problem with unplugging usb mouse. Regards, Gus - -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJMBMACgkQAvcpDulVChAgjwCfdeM0VndeN4kfmmoMUlt4f1uV zp8AnRQ84tzi3sda1rUAgpCz32zK3KZW =3wTd -----END PGP SIGNATURE----- From marck at rinet.ru Tue May 12 10:09:29 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Tue May 12 10:09:38 2009 Subject: newsyslog(8) patch for both size and time checks Message-ID: Dear colleagues, for now, if log is configured to be rotated in time manner, its size is not checked, so /var/log may be DoSed by some service (in our case, it was mad DHCP client which fills up our /var/log with dhcpd log; our newsyslog.conf line was /var/log/dhcpd 640 5 5000 @T00 JC The following simple patch should fix the problem. Any objection to commit this? Thanks. Index: usr.sbin/newsyslog/newsyslog.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.c,v retrieving revision 1.107.2.1 diff -u -r1.107.2.1 newsyslog.c --- usr.sbin/newsyslog/newsyslog.c 8 Mar 2008 01:00:25 -0000 1.107.2.1 +++ usr.sbin/newsyslog/newsyslog.c 12 May 2009 09:48:00 -0000 @@ -466,7 +466,8 @@ printf("does not exist, skipped%s.\n", temp_reason); } } else { - if (ent->flags & CE_TRIMAT && !force && !rotatereq) { + if ((ent->trsize < 0 || ent->fsize < ent->trsize) && + ent->flags & CE_TRIMAT && !force && !rotatereq) { diffsecs = ptimeget_diff(timenow, ent->trim_at); if (diffsecs < 0.0) { /* trim_at is some time in the future. */ -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From knowtree at aloha.com Tue May 12 07:38:15 2009 From: knowtree at aloha.com (Gary Dunn) Date: Tue May 12 11:34:20 2009 Subject: Fighting for the power. In-Reply-To: <4A08B10E.4040702@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> Message-ID: <1242110455.2664.9.camel@slate01> On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: ... > > What's about general effect, the main idea here is the same as in audio > processing: result mostly depends on quality of the worst component. > Your system may just have some other consumers which I don't have. For > example, desktop CPU instead of mobile, desktop chipset instead of > mobile, powerful external video instead of (or even in addition to) > built-in, and so on. > Interesting point. Is there a power consumption benchmark for evaluating hardware for use with FreeBSD? -- Gary Dunn, Honolulu osp@aloha.com http://openslate.net/ http://e9erust.blogspot.com/ Sent from Slate001 From ccuiyyan at gmail.com Tue May 12 10:29:36 2009 From: ccuiyyan at gmail.com (=?GB2312?B?tN7R0mNjdWl5eWFuQHNpbmEuY29t?=) Date: Tue May 12 11:34:32 2009 Subject: Is there printk() in FreeBSD? Message-ID: <4451ccf20905120329x68e86081p90d0098ad5ea5d5b@mail.gmail.com> Dear all; A simple question: sometimes i need to print out some kernel address in FreeBSD kernel. And i know printk() can be used in Linux to print the message to dmesg, Is there some similar in FreeBSD? It seems that printk() cannot work in the FreeBSD kernel. And where can we find the output? in dmesg or somewhere else? Best Wishes! Yan From smithi at nimnet.asn.au Tue May 12 10:53:24 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue May 12 11:34:43 2009 Subject: Fighting for the power. In-Reply-To: <1242110455.2664.9.camel@slate01> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> <1242110455.2664.9.camel@slate01> Message-ID: <20090512182420.K46325@sola.nimnet.asn.au> On Mon, 11 May 2009, Gary Dunn wrote: > On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: > ... > > > > What's about general effect, the main idea here is the same as in audio > > processing: result mostly depends on quality of the worst component. > > Your system may just have some other consumers which I don't have. For > > example, desktop CPU instead of mobile, desktop chipset instead of > > mobile, powerful external video instead of (or even in addition to) > > built-in, and so on. > > > > Interesting point. Is there a power consumption benchmark for evaluating > hardware for use with FreeBSD? make buildworld, running on battery? :-) More seriously: thanks to Nate's earlier niggling, I've been thinking towards a richer set of power profiles than our {performance,economy} dichotomy for a while, both in terms of various different work/play and AC/battery scenarious, and re specific settings that may be more or less optimal for particular hardware, that could be distributed or advised as more of a basic working set rather than as a series of 'try this' hints. Many of the useful points Alexander makes apply to lots of recent kit, but perhaps not as applicably to some older machines - just one example being whether using C3 is likely to help or hinder, eg with the C3 quirks for (some) PIIX4 chipset variants that got some work last? year. I'm not a C programmer, so I've been thinking more towards inclusion as a deeper level of rc.conf variables and parsing of these by sh script, tweaking sysctls after the fashion of the present power_profile and its triggering by devd events. Some features of individual machine / scenario profiles could include min/max cpu freq settings, whether or not to use p4tcc/acpi_throttle, highest C-state, powerd high/low load shift up/down percentages, and perhaps whether or not to power-down (D3) various devices/subsystems .. Recent exposure to (debian etch) cpufreqd profiles provides a few more ideas, eg here are a few examples from its default cpufreqd.conf, noting that cpufreqd and friends are add-ons, not system components, in debian. # stay in performance mode for the first minutes [Rule] name=AC Off - High Power ac=off # (on/off) battery_interval=70-100 #exec_post=echo 5 > /proc/acpi/sony/brightness profile=Performance Low [/Rule] # conservative mode when not AC [Rule] name=AC Off - Medium Battery ac=off # (on/off) battery_interval=30-70 #exec_post=echo 3 > /proc/acpi/sony/brightness profile=Powersave High [/Rule] # conservative mode when not AC [Rule] name=AC Off - Low Battery ac=off # (on/off) battery_interval=0-30 #exec_post=echo 3 > /proc/acpi/sony/brightness profile=Powersave Low [/Rule] ## # Special Rules ## # CPU Too hot! [Rule] name=CPU Too Hot acpi_temperature=55-100 cpu_interval=50-100 profile=Performance Low [/Rule] # use performance mode if I'm watching a movie # I don't care for batteries! # But don't heat too much. [Rule] name=Movie Watcher programs=xine,mplayer,gmplayer battery_interval=0-100 acpi_temperature=0-60 cpu_interval=0-100 profile=Performance High [/Rule] cheers, Ian From mav at FreeBSD.org Tue May 12 11:45:14 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue May 12 11:45:21 2009 Subject: Fighting for the power. In-Reply-To: <1242110455.2664.9.camel@slate01> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> <1242110455.2664.9.camel@slate01> Message-ID: <4A096131.4040405@FreeBSD.org> Gary Dunn wrote: > On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: > ... >> What's about general effect, the main idea here is the same as in audio >> processing: result mostly depends on quality of the worst component. >> Your system may just have some other consumers which I don't have. For >> example, desktop CPU instead of mobile, desktop chipset instead of >> mobile, powerful external video instead of (or even in addition to) >> built-in, and so on. > > Interesting point. Is there a power consumption benchmark for evaluating > hardware for use with FreeBSD? It is difficult to speak about benchmark, as soon as we are talking about idle power. I think the first step evaluation could be made with vendor provided data, as it mostly depends on hardware. If vendor speaks about 2 hours on battery, then there is quite small probability to get much out of that system, as it looks mostly positioned as desktop and may have many desktop components. And opposite, system declaring 9 hours must support a lot of different power-saving technologies to reach it. -- Alexander Motin From rea-fbsd at codelabs.ru Tue May 12 11:48:43 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue May 12 11:48:51 2009 Subject: Is there printk() in FreeBSD? In-Reply-To: <4451ccf20905120329x68e86081p90d0098ad5ea5d5b@mail.gmail.com> References: <4451ccf20905120329x68e86081p90d0098ad5ea5d5b@mail.gmail.com> Message-ID: Tue, May 12, 2009 at 06:29:35PM +0800, ????ccuiyyan@sina.com wrote: > A simple question: sometimes i need to print out some kernel > address in FreeBSD kernel. And i know printk() can be used in > Linux to print the message to dmesg, Is there some similar in > FreeBSD? > > It seems that printk() cannot work in the FreeBSD kernel. Use plain printf(). > And where can we find the output? in dmesg or somewhere else? In the dmesg and in all (syslogged) destinations you had configured. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From rea-fbsd at codelabs.ru Tue May 12 11:50:11 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue May 12 11:50:19 2009 Subject: Is there printk() in FreeBSD? In-Reply-To: References: <4451ccf20905120329x68e86081p90d0098ad5ea5d5b@mail.gmail.com> Message-ID: Tue, May 12, 2009 at 03:48:38PM +0400, Eygene Ryabinkin wrote: > Tue, May 12, 2009 at 06:29:35PM +0800, ????ccuiyyan@sina.com wrote: > > > A simple question: sometimes i need to print out some kernel > > address in FreeBSD kernel. And i know printk() can be used in > > Linux to print the message to dmesg, Is there some similar in > > FreeBSD? > > > > It seems that printk() cannot work in the FreeBSD kernel. > > Use plain printf(). By the way, there is device_printf (man 9 device_printf) that is a bit prettier than the plain printf, so you can use it as well. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From krassi at bulinfo.net Tue May 12 12:06:19 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Tue May 12 12:06:26 2009 Subject: Is there printk() in FreeBSD? In-Reply-To: <4451ccf20905120329x68e86081p90d0098ad5ea5d5b@mail.gmail.com> References: <4451ccf20905120329x68e86081p90d0098ad5ea5d5b@mail.gmail.com> Message-ID: <4A0961D1.1010503@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You can use printf or device_printf. See man 9 device_printf ??ccuiyyan@sina.com wrote: > Dear all; > > A simple question: sometimes i need to print out some kernel > > address in FreeBSD kernel. And i know printk() can be used in > > Linux to print the message to dmesg, Is there some similar in > FreeBSD? > > It seems that printk() cannot work in the FreeBSD kernel. And > > where can we find the output? in dmesg or somewhere else? > > Best Wishes! > > Yan > _______________________________________________ > 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" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFKCWHRxJBWvpalMpkRAu41AJ4x9mI2AHvgAyn16fY8OB7LEnuMBACgo+XJ S/FaTNIouZtd/LsTa2t6lAw= =D4TH -----END PGP SIGNATURE----- From rodrigo at bebik.net Tue May 12 12:07:08 2009 From: rodrigo at bebik.net (Rodrigo OSORIO (ros)) Date: Tue May 12 12:07:14 2009 Subject: Is there printk() in FreeBSD? In-Reply-To: <4451ccf20905120329x68e86081p90d0098ad5ea5d5b@mail.gmail.com> References: <4451ccf20905120329x68e86081p90d0098ad5ea5d5b@mail.gmail.com> Message-ID: <20090512114946.GA79236@hodja.bebik.net> On 12/05/09 18:29 +0800, ????ccuiyyan@sina.com wrote: > Dear all; > > A simple question: sometimes i need to print out some kernel > > address in FreeBSD kernel. And i know printk() can be used in > > Linux to print the message to dmesg, Is there some similar in > FreeBSD? > > It seems that printk() cannot work in the FreeBSD kernel. And > > where can we find the output? in dmesg or somewhere else? > > Best Wishes! > > Yan > _______________________________________________ > 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" Hi Please check the printf(9) to how to print messages in kernel code : http://www.freebsd.org/cgi/man.cgi?query=printf&apropos=0&sektion=9&manpath=FreeBSD+7.2-RELEASE&format=html Regards - Rodrigo From gavin at FreeBSD.org Tue May 12 12:54:34 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue May 12 12:54:41 2009 Subject: newsyslog(8) patch for both size and time checks In-Reply-To: References: Message-ID: <1242132870.5455.9.camel@buffy.york.ac.uk> On Tue, 2009-05-12 at 13:59 +0400, Dmitry Morozovsky wrote: > Dear colleagues, > > for now, if log is configured to be rotated in time manner, its size is not > checked, so /var/log may be DoSed by some service (in our case, it was mad DHCP > client which fills up our /var/log with dhcpd log; our newsyslog.conf line was > > /var/log/dhcpd 640 5 5000 @T00 JC > > The following simple patch should fix the problem. Any objection to commit > this? Short answer: I believe you will find this patch breaks some newsyslog functionality. I can't remember what the problems are, but that patch is pretty similar to my first attempt at fixing the problem too. The patch I ended up creating is at http://people.freebsd.org/~gavin/PRs/100018.diff (and a PR where somebody else requested this functionality is bin/100018). Gavin From 000.fbsd at quip.cz Tue May 12 13:23:44 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue May 12 13:23:52 2009 Subject: newsyslog(8) patch for both size and time checks In-Reply-To: References: Message-ID: <4A097857.5040007@quip.cz> Dmitry Morozovsky wrote: > Dear colleagues, > > for now, if log is configured to be rotated in time manner, its size is not > checked, so /var/log may be DoSed by some service (in our case, it was mad DHCP > client which fills up our /var/log with dhcpd log; our newsyslog.conf line was > > /var/log/dhcpd 640 5 5000 @T00 JC > > The following simple patch should fix the problem. Any objection to commit > this? I can't judged the patch, but I am +1 for this functionality. Miroslav Lachman From jhb at freebsd.org Tue May 12 15:48:14 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue May 12 15:48:36 2009 Subject: [patch] corrupt memstat_kvm_malloc(3) output and dtrace In-Reply-To: References: <9A637B27-7C89-49BA-8385-A5B2D5D54BB3@wanderview.com> Message-ID: <200905121028.58998.jhb@freebsd.org> On Wednesday 06 May 2009 1:00:09 am Ben Kelly wrote: > On May 5, 2009, at 10:18 AM, Ben Kelly wrote: > > While debugging a problem recently with Alexander Leidinger we > > noticed that crashinfo(8) was producing corrupt vmstat -m output. > > After doing some digging it appears that memstat_kvm_malloc(3) might > > have been broken by this commit: > > > > http://svn.freebsd.org/viewvc/base?view=revision&revision=179222 > > > > The problem is that memstat_kvm_malloc(3) assumes that > > malloc_type_internal starts with an array of malloc_types_stats > > structures. This assumption is no longer true, though, as > > mti_probes was inserted at the start of the structure. > > > > It appears that this (untested) patch might fix the problem: > > > > http://www.wanderview.com/svn/public/misc/zfs/vmstat_kvm_malloc.diff > > > > I'm not very familiar with dtrace, though. Does anyone know if this > > would cause problems? > > Just FYI, I was able to recompile and test this patch tonight. It > seems to have fixed vmstat -M $core -m output on my machine. I think that it would be better to update memstat_kvm_malloc(3) though. I'm also curious why libmemstat isn't just using malloc_types_internal directly. -- John Baldwin From mel.flynn+fbsd.current at mailing.thruhere.net Tue May 12 16:53:13 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Tue May 12 16:53:20 2009 Subject: Feedback and Questions Updating to CURRENT In-Reply-To: References: <87vdo8powi.fsf@kobe.laptop> Message-ID: <200905121853.09947.mel.flynn+fbsd.current@mailing.thruhere.net> On Monday 11 May 2009 02:29:38 Jon Loeliger wrote: > > pkgdb -Fu && portupgrade -fa > > > > or: > > > > portmaster -fa > > And confusingly here, there's no indication as to why I might > pick one or the other, nor the pros and cons of either, nor > if having picked one, I could use the other later. portmaster is superior when crossing major release boundaries as it has no dependencies other then /bin/sh, while portupgrade uses ruby and bdb. > A "use the defaults" configuration for totally non-interactive > build would have been my expectation here. Will I need to > babysit this whole build now? Yep. Nope. Again, portmaster will present you with all options before you go to dinner and when confronted with an interactive port will tell you before it starts to build and allows you to eat. Adding -m '-DBATCH' to portmaster will also silence any confirmation questions. These are not considered interactive ports, because of this fact that BATCH compiling can turn them off. Ports marked interactive (IS_INTERACTIVE=yes) have no sane or legally valid default (accepting a license for example). -- Mel From gad at FreeBSD.org Tue May 12 18:26:12 2009 From: gad at FreeBSD.org (Garance A Drosehn) Date: Tue May 12 18:26:18 2009 Subject: newsyslog(8) patch for both size and time checks In-Reply-To: References: Message-ID: At 1:59 PM +0400 5/12/09, Dmitry Morozovsky wrote: >Dear colleagues, > >for now, if log is configured to be rotated in time manner, its size is not >checked, so /var/log may be DoSed by some service (in our case, it >was mad DHCP client which fills up our /var/log with dhcpd log; our >newsyslog.conf >line was > >/var/log/dhcpd 640 5 5000 @T00 JC > >The following simple patch should fix the problem. Any objection to commit >this? It would fix your problem, but it changes the behavior as is explicitly documented in 'man newsyslog.conf' . There is a paragraph in the man page which makes it clear that if both fields are specified, then the log file will only be rotated if both conditions are true. I agree that newsyslog needs some way to specify an "either/or" combination of those fields. I believe I have some time to look into changes to newsyslog right this week, so I'll see what is needed to address this issue. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From jakub_lach at mailplus.pl Tue May 12 18:27:16 2009 From: jakub_lach at mailplus.pl (Jakub Lach) Date: Tue May 12 18:27:24 2009 Subject: dead dhclient em0 in r192014 /Thinkpad T400 Message-ID: <23507827.post@talk.nabble.com> Hello. After updating to 192014, gigabit Intel ethernet is dead. em0: link state changed to UP in_ifinit: insertion failed #dhclient em0 ifconfig ioctl (SIOCSIFADDR) File exists em0: not found exiting dhclient em0: not found dhclient exiting dhclient connection closed dhclient exiting -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/dead-dhclient-em0-in-r192014--Thinkpad-T400-tp23507827p23507827.html Sent from the freebsd-current mailing list archive at Nabble.com. From dimitry at andric.com Tue May 12 18:40:17 2009 From: dimitry at andric.com (Dimitry Andric) Date: Tue May 12 18:40:30 2009 Subject: dead dhclient em0 in r192014 /Thinkpad T400 In-Reply-To: <23507827.post@talk.nabble.com> References: <23507827.post@talk.nabble.com> Message-ID: <4A09C292.5070700@andric.com> On 2009-05-12 20:27, Jakub Lach wrote: > After updating to 192014, gigabit Intel ethernet is dead. ... > in_ifinit: insertion failed Revert r192011 to fix this issue. See also http://docs.freebsd.org/cgi/mid.cgi?4A09B57C.6050709 From andrey.kosachenko at gmail.com Tue May 12 19:29:33 2009 From: andrey.kosachenko at gmail.com (Andrey) Date: Tue May 12 19:29:40 2009 Subject: system panics on USB-mouse detachment In-Reply-To: <200905120843.12065.hselasky@c2i.net> References: <4A089216.1050701@gmail.com> <200905120843.12065.hselasky@c2i.net> Message-ID: <4A09CDD3.7030801@gmail.com> Hello, Hans Petter Selasky, I go along with report of Gustau Pe'rez (previous message in the thread) and confirm that given patch eliminates issue. Thank you for your time and efforts! Hans Petter Selasky wrote: > On Monday 11 May 2009, Andrey wrote: >> Andrey > > Hi Andrey, > > Thanks for reporting. I suspect the patch below will fix your problem: > > http://perforce.freebsd.org/chv.cgi?CH=161961 > > --HPS --- WBR, Andrey Kosachenko From mwest at l.zeeb.org Tue May 12 20:03:04 2009 From: mwest at l.zeeb.org (Matthew West) Date: Tue May 12 20:03:11 2009 Subject: ZFS panic: existing znode Message-ID: <20090512193945.GA34736@zeeb.org> FreeBSD 8-CURRENT, built from sources around 27/02/2009: FreeBSD foo.internal 8.0-CURRENT FreeBSD 8.0-CURRENT #5: Fri Apr 17 18:33:02 BST 2009 mwest@foo.internal:/usr/obj/usr/src/sys/DEBUGLOCK amd64 The system is AMD64, with 16GB of RAM, serving a few hundred clients via NFS (v2 and v3) and Samba, from a 800GB ZFS pool; using hardware RAID (aac controller), not RAID-Z. Running a GENERIC kernel, but with the following options enabled: options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC I also have Jaakko Heinonen's patch to zfs_znode.c applied, from: http://www.freebsd.org/cgi/query-pr.cgi?pr=132068 After almost a week of active usage, there was a system panic. ---------- panic: existing znode 0xffffff007dfd3d38 for dbuf 0xffffff00aeeb9620 cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 zfs_znode_dmu_init() at zfs_znode_dmu_init+0xb5 zfs_znode_alloc() at zfs_znode_alloc+0xa0 zfs_mknode() at zfs_mknode+0x205 zfs_freebsd_create() at zfs_freebsd_create+0x617 VOP_CREATE_APV() at VOP_CREATE_APV+0xb3 nfsrv_create() at nfsrv_create+0x909 nfssvc() at nfssvc+0x4af syscall() at syscall+0x1e7 Xfast_syscall() at Xfast_syscall+0xab --- syscall (155, FreeBSD ELF64, nfssvc), rip = 0x800695c4c, rsp = 0x7fffffffe8e8, rbp = 0 --- ---------- I see Kris Kennaway encountered a similar crash, but no one seems to have replied: http://lists.freebsd.org/pipermail/freebsd-current/2009-January/002631.html I was unfortunately not able to generate a crash dump. Let me know if there's any further information I can provide which might be useful. Thanks, Matthew From jkim at FreeBSD.org Tue May 12 21:23:35 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue May 12 21:23:47 2009 Subject: dead dhclient em0 in r192014 /Thinkpad T400 In-Reply-To: <4A09C292.5070700@andric.com> References: <23507827.post@talk.nabble.com> <4A09C292.5070700@andric.com> Message-ID: <200905121723.26171.jkim@FreeBSD.org> On Tuesday 12 May 2009 02:40 pm, Dimitry Andric wrote: > On 2009-05-12 20:27, Jakub Lach wrote: > > After updating to 192014, gigabit Intel ethernet is dead. > > ... > > > in_ifinit: insertion failed > > Revert r192011 to fix this issue. Or you can try the attached patch until it gets fixed. Jung-uk Kim -------------- next part -------------- --- sys/netinet/in.c 12 May 2009 07:41:20 -0000 1.131 +++ sys/netinet/in.c 12 May 2009 21:18:51 -0000 @@ -917,6 +917,8 @@ in_ifinit(struct ifnet *ifp, struct in_i info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)&null_sdl; error = rtrequest1_fib(RTM_ADD, &info, &rt, 0); + if (error == EEXIST) + return (0); if (error == 0 && rt != NULL) { RT_LOCK(rt); ((struct sockaddr_dl *)rt->rt_gateway)->sdl_type = From kmacy at freebsd.org Tue May 12 21:47:39 2009 From: kmacy at freebsd.org (Kip Macy) Date: Tue May 12 21:47:46 2009 Subject: ZFS panic: existing znode In-Reply-To: <20090512193945.GA34736@zeeb.org> References: <20090512193945.GA34736@zeeb.org> Message-ID: <3c1674c90905121447h4fe1f29bq90dd38e1861178c8@mail.gmail.com> This is fairly easy to reproduce with stress2 + fsstress. I haven't had time to track down the locking bug yet. Cheers, Kip On Tue, May 12, 2009 at 12:39 PM, Matthew West wrote: > FreeBSD 8-CURRENT, built from sources around 27/02/2009: > > FreeBSD foo.internal 8.0-CURRENT FreeBSD 8.0-CURRENT #5: Fri Apr 17 18:33:02 BST 2009 mwest@foo.internal:/usr/obj/usr/src/sys/DEBUGLOCK amd64 > > The system is AMD64, with 16GB of RAM, serving a few hundred clients via > NFS (v2 and v3) and Samba, from a 800GB ZFS pool; using hardware RAID > (aac controller), not RAID-Z. > > Running a GENERIC kernel, but with the following options enabled: > > options DEBUG_LOCKS > options DEBUG_VFS_LOCKS > options DIAGNOSTIC > > I also have Jaakko Heinonen's patch to zfs_znode.c applied, from: > http://www.freebsd.org/cgi/query-pr.cgi?pr=132068 > > After almost a week of active usage, there was a system panic. > > ---------- > panic: existing znode 0xffffff007dfd3d38 for dbuf 0xffffff00aeeb9620 > cpuid = 2 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x182 > zfs_znode_dmu_init() at zfs_znode_dmu_init+0xb5 > zfs_znode_alloc() at zfs_znode_alloc+0xa0 > zfs_mknode() at zfs_mknode+0x205 > zfs_freebsd_create() at zfs_freebsd_create+0x617 > VOP_CREATE_APV() at VOP_CREATE_APV+0xb3 > nfsrv_create() at nfsrv_create+0x909 > nfssvc() at nfssvc+0x4af > syscall() at syscall+0x1e7 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (155, FreeBSD ELF64, nfssvc), rip = 0x800695c4c, rsp = 0x7fffffffe8e8, rbp = 0 --- > ---------- > > I see Kris Kennaway encountered a similar crash, but no one seems to > have replied: > > ?http://lists.freebsd.org/pipermail/freebsd-current/2009-January/002631.html > > I was unfortunately not able to generate a crash dump. > > Let me know if there's any further information I can provide which > might be useful. > > Thanks, > > Matthew > > _______________________________________________ > 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" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From dan at langille.org Tue May 12 21:23:34 2009 From: dan at langille.org (Dan Langille) Date: Tue May 12 22:02:29 2009 Subject: usb/serial issues with dial up modem Message-ID: <4A09E44E.6090907@langille.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Giday, I encountered a problem with an 8.0 snapshot recently. I'm trying to get a dial-up modem working via a USB-serial cable on a eeePC 1000HE. It works fine under 7.2-RELEASE. The ppp log from 8 is attached but please scroll down. The main issue is: ppp[1686]: tun0: Phase: Auth: No response from server Also included is the debug output (messages) thompsa@ suggested that and has seen it, FWIW. In the meantime, I'm on 7.2-release trying to backport ath from HEAD, which was the main reason for the current-snapshot attempt. cheers. hth. - -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ5E4ACgkQCgsXFM/7nTyydwCg6IAyZSqLvSuOiC0zjXHMti1h 6FcAoJwzuZaUWWLc2Wj8mvYdZ/8WPrSV =Y/cr -----END PGP SIGNATURE----- -------------- next part -------------- [root@mum ~]# tail -F /var/log/ppp.log May 11 19:53:28 mum ppp[1679]: tun0: Phase: deflink: Disconnected! May 11 19:53:28 mum ppp[1679]: tun0: Phase: deflink: logout -> hangup May 11 19:53:28 mum ppp[1679]: tun0: Phase: deflink: Connect time: 41 secs: 8651 octets in, 463 octets out May 11 19:53:28 mum ppp[1679]: tun0: Phase: deflink: 141 packets in, 12 packets out May 11 19:53:28 mum ppp[1679]: tun0: Phase: total 222 bytes/sec, peak 551 bytes/sec on Mon May 11 19:53:27 2009 May 11 19:53:28 mum ppp[1679]: tun0: Phase: deflink: hangup -> closed May 11 19:53:28 mum ppp[1679]: tun0: Phase: bundle: Dead May 11 19:53:28 mum ppp[1679]: tun0: Phase: PPP Terminated (normal). May 11 19:53:28 mum ppp[1679]: tun0: Chat: Parent notified of failure May 11 19:53:28 mum ppp[1678]: tun0: Phase: Parent: Child failed (errdead) May 11 19:53:46 mum ppp[1685]: Phase: Using interface: tun0 May 11 19:53:46 mum ppp[1685]: Phase: deflink: Created in closed state May 11 19:53:46 mum ppp[1685]: tun0: Command: default: ident user-ppp VERSION (built COMPILATIONDATE) May 11 19:53:46 mum ppp[1685]: tun0: Command: default: set device /dev/cuaU0 May 11 19:53:46 mum ppp[1685]: tun0: Command: default: set speed 115200 May 11 19:53:46 mum ppp[1685]: tun0: Command: default: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5 "" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT May 11 19:53:46 mum ppp[1685]: tun0: Command: default: set timeout 180 May 11 19:53:46 mum ppp[1685]: tun0: Command: default: enable dns May 11 19:53:46 mum ppp[1685]: tun0: Command: ncf: set server /var/run/ncf ******** 0177 May 11 19:53:46 mum ppp[1685]: tun0: Phase: Listening at local socket /var/run/ncf. May 11 19:53:46 mum ppp[1685]: tun0: Command: ncf: set phone 6135201135 May 11 19:53:46 mum ppp[1685]: tun0: Command: ncf: set authname mom May 11 19:53:46 mum ppp[1685]: tun0: Command: ncf: set authkey ****** May 11 19:53:46 mum ppp[1685]: tun0: Command: ncf: set login TIMEOUT 10 gin: \U word: \n May 11 19:53:46 mum ppp[1685]: tun0: Command: ncf: set ifaddr 0 0 May 11 19:53:46 mum ppp[1685]: tun0: Command: ncf: add default HISADDR May 11 19:53:46 mum ppp[1685]: tun0: Command: ncf: disable ipv6cp May 11 19:53:46 mum ppp[1685]: tun0: Command: ncf: disable deflate May 11 19:53:46 mum ppp[1685]: tun0: Command: ncf: disable pred1 May 11 19:53:46 mum ppp[1685]: tun0: Command: ncf: disable vjcomp May 11 19:53:46 mum ppp[1686]: tun0: Phase: PPP Started (background mode). May 11 19:53:46 mum ppp[1686]: tun0: Phase: bundle: Establish May 11 19:53:46 mum ppp[1686]: tun0: Phase: deflink: closed -> opening May 11 19:53:46 mum ppp[1686]: tun0: Phase: deflink: Connected! May 11 19:53:46 mum ppp[1686]: tun0: Phase: deflink: opening -> dial May 11 19:53:46 mum ppp[1686]: tun0: Chat: Phone: 6135201135 May 11 19:53:46 mum ppp[1686]: tun0: Chat: deflink: Dial attempt 1 of 1 May 11 19:53:46 mum ppp[1686]: tun0: Chat: Send: AT^M May 11 19:53:46 mum ppp[1686]: tun0: Chat: Expect(5): OK May 11 19:53:51 mum ppp[1686]: tun0: Chat: Expect timeout May 11 19:53:51 mum ppp[1686]: tun0: Chat: Send: AT^M May 11 19:53:51 mum ppp[1686]: tun0: Chat: Expect(5): OK May 11 19:53:51 mum ppp[1686]: tun0: Chat: Received: 3.4.2 (built COMPILATIONDATE)G?~~?#^A^A May 11 19:53:51 mum ppp[1686]: tun0: Chat: Received: OK^M May 11 19:53:51 mum ppp[1686]: tun0: Chat: Send: ATE1Q0^M May 11 19:53:51 mum ppp[1686]: tun0: Chat: Expect(5): OK May 11 19:53:51 mum ppp[1686]: tun0: Chat: Received: ATE1Q0^M^M May 11 19:53:51 mum ppp[1686]: tun0: Chat: Received: OK^M May 11 19:53:51 mum ppp[1686]: tun0: Chat: Send: ATDT6135201135^M May 11 19:53:53 mum ppp[1686]: tun0: Chat: Expect(40): CONNECT May 11 19:54:05 mum ppp[1686]: tun0: Chat: Received: ATDT6135201135^M^M May 11 19:54:05 mum ppp[1686]: tun0: Chat: Received: CONNECT 31200/ARQ/V34/LAPM/V42BIS^M May 11 19:54:05 mum ppp[1686]: tun0: Phase: deflink: dial -> carrier May 11 19:54:06 mum ppp[1686]: tun0: Phase: deflink: /dev/cuaU0: CD detected May 11 19:54:06 mum ppp[1686]: tun0: Phase: deflink: carrier -> login May 11 19:54:06 mum ppp[1686]: tun0: Chat: Expect(10): gin: May 11 19:54:07 mum ppp[1686]: tun0: Chat: Received: ^M May 11 19:54:07 mum ppp[1686]: tun0: Chat: Received: NCF Help/LCN aide: (613-520-9001, office@ncf.ca^M May 11 19:54:07 mum ppp[1686]: tun0: Chat: Received: ^M May 11 19:54:07 mum ppp[1686]: tun0: Chat: Received: For a text connection, type the word 'text' at the 'login:' prompt.^M May 11 19:54:07 mum ppp[1686]: tun0: Chat: Send: mom^M May 11 19:54:07 mum ppp[1686]: tun0: Chat: Expect(10): word: May 11 19:54:07 mum ppp[1686]: tun0: Chat: Received: Pour un connection des textes, ecrivez le mot 'text' au message 'login:'^M May 11 19:54:07 mum ppp[1686]: tun0: Chat: Received: ^M May 11 19:54:07 mum ppp[1686]: tun0: Chat: Received: login: mom^M May 11 19:54:07 mum ppp[1686]: tun0: Chat: Received: Password: May 11 19:54:07 mum ppp[1686]: tun0: Chat: Send: ^M May 11 19:54:07 mum ppp[1686]: tun0: Phase: deflink: login -> lcp May 11 19:54:07 mum ppp[1686]: tun0: LCP: FSM: Using "deflink" as a transport May 11 19:54:07 mum ppp[1686]: tun0: LCP: deflink: State change Initial --> Closed May 11 19:54:07 mum ppp[1686]: tun0: LCP: deflink: State change Closed --> Stopped May 11 19:54:08 mum ppp[1686]: tun0: LCP: deflink: LayerStart May 11 19:54:08 mum ppp[1686]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped May 11 19:54:08 mum ppp[1686]: tun0: LCP: ACFCOMP[2] May 11 19:54:08 mum ppp[1686]: tun0: LCP: PROTOCOMP[2] May 11 19:54:08 mum ppp[1686]: tun0: LCP: ACCMAP[6] 0x00000000 May 11 19:54:08 mum ppp[1686]: tun0: LCP: MRU[4] 1500 May 11 19:54:08 mum ppp[1686]: tun0: LCP: MAGICNUM[6] 0xacc7b611 May 11 19:54:08 mum ppp[1686]: tun0: LCP: deflink: State change Stopped --> Req-Sent May 11 19:54:11 mum ppp[1686]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent May 11 19:54:11 mum ppp[1686]: tun0: LCP: ACFCOMP[2] May 11 19:54:11 mum ppp[1686]: tun0: LCP: PROTOCOMP[2] May 11 19:54:11 mum ppp[1686]: tun0: LCP: ACCMAP[6] 0x00000000 May 11 19:54:11 mum ppp[1686]: tun0: LCP: MRU[4] 1500 May 11 19:54:11 mum ppp[1686]: tun0: LCP: MAGICNUM[6] 0xacc7b611 May 11 19:54:14 mum ppp[1686]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent May 11 19:54:14 mum ppp[1686]: tun0: LCP: ACFCOMP[2] May 11 19:54:14 mum ppp[1686]: tun0: LCP: PROTOCOMP[2] May 11 19:54:14 mum ppp[1686]: tun0: LCP: ACCMAP[6] 0x00000000 May 11 19:54:14 mum ppp[1686]: tun0: LCP: MRU[4] 1500 May 11 19:54:14 mum ppp[1686]: tun0: LCP: MAGICNUM[6] 0xacc7b611 May 11 19:54:14 mum ppp[1686]: tun0: LCP: deflink: RecvConfigReq(1) state = Req-Sent May 11 19:54:14 mum ppp[1686]: tun0: LCP: MRU[4] 1514 May 11 19:54:14 mum ppp[1686]: tun0: LCP: ACCMAP[6] 0x00000000 May 11 19:54:14 mum ppp[1686]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) May 11 19:54:14 mum ppp[1686]: tun0: LCP: MAGICNUM[6] 0xf75389ac May 11 19:54:14 mum ppp[1686]: tun0: LCP: PROTOCOMP[2] May 11 19:54:14 mum ppp[1686]: tun0: LCP: ACFCOMP[2] May 11 19:54:14 mum ppp[1686]: tun0: LCP: MRRU[4] 1514 May 11 19:54:14 mum ppp[1686]: tun0: LCP: ENDDISC[9] MAC 00:c0:49:17:a3:c8 May 11 19:54:14 mum ppp[1686]: tun0: LCP: deflink: SendConfigRej(1) state = Req-Sent May 11 19:54:14 mum ppp[1686]: tun0: LCP: MRRU[4] 1514 May 11 19:54:14 mum ppp[1686]: tun0: LCP: deflink: SendIdent(0) state = Req-Sent May 11 19:54:14 mum ppp[1686]: tun0: LCP: MAGICNUM acc7b611 May 11 19:54:14 mum ppp[1686]: tun0: LCP: TEXT user-ppp 3.4.2 (built COMPILATIONDATE) May 11 19:54:14 mum ppp[1686]: tun0: LCP: deflink: RecvConfigAck(1) state = Req-Sent May 11 19:54:14 mum ppp[1686]: tun0: LCP: ACFCOMP[2] May 11 19:54:14 mum ppp[1686]: tun0: LCP: PROTOCOMP[2] May 11 19:54:14 mum ppp[1686]: tun0: LCP: ACCMAP[6] 0x00000000 May 11 19:54:14 mum ppp[1686]: tun0: LCP: MRU[4] 1500 May 11 19:54:14 mum ppp[1686]: tun0: LCP: MAGICNUM[6] 0xacc7b611 May 11 19:54:14 mum ppp[1686]: tun0: LCP: deflink: State change Req-Sent --> Ack-Rcvd May 11 19:54:14 mum ppp[1686]: tun0: LCP: deflink: RecvConfigReq(2) state = Ack-Rcvd May 11 19:54:14 mum ppp[1686]: tun0: LCP: MRU[4] 1514 May 11 19:54:14 mum ppp[1686]: tun0: LCP: ACCMAP[6] 0x00000000 May 11 19:54:14 mum ppp[1686]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) May 11 19:54:14 mum ppp[1686]: tun0: LCP: MAGICNUM[6] 0xf75389ac May 11 19:54:14 mum ppp[1686]: tun0: LCP: PROTOCOMP[2] May 11 19:54:14 mum ppp[1686]: tun0: LCP: ACFCOMP[2] May 11 19:54:14 mum ppp[1686]: tun0: LCP: deflink: SendConfigAck(2) state = Ack-Rcvd May 11 19:54:14 mum ppp[1686]: tun0: LCP: MRU[4] 1514 May 11 19:54:14 mum ppp[1686]: tun0: LCP: ACCMAP[6] 0x00000000 May 11 19:54:14 mum ppp[1686]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) May 11 19:54:14 mum ppp[1686]: tun0: LCP: MAGICNUM[6] 0xf75389ac May 11 19:54:14 mum ppp[1686]: tun0: LCP: PROTOCOMP[2] May 11 19:54:14 mum ppp[1686]: tun0: LCP: ACFCOMP[2] May 11 19:54:14 mum ppp[1686]: tun0: LCP: deflink: State change Ack-Rcvd --> Opened May 11 19:54:14 mum ppp[1686]: tun0: LCP: deflink: LayerUp May 11 19:54:14 mum ppp[1686]: tun0: LCP: deflink: SendIdent(1) state = Opened May 11 19:54:14 mum ppp[1686]: tun0: LCP: MAGICNUM acc7b611 May 11 19:54:14 mum ppp[1686]: tun0: LCP: TEXT user-ppp 3.4.2 (built COMPILATIONDATE) May 11 19:54:14 mum ppp[1686]: tun0: Phase: bundle: Authenticate May 11 19:54:14 mum ppp[1686]: tun0: Phase: deflink: his = PAP, mine = none May 11 19:54:14 mum ppp[1686]: tun0: Phase: Pap Output: mom ******** May 11 19:54:20 mum last message repeated 2 times May 11 19:54:23 mum ppp[1686]: tun0: Phase: Auth: No response from server May 11 19:54:23 mum ppp[1686]: tun0: LCP: deflink: LayerDown May 11 19:54:23 mum ppp[1686]: tun0: LCP: deflink: SendTerminateReq(2) state = Opened May 11 19:54:23 mum ppp[1686]: tun0: LCP: deflink: State change Opened --> Closing May 11 19:54:26 mum ppp[1686]: tun0: LCP: deflink: SendTerminateReq(2) state = Closing May 11 19:54:35 mum last message repeated 3 times May 11 19:54:38 mum ppp[1686]: tun0: LCP: deflink: LayerFinish May 11 19:54:38 mum ppp[1686]: tun0: LCP: deflink: State change Closing --> Closed May 11 19:54:38 mum ppp[1686]: tun0: LCP: deflink: State change Closed --> Initial May 11 19:54:38 mum ppp[1686]: tun0: Warning: deflink: Unable to set physical to speed 0 May 11 19:54:38 mum ppp[1686]: tun0: Phase: deflink: Disconnected! May 11 19:54:38 mum ppp[1686]: tun0: Phase: deflink: lcp -> logout May 11 19:54:38 mum ppp[1686]: tun0: Phase: deflink: logout -> hangup May 11 19:54:38 mum ppp[1686]: tun0: Warning: deflink: Unable to set physical to speed 0 May 11 19:54:38 mum ppp[1686]: tun0: Phase: deflink: Disconnected! May 11 19:54:38 mum ppp[1686]: tun0: Warning: deflink: Unable to set physical to speed 0 May 11 19:54:39 mum ppp[1686]: tun0: Phase: deflink: Connect time: 53 secs: 223 octets in, 523 octets out May 11 19:54:39 mum ppp[1686]: tun0: Phase: deflink: 5 packets in, 15 packets out May 11 19:54:39 mum ppp[1686]: tun0: Phase: total 14 bytes/sec, peak 110 bytes/sec on Mon May 11 19:54:15 2009 May 11 19:54:39 mum ppp[1686]: tun0: Phase: deflink: hangup -> closed May 11 19:54:39 mum ppp[1686]: tun0: Phase: bundle: Dead May 11 19:54:39 mum ppp[1686]: tun0: Phase: PPP Terminated (normal). May 11 19:54:39 mum ppp[1686]: tun0: Chat: Parent notified of failure May 11 19:54:39 mum ppp[1685]: tun0: Phase: Parent: Child failed (errdead) -------------- next part -------------- May 11 20:32:04 mum kernel: usb2a_com_open:538: tp = 0xc4982e00 May 11 20:32:04 mum kernel: usb2_com_dtr:820: onoff = 1 May 11 20:32:04 mum kernel: usb2_com_line_state:792: on=0x01, off=0x00 May 11 20:32:04 mum kernel: usb2_com_rts:831: onoff = 1 May 11 20:32:04 mum kernel: usb2_com_line_state:792: on=0x02, off=0x00 May 11 20:32:04 mum kernel: usb2_com_break:809: onoff = 0 May 11 20:32:04 mum kernel: usb2_com_line_state:792: on=0x00, off=0x04 May 11 20:32:04 mum kernel: usb2_com_status_change:894: May 11 20:32:04 mum kernel: usb2_com_param:943: sc = 0xc49f4e30 May 11 20:32:04 mum kernel: usb2_com_dtr:820: onoff = 1 May 11 20:32:04 mum kernel: usb2_com_line_state:792: on=0x01, off=0x00 May 11 20:32:04 mum kernel: usb2_com_rts:831: onoff = 1 May 11 20:32:04 mum kernel: usb2_com_line_state:792: on=0x02, off=0x00 May 11 20:32:04 mum kernel: usb2_com_cfg_open:504: May 11 20:32:04 mum kernel: usb2_com_ioctl:646: cmd = 0x402c7413 May 11 20:32:04 mum kernel: usb2_com_ioctl:646: cmd = 0x402c7413 May 11 20:32:04 mum kernel: usb2_com_ioctl:646: cmd = 0x802c7415 May 11 20:32:04 mum kernel: usb2_com_param:943: sc = 0xc49f4e30 May 11 20:32:04 mum kernel: usb2_com_ioctl:646: cmd = 0x8004667e May 11 20:32:04 mum kernel: usb2_com_ioctl:646: cmd = 0x8004667d May 11 20:32:04 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:04 mum kernel: usb2_com_status_change:894: May 11 20:32:05 mum kernel: usb2_com_get_data:1060: cnt=3 May 11 20:32:05 mum kernel: usb2_com_get_data:1060: cnt=0 May 11 20:32:05 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:05 mum kernel: usb2_com_get_data:1060: cnt=7 May 11 20:32:05 mum kernel: usb2_com_get_data:1060: cnt=0 May 11 20:32:05 mum kernel: usb2_com_outwakeup:1002: sc = May 11 20:32:05 mum kernel: 0xc49f4e30 May 11 20:32:05 mum kernel: usb2_com_get_data:1060: cnt=15 May 11 20:32:05 mum kernel: usb2_com_get_data:1060: cnt=0 May 11 20:32:19 mum kernel: usb2_com_status_change:894: May 11 20:32:19 mum kernel: usb2_com_cfg_status_change:880: DCD changed to 1 May 11 20:32:20 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:20 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:20 mum kernel: usb2_com_get_data:1060: cnt=6 May 11 20:32:20 mum kernel: usb2_com_get_data:1060: cnt=0 May 11 20:32:20 mum kernel: usb2_com_outwakeup:1002: sc = May 11 20:32:20 mum kernel: 0xc49f4e30 May 11 20:32:20 mum kernel: usb2_com_get_data:1060: cnt=2 May 11 20:32:20 mum kernel: usb2_com_ioctl:646: cmd = 0x402c7413 May 11 20:32:20 mum kernel: usb2_com_ioctl:646: cmd = 0x802c7414 May 11 20:32:20 mum kernel: usb2_com_ioctl:646: cmd = 0x8004667e May 11 20:32:20 mum kernel: usb2_com_ioctl:646: cmd = 0x8004667d May 11 20:32:20 mum kernel: usb2_com_get_data:1060: cnt=0 May 11 20:32:21 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:21 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:21 mum kernel: May 11 20:32:21 mum kernel: usb2_com_get_data:1060: cnt=53 May 11 20:32:21 mum kernel: usb2_com_get_data:1060: cnt=0 May 11 20:32:22 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:24 mum last message repeated 2 times May 11 20:32:24 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:24 mum kernel: usb2_com_get_data:1060: cnt=53 May 11 20:32:24 mum kernel: usb2_com_get_data:1060: cnt=0 May 11 20:32:25 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:27 mum last message repeated 2 times May 11 20:32:27 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:27 mum kernel: usb2_com_get_data:1060: cnt=53 May 11 20:32:27 mum kernel: usb2_com_get_data:1060: cnt=0 May 11 20:32:28 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:28 mum kernel: May 11 20:32:28 mum kernel: usb2_com_get_data:1060: cnt=24 May 11 20:32:28 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:28 mum kernel: usb2_com_get_data:1060: cnt=58 May 11 20:32:28 mum kernel: usb2_com_get_data:1060: cnt=0 May 11 20:32:28 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:28 mum kernel: May 11 20:32:28 mum kernel: usb2_com_get_data:1060: cnt=58 May 11 20:32:28 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:28 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:28 mum kernel: usb2_com_get_data:1060: cnt=64 May 11 20:32:28 mum kernel: usb2_com_get_data:1060: cnt=19 May 11 20:32:28 mum kernel: usb2_com_get_data:1060: cnt=0 May 11 20:32:28 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:30 mum last message repeated 2 times May 11 20:32:31 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:31 mum kernel: usb2_com_get_data:1060: cnt=25 May 11 20:32:31 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:33 mum last message repeated 2 times May 11 20:32:34 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:34 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:36 mum last message repeated 2 times May 11 20:32:37 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:37 mum kernel: May 11 20:32:37 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:39 mum last message repeated 2 times May 11 20:32:40 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:40 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:42 mum last message repeated 2 times May 11 20:32:43 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:43 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:45 mum last message repeated 2 times May 11 20:32:46 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:46 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:48 mum last message repeated 2 times May 11 20:32:49 mum kernel: usb2_com_outwakeup:1002: sc = 0xc49f4e30 May 11 20:32:49 mum kernel: usb2_com_ioctl:646: cmd = 0x4004746a May 11 20:32:51 mum last message repeated 2 times May 11 20:32:52 mum kernel: usb2_com_ioctl:646: cmd = 0x402c7413 May 11 20:32:52 mum kernel: usb2_com_ioctl:646: cmd = 0x802c7414 May 11 20:32:52 mum kernel: usb2_com_param:943: sc = 0xc49f4e30 May 11 20:32:52 mum kernel: usb2_com_param:962: callback error = 22 May 11 20:32:52 mum kernel: May 11 20:32:52 mum kernel: usb2_com_ioctl:646: cmd = 0x402c7413 May 11 20:32:52 mum ppp[1788]: tun0: Warning: deflink: Unable to set physical to speed 0 May 11 20:32:52 mum kernel: May 11 20:32:52 mum kernel: usb2_com_ioctl:646: cmd = 0x802c7414 May 11 20:32:52 mum kernel: usb2_com_param:943: sc = 0xc49f4e30 May 11 20:32:52 mum kernel: usb2_com_param:962: callback error = 22 May 11 20:32:52 mum kernel: usb2_com_ioctl:646: cmd = 0x402c7413 May 11 20:32:52 mum kernel: May 11 20:32:52 mum kernel: usb2_com_ioctl:646: cmd = 0x802c7414 May 11 20:32:52 mum kernel: usb2_com_param:943: sc = 0xc49f4e30 May 11 20:32:52 mum kernel: usb2_com_param:962: callback error = 22 May 11 20:32:52 mum kernel: usb2_com_ioctl:646: cmd = 0x80047410 May 11 20:32:52 mum kernel: usb2_com_ioctl:646: cmd = 0x802c7416 May 11 20:32:52 mum kernel: usb2_com_param:943: sc = 0xc49f4e30 May 11 20:32:52 mum kernel: usb2_com_dtr:820: onoff = 1 May 11 20:32:52 mum kernel: usb2_com_line_state:792: on=0x01, off=0x00 May 11 20:32:52 mum kernel: usb2_com_rts:831: onoff = 1 May 11 20:32:52 mum kernel: usb2_com_line_state:792: on=0x02, off=0x00 May 11 20:32:52 mum kernel: usb2_com_ioctl:646: cmd = 0x8004667e May 11 20:32:52 mum kernel: usb2_com_ioctl:646: cmd = 0x8004667d May 11 20:32:52 mum kernel: usb2_com_ioctl:646: cmd = 0x40047477 May 11 20:32:52 mum kernel: usb2_com_close:611: tp=0xc4982e00 May 11 20:32:52 mum kernel: usb2_com_shutdown:430: May 11 20:32:52 mum kernel: usb2_com_dtr:820: onoff = 0 May 11 20:32:52 mum ppp[1788]: tun0: Warning: deflink: Unable to set physical to speed 0 May 11 20:32:52 mum kernel: May 11 20:32:52 mum kernel: usb2_com_line_state:792: on=0x00, off=0x01 May 11 20:32:52 mum kernel: usb2_com_rts:831: onoff = 1 May 11 20:32:52 mum kernel: usb2_com_line_state:792: on=0x02, off=0x00 May 11 20:32:52 mum ppp[1788]: tun0: Warning: deflink: Unable to set physical to speed 0 May 11 20:32:52 mum kernel: usb2_com_cfg_close:589: May 11 20:32:52 mum kernel: tun0: link state changed to DOWN From kientzle at freebsd.org Tue May 12 22:29:39 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Tue May 12 22:29:46 2009 Subject: newsyslog(8) patch for both size and time checks In-Reply-To: References: Message-ID: <4A09F850.2080208@freebsd.org> Garance A Drosehn wrote: > At 1:59 PM +0400 5/12/09, Dmitry Morozovsky wrote: >> >> for now, if log is configured to be rotated in time manner, its size >> is not checked ... >> >> The following simple patch should fix the problem. Any objection to >> commit this? > > It would fix your problem, but it changes the behavior as is explicitly > documented in 'man newsyslog.conf' . There is a paragraph in the man > page which makes it clear that if both fields are specified, then the > log file will only be rotated if both conditions are true. I've never liked that paragraph and find the documented behavior is much less useful than the proposed behavior. With the documented behavior, the effect is "rotate at this size, but no more often than XXX time interval", which serves to limit the number of log files created, but not the total size. In practice, /var/log total size is almost always the critical resource. If compatibility is essential, perhaps we could add a new flag to control this behavior. (I would argue for changing the default and providing a flag to obtain the old behavior.) Tim From linimon at lonesome.com Tue May 12 22:54:17 2009 From: linimon at lonesome.com (Mark Linimon) Date: Tue May 12 23:04:26 2009 Subject: trivial patch commit request/reminder In-Reply-To: <1241645643.23197.7.camel@hyperion> References: <1241645643.23197.7.camel@hyperion> Message-ID: <20090512224414.GC32221@lonesome.com> On Thu, May 07, 2009 at 12:34:03AM +0300, Cristi Magherusan wrote: > Please anyone in charge (David Christensen?) review and commit to the > tree the trivial patch that fixes the issue discussed in this thread: > http://www.freebsd.org/cgi/query-pr.cgi?pr=118238 I've reassigned it to freebsd-net and noted that it has a patch now, so hopefully it will get some attention. mcl From jakub_lach at mailplus.pl Wed May 13 00:25:01 2009 From: jakub_lach at mailplus.pl (Jakub Lach) Date: Wed May 13 00:25:08 2009 Subject: dead dhclient em0 in r192014 /Thinkpad T400 In-Reply-To: <200905121723.26171.jkim@FreeBSD.org> References: <23507827.post@talk.nabble.com> <4A09C292.5070700@andric.com> <200905121723.26171.jkim@FreeBSD.org> Message-ID: <23513281.post@talk.nabble.com> Jung-uk Kim wrote: > > On Tuesday 12 May 2009 02:40 pm, Dimitry Andric wrote: >> On 2009-05-12 20:27, Jakub Lach wrote: >> > After updating to 192014, gigabit Intel ethernet is dead. >> >> ... >> >> > in_ifinit: insertion failed >> >> Revert r192011 to fix this issue. > > Or you can try the attached patch until it gets fixed. > > Jung-uk Kim > > --- sys/netinet/in.c 12 May 2009 07:41:20 -0000 1.131 > +++ sys/netinet/in.c 12 May 2009 21:18:51 -0000 > @@ -917,6 +917,8 @@ in_ifinit(struct ifnet *ifp, struct in_i > info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)&null_sdl; > error = rtrequest1_fib(RTM_ADD, &info, &rt, 0); > > + if (error == EEXIST) > + return (0); > if (error == 0 && rt != NULL) { > RT_LOCK(rt); > ((struct sockaddr_dl *)rt->rt_gateway)->sdl_type = > > _______________________________________________ > 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" > Thanks for replies. I've already reverted 192011 for now, thanks for patch anyway. -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/dead-dhclient-em0-in-r192014--Thinkpad-T400-tp23507827p23513281.html Sent from the freebsd-current mailing list archive at Nabble.com. From keramida at ceid.upatras.gr Wed May 13 01:16:52 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Wed May 13 01:17:00 2009 Subject: system panics on USB-mouse detachment In-Reply-To: <200905120843.12065.hselasky@c2i.net> (Hans Petter Selasky's message of "Tue, 12 May 2009 08:43:11 +0200") References: <4A089216.1050701@gmail.com> <200905120843.12065.hselasky@c2i.net> Message-ID: <878wl1ajjz.fsf@kobe.laptop> On Tue, 12 May 2009 08:43:11 +0200, Hans Petter Selasky wrote: > On Monday 11 May 2009, Andrey wrote: >> Andrey > > Hi Andrey, > Thanks for reporting. I suspect the patch below will fix your problem: > > http://perforce.freebsd.org/chv.cgi?CH=161961 It does for me too. Detachin my Logitech USB mouse panicked my laptop, but with the patch I can confirm that all seems to be fine again. From mike at sentex.net Wed May 13 01:40:56 2009 From: mike at sentex.net (Mike Tancsa) Date: Wed May 13 01:41:03 2009 Subject: dead dhclient em0 in r192014 /Thinkpad T400 In-Reply-To: <200905121723.26171.jkim@FreeBSD.org> References: <23507827.post@talk.nabble.com> <4A09C292.5070700@andric.com> <200905121723.26171.jkim@FreeBSD.org> Message-ID: <200905130139.n4D1dTpB033159@lava.sentex.ca> At 05:23 PM 5/12/2009, Jung-uk Kim wrote: > > > > Revert r192011 to fix this issue. > >Or you can try the attached patch until it gets fixed. Hi, That fixes it for me in that dhclient works at bootup. I do still see an error/warning message EOM_LABEL: Label ufsid/4a09abd8f0385de0 removed. Starting Network: lo0 em0. Additional routing options: IP gateway=YES . Configuring syscons: blanktime . em0: link state changed to UP Tue May 12 21:39:29 EDT 2009 in_scrubprefix: deletion failed ---Mike From qing.li at bluecoat.com Wed May 13 02:03:07 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Wed May 13 02:03:14 2009 Subject: dead dhclient em0 in r192014 /Thinkpad T400 In-Reply-To: <23507827.post@talk.nabble.com> References: <23507827.post@talk.nabble.com> Message-ID: Forgot to take care of DHCP, sorry about that. Please try the patch at http://people.freebsd.org/~qingli/in.c I have tested it and appears to be good. -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Jakub Lach > Sent: Tuesday, May 12, 2009 11:27 AM > To: freebsd-current@freebsd.org > Subject: dead dhclient em0 in r192014 /Thinkpad T400 > > > Hello. > > After updating to 192014, gigabit Intel ethernet is dead. > > > em0: link state changed to UP > in_ifinit: insertion failed > > #dhclient em0 > > ifconfig ioctl (SIOCSIFADDR) File exists > em0: not found > exiting > dhclient em0: not found > dhclient exiting > dhclient connection closed > dhclient exiting > > -best regards, > Jakub Lach > -- > View this message in context: http://www.nabble.com/dead-dhclient-em0- > in-r192014--Thinkpad-T400-tp23507827p23507827.html > Sent from the freebsd-current mailing list archive at Nabble.com. > > _______________________________________________ > 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 davidch at broadcom.com Wed May 13 05:08:36 2009 From: davidch at broadcom.com (David Christensen) Date: Wed May 13 05:08:43 2009 Subject: trivial patch commit request/reminder In-Reply-To: <1241645643.23197.7.camel@hyperion> References: <1241645643.23197.7.camel@hyperion> Message-ID: <5D267A3F22FD854F8F48B3D2B523819339DA2599DC@IRVEXCHCCR01.corp.ad.broadcom.com> > Please anyone in charge (David Christensen?) review and > commit to the tree the trivial patch that fixes the issue > discussed in this thread: > http://www.freebsd.org/cgi/query-pr.cgi?pr=118238 > > It's a shame that it didn't make it in 7.2, but hopefully it > will in 8.0. I'm travelling and will try it when I get back to the office on Monday. The 5709S which is also supported by bce(4) needs a more significant change for SerDes support which I would also like to fold into the driver. Dave From jeremie at le-hen.org Wed May 13 06:57:39 2009 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Wed May 13 06:57:56 2009 Subject: New mergemaster option -I, failsafe install files In-Reply-To: <4A07AF92.1040309@FreeBSD.org> References: <20090510165737.GB88857@obiwan.tataz.chchile.org> <4A07AF92.1040309@FreeBSD.org> Message-ID: <20090513065650.GF45358@obiwan.tataz.chchile.org> On Sun, May 10, 2009 at 09:54:42PM -0700, Doug Barton wrote: > Jeremie Le Hen wrote: > > Hi Doug, > > > > As you may guess from my multiple emails, I'm in the process of > > upgrading my jails :-). > > > > Since I have one jail per service, a very few number of configuration > > files are modified on each jail. As most of user of FreeBSD I think, > > I'm used to run "mergemaster -iU" to automate the process as much as > > possible. The problem with service jails (chapter 15.6.1 of the > > handbook) is that / is read-only mounted on all jails, /etc /var /root > > and a few other places being symlinks to /s, the private read-write > > space of each jail. Thus when mergemaster tries to update > > /boot/devices.hints it fails and abort. > > I think the way to solve this problem would be with an > MM_PRE_COMPARE_SCRIPT that deletes /boot/device.hints (and any other > relevant files) from the temproot. If they are not present in that > directory when the comparison starts then it's a non-issue. Actually, /boot belongs to the read/only nullfs mount, so it is not possible to use MM_PRE_COMPARE_SCRIPT from the jail. The only way to handle this currently is to remove /boot from the jail template. I'm Cc:ing -doc@ because chapter 15.6.1 of the handbook (service jails) needs to be updated to remove /boot from the jail template "mroot". Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From Thomas.Sparrevohn at btinternet.com Wed May 13 07:32:02 2009 From: Thomas.Sparrevohn at btinternet.com (Thomas Sparrevohn) Date: Wed May 13 07:32:08 2009 Subject: rum(4) not working on 8-CURRENT In-Reply-To: <20090510204757.GA45375@citylink.fud.org.nz> References: <4A072AF0.2000903@gmail.com> <20090510204757.GA45375@citylink.fud.org.nz> Message-ID: <200905111433.14298.Thomas.Sparrevohn@btinternet.com> On Sunday 10 May 2009 21:47:57 Andrew Thompson wrote: > On Sun, May 10, 2009 at 08:28:48PM +0100, Sevan / Venture37 wrote: > > Hi > > I've installed a fresh copy of 8-CURRENT 05/09 AMD64 snapshot on my laptop > > which has a ralink pci express mini card, the device is detected by the > > kernel correctly & the rum driver attaches however the card doesn't work, > > ifconfig rum0 scan or list scan results in: > ^^^^^^^^^^^^^^^^^^ > > You need to create a wlan pseudo device and operate on that > > # ifconfig wlan0 create wlandev rum0 up > > If you still have problems then enable debugging with 'wlandebug > state+scan' and then down/up the interface. > > > Andrew > _______________________________________________ > 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" > The rum driver is very flacky on CURRENT - on my machine a "make fetchindex" makes the driver freeze and I have to do a ifconfig wlan0 down/ifconfig wlan0 up in order to get it running again. It seems that it has something to do with "fetch" that triggers the issue From ohartman at zedat.fu-berlin.de Wed May 13 07:36:17 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Wed May 13 07:36:24 2009 Subject: FreeBSD 8.0: how to exchange order of recognized HDA devices? Message-ID: <4A0A7820.6070602@zedat.fu-berlin.de> The problem occured after the installation of an ATI HD4670 graphics board, on which one can find an additional HDA device found by the kernel before the on-board HDA device is found. So many clients, like vlc, mplayer etc. do have problems - they either play no sound through the usual pathways (via on-board soundcard/chip and the attached speakerset and/or headphones). I see 4 mixer-devices: mixer0 through mixer3. mixer0 seems to be attached to the graphics-card, mixer1 shows the usual devices I recognize and mixer 2 and 3 are unknown to me, they show up only 2 facilities. To make things simple: is there a way to change order of the found HDA controller? Thi8s is what 'dmesg|grep HDA' reveals: -- hdac0: HDA Codec #0: ATI R6xx HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Analog Devices AD1988B pcm1: at cad 0 nid 1 on hdac1 pcm2: at cad 0 nid 1 on hdac1 pcm3: at cad 0 nid 1 on hdac1 -- Or do i miss something unrevealed? Thanks in advance, Oliver From marck at rinet.ru Wed May 13 07:45:39 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed May 13 07:45:47 2009 Subject: newsyslog(8) patch for both size and time checks In-Reply-To: References: Message-ID: On Tue, 12 May 2009, Garance A Drosehn wrote: GAD> > for now, if log is configured to be rotated in time manner, its size is GAD> > not GAD> > checked, so /var/log may be DoSed by some service (in our case, it was GAD> > mad DHCP client which fills up our /var/log with dhcpd log; our GAD> > newsyslog.conf GAD> > line was GAD> > GAD> > /var/log/dhcpd 640 5 5000 @T00 JC GAD> > GAD> > The following simple patch should fix the problem. Any objection to GAD> > commit GAD> > this? GAD> GAD> It would fix your problem, but it changes the behavior as is explicitly GAD> documented in 'man newsyslog.conf' . There is a paragraph in the man GAD> page which makes it clear that if both fields are specified, then the GAD> log file will only be rotated if both conditions are true. Nope, there is statement about time/interval combination, and size is not mentioned: == 8< == When both a time and an interval are specified then both conditions must be satisfied for the rotation to take place. == 8< == Also, I can't find anything about expected behaviour in the standards... GAD> I agree that newsyslog needs some way to specify an "either/or" GAD> combination of those fields. I believe I have some time to look into GAD> changes to newsyslog right this week, so I'll see what is needed to GAD> address this issue. Thank you for looking into this. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From pieter at degoeje.nl Wed May 13 07:57:22 2009 From: pieter at degoeje.nl (Pieter de Goeje) Date: Wed May 13 07:57:30 2009 Subject: FreeBSD 8.0: how to exchange order of recognized HDA devices? In-Reply-To: <4A0A7820.6070602@zedat.fu-berlin.de> References: <4A0A7820.6070602@zedat.fu-berlin.de> Message-ID: <200905130957.16156.pieter@degoeje.nl> On Wednesday 13 May 2009 09:34:56 O. Hartmann wrote: > The problem occured after the installation of an ATI HD4670 graphics > board, on which one can find an additional HDA device found by the > kernel before the on-board HDA device is found. > So many clients, like vlc, mplayer etc. do have problems - they either > play no sound through the usual pathways (via on-board soundcard/chip > and the attached speakerset and/or headphones). > I see 4 mixer-devices: mixer0 through mixer3. mixer0 seems to be > attached to the graphics-card, mixer1 shows the usual devices I > recognize and mixer 2 and 3 are unknown to me, they show up only 2 > facilities. > > To make things simple: is there a way to change order of the found HDA > controller? sysctl hw.snd.default_unit=x where x should probably be 1 in your case. Regards, Pieter de Goeje From hselasky at freebsd.org Wed May 13 07:59:39 2009 From: hselasky at freebsd.org (Hans Petter Selasky) Date: Wed May 13 07:59:46 2009 Subject: usb/serial issues with dial up modem In-Reply-To: <4A09E44E.6090907@langille.org> References: <4A09E44E.6090907@langille.org> Message-ID: <200905130902.11515.hselasky@freebsd.org> On Tuesday 12 May 2009, Dan Langille wrote: > May 11 19:53:51 mum ppp[1686]: tun0: Chat: Send: ATE1Q0^M Hi, What kind of modem are you using? Maybe it is a TTY problem. I cannot find any errors besides from that ppp cannot set the modem speed to zero. --HPS From thierry.herbelot at free.fr Wed May 13 08:03:50 2009 From: thierry.herbelot at free.fr (Thierry Herbelot) Date: Wed May 13 08:03:59 2009 Subject: FreeBSD 8.0: how to exchange order of recognized HDA devices? In-Reply-To: <4A0A7820.6070602@zedat.fu-berlin.de> References: <4A0A7820.6070602@zedat.fu-berlin.de> Message-ID: <200905131003.33424.thierry.herbelot@free.fr> Le Wednesday 13 May 2009, O. Hartmann a ?crit : > The problem occured after the installation of an ATI HD4670 graphics > board, on which one can find an additional HDA device found by the > kernel before the on-board HDA device is found. > So many clients, like vlc, mplayer etc. do have problems - they either > play no sound through the usual pathways (via on-board soundcard/chip > and the attached speakerset and/or headphones). > I see 4 mixer-devices: mixer0 through mixer3. mixer0 seems to be > attached to the graphics-card, mixer1 shows the usual devices I > recognize and mixer 2 and 3 are unknown to me, they show up only 2 > facilities. > > To make things simple: is there a way to change order of the found HDA > controller? Hello, I am using a quick and dirty workaround for the same issue under -stable : I am loading the snd_hda from /etc/rc.local (i.e. late in the boot process) instead of via the loader (from /boot/loader.conf) then, the snd_hda uses the "right" physical device (this is with a 780G-based integrated motherboard) Cheers TfH PS : dmesg extract : hdac0: mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20090131_0127 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC885 hdac1: mem 0xfdffc000-0xfdffffff irq 19 at device 5.1 on pci1 hdac1: HDA Driver Revision: 20090131_0127 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI RS690/780 HDMI pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm3: at cad 0 nid 1 on hdac1 > > Thi8s is what 'dmesg|grep HDA' reveals: > > -- > hdac0: HDA Codec #0: ATI R6xx HDMI > pcm0: at cad 0 nid 1 on hdac0 > hdac1: HDA Codec #0: Analog Devices AD1988B > pcm1: at cad 0 nid 1 on hdac1 > pcm2: at cad 0 nid 1 on hdac1 > pcm3: at cad 0 nid 1 on hdac1 > -- > > > Or do i miss something unrevealed? > > Thanks in advance, > Oliver > > _______________________________________________ > 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 ohartman at zedat.fu-berlin.de Wed May 13 08:07:33 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Wed May 13 08:07:46 2009 Subject: FreeBSD 8.0: how to exchange order of recognized HDA devices? In-Reply-To: <200905130957.16156.pieter@degoeje.nl> References: <4A0A7820.6070602@zedat.fu-berlin.de> <200905130957.16156.pieter@degoeje.nl> Message-ID: <4A0A7F73.2060203@zedat.fu-berlin.de> Pieter de Goeje wrote: > On Wednesday 13 May 2009 09:34:56 O. Hartmann wrote: >> The problem occured after the installation of an ATI HD4670 graphics >> board, on which one can find an additional HDA device found by the >> kernel before the on-board HDA device is found. >> So many clients, like vlc, mplayer etc. do have problems - they either >> play no sound through the usual pathways (via on-board soundcard/chip >> and the attached speakerset and/or headphones). >> I see 4 mixer-devices: mixer0 through mixer3. mixer0 seems to be >> attached to the graphics-card, mixer1 shows the usual devices I >> recognize and mixer 2 and 3 are unknown to me, they show up only 2 >> facilities. >> >> To make things simple: is there a way to change order of the found HDA >> controller? > sysctl hw.snd.default_unit=x > where x should probably be 1 in your case. > > Regards, > Pieter de Goeje > _______________________________________________ > 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" Great! Thanks, this 'solved' it, simple, shiny, perfect ;-) Oliver From tinderbox at freebsd.org Wed May 13 08:09:30 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed May 13 08:09:37 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <20090513080926.175F37302F@freebsd-current.sentex.ca> TB --- 2009-05-13 07:04:55 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-13 07:04:55 - starting HEAD tinderbox run for mips/mips TB --- 2009-05-13 07:04:55 - cleaning the object tree TB --- 2009-05-13 07:05:48 - cvsupping the source tree TB --- 2009-05-13 07:05:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-05-13 07:05:56 - building world TB --- 2009-05-13 07:05:56 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-13 07:05:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-13 07:05:56 - TARGET=mips TB --- 2009-05-13 07:05:56 - TARGET_ARCH=mips TB --- 2009-05-13 07:05:56 - TZ=UTC TB --- 2009-05-13 07:05:56 - __MAKE_CONF=/dev/null TB --- 2009-05-13 07:05:56 - cd /src TB --- 2009-05-13 07:05:56 - /usr/bin/make -B buildworld >>> World build started on Wed May 13 07:05:59 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] In file included from ioctl.c:101: /obj/mips/src/tmp/usr/include/sys/ioctl_compat.h:117:1: warning: "MDMBUF" redefined In file included from /obj/mips/src/tmp/usr/include/sys/tty.h:41, from ioctl.c:9: /obj/mips/src/tmp/usr/include/sys/termios.h:148:1: warning: this is the location of the previous definition cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.bin/truss -I. -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/truss/mips-fbsd.c /src/usr.bin/truss/mips-fbsd.c: In function 'mips_syscall_exit': /src/usr.bin/truss/mips-fbsd.c:341: error: too few arguments to function 'print_syscall_ret' *** Error code 1 Stop in /src/usr.bin/truss. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-13 08:09:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-13 08:09:25 - ERROR: failed to build world TB --- 2009-05-13 08:09:25 - 2841.80 user 324.30 system 3870.22 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From Alexander at Leidinger.net Wed May 13 08:12:23 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed May 13 08:12:35 2009 Subject: FreeBSD 8.0: how to exchange order of recognized HDA devices? In-Reply-To: <4A0A7820.6070602@zedat.fu-berlin.de> References: <4A0A7820.6070602@zedat.fu-berlin.de> Message-ID: <20090513101212.14014bw30s2b0c84@webmail.leidinger.net> Quoting "O. Hartmann" (from Wed, 13 May 2009 07:34:56 +0000): > The problem occured after the installation of an ATI HD4670 graphics > board, on which one can find an additional HDA device found by the > kernel before the on-board HDA device is found. > So many clients, like vlc, mplayer etc. do have problems - they > either play no sound through the usual pathways (via on-board > soundcard/chip and the attached speakerset and/or headphones). > I see 4 mixer-devices: mixer0 through mixer3. mixer0 seems to be > attached to the graphics-card, mixer1 shows the usual devices I > recognize and mixer 2 and 3 are unknown to me, they show up only 2 > facilities. > > To make things simple: is there a way to change order of the found > HDA controller? No, but you can do sysctl hw.snd.default_unit=1 or an appropriate line in /etc/sysctl.conf instead. Bye, Alexander. -- Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From guru at unixarea.de Wed May 13 08:20:46 2009 From: guru at unixarea.de (Matthias Apitz) Date: Wed May 13 08:20:58 2009 Subject: laptop Dell M4400 with -CURRENT? In-Reply-To: <20090511122121.GA9961@rebelion.Sisis.de> References: <20090428083627.GA3621@rebelion.Sisis.de> <20090508141755.GB13584@rebelion.Sisis.de> <1241796489.1733.25.camel@balrog.2hip.net> <20090511122121.GA9961@rebelion.Sisis.de> Message-ID: <20090513082036.GA4222@rebelion.Sisis.de> El d?a Monday, May 11, 2009 a las 02:21:21PM +0200, Matthias Apitz escribi?: > El d?a Friday, May 08, 2009 a las 10:28:09AM -0500, Robert Noland escribi?: > > > I have ported the nouveau drm driver. > > > > http://people.freebsd.org/~rnoland/drm-nouveau-043009.patch > > > > It is working on NV50 cards, NV40 was working, but with WITNESS enabled > > I seem to be getting a panic on NV40. My NV40 card seems to be having > > memory issues so I haven't been able to get and/or see the backtrace. I > > think it is just a locking issue which should be pretty easily solved if > > I can get a clear backtrace. > > > > You will need current libdrm and xf86-video-nouveau from ports. > > > > This won't get you 3d right now, but should get you EXA + Xv. > > Hello Robert, > > I have applied your patch and ported xf86-video-nouveau from ports; all > is fine now and the display comes up with 1920x1200 resolution; > > I'm attaching Xorg.0.log so you can see what kind of chips the nouveau > driver is detecting. > > Thanks again for your work and help .... Hello, I have to admit that this message 'all is fine' was to fast; the Xorg came only up *once* and let the KDE3.5.10 fully appear; I was even able to switch the font size from 8 to 12, because with this high resolution it was nearly unreadable. after stopping X with Ctrl-Alt-BS I was never ever able to bring X + KDE up; while KDE is initialising at some point the X goes into 100% of CPU usage; it is not a CPU-loop itself inside the X server, but a loop of SIG 14 as I can proof with truss from another session: SIGNAL 14 (SIGALRM) sigreturn(0xbfbfe500,0xe,0x0,0xbfbfe500,0x0,0x8127070) = 678420552 (0x286fe048) SIGNAL 14 (SIGALRM) sigreturn(0xbfbfe500,0xe,0x0,0xbfbfe500,0x0,0x8127070) = 678420552 (0x286fe048) SIGNAL 14 (SIGALRM) sigreturn(0xbfbfe500,0xe,0x0,0xbfbfe500,0x0,0x8127070) = 678420552 (0x286fe048) SIGNAL 14 (SIGALRM) ... when I only start via ~/.xinitrc a 'xterm' and 'twm' there is no problem, but as soon I'm launching 'startkde' inside such a session the above loop comes up and only power cycle bring the system back to life. What can I do? I have also removed ~/.kde and ~/Desktop to let KDE init a fresh environment, no luck. I'm not using HAL with KDE. The 'vesa' driver works but only gives 1024x??? resolution (don't remember the exact 2nd size right now), but this is not an option to go; is it possible to get higher res with 'vesa'? If someone wants me debugging something, please tell me how; I could even provide SSH access to the laptop (because it is still nearly empty), please contact me off-list for this. Thanks for any hint. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From hselasky at c2i.net Wed May 13 08:46:04 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed May 13 08:46:11 2009 Subject: rum(4) not working on 8-CURRENT In-Reply-To: <200905130922.52887.Thomas.Sparrevohn@btinternet.com> References: <200905130922.52887.Thomas.Sparrevohn@btinternet.com> Message-ID: <200905131048.37146.hselasky@c2i.net> On Wednesday 13 May 2009, Thomas Sparrevohn wrote: > Hans Petter > > I don't see this one came through - but I am having real pains with rum(4) > - the weird thing it that it seems to work with HTTP etc but not with fetch > - no panics - it just drops all connections and routing information - It am > still getting the "kernel: rum0: need multicast update callback" error but > I cannot see that it has anything to do with the issue In my experience it's not the driver that is flaky, but the firmware in the hardware. I've seen several times that if certain commands are intermixed, the firmware will completely stop responding. Has the rum driver ever worked with USB2 and -current? Recently there has been several changes in the WLAN layer and some minor changes in if_rum. --HPS From dimitry at andric.com Wed May 13 08:52:50 2009 From: dimitry at andric.com (Dimitry Andric) Date: Wed May 13 08:52:56 2009 Subject: dead dhclient em0 in r192014 /Thinkpad T400 In-Reply-To: References: <23507827.post@talk.nabble.com> Message-ID: <4A0A8A64.3020007@andric.com> On 2009-05-13 03:48, Li, Qing wrote: > Forgot to take care of DHCP, sorry about that. > > Please try the patch at http://people.freebsd.org/~qingli/in.c > I have tested it and appears to be good. Confirmed; this makes dhclient work again, and even without any error message. :) From Thomas.Sparrevohn at btinternet.com Wed May 13 10:05:46 2009 From: Thomas.Sparrevohn at btinternet.com (Thomas Sparrevohn) Date: Wed May 13 10:05:53 2009 Subject: rum(4) not working on 8-CURRENT In-Reply-To: <200905131048.37146.hselasky@c2i.net> References: <200905130922.52887.Thomas.Sparrevohn@btinternet.com> <200905131048.37146.hselasky@c2i.net> Message-ID: <200905131105.40616.Thomas.Sparrevohn@btinternet.com> On Wednesday 13 May 2009 09:48:36 Hans Petter Selasky wrote: > On Wednesday 13 May 2009, Thomas Sparrevohn wrote: > > Hans Petter > > > > I don't see this one came through - but I am having real pains with rum(4) > > - the weird thing it that it seems to work with HTTP etc but not with fetch > > - no panics - it just drops all connections and routing information - It am > > still getting the "kernel: rum0: need multicast update callback" error but > > I cannot see that it has anything to do with the issue > > In my experience it's not the driver that is flaky, but the firmware in the > hardware. I've seen several times that if certain commands are intermixed, > the firmware will completely stop responding. > > Has the rum driver ever worked with USB2 and -current? Recently there has been > several changes in the WLAN layer and some minor changes in if_rum. > > --HPS > _______________________________________________ > 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" > yes a couple of month ago you send me some patches and it worked fine - I need to look in my old maill - I am using a kernel with those patches as we speak - unfortunately I lost the patches From Thomas.Sparrevohn at btinternet.com Wed May 13 10:07:27 2009 From: Thomas.Sparrevohn at btinternet.com (Thomas Sparrevohn) Date: Wed May 13 10:07:34 2009 Subject: rum(4) not working on 8-CURRENT In-Reply-To: <200905131048.37146.hselasky@c2i.net> References: <200905130922.52887.Thomas.Sparrevohn@btinternet.com> <200905131048.37146.hselasky@c2i.net> Message-ID: <200905131107.25115.Thomas.Sparrevohn@btinternet.com> On Wednesday 13 May 2009 09:48:36 Hans Petter Selasky wrote: > On Wednesday 13 May 2009, Thomas Sparrevohn wrote: > > Hans Petter > > > > I don't see this one came through - but I am having real pains with rum(4) > > - the weird thing it that it seems to work with HTTP etc but not with fetch > > - no panics - it just drops all connections and routing information - It am > > still getting the "kernel: rum0: need multicast update callback" error but > > I cannot see that it has anything to do with the issue > > In my experience it's not the driver that is flaky, but the firmware in the > hardware. I've seen several times that if certain commands are intermixed, > the firmware will completely stop responding. > > Has the rum driver ever worked with USB2 and -current? Recently there has been > several changes in the WLAN layer and some minor changes in if_rum. > > --HPS > _______________________________________________ > 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" > The driver stopped when the USB2 changes was reverted some time ago - prior to that USB2 worked fine e.g. when the dummy multicast was removed etc From bjakoktochce at o2.pl Wed May 13 10:59:36 2009 From: bjakoktochce at o2.pl (Bartosz Jakoktochce) Date: Wed May 13 10:59:49 2009 Subject: 8.0-current on virtualbox intel cards reports invalid mac Message-ID: <4A0AA1DA.5040903@o2.pl> I'm running 8.0-CURRENT on VirtualBox 2.2.2 and noticed an error while loading kernel. em0: port 0xc010-0xc017 mem 0xf0000000-0xf001ffff irq 11 at device 3.0 on pci0 em0: Invalid MAC address device_attach: em0 attach returned 5 The 7.x and also 6.x work fine with this. Regards Bartosz Jakoktochce From guru at unixarea.de Wed May 13 11:26:10 2009 From: guru at unixarea.de (Matthias Apitz) Date: Wed May 13 11:26:20 2009 Subject: laptop Dell M4400 with -CURRENT? In-Reply-To: <20090513082036.GA4222@rebelion.Sisis.de> References: <20090428083627.GA3621@rebelion.Sisis.de> <20090508141755.GB13584@rebelion.Sisis.de> <1241796489.1733.25.camel@balrog.2hip.net> <20090511122121.GA9961@rebelion.Sisis.de> <20090513082036.GA4222@rebelion.Sisis.de> Message-ID: <20090513112608.GA9693@rebelion.Sisis.de> El d?a Wednesday, May 13, 2009 a las 10:20:36AM +0200, Matthias Apitz escribi?: > Hello, > > I have to admit that this message 'all is fine' was to fast; the Xorg > came only up *once* and let the KDE3.5.10 fully appear; I was even able > to switch the font size from 8 to 12, because with this high resolution > it was nearly unreadable. > > after stopping X with Ctrl-Alt-BS I was never ever able to bring X + KDE > up; while KDE is initialising at some point the X goes into 100% of CPU > usage; it is not a CPU-loop itself inside the X server, but a loop of > SIG 14 as I can proof with truss from another session: > > SIGNAL 14 (SIGALRM) > sigreturn(0xbfbfe500,0xe,0x0,0xbfbfe500,0x0,0x8127070) = 678420552 (0x286fe048) > SIGNAL 14 (SIGALRM) > sigreturn(0xbfbfe500,0xe,0x0,0xbfbfe500,0x0,0x8127070) = 678420552 (0x286fe048) > SIGNAL 14 (SIGALRM) > sigreturn(0xbfbfe500,0xe,0x0,0xbfbfe500,0x0,0x8127070) = 678420552 (0x286fe048) > SIGNAL 14 (SIGALRM) > ... > > when I only start via ~/.xinitrc a 'xterm' and 'twm' there is no > problem, but as soon I'm launching 'startkde' inside such a session the > above loop comes up and only power cycle bring the system back to life. > > What can I do? I have set now in xorg.conf Option "NoAccel" "true" which let KDE come up, but ofc it is terrible slow; just to let you know; Thanks in any case for your work. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From ulf.lilleengen at gmail.com Wed May 13 11:55:29 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Wed May 13 11:55:35 2009 Subject: dead dhclient em0 in r192014 /Thinkpad T400 In-Reply-To: References: <23507827.post@talk.nabble.com> Message-ID: <4A0AAF8B.6040905@gmail.com> Li, Qing wrote: > Forgot to take care of DHCP, sorry about that. > > Please try the patch at http://people.freebsd.org/~qingli/in.c > I have tested it and appears to be good. > > -- Qing > > > Works for me. >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >> current@freebsd.org] On Behalf Of Jakub Lach >> Sent: Tuesday, May 12, 2009 11:27 AM >> To: freebsd-current@freebsd.org >> Subject: dead dhclient em0 in r192014 /Thinkpad T400 >> >> >> Hello. >> >> After updating to 192014, gigabit Intel ethernet is dead. >> >> >> em0: link state changed to UP >> in_ifinit: insertion failed >> >> #dhclient em0 >> >> ifconfig ioctl (SIOCSIFADDR) File exists >> em0: not found >> exiting >> dhclient em0: not found >> dhclient exiting >> dhclient connection closed >> dhclient exiting >> >> -best regards, >> Jakub Lach >> -- >> View this message in context: http://www.nabble.com/dead-dhclient-em0- >> in-r192014--Thinkpad-T400-tp23507827p23507827.html >> Sent from the freebsd-current mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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" >> > _______________________________________________ > 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 serenity at exscape.org Wed May 13 13:19:16 2009 From: serenity at exscape.org (Thomas Backman) Date: Wed May 13 13:19:24 2009 Subject: DTrace panic while probing syscall::open (and possibly many others) Message-ID: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> OK, so I first posted a thread on the forums about this in 7.2-RELEASE: http://forums.freebsd.org/showthread.php?t=3834 Then filed a PR, kern/134408: http://www.freebsd.org/cgi/query-pr.cgi?pr=134408 The very same bug remains in 8-CURRENT/amd64 as of May 13, ~10(am) GMT+2. Steps to reproduce: 1) Build DTrace capable kernel (I followed the wiki DTrace instructions) 2) Reboot; kldload dtraceall 3) dtrace -n 'syscall::open:entry { self->path = arg0; } syscall::open:return { printf("%s\n", copyinstr(self->path)); }' 4) Crash. Backtrace: [root@vmware /usr/obj/usr/src/sys/DTRACE]# kgdb kernel.debug /var/ crash/vmcore.3 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 conditions. 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: panic: from debugger cpuid = 0 Uptime: 3m10s Physical memory: 368 MB Dumping 81 MB: 66 50 34 18 2 Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from / boot/kernel/dtraceall.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtraceall.ko Reading symbols from /boot/kernel/profile.ko...Reading symbols from / boot/kernel/profile.ko.symbols...done. done. Loaded symbols for /boot/kernel/profile.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/cyclic.ko...Reading symbols from / boot/kernel/cyclic.ko.symbols...done. done. Loaded symbols for /boot/kernel/cyclic.ko Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from / boot/kernel/dtrace.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtrace.ko Reading symbols from /boot/kernel/systrace.ko...Reading symbols from / boot/kernel/systrace.ko.symbols...done. done. Loaded symbols for /boot/kernel/systrace.ko Reading symbols from /boot/kernel/sdt.ko...Reading symbols from /boot/ kernel/sdt.ko.symbols...done. done. Loaded symbols for /boot/kernel/sdt.ko Reading symbols from /boot/kernel/fbt.ko...Reading symbols from /boot/ kernel/fbt.ko.symbols...done. done. Loaded symbols for /boot/kernel/fbt.ko Reading symbols from /boot/kernel/dtnfsclient.ko...Reading symbols from /boot/kernel/dtnfsclient.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtnfsclient.ko Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from / boot/kernel/dtmalloc.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtmalloc.ko #0 doadump () at pcpu.h:223 223 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff80566b23 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:420 #2 0xffffffff80566fac in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xffffffff801d3ef7 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801d43a1 in db_command (last_cmdp=0xffffffff80bd3620, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801d45f0 in db_command_loop () at /usr/src/sys/ddb/ db_command.c:498 #6 0xffffffff801d6599 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff80597135 in kdb_trap (type=10, code=0, tf=0xfffffffe4e64e450) at /usr/src/sys/kern/subr_kdb.c:534 #8 0xffffffff80843f81 in trap (frame=0xfffffffe4e64e450) at /usr/src/ sys/amd64/amd64/trap.c:606 #9 0xffffffff8081edc7 in calltrap () at /usr/src/sys/amd64/amd64/ exception.S:223 #10 0xffffffff8123c128 in dtrace_panic (format=Variable "format" is not available. ) at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/ opensolaris/uts/common/dtrace/dtrace.c:601 #11 0xffffffff8123c200 in dtrace_copycheck (uaddr=18446744071581326184, kaddr=Variable "kaddr" is not available. ) at dtrace_isa.c:527 #12 0xffffffff8123c2bc in dtrace_copyinstr (uaddr=34365395808, kaddr=18446744066201920856, size=256, flags=0xffffffff8122f120) at dtrace_isa.c:558 #13 0xffffffff81249e84 in dtrace_dif_emulate (difo=0xffffff00026a2d80, mstate=0xfffffffe4e64ea00, vstate=0xffffff0002548838, state=0xffffff0002548800) at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/ opensolaris/uts/common/dtrace/dtrace.c:3446 #14 0xffffffff8124b20a in dtrace_probe (id=Variable "id" is not available. ) at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/ opensolaris/uts/common/dtrace/dtrace.c:6220 #15 0xffffffff8137b155 in systrace_probe () from /boot/kernel/ systrace.ko #16 0xffffffff80843c4d in syscall (frame=0xfffffffe4e64ec90) at /usr/ src/sys/amd64/amd64/trap.c:990 #17 0xffffffff8081f050 in Xfast_syscall () at /usr/src/sys/amd64/amd64/ exception.S:364 #18 0x00000008005411fc in ?? () Previous frame inner to this frame (corrupt stack?) Hope this helps to fix this bug - I assume syscall::open isn't the only probe affected as it's simply the very first one I tried. Same panic on two computers (a "real" one, A64 3200+, nForce4, 2GB RAM; and a Macbook Pro C2D running VMware Fusion). Same panic in 7.2 and 8.0. Regards, Thomas From dds at aueb.gr Wed May 13 13:04:17 2009 From: dds at aueb.gr (Diomidis Spinellis) Date: Wed May 13 13:31:23 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090513080926.175F37302F@freebsd-current.sentex.ca> References: <20090513080926.175F37302F@freebsd-current.sentex.ca> Message-ID: <4A0AC23E.2060005@aueb.gr> FreeBSD Tinderbox wrote: > TB --- 2009-05-13 07:04:55 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-05-13 07:04:55 - starting HEAD tinderbox run for mips/mips > TB --- 2009-05-13 07:04:55 - cleaning the object tree > TB --- 2009-05-13 07:05:48 - cvsupping the source tree > TB --- 2009-05-13 07:05:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile > TB --- 2009-05-13 07:05:56 - building world > TB --- 2009-05-13 07:05:56 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-05-13 07:05:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-05-13 07:05:56 - TARGET=mips > TB --- 2009-05-13 07:05:56 - TARGET_ARCH=mips > TB --- 2009-05-13 07:05:56 - TZ=UTC > TB --- 2009-05-13 07:05:56 - __MAKE_CONF=/dev/null > TB --- 2009-05-13 07:05:56 - cd /src > TB --- 2009-05-13 07:05:56 - /usr/bin/make -B buildworld >>>> World build started on Wed May 13 07:05:59 UTC 2009 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything > [...] > cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.bin/truss -I. -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/truss/mips-fbsd.c > /src/usr.bin/truss/mips-fbsd.c: In function 'mips_syscall_exit': > /src/usr.bin/truss/mips-fbsd.c:341: error: too few arguments to function 'print_syscall_ret' > *** Error code 1 > > Stop in /src/usr.bin/truss. > *** Error code 1 > > Stop in /src/usr.bin. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 Sorry, I missed syncing the code I wrote in January with the MIPS support introduced in February. I fixed it in r192040. Diomidis Spinellis From roberthuff at rcn.com Wed May 13 13:44:53 2009 From: roberthuff at rcn.com (Robert Huff) Date: Wed May 13 13:45:00 2009 Subject: Installation of FreeBSD 8.0-Current-2009-amd64-dvd In-Reply-To: <4A088642.3030402@freebsd.org> References: <4A088642.3030402@freebsd.org> Message-ID: <18954.52941.106357.651668@jerusalem.litteratus.org> Tim Kientzle writes: > It also helps to watch the freebsd-current mailing > list so you know when things are relatively calm. If you're actually going to track -CURRENT - instead of installing a working version that has necessary feature X and stuffing that machine back in the closet - I would say reading the mailing list is mandatory in everything but the literal sense. Reading hackers@ is also not a bad idea. Robert Huff From Achim_Leubner at adaptec.com Wed May 13 13:53:07 2009 From: Achim_Leubner at adaptec.com (Leubner, Achim) Date: Wed May 13 13:53:14 2009 Subject: softdep_move_dependencies panic In-Reply-To: <4A01C10F.4060805@samsco.org> References: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> <4A01C10F.4060805@samsco.org> Message-ID: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B72409D@ADPE2K703.adaptec.com> Thanks for the information. But could you please explain this workaround in detail? If I understand you correctly I should not remove the device with device_delete_child(). But how should I indicate that it has failed? And how can I complete the i/o with good status although the i/o did not work? Thanks, Achim -----Original Message----- From: Scott Long [mailto:scottl@samsco.org] Sent: Wednesday, May 06, 2009 6:56 PM To: Leubner, Achim Cc: Ed Maste; current@freebsd.org; Sridaran, Gana Subject: Re: softdep_move_dependencies panic No, there is no fix for this. FreeBSD doesn't handle this case very well. What I would suggest doing is keeping the logical representation of the device around, but indicate that it has failed. Then complete all i/o with good status. This is something that is being worked on, but I have no information on when it might be fixed. Scott Leubner, Achim wrote: > Hi Ed, Hi Scott, > > > > We run into a problem if a RAID array goes into an "error" state and is > marked "offline". The new aac driver removes the device in this case > with device_delete_child() and all commands to that device will be > answered using biodone() with flag BIO_ERROR and error EINVAL. But this > causes a "softdep_move_dependencies: need merge code" panic in the > filesystem. Is there any possibility to avoid this panic? We see it > under FreeBSD 7.1 too. > > Any help is greatly appreciated. > > > > Thanks & Regards, > > Achim > > > > =========================== > > Achim Leubner > > Software Engineer / RAID drivers > > ICP vortex GmbH / Adaptec Inc. > > Phone: +49-351-8718291 > > > From Achim_Leubner at adaptec.com Wed May 13 13:58:42 2009 From: Achim_Leubner at adaptec.com (Leubner, Achim) Date: Wed May 13 13:58:49 2009 Subject: softdep_move_dependencies panic In-Reply-To: References: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B67FCE8@ADPE2K703.adaptec.com> Message-ID: <532ABFBDAAC3A34EB12EBA6CEC2838F4020B72409F@ADPE2K703.adaptec.com> Unfortunately there is no complete dump during that panics. I only see some g_vfs_done() errors during WRITE like "g_vfs_done():aacdu0s1[WRITE(offset=98304, length=16384)]error = 22" and a "panic: softdep_move_dependencies: need merge code" at the end. Then the system hangs during dump. Thanks, Achim -----Original Message----- From: Jeff Roberson [mailto:jroberson@jroberson.net] Sent: Thursday, May 07, 2009 3:20 PM To: Leubner, Achim Cc: Ed Maste; Scott Long; current@freebsd.org; Sridaran, Gana Subject: Re: softdep_move_dependencies panic On Wed, 6 May 2009, Leubner, Achim wrote: > Hi Ed, Hi Scott, > > We run into a problem if a RAID array goes into an "error" state and is marked "offline". The new aac driver removes the device in this case with device_delete_child() and all commands to that device will be answered using biodone() with flag BIO_ERROR and error EINVAL. But this causes a "softdep_move_dependencies: need merge code" panic in the filesystem. Is there any possibility to avoid this panic? We see it under FreeBSD 7.1 too. > Any help is greatly appreciated. Hi Achim, Can you post the entire stack trace from the panic? Thanks, Jeff > > Thanks & Regards, > Achim > > > =========================== > > Achim Leubner > > Software Engineer / RAID drivers > > ICP vortex GmbH / Adaptec Inc. > > Phone: +49-351-8718291 > > _______________________________________________ > 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 glen.j.barber at gmail.com Wed May 13 14:08:43 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Wed May 13 14:08:49 2009 Subject: 8.0-current on virtualbox intel cards reports invalid mac In-Reply-To: <4A0AA1DA.5040903@o2.pl> References: <4A0AA1DA.5040903@o2.pl> Message-ID: <4ad871310905130641n5a6a3c2y7e1fb647225cd22f@mail.gmail.com> 2009/5/13 Bartosz Jakoktochce : > I'm running 8.0-CURRENT on VirtualBox 2.2.2 and noticed an error while > loading kernel. > > em0: port 0xc010-0xc017 mem > 0xf0000000-0xf001ffff irq 11 at device 3.0 on pci0 > em0: Invalid MAC address > device_attach: em0 attach returned 5 > > The 7.x and also 6.x work fine with this. > I remember seeing this problem in the archives a few weeks(?) back. Apparently there are a few em0 devices VirtualBox can use. I don't recall seeing a solution, but you should be able to come across it by searching the archives. HTH. -- Glen Barber From sam at freebsd.org Wed May 13 14:58:01 2009 From: sam at freebsd.org (Sam Leffler) Date: Wed May 13 14:58:08 2009 Subject: rum(4) not working on 8-CURRENT In-Reply-To: <200905131107.25115.Thomas.Sparrevohn@btinternet.com> References: <200905130922.52887.Thomas.Sparrevohn@btinternet.com> <200905131048.37146.hselasky@c2i.net> <200905131107.25115.Thomas.Sparrevohn@btinternet.com> Message-ID: <4A0ADFF3.5010308@freebsd.org> Thomas Sparrevohn wrote: > On Wednesday 13 May 2009 09:48:36 Hans Petter Selasky wrote: > >> On Wednesday 13 May 2009, Thomas Sparrevohn wrote: >> >>> Hans Petter >>> >>> I don't see this one came through - but I am having real pains with rum(4) >>> - the weird thing it that it seems to work with HTTP etc but not with fetch >>> - no panics - it just drops all connections and routing information - It am >>> still getting the "kernel: rum0: need multicast update callback" error but >>> I cannot see that it has anything to do with the issue >>> >> In my experience it's not the driver that is flaky, but the firmware in the >> hardware. I've seen several times that if certain commands are intermixed, >> the firmware will completely stop responding. >> >> Has the rum driver ever worked with USB2 and -current? Recently there has been >> several changes in the WLAN layer and some minor changes in if_rum. >> >> --HPS >> _______________________________________________ >> 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" >> >> > > The driver stopped when the USB2 changes was reverted some time ago - prior to that USB2 > worked fine e.g. when the dummy multicast was removed etc > All usb drivers are tested with any net80211 changes; at least in sta mode. Complaints about missing mcast and/or promisc support are because the drivers are missing code that breaks functionality. Silencing these printfs does nothing except bury problems so they are forgotten and never fixed. If you have problems w/ a wireless driver there are facilities to help; e.g. man wlandebug. Sam From jdl at jdl.com Wed May 13 16:49:42 2009 From: jdl at jdl.com (Jon Loeliger) Date: Wed May 13 16:49:54 2009 Subject: Building boot2 for ixp425 Message-ID: Folks, I'm following the instructions on the Wiki here: http://wiki.freebsd.org/FreeBSDAvila After successfully building FreeBSD current using nanobsd and placing it onto a Compact Flash, I am now trying to build the boot2 image so that I can boot it. The instructions say: Build a kernel configured to mount the file system from ad0. This is most easily done by copying the AVILA config file and stripping out the BOOTP* options. Which I did, placing a new "BOOT2" config file in /usr/src/sys/arm/conf. Then: Build the second level bootstrap program by entering the arm/xscale build environment and building sys/boot2/ixdp425: make TARGET_ARCH=arm TARGET_CPUTYPE=xscale \ TARGET_BIG_ENDIAN=true buildenv cd sys/boot/arm/ixp425/boot2/ make The problem arises from that make: # make Warning: Object directory not changed from original /usr/src/sys/boot/arm/ixp425/boot2 cc -O -pipe -mbig-endian -march=armv5te -D__XSCALE__ -DBOOT_STACK=0x200000-4 -I/usr/src/sys/boot/arm/ixp425/boot2/../../../common -I/usr/src/sys/boot/arm/ixp425/boot2 -DFIXUP_BOOT_DRV -Os -ffreestanding -I/usr/src/sys/boot/arm/ixp425/boot2/../../../.. -I/usr/src/sys/boot/arm/ixp425/boot2/../../../../arm -DCPU_XSCALE_IXP425 -Wall -Waggregate-return -Werror -Wnested-externs -Wpointer-arith -Wshadow -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -DBOOT_IXP425 -std=gnu99 -c arm_init.S cc1: error: unrecognized command line option "-mbig-endian" arm_init.S:0: error: bad value (armv5te) for -march= switch arm_init.S:0: error: bad value (armv5te) for -mtune= switch *** Error code 1 Stop in /usr/src/sys/boot/arm/ixp425/boot2. Any advice for the weary here? If I just strip the three offending flags from the Makefile, will it build properly? I'm dubious, except that there are also these in the environment now: TARGET_CPUTYPE=xscale CPUTYPE=xscale TARGET_BIG_ENDIAN=true MACHINE_ARCH=arm MAKEOBJDIRPREFIX=/usr/obj/arm MAKEFLAGS= TARGET_ARCH=arm TARGET_CPUTYPE=xscale TARGET_BIG_ENDIAN=true -m /usr/src/share/mk Thanks, jdl From jdl at jdl.com Wed May 13 16:57:20 2009 From: jdl at jdl.com (Jon Loeliger) Date: Wed May 13 16:57:26 2009 Subject: Building boot2 for ixp425 In-Reply-To: References: Message-ID: Follow up question... > The instructions say: > > Build a kernel configured to mount the file system from ad0. This is > most easily done by copying the AVILA config file and stripping out > the BOOTP* options. > > Which I did, placing a new "BOOT2" config file in /usr/src/sys/arm/conf. I forgot to ask the important question here. By the phrase "Build a kernel configured to ..." here, does it really mean a whole new "make buildworld" like this: make KERNCONF=BOOT2 TARGET=arm TARGET_CPUTYPE=xscale \ TARGET_BIG_ENDIAN=true buildworld or perhaps just: make KERNCONF=BOOT2 TARGET=arm TARGET_CPUTYPE=xscale \ TARGET_BIG_ENDIAN=true buildkernel make KERNCONF=BOOT2 TARGET=arm TARGET_CPUTYPE=xscale \ TARGET_BIG_ENDIAN=true DESTDIR=/some/where \ installkernel within the existing (from nanobsd) environment? Thanks, jdl From thompsa at FreeBSD.org Wed May 13 17:00:40 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Wed May 13 17:00:47 2009 Subject: Building boot2 for ixp425 In-Reply-To: References: Message-ID: <20090513170028.GA96051@citylink.fud.org.nz> On Wed, May 13, 2009 at 11:49:41AM -0500, Jon Loeliger wrote: > > Folks, > > I'm following the instructions on the Wiki here: > > http://wiki.freebsd.org/FreeBSDAvila > > After successfully building FreeBSD current using nanobsd > and placing it onto a Compact Flash, I am now trying to > build the boot2 image so that I can boot it. > > The instructions say: > > Build a kernel configured to mount the file system from ad0. This is > most easily done by copying the AVILA config file and stripping out > the BOOTP* options. > > Which I did, placing a new "BOOT2" config file in /usr/src/sys/arm/conf. > > Then: > > Build the second level bootstrap program by entering the arm/xscale > build environment and building sys/boot2/ixdp425: > > make TARGET_ARCH=arm TARGET_CPUTYPE=xscale \ > TARGET_BIG_ENDIAN=true buildenv > cd sys/boot/arm/ixp425/boot2/ > make > > The problem arises from that make: > > # make > Warning: Object directory not changed from original /usr/src/sys/boot/arm/ixp425/boot2 > cc -O -pipe -mbig-endian -march=armv5te -D__XSCALE__ -DBOOT_STACK=0x200000-4 -I/usr/src/sys/boot/arm/ixp425/boot2/../../../common -I/usr/src/sys/boot/arm/ixp425/boot2 -DFIXUP_BOOT_DRV -Os -ffreestanding -I/usr/src/sys/boot/arm/ixp425/boot2/../../../.. -I/usr/src/sys/boot/arm/ixp425/boot2/../../../../arm -DCPU_XSCALE_IXP425 -Wall -Waggregate-return -Werror -Wnested-externs -Wpointer-arith -Wshadow -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -DBOOT_IXP425 -std=gnu99 -c arm_init.S > cc1: error: unrecognized command line option "-mbig-endian" > arm_init.S:0: error: bad value (armv5te) for -march= switch > arm_init.S:0: error: bad value (armv5te) for -mtune= switch > *** Error code 1 > > Stop in /usr/src/sys/boot/arm/ixp425/boot2. Are you sure your cross compile toolchain is built? make TARGET_ARCH=arm TARGET_CPUTYPE=xscale \ TARGET_BIG_ENDIAN=true kernel-toolchain Andrew From jdl at jdl.com Wed May 13 17:05:20 2009 From: jdl at jdl.com (Jon Loeliger) Date: Wed May 13 17:05:27 2009 Subject: Building boot2 for ixp425 In-Reply-To: <20090513170028.GA96051@citylink.fud.org.nz> References: <20090513170028.GA96051@citylink.fud.org.nz> Message-ID: > > Are you sure your cross compile toolchain is built? I just build the whole set using the nanobsd.sh mechanism. It resulted in an arm kernel, so I'm assuming the toolchain is available. That said, I'm not sure how to *point* to it... Which may be the issue at the heart of my "Follow up question"? jdl From gb at unistra.fr Wed May 13 17:20:49 2009 From: gb at unistra.fr (Guy Brand) Date: Wed May 13 17:20:56 2009 Subject: [Fwd: Re: amd64 suspend/resume broken on current] In-Reply-To: <200905111602.20462.jkim@FreeBSD.org> References: <4A058B5C.3010707@FreeBSD.org> <200905111529.12808.jkim@FreeBSD.org> <200905111602.20462.jkim@FreeBSD.org> Message-ID: <20090513171851.GA2582@unistra.fr> Jung-uk Kim (jkim@FreeBSD.org) on 11/05/2009 at 16:02 wrote: Hello > Can you try the attached patch? I may be wrong cause I am not a > firewire guru, though. I can, but I updated (csup) my sources yesterday and resuming works fine again without your patch applied. I now have: FreeBSD 8.0-CURRENT #12: Wed May 13 11:22:30 CEST 2009 ... acpi_lid0: Lid closed fwohci0: fwohci_pci_suspend acpi_ec0: warning: EC done before starting event wait stray irq0 ugen0.2: at usbus0 (disconnected) ugen4.2: at usbus4 (disconnected) wpi0: could not lock memory wpi0: could not lock memory wpi0: could not lock memory wpi0: could not lock memory wpi0: could not lock memory wpi0: could not lock memory wpi0: could not lock memory wpi0: could not lock memory wpi0: timeout waiting for master fwohci0: device physically ejected? uhci_interrupt: resume detect fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? wlan0: link state changed to DOWN fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? ugen0.2: at usbus0 fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: device physically ejected? fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 fwohci0: unrecoverable error so the repeating fwohci0 stops and the system is working fine. I only had to apply you two line patch to fix sys/netinet/in.c to get network devices working properly, but that's another issue. All the best -- bug From thompsa at FreeBSD.org Wed May 13 17:50:06 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Wed May 13 17:50:12 2009 Subject: Building boot2 for ixp425 In-Reply-To: References: <20090513170028.GA96051@citylink.fud.org.nz> Message-ID: <20090513175000.GA2635@citylink.fud.org.nz> On Wed, May 13, 2009 at 12:05:15PM -0500, Jon Loeliger wrote: > > > > Are you sure your cross compile toolchain is built? > > I just build the whole set using the nanobsd.sh mechanism. > It resulted in an arm kernel, so I'm assuming the toolchain > is available. It may be that nanobsd puts the obj files in a different location. > That said, I'm not sure how to *point* to it... The buildenv command is the one that spawns a new shell with all the correct paths to use the new compiler. just do the kernel-toolchain before it, as in. make TARGET_ARCH=arm TARGET_CPUTYPE=xscale \ TARGET_BIG_ENDIAN=true kernel-toolchain make TARGET_ARCH=arm TARGET_CPUTYPE=xscale \ TARGET_BIG_ENDIAN=true buildenv cd sys/boot/arm/ixp425/boot2/ make That should work :) Andrew From sam at freebsd.org Wed May 13 17:51:02 2009 From: sam at freebsd.org (Sam Leffler) Date: Wed May 13 17:51:09 2009 Subject: Building boot2 for ixp425 In-Reply-To: References: <20090513170028.GA96051@citylink.fud.org.nz> Message-ID: <4A0B0884.7020901@freebsd.org> Jon Loeliger wrote: >> >> Are you sure your cross compile toolchain is built? >> > > I just build the whole set using the nanobsd.sh mechanism. > It resulted in an arm kernel, so I'm assuming the toolchain > is available. > > That said, I'm not sure how to *point* to it... > > Which may be the issue at the heart of my "Follow up question"? > The wiki instructions assume you've first done a cross-buildworld which sets up the toolchain required for the subsequent buildkernel and boot2 build. I can't recall if buildkernel will build a toolchain if it's not available but I do recall that boot2 will not build w/o a full toolchain build because it drags in something the kernel does not. I think "make toolchain" will get the bits required. The nanobsd build results will not be used because they go in a different tree under /usr/obj (if I recall). These instructions were written pre-nanobsd support and likely need some TLC and/or need to be split up. Sam From lists at jnielsen.net Wed May 13 18:04:09 2009 From: lists at jnielsen.net (John Nielsen) Date: Wed May 13 18:04:16 2009 Subject: ethernet interface ed1 In-Reply-To: <20090510171111.GA1516@Harvard.lordofunix.org> References: <20090510171111.GA1516@Harvard.lordofunix.org> Message-ID: <200905131404.07033.lists@jnielsen.net> On Sunday 10 May 2009 01:11:11 pm Jose Luis Alarcon Sanchez wrote: > my computer have only one ethernet interface, only one card attached. > But FreeBSD-CURRENT detect it like ed1. Why this interface, and not > ed0?. This can happen if the kernel is configured to look for a non-PnP card which (if found) would be ed0. Assuming your card IS PnP, check your /boot/device.hints and remove any entries that refer to ed0. > All the RELEASES installed in the same computer, detected the ethernet > card like ed0. JN From sullrich at gmail.com Wed May 13 18:13:12 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Wed May 13 18:13:18 2009 Subject: ethernet interface ed1 In-Reply-To: <200905131404.07033.lists@jnielsen.net> References: <20090510171111.GA1516@Harvard.lordofunix.org> <200905131404.07033.lists@jnielsen.net> Message-ID: On Wed, May 13, 2009 at 2:04 PM, John Nielsen wrote: > This can happen if the kernel is configured to look for a non-PnP card > which (if found) would be ed0. Assuming your card IS PnP, check > your /boot/device.hints and remove any entries that refer to ed0. What happens if you remove hint.ed.0.disabled="1" from /boot/device.hints ? Scott From saifi.khan at twincling.org Wed May 13 19:19:31 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Wed May 13 19:19:38 2009 Subject: howto sidestep sysinstall during installation In-Reply-To: References: <4A07E966.60503@unsane.co.uk> Message-ID: On Mon, 11 May 2009, Vincent Hoffman wrote: > > > > Is there a way to sidestep the sysinstall during the > > > installation process, beyond selecting the 'location' ? > > > > > > > > Since you are using the snapshot DVD you should have the live/fixit > > environment which is very handy for this. > > I would suggest a combination of LOTS of reading and understanding of > > the pages at > > http://typo.submonkey.net/articles/2006/04/13/installing-freebsd-on-usb-stick-episode-2 > > (which goes though the steps for partitoning and installing using fdisk > > and bsdlabel, adjust paths to your dvd-rom) Thanks Vince for the link that was a nice starting point. Thanks to everybody who chipped in with pointers and help with learning the various concepts. Using the Fixit# console (LiveDVD) i could install FreeBSD 200905 snapshot (bypassed the sysinstall). i plan to write an article on the experience shortly. Since then, i've installed the following software: . xorg X 7.4 meta port (complete) . postgresql 8.3.7 . apache 2.2.11 . diablo-jdk 1.6.0 . opera 9.64 . dwm + many others. There were two errors/quirks that i noticed. http://www.flickr.com/photos/saifi/sets/72157618010835543/ 1. crash encountered while running sysinstall from the booted up system. 2. same crash encountered while running 'make fetch' for many of the ports. (rather random in occurence). Anybody encountered this issue ? thanks Saifi. From saifi.khan at twincling.org Wed May 13 19:24:00 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Wed May 13 19:24:06 2009 Subject: Scala Message-ID: Hi: just tried out Scala 2.8.0 svn r17711 revision with Diablo Java HotSpot(TM) Client VM 1.6.0_07 and it works awesome on the FreeBSD 8.0 200905 i386 snapshot. However, while running the 'ant test', i noticed that java tops out at 274MB heap size with 31 threads (falls to 29 threads after approx 5min and stays there) . Interestingly, the state in 'top' is shown as 'ucond'. Is this pthread_cond_wait_ or something, where the VM thread is deadlocked ? Any work around to this issue ? I also noticed that the recent ports checkin is Scala 2.7.3 http://www.freebsd.org/cgi/query-pr.cgi?pr=133887 May be, Scala 2.7.4 can be fast tracked to the ports. Can somebody point out to a template for the ports directory tree layout ? Is there a location to place bleeding edge ports? thanks Saifi. From mel.flynn+fbsd.current at mailing.thruhere.net Wed May 13 19:57:42 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Wed May 13 19:57:48 2009 Subject: newsyslog(8) patch for both size and time checks In-Reply-To: <4A09F850.2080208@freebsd.org> References: <4A09F850.2080208@freebsd.org> Message-ID: <200905132157.14906.mel.flynn+fbsd.current@mailing.thruhere.net> On Wednesday 13 May 2009 00:29:36 Tim Kientzle wrote: > Garance A Drosehn wrote: > > At 1:59 PM +0400 5/12/09, Dmitry Morozovsky wrote: > >> for now, if log is configured to be rotated in time manner, its size > >> is not checked ... > >> > >> The following simple patch should fix the problem. Any objection to > >> commit this? > > > > It would fix your problem, but it changes the behavior as is explicitly > > documented in 'man newsyslog.conf' . There is a paragraph in the man > > page which makes it clear that if both fields are specified, then the > > log file will only be rotated if both conditions are true. > > I've never liked that paragraph and find the > documented behavior is much less useful than the > proposed behavior. I rotate maillogs on not so busy machines using this functionality. The reasoning behind it is that I keep a limited number of logs available and if for some reason the machine starts spewing a lot of mail, I still want to know when it started. I also don't see the point of compressing/rotating 1-10 lines if the machine only sends out the periodic mails, hence this works peachy. > If compatibility is essential, perhaps we could > add a new flag to control this behavior. (I would > argue for changing the default and providing a flag > to obtain the old behavior.) Fine on the flag, maybe mergemaster could be a little more assisting in this case, since I'm not looking forward to "just adding a flag". Like mergemaster -p could auto-upgrade the lines that have both columns with values? -- Mel From glarkin at FreeBSD.org Wed May 13 20:46:43 2009 From: glarkin at FreeBSD.org (Greg Larkin) Date: Wed May 13 20:47:15 2009 Subject: Scala In-Reply-To: References: Message-ID: <4A0B2940.8090405@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Saifi Khan wrote: > Hi: > > just tried out Scala 2.8.0 svn r17711 revision with Diablo Java > HotSpot(TM) Client VM 1.6.0_07 and it works awesome on the > FreeBSD 8.0 200905 i386 snapshot. > > However, while running the 'ant test', i noticed that java > tops out at 274MB heap size with 31 threads (falls to 29 threads > after approx 5min and stays there) . > > Interestingly, the state in 'top' is shown as 'ucond'. > Is this pthread_cond_wait_ or something, where the VM thread is > deadlocked ? > > Any work around to this issue ? > > I also noticed that the recent ports checkin is Scala 2.7.3 > http://www.freebsd.org/cgi/query-pr.cgi?pr=133887 > > May be, Scala 2.7.4 can be fast tracked to the ports. > > Can somebody point out to a template for the ports directory > tree layout ? Is there a location to place bleeding edge ports? > > > thanks > Saifi. Hi Saifi, Coincidentally, I have been working on the Scala port PR today, and I also saw that it has been updated to 2.7.4. I modified the PR patch to upgrade to that version. I'm in the process of testing out the port on the various platform and OS version combinations. I expect to commit it to the tree in the next few days. If there are any FreeBSD-specific patches that should be added to the port to fix the problem that you noted above, please send them to me. I'm no expert on OS internals, so I'll leave your question to the good folks on the -current mailing list. Cheers, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKCylA0sRouByUApARAiG5AJ9bDWvPbu0w3xR/BjI9EHTMKpRa+ACdHB/S M6qVPsL3+QxFfVgGfzQWOGE= =cMSJ -----END PGP SIGNATURE----- From gperez at entel.upc.edu Wed May 13 21:42:39 2009 From: gperez at entel.upc.edu (=?ISO-8859-1?Q?Gustau_P=E9rez?=) Date: Wed May 13 21:42:46 2009 Subject: commit r191990 seems to break fusefs-kmod Message-ID: <4A0C8F8B.1090602@entel.upc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, commit r191990 seems to break fusefs-kmod. When recompiling the port the error I get is : fuse_vfsops.c:218: error: conflicting types for 'fuse_mount' fuse_vfsops.c:51: error: previous declaration of 'fuse_mount' was here fuse_vfsops.c:534: error: conflicting types for 'fuse_unmount' fuse_vfsops.c:52: error: previous declaration of 'fuse_unmount' was here fuse_vfsops.c:638: error: conflicting types for 'fuse_root' fuse_vfsops.c:53: error: previous declaration of 'fuse_root' was here fuse_vfsops.c:687: error: conflicting types for 'fuse_statfs' fuse_vfsops.c:54: error: previous declaration of 'fuse_statfs' was here fuse_vfsops.c:802:38: error: macro "VFS_ROOT" passed 4 arguments, but takes just 3 fuse_vfsops.c: In function 'fuse_vget_i': fuse_vfsops.c:802: error: 'VFS_ROOT' undeclared (first use in this function) fuse_vfsops.c:802: error: (Each undeclared identifier is reported only once fuse_vfsops.c:802: error: for each function it appears in.) *** Error code 1 I'm CC port maintainer because I have the feeling this is the desired behavior. Regards, Gustau - -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoMj4oACgkQAvcpDulVChCsMwCeKZyDuKtd4f+zO