From jhs at berklix.com Wed Jul 1 01:09:59 2009 From: jhs at berklix.com (Julian H. Stacey) Date: Wed Jul 1 01:10:12 2009 Subject: umount -f implementation In-Reply-To: Your message "Tue, 30 Jun 2009 14:58:39 PDT." <200906302158.n5ULwdxk002480@chez.mckusick.com> Message-ID: <200907010048.n610mPem058027@fire.js.berklix.net> Kirk McKusick wrote: > forced unmounts. The gentle force (-f) and the brute force (-F) > unmount. -F Would also be nice for devd.conf detach, for when people forget & pull a USB stick without unmounting first. Better a corrupt stick than a crashed OS. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys. Eng. Consultant Munich http://berklix.com Mail in plain ASCII text, HTML & Base64 are spam. http://asciiribbon.org From js at alien8.de Wed Jul 1 01:12:32 2009 From: js at alien8.de (Julian Stecklina) Date: Wed Jul 1 01:13:39 2009 Subject: 8-CURRENT Firewire References: <1246316092.3981.11.camel@Lappy> Message-ID: <87hbxxp5ot.fsf@tabernacle.lan> Sean Bruno writes: > -CURRENT has some slightly different Firewire code in it than 6/7. If > you have an opportunity to test it with your Firewire hard drives and > cameras I'd really appreciate it. > > Stuff that's changed: > multi-speed compatible devices will acutally work. > a 400/800 device is connected to a 400/800 compatible > firewire card via a 400 connection will work at 400 > fwcontrol understands multiple firewire cards as multiple > buses now. most commands now take a -u argument to > indicate the bus. > > Please report to the -firewire if you get a chance to test. It would > be great to get positive as well as negative results. I have an AMD 780G board with onboard Firewire controller. 8-CURRENT hangs at boot with: run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config ... If I disable the Firewire controller in the BIOS it boots fine. What is a good way to debug this? Regards, -- Julian Stecklina The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners - Ernst Jan Plugge From mel.flynn+fbsd.current at mailing.thruhere.net Wed Jul 1 01:53:26 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Wed Jul 1 01:53:33 2009 Subject: Interface dependencies In-Reply-To: <200906291241.56414.mel.flynn+fbsd.current@mailing.thruhere.net> References: <200906271948.54745.mel.flynn+fbsd.current@mailing.thruhere.net> <20090629144205.GA83592@lor.one-eyed-alien.net> <200906291241.56414.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <200906301753.24089.mel.flynn+fbsd.current@mailing.thruhere.net> On Monday 29 June 2009 12:41:55 Mel Flynn wrote: > I'll revert to what it "should really be" and keep rc_debug. Well, guess what. It now works: cloned_interfaces="lagg0" ifconfig_wpi0="ether 00:16:36:f2:3b:84" wlans_wpi0="wlan0" ifconfig_wlan0="WPA" ifconfig_em0="up" ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 192.168.2.50 netmask 255.255.255.0" This didn't work ~week or so ago, the exact same lines. I didn't have rc_debug on at the time and the /var/log/messages is gone anyway :(. The kernel didn't really change either (I went from a custom copy+delete one to an include GENERIC with a lot of nodevice/nooptions, but with the same result), so I'm stumped. Maybe r195029 fixed this too. -- Mel From tinderbox at freebsd.org Wed Jul 1 07:02:33 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Jul 1 07:02:50 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090701070230.076767302F@freebsd-current.sentex.ca> TB --- 2009-07-01 05:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-01 05:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-07-01 05:00:00 - cleaning the object tree TB --- 2009-07-01 05:01:03 - cvsupping the source tree TB --- 2009-07-01 05:01:03 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-07-01 05:01:10 - building world TB --- 2009-07-01 05:01:10 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-01 05:01:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-01 05:01:10 - TARGET=amd64 TB --- 2009-07-01 05:01:10 - TARGET_ARCH=amd64 TB --- 2009-07-01 05:01:10 - TZ=UTC TB --- 2009-07-01 05:01:10 - __MAKE_CONF=/dev/null TB --- 2009-07-01 05:01:10 - cd /src TB --- 2009-07-01 05:01:10 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 1 05:01:12 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Jul 1 07:01:31 UTC 2009 TB --- 2009-07-01 07:01:31 - generating LINT kernel config TB --- 2009-07-01 07:01:31 - cd /src/sys/amd64/conf TB --- 2009-07-01 07:01:31 - /usr/bin/make -B LINT TB --- 2009-07-01 07:01:31 - building LINT kernel TB --- 2009-07-01 07:01:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-01 07:01:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-01 07:01:31 - TARGET=amd64 TB --- 2009-07-01 07:01:31 - TARGET_ARCH=amd64 TB --- 2009-07-01 07:01:31 - TZ=UTC TB --- 2009-07-01 07:01:31 - __MAKE_CONF=/dev/null TB --- 2009-07-01 07:01:31 - cd /src TB --- 2009-07-01 07:01:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 1 07:01:31 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 -------------------------------------------------------------- cd /obj/amd64/src/sys/LINT; MAKEOBJDIRPREFIX=/obj/amd64 MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/obj/amd64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/amd64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/amd64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/amd64/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 800003" INSTALL="sh /src/tools/install.sh" PATH=/obj/amd64/src/tmp/legacy/usr/sbin:/obj/amd64/src/tmp/legacy/usr/bin:/obj/amd64/src/tmp/legacy/usr/games:/obj/amd64/src/tmp/usr/sbin:/obj/amd64/src/tmp/usr/bin:/obj/amd64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 /usr/bin/make KERNEL=kernel depend -DNO_MODULES_OBJ machine -> /src/sys/amd64/include cc -c -O2 -frename-registers -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/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -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 /src/sys/amd64/amd64/g enassym.c /src/sys/amd64/amd64/genassym.c:67:23: error: nfs/rpcv2.h: No such file or directory *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-01 07:02:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-01 07:02:29 - ERROR: failed to build lint kernel TB --- 2009-07-01 07:02:29 - 5708.16 user 602.27 system 7349.05 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From dfr at rabson.org Wed Jul 1 08:30:38 2009 From: dfr at rabson.org (Doug Rabson) Date: Wed Jul 1 08:30:50 2009 Subject: [head tinderbox] failure on amd64/amd64 In-Reply-To: <20090701070230.076767302F@freebsd-current.sentex.ca> References: <20090701070230.076767302F@freebsd-current.sentex.ca> Message-ID: Fixed. On 1 Jul 2009, at 08:02, FreeBSD Tinderbox wrote: > TB --- 2009-07-01 05:00:00 - tinderbox 2.6 running on freebsd- > current.sentex.ca > TB --- 2009-07-01 05:00:00 - starting HEAD tinderbox run for amd64/ > amd64 > TB --- 2009-07-01 05:00:00 - cleaning the object tree > TB --- 2009-07-01 05:01:03 - cvsupping the source tree > TB --- 2009-07-01 05:01:03 - /usr/bin/csup -z -r 3 -g -L 1 -h > localhost -s /tinderbox/HEAD/amd64/amd64/supfile > TB --- 2009-07-01 05:01:10 - building world > TB --- 2009-07-01 05:01:10 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-07-01 05:01:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-07-01 05:01:10 - TARGET=amd64 > TB --- 2009-07-01 05:01:10 - TARGET_ARCH=amd64 > TB --- 2009-07-01 05:01:10 - TZ=UTC > TB --- 2009-07-01 05:01:10 - __MAKE_CONF=/dev/null > TB --- 2009-07-01 05:01:10 - cd /src > TB --- 2009-07-01 05:01:10 - /usr/bin/make -B buildworld >>>> World build started on Wed Jul 1 05:01:12 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 >>>> stage 5.1: building 32 bit shim libraries >>>> World build completed on Wed Jul 1 07:01:31 UTC 2009 > TB --- 2009-07-01 07:01:31 - generating LINT kernel config > TB --- 2009-07-01 07:01:31 - cd /src/sys/amd64/conf > TB --- 2009-07-01 07:01:31 - /usr/bin/make -B LINT > TB --- 2009-07-01 07:01:31 - building LINT kernel > TB --- 2009-07-01 07:01:31 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-07-01 07:01:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-07-01 07:01:31 - TARGET=amd64 > TB --- 2009-07-01 07:01:31 - TARGET_ARCH=amd64 > TB --- 2009-07-01 07:01:31 - TZ=UTC > TB --- 2009-07-01 07:01:31 - __MAKE_CONF=/dev/null > TB --- 2009-07-01 07:01:31 - cd /src > TB --- 2009-07-01 07:01:31 - /usr/bin/make -B buildkernel > KERNCONF=LINT >>>> Kernel build for LINT started on Wed Jul 1 07:01:31 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 > -------------------------------------------------------------- > cd /obj/amd64/src/sys/LINT; MAKEOBJDIRPREFIX=/obj/amd64 > MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/obj/ > amd64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/amd64/src/tmp/ > legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/amd64/src/tmp/ > legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/amd64/src/tmp > VERSION="FreeBSD 8.0-CURRENT i386 800003" INSTALL="sh /src/tools/ > install.sh" PATH=/obj/amd64/src/tmp/legacy/usr/sbin:/obj/amd64/src/ > tmp/legacy/usr/bin:/obj/amd64/src/tmp/legacy/usr/games:/obj/amd64/ > src/tmp/usr/sbin:/obj/amd64/src/tmp/usr/bin:/obj/amd64/src/tmp/usr/ > games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 /usr/bin/make > KERNEL=kernel depend -DNO_MODULES_OBJ > machine -> /src/sys/amd64/include > cc -c -O2 -frename-registers -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/ipfilter -I/src/sys/contrib/pf - > I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ > ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/ > gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/ > opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL - > DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline- > limit=8000 --param inline-unit-growth=100 --param large-function- > growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno- > builtin -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 /src/sys/amd64/amd64/g > enassym.c > /src/sys/amd64/amd64/genassym.c:67:23: error: nfs/rpcv2.h: No such > file or directory > *** Error code 1 > > Stop in /obj/amd64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-07-01 07:02:29 - WARNING: /usr/bin/make returned exit > code 1 > TB --- 2009-07-01 07:02:29 - ERROR: failed to build lint kernel > TB --- 2009-07-01 07:02:29 - 5708.16 user 602.27 system 7349.05 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 > " From rwatson at FreeBSD.org Wed Jul 1 08:48:42 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jul 1 08:48:49 2009 Subject: 8-CURRENT Firewire In-Reply-To: <87hbxxp5ot.fsf@tabernacle.lan> References: <1246316092.3981.11.camel@Lappy> <87hbxxp5ot.fsf@tabernacle.lan> Message-ID: On Wed, 1 Jul 2009, Julian Stecklina wrote: >> -CURRENT has some slightly different Firewire code in it than 6/7. If you >> have an opportunity to test it with your Firewire hard drives and cameras >> I'd really appreciate it. >> >> Stuff that's changed: >> multi-speed compatible devices will acutally work. >> a 400/800 device is connected to a 400/800 compatible >> firewire card via a 400 connection will work at 400 >> fwcontrol understands multiple firewire cards as multiple >> buses now. most commands now take a -u argument to >> indicate the bus. >> >> Please report to the -firewire if you get a chance to test. It would be >> great to get positive as well as negative results. > > I have an AMD 780G board with onboard Firewire controller. 8-CURRENT hangs > at boot with: > > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > ... > > If I disable the Firewire controller in the BIOS it boots fine. What is a > good way to debug this? I've seen similar reports of this on 7.x; Richard Clayton has a box that has done this since at least 7.1, and it's one of the reasons I added the debugging output above :-). Unfortunately, it's not in an easy position to debug on that box. Robert N M Watson Computer Laboratory University of Cambridge From james-freebsd-current at jrv.org Wed Jul 1 09:21:54 2009 From: james-freebsd-current at jrv.org (James R. Van Artsdalen) Date: Wed Jul 1 09:22:00 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A49EA94.3070109@FreeBSD.org> References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> <4A48D136.3050309@haruhiism.net> <4A48D551.5090509@FreeBSD.org> <4A49E7A3.70509@haruhiism.net> <4A49EA94.3070109@FreeBSD.org> Message-ID: <4A4B2A90.8090300@jrv.org> Has anyone found any PCI-X or PCI cards that do AHCI? Or a PCI-Express, PCI-X or PCI card that supports AHCI & FIS-based switching for port multipliers? I'm trying to set up to test this but the only AHCI cards I've found are based on the Jmicron chips, which are PCI-e only, no more than 2 SATA ports, and don't do FIS-based switching. PS. I understand FIS-based switching isn't there yet but I assume it will be. From mav at FreeBSD.org Wed Jul 1 09:39:58 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Jul 1 09:40:04 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A4B2A90.8090300@jrv.org> References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> <4A48D136.3050309@haruhiism.net> <4A48D551.5090509@FreeBSD.org> <4A49E7A3.70509@haruhiism.net> <4A49EA94.3070109@FreeBSD.org> <4A4B2A90.8090300@jrv.org> Message-ID: <4A4B2EE6.2080501@FreeBSD.org> James R. Van Artsdalen wrote: > Has anyone found any PCI-X or PCI cards that do AHCI? Or a PCI-Express, > PCI-X or PCI card that supports AHCI & FIS-based switching for port > multipliers? > > I'm trying to set up to test this but the only AHCI cards I've found are > based on the Jmicron chips, which are PCI-e only, no more than 2 SATA > ports, and don't do FIS-based switching. > > PS. I understand FIS-based switching isn't there yet but I assume it > will be. I still haven't found any AHCI card with FBS support. Ideas welcome. I am working on driver for SiI3124/3132. I haven't tested yet how fast they really are (3132 is quite cheap), but they declare PM with FBS support. First one is 4-port PCI-X, second - 2-port PCIe. -- Alexander Motin From mexas at bristol.ac.uk Wed Jul 1 10:57:43 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 1 10:57:52 2009 Subject: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> Message-ID: <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> On Thu, Jun 25, 2009 at 09:41:13AM -0700, Marcel Moolenaar wrote: > > On Jun 25, 2009, at 4:02 AM, Anton Shterenlikht wrote: > > dev_taste(DEV,mirror/gm0) > > g_part_taste(PART,mirror/gm0) > > > > GEOM: mirror/gm0: the secondary GPT table is corrupt or invalid. > > GEOM: mirror/gm0: using the primary only -- recovery suggested. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > You created the mirror after the GPT, which means you destroyed > the GPT backup header. gmirror uses the last sector on the disk > for metadata and that by itself is a cause for various problems. > > It's better to use gmirror per partition. Like this? # gmirror label -vb round-robin root /dev/da0p2 gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. # I've read some boot disk gmirror examples, e.g. http://people.freebsd.org/~rse/mirror however, all examples I've seen are for i386, talking about MBR, fdisk and bsdlabel, so these are not directly applicable to ia64. Application of gvinum for boot disk on ia64 is not clear either. It seems gvinum section of the handbook, 21.9, is also based on i386. Please advise many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From js at alien8.de Wed Jul 1 11:45:39 2009 From: js at alien8.de (Julian Stecklina) Date: Wed Jul 1 11:45:51 2009 Subject: 8-CURRENT Firewire In-Reply-To: (Robert Watson's message of "Wed\, 1 Jul 2009 09\:48\:38 +0100 \(BST\)") References: <1246316092.3981.11.camel@Lappy> <87hbxxp5ot.fsf@tabernacle.lan> Message-ID: <87d48k1va7.fsf@tabernacle.lan> Robert Watson writes: > On Wed, 1 Jul 2009, Julian Stecklina wrote: > >>> -CURRENT has some slightly different Firewire code in it than 6/7. >>> If you have an opportunity to test it with your Firewire hard >>> drives and cameras I'd really appreciate it. >>> >>> Stuff that's changed: >>> multi-speed compatible devices will acutally work. >>> a 400/800 device is connected to a 400/800 compatible >>> firewire card via a 400 connection will work at 400 >>> fwcontrol understands multiple firewire cards as multiple >>> buses now. most commands now take a -u argument to >>> indicate the bus. >>> >>> Please report to the -firewire if you get a chance to test. It >>> would be great to get positive as well as negative results. >> >> I have an AMD 780G board with onboard Firewire controller. 8-CURRENT >> hangs at boot with: >> >> run_interrupt_driven_hooks: still waiting after 60 seconds for >> xpt_config run_interrupt_driven_hooks: still waiting after 120 >> seconds for xpt_config ... >> >> If I disable the Firewire controller in the BIOS it boots fine. What >> is a good way to debug this? > > I've seen similar reports of this on 7.x; Richard Clayton has a box > that has done this since at least 7.1, and it's one of the reasons I > added the debugging output above :-). Unfortunately, it's not in an > easy position to debug on that box. Is there any other way I can help to resolve this? Regards, -- Julian Stecklina The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners - Ernst Jan Plugge From mexas at bristol.ac.uk Wed Jul 1 12:20:22 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 1 12:20:29 2009 Subject: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <4A4B4FFE.7010400@jrv.org> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <4A4B4FFE.7010400@jrv.org> Message-ID: <20090701122015.GA62937@mech-cluster238.men.bris.ac.uk> On Wed, Jul 01, 2009 at 07:01:02AM -0500, James R. Van Artsdalen wrote: > Anton Shterenlikht wrote: > > Like this? > > > > # gmirror label -vb round-robin root /dev/da0p2 > > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > > # > > > > Is there a filesystem already mounted from da0p2? yes, da0 is the disk on which I installed the system. > Use gmirror label immediately after using gpart to create da0p2 then > always use /dev/mirror/root as the device after that, never da0p2, ie > > # gpart add -b 162 -s 1048576 -t freebsd-ufs ad0 wow! gpart is never mentioned in the handbook, neither in GEOM, nor in gvinum chapter. Is the handbook a bit out of date? > # gmirror label -vb round-robin root /dev/da0p2 > > # newfs /dev/mirror/root > > The examples from the gpart and gmirror man pages worked for me. are you using ia64? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From ianf at clue.co.za Wed Jul 1 13:50:40 2009 From: ianf at clue.co.za (Ian Freislich) Date: Wed Jul 1 13:50:48 2009 Subject: kgdb on an amd64 kernel anyone? Message-ID: Hi Has anyone managed to inspect a vmcore produced by an amd64 kernel in the last few months? I've had several crashes, but all the cores appear corrupted and no useful data can be had. The latest: [firewall2.jnb1] /var/crash # kgdb -c vmcore.5 /boot/kernel.old/kernel 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"...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0x0000000000000000 in ?? () (kgdb) bt #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 Or this followed by pages and pages stack corruption. The most frames I've had the patience to scroll through like this is in the 0000s. [firewall1.jnb1] /var/db/firewall # kgdb -c /var/crash/vmcore.4 /boot/kernel/kernel 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"...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xffffffff802bdb8a in doadump () (kgdb) bt #0 0xffffffff802bdb8a in doadump () #1 0xffffff81a4af95f0 in ?? () #2 0xffffffff802be0bb in boot () #3 0xe880695fa0c7c748 in ?? () #4 0x9066eaebfff07554 in ?? () #5 0x31804b26a0c7c748 in ?? () #6 0xc3c900033ee2e8c0 in ?? () #7 0x56415741e5894855 in ?? () #8 0x48fb895354415541 in ?? () #9 0x253c8b486528ec83 in ?? () #10 0x000119b900000000 in ?? () #11 0x804b26d8c2c74800 in ?? () #12 0x65ffff14b1e8f631 in ?? () #13 0x00000000253c8b48 in ?? () #14 0x65000235f1e8f631 in ?? () #15 0x0000000025148b48 in ?? () #16 0x450c608b44028b48 in ?? () #17 0x000004cd840fe485 in ?? () #18 0x00000025348b4865 in ?? () #19 0xe80c49ff0e8b4800 in ?? () #20 0x68c7c74800148304 in ?? () #21 0x05c7df89418048c1 in ?? () #22 0x00000001003d81e8 in ?? () ---Type to continue, or q to quit---q The last useful crashdump I've had was before February this year. Do others share this experience? Ian -- Ian Freislich From serenity at exscape.org Wed Jul 1 13:54:39 2009 From: serenity at exscape.org (Thomas Backman) Date: Wed Jul 1 13:54:47 2009 Subject: kgdb on an amd64 kernel anyone? In-Reply-To: References: Message-ID: <3EF4C954-2A84-42BA-B0F5-629B3CCC1578@exscape.org> On Jul 1, 2009, at 03:50 PM, Ian Freislich wrote: > Hi > > Has anyone managed to inspect a vmcore produced by an amd64 kernel > in the last few months? I've had several crashes, but all the cores > appear corrupted and no useful data can be had. > > The latest: > > [firewall2.jnb1] /var/crash # kgdb -c vmcore.5 /boot/kernel.old/kernel > 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"...(no debugging > symbols found)... > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > #0 0x0000000000000000 in ?? () > (kgdb) bt > #0 0x0000000000000000 in ?? () > Cannot access memory at address 0x0 > > Or this followed by pages and pages stack corruption. The most > frames I've had the patience to scroll through like this is in the > 0000s. > > [firewall1.jnb1] /var/db/firewall # kgdb -c /var/crash/vmcore.4 / > boot/kernel/kernel > 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"...(no debugging > symbols found)... > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > #0 0xffffffff802bdb8a in doadump () > (kgdb) bt > #0 0xffffffff802bdb8a in doadump () > #1 0xffffff81a4af95f0 in ?? () > #2 0xffffffff802be0bb in boot () > #3 0xe880695fa0c7c748 in ?? () > #4 0x9066eaebfff07554 in ?? () > #5 0x31804b26a0c7c748 in ?? () > #6 0xc3c900033ee2e8c0 in ?? () > #7 0x56415741e5894855 in ?? () > #8 0x48fb895354415541 in ?? () > #9 0x253c8b486528ec83 in ?? () > #10 0x000119b900000000 in ?? () > #11 0x804b26d8c2c74800 in ?? () > #12 0x65ffff14b1e8f631 in ?? () > #13 0x00000000253c8b48 in ?? () > #14 0x65000235f1e8f631 in ?? () > #15 0x0000000025148b48 in ?? () > #16 0x450c608b44028b48 in ?? () > #17 0x000004cd840fe485 in ?? () > #18 0x00000025348b4865 in ?? () > #19 0xe80c49ff0e8b4800 in ?? () > #20 0x68c7c74800148304 in ?? () > #21 0x05c7df89418048c1 in ?? () > #22 0x00000001003d81e8 in ?? () > ---Type to continue, or q to quit---q > > The last useful crashdump I've had was before February this year. > Do others share this experience? > > Ian I haven't had any such problems. I do often get a "broken stack?" following the rest of the BT, but they're generally useful anyway, and I've never ever seen "Attempt to extract a component of a value that is not a structure pointer" before. Regards, Thomas From spambox at haruhiism.net Wed Jul 1 14:00:23 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Wed Jul 1 14:00:37 2009 Subject: kgdb on an amd64 kernel anyone? In-Reply-To: References: Message-ID: <4A4B6C0D.5070104@haruhiism.net> Ian Freislich wrote: > Has anyone managed to inspect a vmcore produced by an amd64 kernel > in the last few months? I've had several crashes, but all the cores > appear corrupted and no useful data can be had No such luck. See f.ex. http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008777.html - an example of a correct dump on my amd64 -current (the netisr.c trap examples). -- Kamigishi Rei KREI-RIPE From ken at mthelicon.com Wed Jul 1 14:23:38 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Wed Jul 1 14:23:46 2009 Subject: Has anyone been able to actually boot the AMD64 kernel after r194958? Message-ID: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> Hi Current, I was wondering.. Has anyone actually been able to boot a kernel after r194958? On 2 different machine (simmilar archecture) the system will kernel-trap right after attemping to mount the ZFS filesystems. I dont know if it is ZFS related or not as I am not able to get a core. It complains that no dump device has been defined and then locks up... If there is a way that I can provide more information, please let me know how and I will post it. Thanks again, Peg From ianf at clue.co.za Wed Jul 1 14:25:42 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Wed Jul 1 14:25:52 2009 Subject: kgdb on an amd64 kernel anyone? In-Reply-To: <3EF4C954-2A84-42BA-B0F5-629B3CCC1578@exscape.org> References: <3EF4C954-2A84-42BA-B0F5-629B3CCC1578@exscape.org> Message-ID: Thomas Backman wrote: > On Jul 1, 2009, at 03:50 PM, Ian Freislich wrote: > > > > The last useful crashdump I've had was before February this year. > > Do others share this experience? > > I haven't had any such problems. I do often get a "broken stack?" > following the rest of the BT, but they're generally useful anyway, and > I've never ever seen "Attempt to extract a component of a value that > is not a structure pointer" before. Interesting. So, it's just me then (which is why there haven't been any panic reports from me for a while). There's heavy use of the following modules to the tune of 3*10^9 packets a day peaking at several 1000Mbits/s: Id Refs Address Size Name 1 10 0xffffffff80100000 6f3108 kernel 2 1 0xffffffff80a22000 4986 if_lagg.ko 3 1 0xffffffff80a27000 9f9 pflog.ko 4 1 0xffffffff80a28000 5292 if_bridge.ko 5 1 0xffffffff80a2e000 350f bridgestp.ko I suspect it's blowing up in there somewhere a few times a week. I'll try compiling them into the kernel and see if that yields a useable vmcore. Ian -- Ian Freislich From spambox at haruhiism.net Wed Jul 1 14:27:02 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Wed Jul 1 14:27:09 2009 Subject: Has anyone been able to actually boot the AMD64 kernel after r194958? In-Reply-To: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> Message-ID: <4A4B724D.10506@haruhiism.net> Pegasus Mc Cleaft wrote: > I was wondering.. Has anyone actually been able to boot a kernel after r194958? On 2 different machine (simmilar archecture) the system will kernel-trap right after attemping to mount the ZFS filesystems. I dont know if it is ZFS related or not as I am not able to get a core. It complains that no dump device has been defined and then locks up... > > If there is a way that I can provide more information, please let me know how and I will post it. > If your swap space is in zpool, you won't be able to dump. Does the system boot in single user mode? Without starting /etc/rc.d/zfs I mean. And about being able to boot: fujibayashi@ameagari ~ % uname -a FreeBSD ameagari.fujibayashi.jp 8.0-CURRENT FreeBSD 8.0-CURRENT #8 r195182M: Tue Jun 30 16:02:54 JST 2009 fujibayashi@ameagari ~ % uptime 18:26 up 1 day, 6:10, 3 users, load averages: 0,18 0,05 0,02 fujibayashi@ameagari ~ % zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT data 928G 14,3G 914G 1% ONLINE - storage 1,36T 432G 960G 31% ONLINE - -- Kamigishi Rei KREI-RIPE From ken at mthelicon.com Wed Jul 1 14:41:23 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Wed Jul 1 14:41:31 2009 Subject: Has anyone been able to actually boot the AMD64 kernel after r194958? In-Reply-To: <4A4B724D.10506@haruhiism.net> References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <4A4B724D.10506@haruhiism.net> Message-ID: > Pegasus Mc Cleaft wrote: >> I was wondering.. Has anyone actually been able to boot a kernel >> after r194958? On 2 different machine (simmilar archecture) the system >> will kernel-trap right after attemping to mount the ZFS filesystems. I >> dont know if it is ZFS related or not as I am not able to get a core. It >> complains that no dump device has been defined and then locks up... >> If there is a way that I can provide more information, please let me >> know how and I will post it. > > If your swap space is in zpool, you won't be able to dump. > Does the system boot in single user mode? Without starting /etc/rc.d/zfs I > mean. I use ZFS Boot with a three-way mirror (A seperate GPT slice on each of the drives) and the swap-space is spanned across 3 other slices (one on each of the boot drives). I think its giving me that error because it never gets far enough in the boot to swapon those slices before it panics. Another symptom of this is that it dosent get far enough to clear the nextboot flag, so when it does go boom, I have to manually tell it to boot from the working kernel (r194958). I'll try in a few hours to see if it will allow me to go into single user and report back to everyone. I'm not infront of the console at the moment (I need to get a IP-KVM) :> Peg From spambox at haruhiism.net Wed Jul 1 14:46:04 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Wed Jul 1 14:46:11 2009 Subject: Has anyone been able to actually boot the AMD64 kernel after r194958? In-Reply-To: References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <4A4B724D.10506@haruhiism.net> Message-ID: <4A4B76C2.90406@haruhiism.net> Pegasus Mc Cleaft wrote: > I use ZFS Boot with a three-way mirror (A seperate GPT slice on > each of the drives) and the swap-space is spanned across 3 other > slices (one on each of the boot drives). I think its giving me that > error because it never gets far enough in the boot to swapon those > slices before it panics. Another symptom of this is that it dosent get > far enough to clear the nextboot flag, so when it does go boom, I have > to manually tell it to boot from the working kernel (r194958). Well, then you won't be able to get a core, because by the time doadump starts the filesystem layer is already dead. The kernel just won't be able to save the dump to something as complicated as a 3-disk-span swap space - it can't even dump to a gmirror-based swapspace properly, you know ;) And if you're using ZFS boot, you probably have ZFS built into kernel so I'm not sure if booting without loading zfs.ko is possible as it's already inside... -- Kamigishi Rei KREI-RIPE From lwindschuh at googlemail.com Wed Jul 1 15:42:31 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Wed Jul 1 15:42:39 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A4B2EE6.2080501@FreeBSD.org> References: <1246206181.00132972.1246192801@10.7.7.3> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> <4A48D136.3050309@haruhiism.net> <4A48D551.5090509@FreeBSD.org> <4A49E7A3.70509@haruhiism.net> <4A49EA94.3070109@FreeBSD.org> <4A4B2A90.8090300@jrv.org> <4A4B2EE6.2080501@FreeBSD.org> Message-ID: <90a5caac0907010842r3f314186n366c2417f979e767@mail.gmail.com> I'd like to notice that the patch seems to break cdrecord -scanbus (freshly rebuilt from the ports): $ cdrecord -scanbus Cdrecord-Clone 2.01 (i386-unknown-freebsd8.0) Copyright (C) 1995-2004 J?rg Schilling cdrecord: Argument list too long. CAMIOCOMMAND ioctl failed. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. cdrecord: For possible transport specifiers try 'cdrecord dev=help'. Regards Lucius From paul at fletchermoorland.co.uk Wed Jul 1 15:53:54 2009 From: paul at fletchermoorland.co.uk (Paul Wootton) Date: Wed Jul 1 15:54:01 2009 Subject: Has anyone been able to actually boot the AMD64 kernel after r194958? In-Reply-To: <4A4B76C2.90406@haruhiism.net> References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <4A4B724D.10506@haruhiism.net> <4A4B76C2.90406@haruhiism.net> Message-ID: <4A4B7FC1.5020709@fletchermoorland.co.uk> Kamigishi Rei wrote: > Pegasus Mc Cleaft wrote: >> I use ZFS Boot with a three-way mirror (A seperate GPT slice on >> each of the drives) and the swap-space is spanned across 3 other >> slices (one on each of the boot drives). I think its giving me that >> error because it never gets far enough in the boot to swapon those >> slices before it panics. Another symptom of this is that it dosent >> get far enough to clear the nextboot flag, so when it does go boom, I >> have to manually tell it to boot from the working kernel (r194958). > Well, then you won't be able to get a core, because by the time > doadump starts the filesystem layer is already dead. The kernel just > won't be able to save the dump to something as complicated as a > 3-disk-span swap space - it can't even dump to a gmirror-based > swapspace properly, you know ;) > > And if you're using ZFS boot, you probably have ZFS built into kernel > so I'm not sure if booting without loading zfs.ko is possible as it's > already inside... > > -- > Kamigishi Rei > KREI-RIPE I also have the same issue and have not been able to boot any kernels from recent builds. I know that r194437 works for me I am also using ZFS on an intel Core2Quad If I boot a recent kernel I get (copied on to paper and type retyped here) ------------------ Jul 1 15:55:30 demophon kernel: pcm3: at cad 2 nid 1 on hdac1 Jul 1 15:55:30 demophon kernel: SMP: AP CPU #1 Launched! Jul 1 15:55:30 demophon kernel: SMP: AP CPU #3 Launched! Jul 1 15:55:30 demophon kernel: SMP: AP CPU #2 Launched! Jul 1 15:55:30 demophon kernel: hwpmc: TSC/1/ Fatal trap 30: reserved (unknown) fault while in kernel mode cpuid = 3; apic id = 03 instruction pointer = 0x20:0xffffffff808a547f stack pointer = 0x28:0xffffffff810618d0 frame pointer = 2x28:0xffffffff810618f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interput enable, IOPL=0 current process = 0 (swapper) trap number = 30 panic: reserved (unkown) fault cpuid 3 Uptime: 1s ------------------ Every time I try a kernel it always bombs out with cpuid 3 but the hwpmc line can be anywhere between "hwpmc: TSC/1" and "hwpmc: TSC/1/64/0x20 IAP/2/40/0x" I cant even start in to single user mode (get the same error as above.) If I try to boot with ACPI disabled I get --------------------- Trying to mount root from zfs:zfsroot/root ROOT MOUNT ERROR: If you have invalid mount options, reboot, and try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove the invalid options from /etc/fstab Loader varaibles vfs.root.mountfrom="zfs:zfsroot/zfsroot" vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> -------------------- Paul ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From alexbestms at math.uni-muenster.de Wed Jul 1 16:37:43 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Jul 1 16:37:50 2009 Subject: building device drivers for FreeBSD 7.2+ /AMD64 Message-ID: have you tried this article? http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/driverbasics.html i don't think it's amd64 specific though. cheers. alex From dillon at apollo.backplane.com Wed Jul 1 16:56:57 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Wed Jul 1 16:57:13 2009 Subject: RFC: ATA to CAM integration patch References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> <4A48D136.3050309@haruhiism.net> <4A48D551.5090509@FreeBSD.org> <4A49E7A3.70509@haruhiism.net> <4A49EA94.3070109@FreeBSD.org> <4A4B2A90.8090300@jrv.org> <4A4B2EE6.2080501@FreeBSD.org> Message-ID: <200907011656.n61GuuEZ012662@apollo.backplane.com> :James R. Van Artsdalen wrote: :> Has anyone found any PCI-X or PCI cards that do AHCI? Or a PCI-Express, :> PCI-X or PCI card that supports AHCI & FIS-based switching for port :> multipliers? :> ... : :I still haven't found any AHCI card with FBS support. Ideas welcome. : :I am working on driver for SiI3124/3132. I haven't tested yet how fast :they really are (3132 is quite cheap), but they declare PM with FBS :support. First one is 4-port PCI-X, second - 2-port PCIe. : :-- :Alexander Motin I haven't had much luck on the AHCI front either re: FBSS. No cards, and very few motherboards have the FBSS capability. FBSS is a very new feature for AHCI, so the expectation is that it will work its way into more chipsets over time. It should become common in less then a year. There is huge demand for the feature. Alexander and I have been discussing the Sili chip. The linux folks found one very serious hardware bug and there are multiple other issues when working with targets behind a PM. Fortunately the worst hardware bug does seem to have workarounds which do not screw up performance too badly. The bug is related to reading the LRAM (that's right, just doing a simple memory read of a mapped LRAM location(!)(!)) on the chip while any command is active produces corruption. It is possible to operate the Sili chip with NCQ+FBSS (The chip does the FBSS internally). The chip seems to be able to handle upwards of 30,000 transactions per second but the main performance limitation appears to be physical port bandwidth limitations. Each physical port on the 3132 seems to be limited to 120-150 MBytes/sec (at least on the 3132), even if the phy probes at 3 Gbit/sec. And, of course, the 3132 uses only one PCI-E lane and that's something like 3 GBits/sec. I successfully ran a test on a 10-Terrabyte PM array with 5 2TB disks over 2 days of continuous reading and writing with no errors so the Sili chip does work once the issues are worked out, but with 5 disks going at once bandwidth was limited to 20-30 MB/sec on each one due to the above mentioned limitations. The SAS chipsets can probably do a lot better. The advantage of the Sili chipsets is that they are ridiculously cheap. So cheap that many of the PM enclosures sold on the market also come with a freebie PCI-e 3132 card to stuff into your computer. There are other issues with the Sili chipset and PM's related to hot insertions and firmware bugs... it isn't a walk in the park, but it seems to be possible to work around them and get something reasonably robust out of the boards. Also, error handling requires command exclusivity (due to the LRAM bug) so a failing target behind the PM can potentially cause problems for the entire enclosure. -Matt From rmacklem at uoguelph.ca Wed Jul 1 17:27:25 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Wed Jul 1 17:27:43 2009 Subject: umount -f implementation In-Reply-To: <200907010048.n610mPem058027@fire.js.berklix.net> References: <200907010048.n610mPem058027@fire.js.berklix.net> Message-ID: On Wed, 1 Jul 2009, Julian H. Stacey wrote: > Kirk McKusick wrote: >> forced unmounts. The gentle force (-f) and the brute force (-F) >> unmount. > > -F Would also be nice for devd.conf detach, for when people > forget & pull a USB stick without unmounting first. > Better a corrupt stick than a crashed OS. > All I'll add is, for the experimental nfs client, if both semantics are desired (and, imho they are), there will need to be separate flags to indicate whether or not to terminate RPCs in progress. So, it seems that there is interest in a separate "umount -F" to handle the case of failed storage (disk subsystem, NAS server down,...). Is there anyone who is opposed to my pursuing this after FreeBSD-CURRENT branches from 8? (I can do the experimental nfs client + some testing. Hopefully others can help with the generic VFS issues and other file systems.) rick, who obviously doesn't have as good a memory as Kirk's:-) ps: Unfortunately Solaris uses "-F" for something entirely different, so feel free to suggest other flag values if you think that is a concern. From gcr+freebsd-current at tharned.org Wed Jul 1 17:27:26 2009 From: gcr+freebsd-current at tharned.org (Greg Rivers) Date: Wed Jul 1 17:27:44 2009 Subject: Panic during shutdown Message-ID: I'm running -CURRENT on an Acer One netbook. Every kernel I've built since last Sunday panics on shutdown (see below). The panic occurs whenever shutdown(8) is executed, even if only to drop to single-user. halt(8) does not trigger the panic. I have a core dump and kernel with debugging symbols available if needed. -- Greg Rivers blue.tharned.org dumped core - see /var/crash/vmcore.0 Wed Jul 1 09:28:41 CDT 2009 FreeBSD blue.tharned.org 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Jul 1 00:53:42 CDT 2009 root@blue.tharned.org:/usr/obj/usr/src/sys/SMALL-SMP i386 panic: swap_reserved < decr 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: <118>. <118>. <118>Jul 1 09:25:35 blue syslogd: exiting on signal 15 panic: swap_reserved < decr cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c06bef5d,e649db30,c04fe90f,c06d6322,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c06d6322,0,c06cdb69,e649db3c,0,...) at kdb_backtrace+0x29 panic(c06cdb69,c065575e,c11ac1b8,e649db6c,c064e52e,...) at panic+0x114 swap_release_by_uid(f5000,0,c3d10340,e649db78,c0652b30,...) at swap_release_by_uid+0x94 vm_object_destroy(c4300000,c06cf12d,c06442e5,c3d2f280,bfbe0000,bfc00000) at vm_object_destroy+0xd0 vm_object_terminate(c4300000,c4176708,c3d2f1d0,e649dbc8,c064314a,...) at vm_object_terminate+0x225 vm_object_deallocate(c4300000,0,0,c3d2f1d0,0,...) at vm_object_deallocate+0x6cf _vm_map_unlock(c3d2f1d0,0,0,1,c3d2f1d0,...) at _vm_map_unlock+0x74 vm_map_remove(c3d2f1d0,0,bfc00000,c3effc40,0,...) at vm_map_remove+0x69 vmspace_exit(c417bd80,c41792a8,c41792a8,0,e649dc80,...) at vmspace_exit+0xbc exit1(c417bd80,0,e649dd2c,c068d2ee,c417bd80,...) at exit1+0x61a clear_entries(c417bd80,e649dcf8,4,c,e649dd2c,...) at clear_entries syscall(e649dd38) at syscall+0x2ff Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x8832b27f, esp = 0xbfbfedac, ebp = 0xbfbfedb8 --- Uptime: 1m4s Physical memory: 1003 MB Dumping 58 MB: 43 27 11 [snip] #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc04fe634 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc04fe94b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc063262d in swap_release_by_uid (decr=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/swap_pager.c:267 #4 0xc064a60b in vm_object_destroy (object=0xc4300000) at /usr/src/sys/vm/vm_object.c:622 #5 0xc064cb76 in vm_object_terminate (object=0xc4300000) at /usr/src/sys/vm/vm_object.c:715 #6 0xc064d24c in vm_object_deallocate (object=0xc4300000) at /usr/src/sys/vm/vm_object.c:592 #7 0xc0644059 in _vm_map_unlock (map=0xc3d2f1d0, file=0x0, line=0) at /usr/src/sys/vm/vm_map.c:480 #8 0xc0644586 in vm_map_remove (map=0xc3d2f1d0, start=0, end=Variable "end" is not available. ) at /usr/src/sys/vm/vm_map.c:2765 #9 0xc0647548 in vmspace_exit (td=0xc417bd80) at /usr/src/sys/vm/vm_map.c:329 #10 0xc04d3c1c in exit1 (td=0xc417bd80, rv=0) at /usr/src/sys/kern/kern_exit.c:299 #11 0xc04d4c10 in sys_exit (td=Could not find the frame base for "sys_exit". ) at /usr/src/sys/kern/kern_exit.c:110 #12 0xc068d2ee in syscall (frame=0xe649dd38) at /usr/src/sys/i386/i386/trap.c:1073 #13 0xc0672790 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #14 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) [snip] From mjs at rakupottery.org.uk Wed Jul 1 18:01:28 2009 From: mjs at rakupottery.org.uk (Martin Smith) Date: Wed Jul 1 18:01:34 2009 Subject: [Call For Testing] VirtualBox for FreeBSD! take 6 In-Reply-To: <20090629131534.2d764f72@ernst.jennejohn.org> References: <20090611194557.GC98175@bsdcrew.de> <4A473976.6030807@rakupottery.org.uk> <20090629131534.2d764f72@ernst.jennejohn.org> Message-ID: <4A4BA476.1020301@rakupottery.org.uk> Gary Jennejohn wrote: > On Sun, 28 Jun 2009 10:35:50 +0100 > Martin Smith wrote: > >> Martin Wilke wrote: > [snip what miwi wrote] >> Well ,I have got it up and running on a stable of 26 June, managed to >> set up a vdi, no problem, but it will not see the cd drive. >> It (vbox) says the cd drive is always secondary master, but I only have >> one ata channel so it is primary master. The dropdown list just does >> not drop down. >> Is there a workaround for this, or have I missed something stupid? >> > > I saw this too and had to start hald in order for VirtualBox to see the > real DVD/CD drives, even though I'd compiled VirtualBox without hald > support. > > BTW I'm running -current, but the problem probably has the same solution > under -stable. Well hald is already running, no problem there, I also have a current box which I am just bringing up to date, I will try it on that later in the week. Cheers -- Martin From dnelson at allantgroup.com Wed Jul 1 18:06:14 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Wed Jul 1 18:06:21 2009 Subject: 8-CURRENT Firewire In-Reply-To: References: <1246316092.3981.11.camel@Lappy> <87hbxxp5ot.fsf@tabernacle.lan> Message-ID: <20090701180602.GA36496@dan.emsphone.com> In the last episode (Jul 01), Robert Watson said: > On Wed, 1 Jul 2009, Julian Stecklina wrote: > > I have an AMD 780G board with onboard Firewire controller. 8-CURRENT hangs > > at boot with: > > > > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > > ... > > > > If I disable the Firewire controller in the BIOS it boots fine. What is a > > good way to debug this? > > I've seen similar reports of this on 7.x; Richard Clayton has a box that > has done this since at least 7.1, and it's one of the reasons I added the > debugging output above :-). Unfortunately, it's not in an easy position > to debug on that box. I have always seen this behaviour on bootup on 7.x, on a Dell Studio with an onboard port, or varying other Dells with add-on PCI cards. Loading the module after bootup works fine, but then you don't get to boot off a FW device :) -- Dan Nelson dnelson@allantgroup.com From sfourman at gmail.com Wed Jul 1 18:30:58 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Wed Jul 1 18:31:06 2009 Subject: flash10 vs f10 In-Reply-To: <747dc8f30906290434y77f11bf1i5911ea1efe29fab5@mail.gmail.com> References: <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <747dc8f30906290434y77f11bf1i5911ea1efe29fab5@mail.gmail.com> Message-ID: <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> On Mon, Jun 29, 2009 at 6:34 AM, Renato Botelho wrote: > On Sun, Jun 28, 2009 at 11:10 AM, Juergen Lock wrote: >> On Sun, Jun 28, 2009 at 04:40:20PM +0400, Boris Samorodov wrote: >>> Juergen Lock writes: >>> >>> > ?New patch and shar: >>> >>> No more comments from me, thanks! >> >> Ok. ?Has anyone tested this yet tho? ?(Besides me in a vm... :) > > Working fine here. 8.0-current i386 > I saw linux-f10-flashplugin10 hit the ports tree so I decided to try it I have a recent FreeBSD CURRENT snapshot installed uname -a FreeBSD 8.0-HEAD-20090601-JPSNAP FreeBSD 8.0-HEAD-20090601-JPSNAP #0: Mon Jun 1 02:48:06 UTC 2009 root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386/usr/src/sys/GENERIC i386 I have linux-f10 installed pkg_info | grep linux linux_base-f10-10 Base set of packages needed in Linux mode for i386/amd64 (L here is the error I get, is there some wiki available that details the steps it takes to test flash10? # cd /usr/ports/www/linux-f10-flashplugin10/ # make install ===> linux-flashplugin-10.0r22 bsd.linux-apps.mk test failed: The component libidn is not defined for LINUX_DIST_SUFFIX=-f10 (the corresponding variable libidn_f10_FILE is not defined). *** Error code 1 Stop in /usr/ports/www/linux-f10-flashplugin10. most everything else is set to defaults Sam Fourman Jr. From matheus at eternamente.info Wed Jul 1 19:02:35 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Wed Jul 1 19:02:42 2009 Subject: problems building current from today Message-ID: <3730d4eb75f62cac45c8113ef595c2f5.squirrel@cygnus.homeunix.com> hail, I'm trying to build tinybsd as of today, and I get this: 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/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/sysv_msg.c /usr/src/sys/kern/sysv_msg.c:1263: error: invalid application of 'sizeof' to incomplete type 'struct freebsd7_msgctl_args' /usr/src/sys/kern/sysv_msg.c:1263: error: 'freebsd7_msgctl' undeclared here (not in a function) cc1: warnings being treated as errors /usr/src/sys/kern/sysv_msg.c:1309: warning: function declaration isn't a prototype /usr/src/sys/kern/sysv_msg.c: In function 'freebsd7_msgctl': /usr/src/sys/kern/sysv_msg.c:1318: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1318: error: request for member 'cmd' in something not a structure or union /usr/src/sys/kern/sysv_msg.c:1318: warning: comparison between pointer and integer /usr/src/sys/kern/sysv_msg.c:1319: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1319: error: request for member 'buf' in something not a structure or union /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'msqid' in something not a structure or union /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'cmd' in something not a structure or union /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 2 of 'kern_msgctl' makes integer from pointer without a cast /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 3 of 'kern_msgctl' makes integer from pointer without a cast /usr/src/sys/kern/sysv_msg.c:1337: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1337: error: request for member 'cmd' in something not a structure or union /usr/src/sys/kern/sysv_msg.c:1337: warning: comparison between pointer and integer /usr/src/sys/kern/sysv_msg.c:1350: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1350: error: request for member 'buf' in something not a structure or union *** Error code 1 Stop in /usr/obj/usr/src/sys/TINYBSD. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. tinybsd# I read about some commits breaking current recently, but also saw saying was fixed. if any hints, thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From peterjeremy at optushome.com.au Wed Jul 1 19:04:08 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Jul 1 19:04:16 2009 Subject: flash10 vs f10 In-Reply-To: <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> References: <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <747dc8f30906290434y77f11bf1i5911ea1efe29fab5@mail.gmail.com> <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> Message-ID: <20090701190404.GA59698@server.vk2pj.dyndns.org> On 2009-Jul-01 13:30:56 -0500, "Sam Fourman Jr." wrote: >I saw linux-f10-flashplugin10 hit the ports tree so I decided to try it ... >===> linux-flashplugin-10.0r22 bsd.linux-apps.mk test failed: The >component libidn is not defined for LINUX_DIST_SUFFIX=-f10 (the >corresponding variable libidn_f10_FILE is not defined). >*** Error code 1 linux-f10-flashplugin10 has been repo-copied into place but the infrastructure to support it is not yet in place, hence you still need the patches mentioned earlier in this thread. -- 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/20090701/df33b329/attachment.pgp From danfe at nsu.ru Wed Jul 1 16:48:18 2009 From: danfe at nsu.ru (Alexey Dokuchaev) Date: Wed Jul 1 19:05:52 2009 Subject: Kernel panic with if_sf.ko Message-ID: <20090701162108.GA33681@regency.nsu.ru> Hello there, I've started to observe the following rather annoying panic if I boot with if_sf loaded (via loader.conf) and having sf0 configured via DHCP on recent -CURRENT. If I comment out driver from loader.conf and load it manually (via kldload(8)) after system boots, it loads and gets configured just fine. Any clues here? Attached is relevant dmesg + DDB trace (debug kernel with WITNESS). I'm happy to provide any additional information (that is, ps/show uma/malloc, whatever). Thanks. ./danfe -------------- next part -------------- sf0: link state changed to UP Starting Network: lo0 sf0. sf1: link state changed to DOWN Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ sys/modules/sf/../../dev/sf/if_sf.c:1971 KDB: stack backtrace: db_trace_self_wrapper(c0683396,d655e808,c05188c5,c0fd7bc2,7b3,...) at db_trace_s elf_wrapper+0x26 kdb_backtrace(c0fd7bc2,7b3,ffffffff,c0eb2914,d655e840,...) at kdb_backtrace+0x29 _witness_debugger(c0685907,d655e854,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c06a5f7f,d655e890,c3537d48,...) at witness_warn+0x1fd trap(d655e8e0) at trap+0x192 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc062cec2, esp = 0xd655e920, ebp = 0xd655e954 --- _bus_dmamap_sync(c3551c80,c3573000,2,90a,6000,...) at _bus_dmamap_sync+0xa2 sf_stop(c3551d80,4,c0fd7bc2,7c1,c3556c70,...) at sf_stop+0x130 sf_init_locked(c356c584,0,c0fd7bc2,7b3,c36e3c00,...) at sf_init_locked+0x50 sf_init(c356b000,c356b000,0,0,c36e3cbb,...) at sf_init+0x3c ether_ioctl(c3554c00,8020690c,c36e3c00,d655ea38,456bc5b,...) at ether_ioctl+0x41 in_ifinit(0,c36e3c00,1aa,1a6,c0eb2910,...) at in_ifinit+0x2a6 in_control(c377bce0,8040691a,c35a26c0,c3554c00,c36b9720,...) at in_control+0xd7b ifioctl(c377bce0,8040691a,c35a26c0,c36b9720,4,...) at ifioctl+0x157d soo_ioctl(c36a57e0,8040691a,c35a26c0,c34a9b00,c36b9720,...) at soo_ioctl+0x3d2 kern_ioctl(c36b9720,4,8040691a,c35a26c0,6b9884,...) at kern_ioctl+0x1dd ioctl(c36b9720,d655ecf8,419,c06a5e55,c36b9720,...) at ioctl+0x134 syscall(d655ed38) at syscall+0x323 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281bf8a3, esp = 0xbfbfe5bc, ebp = 0xbfbfe5f8 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x400000c fault code = supervisor read, page not present instruction pointer = 0x20:0xc062cec2 stack pointer = 0x28:0xd655e920 frame pointer = 0x28:0xd655e954 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 = 453 (ifconfig) [thread pid 453 tid 100040 ] Stopped at _bus_dmamap_sync+0xa2: movl 0xc(%ebx),%eax db> show pcpu cpuid = 0 dynamic pcpu = 0xd3c597 curthread = 0xc36b9720: pid 453 "ifconfig" curpcb = 0xd655ed90 fpcurthread = none idlethread = 0xc34adbe0: pid 10 "idle" APIC ID = 0 currentldt = 0x50 spin locks held: db> show allpcpu Current CPU: 0 cpuid = 0 dynamic pcpu = 0xd3c597 curthread = 0xc36b9720: pid 453 "ifconfig" curpcb = 0xd655ed90 fpcurthread = none idlethread = 0xc34adbe0: pid 10 "idle" APIC ID = 0 currentldt = 0x50 spin locks held: db> show locks exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ sys/modules/sf/../../dev/sf/if_sf.c:1971 db> show alllocks Process 453 (ifconfig) thread 0xc36b9720 (100040) exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ sys/modules/sf/../../dev/sf/if_sf.c:1971 From alexbestms at math.uni-muenster.de Wed Jul 1 19:08:22 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Jul 1 19:08:31 2009 Subject: nspluginwrapper patch for testing (was: Re: flash10 vs f10) Message-ID: the latest patch to get rid of the ulimit warning doesn't suppress the warning since it get's output to stderr and not to stdout. replacing it with "ulimit -s 32768 2 > /dev/null 2>&1" should work. cheers. From kostikbel at gmail.com Wed Jul 1 19:22:01 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jul 1 19:22:16 2009 Subject: Panic during shutdown In-Reply-To: References: Message-ID: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> On Wed, Jul 01, 2009 at 11:57:20AM -0500, Greg Rivers wrote: > I'm running -CURRENT on an Acer One netbook. Every kernel I've built > since last Sunday panics on shutdown (see below). The panic occurs > whenever shutdown(8) is executed, even if only to drop to single-user. > halt(8) does not trigger the panic. > > I have a core dump and kernel with debugging symbols available if needed. ... > > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:246 > #1 0xc04fe634 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 > #2 0xc04fe94b in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xc063262d in swap_release_by_uid (decr=Unhandled dwarf expression > opcode 0x93 > ) > at /usr/src/sys/vm/swap_pager.c:267 > #4 0xc064a60b in vm_object_destroy (object=0xc4300000) > at /usr/src/sys/vm/vm_object.c:622 > #5 0xc064cb76 in vm_object_terminate (object=0xc4300000) > at /usr/src/sys/vm/vm_object.c:715 > #6 0xc064d24c in vm_object_deallocate (object=0xc4300000) > at /usr/src/sys/vm/vm_object.c:592 I am interested in the output of p *object from the frame 6, and the output of p swap_total p swap_reserved all from kgdb. Also, please describe the load on the machine, and look up what process exited when the panic happens. Thanks for the report. > #7 0xc0644059 in _vm_map_unlock (map=0xc3d2f1d0, file=0x0, line=0) > at /usr/src/sys/vm/vm_map.c:480 > #8 0xc0644586 in vm_map_remove (map=0xc3d2f1d0, start=0, end=Variable > "end" is not available. > ) > at /usr/src/sys/vm/vm_map.c:2765 > #9 0xc0647548 in vmspace_exit (td=0xc417bd80) at > /usr/src/sys/vm/vm_map.c:329 > #10 0xc04d3c1c in exit1 (td=0xc417bd80, rv=0) > at /usr/src/sys/kern/kern_exit.c:299 > #11 0xc04d4c10 in sys_exit (td=Could not find the frame base for "sys_exit". > ) at /usr/src/sys/kern/kern_exit.c:110 > #12 0xc068d2ee in syscall (frame=0xe649dd38) > at /usr/src/sys/i386/i386/trap.c:1073 > #13 0xc0672790 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:261 > #14 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > [snip] > _______________________________________________ > 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" -------------- 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/20090701/590ec501/attachment.pgp From nox at jelal.kn-bremen.de Wed Jul 1 19:37:59 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Wed Jul 1 19:40:12 2009 Subject: nspluginwrapper patch for testing (was: Re: flash10 vs f10) In-Reply-To: Message-ID: <200907011936.n61Jahd7061038@triton.kn-bremen.de> In article you write: >the latest patch to get rid of the ulimit warning doesn't suppress the warning >since it get's output to stderr and not to stdout. replacing it with "ulimit >-s 32768 2 > /dev/null 2>&1" should work. You mean the patch doesn't work for you? It already does redirect stderr to /dev/null (`2>/dev/null'), which works as expected when tested here from commandline /bin/sh and from a script, and also when invoking firefox after ulimit -s 16384. If it doesn't work for you there must be something else going on... Wondering... Juergen From alexbestms at math.uni-muenster.de Wed Jul 1 19:50:42 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Jul 1 19:50:50 2009 Subject: nspluginwrapper patch for testing (was: Re: flash10 vs f10) In-Reply-To: <200907011936.n61Jahd7061038@triton.kn-bremen.de> Message-ID: you're right. it was my mistake. i didn't apply the patch, but added the changes manually. i probably overlooked the "2>". sorry for that. ;) alex Juergen Lock schrieb am 2009-07-01: > In article > > you write: > >the latest patch to get rid of the ulimit warning doesn't suppress > >the warning > >since it get's output to stderr and not to stdout. replacing it with > >"ulimit > >-s 32768 2 > /dev/null 2>&1" should work. > You mean the patch doesn't work for you? It already does redirect > stderr to /dev/null (`2>/dev/null'), which works as expected when > tested here from commandline /bin/sh and from a script, and also when > invoking firefox after ulimit -s 16384. If it doesn't work for you > there > must be something else going on... > Wondering... > Juergen From bsam at ipt.ru Wed Jul 1 20:02:38 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Jul 1 20:02:52 2009 Subject: flash10 vs f10 In-Reply-To: <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> (Sam Fourman, Jr.'s message of "Wed\, 1 Jul 2009 13\:30\:56 -0500") References: <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <747dc8f30906290434y77f11bf1i5911ea1efe29fab5@mail.gmail.com> <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> Message-ID: <57964197_-_@h30.sp.ipt.ru> On Wed, 1 Jul 2009 13:30:56 -0500 Sam Fourman Jr. wrote: > On Mon, Jun 29, 2009 at 6:34 AM, Renato Botelho wrote: > > On Sun, Jun 28, 2009 at 11:10 AM, Juergen Lock wrote: > >> On Sun, Jun 28, 2009 at 04:40:20PM +0400, Boris Samorodov wrote: > >>> Juergen Lock writes: > >>> > >>> > ?New patch and shar: > >>> > >>> No more comments from me, thanks! > >> > >> Ok. ?Has anyone tested this yet tho? ?(Besides me in a vm... :) > > > > Working fine here. 8.0-current i386 > > > I saw linux-f10-flashplugin10 hit the ports tree so I decided to try it > I have a recent FreeBSD CURRENT snapshot installed > uname -a > FreeBSD 8.0-HEAD-20090601-JPSNAP FreeBSD 8.0-HEAD-20090601-JPSNAP #0: > Mon Jun 1 02:48:06 UTC 2009 > root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386/usr/src/sys/GENERIC > i386 > I have linux-f10 installed > pkg_info | grep linux > linux_base-f10-10 Base set of packages needed in Linux mode for i386/amd64 (L For future reference, either show another command (i.e. pkg_info | grep linux_base) or show the full output for the command you give. > here is the error I get, is there some wiki available that details the > steps it takes to test flash10? > # cd /usr/ports/www/linux-f10-flashplugin10/ > # make install > ===> linux-flashplugin-10.0r22 bsd.linux-apps.mk test failed: The > component libidn is not defined for LINUX_DIST_SUFFIX=-f10 (the This component should not present at the makefile (the package is included at linux_base-f10 port). > corresponding variable libidn_f10_FILE is not defined). > *** Error code 1 > Stop in /usr/ports/www/linux-f10-flashplugin10. Here is a patch to test: ----- --- Makefile.orig 2009-07-01 23:56:23.000000000 +0400 +++ Makefile 2009-07-01 23:56:39.000000000 +0400 @@ -20,7 +20,7 @@ ONLY_FOR_ARCHS= amd64 i386 USE_LINUX= yes -USE_LINUX_APPS= openssl curl libssh2 libidn nspr nss +USE_LINUX_APPS= openssl curl libssh2 nspr nss RESTRICTED= Redistribution not allowed RESTRICTED_FILES= ${DISTFILES:Nlinux-f8-flashsupport*:C/:[^:]+$//} ----- WBR -- bsam From bsam at ipt.ru Wed Jul 1 20:08:19 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Jul 1 20:08:26 2009 Subject: flash10 vs f10 In-Reply-To: <57964197_-_@h30.sp.ipt.ru> (Boris Samorodov's message of "Thu\, 02 Jul 2009 00\:02\:34 +0400") References: <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <747dc8f30906290434y77f11bf1i5911ea1efe29fab5@mail.gmail.com> <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> <57964197_-_@h30.sp.ipt.ru> Message-ID: <91883855@h30.sp.ipt.ru> On Thu, 02 Jul 2009 00:02:34 +0400 Boris Samorodov wrote: > Here is a patch to test: Sorry, was stupid of me. Peter Jeremy is right -- it was just a repocopy and the port is not committed yet. I spoke too soon. WBR -- bsam From jkim at FreeBSD.org Wed Jul 1 20:13:18 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Wed Jul 1 20:13:27 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: <20090701162108.GA33681@regency.nsu.ru> References: <20090701162108.GA33681@regency.nsu.ru> Message-ID: <200907011613.10550.jkim@FreeBSD.org> On Wednesday 01 July 2009 12:21 pm, Alexey Dokuchaev wrote: > Hello there, > > I've started to observe the following rather annoying panic if I > boot with if_sf loaded (via loader.conf) and having sf0 configured > via DHCP on recent -CURRENT. If I comment out driver from > loader.conf and load it manually (via kldload(8)) after system > boots, it loads and gets configured just fine. > > Any clues here? Attached is relevant dmesg + DDB trace (debug > kernel with WITNESS). I'm happy to provide any additional > information (that is, ps/show uma/malloc, whatever). Last time I checked, bpf(4) with MAC caused a similar problem when it is destroying bpf descriptor label. GENERIC includes MAC by default now. If you don't need MAC, try removing "options MAC" from your kernel configuration. FYI... Jung-uk Kim From rwatson at FreeBSD.org Wed Jul 1 20:17:26 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jul 1 20:17:32 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: <200907011613.10550.jkim@FreeBSD.org> References: <20090701162108.GA33681@regency.nsu.ru> <200907011613.10550.jkim@FreeBSD.org> Message-ID: On Wed, 1 Jul 2009, Jung-uk Kim wrote: > On Wednesday 01 July 2009 12:21 pm, Alexey Dokuchaev wrote: > >> I've started to observe the following rather annoying panic if I boot with >> if_sf loaded (via loader.conf) and having sf0 configured via DHCP on recent >> -CURRENT. If I comment out driver from loader.conf and load it manually >> (via kldload(8)) after system boots, it loads and gets configured just >> fine. >> >> Any clues here? Attached is relevant dmesg + DDB trace (debug kernel with >> WITNESS). I'm happy to provide any additional information (that is, >> ps/show uma/malloc, whatever). > > Last time I checked, bpf(4) with MAC caused a similar problem when it is > destroying bpf descriptor label. GENERIC includes MAC by default now. If > you don't need MAC, try removing "options MAC" from your kernel > configuration. I was not aware of this problem -- could you provide some more details? Any panic caused by having MAC in the kernel is a bug... Robert N M Watson Computer Laboratory University of Cambridge From wojtek at wojtek.tensor.gdynia.pl Wed Jul 1 20:12:57 2009 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Wed Jul 1 20:24:17 2009 Subject: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> Message-ID: >> It's better to use gmirror per partition. > > Like this? > > # gmirror label -vb round-robin root /dev/da0p2 > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. isn't that partition accessed by other process or mounted? From matheus at eternamente.info Wed Jul 1 21:23:16 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Wed Jul 1 21:23:23 2009 Subject: problems building current from today In-Reply-To: <1de79840907011400v7f625f6av926ffc311f469f52@mail.gmail.com> References: <3730d4eb75f62cac45c8113ef595c2f5.squirrel@cygnus.homeunix.com> <1de79840907011400v7f625f6av926ffc311f469f52@mail.gmail.com> Message-ID: <278f1543f854567d812e3cd65ff4d42d.squirrel@cygnus.homeunix.com> On Wed, July 1, 2009 18:00, Michael Proto wrote: > On Wed, Jul 1, 2009 at 3:02 PM, Nenhum_de_Nos > wrote: >> hail, >> >> I'm trying to build tinybsd as of today, and I get this: >> >> 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/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL >> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common >> -finline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000 -mno-align-long-strings >> -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >> -mno-sse3 -ffreestanding -fstack-protector -Werror >> /usr/src/sys/kern/sysv_msg.c >> /usr/src/sys/kern/sysv_msg.c:1263: error: invalid application of >> 'sizeof' >> to incomplete type 'struct freebsd7_msgctl_args' >> /usr/src/sys/kern/sysv_msg.c:1263: error: 'freebsd7_msgctl' undeclared >> here (not in a function) >> cc1: warnings being treated as errors >> /usr/src/sys/kern/sysv_msg.c:1309: warning: function declaration isn't a >> prototype >> /usr/src/sys/kern/sysv_msg.c: In function 'freebsd7_msgctl': >> /usr/src/sys/kern/sysv_msg.c:1318: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1318: error: request for member 'cmd' in >> something not a structure or union >> /usr/src/sys/kern/sysv_msg.c:1318: warning: comparison between pointer >> and >> integer >> /usr/src/sys/kern/sysv_msg.c:1319: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1319: error: request for member 'buf' in >> something not a structure or union >> /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'msqid' in >> something not a structure or union >> /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'cmd' in >> something not a structure or union >> /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 2 of >> 'kern_msgctl' makes integer from pointer without a cast >> /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 3 of >> 'kern_msgctl' makes integer from pointer without a cast >> /usr/src/sys/kern/sysv_msg.c:1337: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1337: error: request for member 'cmd' in >> something not a structure or union >> /usr/src/sys/kern/sysv_msg.c:1337: warning: comparison between pointer >> and >> integer >> /usr/src/sys/kern/sysv_msg.c:1350: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1350: error: request for member 'buf' in >> something not a structure or union >> *** Error code 1 >> >> Stop in /usr/obj/usr/src/sys/TINYBSD. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> tinybsd# >> >> I read about some commits breaking current recently, but also saw saying >> was fixed. >> > > I ran across this myself on a non-TINYBSD build, and was able to > resolve it by commenting-out COMPAT_FREEBSD6 in my kernel config since > I didn't need it (all other COMPAT entries except COMPAT_43TTY were > already disabled, so now only COMPAT_43TTY is enabled). Might help > your situation. > > > -Proto thanks, I looked into it and there is no COMPAT_FREEBSD6, just COMPAT_FREEBSD4. sam said to put COMPAT_FREEBSD7 on it. trying it now. thanks all, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From mike at jellydonut.org Wed Jul 1 21:25:11 2009 From: mike at jellydonut.org (Michael Proto) Date: Wed Jul 1 21:25:19 2009 Subject: problems building current from today In-Reply-To: <3730d4eb75f62cac45c8113ef595c2f5.squirrel@cygnus.homeunix.com> References: <3730d4eb75f62cac45c8113ef595c2f5.squirrel@cygnus.homeunix.com> Message-ID: <1de79840907011400v7f625f6av926ffc311f469f52@mail.gmail.com> On Wed, Jul 1, 2009 at 3:02 PM, Nenhum_de_Nos wrote: > hail, > > I'm trying to build tinybsd as of today, and I get this: > > 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/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -Werror > /usr/src/sys/kern/sysv_msg.c > /usr/src/sys/kern/sysv_msg.c:1263: error: invalid application of 'sizeof' > to incomplete type 'struct freebsd7_msgctl_args' > /usr/src/sys/kern/sysv_msg.c:1263: error: 'freebsd7_msgctl' undeclared > here (not in a function) > cc1: warnings being treated as errors > /usr/src/sys/kern/sysv_msg.c:1309: warning: function declaration isn't a > prototype > /usr/src/sys/kern/sysv_msg.c: In function 'freebsd7_msgctl': > /usr/src/sys/kern/sysv_msg.c:1318: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1318: error: request for member 'cmd' in > something not a structure or union > /usr/src/sys/kern/sysv_msg.c:1318: warning: comparison between pointer and > integer > /usr/src/sys/kern/sysv_msg.c:1319: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1319: error: request for member 'buf' in > something not a structure or union > /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'msqid' in > something not a structure or union > /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'cmd' in > something not a structure or union > /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 2 of > 'kern_msgctl' makes integer from pointer without a cast > /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 3 of > 'kern_msgctl' makes integer from pointer without a cast > /usr/src/sys/kern/sysv_msg.c:1337: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1337: error: request for member 'cmd' in > something not a structure or union > /usr/src/sys/kern/sysv_msg.c:1337: warning: comparison between pointer and > integer > /usr/src/sys/kern/sysv_msg.c:1350: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1350: error: request for member 'buf' in > something not a structure or union > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/TINYBSD. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > tinybsd# > > I read about some commits breaking current recently, but also saw saying > was fixed. > I ran across this myself on a non-TINYBSD build, and was able to resolve it by commenting-out COMPAT_FREEBSD6 in my kernel config since I didn't need it (all other COMPAT entries except COMPAT_43TTY were already disabled, so now only COMPAT_43TTY is enabled). Might help your situation. -Proto From sean.bruno at dsl-only.net Wed Jul 1 21:29:56 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Wed Jul 1 21:30:03 2009 Subject: 8-CURRENT Firewire In-Reply-To: <87hbxxp5ot.fsf@tabernacle.lan> References: <1246316092.3981.11.camel@Lappy> <87hbxxp5ot.fsf@tabernacle.lan> Message-ID: <1246483794.3443.6.camel@Lappy> > I have an AMD 780G board with onboard Firewire controller. 8-CURRENT > hangs at boot with: > > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > ... Two things: 1. Full dmesg output from boot with the firewire enabled and disabled would be great. Post it over on freebsd-firewire. 2. Can you boot with the firewire enabled in the BIOS and the following in loader.conf: firewire_load="NO" If you can boot this way, what happens when you: kldload sbp.ko Sean From jkim at FreeBSD.org Wed Jul 1 21:37:25 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Wed Jul 1 21:37:31 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: References: <20090701162108.GA33681@regency.nsu.ru> <200907011613.10550.jkim@FreeBSD.org> Message-ID: <200907011737.15525.jkim@FreeBSD.org> On Wednesday 01 July 2009 04:17 pm, Robert Watson wrote: > On Wed, 1 Jul 2009, Jung-uk Kim wrote: > > On Wednesday 01 July 2009 12:21 pm, Alexey Dokuchaev wrote: > >> I've started to observe the following rather annoying panic if I > >> boot with if_sf loaded (via loader.conf) and having sf0 > >> configured via DHCP on recent -CURRENT. If I comment out driver > >> from loader.conf and load it manually (via kldload(8)) after > >> system boots, it loads and gets configured just fine. > >> > >> Any clues here? Attached is relevant dmesg + DDB trace (debug > >> kernel with WITNESS). I'm happy to provide any additional > >> information (that is, ps/show uma/malloc, whatever). > > > > Last time I checked, bpf(4) with MAC caused a similar problem > > when it is destroying bpf descriptor label. GENERIC includes MAC > > by default now. If you don't need MAC, try removing "options > > MAC" from your kernel configuration. > > I was not aware of this problem -- could you provide some more > details? Any panic caused by having MAC in the kernel is a bug... It was about a month ago. I had funny impression that you and sam were working on it cause it started happening when sam added bpf detach event handler and MAC was enabled by default. Any way, I will let you know if I can reproduce the problem. Jung-uk Kim From danfe at nsu.ru Wed Jul 1 21:31:02 2009 From: danfe at nsu.ru (Alexey Dokuchaev) Date: Wed Jul 1 21:40:07 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: References: <20090701162108.GA33681@regency.nsu.ru> <200907011613.10550.jkim@FreeBSD.org> Message-ID: <20090701211327.GA99767@regency.nsu.ru> Robert Watson wrote: > Jung-uk Kim wrote: > >Last time I checked, bpf(4) with MAC caused a similar problem when it is > >destroying bpf descriptor label. GENERIC includes MAC by default now. If > >you don't need MAC, try removing "options MAC" from your kernel > >configuration. > > I was not aware of this problem -- could you provide some more details? > Any panic caused by having MAC in the kernel is a bug... My kernel is custom one, with everything I could moved out to modules (had to add "nodevice" entries for io and mem since they are in DEFAULTS these days). So I don't see how it can be related to MAC. ./danfe P.S. Took me couple of hours to figure out that "uart" must be compiled in, loading it via loader.conf does not quite work for serial console. :-( From rwatson at FreeBSD.org Wed Jul 1 21:42:48 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jul 1 21:42:59 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: <200907011737.15525.jkim@FreeBSD.org> References: <20090701162108.GA33681@regency.nsu.ru> <200907011613.10550.jkim@FreeBSD.org> <200907011737.15525.jkim@FreeBSD.org> Message-ID: On Wed, 1 Jul 2009, Jung-uk Kim wrote: >>> Last time I checked, bpf(4) with MAC caused a similar problem when it is >>> destroying bpf descriptor label. GENERIC includes MAC by default now. >>> If you don't need MAC, try removing "options MAC" from your kernel >>> configuration. >> >> I was not aware of this problem -- could you provide some more details? >> Any panic caused by having MAC in the kernel is a bug... > > It was about a month ago. I had funny impression that you and sam were > working on it cause it started happening when sam added bpf detach event > handler and MAC was enabled by default. Any way, I will let you know if I > can reproduce the problem. There have been a number of tear-down related races for ifnets, more of which are closed now than before the last few weeks, but none MAC-related as far as I'm aware. If it recurs, please let me know and I'm happy to help investigate (MAC-related or otherwise). Robert N M Watson Computer Laboratory University of Cambridge From root at free.fr Wed Jul 1 21:54:26 2009 From: root at free.fr (raoul megelas) Date: Wed Jul 1 22:09:53 2009 Subject: shutdown panic Message-ID: <20090701213756.55F3E8180D1@smtp3-g21.free.fr> Hi all, i am bitten by this one, (current from this day). in all case i will re cvsup later. Hope to help. REgards raoul* rmgls@free.Fr Jul 1 23:22:46 asus_p2bd_biXeon syslogd: exiting on signal 15 panic: swap_reserved < decr cpuid = 2 KDB: enter: panic [thread pid 1402 tid 100143 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 1402 tid 100143 td 0xc5ef4480 kdb_enter(c0c56d5d,c0c56d5d,c0c7db0e,e753fb20,2,...) at kdb_enter+0x3a panic(c0c7db0e,0,c0c7da6a,109,df,...) at panic+0x136 swap_release_by_uid(fb000,0,c553d300,264,c5c6a198,...) at swap_release_by_uid+0x75 vm_object_destroy(c5c6a198,0,c0c7f941,2c9,c0c55540,df) at vm_object_destroy+0xdc vm_object_terminate(c5c6a198,0,c0c7f941,247,c5c98360,...) at vm_object_terminate+0x217 vm_object_deallocate(c5c6a198,c0c7ee43,acd,c5bffd98,0,...) at vm_object_deallocate+0x5ef _vm_map_unlock(c5bffd98,c0c7ee43,acd,1,c5bffd98,...) at _vm_map_unlock+0x76 vm_map_remove(c5bffd98,0,bfc00000,c5d42fa0,c5d42d48,...) at vm_map_remove+0x6b vmspace_exit(c5ef4480,0,c0c5210e,129,0,...) at vmspace_exit+0xbf exit1(c5ef4480,100,e753fd2c,c0b97953,c5ef4480,...) at exit1+0x5cb sys_exit(c5ef4480,e753fcf8,4,c0c5d7a7,c0d3a91c,...) at sys_exit+0x1d syscall(e753fd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x28139b83, esp = 0xbfbfddcc, ebp = 0xbfbfddd8 --- db> bt Tracing pid 1402 tid 100143 td 0xc5ef4480 kdb_enter(c0c56d5d,c0c56d5d,c0c7db0e,e753fb20,2,...) at kdb_enter+0x3a panic(c0c7db0e,0,c0c7da6a,109,df,...) at panic+0x136 swap_release_by_uid(fb000,0,c553d300,264,c5c6a198,...) at swap_release_by_uid+0x75 vm_object_destroy(c5c6a198,0,c0c7f941,2c9,c0c55540,df) at vm_object_destroy+0xdc vm_object_terminate(c5c6a198,0,c0c7f941,247,c5c98360,...) at vm_object_terminate+0x217 vm_object_deallocate(c5c6a198,c0c7ee43,acd,c5bffd98,0,...) at vm_object_deallocate+0x5ef _vm_map_unlock(c5bffd98,c0c7ee43,acd,1,c5bffd98,...) at _vm_map_unlock+0x76 vm_map_remove(c5bffd98,0,bfc00000,c5d42fa0,c5d42d48,...) at vm_map_remove+0x6b vmspace_exit(c5ef4480,0,c0c5210e,129,0,...) at vmspace_exit+0xbf exit1(c5ef4480,100,e753fd2c,c0b97953,c5ef4480,...) at exit1+0x5cb sys_exit(c5ef4480,e753fcf8,4,c0c5d7a7,c0d3a91c,...) at sys_exit+0x1d syscall(e753fd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x28139b83, esp = 0xbfbfddcc, ebp = 0xbfbfddd8 --- db>* From glen.j.barber at gmail.com Wed Jul 1 22:13:53 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Wed Jul 1 22:14:00 2009 Subject: shutdown panic In-Reply-To: <20090701213756.55F3E8180D1@smtp3-g21.free.fr> References: <20090701213756.55F3E8180D1@smtp3-g21.free.fr> Message-ID: <4ad871310907011513o1e569ebct9a74796252ee86b4@mail.gmail.com> On Wed, Jul 1, 2009 at 5:37 PM, raoul megelas wrote: > > > Hi all, > > i am bitten by this one, (current from this day). > in all case i will re cvsup later. > Hope to help. > Hi, Raoul. There's another thread floating around from today with a similar situation. Just an FYI. :) -- Glen Barber From matheus at eternamente.info Wed Jul 1 22:28:32 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Wed Jul 1 22:28:39 2009 Subject: problems building current from today In-Reply-To: <278f1543f854567d812e3cd65ff4d42d.squirrel@cygnus.homeunix.com> References: <3730d4eb75f62cac45c8113ef595c2f5.squirrel@cygnus.homeunix.com> <1de79840907011400v7f625f6av926ffc311f469f52@mail.gmail.com> <278f1543f854567d812e3cd65ff4d42d.squirrel@cygnus.homeunix.com> Message-ID: <6f61f2768503d60751a837d8cd81c3db.squirrel@cygnus.homeunix.com> On Wed, July 1, 2009 18:23, Nenhum_de_Nos wrote: > > On Wed, July 1, 2009 18:00, Michael Proto wrote: >> On Wed, Jul 1, 2009 at 3:02 PM, Nenhum_de_Nos >> wrote: >>> hail, >>> >>> I'm trying to build tinybsd as of today, and I get this: >>> >>> 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/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL >>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common >>> -finline-limit=8000 --param inline-unit-growth=100 --param >>> large-function-growth=1000 -mno-align-long-strings >>> -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >>> -mno-sse3 -ffreestanding -fstack-protector -Werror >>> /usr/src/sys/kern/sysv_msg.c >>> /usr/src/sys/kern/sysv_msg.c:1263: error: invalid application of >>> 'sizeof' >>> to incomplete type 'struct freebsd7_msgctl_args' >>> /usr/src/sys/kern/sysv_msg.c:1263: error: 'freebsd7_msgctl' undeclared >>> here (not in a function) >>> cc1: warnings being treated as errors >>> /usr/src/sys/kern/sysv_msg.c:1309: warning: function declaration isn't >>> a >>> prototype >>> /usr/src/sys/kern/sysv_msg.c: In function 'freebsd7_msgctl': >>> /usr/src/sys/kern/sysv_msg.c:1318: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1318: error: request for member 'cmd' in >>> something not a structure or union >>> /usr/src/sys/kern/sysv_msg.c:1318: warning: comparison between pointer >>> and >>> integer >>> /usr/src/sys/kern/sysv_msg.c:1319: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1319: error: request for member 'buf' in >>> something not a structure or union >>> /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'msqid' in >>> something not a structure or union >>> /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'cmd' in >>> something not a structure or union >>> /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 2 of >>> 'kern_msgctl' makes integer from pointer without a cast >>> /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 3 of >>> 'kern_msgctl' makes integer from pointer without a cast >>> /usr/src/sys/kern/sysv_msg.c:1337: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1337: error: request for member 'cmd' in >>> something not a structure or union >>> /usr/src/sys/kern/sysv_msg.c:1337: warning: comparison between pointer >>> and >>> integer >>> /usr/src/sys/kern/sysv_msg.c:1350: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1350: error: request for member 'buf' in >>> something not a structure or union >>> *** Error code 1 >>> >>> Stop in /usr/obj/usr/src/sys/TINYBSD. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> tinybsd# >>> >>> I read about some commits breaking current recently, but also saw >>> saying >>> was fixed. >>> >> >> I ran across this myself on a non-TINYBSD build, and was able to >> resolve it by commenting-out COMPAT_FREEBSD6 in my kernel config since >> I didn't need it (all other COMPAT entries except COMPAT_43TTY were >> already disabled, so now only COMPAT_43TTY is enabled). Might help >> your situation. >> >> >> -Proto > > thanks, > > I looked into it and there is no COMPAT_FREEBSD6, just COMPAT_FREEBSD4. > > sam said to put COMPAT_FREEBSD7 on it. > > trying it now. > > thanks all, > > matheus for the record, options COMPAT_FREEBSD7 did the trick. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From spambox at haruhiism.net Wed Jul 1 22:33:28 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Wed Jul 1 22:33:37 2009 Subject: r194546 amd64: kernel panic in tcp_sack.c In-Reply-To: <4A48DA31.5010900@freebsd.org> References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> Message-ID: <4A4BE438.5060203@haruhiism.net> Lawrence Stewart wrote: > Ok. I'm working on a patch to address a different TCP/SACK issue, but > it may in fact be partially relevant to the cause of your panic... > can't promise when I'll be able to take a close look at this but I'm > aware of it now so that's a start. If you run into it again or find > the trigger for the panic, please let me know. Reproduced. I don't know what was the trigger this time. The system runs lighttpd, fastcgi python and php, mysql and postgresql. Also, in this core somehow everything looks quite similar (looks like another page fault but with panic() called prior to getting into fatal trap 12) to my two earlier dumps: http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008777.html http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008781.html so maybe it's not really a problem with tcp_sack.c or netisr.c. Should I attach the core.txt as well? Unread portion of the kernel message buffer: panic: tcp_sack_globalholes >= 0 cpuid = 0 KDB: enter: panic Physical memory: 2014 MB Dumping 1622 MB: 1607 1591 1575 1559 1543 1527 1511 1495 1479 1463 1447 1431 1415 1399 1383 1367 1351 1335 1319 1303 1287 1271 1255 1239 1223 1207 1191 1175 1159 1143 1127 1111 1095 1079 1063 1047 1031 1015 999 983 967 951 935 919 903 887 871 855 839 823 807 791 775 759 743 727 711 695 679 663 647 631 615 599 583 567 551 535 519 503 487 471 455 439 423 407 391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko 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/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko Reading symbols from /boot/kernel/blank_saver.ko...Reading symbols from /boot/kernel/blank_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/blank_saver.ko #0 doadump () at pcpu.h:223 223 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:223 #1 0xffffffff801f909c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801f93d1 in db_command (last_cmdp=0xffffffff80bec5e0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801f9620 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801fb5c9 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff805c92e5 in kdb_trap (type=3, code=0, tf=0xffffff8000031900) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff80862ad1 in trap (frame=0xffffff8000031900) at /usr/src/sys/amd64/amd64/trap.c:613 #7 0xffffffff80848f03 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #8 0xffffffff805c94bd in kdb_enter (why=0xffffffff8095b989 "panic", msg=0xa
) at cpufunc.h:63 #9 0xffffffff80599ecb in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:558 #10 0xffffffff80709537 in tcp_sackhole_remove (tp=0xffffffff81020fe0, hole=0xa) at /usr/src/sys/netinet/tcp_sack.c:295 #11 0xffffffff80709598 in tcp_free_sackholes (tp=0xffffff0030168b60) at /usr/src/sys/netinet/tcp_sack.c:554 #12 0xffffffff807100f3 in tcp_timer_rexmt (xtp=Variable "xtp" is not available. ) at /usr/src/sys/netinet/tcp_timer.c:482 #13 0xffffffff805ac041 in softclock (arg=Variable "arg" is not available. ) at /usr/src/sys/kern/kern_timeout.c:411 #14 0xffffffff805735d8 in intr_event_execute_handlers (p=Variable "p" is not available. ) at /usr/src/sys/kern/kern_intr.c:1145 #15 0xffffffff80574232 in ithread_loop (arg=0xffffff000131d640) at /usr/src/sys/kern/kern_intr.c:1158 #16 0xffffffff8057153a in fork_exit (callout=0xffffffff80574180 , arg=0xffffff000131d640, frame=0xffffff8000031c90) at /usr/src/sys/kern/kern_fork.c:842 #17 0xffffffff8084938e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:552 #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000001 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000eb9000 in ?? () #43 0x0000000000000000 in ?? () #44 0xffffffff80c28ec0 in affinity () #45 0xffffffff80c28ec0 in affinity () #46 0xffffff0001321390 in ?? () #47 0xffffff8000031b90 in ?? () #48 0xffffff8000031b48 in ?? () #49 0xffffff0001332390 in ?? () #50 0xffffffff805bccf0 in sched_switch (td=0xffffff000131d640, newtd=0xffffffff80574180, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1858 Previous frame inner to this frame (corrupt stack?) -- Kamigishi Rei KREI-RIPE From jkim at FreeBSD.org Wed Jul 1 22:42:13 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Wed Jul 1 22:42:21 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: References: <20090701162108.GA33681@regency.nsu.ru> <200907011737.15525.jkim@FreeBSD.org> Message-ID: <200907011842.01710.jkim@FreeBSD.org> On Wednesday 01 July 2009 05:42 pm, Robert Watson wrote: > On Wed, 1 Jul 2009, Jung-uk Kim wrote: > >>> Last time I checked, bpf(4) with MAC caused a similar problem > >>> when it is destroying bpf descriptor label. GENERIC includes > >>> MAC by default now. If you don't need MAC, try removing > >>> "options MAC" from your kernel configuration. > >> > >> I was not aware of this problem -- could you provide some more > >> details? Any panic caused by having MAC in the kernel is a > >> bug... > > > > It was about a month ago. I had funny impression that you and > > sam were working on it cause it started happening when sam added > > bpf detach event handler and MAC was enabled by default. Any > > way, I will let you know if I can reproduce the problem. > > There have been a number of tear-down related races for ifnets, > more of which are closed now than before the last few weeks, but > none MAC-related as far as I'm aware. If it recurs, please let me > know and I'm happy to help investigate (MAC-related or otherwise). I cannot reproduce it any more. It must be fixed already. FYI, when it happened, I traced it down to: shutdown -> dhclient closing fd -> bpf_dtor() -> mac_bpfdesc_destroy() -> mac_bpfdesc_label_free() -> d->bd_label corrupt! bpfmac_labelzone_free() -> uma_zfree() -> ... -> page fault! Any way, sorry for the noise and thanks for fixing this, whoever that is. Jung-uk Kim From lstewart at freebsd.org Wed Jul 1 23:07:57 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Wed Jul 1 23:08:05 2009 Subject: r194546 amd64: kernel panic in tcp_sack.c In-Reply-To: <4A4BE438.5060203@haruhiism.net> References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> Message-ID: <4A4BEC3A.2060108@freebsd.org> Kamigishi Rei wrote: > Lawrence Stewart wrote: >> Ok. I'm working on a patch to address a different TCP/SACK issue, but >> it may in fact be partially relevant to the cause of your panic... >> can't promise when I'll be able to take a close look at this but I'm >> aware of it now so that's a start. If you run into it again or find >> the trigger for the panic, please let me know. > Reproduced. I don't know what was the trigger this time. The system runs > lighttpd, fastcgi python and php, mysql and postgresql. hmmm, handy. What is generating the TCP load on this machine? Serving to clients on the Internet? Or machines on a local lan? Is there lots of load? Little bit? > Also, in this core somehow everything looks quite similar (looks like > another page fault but with panic() called prior to getting into fatal > trap 12) to my two earlier dumps: > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008777.html > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008781.html > so maybe it's not really a problem with tcp_sack.c or netisr.c. > No, the two earlier panics look like the same issue as one another, but they are unrelated to this SACK panic. I've CC'd Robert who might have thoughts on the netisr related panics. > Should I attach the core.txt as well? Yes, send it to me directly and I'll take a look. Cheers, Lawrence From spambox at haruhiism.net Wed Jul 1 23:27:10 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Wed Jul 1 23:27:16 2009 Subject: r194546 amd64: kernel panic in tcp_sack.c In-Reply-To: <4A4BEC3A.2060108@freebsd.org> References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> <4A4BEC3A.2060108@freebsd.org> Message-ID: <4A4BF0CE.2070203@haruhiism.net> Lawrence Stewart wrote: > hmmm, handy. What is generating the TCP load on this machine? Serving > to clients on the Internet? Or machines on a local lan? Is there lots > of load? Little bit? I've forgot to mention that in both cases with this tcp_sack conditional panic the uptime was approximately 40 hours. -- Kamigishi Rei KREI-RIPE From lstewart at freebsd.org Wed Jul 1 23:32:11 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Wed Jul 1 23:32:17 2009 Subject: r194546 amd64: kernel panic in tcp_sack.c In-Reply-To: <4A4BF0CE.2070203@haruhiism.net> References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> <4A4BEC3A.2060108@freebsd.org> <4A4BF0CE.2070203@haruhiism.net> Message-ID: <4A4BF1E9.8030609@freebsd.org> Kamigishi Rei wrote: > Lawrence Stewart wrote: >> hmmm, handy. What is generating the TCP load on this machine? Serving >> to clients on the Internet? Or machines on a local lan? Is there lots >> of load? Little bit? > I've forgot to mention that in both cases with this tcp_sack conditional > panic the uptime was approximately 40 hours. You didn't mention whether the clients being served were local lan or remote. I ask because tcp_timer_rexmt() is in the backtrace indicating you're getting TCP RTOs firing on the connection that's triggering the panic. Cheers, Lawrence From spambox at haruhiism.net Wed Jul 1 23:34:56 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Wed Jul 1 23:35:03 2009 Subject: r194546 amd64: kernel panic in tcp_sack.c In-Reply-To: <4A4BF1E9.8030609@freebsd.org> References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> <4A4BEC3A.2060108@freebsd.org> <4A4BF0CE.2070203@haruhiism.net> <4A4BF1E9.8030609@freebsd.org> Message-ID: <4A4BF2A0.5040207@haruhiism.net> Lawrence Stewart wrote: > You didn't mention whether the clients being served were local lan or > remote. I ask because tcp_timer_rexmt() is in the backtrace indicating > you're getting TCP RTOs firing on the connection that's triggering the > panic. Lighttpd only serves remote clients. Local LAN is a /29 network at the datacenter which is bound to the server (5 IP addresses as aliases). -- Kamigishi Rei KREI-RIPE From gcr+freebsd-current at tharned.org Wed Jul 1 23:54:24 2009 From: gcr+freebsd-current at tharned.org (Greg Rivers) Date: Wed Jul 1 23:54:30 2009 Subject: Panic during shutdown In-Reply-To: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> Message-ID: On Wed, 1 Jul 2009, Kostik Belousov wrote: >> at /usr/src/sys/vm/vm_object.c:715 >> #6 0xc064d24c in vm_object_deallocate (object=0xc4300000) >> at /usr/src/sys/vm/vm_object.c:592 > I am interested in the output of > p *object > from the frame 6, and the output of > p swap_total > p swap_reserved > all from kgdb. > ... (kgdb) frame 6 #6 0xc064d24c in vm_object_deallocate (object=0xc4300000) at /usr/src/sys/vm/vm_object.c:592 592 vm_object_terminate(object); (kgdb) list 587 * Don't double-terminate, we could be in a termination 588 * recursion due to the terminate having to sync data 589 * to disk. 590 */ 591 if ((object->flags & OBJ_DEAD) == 0) 592 vm_object_terminate(object); 593 else 594 VM_OBJECT_UNLOCK(object); 595 object = temp; 596 } (kgdb) p *object $1 = {mtx = {lock_object = {lo_name = 0xc06ce176 "vm object", lo_flags = 21168128, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, object_list = {tqe_next = 0xc43217f8, tqe_prev = 0xc41b1454}, shadow_head = { lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0xc415c5f4}, memq = {tqh_first = 0x0, tqh_last = 0xc4300028}, root = 0x0, size = 245, generation = 271, ref_count = 0, shadow_count = 0, type = 0 '\0', flags = 12552, pg_color = 250, paging_in_progress = 0, resident_page_count = 0, backing_object = 0x0, backing_object_offset = 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = { lh_first = 0x0}, cache = 0x0, handle = 0x0, un_pager = {vnp = { vnp_size = 0}, devp = {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_bcount = 0}}, uip = 0xc3d10340, charge = 1003520} (kgdb) p swap_total $2 = 2147483648 (kgdb) p swap_reserved $3 = 634880 > Also, please describe the load on the machine, > It happens regardless of the load. For example, just booting multi-user and immediately running shutdown (either by logging in or pressing the ACPI power button) triggers the panic. > ... and look up what process exited when the panic happens. > The panic message on the console does not show the process. Can that be determined from kgdb? If so, how? > Thanks for the report. > Thanks for looking into it! -- Greg Rivers From pyunyh at gmail.com Thu Jul 2 01:59:35 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Jul 2 01:59:42 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: <20090701162108.GA33681@regency.nsu.ru> References: <20090701162108.GA33681@regency.nsu.ru> Message-ID: <20090702015729.GE13137@michelle.cdnetworks.co.kr> On Wed, Jul 01, 2009 at 11:21:08PM +0700, Alexey Dokuchaev wrote: > Hello there, > > I've started to observe the following rather annoying panic if I boot > with if_sf loaded (via loader.conf) and having sf0 configured via DHCP > on recent -CURRENT. If I comment out driver from loader.conf and load > it manually (via kldload(8)) after system boots, it loads and gets > configured just fine. > Hmm, sf(4) also calls me. :-( I can't reproduce this on 10 days old CURRENT box so will try reproduce it on latest CURRENT. > Any clues here? Attached is relevant dmesg + DDB trace (debug kernel > with WITNESS). I'm happy to provide any additional information (that > is, ps/show uma/malloc, whatever). > Still have no idea why it panicked but can you let me know the line number of sf_stop+0x130? > Thanks. > > ./danfe > sf0: link state changed to UP > Starting Network: lo0 sf0. > sf1: link state changed to DOWN > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ > sys/modules/sf/../../dev/sf/if_sf.c:1971 > KDB: stack backtrace: > db_trace_self_wrapper(c0683396,d655e808,c05188c5,c0fd7bc2,7b3,...) at db_trace_s > elf_wrapper+0x26 > kdb_backtrace(c0fd7bc2,7b3,ffffffff,c0eb2914,d655e840,...) at kdb_backtrace+0x29 > _witness_debugger(c0685907,d655e854,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c06a5f7f,d655e890,c3537d48,...) at witness_warn+0x1fd > trap(d655e8e0) at trap+0x192 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc062cec2, esp = 0xd655e920, ebp = 0xd655e954 --- > _bus_dmamap_sync(c3551c80,c3573000,2,90a,6000,...) at _bus_dmamap_sync+0xa2 > sf_stop(c3551d80,4,c0fd7bc2,7c1,c3556c70,...) at sf_stop+0x130 > sf_init_locked(c356c584,0,c0fd7bc2,7b3,c36e3c00,...) at sf_init_locked+0x50 > sf_init(c356b000,c356b000,0,0,c36e3cbb,...) at sf_init+0x3c > ether_ioctl(c3554c00,8020690c,c36e3c00,d655ea38,456bc5b,...) at ether_ioctl+0x41 > in_ifinit(0,c36e3c00,1aa,1a6,c0eb2910,...) at in_ifinit+0x2a6 > in_control(c377bce0,8040691a,c35a26c0,c3554c00,c36b9720,...) at in_control+0xd7b > ifioctl(c377bce0,8040691a,c35a26c0,c36b9720,4,...) at ifioctl+0x157d > soo_ioctl(c36a57e0,8040691a,c35a26c0,c34a9b00,c36b9720,...) at soo_ioctl+0x3d2 > kern_ioctl(c36b9720,4,8040691a,c35a26c0,6b9884,...) at kern_ioctl+0x1dd > ioctl(c36b9720,d655ecf8,419,c06a5e55,c36b9720,...) at ioctl+0x134 > syscall(d655ed38) at syscall+0x323 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281bf8a3, esp = 0xbfbfe5bc, ebp > = 0xbfbfe5f8 --- > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x400000c > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc062cec2 > stack pointer = 0x28:0xd655e920 > frame pointer = 0x28:0xd655e954 > 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 = 453 (ifconfig) > [thread pid 453 tid 100040 ] > Stopped at _bus_dmamap_sync+0xa2: movl 0xc(%ebx),%eax > db> show pcpu > cpuid = 0 > dynamic pcpu = 0xd3c597 > curthread = 0xc36b9720: pid 453 "ifconfig" > curpcb = 0xd655ed90 > fpcurthread = none > idlethread = 0xc34adbe0: pid 10 "idle" > APIC ID = 0 > currentldt = 0x50 > spin locks held: > db> show allpcpu > Current CPU: 0 > > cpuid = 0 > dynamic pcpu = 0xd3c597 > curthread = 0xc36b9720: pid 453 "ifconfig" > curpcb = 0xd655ed90 > fpcurthread = none > idlethread = 0xc34adbe0: pid 10 "idle" > APIC ID = 0 > currentldt = 0x50 > spin locks held: > db> show locks > exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ > sys/modules/sf/../../dev/sf/if_sf.c:1971 > db> show alllocks > Process 453 (ifconfig) thread 0xc36b9720 (100040) > exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ > sys/modules/sf/../../dev/sf/if_sf.c:1971 > _______________________________________________ > 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 Jul 2 04:03:55 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Thu Jul 2 04:04:02 2009 Subject: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 In-Reply-To: <2BE0378C-96A3-4714-A5C3-7B1A6AA0DCE2@lakerest.net> References: <951233.95131.qm@web39108.mail.mud.yahoo.com> <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> <4A23919F.8050905@mail.zedat.fu-berlin.de> <4A2B3040.7020509@poildetroll.net> <3bbf2fe10906070339k663bace7qe5142702248ce6c9@mail.gmail.com> <4A2BBDC0.6000801@poildetroll.net> <3bbf2fe10906070623o65ce021fkb7f59fe1924cc1ec@mail.gmail.com> <4A353E21.1080001@poildetroll.net> <2BE0378C-96A3-4714-A5C3-7B1A6AA0DCE2@lakerest.net> Message-ID: On Tue, 23 Jun 2009, Randall Stewart wrote: > One thing I have noticed for a while.. and have not > been able to track down.. > > If one runs > > /usr/src/tools/tools/syscall_timing/syscall_timing > > On a 7.2 kernel and compare it on the same machine to an 8.0 kernel > you will see almost a 3x slow down in 8. > > Yes I have 8.0 without witness and all the debug. The thing > that is most interesting is I even ran 8 on a 7.2 user space... > same result. > > My AMD 64 1.6Gig 8 core machines (in SMP) are showing > > 250ns or so for getuid 1000 times on 7.2 > and > 880ns or so for getuid 1000 times on 8.0 This is due to Kib's segment changes in current. I found it with hwpmc and he has produced a patch which fixes it. It will be in after beta 1. Thank you for reporting it. Jeff > > I started tracking this in 7.1.. > > When I get some more time next week I will do some more digging.. not sure > its related to this issue though > > R > > On Jun 14, 2009, at 2:14 PM, Pierre Guinoiseau wrote: > >> Hi again, >> >> I don't know if it can be of better help or not, but I made 2 other >> dumps, before and after the slowdown, and without X running and all... I >> recompiled some packages several times to make the slowdown appear. >> >> The dumps are here : http://foo.poildetroll.net/freebsd/ktr/ >> >> Thanks again for your help! >> >> Pierre Guinoiseau >> >> >> Attilio Rao wrote: >>> 2009/6/7 Pierre Guinoiseau : >>>> Ok, here is a ktr output. This time, the slowdown appeared while >>>> recompiling thunderbird. I have 2 core at 2.2Ghz (and powerd running, I >>>> don't know if it matters). >>>> >>>> BTW, what is the use of py-tkinter ? If it was in order to cause the >>>> bug, it failed, it needed a higher load. :) >>> >>> Ah sorry, I was supposed to let you run schedgraph but I'm going to do >>> that, so you actually didn't need it >>> I will let you know if something cames up. >>> If others can report the same it will be great. >>> >>> Thanks, >>> Attilio >>> _______________________________________________ >>> 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" >> > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct) > > _______________________________________________ > 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 Thu Jul 2 08:23:01 2009 From: serenity at exscape.org (Thomas Backman) Date: Thu Jul 2 08:23:09 2009 Subject: Has anyone been able to actually boot the AMD64 kernel after r194958? In-Reply-To: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> Message-ID: <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> On Jul 1, 2009, at 04:23 PM, Pegasus Mc Cleaft wrote: > Hi Current, > > I was wondering.. Has anyone actually been able to boot a kernel > after r194958? On 2 different machine (simmilar archecture) the > system will kernel-trap right after attemping to mount the ZFS > filesystems. I dont know if it is ZFS related or not as I am not > able to get a core. It complains that no dump device has been > defined and then locks up... > > If there is a way that I can provide more information, please let > me know how and I will post it. > > Thanks again, > Peg I tried this after reading this thread, and no problems whatsoever. gptzfsboot. [root@clone ~]# uname -a FreeBSD clone.exscape.org 8.0-CURRENT FreeBSD 8.0-CURRENT #3 r195244M: Wed Jul 1 23:03:10 CEST 2009 root@clone.exscape.org:/usr/obj/usr/ src/sys/DTRACE amd64 [root@clone ~]# df -h Filesystem Size Used Avail Capacity Mounted on rpool 7.5G 461M 7.0G 6% / devfs 1.0K 1.0K 0B 100% /dev rpool/tmp 7.0G 10M 7.0G 0% /tmp rpool/usr 9.3G 2.2G 7.0G 24% /usr rpool/usr/ports 7.2G 199M 7.0G 3% /usr/ ports rpool/usr/src 7.5G 434M 7.0G 6% /usr/src rpool/var 7.1G 104M 7.0G 1% /var rpool/var/crash 7.0G 0B 7.0G 0% /var/ crash Regards, Thomas From mexas at bristol.ac.uk Thu Jul 2 08:37:19 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 2 08:37:31 2009 Subject: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> Message-ID: <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> On Wed, Jul 01, 2009 at 10:00:54PM +0200, Wojciech Puchar wrote: > >> It's better to use gmirror per partition. > > > > Like this? > > > > # gmirror label -vb round-robin root /dev/da0p2 > > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > isn't that partition accessed by other process or mounted? should it not be mounted? Sorry, I was just following the handbook, but I now understand it is incorrect when it comes to ia64. many thanks anton > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From kostikbel at gmail.com Thu Jul 2 08:41:55 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Jul 2 08:42:02 2009 Subject: Panic during shutdown In-Reply-To: References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> Message-ID: <20090702084149.GE2884@deviant.kiev.zoral.com.ua> On Wed, Jul 01, 2009 at 06:54:22PM -0500, Greg Rivers wrote: > On Wed, 1 Jul 2009, Kostik Belousov wrote: > > >> at /usr/src/sys/vm/vm_object.c:715 > >>#6 0xc064d24c in vm_object_deallocate (object=0xc4300000) > >> at /usr/src/sys/vm/vm_object.c:592 > >I am interested in the output of > >p *object > >from the frame 6, and the output of > >p swap_total > >p swap_reserved > >all from kgdb. > > > > ... > (kgdb) frame 6 > #6 0xc064d24c in vm_object_deallocate (object=0xc4300000) > at /usr/src/sys/vm/vm_object.c:592 > 592 vm_object_terminate(object); > (kgdb) list > 587 * Don't double-terminate, we could be in a > termination > 588 * recursion due to the terminate having to sync > data > 589 * to disk. > 590 */ > 591 if ((object->flags & OBJ_DEAD) == 0) > 592 vm_object_terminate(object); > 593 else > 594 VM_OBJECT_UNLOCK(object); > 595 object = temp; > 596 } > (kgdb) p *object > $1 = {mtx = {lock_object = {lo_name = 0xc06ce176 "vm object", > lo_flags = 21168128, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, > object_list = {tqe_next = 0xc43217f8, tqe_prev = 0xc41b1454}, shadow_head > = { > lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0xc415c5f4}, > memq = {tqh_first = 0x0, tqh_last = 0xc4300028}, root = 0x0, size = 245, > generation = 271, ref_count = 0, shadow_count = 0, type = 0 '\0', > flags = 12552, pg_color = 250, paging_in_progress = 0, > resident_page_count = 0, backing_object = 0x0, backing_object_offset = 0, > pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = { > lh_first = 0x0}, cache = 0x0, handle = 0x0, un_pager = {vnp = { > vnp_size = 0}, devp = {devp_pglist = {tqh_first = 0x0, tqh_last = > 0x0}}, > swp = {swp_bcount = 0}}, uip = 0xc3d10340, charge = 1003520} > (kgdb) p swap_total > $2 = 2147483648 > (kgdb) p swap_reserved > $3 = 634880 > > > >Also, please describe the load on the machine, > > > > It happens regardless of the load. For example, just booting multi-user > and immediately running shutdown (either by logging in or pressing the > ACPI power button) triggers the panic. No, it does not happen regardless of the load. The patch was tested on the semi-standard set of programs run on the system, and all seen accounting mistakes were fixed. You have some process that does exhibit the behaviour causing error in swap accounting. I think for start you could just show me ps auxww output, in private, if you prefer. > > > >... and look up what process exited when the panic happens. > > > > The panic message on the console does not show the process. Can that be > determined from kgdb? If so, how? It does show the process, like KDB: enter: panic [thread pid 32021 tid 100598 ] there, you can look up pid/tid and then do ps in ddb to look at the processes. Also, you may do "show allpcpu" in ddb. In kgdb, info threads should do the trick, AFAIR. BTW, did you saw the kernel messages like negative vmsize for uid = XXX ? -------------- 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/20090702/f1490a69/attachment.pgp From stas at FreeBSD.org Thu Jul 2 11:14:08 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Jul 2 11:14:14 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: <20090702015729.GE13137@michelle.cdnetworks.co.kr> References: <20090701162108.GA33681@regency.nsu.ru> <20090702015729.GE13137@michelle.cdnetworks.co.kr> Message-ID: <20090702151354.75dff22a.stas@FreeBSD.org> On Thu, 2 Jul 2009 10:57:29 +0900 Pyun YongHyeon mentioned: > > Still have no idea why it panicked but can you let me know the line > number of sf_stop+0x130? > It looks like a memory corruption issue. From the information he provided it appears that sc contains 0x400000 while a couple of lines before busdma_sync it had the correct value (otherwise it would have paniced earlier. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090702/97bf29e3/attachment.pgp From stas at FreeBSD.org Thu Jul 2 11:15:09 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Jul 2 11:15:15 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: <20090701162108.GA33681@regency.nsu.ru> References: <20090701162108.GA33681@regency.nsu.ru> Message-ID: <20090702151507.c997fa89.stas@FreeBSD.org> On Wed, 1 Jul 2009 23:21:08 +0700 Alexey Dokuchaev mentioned: > Hello there, > > I've started to observe the following rather annoying panic if I boot > with if_sf loaded (via loader.conf) and having sf0 configured via DHCP > on recent -CURRENT. If I comment out driver from loader.conf and load > it manually (via kldload(8)) after system boots, it loads and gets > configured just fine. > > Any clues here? Attached is relevant dmesg + DDB trace (debug kernel > with WITNESS). I'm happy to provide any additional information (that > is, ps/show uma/malloc, whatever). > Hi, Alexey! Do you use SMP system? -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090702/61aea021/attachment.pgp From raj at semihalf.com Thu Jul 2 11:49:36 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Thu Jul 2 11:49:44 2009 Subject: MD5 test slowdown Message-ID: I'm observing some heavy slowdown seen with md5 test on PowerPC: 1. On the MPC8572 machine with today's HEAD I'm getting: # md5 -t MD5 time trial. Digesting 100000 10000-byte blocks ... done Digest = 766a2bb5d24bddae466c572bcabca3ee Time = 36.930565 seconds Speed = 27077842.000000 bytes/second 2. While a couple of months back it yielded 6x shorter times on this very same hardware, like this one: # md5 -t MD5 time trial. Digesting 100000 10000-byte blocks ... done Digest = 766a2bb5d24bddae466c572bcabca3ee Time = 6.027277 seconds Speed = 165912400.000000 bytes/second Timers work fine, the slowdown is real. I don't know if this is PowerPC related, and was wondering if anybody observed something similar on other archs perhaps? Any suggestions what could be causing this or where to look? I cannot see immediate suspects in the arch/ platform code. Rafal From bzeeb-lists at lists.zabbadoz.net Thu Jul 2 12:20:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Jul 2 12:20:16 2009 Subject: Install from NFS onto NFS fails on amd64 Message-ID: <20090702121640.D245@maildrop.int.zabbadoz.net> Hi, trying to installworld from NFS to NFS (which also is the NFS Root of the installing and to be updated machien) on amd64 always fails with this error. Anyone knows why that is? ------------------------------------------------------------------------ lion1# make installworld -DNO_FSCHG ... ... ... ... ===> libkafs5 (install) install -C -o root -g wheel -m 444 libkafs5.a /usr/lib32 install -C -o root -g wheel -m 444 libkafs5_p.a /usr/lib32 install -s -o root -g wheel -m 444 libkafs5.so.10 /usr/lib32 ln -fs libkafs5.so.10 /usr/lib32/libkafs5.so ===> libkrb5 (install) install -C -o root -g wheel -m 444 libkrb5.a /usr/lib32 install -C -o root -g wheel -m 444 libkrb5_p.a /usr/lib32 install -s -o root -g wheel -m 444 libkrb5.so.10 /usr/lib32 ln -fs libkrb5.so.10 /usr/lib32/libkrb5.so ===> libroken (install) install -C -o root -g wheel -m 444 libroken.a /usr/lib32 install -C -o root -g wheel -m 444 libroken_p.a /usr/lib32 install -s -o root -g wheel -m 444 libroken.so.10 /usr/lib32 ln -fs libroken.so.10 /usr/lib32/libroken.so ===> libsl (install) ===> libvers (install) cd /zoo/bz/HEAD.svn/libexec/rtld-elf; PROG=ld-elf32.so.1 MAKEOBJDIRPREFIX=/usr/obj/lib32 _SHLIBDIRPREFIX=/usr/obj/zoo/bz/HEAD.svn/lib32 VERSION="FreeBSD 8.0-CURRENT amd64 800101" MACHINE=i386 MACHINE_ARCH=i386 PATH=/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/games:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/games:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/games:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/games:/tmp/install.uMl44I7W CC="cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/zoo/bz/HEAD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32 -B/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" CXX="c++ -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/zoo/bz/HEAD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32 -B/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" OBJC="cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/zoo/bz/HEAD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32 -B/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" LD="ld -m elf_i386_fbsd -Y P,/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" AS="as --32" LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 make -DNO_CPU_CFLAGS -DCOMPAT_32BIT -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO -DWITHOUT_HTML -DNO_CTF -DNO_INCS install chflags noschg /usr/libexec/ld-elf32.so.1 install -s -o root -g wheel -m 555 -C -b -S ld-elf32.so.1 /libexec /usr/libexec/ld-elf32.so.1 -> /libexec/ld-elf32.so.1 cd /zoo/bz/HEAD.svn/usr.bin/ldd; PROG=ldd32 MAKEOBJDIRPREFIX=/usr/obj/lib32 _SHLIBDIRPREFIX=/usr/obj/zoo/bz/HEAD.svn/lib32 VERSION="FreeBSD 8.0-CURRENT amd64 800101" MACHINE=i386 MACHINE_ARCH=i386 PATH=/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/games:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/games:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/games:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/games:/tmp/install.uMl44I7W CC="cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/zoo/bz/HEAD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32 -B/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" CXX="c++ -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/zoo/bz/HEAD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32 -B/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" OBJC="cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/zoo/bz/HEAD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32 -B/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" LD="ld -m elf_i386_fbsd -Y P,/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" AS="as --32" LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 make -DNO_CPU_CFLAGS -DCOMPAT_32BIT -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO -DWITHOUT_HTML -DNO_CTF -DNO_INCS install install -s -o root -g wheel -m 555 ldd32 /usr/bin rm: /tmp/install.uMl44I7W: Directory not empty *** Error code 1 Stop in /zoo/bz/HEAD.svn. *** Error code 1 Stop in /zoo/bz/HEAD.svn. lion1# ------------------------------------------------------------------------ -- Bjoern A. Zeeb The greatest risk is not taking one. From bzeeb-lists at lists.zabbadoz.net Thu Jul 2 12:35:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Jul 2 12:35:13 2009 Subject: Install from NFS onto NFS fails on amd64 In-Reply-To: <20090702121640.D245@maildrop.int.zabbadoz.net> References: <20090702121640.D245@maildrop.int.zabbadoz.net> Message-ID: <20090702122955.J245@maildrop.int.zabbadoz.net> On Thu, 2 Jul 2009, Bjoern A. Zeeb wrote: > Hi, > > trying to installworld from NFS to NFS (which also is the NFS Root > of the installing and to be updated machien) on amd64 always fails > with this error. Anyone knows why that is? > > ------------------------------------------------------------------------ > lion1# make installworld -DNO_FSCHG > ... > ... > ... > install -s -o root -g wheel -m 555 ldd32 /usr/bin > rm: /tmp/install.uMl44I7W: Directory not empty > *** Error code 1 > > Stop in /zoo/bz/HEAD.svn. > *** Error code 1 > > Stop in /zoo/bz/HEAD.svn. > lion1# > ------------------------------------------------------------------------ I probably should have added that the directory is empty: lion1# ls -la /tmp/install.uMl44I7W total 4 drwxr-xr-x 2 root wheel 1024 Jul 2 12:15 . drwxrwxrwt 15 root wheel 1024 Jul 2 12:10 .. and I am well aware that that is one of the last things that make installworld does; it's just strange and I blame it on NFS;-) /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From wojtek at wojtek.tensor.gdynia.pl Thu Jul 2 14:02:32 2009 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Thu Jul 2 14:16:04 2009 Subject: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> Message-ID: >>> >>> # gmirror label -vb round-robin root /dev/da0p2 >>> gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. >> isn't that partition accessed by other process or mounted? > > should it not be mounted? yes it should not, no matter what architecture. From paul at fletchermoorland.co.uk Thu Jul 2 14:50:37 2009 From: paul at fletchermoorland.co.uk (Paul Wootton) Date: Thu Jul 2 14:50:50 2009 Subject: Has anyone been able to actually boot the AMD64 kernel after r194958? In-Reply-To: <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> Message-ID: <4A4CC937.5050008@fletchermoorland.co.uk> Thomas Backman wrote: > On Jul 1, 2009, at 04:23 PM, Pegasus Mc Cleaft wrote: > >> Hi Current, >> >> I was wondering.. Has anyone actually been able to boot a kernel >> after r194958? On 2 different machine (simmilar archecture) the >> system will kernel-trap right after attemping to mount the ZFS >> filesystems. I dont know if it is ZFS related or not as I am not able >> to get a core. It complains that no dump device has been defined and >> then locks up... >> >> If there is a way that I can provide more information, please let >> me know how and I will post it. >> >> Thanks again, >> Peg > I tried this after reading this thread, and no problems whatsoever. > gptzfsboot. > > [root@clone ~]# uname -a > FreeBSD clone.exscape.org 8.0-CURRENT FreeBSD 8.0-CURRENT #3 r195244M: > Wed Jul 1 23:03:10 CEST 2009 > root@clone.exscape.org:/usr/obj/usr/src/sys/DTRACE amd64 > [root@clone ~]# df -h > Filesystem Size Used Avail Capacity > Mounted on > rpool 7.5G 461M 7.0G 6% / > devfs 1.0K 1.0K 0B 100% /dev > rpool/tmp 7.0G 10M 7.0G 0% /tmp > rpool/usr 9.3G 2.2G 7.0G 24% /usr > rpool/usr/ports 7.2G 199M 7.0G 3% > /usr/ports > rpool/usr/src 7.5G 434M 7.0G 6% /usr/src > rpool/var 7.1G 104M 7.0G 1% /var > rpool/var/crash 7.0G 0B 7.0G 0% > /var/crash > > > Regards, > Thomas With you saying this, I decided to try GENERIC kernel configuration and that builds and runs just fine. I suspect that Peg and myself have something in our kernel conf files that is causing an issue. I'll have a go later on and see if I can narrow it down a little bit more Paul ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From rmacklem at uoguelph.ca Thu Jul 2 14:50:42 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Thu Jul 2 14:50:51 2009 Subject: Install from NFS onto NFS fails on amd64 In-Reply-To: <20090702121640.D245@maildrop.int.zabbadoz.net> References: <20090702121640.D245@maildrop.int.zabbadoz.net> Message-ID: On Thu, 2 Jul 2009, Bjoern A. Zeeb wrote: > Hi, > > trying to installworld from NFS to NFS (which also is the NFS Root > of the installing and to be updated machien) on amd64 always fails > with this error. Anyone knows why that is? > [stuff snipped] > install -s -o root -g wheel -m 555 ldd32 /usr/bin > rm: /tmp/install.uMl44I7W: Directory not empty > *** Error code 1 > > Stop in /zoo/bz/HEAD.svn. > *** Error code 1 > > Stop in /zoo/bz/HEAD.svn. > lion1# Well, at a quick glance, I can't see anything in either the NFS client nor server that generates ENOTEMPTY for rmdir. It would seem to me that it was generated by the underlying file system on the NFS server for some reason. (Same goes for the syscall above the client side NFS.) You could confirm this with a printf() right after VOP_RMDIR() in sys/nfsserver/nfs_serv.c. (A tcpdump/wireshark trace would tell you if the ENOTEMPTY was reported by the server, which looks like it is the case.) Not much help, but...rick From lstewart at freebsd.org Thu Jul 2 14:53:15 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Thu Jul 2 14:53:23 2009 Subject: Temporary patch to fix USB in kdebase4 In-Reply-To: <200906080902.43391.hselasky@c2i.net> References: <200906080902.43391.hselasky@c2i.net> Message-ID: <4A4CC9C1.4080200@freebsd.org> Hans Petter Selasky wrote: > See attachment. > --HPS Any chance you (or someone with the right clue) could update this patch to work with more recent 8-CURRENT? I get the following output when trying to compile kdebase4 (which applies your original patch as extra-patch-libusb20) on r195046 world/kernel: Scanning dependencies of target kcm_usb [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o In file included from /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevices.h:20, from /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/kcmusb.cpp:27: /usr/include/dev/usb/usb_revision.h:33: error: multiple definition of 'enum usb_dev_speed' /usr/include/dev/usb/usb.h:686: error: previous definition here /usr/include/dev/usb/usb_revision.h:34: error: conflicting declaration 'USB_SPEED_VARIABLE' /usr/include/dev/usb/usb.h:687: error: 'USB_SPEED_VARIABLE' has a previous declaration as 'usb_dev_speed USB_SPEED_VARIABLE' /usr/include/dev/usb/usb_revision.h:35: error: conflicting declaration 'USB_SPEED_LOW' /usr/include/dev/usb/usb.h:688: error: 'USB_SPEED_LOW' has a previous declaration as 'usb_dev_speed USB_SPEED_LOW' /usr/include/dev/usb/usb_revision.h:36: error: conflicting declaration 'USB_SPEED_FULL' /usr/include/dev/usb/usb.h:689: error: 'USB_SPEED_FULL' has a previous declaration as 'usb_dev_speed USB_SPEED_FULL' /usr/include/dev/usb/usb_revision.h:37: error: conflicting declaration 'USB_SPEED_HIGH' /usr/include/dev/usb/usb.h:690: error: 'USB_SPEED_HIGH' has a previous declaration as 'usb_dev_speed USB_SPEED_HIGH' /usr/include/dev/usb/usb_revision.h:38: error: conflicting declaration 'USB_SPEED_SUPER' /usr/include/dev/usb/usb.h:691: error: 'USB_SPEED_SUPER' has a previous declaration as 'usb_dev_speed USB_SPEED_SUPER' /usr/include/dev/usb/usb_revision.h:45: error: multiple definition of 'enum usb_revision' /usr/include/dev/usb/usb.h:698: error: previous definition here /usr/include/dev/usb/usb_revision.h:46: error: conflicting declaration 'USB_REV_UNKNOWN' /usr/include/dev/usb/usb.h:699: error: 'USB_REV_UNKNOWN' has a previous declaration as 'usb_revision USB_REV_UNKNOWN' /usr/include/dev/usb/usb_revision.h:47: error: conflicting declaration 'USB_REV_PRE_1_0' /usr/include/dev/usb/usb.h:700: error: 'USB_REV_PRE_1_0' has a previous declaration as 'usb_revision USB_REV_PRE_1_0' /usr/include/dev/usb/usb_revision.h:48: error: conflicting declaration 'USB_REV_1_0' /usr/include/dev/usb/usb.h:701: error: 'USB_REV_1_0' has a previous declaration as 'usb_revision USB_REV_1_0' /usr/include/dev/usb/usb_revision.h:49: error: conflicting declaration 'USB_REV_1_1' /usr/include/dev/usb/usb.h:702: error: 'USB_REV_1_1' has a previous declaration as 'usb_revision USB_REV_1_1' /usr/include/dev/usb/usb_revision.h:50: error: conflicting declaration 'USB_REV_2_0' /usr/include/dev/usb/usb.h:703: error: 'USB_REV_2_0' has a previous declaration as 'usb_revision USB_REV_2_0' /usr/include/dev/usb/usb_revision.h:51: error: conflicting declaration 'USB_REV_2_5' /usr/include/dev/usb/usb.h:704: error: 'USB_REV_2_5' has a previous declaration as 'usb_revision USB_REV_2_5' /usr/include/dev/usb/usb_revision.h:52: error: conflicting declaration 'USB_REV_3_0' /usr/include/dev/usb/usb.h:705: error: 'USB_REV_3_0' has a previous declaration as 'usb_revision USB_REV_3_0' /usr/include/dev/usb/usb_revision.h:59: error: multiple definition of 'enum usb_hc_mode' /usr/include/dev/usb/usb.h:712: error: previous definition here /usr/include/dev/usb/usb_revision.h:60: error: conflicting declaration 'USB_MODE_HOST' /usr/include/dev/usb/usb.h:713: error: 'USB_MODE_HOST' has a previous declaration as 'usb_hc_mode USB_MODE_HOST' /usr/include/dev/usb/usb_revision.h:61: error: conflicting declaration 'USB_MODE_DEVICE' /usr/include/dev/usb/usb.h:714: error: 'USB_MODE_DEVICE' has a previous declaration as 'usb_hc_mode USB_MODE_DEVICE' /usr/include/dev/usb/usb_revision.h:62: error: conflicting declaration 'USB_MODE_DUAL' /usr/include/dev/usb/usb.h:715: error: 'USB_MODE_DUAL' has a previous declaration as 'usb_hc_mode USB_MODE_DUAL' /usr/include/dev/usb/usb_revision.h:69: error: multiple definition of 'enum usb_dev_state' /usr/include/dev/usb/usb.h:722: error: previous definition here /usr/include/dev/usb/usb_revision.h:70: error: conflicting declaration 'USB_STATE_DETACHED' /usr/include/dev/usb/usb.h:723: error: 'USB_STATE_DETACHED' has a previous declaration as 'usb_dev_state USB_STATE_DETACHED' /usr/include/dev/usb/usb_revision.h:71: error: conflicting declaration 'USB_STATE_ATTACHED' /usr/include/dev/usb/usb.h:724: error: 'USB_STATE_ATTACHED' has a previous declaration as 'usb_dev_state USB_STATE_ATTACHED' /usr/include/dev/usb/usb_revision.h:72: error: conflicting declaration 'USB_STATE_POWERED' /usr/include/dev/usb/usb.h:725: error: 'USB_STATE_POWERED' has a previous declaration as 'usb_dev_state USB_STATE_POWERED' /usr/include/dev/usb/usb_revision.h:73: error: conflicting declaration 'USB_STATE_ADDRESSED' /usr/include/dev/usb/usb.h:726: error: 'USB_STATE_ADDRESSED' has a previous declaration as 'usb_dev_state USB_STATE_ADDRESSED' /usr/include/dev/usb/usb_revision.h:74: error: conflicting declaration 'USB_STATE_CONFIGURED' /usr/include/dev/usb/usb.h:727: error: 'USB_STATE_CONFIGURED' has a previous declaration as 'usb_dev_state USB_STATE_CONFIGURED' *** Error code 1 Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. *** Error code 1 Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. *** Error code 1 Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. *** Error code 1 Stop in /usr/ports/x11/kdebase4. Cheers, Lawrence From hselasky at c2i.net Thu Jul 2 15:01:14 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Jul 2 15:01:23 2009 Subject: Temporary patch to fix USB in kdebase4 In-Reply-To: <4A4CC9C1.4080200@freebsd.org> References: <200906080902.43391.hselasky@c2i.net> <4A4CC9C1.4080200@freebsd.org> Message-ID: <200907021700.39350.hselasky@c2i.net> On Thursday 02 July 2009 16:52:49 Lawrence Stewart wrote: > Hans Petter Selasky wrote: > > See attachment. > > --HPS > > Any chance you (or someone with the right clue) could update this patch > to work with more recent 8-CURRENT? I get the following output when > trying to compile kdebase4 (which applies your original patch as > extra-patch-libusb20) on r195046 world/kernel: > > > Scanning dependencies of target kcm_usb > > [ 67%] Building CXX object > apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o > [ 67%] Building CXX object > apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o > In file included from > /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevi >ces.h:20, > > Hi, It looks like you have two set of header files. Second, change the USB "dev/" header files to: # include # include Else there are no further changes. --HPS From lstewart at freebsd.org Thu Jul 2 15:14:42 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Thu Jul 2 15:14:54 2009 Subject: Temporary patch to fix USB in kdebase4 In-Reply-To: <200907021700.39350.hselasky@c2i.net> References: <200906080902.43391.hselasky@c2i.net> <4A4CC9C1.4080200@freebsd.org> <200907021700.39350.hselasky@c2i.net> Message-ID: <4A4CCECA.40607@freebsd.org> Hans Petter Selasky wrote: > On Thursday 02 July 2009 16:52:49 Lawrence Stewart wrote: >> Hans Petter Selasky wrote: >>> See attachment. >>> --HPS >> Any chance you (or someone with the right clue) could update this patch >> to work with more recent 8-CURRENT? I get the following output when >> trying to compile kdebase4 (which applies your original patch as >> extra-patch-libusb20) on r195046 world/kernel: >> >> >> Scanning dependencies of target kcm_usb >> >> [ 67%] Building CXX object >> apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o >> [ 67%] Building CXX object >> apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o >> In file included from >> /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevi >> ces.h:20, >> >> > > Hi, > > It looks like you have two set of header files. Second, change the USB "dev/" > header files to: > > # include > # include > > Else there are no further changes. ah ha, had forgotten to run "make delete-old" after last update. Thanks for the hint and thanks for the include fix. Trying it out now. Cheers, Lawrence From mezz7 at cox.net Thu Jul 2 15:31:24 2009 From: mezz7 at cox.net (Jeremy Messenger) Date: Thu Jul 2 15:31:36 2009 Subject: Temporary patch to fix USB in kdebase4 In-Reply-To: <4A4CC9C1.4080200@freebsd.org> References: <200906080902.43391.hselasky@c2i.net> <4A4CC9C1.4080200@freebsd.org> Message-ID: On Thu, 02 Jul 2009 09:52:49 -0500, Lawrence Stewart wrote: > Hans Petter Selasky wrote: >> See attachment. >> --HPS > > Any chance you (or someone with the right clue) could update this patch > to work with more recent 8-CURRENT? I get the following output when > trying to compile kdebase4 (which applies your original patch as > extra-patch-libusb20) on r195046 world/kernel: There is no usb_revision.h in recently -CURRENT. I have nothing of it in my system, I always run make delete-old and delete-old-libs. However, I am able to installed both kdebase3 and kdebase4 by tweak in extra-patch-libusb20. All I have to do like this: Change from: +#include To: +/*#include */ As for the kdebase3, I just took a patch from ports/135860 then tweak a bit. I am planning to follow up in its PR. But, I haven't run those in runtime yet thought. Cheers, Mezz > Scanning dependencies of target kcm_usb [ 67%] Building CXX object > apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o > [ 67%] Building CXX object > apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o > In file included from > /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevices.h:20, > from > /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/kcmusb.cpp:27: > /usr/include/dev/usb/usb_revision.h:33: error: multiple definition of > 'enum usb_dev_speed' > /usr/include/dev/usb/usb.h:686: error: previous definition here > /usr/include/dev/usb/usb_revision.h:34: error: conflicting declaration > 'USB_SPEED_VARIABLE' > /usr/include/dev/usb/usb.h:687: error: 'USB_SPEED_VARIABLE' has a > previous declaration as 'usb_dev_speed USB_SPEED_VARIABLE' > /usr/include/dev/usb/usb_revision.h:35: error: conflicting declaration > 'USB_SPEED_LOW' > /usr/include/dev/usb/usb.h:688: error: 'USB_SPEED_LOW' has a previous > declaration as 'usb_dev_speed USB_SPEED_LOW' > /usr/include/dev/usb/usb_revision.h:36: error: conflicting declaration > 'USB_SPEED_FULL' > /usr/include/dev/usb/usb.h:689: error: 'USB_SPEED_FULL' has a previous > declaration as 'usb_dev_speed USB_SPEED_FULL' > /usr/include/dev/usb/usb_revision.h:37: error: conflicting declaration > 'USB_SPEED_HIGH' > /usr/include/dev/usb/usb.h:690: error: 'USB_SPEED_HIGH' has a previous > declaration as 'usb_dev_speed USB_SPEED_HIGH' > /usr/include/dev/usb/usb_revision.h:38: error: conflicting declaration > 'USB_SPEED_SUPER' > /usr/include/dev/usb/usb.h:691: error: 'USB_SPEED_SUPER' has a previous > declaration as 'usb_dev_speed USB_SPEED_SUPER' > /usr/include/dev/usb/usb_revision.h:45: error: multiple definition of > 'enum usb_revision' > /usr/include/dev/usb/usb.h:698: error: previous definition here > /usr/include/dev/usb/usb_revision.h:46: error: conflicting declaration > 'USB_REV_UNKNOWN' > /usr/include/dev/usb/usb.h:699: error: 'USB_REV_UNKNOWN' has a previous > declaration as 'usb_revision USB_REV_UNKNOWN' > /usr/include/dev/usb/usb_revision.h:47: error: conflicting declaration > 'USB_REV_PRE_1_0' > /usr/include/dev/usb/usb.h:700: error: 'USB_REV_PRE_1_0' has a previous > declaration as 'usb_revision USB_REV_PRE_1_0' > /usr/include/dev/usb/usb_revision.h:48: error: conflicting declaration > 'USB_REV_1_0' > /usr/include/dev/usb/usb.h:701: error: 'USB_REV_1_0' has a previous > declaration as 'usb_revision USB_REV_1_0' > /usr/include/dev/usb/usb_revision.h:49: error: conflicting declaration > 'USB_REV_1_1' > /usr/include/dev/usb/usb.h:702: error: 'USB_REV_1_1' has a previous > declaration as 'usb_revision USB_REV_1_1' > /usr/include/dev/usb/usb_revision.h:50: error: conflicting declaration > 'USB_REV_2_0' > /usr/include/dev/usb/usb.h:703: error: 'USB_REV_2_0' has a previous > declaration as 'usb_revision USB_REV_2_0' > /usr/include/dev/usb/usb_revision.h:51: error: conflicting declaration > 'USB_REV_2_5' > /usr/include/dev/usb/usb.h:704: error: 'USB_REV_2_5' has a previous > declaration as 'usb_revision USB_REV_2_5' > /usr/include/dev/usb/usb_revision.h:52: error: conflicting declaration > 'USB_REV_3_0' > /usr/include/dev/usb/usb.h:705: error: 'USB_REV_3_0' has a previous > declaration as 'usb_revision USB_REV_3_0' > /usr/include/dev/usb/usb_revision.h:59: error: multiple definition of > 'enum usb_hc_mode' > /usr/include/dev/usb/usb.h:712: error: previous definition here > /usr/include/dev/usb/usb_revision.h:60: error: conflicting declaration > 'USB_MODE_HOST' > /usr/include/dev/usb/usb.h:713: error: 'USB_MODE_HOST' has a previous > declaration as 'usb_hc_mode USB_MODE_HOST' > /usr/include/dev/usb/usb_revision.h:61: error: conflicting declaration > 'USB_MODE_DEVICE' > /usr/include/dev/usb/usb.h:714: error: 'USB_MODE_DEVICE' has a previous > declaration as 'usb_hc_mode USB_MODE_DEVICE' > /usr/include/dev/usb/usb_revision.h:62: error: conflicting declaration > 'USB_MODE_DUAL' > /usr/include/dev/usb/usb.h:715: error: 'USB_MODE_DUAL' has a previous > declaration as 'usb_hc_mode USB_MODE_DUAL' > /usr/include/dev/usb/usb_revision.h:69: error: multiple definition of > 'enum usb_dev_state' > /usr/include/dev/usb/usb.h:722: error: previous definition here > /usr/include/dev/usb/usb_revision.h:70: error: conflicting declaration > 'USB_STATE_DETACHED' > /usr/include/dev/usb/usb.h:723: error: 'USB_STATE_DETACHED' has a > previous declaration as 'usb_dev_state USB_STATE_DETACHED' > /usr/include/dev/usb/usb_revision.h:71: error: conflicting declaration > 'USB_STATE_ATTACHED' > /usr/include/dev/usb/usb.h:724: error: 'USB_STATE_ATTACHED' has a > previous declaration as 'usb_dev_state USB_STATE_ATTACHED' > /usr/include/dev/usb/usb_revision.h:72: error: conflicting declaration > 'USB_STATE_POWERED' > /usr/include/dev/usb/usb.h:725: error: 'USB_STATE_POWERED' has a > previous declaration as 'usb_dev_state USB_STATE_POWERED' > /usr/include/dev/usb/usb_revision.h:73: error: conflicting declaration > 'USB_STATE_ADDRESSED' > /usr/include/dev/usb/usb.h:726: error: 'USB_STATE_ADDRESSED' has a > previous declaration as 'usb_dev_state USB_STATE_ADDRESSED' > /usr/include/dev/usb/usb_revision.h:74: error: conflicting declaration > 'USB_STATE_CONFIGURED' > /usr/include/dev/usb/usb.h:727: error: 'USB_STATE_CONFIGURED' has a > previous declaration as 'usb_dev_state USB_STATE_CONFIGURED' *** Error > code 1 > Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. > *** Error code 1 > > Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. > *** Error code 1 > > Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. > *** Error code 1 > > Stop in /usr/ports/x11/kdebase4. > > > > > Cheers, > Lawrence > _______________________________________________ > 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" -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From tim-lists at bishnet.net Thu Jul 2 15:51:04 2009 From: tim-lists at bishnet.net (Tim Bishop) Date: Thu Jul 2 15:51:13 2009 Subject: XEN kernel config - supposed to build? Message-ID: <20090702155055.GM2504@carrick.bishnet.net> I'm building the XEN kernel config on a recent (today) csup of CURRENT, but I'm getting the following build error: # make buildkernel KERNCONF=XEN ... 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/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/xen/evtchn/evtchn.c cc1: warnings being treated as errors /usr/src/sys/xen/evtchn/evtchn.c:653: warning: initialization from incompatible pointer type *** Error code 1 Is this supposed to be working? Or have I dived randomly in and missed the pool? :-) Thanks, Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From gcr+freebsd-current at tharned.org Thu Jul 2 16:37:06 2009 From: gcr+freebsd-current at tharned.org (Greg Rivers) Date: Thu Jul 2 16:37:13 2009 Subject: Panic during shutdown (cause identified) In-Reply-To: <20090702084149.GE2884@deviant.kiev.zoral.com.ua> References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> <20090702084149.GE2884@deviant.kiev.zoral.com.ua> Message-ID: On Thu, 2 Jul 2009, Kostik Belousov wrote: >>> Also, please describe the load on the machine, >>> >> >> It happens regardless of the load. For example, just booting >> multi-user and immediately running shutdown (either by logging in or >> pressing the ACPI power button) triggers the panic. > No, it does not happen regardless of the load. The patch was tested on > the semi-standard set of programs run on the system, and all seen > accounting mistakes were fixed. > I don't know what patch you're referring to. Are you saying this issue was seen before and thought to have been fixed? > You have some process that does exhibit the behaviour causing error in > swap accounting. I think for start you could just show me ps auxww > output, in private, if you prefer. > I can save you the trouble of reading ps output. Based on your insight that the problem is with a particular process, I eliminated variables from /etc/rc.conf by trial, and have determined that it's the amd(8) automounter that's causing the panic. When I remove 'amd_enable="YES"', no more panic. > > The panic message on the console does not show the process. Can that > > be determined from kgdb? If so, how? > It does show the process, like > KDB: enter: panic > [thread pid 32021 tid 100598 ] > Yes, ordinarily such message is shown, but it is not shown for this panic. Also with this panic, about half the time the machine locks up hard just before, during, or after the core dump. > BTW, did you saw the kernel messages like negative vmsize for uid = XXX ? > No, there have been none of those. Please let me know if I can help with further testing/debugging. BTW, I did not customize the amd configuration; I was using the stock configuration from the base system. -- Greg Rivers From rwatson at FreeBSD.org Thu Jul 2 18:13:40 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Jul 2 18:13:46 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: <200907011842.01710.jkim@FreeBSD.org> References: <20090701162108.GA33681@regency.nsu.ru> <200907011737.15525.jkim@FreeBSD.org> <200907011842.01710.jkim@FreeBSD.org> Message-ID: On Wed, 1 Jul 2009, Jung-uk Kim wrote: > I cannot reproduce it any more. It must be fixed already. FYI, when it > happened, I traced it down to: > > shutdown -> > dhclient closing fd -> > bpf_dtor() -> > mac_bpfdesc_destroy() -> > mac_bpfdesc_label_free() -> d->bd_label corrupt! > bpfmac_labelzone_free() -> > uma_zfree() -> > ... -> page fault! > > Any way, sorry for the noise and thanks for fixing this, whoever that is. This is almost certainly an ifnet-related race condition that has been fixed in 8.x, and that MAC is panicking is just a symptom that it picked up on a double free (or the like) since it has internal validation. It may still existing in 7.x as there's a lot of ifnet/ifaddr work I haven't MFC'd yet (and won't for a few weeks at least). Thanks, Robert N M Watson Computer Laboratory University of Cambridge From danfe at nsu.ru Thu Jul 2 17:28:02 2009 From: danfe at nsu.ru (Alexey Dokuchaev) Date: Thu Jul 2 18:28:36 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: <20090702151507.c997fa89.stas@FreeBSD.org> References: <20090701162108.GA33681@regency.nsu.ru> <20090702151507.c997fa89.stas@FreeBSD.org> Message-ID: <20090702172853.GA94604@regency.nsu.ru> Stanislav Sedov wrote: > Alexey Dokuchaev mentioned: > > I've started to observe the following rather annoying panic if I boot > > with if_sf loaded (via loader.conf) and having sf0 configured via DHCP > > on recent -CURRENT. If I comment out driver from loader.conf and load > > it manually (via kldload(8)) after system boots, it loads and gets > > configured just fine. > > > > Any clues here? Attached is relevant dmesg + DDB trace (debug kernel > > with WITNESS). I'm happy to provide any additional information (that > > is, ps/show uma/malloc, whatever). > > > > Do you use SMP system? Nope, it's good old UP box: $ dmesg | grep CPU: CPU: Intel Pentium III (1125.00-MHz 686-class CPU) ./danfe From mav at FreeBSD.org Thu Jul 2 18:31:09 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Jul 2 18:31:16 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: References: Message-ID: <4A4CFCDD.4020202@FreeBSD.org> Lucius Windschuh wrote: > I'd like to notice that the patch seems to break cdrecord -scanbus > (freshly rebuilt from the ports): > $ cdrecord -scanbus > Cdrecord-Clone 2.01 (i386-unknown-freebsd8.0) Copyright (C) 1995-2004 > J=F6rg Schilling > cdrecord: Argument list too long. CAMIOCOMMAND ioctl failed. Cannot > open SCSI driver. > cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are r= > oot. > cdrecord: For possible transport specifiers try 'cdrecord dev=3Dhelp'. It is the same problem I have fixed in camcontrol. You can do the same with changing in scsi-bsd.c in cdrtools #define>CAM_MAXDEVS 128 to #define>CAM_MAXDEVS 50. I hope it is temporal solution. I am thinking about to remove or at least rise that limitation. -- Alexander Motin From mike at sentex.net Thu Jul 2 19:02:12 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Jul 2 19:02:19 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A471F44.7010108@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> Message-ID: <200907021859.n62IxghN009931@lava.sentex.ca> At 03:44 AM 6/28/2009, Alexander Motin wrote: >I see no any relation to the patch here. I would say it is some >BIOS/loader problem, as kernel wasn't yet booted. Have you been ever >able to boot this system with AHCI enabled before? I re-installed the OS on a new drive with a 200906 snapshot, and can now boot with AHCI enabled in the BIOS. The original image was a RELENG_7 box that I upgraded to HEAD some time ago. Is there something that needs to be manually updated that would not have been done as part of the normal buildworld/buildkernel ? Re-install the boot blocks perhaps ? ahci0: port 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb49f mem 0xfadd6000-0xfadd67ff irq 19 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.20 controller with 6 3Gbps ports, PM not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] On the ich10 board, its trying to boot up now, but I am getting uhub8: 4 ports with 4 removable, self powered (probe2:ahcich2:0:0:0): SIGNATURE: eb14 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ahcich2: Timeout on slot 4 run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config ahcich2: Timeout on slot 5 run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config ahcich2: Timeout on slot 6 run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config ahcich2: Timeout on slot 7 run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config ahcich2: Timeout on slot 8 ada0 at ahcich1 bus 0 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing Enabled mountroot> ufs:/dev/ada0s1 Trying to mount root from ufs:/dev/ada0s1 GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). And then it hangs there. ---Mike From mav at FreeBSD.org Thu Jul 2 19:33:30 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Jul 2 19:33:36 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <200907021859.n62IxghN009931@lava.sentex.ca> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> Message-ID: <4A4D0B7E.8060503@FreeBSD.org> Mike Tancsa wrote: > At 03:44 AM 6/28/2009, Alexander Motin wrote: >> I see no any relation to the patch here. I would say it is some >> BIOS/loader problem, as kernel wasn't yet booted. Have you been ever >> able to boot this system with AHCI enabled before? > > I re-installed the OS on a new drive with a 200906 snapshot, and can now > boot with AHCI enabled in the BIOS. The original image was a RELENG_7 > box that I upgraded to HEAD some time ago. Is there something that needs > to be manually updated that would not have been done as part of the > normal buildworld/buildkernel ? Re-install the boot blocks perhaps ? mergemaster? As soon as you are able to run kernel, loaders are fine. > ahci0: port > 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb49f > mem 0xfadd6000-0xfadd67ff irq 19 at device 31.2 on pci0 > ahci0: [ITHREAD] > ahci0: AHCI v1.20 controller with 6 3Gbps ports, PM not supported > ahcich0: at channel 0 on ahci0 > ahcich0: [ITHREAD] > ahcich1: at channel 1 on ahci0 > ahcich1: [ITHREAD] > ahcich2: at channel 2 on ahci0 > ahcich2: [ITHREAD] > ahcich3: at channel 3 on ahci0 > ahcich3: [ITHREAD] > ahcich4: at channel 4 on ahci0 > ahcich4: [ITHREAD] > ahcich5: at channel 5 on ahci0 > ahcich5: [ITHREAD] > > On the ich10 board, its trying to boot up now, but I am getting > > uhub8: 4 ports with 4 removable, self powered > (probe2:ahcich2:0:0:0): SIGNATURE: eb14 Looks like you have CD on third SATA channel. > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > ahcich2: Timeout on slot 4 > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > ahcich2: Timeout on slot 5 > run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config > ahcich2: Timeout on slot 6 > run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config > ahcich2: Timeout on slot 7 > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > ahcich2: Timeout on slot 8 And this CD does not really wants speak. > ada0 at ahcich1 bus 0 target 0 lun 0 > ada0: ATA/ATAPI-8 SATA 2.x device > ada0: 300.000MB/s transfers > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: Native Command Queueing Enabled > > mountroot> ufs:/dev/ada0s1 > Trying to mount root from ufs:/dev/ada0s1 > GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). As soon as GEOM found the label, disk seems to work. > And then it hangs there. Can you try to disconnect CD? -- Alexander Motin From kostikbel at gmail.com Thu Jul 2 19:44:51 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Jul 2 19:44:59 2009 Subject: Panic during shutdown (cause identified) In-Reply-To: References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> <20090702084149.GE2884@deviant.kiev.zoral.com.ua> Message-ID: <20090702194444.GK2884@deviant.kiev.zoral.com.ua> On Thu, Jul 02, 2009 at 11:37:01AM -0500, Greg Rivers wrote: > On Thu, 2 Jul 2009, Kostik Belousov wrote: > > >>>Also, please describe the load on the machine, > >>> > >> > >>It happens regardless of the load. For example, just booting > >>multi-user and immediately running shutdown (either by logging in or > >>pressing the ACPI power button) triggers the panic. > >No, it does not happen regardless of the load. The patch was tested on > >the semi-standard set of programs run on the system, and all seen > >accounting mistakes were fixed. > > > > I don't know what patch you're referring to. Are you saying this issue > was seen before and thought to have been fixed? The issue is an indicator of the bug somewhere else, in the code that does precise swap accounting. I committed that approximately one week ago. The patch I am referring to is the r194766. > > > >You have some process that does exhibit the behaviour causing error in > >swap accounting. I think for start you could just show me ps auxww > >output, in private, if you prefer. > > > > I can save you the trouble of reading ps output. Based on your insight > that the problem is with a particular process, I eliminated variables from > /etc/rc.conf by trial, and have determined that it's the amd(8) > automounter that's causing the panic. When I remove 'amd_enable="YES"', > no more panic. > > > >> The panic message on the console does not show the process. Can that > >> be determined from kgdb? If so, how? > >It does show the process, like > >KDB: enter: panic > >[thread pid 32021 tid 100598 ] > > > > Yes, ordinarily such message is shown, but it is not shown for this panic. > Also with this panic, about half the time the machine locks up hard just > before, during, or after the core dump. > > > >BTW, did you saw the kernel messages like negative vmsize for uid = XXX ? > > > > No, there have been none of those. > > > Please let me know if I can help with further testing/debugging. BTW, I > did not customize the amd configuration; I was using the stock > configuration from the base system. The information you provided about amd(8) causing the problem was crusial. The issue is that amd locks its pages with mlockall(2), and the code neglected to account the wired mappings, but did not forgot to decrease their swap share on unmapping. Patch below fixed the issue for me. diff --git a/sys/vm/vm_extern.h b/sys/vm/vm_extern.h index 7bacde4..ec21a3a 100644 --- a/sys/vm/vm_extern.h +++ b/sys/vm/vm_extern.h @@ -55,7 +55,8 @@ vm_map_t kmem_suballoc(vm_map_t, vm_offset_t *, vm_offset_t *, vm_size_t, void swapout_procs(int); int useracc(void *, int, int); int vm_fault(vm_map_t, vm_offset_t, vm_prot_t, int); -void vm_fault_copy_entry(vm_map_t, vm_map_t, vm_map_entry_t, vm_map_entry_t); +void vm_fault_copy_entry(vm_map_t, vm_map_t, vm_map_entry_t, vm_map_entry_t, + vm_ooffset_t *); void vm_fault_unwire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); int vm_fault_wire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t, boolean_t); int vm_forkproc(struct thread *, struct proc *, struct thread *, struct vmspace *, int); diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c index 43743f4..579cf49 100644 --- a/sys/vm/vm_fault.c +++ b/sys/vm/vm_fault.c @@ -1126,11 +1126,9 @@ vm_fault_unwire(vm_map_t map, vm_offset_t start, vm_offset_t end, * entry corresponding to a main map entry that is wired down). */ void -vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry) - vm_map_t dst_map; - vm_map_t src_map; - vm_map_entry_t dst_entry; - vm_map_entry_t src_entry; +vm_fault_copy_entry(vm_map_t dst_map, vm_map_t src_map, + vm_map_entry_t dst_entry, vm_map_entry_t src_entry, + vm_ooffset_t *fork_charge) { vm_object_t backing_object, dst_object, object; vm_object_t src_object; @@ -1163,10 +1161,12 @@ vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry) VM_OBJECT_LOCK(dst_object); dst_entry->object.vm_object = dst_object; dst_entry->offset = 0; - if (dst_entry->uip != NULL) { - dst_object->uip = dst_entry->uip; + if (fork_charge != NULL) { + dst_object->uip = curthread->td_ucred->cr_ruidinfo; + uihold(dst_object->uip); dst_object->charge = dst_entry->end - dst_entry->start; dst_entry->uip = NULL; + *fork_charge += dst_entry->end - dst_entry->start; } prot = dst_entry->max_protection; diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 82d37e6..ea6f713 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -2909,7 +2909,8 @@ vm_map_copy_entry( * Cause wired pages to be copied into the new map by * simulating faults (the new pages are pageable) */ - vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry); + vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry, + fork_charge); } } -------------- 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/20090702/1da0a3f8/attachment.pgp From ken at mthelicon.com Thu Jul 2 20:36:18 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Thu Jul 2 20:36:31 2009 Subject: Has anyone been able to actually boot the AMD64 kernel after r194958? In-Reply-To: <4A4CC937.5050008@fletchermoorland.co.uk> References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> <4A4CC937.5050008@fletchermoorland.co.uk> Message-ID: <200907022136.04164.ken@mthelicon.com> On Thursday 02 July 2009 15:50:31 Paul Wootton wrote: > > With you saying this, I decided to try GENERIC kernel configuration and > that builds and runs just fine. I suspect that Peg and myself have > something in our kernel conf files that is causing an issue. I'll have a > go later on and see if I can narrow it down a little bit more > > Paul > Hi Paul, I think I may have tracked down the trigger, although I dont know how to pin- point the cause. It looks like compiling in the radeondrm driver into the kernel is the culprit. if I omit that line from my kernel config, the latest kernels will compile and boot properly on my machine. I'm using a R7xx (but it load the R6xx code) radeon HD card. From talking to you, I know you are using a proper R6xx card. Strangely I can kldload the driver after the machine has booted and all is well, it just seems to hate being compiled into the kernel. Can you see if this is the same on your machine? Peg From ken at mthelicon.com Thu Jul 2 20:36:18 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Thu Jul 2 20:36:31 2009 Subject: Has anyone been able to actually boot the AMD64 kernel after r194958? In-Reply-To: <4A4CC937.5050008@fletchermoorland.co.uk> References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> <4A4CC937.5050008@fletchermoorland.co.uk> Message-ID: <200907022136.04164.ken@mthelicon.com> On Thursday 02 July 2009 15:50:31 Paul Wootton wrote: > > With you saying this, I decided to try GENERIC kernel configuration and > that builds and runs just fine. I suspect that Peg and myself have > something in our kernel conf files that is causing an issue. I'll have a > go later on and see if I can narrow it down a little bit more > > Paul > Hi Paul, I think I may have tracked down the trigger, although I dont know how to pin- point the cause. It looks like compiling in the radeondrm driver into the kernel is the culprit. if I omit that line from my kernel config, the latest kernels will compile and boot properly on my machine. I'm using a R7xx (but it load the R6xx code) radeon HD card. From talking to you, I know you are using a proper R6xx card. Strangely I can kldload the driver after the machine has booted and all is well, it just seems to hate being compiled into the kernel. Can you see if this is the same on your machine? Peg From pluknet at gmail.com Thu Jul 2 20:49:21 2009 From: pluknet at gmail.com (pluknet) Date: Thu Jul 2 20:49:27 2009 Subject: Panic during shutdown (cause identified) In-Reply-To: <20090702194444.GK2884@deviant.kiev.zoral.com.ua> References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> <20090702084149.GE2884@deviant.kiev.zoral.com.ua> <20090702194444.GK2884@deviant.kiev.zoral.com.ua> Message-ID: 2009/7/2 Kostik Belousov : > On Thu, Jul 02, 2009 at 11:37:01AM -0500, Greg Rivers wrote: >> Please let me know if I can help with further testing/debugging. BTW, I >> did not customize the amd configuration; I was using the stock >> configuration from the base system. > > The information you provided about amd(8) causing the problem was crusial. > The issue is that amd locks its pages with mlockall(2), and the code > neglected to account the wired mappings, but did not forgot to decrease > their swap share on unmapping. > > Patch below fixed the issue for me. I can confirm that simply staring amd(8) daemon and then reboot would cause such panic in swap accounting. I saw a dozen messages "negative vmsize for uid = 0" in time just before panic. This patch fixes that for me. my 2c. -- wbr, pluknet From mike at sentex.net Thu Jul 2 21:20:22 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Jul 2 21:20:28 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A4D0B7E.8060503@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> Message-ID: <200907022117.n62LHrvZ010791@lava.sentex.ca> At 03:33 PM 7/2/2009, Alexander Motin wrote: >As soon as GEOM found the label, disk seems to work. Actually, It went to single user mode on the console (I was logged in via serial console). However, I could not mount anything for some reason. Going in /dev, only /dev/ada0 and /dev/ada0s1 were there. The disk slices were not for some reason. This was on an AMD64 kernel BTW. But, going back to the original i386 image, with the boot blocks reinstalled and using your latest patch, it seems to work! (however, the same 300sec delay due to the cdrom ? ) mountroot> ufs:/dev/ada0s1a Trying to mount root from ufs:/dev/ada0s1a dumpon: /dev/ad4s1b: No such file or directory /etc/rc: WARNING: unable to specify /dev/ad4s1b as a dump device Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: /dev/ad4s1b: No such file or directory /dev/ada0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s1a: clean, 259768 free (1048 frags, 32340 blocks, 0.2% fragmentation) Can't stat /dev/ad4s1d: No such file or directorJul 1 08:07:58 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: # ls -l /dev/ad* crw-r----- 1 root operator 0, 111 Jul 1 08:02 /dev/ada0 crw-r----- 1 root operator 0, 112 Jul 1 08:02 /dev/ada0s1 crw-r----- 1 root operator 0, 113 Jul 1 08:02 /dev/ada0s1a crw-r----- 1 root operator 0, 114 Jul 1 08:02 /dev/ada0s1b crw-r----- 1 root operator 0, 115 Jul 1 08:02 /dev/ada0s1d crw-r----- 1 root operator 0, 116 Jul 1 08:02 /dev/ada0s1e crw-r----- 1 root operator 0, 117 Jul 1 08:02 /dev/ada0s1f # And, after its booted up, ahci0: port 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb49f mem 0xfadd6000-0xfadd67ff irq 19 at device 31.2 on pci0 ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfadd6000 ahci0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 262 to local APIC 0 vector 64 ahci0: using IRQ 262 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.20 controller with 6 3Gbps ports, PM not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 6ports ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [MPSAFE] ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [MPSAFE] ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [MPSAFE] ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [MPSAFE] ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [MPSAFE] ahcich5: [ITHREAD] ---Mike From jilles at stack.nl Thu Jul 2 21:25:07 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Thu Jul 2 21:25:14 2009 Subject: Install from NFS onto NFS fails on amd64 In-Reply-To: <20090702122955.J245@maildrop.int.zabbadoz.net> References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> Message-ID: <20090702212505.GA39889@stack.nl> On Thu, Jul 02, 2009 at 12:31:16PM +0000, Bjoern A. Zeeb wrote: > On Thu, 2 Jul 2009, Bjoern A. Zeeb wrote: > > trying to installworld from NFS to NFS (which also is the NFS Root > > of the installing and to be updated machien) on amd64 always fails > > with this error. Anyone knows why that is? > > ------------------------------------------------------------------------ > > lion1# make installworld -DNO_FSCHG > > ... > > ... > > ... > > install -s -o root -g wheel -m 555 ldd32 /usr/bin > > rm: /tmp/install.uMl44I7W: Directory not empty > > *** Error code 1 > > > > Stop in /zoo/bz/HEAD.svn. > > *** Error code 1 > > > > Stop in /zoo/bz/HEAD.svn. > > lion1# > > ------------------------------------------------------------------------ > I probably should have added that the directory is empty: > lion1# ls -la /tmp/install.uMl44I7W > total 4 > drwxr-xr-x 2 root wheel 1024 Jul 2 12:15 . > drwxrwxrwt 15 root wheel 1024 Jul 2 12:10 .. > and I am well aware that that is one of the last things that make > installworld does; it's just strange and I blame it on NFS;-) This could be because of NFS "sillyrename". To avoid some ESTALE errors, the NFS client (for NFSv2 and NFSv3 at least) renames if you delete a file that is currently in use (in this case, the rm binary). Because the renamed file (name typically starts with .nfs) is in the same directory, this causes problems when removing directories. Once the file is no longer in use, it is finally deleted. Without sillyrename, rm could segfault after deleting itself. Maybe NFSv4 has a cleaner way to keep a file with 0 links as long as it is open. -- Jilles Tjoelker From jhb at FreeBSD.org Thu Jul 2 22:36:20 2009 From: jhb at FreeBSD.org (John Baldwin) Date: Thu Jul 2 22:36:31 2009 Subject: panic on acpi_cpu_c1() In-Reply-To: References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> Message-ID: <4A4D3665.3060502@FreeBSD.org> Maxim Ignatenko wrote: >> Fatal trap 30: reserved (unknown) fault while in kernel mode >> cpuid = 3; apic id = 03 >> instruction pointer = 0x20:0xffffffff804bce56 >> stack pointer = 0x20:0xffffff8000039b60 >> frame pointer = 0x20:0xffffff8000039b70 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, IOPL = 0 >> current process = 11 (idle: cpu3) >> [thread pid 11 tid 100003 ] >> Stopped at acpi_cpu_c1+0x6: leave >> db> bt >> Tracing pid 11 tid 100003 td 0xffffff8001863720 >> acpi_cpu_c1() at acpi_cpu_c1+0x6 >> acpi_cpu_idle() at acpi_cpu_idle+0x20c >> sched_idletd() at sched_idletd+0x123 >> fork_exit() at fork_exit+0x117 >> fork_trampoline() at fork_trampoline+0xe > > As for me, r194984 runs normally, but when I tried to boot with > r194985 at second try it paniced with backtrace very similar to shown > in first message, and at first try even earlier: in sched_ideltd and > again on instruction that uses %ebp when ebp = 0. > First time I stepped on this panic after updating to r195130: > > Trying to mount root from ufs:/dev/ufs/root > > > Fatal trap 30; reserved (unknown) fault while in kernel mode > cpuid = 1; apic id = 01 > instruction ponter = 0x20:0xc09252c5 > stack pointer = 0x28:0xc4ecec94 > frame pointer = 0x28:0xc4ecec94 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 11 (idle: cpu1) > [thread pid 11 tid 100003] > Stopped at 0xc09252c5 = acpi_cpu_c1+0x5: popl %ebp > db> bt > Tracing pid 11 tid 100003 td 0xc5176af0 > acpi_cpu_c1(1,c4ececa8,1,0,c4ececc0,...) at 0xc09252c5 = acpi_cpu_c1+0x5 > acpi_cpu_idle(c4ececd4,c093c0ab,0,c4ececf4,c066fdec,...) at 0xc04acf37 > = acpi_cpu_idle+0x107 > cpu_idle_acpi(0,c4ececf4,c066fdec,0,0,...) at 0xc093d5bb = cpu_idle_acpi+0x1b > cpu_idle(0,0,c5176af0,c4ececf4,202,...) at 0xc093c0ab = cpu_idle+0x1b > sched_idletd(0,c4ececd38,a4108400,2c0a0e,7022d00,...) at 0xc066fdec = > sched_idletd+0x1c > fork_exit(c066fdd0,0,c4eced38) at 0xc0623aa1 = fork_exit+0x91 > fork_trampoline() at 0xc0930c80 = fork_tramoline+0x8 > --- trap 0, eip = 0, esp = 0xc4ececd70, ebp = 0 --- > > > P.S.: i386, dual-core, drm and radeon compiled as modules > When I'm trying to boot w/o ACPI support all seems work fine, but > system hangs just before starting kdm Please try http://www.FreeBSD.org/~jhb/patches/msi_assign.patch -- John Baldwin From max at love2party.net Fri Jul 3 00:04:54 2009 From: max at love2party.net (Max Laier) Date: Fri Jul 3 00:05:01 2009 Subject: MD5 test slowdown In-Reply-To: References: Message-ID: <200907030204.51415.max@love2party.net> On Thursday 02 July 2009 13:32:08 Rafal Jaworowski wrote: > I'm observing some heavy slowdown seen with md5 test on PowerPC: > > 1. On the MPC8572 machine with today's HEAD I'm getting: > > # md5 -t > MD5 time trial. Digesting 100000 10000-byte blocks ... done > Digest = 766a2bb5d24bddae466c572bcabca3ee > Time = 36.930565 seconds > Speed = 27077842.000000 bytes/second > > 2. While a couple of months back it yielded 6x shorter times on this > very same hardware, like this one: > > # md5 -t > MD5 time trial. Digesting 100000 10000-byte blocks ... done > Digest = 766a2bb5d24bddae466c572bcabca3ee > Time = 6.027277 seconds > Speed = 165912400.000000 bytes/second > > Timers work fine, the slowdown is real. I don't know if this is > PowerPC related, and was wondering if anybody observed something > similar on other archs perhaps? Any suggestions what could be causing > this or where to look? I cannot see immediate suspects in the arch/ > platform code. "signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64" to this mailing list reports something that might be related. It seems there is a patch available, but not committed yet. Though I'm not sure about the nature of the problem exactly. Jeff? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From gcr+freebsd-current at tharned.org Fri Jul 3 01:24:32 2009 From: gcr+freebsd-current at tharned.org (Greg Rivers) Date: Fri Jul 3 01:24:40 2009 Subject: Panic during shutdown (cause identified) In-Reply-To: <20090702194444.GK2884@deviant.kiev.zoral.com.ua> References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> <20090702084149.GE2884@deviant.kiev.zoral.com.ua> <20090702194444.GK2884@deviant.kiev.zoral.com.ua> Message-ID: On Thu, 2 Jul 2009, Kostik Belousov wrote: > The information you provided about amd(8) causing the problem was > crusial. The issue is that amd locks its pages with mlockall(2), and > the code neglected to account the wired mappings, but did not forgot to > decrease their swap share on unmapping. > > Patch below fixed the issue for me. > [snip] > Confirmed: your patch fixes the issue for me as well. Thanks! -- Greg Rivers From swell.k at gmail.com Fri Jul 3 02:09:00 2009 From: swell.k at gmail.com (Anonymous) Date: Fri Jul 3 02:09:06 2009 Subject: panic on acpi_cpu_c1() References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> <4A4D3665.3060502@FreeBSD.org> Message-ID: <86hbxujz6s.fsf@gmail.com> John Baldwin writes: > Maxim Ignatenko wrote: >>> Fatal trap 30: reserved (unknown) fault while in kernel mode >>> cpuid = 3; apic id = 03 >>> instruction pointer = 0x20:0xffffffff804bce56 >>> stack pointer = 0x20:0xffffff8000039b60 >>> frame pointer = 0x20:0xffffff8000039b70 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, IOPL = 0 >>> current process = 11 (idle: cpu3) >>> [thread pid 11 tid 100003 ] >>> Stopped at acpi_cpu_c1+0x6: leave >>> db> bt >>> Tracing pid 11 tid 100003 td 0xffffff8001863720 >>> acpi_cpu_c1() at acpi_cpu_c1+0x6 >>> acpi_cpu_idle() at acpi_cpu_idle+0x20c >>> sched_idletd() at sched_idletd+0x123 >>> fork_exit() at fork_exit+0x117 >>> fork_trampoline() at fork_trampoline+0xe >> >> As for me, r194984 runs normally, but when I tried to boot with >> r194985 at second try it paniced with backtrace very similar to shown >> in first message, and at first try even earlier: in sched_ideltd and >> again on instruction that uses %ebp when ebp = 0. >> First time I stepped on this panic after updating to r195130: >> >> Trying to mount root from ufs:/dev/ufs/root >> >> >> Fatal trap 30; reserved (unknown) fault while in kernel mode >> cpuid = 1; apic id = 01 >> instruction ponter = 0x20:0xc09252c5 >> stack pointer = 0x28:0xc4ecec94 >> frame pointer = 0x28:0xc4ecec94 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, IOPL = 0 >> current process = 11 (idle: cpu1) >> [thread pid 11 tid 100003] >> Stopped at 0xc09252c5 = acpi_cpu_c1+0x5: popl %ebp >> db> bt >> Tracing pid 11 tid 100003 td 0xc5176af0 >> acpi_cpu_c1(1,c4ececa8,1,0,c4ececc0,...) at 0xc09252c5 = acpi_cpu_c1+0x5 >> acpi_cpu_idle(c4ececd4,c093c0ab,0,c4ececf4,c066fdec,...) at 0xc04acf37 >> = acpi_cpu_idle+0x107 >> cpu_idle_acpi(0,c4ececf4,c066fdec,0,0,...) at 0xc093d5bb = cpu_idle_acpi+0x1b >> cpu_idle(0,0,c5176af0,c4ececf4,202,...) at 0xc093c0ab = cpu_idle+0x1b >> sched_idletd(0,c4ececd38,a4108400,2c0a0e,7022d00,...) at 0xc066fdec = >> sched_idletd+0x1c >> fork_exit(c066fdd0,0,c4eced38) at 0xc0623aa1 = fork_exit+0x91 >> fork_trampoline() at 0xc0930c80 = fork_tramoline+0x8 >> --- trap 0, eip = 0, esp = 0xc4ececd70, ebp = 0 --- >> >> >> P.S.: i386, dual-core, drm and radeon compiled as modules >> When I'm trying to boot w/o ACPI support all seems work fine, but >> system hangs just before starting kdm > > Please try http://www.FreeBSD.org/~jhb/patches/msi_assign.patch This fixes the panic for me. Loading drm module either at loader prompt or compiling it in both works with your patch. From swell.k at gmail.com Fri Jul 3 02:26:51 2009 From: swell.k at gmail.com (Anonymous) Date: Fri Jul 3 02:26:58 2009 Subject: Has anyone been able to actually boot the AMD64 kernel after r194958? In-Reply-To: <200907022136.04164.ken@mthelicon.com> (Pegasus Mc Cleaft's message of "Thu, 2 Jul 2009 21:36:03 +0100") References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> <4A4CC937.5050008@fletchermoorland.co.uk> <200907022136.04164.ken@mthelicon.com> Message-ID: <86ab3mec36.fsf@gmail.com> Pegasus Mc Cleaft writes: > On Thursday 02 July 2009 15:50:31 Paul Wootton wrote: >> >> With you saying this, I decided to try GENERIC kernel configuration and >> that builds and runs just fine. I suspect that Peg and myself have >> something in our kernel conf files that is causing an issue. I'll have a >> go later on and see if I can narrow it down a little bit more >> >> Paul >> > Hi Paul, > > I think I may have tracked down the trigger, although I dont know how to pin- > point the cause. > > It looks like compiling in the radeondrm driver into the kernel is the > culprit. if I omit that line from my kernel config, the latest kernels will > compile and boot properly on my machine. I'm using a R7xx (but it load the > R6xx code) radeon HD card. From talking to you, I know you are using a proper > R6xx card. I think this is related to the recent problem described in "panic on acpi_cpu_c1()" thread[1]. There is at least one patch and two workarounds (load drm module after boot or set hw.drm.msi=0 at loader prompt). [1] http://docs.freebsd.org/cgi/mid.cgi?4A4D3665.3060502 > > Strangely I can kldload the driver after the machine has booted and all is > well, it just seems to hate being compiled into the kernel. > > Can you see if this is the same on your machine? > > Peg From james-freebsd-current at jrv.org Fri Jul 3 07:26:17 2009 From: james-freebsd-current at jrv.org (James R. Van Artsdalen) Date: Fri Jul 3 07:26:24 2009 Subject: how to enable /dev/ufs? Message-ID: <4A4DB284.607@jrv.org> amd64, svn HEAD 195136 June 28, 2009 What enables /dev/ufs and /dev/ufsid? Below /usr is labeled yet /dev/ufs and /dev/ufsid are empty. geom label is loaded. [root@esata /usr/home/james]# tunefs -p /usr tunefs: ACLs: (-a) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) usr [root@esata /usr/home/james]# ls -la /dev/ufs total 1 dr-xr-xr-x 2 root wheel 512 Jul 2 23:06 . dr-xr-xr-x 9 root wheel 512 Jul 2 18:06 .. [root@esata /usr/home/james]# kldstat Id Refs Address Size Name 1 13 0xffffffff80100000 e6c278 kernel 2 1 0xffffffff80f6d000 196550 zfs.ko 3 2 0xffffffff81104000 3a90 opensolaris.ko 4 1 0xffffffff81108000 8958 geom_label.ko 5 1 0xffffffff81111000 23e30 geom_mirror.ko [root@esata /usr/home/james]# ls -la /dev/ufsid/ total 1 dr-xr-xr-x 2 root wheel 512 Jul 2 23:06 . dr-xr-xr-x 9 root wheel 512 Jul 2 18:06 .. [root@esata /usr/home/james]# From max at love2party.net Fri Jul 3 07:41:54 2009 From: max at love2party.net (Max Laier) Date: Fri Jul 3 07:42:03 2009 Subject: how to enable /dev/ufs? In-Reply-To: <4A4DB284.607@jrv.org> References: <4A4DB284.607@jrv.org> Message-ID: <200907030941.52387.max@love2party.net> On Friday 03 July 2009 09:25:56 James R. Van Artsdalen wrote: > amd64, svn HEAD 195136 June 28, 2009 > > What enables /dev/ufs and /dev/ufsid? Below /usr is labeled yet > /dev/ufs and /dev/ufsid are empty. geom label is loaded. > > [root@esata /usr/home/james]# tunefs -p /usr > tunefs: ACLs: (-a) disabled > tunefs: MAC multilabel: (-l) disabled > tunefs: soft updates: (-n) enabled > tunefs: gjournal: (-J) disabled > tunefs: maximum blocks per file in a cylinder group: (-e) 2048 > tunefs: average file size: (-f) 16384 > tunefs: average number of files in a directory: (-s) 64 > tunefs: minimum percentage of free space: (-m) 8% > tunefs: optimization preference: (-o) time > tunefs: volume label: (-L) usr > [root@esata /usr/home/james]# ls -la /dev/ufs > total 1 > dr-xr-xr-x 2 root wheel 512 Jul 2 23:06 . > dr-xr-xr-x 9 root wheel 512 Jul 2 18:06 .. > [root@esata /usr/home/james]# kldstat > Id Refs Address Size Name > 1 13 0xffffffff80100000 e6c278 kernel > 2 1 0xffffffff80f6d000 196550 zfs.ko > 3 2 0xffffffff81104000 3a90 opensolaris.ko > 4 1 0xffffffff81108000 8958 geom_label.ko > 5 1 0xffffffff81111000 23e30 geom_mirror.ko > [root@esata /usr/home/james]# ls -la /dev/ufsid/ > total 1 > dr-xr-xr-x 2 root wheel 512 Jul 2 23:06 . > dr-xr-xr-x 9 root wheel 512 Jul 2 18:06 .. > [root@esata /usr/home/james]# Once the partition is mounted, the label link is removed. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From kostikbel at gmail.com Fri Jul 3 08:20:47 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Jul 3 08:20:53 2009 Subject: MD5 test slowdown In-Reply-To: <200907030204.51415.max@love2party.net> References: <200907030204.51415.max@love2party.net> Message-ID: <20090703082040.GN2884@deviant.kiev.zoral.com.ua> On Fri, Jul 03, 2009 at 02:04:50AM +0200, Max Laier wrote: > On Thursday 02 July 2009 13:32:08 Rafal Jaworowski wrote: > > I'm observing some heavy slowdown seen with md5 test on PowerPC: > > > > 1. On the MPC8572 machine with today's HEAD I'm getting: > > > > # md5 -t > > MD5 time trial. Digesting 100000 10000-byte blocks ... done > > Digest = 766a2bb5d24bddae466c572bcabca3ee > > Time = 36.930565 seconds > > Speed = 27077842.000000 bytes/second > > > > 2. While a couple of months back it yielded 6x shorter times on this > > very same hardware, like this one: > > > > # md5 -t > > MD5 time trial. Digesting 100000 10000-byte blocks ... done > > Digest = 766a2bb5d24bddae466c572bcabca3ee > > Time = 6.027277 seconds > > Speed = 165912400.000000 bytes/second > > > > Timers work fine, the slowdown is real. I don't know if this is > > PowerPC related, and was wondering if anybody observed something > > similar on other archs perhaps? Any suggestions what could be causing > > this or where to look? I cannot see immediate suspects in the arch/ > > platform code. > > "signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64" to this mailing list > reports something that might be related. It seems there is a patch > available, but not committed yet. Though I'm not sure about the nature of > the problem exactly. Jeff? I want to make some points clear to avoid a confusion and spread of FUD. It seems we have at least three issues, all different: 1. Syscalls slowdown on amd64. To see this, you need to microbenchmark syscall enter/leave sequence. I doubt that it can be seen on any load except while (1) {getpid();} loops or such. The issue is valid _only_ for amd64. I developed the patch with the input from Jeff who confirmed that this slowdown is solved by the change. 2. There are enough independent reports of i/o slowdown to believe that some problem is real; but we have not seen numbers or detailed configurations or (most desirable) the revision after which the slowdown started. Note the i/o part. This report is for PPC (right ?) and for workload that is purely CPU-bounded. Please do not mix different issues. -------------- 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/20090703/83299aaa/attachment.pgp From stas at FreeBSD.org Fri Jul 3 09:03:21 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Jul 3 09:03:28 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: <20090702172853.GA94604@regency.nsu.ru> References: <20090701162108.GA33681@regency.nsu.ru> <20090702151507.c997fa89.stas@FreeBSD.org> <20090702172853.GA94604@regency.nsu.ru> Message-ID: <20090703130311.1b028de5.stas@FreeBSD.org> On Fri, 3 Jul 2009 00:28:53 +0700 Alexey Dokuchaev mentioned: > > $ dmesg | grep CPU: > CPU: Intel Pentium III (1125.00-MHz 686-class CPU) > Hi, Alexey! Do you have a core dump available? It might help to debug this issue. Thanks! -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090703/5c362a7f/attachment.pgp From pyunyh at gmail.com Fri Jul 3 09:09:22 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Jul 3 09:09:30 2009 Subject: Kernel panic with if_sf.ko In-Reply-To: <20090703130311.1b028de5.stas@FreeBSD.org> References: <20090701162108.GA33681@regency.nsu.ru> <20090702151507.c997fa89.stas@FreeBSD.org> <20090702172853.GA94604@regency.nsu.ru> <20090703130311.1b028de5.stas@FreeBSD.org> Message-ID: <20090703090733.GK13137@michelle.cdnetworks.co.kr> On Fri, Jul 03, 2009 at 01:03:11PM +0400, Stanislav Sedov wrote: > On Fri, 3 Jul 2009 00:28:53 +0700 > Alexey Dokuchaev mentioned: > > > > > $ dmesg | grep CPU: > > CPU: Intel Pentium III (1125.00-MHz 686-class CPU) > > > > Hi, Alexey! > > Do you have a core dump available? It might help to debug this issue. > I'm actively debugging the issue and waiting for reply of my patch. > Thanks! From mexas at bristol.ac.uk Fri Jul 3 10:12:55 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Jul 3 10:13:10 2009 Subject: gmirror per partition In-Reply-To: References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> Message-ID: <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> On Thu, Jul 02, 2009 at 03:48:41PM +0200, Wojciech Puchar wrote: > >>> > >>> # gmirror label -vb round-robin root /dev/da0p2 > >>> gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > >> isn't that partition accessed by other process or mounted? > > > > should it not be mounted? > yes it should not, no matter what architecture. ok, thank you So how can I gmirror root partition? I can't unmount it, I think. Perhaps I need to use a single-user mode? Following is a gpart/gmirror report - some success and problems. I did a fresh FBSD current install on ia64 on directly attached scsi, da0. # gpart show => 34 35566411 da0 GPT (17G) 34 819200 1 efi (400M) 819234 1048576 2 freebsd-ufs (512M) 1867810 4194304 3 freebsd-swap (2.0G) 6062114 2097152 4 freebsd-ufs (1.0G) 8159266 2097152 5 freebsd-ufs (1.0G) 10256418 25310027 6 freebsd-ufs (12G) # What I want is to mirror the whole of the boot disk to da1, which is identical to da0, but following Marcel's advice, will apply gmirror per partition. So starting with efi partition: First I create GPT scheme on da1 # gpart create -s gpt da1 da1 created # gpart show da1 => 34 35566411 da1 GPT (17G) 34 35566411 - free - (17G) # then I create EFI partition of the same size as on the boot disk, da0. # gpart add -b 34 -s 819200 -t efi da1 da1p1 added # gpart show da1 => 34 35566411 da1 GPT (17G) 34 819200 1 efi (400M) 819234 34747211 - free - (17G) # then I umount /efi so that I can create gmirror label on da0p1. # umount /efi # gmirror label -vb round-robin efi /dev/da0p1 Metadata value stored on /dev/da0p1. Done. # Checking gmirror # gmirror status Name Status Components mirror/efi COMPLETE da0p1 # and another check # gmirror list Geom name: efi State: COMPLETE Components: 1 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 3904698645 Providers: 1. Name: mirror/efi Mediasize: 419429888 (400M) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: da0p1 Mediasize: 419430400 (400M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 1288665799 # now insert a spare partition, da1p1, into the mirror # gmirror insert efi /dev/da1p1 status looks fine # gmirror status Name Status Components mirror/efi DEGRADED da0p1 da1p1 (44%) # gmirror status Name Status Components mirror/efi DEGRADED da0p1 da1p1 (87%) # gmirror status Name Status Components mirror/efi COMPLETE da0p1 da1p1 # and another check # gmirror list Geom name: efi State: COMPLETE Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 3904698645 Providers: 1. Name: mirror/efi Mediasize: 419429888 (400M) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: da0p1 Mediasize: 419430400 (400M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 1288665799 2. Name: da1p1 Mediasize: 419430400 (400M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 1724596009 # So far, so good. Now, I don't need to create the filesystem on the mirror, because EFI was copied from da0p1 to da1p1. So, I try to mount /dev/mirror/efi # mount -t msdosfs /dev/mirror/efi /mnt # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0p2 507630 35904 431116 8% / devfs 1 1 0 100% /dev /dev/da0p5 1012974 12 931926 0% /tmp /dev/da0p6 12252370 252608 11019574 2% /usr /dev/da0p4 1012974 242 931696 0% /var /dev/mirror/efi 409504 163264 246240 40% /mnt # again seems ok so I proceed to modify /etc/fstab and change da0p1 into mirror/efi # cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/da0p3 none swap sw 0 0 /dev/da0p2 / ufs rw 1 1 /dev/mirror/efi /efi msdosfs rw 0 0 ^^^^^^^^^^^^^^^ /dev/da0p5 /tmp ufs rw 2 2 /dev/da0p6 /usr ufs rw 2 2 /dev/da0p4 /var ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 # now I can try to just mount /efi # umount /mnt # mount /efi # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0p2 507630 35904 431116 8% / devfs 1 1 0 100% /dev /dev/da0p5 1012974 12 931926 0% /tmp /dev/da0p6 12252370 252608 11019574 2% /usr /dev/da0p4 1012974 242 931696 0% /var /dev/mirror/efi 409504 163264 246240 40% /efi # good, working! now to mirror root partition. My problem is that root is mounted and cannot (?) be unmounted, unlike /efi, on the live system. # gpart add -b 819234 -s 1048576 -t freebsd-ufs da1 da1p2 added # # gmirror label -vb round-robin root /dev/da0p2 gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. # If I create gmirror on da1, the spare disk: # gmirror label -vb round-robin root /dev/da1p2 Metadata value stored on /dev/da0p1. Done. # so that # gmirror status Name Status Components mirror/efi COMPLETE da0p1 da1p1 mirror/root COMPLETE da1p2 # then I still cannot insert da0p2 # gmirror insert root da0p2 gmirror: Cannot access provider da0p2. # So how can I gmirror root partion on a live system? Also, if gmirror overwrites the last sector in the partition, then gmirror per partition cannot be used for /usr, because secondary GPT is stored in the last sector of /usr. Isn't it? many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Fri Jul 3 10:52:40 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Jul 3 10:52:48 2009 Subject: nice work on ntp.conf! Message-ID: <20090703105232.GA14372@mech-cluster238.men.bris.ac.uk> ntp.conf update from 2009/06/07 is very welcome, works great straight out of the box, much better than before! many thanks to whoever worked on this. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From hansot at iae.nl Fri Jul 3 11:30:31 2009 From: hansot at iae.nl (Hans Ottevanger) Date: Fri Jul 3 11:30:39 2009 Subject: panic on acpi_cpu_c1() In-Reply-To: <4A4D3665.3060502@FreeBSD.org> References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> <4A4D3665.3060502@FreeBSD.org> Message-ID: <4A4DEBD4.50609@iae.nl> John Baldwin wrote: > Maxim Ignatenko wrote: >>> Fatal trap 30: reserved (unknown) fault while in kernel mode >>> cpuid = 3; apic id = 03 >>> instruction pointer = 0x20:0xffffffff804bce56 >>> stack pointer = 0x20:0xffffff8000039b60 >>> frame pointer = 0x20:0xffffff8000039b70 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, IOPL = 0 >>> current process = 11 (idle: cpu3) >>> [thread pid 11 tid 100003 ] >>> Stopped at acpi_cpu_c1+0x6: leave >>> db> bt >>> Tracing pid 11 tid 100003 td 0xffffff8001863720 >>> acpi_cpu_c1() at acpi_cpu_c1+0x6 >>> acpi_cpu_idle() at acpi_cpu_idle+0x20c >>> sched_idletd() at sched_idletd+0x123 >>> fork_exit() at fork_exit+0x117 >>> fork_trampoline() at fork_trampoline+0xe >> >> As for me, r194984 runs normally, but when I tried to boot with >> r194985 at second try it paniced with backtrace very similar to shown >> in first message, and at first try even earlier: in sched_ideltd and >> again on instruction that uses %ebp when ebp = 0. >> First time I stepped on this panic after updating to r195130: >> >> Trying to mount root from ufs:/dev/ufs/root >> >> >> Fatal trap 30; reserved (unknown) fault while in kernel mode >> cpuid = 1; apic id = 01 >> instruction ponter = 0x20:0xc09252c5 >> stack pointer = 0x28:0xc4ecec94 >> frame pointer = 0x28:0xc4ecec94 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, IOPL = 0 >> current process = 11 (idle: cpu1) >> [thread pid 11 tid 100003] >> Stopped at 0xc09252c5 = acpi_cpu_c1+0x5: popl %ebp >> db> bt >> Tracing pid 11 tid 100003 td 0xc5176af0 >> acpi_cpu_c1(1,c4ececa8,1,0,c4ececc0,...) at 0xc09252c5 = acpi_cpu_c1+0x5 >> acpi_cpu_idle(c4ececd4,c093c0ab,0,c4ececf4,c066fdec,...) at 0xc04acf37 >> = acpi_cpu_idle+0x107 >> cpu_idle_acpi(0,c4ececf4,c066fdec,0,0,...) at 0xc093d5bb = >> cpu_idle_acpi+0x1b >> cpu_idle(0,0,c5176af0,c4ececf4,202,...) at 0xc093c0ab = cpu_idle+0x1b >> sched_idletd(0,c4ececd38,a4108400,2c0a0e,7022d00,...) at 0xc066fdec = >> sched_idletd+0x1c >> fork_exit(c066fdd0,0,c4eced38) at 0xc0623aa1 = fork_exit+0x91 >> fork_trampoline() at 0xc0930c80 = fork_tramoline+0x8 >> --- trap 0, eip = 0, esp = 0xc4ececd70, ebp = 0 --- >> >> >> P.S.: i386, dual-core, drm and radeon compiled as modules >> When I'm trying to boot w/o ACPI support all seems work fine, but >> system hangs just before starting kdm > > Please try http://www.FreeBSD.org/~jhb/patches/msi_assign.patch > I have applied your patch to r195303 (which still panics as before when unpatched). The panic I previously got with my amd64 based system does not occur anymore, so the problem seems to be solved. I do not have an i386 system with MSI available to test the patch. Kind regards, Hans From dalroi at solfertje.student.utwente.nl Fri Jul 3 11:37:12 2009 From: dalroi at solfertje.student.utwente.nl (Alban Hertroys) Date: Fri Jul 3 11:37:18 2009 Subject: gmirror per partition In-Reply-To: <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> Message-ID: <1944CCC8-B2D5-4C06-B21C-FAA5A37D6EE1@solfertje.student.utwente.nl> On Jul 3, 2009, at 12:12 PM, Anton Shterenlikht wrote: > now to mirror root partition. > > My problem is that root is mounted and cannot (?) be unmounted, > unlike /efi, > on the live system. > > # gpart add -b 819234 -s 1048576 -t freebsd-ufs da1 > da1p2 added > # > > # gmirror label -vb round-robin root /dev/da0p2 > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > # > > If I create gmirror on da1, the spare disk: > > # gmirror label -vb round-robin root /dev/da1p2 > Metadata value stored on /dev/da0p1. > Done. > # > > so that > > # gmirror status > Name Status Components > mirror/efi COMPLETE da0p1 > da1p1 > mirror/root COMPLETE da1p2 > > # > > > then I still cannot insert da0p2 > > > # gmirror insert root da0p2 > gmirror: Cannot access provider da0p2. > # > > So how can I gmirror root partion on a live system? You're almost there... I did this a while ago, can't remember when, but I just upgraded the system that had this from FreeBSD 6.3 of sometime in 2006 to 7.2. What I believe I did from this point on was: Copy everything from the root partition to mirror/root. Modify /etc/fstab to mount root on mirror/root. Reboot. Now the original root partition isn't mounted anymore, so we can do operate on it's geom stuff. gmirror insert root da0p2 That should be it. If that doesn't work you can always boot off a live file-system CD/DVD and perform these actions from there. You won't have man pages in that case though, or at least I couldn't find a way to read them off the DVD last I tried. One thing I'd like to warn about at this point: If you ever upgrade to a kernel with a newer geom metadata version and that new kernel crashes, you're left with a system where the new kernel can't boot at all while the old kernel can't mount the root mirror as it's now of a version it can't handle. You can however mount a single geom provider of that root file system (/dev/da1p2 for example) to try to fix things. That file-system WILL be dirty, but DON'T run fsck on it or you will destroy it's contents. That's what happened to my upgrade above... Thankfully it was only my root partition with hardly any data on it and I did make level 0 dumps before the upgrade, but I needed to restore that FS from a fixit shell without man pages. Augh! > many thanks > > -- > Anton Shterenlikht > Room 2.6, Queen's Building > Mech Eng Dept > Bristol University > University Walk, Bristol BS8 1TR, UK > Tel: +44 (0)117 928 8233 > Fax: +44 (0)117 929 4423 > _______________________________________________ > 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 > " > > > > Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:909,4a4de909759157325793587! From lwindschuh at googlemail.com Fri Jul 3 13:07:21 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Fri Jul 3 13:07:29 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A4CFCDD.4020202@FreeBSD.org> References: <4A4CFCDD.4020202@FreeBSD.org> Message-ID: <90a5caac0907030607s3db6a325jbf41f65f3d5fe428@mail.gmail.com> 2009/7/2 Alexander Motin : > [cdrecord -scanbus broken] > > It is the same problem I have fixed in camcontrol. You can do the same with > changing in scsi-bsd.c in cdrtools > #define>CAM_MAXDEVS ? ? 128 > to > #define>CAM_MAXDEVS ? ? 50. > I hope it is temporal solution. I am thinking about to remove or at least > rise that limitation. It woks, indeed. And you AHCI driver also works without problems until now. Thanks Lucius From mike at sentex.net Fri Jul 3 13:28:41 2009 From: mike at sentex.net (Mike Tancsa) Date: Fri Jul 3 13:28:48 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <200907022117.n62LHrvZ010791@lava.sentex.ca> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> Message-ID: <200907031326.n63DQCGM016627@lava.sentex.ca> At 05:20 PM 7/2/2009, Mike Tancsa wrote: >But, going back to the original i386 image, with the boot blocks >reinstalled and using your latest patch, it seems to work! (however, >the same 300sec delay due to the cdrom ? ) At first, I thought something was a miss speed wise, but it looks like this hardware is either having issues, or something is wrong in general as its the same no matter which driver is used. Usually the speeds are much quicker than whats below on block writes Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 1 4000 39798 20.8 39725 4.3 17776 3.4 40269 27.1 42085 4.2 255.8 0.6 2 4000 38827 20.3 40116 4.4 18068 3.4 40227 27.3 42266 4.3 244.8 0.5 3 4000 39748 20.8 40166 4.4 17952 3.3 40192 27.3 42259 4.3 243.4 0.5 4 4000 39855 20.8 40066 4.4 18017 3.3 40206 27.1 42401 4.2 264.2 0.6 1=AHCI in bios, AHCI.ko loaded 2=AHCI in bios, plain old ata driver used post patch 3=IDE in bios, plain old ata driver used post patch 4=IDE in bios, plain old ata driver from the cvs Note, with 2 dmesg shows acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 the boot process then hangs for about 5 seconds, and then proceeds with 3, the boot process hangs a total of about 2 min. ---Mike From mav at FreeBSD.org Fri Jul 3 13:53:27 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Jul 3 13:53:34 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <200907031326.n63DQCGM016627@lava.sentex.ca> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> Message-ID: <4A4E0D51.3080904@FreeBSD.org> Mike Tancsa wrote: > At 05:20 PM 7/2/2009, Mike Tancsa wrote: >> But, going back to the original i386 image, with the boot blocks >> reinstalled and using your latest patch, it seems to work! (however, >> the same 300sec delay due to the cdrom ? ) > > At first, I thought something was a miss speed wise, but it looks like > this hardware is either having issues, or something is wrong in general > as its the same no matter which driver is used. Usually the speeds are > much quicker than whats below on block writes > > > Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... > -------Sequential Output-------- ---Sequential Input-- > --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- > --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > /sec %CPU > 1 4000 39798 20.8 39725 4.3 17776 3.4 40269 27.1 42085 4.2 > 255.8 0.6 > 2 4000 38827 20.3 40116 4.4 18068 3.4 40227 27.3 42266 4.3 > 244.8 0.5 > 3 4000 39748 20.8 40166 4.4 17952 3.3 40192 27.3 42259 4.3 > 243.4 0.5 > 4 4000 39855 20.8 40066 4.4 18017 3.3 40206 27.1 42401 4.2 > 264.2 0.6 > > 1=AHCI in bios, AHCI.ko loaded > 2=AHCI in bios, plain old ata driver used post patch > 3=IDE in bios, plain old ata driver used post patch > 4=IDE in bios, plain old ata driver from the cvs This test looks inadequate. there is almost no modern SATA HDDs having only 40MB/s of linear read/write speed. Usual values now are 60-100MB/s and they should be reached with almost any working driver. Can you try simple `dd if=/dev/ada0 of=/dev/null bs=1m count=1000`? To obtain any measurable benefit from NCQ usage you should have many random requests to the drive running simultaneously. Not sure how this specific test works. Also NCQ depends on effective disk firmware to realize that benefit. > Note, with 2 dmesg shows > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > > the boot process then hangs for about 5 seconds, and then proceeds > > with 3, the boot process hangs a total of about 2 min. If you have issues with old driver also, then it is probably some drive specifics, but not a bug of the new implementation. There was no changes to the old ATA. -- Alexander Motin From mike at sentex.net Fri Jul 3 14:15:31 2009 From: mike at sentex.net (Mike Tancsa) Date: Fri Jul 3 14:15:43 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A4E0D51.3080904@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> Message-ID: <200907031413.n63ED2jl016885@lava.sentex.ca> At 09:53 AM 7/3/2009, Alexander Motin wrote: >This test looks inadequate. there is almost no modern SATA HDDs having >only 40MB/s of linear read/write speed. Usual values now are 60-100MB/s >and they should be reached with almost any working driver. Can you try >simple `dd if=/dev/ada0 of=/dev/null bs=1m count=1000`? Something about this particular disk perhaps 0[i7]# dd if=/dev/ad4 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 14.933896 secs (70214497 bytes/sec) Using a different seagate disk, 0[i7]# dd if=/dev/ad6 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 7.542932 secs (139014377 bytes/sec) 0[i7]# I will re-run the tests with the newer seagate. Perhaps a firmware update to the 'slow' one might help Protocol SATA revision 2.x device model ST380811AS serial number 6PS03G9Z firmware revision 3.AAE cylinders 16383 heads 16 sectors/track 63 lba supported 156301488 sectors lba48 supported 156301488 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 65278/0xFEFE automatic acoustic management no no 0/0x00 208/0xD0 >If you have issues with old driver also, then it is probably some drive >specifics, but not a bug of the new implementation. There was no changes >to the old ATA. Yes, it certainly seems so. This DVD is off the PATA bus 0[i7]# atacontrol list ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: no device present Slave: acd0 ATA/ATAPI revision 7 ATA channel 3: Master: ad6 SATA revision 2.x Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present 0[i7]# >-- >Alexander Motin >_______________________________________________ >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 mav at FreeBSD.org Fri Jul 3 14:26:51 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Jul 3 14:26:57 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <200907031413.n63ED2jl016885@lava.sentex.ca> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> Message-ID: <4A4E1525.2040809@FreeBSD.org> Mike Tancsa wrote: >> If you have issues with old driver also, then it is probably some drive >> specifics, but not a bug of the new implementation. There was no changes >> to the old ATA. > > Yes, it certainly seems so. This DVD is off the PATA bus > > 0[i7]# atacontrol list > ATA channel 2: > Master: no device present > Slave: acd0 ATA/ATAPI revision 7 Wait! Stop! I have got lost in what we are testing. In some of your your previous messages today I have seen: (probe2:ahcich2:0:0:0): SIGNATURE: eb14 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ahcich2: Timeout on slot 4 run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config ahcich2: Timeout on slot 5 First line means that it is ATAPI drive on AHCI SATA controller and latest lines mean that it is not working properly. Now you are talking that this is PATA drive. Could you please somehow identify each of your system to let me identify problems and solutions separately. -- Alexander Motin From mike at sentex.net Fri Jul 3 14:32:53 2009 From: mike at sentex.net (Mike Tancsa) Date: Fri Jul 3 14:33:07 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A4E1525.2040809@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> Message-ID: <200907031430.n63EUMH1016965@lava.sentex.ca> At 10:26 AM 7/3/2009, Alexander Motin wrote: >Wait! Stop! I have got lost in what we are testing. In some of your your >previous messages today I have seen: Sorry, I just opened up the case to confirm, and it is indeed a SATA DVD drive. ---Mike From mav at FreeBSD.org Fri Jul 3 14:49:21 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Jul 3 14:49:28 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <200907031430.n63EUMH1016965@lava.sentex.ca> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> Message-ID: <4A4E1A6C.3090605@FreeBSD.org> Mike Tancsa wrote: > At 10:26 AM 7/3/2009, Alexander Motin wrote: > >> Wait! Stop! I have got lost in what we are testing. In some of your your >> previous messages today I have seen: > > Sorry, I just opened up the case to confirm, and it is indeed a SATA DVD > drive. Messages like "it's just not working" will not give anything except upsetting me. Usually I need more information. So if you are really what to track and fix some problem, please, identify it somehow, to be able to send more follow-ups later and compare to different user's results. Open cases one by one in separate emails. -- Alexander Motin From patfbsd at davenulle.org Fri Jul 3 15:26:05 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Fri Jul 3 15:26:13 2009 Subject: ulpt problem (USB_ERR_IOERROR) Message-ID: <20090703172600.1971111e@baby-jane.lamaiziere.net> Hello, [Yesterday CURRENT/i386] I've got some troubles with unlpt, most of the time I can't print and I must stop cupsd, kill -9 the process usb, and unplug the USB printer. Then it works again for some time (but mostly one time). The printer is a Brother HL-1430 (working fine under FreeBSD since FreeBSD 4.X) ulpt0: on usbus0 ulpt_attach:562: setting alternate config number: 0 ulpt0: using bi-directional mode With hw.usb.ulpt.debug=1, I've got a lot of: ulpt_write_callback:204: state=0x0 actlen=0 ulpt_status_callback:328: error=USB_ERR_IOERROR last message repeated 31 times last message repeated 78 times ... When it works: ulpt_write_callback:220: state=0x0 actlen=0 ulpt_write_callback:220: state=0x1 actlen=2889 ulpt_write_callback:220: state=0x1 actlen=3023 ... Thanks in advance, regards. From hselasky at c2i.net Fri Jul 3 15:57:23 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Jul 3 15:57:32 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <20090703172600.1971111e@baby-jane.lamaiziere.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> Message-ID: <200907031756.55253.hselasky@c2i.net> On Friday 03 July 2009 17:26:00 Patrick Lamaiziere wrote: > Hello, > > [Yesterday CURRENT/i386] > > I've got some troubles with unlpt, most of the time I can't print and I > must stop cupsd, kill -9 the process usb, and unplug the USB printer. > Then it works again for some time (but mostly one time). > > The printer is a Brother HL-1430 (working fine under FreeBSD since > FreeBSD 4.X) > > ulpt0: addr 2> on usbus0 > ulpt_attach:562: setting alternate config number: 0 > ulpt0: using bi-directional mode > > With hw.usb.ulpt.debug=1, I've got a lot of: > > ulpt_write_callback:204: state=0x0 actlen=0 > ulpt_status_callback:328: error=USB_ERR_IOERROR > last message repeated 31 times > last message repeated 78 times > ... > > When it works: > ulpt_write_callback:220: state=0x0 actlen=0 > ulpt_write_callback:220: state=0x1 actlen=2889 > ulpt_write_callback:220: state=0x1 actlen=3023 > ... Hi, Have you tried: usbconfig -u XXX -a YYY reset Does it help? To me it looks like a problem about your printer USB firmware. Does it respond to: usbconfig -u XXX -a YYY dump_curr_config_desc After the first print job? XXX and YYY are the numbers after the "ugen" in dmesg. --HPS From hselasky at c2i.net Fri Jul 3 15:59:00 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Jul 3 15:59:08 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <20090703172600.1971111e@baby-jane.lamaiziere.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> Message-ID: <200907031758.35319.hselasky@c2i.net> On Friday 03 July 2009 17:26:00 Patrick Lamaiziere wrote: > Hello, > > [Yesterday CURRENT/i386] > > I've got some troubles with unlpt, most of the time I can't print and I > must stop cupsd, kill -9 the process usb, and unplug the USB printer. > Then it works again for some time (but mostly one time). > > The printer is a Brother HL-1430 (working fine under FreeBSD since > FreeBSD 4.X) > Did you try both: /dev/unlpt0 and /dev/ulpt0 ? --HPS From patfbsd at davenulle.org Fri Jul 3 16:52:37 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Fri Jul 3 16:52:45 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <200907031756.55253.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031756.55253.hselasky@c2i.net> Message-ID: <20090703185233.4f7e4a65@baby-jane.lamaiziere.net> Le Fri, 3 Jul 2009 17:56:54 +0200, Hans Petter Selasky a ?crit : > Have you tried: > > usbconfig -u XXX -a YYY reset > > Does it help? No, it returns # usbconfig -u 0 -a 2 reset usbconfig: could not reset device: Input/output error Then ulpt detaches ulpt0: at uhub0, port 1, addr 2 (disconnected) ulpt_detach:653: sc=0xc317f000 > To me it looks like a problem about your printer USB firmware. Does > it respond to: > > usbconfig -u XXX -a YYY dump_curr_config_desc > > After the first print job? Yes, after the first job: # usbconfig -u 0 -a 2 dump_curr_config_desc ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0020 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0000 bmAttributes = 0x00c0 bMaxPower = 0x0001 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0002 bInterfaceClass = 0x0007 bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x0002 iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 It looks like there are some problems even with the first job (I missed this point before). ulpt0: using bi-directional ulpt_write_callback:220: state=0x0 actlen=0 ulpt_write_callback:220: state=0x1 actlen=2889 ulpt_write_callback:220: state=0x1 actlen=3023 ... ulpt_status_callback:352: error=USB_ERR_STALLED ulpt_write_callback:220: state=0x1 actlen=16384 ulpt_write_callback:220: state=0x1 actlen=16384 ... ulpt_status_callback:352: error=USB_ERR_IOERROR ulpt_write_callback:220: state=0x1 actlen=16384 ulpt_write_callback:220: state=0x1 actlen=16384 ... ulpt_status_callback:352: error=USB_ERR_IOERROR ulpt_write_callback:220: state=0x1 actlen=16384 ulpt_write_callback:220: state=0x1 actlen=15970 ulpt_status_callback:352: error=USB_ERR_IOERROR ulpt_status_callback:352: error=USB_ERR_IOERROR ulpt_status_callback:352: error=USB_ERR_IOERROR ... (ad eternam) If it can help, I can compare with FreeBSD 7.2. Thank you. From hselasky at c2i.net Fri Jul 3 17:29:47 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Jul 3 17:29:53 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <20090703185233.4f7e4a65@baby-jane.lamaiziere.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031756.55253.hselasky@c2i.net> <20090703185233.4f7e4a65@baby-jane.lamaiziere.net> Message-ID: <200907031929.17327.hselasky@c2i.net> On Friday 03 July 2009 18:52:33 Patrick Lamaiziere wrote: > Le Fri, 3 Jul 2009 17:56:54 +0200, > > Hans Petter Selasky a ?crit : > > Have you tried: > > > > usbconfig -u XXX -a YYY reset > > > > Does it help? > > No, it returns > # usbconfig -u 0 -a 2 reset > usbconfig: could not reset device: Input/output error > > Then ulpt detaches > ulpt0: at uhub0, port 1, addr 2 (disconnected) > ulpt_detach:653: sc=0xc317f000 > > > To me it looks like a problem about your printer USB firmware. Does > > it respond to: > > > > usbconfig -u XXX -a YYY dump_curr_config_desc > > > > After the first print job? > > Yes, after the first job: > > # usbconfig -u 0 -a 2 dump_curr_config_desc ugen0.2: vendor 0x04f9> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON > > > Configuration index 0 > > bLength = 0x0009 > bDescriptorType = 0x0002 > wTotalLength = 0x0020 > bNumInterfaces = 0x0001 > bConfigurationValue = 0x0001 > iConfiguration = 0x0000 > bmAttributes = 0x00c0 > bMaxPower = 0x0001 > > Interface 0 > bLength = 0x0009 > bDescriptorType = 0x0004 > bInterfaceNumber = 0x0000 > bAlternateSetting = 0x0000 > bNumEndpoints = 0x0002 > bInterfaceClass = 0x0007 > bInterfaceSubClass = 0x0001 > bInterfaceProtocol = 0x0002 > iInterface = 0x0000 > > Endpoint 0 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0001 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0040 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > Endpoint 1 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0082 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0040 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > > It looks like there are some problems even with the first job (I missed > this point before). > > ulpt0: using bi-directional > ulpt_write_callback:220: state=0x0 actlen=0 > ulpt_write_callback:220: state=0x1 actlen=2889 > ulpt_write_callback:220: state=0x1 actlen=3023 > ... > ulpt_status_callback:352: error=USB_ERR_STALLED > ulpt_write_callback:220: state=0x1 actlen=16384 > ulpt_write_callback:220: state=0x1 actlen=16384 At this point it looks like the firmware crashes, when the error code changes from STALLED to IOERROR. Are you sure the .ps/.pcl file is not corrupt? > ... > ulpt_status_callback:352: error=USB_ERR_IOERROR > ulpt_write_callback:220: state=0x1 actlen=16384 > ulpt_write_callback:220: state=0x1 actlen=16384 > ... > ulpt_status_callback:352: error=USB_ERR_IOERROR > ulpt_write_callback:220: state=0x1 actlen=16384 > ulpt_write_callback:220: state=0x1 actlen=15970 > ulpt_status_callback:352: error=USB_ERR_IOERROR > ulpt_status_callback:352: error=USB_ERR_IOERROR > ulpt_status_callback:352: error=USB_ERR_IOERROR > ... (ad eternam) > > If it can help, I can compare with FreeBSD 7.2. Yes, that might give some more clues. --HPS From patfbsd at davenulle.org Fri Jul 3 17:34:04 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Fri Jul 3 17:34:12 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <200907031758.35319.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031758.35319.hselasky@c2i.net> Message-ID: <20090703193400.60fef21f@baby-jane.lamaiziere.net> Le Fri, 3 Jul 2009 17:58:34 +0200, Hans Petter Selasky a ?crit : > > The printer is a Brother HL-1430 (working fine under FreeBSD since > > FreeBSD 4.X) > > > > Did you try both: > > /dev/unlpt0 and /dev/ulpt0 I tried : with ulpt0 the printer does not print anything (With previous FreeBSD I used unlpt0): the reset disconnects the printer. ulpt0: on usbus0 ulpt_attach:562: setting alternate config number: 0 ulpt0: using bi-directional mode ugen0.2: at usbus0 (disconnected) ulpt0: at uhub0, port 1, addr 2 (disconnected) ulpt_detach:653: sc=0xc3176480 ugen0.2: at usbus0 ulpt0: on usbus0 ulpt_attach:562: setting alternate config number: 0 ulpt0: using bi-directional mode From sam at freebsd.org Fri Jul 3 18:25:29 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri Jul 3 18:25:36 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <20090703193400.60fef21f@baby-jane.lamaiziere.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031758.35319.hselasky@c2i.net> <20090703193400.60fef21f@baby-jane.lamaiziere.net> Message-ID: <4A4E4D12.9010501@freebsd.org> Patrick Lamaiziere wrote: > Le Fri, 3 Jul 2009 17:58:34 +0200, > Hans Petter Selasky a ?crit : > > >>> The printer is a Brother HL-1430 (working fine under FreeBSD since >>> FreeBSD 4.X) >>> >>> >> Did you try both: >> >> /dev/unlpt0 and /dev/ulpt0 >> > > I tried : with ulpt0 the printer does not print anything (With > previous FreeBSD I used unlpt0): the reset disconnects the printer. > > ulpt0: > on usbus0 > ulpt_attach:562: setting alternate config number: 0 > ulpt0: using bi-directional mode > ugen0.2: at usbus0 (disconnected) > ulpt0: at uhub0, port 1, addr 2 (disconnected) > ulpt_detach:653: sc=0xc3176480 > ugen0.2: at usbus0 > ulpt0: > on usbus0 ulpt_attach:562: setting alternate config number: 0 > ulpt0: using bi-directional mode > This looks a bit like an issue I'm about to start chasing where FS devices fed through a HS hub disconnect "spontaneously" under load. It doesn't look like it but to be sure there are no hubs between the host and the printer? Sam From mike at sentex.net Fri Jul 3 19:00:43 2009 From: mike at sentex.net (Mike Tancsa) Date: Fri Jul 3 19:00:50 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <4A4E1A6C.3090605@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> Message-ID: <200907031858.n63IwDIt018455@lava.sentex.ca> At 10:49 AM 7/3/2009, Alexander Motin wrote: >Mike Tancsa wrote: > > At 10:26 AM 7/3/2009, Alexander Motin wrote: > > > >> Wait! Stop! I have got lost in what we are testing. In some of your your > >> previous messages today I have seen: > > > > Sorry, I just opened up the case to confirm, and it is indeed a SATA DVD > > drive. > >Messages like "it's just not working" will not give anything except >upsetting me. Usually I need more information. So if you are really what >to track and fix some problem, please, identify it somehow, to be able >to send more follow-ups later and compare to different user's results. >Open cases one by one in separate emails. Sorry again for the confusion. I am trying a *different* motherboard (INTEL DX58SO) and drive now with your 0629 patch as well as the diff below. --- ahci.c.prev 2009-06-29 12:48:45.000000000 +0300 +++ ahci.c 2009-06-29 17:25:29.000000000 +0300 @@ -986,7 +986,7 @@ ahci_begin_transaction(device_t dev, uni if (ch->slot[tag].state == AHCI_SLOT_EMPTY) break; } while (tag != ch->lastslot); - if (tag == ch->lastslot) + if (ch->slot[tag].state != AHCI_SLOT_EMPTY) device_printf(ch->dev, "ALL SLOTS BUSY!\n"); ch->lastslot = tag; /* Occupy chosen slot. */ Without the diff, I was getting a steady stream of ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! With the above diff, all seems to work well. Full verbose dmesg and pciconf -lvc at http://www.tancsa.com/ahci/DX58SO.txt Read/Write speed looks good with a more modern disk as well -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 4000 103884 51.4 109344 9.7 42048 6.0 91201 59.0 116723 8.5 1123.4 2.0 0(ich10)# dd if=/dev/ada0 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 7.562206 secs (138660068 bytes/sec) 0(ich10)# The eSata port does not work, but it never did under the old driver either. I think it has a separate controller ? At the BIOS boot up time, it shows some Marvell controller talking to the eSata attached drive, and pciconf does show a separate ATA controller ahci0@pci0:0:31:2: class=0x010601 card=0x4f538086 chip=0x3a228086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '6 port SATA AHCI Controller' class = mass storage subclass = SATA cap 05[80] = MSI supports 16 messages enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair none7@pci0:0:31:3: class=0x0c0500 card=0x4f538086 chip=0x3a308086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'SMB controller (50011458)' class = serial bus subclass = SMBus atapci0@pci0:6:0:0: class=0x01018f card=0x4f538086 chip=0x612111ab rev=0xb2 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '6121 SATA2 Controller' class = mass storage subclass = ATA cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 cap 05[50] = MSI supports 1 message cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link x1(x1) From mav at FreeBSD.org Fri Jul 3 19:31:27 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Jul 3 19:31:33 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <200907031858.n63IwDIt018455@lava.sentex.ca> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> Message-ID: <4A4E5C82.9070209@FreeBSD.org> Mike Tancsa wrote: > I am trying a *different* motherboard > (INTEL DX58SO) and drive now with your 0629 patch as well as the diff > below. > With the above diff, all seems to work well. > > Full verbose dmesg and pciconf -lvc at > > http://www.tancsa.com/ahci/DX58SO.txt Fine. > Read/Write speed looks good with a more modern disk as well > > -------Sequential Output-------- ---Sequential Input-- > --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- > --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > /sec %CPU > 4000 103884 51.4 109344 9.7 42048 6.0 91201 59.0 116723 8.5 > 1123.4 2.0 > 0(ich10)# dd if=/dev/ada0 of=/dev/null bs=1m count=1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 7.562206 secs (138660068 bytes/sec) > 0(ich10)# Fine. But first test still looks like bound by something. Or this test requires some tuning, or it is used over file system, your system may require tuning. It would be more interesting to investigate benefits on NCQ suitable workload, as that are new for us. Something like unpacking a lot of small files to normal or async-mounted or gjournalled FS, or some multi-threaded read, or something else. Would be nice to understand on which types of workload NCQ could give us visible effects. You can track real requests parallelism by looking on dev_active field of `camcontrol tags ada0 -v`. > The eSata port does not work, but it never did under the old driver > either. I think it has a separate controller ? At the BIOS boot up > time, it shows some Marvell controller talking to the eSata attached > drive, and pciconf does show a separate ATA controller > > > ahci0@pci0:0:31:2: class=0x010601 card=0x4f538086 chip=0x3a228086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = '6 port SATA AHCI Controller' > class = mass storage > subclass = SATA > cap 05[80] = MSI supports 16 messages enabled with 1 message > cap 01[70] = powerspec 3 supports D0 D3 current D0 > cap 12[a8] = SATA Index-Data Pair As I have noted in man page, "mass storage"/"SATA" is right device. > atapci0@pci0:6:0:0: class=0x01018f card=0x4f538086 chip=0x612111ab > rev=0xb2 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = '6121 SATA2 Controller' > class = mass storage > subclass = ATA > cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 > cap 05[50] = MSI supports 1 message > cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link > x1(x1) But this device, implementing both PATA and SATA ports, report itself as PATA controller. It's SATA part may be AHCI compatible, but driver unable to attach it due to incorrect device identification. Alike happens to my JMicron controllers, but in that case system BIOS is able to switch it into the right mode with separate PATA and AHCI SATA controllers devices. -- Alexander Motin From rmacklem at uoguelph.ca Fri Jul 3 19:39:42 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Fri Jul 3 19:39:49 2009 Subject: Install from NFS onto NFS fails on amd64 In-Reply-To: <20090702212505.GA39889@stack.nl> References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> <20090702212505.GA39889@stack.nl> Message-ID: On Thu, 2 Jul 2009, Jilles Tjoelker wrote: > > This could be because of NFS "sillyrename". To avoid some ESTALE errors, > the NFS client (for NFSv2 and NFSv3 at least) renames if you delete a > file that is currently in use (in this case, the rm binary). Because the > renamed file (name typically starts with .nfs) is in the same directory, > this causes problems when removing directories. Once the file is no > longer in use, it is finally deleted. > Yes, if some file that was in that directory is still open (or mmap'd and the process hasn't yet exit()'d), it will exist as a file named ".nfsXXX" until the v_usecount goes to 0 and then it's removed, which would explain it. > Maybe NFSv4 has a cleaner way to keep a file with 0 links as long as it > is open. > Afraid not. NFSv4 has an Open, but it is an open share lock and not a POSIX style open, so NFSv4 clients still do the silly rename. (ie. The NFSv4 Remove Op is defined as removing the file and not just unlinking it and the NFSv4 server isn't required to retain the file after removal if it is Open'd by a client.) rick From nork at FreeBSD.org Fri Jul 3 21:03:59 2009 From: nork at FreeBSD.org (Norikatsu Shigemura) Date: Fri Jul 3 21:04:06 2009 Subject: panic on acpi_cpu_c1() In-Reply-To: <4A4D3665.3060502@FreeBSD.org> References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> <4A4D3665.3060502@FreeBSD.org> Message-ID: <20090704060344.c1cd57f2.nork@FreeBSD.org> Hi John. On Thu, 02 Jul 2009 18:36:21 -0400 John Baldwin wrote: > Please try http://www.FreeBSD.org/~jhb/patches/msi_assign.patch I confirmed that this issue was fixed by your patch on latest current kernel!! Thank you! -- Norikatsu Shigemura From aragon at phat.za.net Fri Jul 3 21:06:17 2009 From: aragon at phat.za.net (Aragon Gouveia) Date: Fri Jul 3 21:06:24 2009 Subject: nice work on ntp.conf! In-Reply-To: <20090703105232.GA14372@mech-cluster238.men.bris.ac.uk> References: <20090703105232.GA14372@mech-cluster238.men.bris.ac.uk> Message-ID: <4A4E6EB4.9000000@phat.za.net> Anton Shterenlikht wrote: > ntp.conf update from 2009/06/07 is very welcome, > works great straight out of the box, much better than before! > > many thanks to whoever worked on this. Agreed, thanks! Just wish there were a simple solution to the restriction directives... Regards, Aragon From lstewart at freebsd.org Fri Jul 3 21:28:50 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Fri Jul 3 21:28:57 2009 Subject: r194546 amd64: kernel panic in tcp_sack.c In-Reply-To: <4A4BE438.5060203@haruhiism.net> References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> Message-ID: <4A4E77EA.7030803@freebsd.org> Kamigishi Rei wrote: > Lawrence Stewart wrote: >> Ok. I'm working on a patch to address a different TCP/SACK issue, but >> it may in fact be partially relevant to the cause of your panic... >> can't promise when I'll be able to take a close look at this but I'm >> aware of it now so that's a start. If you run into it again or find >> the trigger for the panic, please let me know. > Reproduced. I don't know what was the trigger this time. The system runs > lighttpd, fastcgi python and php, mysql and postgresql. > Also, in this core somehow everything looks quite similar (looks like > another page fault but with panic() called prior to getting into fatal > trap 12) to my two earlier dumps: > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008777.html > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008781.html > so maybe it's not really a problem with tcp_sack.c or netisr.c. > With some poking around and a key insight provided by Robert Watson, I believe we've got this sorted. The SACK code puts a global cap on the amount of memory that can be used for SACK accounting. The variable V_tcp_sack_globalholes tracks how many SACK holes are currently allocated across all active TCP connections. It gets incremented in tcp_sackhole_alloc() and decremented in tcp_sackhole_free() in netinet/tcp_sack.c. It turns out that there is currently no lock synchronising access to the variable, and the incrementing/decrementing is not being done atomically. In Kamigishi's case, his server had a traffic profile consisting of a large number of clients simultaneously connecting over cruddy links which was giving the SACK accounting a real workout. The inevitable race would strike one or more times, leaving the count of holes not in tune with reality, and eventually when traffic died down the variable would decrement down below 0, triggering the panic. Note that this panic only occurs if INVARIANTS is compiled into the kernel so the issue has been around for some time but not noticed. The attached patch makes use of the atomic(9) KPI to ensure incrementing/decrementing the variable is done atomically, which should fix the bug. Reviews/testing would be good so that we can get this into 8.0. Cheers, Lawrence -------------- next part -------------- Index: sys/netinet/tcp_sack.c =================================================================== --- sys/netinet/tcp_sack.c (revision 195317) +++ sys/netinet/tcp_sack.c (working copy) @@ -273,7 +273,7 @@ hole->rxmit = start; tp->snd_numholes++; - V_tcp_sack_globalholes++; + atomic_add_int(&V_tcp_sack_globalholes, 1); return hole; } @@ -289,7 +289,7 @@ uma_zfree(V_sack_hole_zone, hole); tp->snd_numholes--; - V_tcp_sack_globalholes--; + atomic_subtract_int(&V_tcp_sack_globalholes, 1); KASSERT(tp->snd_numholes >= 0, ("tp->snd_numholes >= 0")); KASSERT(V_tcp_sack_globalholes >= 0, ("tcp_sack_globalholes >= 0")); From mike at sentex.net Fri Jul 3 21:30:21 2009 From: mike at sentex.net (Mike Tancsa) Date: Fri Jul 3 21:30:28 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <4A4E5C82.9070209@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> Message-ID: <200907032127.n63LRpO9019250@lava.sentex.ca> At 03:31 PM 7/3/2009, Alexander Motin wrote: >It would be more interesting to investigate benefits on NCQ suitable >workload, as that are new for us. Something like unpacking a lot of >small files to normal or async-mounted or gjournalled FS, or some >multi-threaded read, or something else. Would be nice to understand >on which types of workload NCQ could give us visible effects. > >You can track real requests parallelism by looking on dev_active >field of `camcontrol tags ada0 -v`. We dont have too many disk I/O bound apps here. Where we do, we typically have used raid controllers in RAID10. But I will experiment a little more over the weekend. For us, we are interested in large amounts of storage for backup purposes. Having things like port multiplier features are very nice to have. But I will try some random io tests to see if I can measure a difference. >>The eSata port does not work, but it never did under the old driver >>either. I think it has a separate controller ? At the BIOS boot up >>time, it shows some Marvell controller talking to the eSata >>attached drive, and pciconf does show a separate ATA controller >>atapci0@pci0:6:0:0: class=0x01018f card=0x4f538086 >>chip=0x612111ab rev=0xb2 hdr=0x00 >> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >> device = '6121 SATA2 Controller' >> class = mass storage >> subclass = ATA >> cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 >> cap 05[50] = MSI supports 1 message >> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link x1(x1) > >But this device, implementing both PATA and SATA ports, report >itself as PATA controller. It's SATA part may be AHCI compatible, >but driver unable to attach it due to incorrect device >identification. Alike happens to my JMicron controllers, but in that >case system BIOS is able to switch it into the right mode with >separate PATA and AHCI SATA controllers devices. Looking in the BIOS, I am able to toggle IDE and RAID mode only for the eSata controller portion, where as I have IDE, AHCI and RAID for the onboard Intel controller. ---Mike From mexas at bristol.ac.uk Fri Jul 3 22:26:06 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Jul 3 22:26:19 2009 Subject: SUCCESS: Re: gmirror per partition In-Reply-To: <1944CCC8-B2D5-4C06-B21C-FAA5A37D6EE1@solfertje.student.utwente.nl> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> <1944CCC8-B2D5-4C06-B21C-FAA5A37D6EE1@solfertje.student.utwente.nl> Message-ID: <20090703222558.GA32365@mech-cluster238.men.bris.ac.uk> On Fri, Jul 03, 2009 at 01:18:28PM +0200, Alban Hertroys wrote: > On Jul 3, 2009, at 12:12 PM, Anton Shterenlikht wrote: > > > now to mirror root partition. > > > > My problem is that root is mounted and cannot (?) be unmounted, > > unlike /efi, > > on the live system. > > > > # gpart add -b 819234 -s 1048576 -t freebsd-ufs da1 > > da1p2 added > > # > > > > # gmirror label -vb round-robin root /dev/da0p2 > > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > > # > > > > If I create gmirror on da1, the spare disk: > > > > # gmirror label -vb round-robin root /dev/da1p2 > > Metadata value stored on /dev/da0p1. > > Done. > > # > > > > so that > > > > # gmirror status > > Name Status Components > > mirror/efi COMPLETE da0p1 > > da1p1 > > mirror/root COMPLETE da1p2 > > > > # > > > > > > then I still cannot insert da0p2 > > > > > > # gmirror insert root da0p2 > > gmirror: Cannot access provider da0p2. > > # > > > > So how can I gmirror root partion on a live system? > > You're almost there... I did this a while ago, can't remember when, > but I just upgraded the system that had this from FreeBSD 6.3 of > sometime in 2006 to 7.2. > > What I believe I did from this point on was: > > Copy everything from the root partition to mirror/root. > Modify /etc/fstab to mount root on mirror/root. > Reboot. > > Now the original root partition isn't mounted anymore, so we can do > operate on it's geom stuff. > > gmirror insert root da0p2 > > That should be it. > If that doesn't work you can always boot off a live file-system CD/DVD > and perform these actions from there. You won't have man pages in that > case though, or at least I couldn't find a way to read them off the > DVD last I tried. > > One thing I'd like to warn about at this point: > If you ever upgrade to a kernel with a newer geom metadata version and > that new kernel crashes, you're left with a system where the new > kernel can't boot at all while the old kernel can't mount the root > mirror as it's now of a version it can't handle. > You can however mount a single geom provider of that root file system > (/dev/da1p2 for example) to try to fix things. > That file-system WILL be dirty, but DON'T run fsck on it or you will > destroy it's contents. That's what happened to my upgrade above... > > Thankfully it was only my root partition with hardly any data on it > and I did make level 0 dumps before the upgrade, but I needed to > restore that FS from a fixit shell without man pages. Augh! thank you, that was helpful. I think I've got it, but it's a bit more complex on ia64 because /boot is a symlink to /efi/boot, which is a separate partition. Anyway, I've got: # gmirror status Name Status Components mirror/efi COMPLETE da0p1 da1p1 mirror/root COMPLETE da0p2 da1p2 mirror/swap COMPLETE da0p3 da1p3 mirror/var COMPLETE da1p4 da0p4 mirror/tmp COMPLETE da1p5 da0p5 mirror/usr DEGRADED da1p6 da0p6 (24%) # I'll try to write up my experience and post later. thanks again -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From jos at catnook.com Fri Jul 3 22:31:16 2009 From: jos at catnook.com (Jos Backus) Date: Fri Jul 3 22:31:23 2009 Subject: Selection using mouse aborts unexpectedly Message-ID: <20090703221810.GA31128@lizzy.catnook.local> Hi, For a few weeks now, when I drag my mouse over some text with the left button pressed down, the selection will reproducibly abort after a second or so and start re-selecting even though I never let go of the mouse button. This used to work fine and is very annoying, to say the least. Is anybody else seeing this? It happens both on the console and in X. I'm running moused like this: /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid dmesg output: ums0: on usbus6 ums0: 5 buttons and [XYZ] coordinates ID=1 ums0: on usbus6 ums0: 5 buttons and [XYZ] coordinates ID=1 -- Jos Backus jos at catnook.com From alexbestms at math.uni-muenster.de Sat Jul 4 00:20:23 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sat Jul 4 00:20:31 2009 Subject: clangbsd svn compilation error Message-ID: i just grabbed a svn snapshot of clangbsd and did a buildworld inside it, but i'm getting this error: c++ -O2 -fno-strict-aliasing -pipe -I/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../../../contrib/llvm/include -I/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../../../contrib/llvm/tools/clang/include -I/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../../../contrib/llvm/utils/TableGen -I. -I/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-undermydesk-freebsd8.0\" -I/usr/obj/usr/local/src/clangbsd/tmp/legacy/usr/include -fconserve-space -static -L/usr/obj/usr/local/src/clangbsd/tmp/legacy/usr/lib -o tblgen AsmWriterEmitter.o CallingConvEmitter.o ClangDiagnosticsEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenInstruction.o CodeGenTarget.o DAGISelEmitter.o FastISelEmitter.o InstrEnumEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o LLVMCConfigurationEmitter.o Record.o RegisterInfoEmitter.o SubtargetEmitter.o TGLexer.o TGParser.o TGValueTypes.o TableGen.o TableGenBackend.o /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsupport/libllvmsupport.a /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsystem/libllvmsystem.a -lpthread -legacy /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsystem/libllvmsystem.a(Atomic.o)(.text+0x25): In function `llvm::sys::AtomicIncrement(unsigned int volatile*)': : undefined reference to `__sync_add_and_fetch_4' /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsystem/libllvmsystem.a(Atomic.o)(.text+0x45): In function `llvm::sys::AtomicDecrement(unsigned int volatile*)': : undefined reference to `__sync_sub_and_fetch_4' /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsystem/libllvmsystem.a(Atomic.o)(.text+0x5): In function `llvm::sys::AtomicAdd(unsigned int volatile*, unsigned int)': : undefined reference to `__sync_add_and_fetch_4' /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsystem/libllvmsystem.a(Atomic.o)(.text+0x61): In function `llvm::sys::CompareAndSwap(unsigned int volatile*, unsigned int, unsigned int)': : undefined reference to `__sync_val_compare_and_swap_4' *** Error code 1 Stop in /usr/local/src/clangbsd/usr.bin/clang/bin/tblgen. *** Error code 1 Stop in /usr/local/src/clangbsd. *** Error code 1 Stop in /usr/local/src/clangbsd. *** Error code 1 Stop in /usr/local/src/clangbsd. i followed the instructions on the wiki. i'm running r195247 (HEAD) and the revision of the clangbsd svn snapshot i was trying to build is 195329. i have llvm-devel-2.6.r71086 installed and running gcc version 4.2.1 20070719 (the one that comes with world). cheers. alex From patfbsd at davenulle.org Sat Jul 4 07:07:13 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Sat Jul 4 07:07:21 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <200907031929.17327.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031756.55253.hselasky@c2i.net> <20090703185233.4f7e4a65@baby-jane.lamaiziere.net> <200907031929.17327.hselasky@c2i.net> Message-ID: <20090704090703.1b26dce1@baby-jane.lamaiziere.net> Le Fri, 3 Jul 2009 19:29:15 +0200, Hans Petter Selasky a ?crit : ... > > It looks like there are some problems even with the first job (I > > missed this point before). > > > > ulpt0: using bi-directional > > ulpt_write_callback:220: state=0x0 actlen=0 > > ulpt_write_callback:220: state=0x1 actlen=2889 > > ulpt_write_callback:220: state=0x1 actlen=3023 > > ... > > ulpt_status_callback:352: error=USB_ERR_STALLED > > ulpt_write_callback:220: state=0x1 actlen=16384 > > ulpt_write_callback:220: state=0x1 actlen=16384 > > At this point it looks like the firmware crashes, when the error code > changes from STALLED to IOERROR. > > Are you sure the .ps/.pcl file is not corrupt? Yes I print the cups' test page, I've reinstalled all cupds, foomatic and hpijs just to be sure. > > If it can help, I can compare with FreeBSD 7.2. > > Yes, that might give some more clues. On 7.2 (but not on the same hardware): ulptopen: flags=0x40 ulpt_open: open input pipe ulpt_open: start read callout ulptopen: done, error=0 ulpt_tick: start sc=0xc6fae000 ulpt_tick: err=1 ulpt_read_cb: start sc=0xc6fae000, err=0 n=0 ulpt_tick: start sc=0xc6fae000 ulpt_tick: err=1 ulpt_read_cb: start sc=0xc6fae000, err=0 n=0 ulptwrite ulpt_status: status=0x18 err=0 ulptwrite: transfer 4096 bytes ulptwrite ulpt_status: status=0x18 err=0 ulptwrite: transfer 4096 bytes ulpt_status: status=0x18 err=0 ulptwrite: transfer 4096 bytes ulptwrite ulpt_status: status=0x18 err=0 ulptwrite: transfer 4096 bytes ulpt_status: status=0x18 err=0 ulptwrite: transfer 4096 bytes ulptwrite ulpt_status: status=0x18 err=0 ulptwrite: transfer 4096 bytes ulpt_tick: start sc=0xc6fae000 ulpt_tick: err=1 ulpt_read_cb: start sc=0xc6fae000, err=0 n=0 ulpt_status: status=0x18 err=0 ulptwrite: transfer 4096 bytes ... ulptclose: closed I've tried to change ULPT_BSIZE to 4096 (ulpt.c) on Current but there are still some "USB_ERR_IOERROR". No luck. Thanks! From patfbsd at davenulle.org Sat Jul 4 07:14:48 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Sat Jul 4 07:14:54 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <4A4E4D12.9010501@freebsd.org> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031758.35319.hselasky@c2i.net> <20090703193400.60fef21f@baby-jane.lamaiziere.net> <4A4E4D12.9010501@freebsd.org> Message-ID: <20090704091444.0fbdd018@baby-jane.lamaiziere.net> Le Fri, 03 Jul 2009 11:25:22 -0700, Sam Leffler a ?crit : > > I tried : with ulpt0 the printer does not print anything (With > > previous FreeBSD I used unlpt0): the reset disconnects the printer. > > > > ulpt0: > addr 2> on usbus0 > > ulpt_attach:562: setting alternate config number: 0 > > ulpt0: using bi-directional mode > > ugen0.2: at usbus0 (disconnected) > > ulpt0: at uhub0, port 1, addr 2 (disconnected) > > ulpt_detach:653: sc=0xc3176480 > > ugen0.2: at usbus0 > > ulpt0: > addr 2> on usbus0 ulpt_attach:562: setting alternate config number: > > 0 ulpt0: using bi-directional mode > > > > This looks a bit like an issue I'm about to start chasing where FS > devices fed through a HS hub disconnect "spontaneously" under load. > It doesn't look like it but to be sure there are no hubs between the > host and the printer? No hub at all. May be it's related to the usb chipset but I do not have any problem with umass. From hselasky at c2i.net Sat Jul 4 07:46:07 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Jul 4 07:46:16 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <20090703172600.1971111e@baby-jane.lamaiziere.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> Message-ID: <200907040945.41153.hselasky@c2i.net> On Friday 03 July 2009 17:26:00 Patrick Lamaiziere wrote: > ulpt_write_callback:220: state=0x1 actlen=2889 > ulpt_write_callback:220: state=0x1 actlen=3023 These two lines are interesting. Are these printed when doing the same job? If the actlen is not a factor of 64 in your case, the printer will think that the document has ended. Could you verify that, that cups is feeding too little data into the ULPT port? --HPS From h.schmalzbauer at omnilan.de Sat Jul 4 08:13:26 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Sat Jul 4 08:13:36 2009 Subject: Odd disk spin-ups (seperate non-OS-disk) Message-ID: <4A4F0F23.3050208@omnilan.de> Hello, I have -current installed on a SSD (incl. /var) and have another, usually not used, hard disk which gets spun down after some minutes idle time. Frequently my complete system stops (no mouse moving) until the not used hard disk spins up. How can I find out what process causes the disk access and more important, why does it block my complete system? Best regards, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090704/35288d73/signature.pgp From rhurlin at gwdg.de Sat Jul 4 09:22:20 2009 From: rhurlin at gwdg.de (Rainer Hurling) Date: Sat Jul 4 09:22:27 2009 Subject: Logitech QuickCam 9000 Pro In-Reply-To: <49C4B426.3070603@gwdg.de> References: <49AAA35F.3080805@gwdg.de> <200903012105.55371.hselasky@c2i.net> <49AAFC99.9030205@gwdg.de> <200903012231.32565.hselasky@c2i.net> <49AB6E18.2000207@gwdg.de> <49C4B426.3070603@gwdg.de> Message-ID: <4A4F179A.6060606@gwdg.de> Hello Hans Petter, with the last changes on usb stack (a few days ago) my webcam is not regocnized any more. We got it working in march, if you remember ... Please tell me if I can help. Thanks in advance, Rainer Hurling On 21.03.2009 10:32 (UTC+2), Rainer Hurling wrote: > Since yesterday (03/20/2009) I find this webcam recognized from new > usbstack. Now we can start testing software working with it :-) > > Thank you, > Rainer > > > On 02.03.2009 06:26 (UTC+1), Rainer Hurling wrote: >> On 01.03.2009 22:31 (UTC+1), Hans Petter Selasky wrote: >>> On Sunday 01 March 2009, Rainer Hurling wrote: >>>> On 01.03.2009 21:05 (UTC+1), Hans Petter Selasky wrote: >>>>> On Sunday 01 March 2009, Rainer Hurling wrote: >>>>>> Rainer Hurling >>>>> Should end up in -current sometime next week. >>>>> >>>>> http://perforce.freebsd.org/chv.cgi?CH=158561 >>>>> >>>>> --HPS >>>> I just recognized that the naming for this device is correctly >>>> spelled as >>>> >>>> 'QuickCam Pro 9000' (the number at last). >>>> >>>> I am afraid this could be relevant for some linux drivers and >>>> applications. Hope you can change it for the last time :-) >>>> >>>> And there is a salience in sys/dev/usb/usbdevs: at line 1648 another >>>> device is named QUICKCAMPRO2. Could this provoke unpredictable >>>> behaviour >>>> of the driver? >>> >>> Ok, try this: >>> >>> http://perforce.freebsd.org/chv.cgi?CH=158563 >>> >>> --HPS >> >> This should work. >> >> Thanks, >> Rainer From hselasky at c2i.net Sat Jul 4 09:43:43 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Jul 4 09:43:50 2009 Subject: Logitech QuickCam 9000 Pro In-Reply-To: <4A4F179A.6060606@gwdg.de> References: <49AAA35F.3080805@gwdg.de> <49C4B426.3070603@gwdg.de> <4A4F179A.6060606@gwdg.de> Message-ID: <200907041143.15598.hselasky@c2i.net> On Saturday 04 July 2009 10:49:30 Rainer Hurling wrote: > Hello Hans Petter, > > with the last changes on usb stack (a few days ago) my webcam is not > regocnized any more. We got it working in march, if you remember ... > > Please tell me if I can help. What is the location of the driver? You need to refresh my memory. --HPS From rhurlin at gwdg.de Sat Jul 4 10:41:00 2009 From: rhurlin at gwdg.de (Rainer Hurling) Date: Sat Jul 4 10:41:06 2009 Subject: Logitech QuickCam 9000 Pro In-Reply-To: <200907041143.15598.hselasky@c2i.net> References: <49AAA35F.3080805@gwdg.de> <49C4B426.3070603@gwdg.de> <4A4F179A.6060606@gwdg.de> <200907041143.15598.hselasky@c2i.net> Message-ID: <4A4F31B7.2090501@gwdg.de> Hello Hans Petter, thank you for answering. I am working with newest 8.0-CURRENT. Your latest changes in our post were at: http://p4db.freebsd.org/chv.cgi?CH=158563 After that patches, I got the following output # usbconfig ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON The entry in /sys/dev/usb/usbdevs (line 1649) seems ok: product LOGITECH QUICKCAMPRO3 0x0990 QuickCam Pro 9000 Tell me, if you need more information or testing. Rainer On 04.07.2009 11:43 (UTC+2), Hans Petter Selasky wrote: > On Saturday 04 July 2009 10:49:30 Rainer Hurling wrote: >> Hello Hans Petter, >> >> with the last changes on usb stack (a few days ago) my webcam is not >> regocnized any more. We got it working in march, if you remember ... >> >> Please tell me if I can help. > > What is the location of the driver? > > You need to refresh my memory. > > --HPS > From hselasky at c2i.net Sat Jul 4 10:43:27 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Jul 4 10:43:33 2009 Subject: Logitech QuickCam 9000 Pro In-Reply-To: <4A4F31B7.2090501@gwdg.de> References: <49AAA35F.3080805@gwdg.de> <200907041143.15598.hselasky@c2i.net> <4A4F31B7.2090501@gwdg.de> Message-ID: <200907041243.00578.hselasky@c2i.net> On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: > Hello Hans Petter, > > thank you for answering. I am working with newest 8.0-CURRENT. > > Your latest changes in our post were at: > > http://p4db.freebsd.org/chv.cgi?CH=158563 > > > After that patches, I got the following output > > # usbconfig > ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON Are you compiling the driver from ports? Did you recompile the port? --HPS From rhurlin at gwdg.de Sat Jul 4 10:52:42 2009 From: rhurlin at gwdg.de (Rainer Hurling) Date: Sat Jul 4 10:52:50 2009 Subject: Logitech QuickCam 9000 Pro In-Reply-To: <200907041243.00578.hselasky@c2i.net> References: <49AAA35F.3080805@gwdg.de> <200907041143.15598.hselasky@c2i.net> <4A4F31B7.2090501@gwdg.de> <200907041243.00578.hselasky@c2i.net> Message-ID: <4A4F3477.5070201@gwdg.de> On 04.07.2009 12:42 (UTC+2), Hans Petter Selasky wrote: > On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: >> Hello Hans Petter, >> >> thank you for answering. I am working with newest 8.0-CURRENT. >> >> Your latest changes in our post were at: >> >> http://p4db.freebsd.org/chv.cgi?CH=158563 >> >> >> After that patches, I got the following output >> >> # usbconfig >> ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=ON > > Are you compiling the driver from ports? Did you recompile the port? No, that is without any driver from ports (which driver do you mean?). My report relates to the (new) usb stack from system, I think. Actually I get the following message when using usbconfig: # usbconfig ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Rainer From mav at FreeBSD.org Sat Jul 4 11:21:14 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sat Jul 4 11:21:20 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <200907021859.n62IxghN009931@lava.sentex.ca> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> Message-ID: <4A4F3B18.5010905@FreeBSD.org> Mike Tancsa wrote: > On the ich10 board, its trying to boot up now, but I am getting > > uhub8: 4 ports with 4 removable, self powered > (probe2:ahcich2:0:0:0): SIGNATURE: eb14 > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > ahcich2: Timeout on slot 4 > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > ahcich2: Timeout on slot 5 > run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config > ahcich2: Timeout on slot 6 > run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config > ahcich2: Timeout on slot 7 > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > ahcich2: Timeout on slot 8 > ada0 at ahcich1 bus 0 target 0 lun 0 > ada0: ATA/ATAPI-8 SATA 2.x device > ada0: 300.000MB/s transfers > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: Native Command Queueing Enabled I've found how to make this DVD work. It refused to process PACKET command until I have explicitly set it's PATA-legacy transfer mode to the maximal supported. %camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) at scbus2 target 0 lun 0 (cd0,pass1) Patch committed to P4. -- Alexander Motin From hselasky at c2i.net Sat Jul 4 11:49:30 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Jul 4 11:49:38 2009 Subject: Logitech QuickCam 9000 Pro In-Reply-To: <4A4F3477.5070201@gwdg.de> References: <49AAA35F.3080805@gwdg.de> <200907041243.00578.hselasky@c2i.net> <4A4F3477.5070201@gwdg.de> Message-ID: <200907041349.00734.hselasky@c2i.net> On Saturday 04 July 2009 12:52:39 Rainer Hurling wrote: > On 04.07.2009 12:42 (UTC+2), Hans Petter Selasky wrote: > > On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: > >> Hello Hans Petter, > >> > >> thank you for answering. I am working with newest 8.0-CURRENT. > >> > >> Your latest changes in our post were at: > >> > >> http://p4db.freebsd.org/chv.cgi?CH=158563 > >> > >> > >> After that patches, I got the following output > >> > >> # usbconfig > >> ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH > >> (480Mbps) pwr=ON > > > > Are you compiling the driver from ports? Did you recompile the port? > > No, that is without any driver from ports (which driver do you mean?). > My report relates to the (new) usb stack from system, I think. > > Actually I get the following message when using usbconfig: > > # usbconfig > ugen1.2: at usbus1, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON > Ok, now I get it. You need to add the "USB_VERBOSE" option to the kernel config. Verbose output is not compiled by default any more. --HPS From rhurlin at gwdg.de Sat Jul 4 12:56:20 2009 From: rhurlin at gwdg.de (Rainer Hurling) Date: Sat Jul 4 12:56:27 2009 Subject: Logitech QuickCam 9000 Pro In-Reply-To: <200907041349.00734.hselasky@c2i.net> References: <49AAA35F.3080805@gwdg.de> <200907041243.00578.hselasky@c2i.net> <4A4F3477.5070201@gwdg.de> <200907041349.00734.hselasky@c2i.net> Message-ID: <4A4F5167.8080601@gwdg.de> On 04.07.2009 13:48 (UTC+2), Hans Petter Selasky wrote: > On Saturday 04 July 2009 12:52:39 Rainer Hurling wrote: >> On 04.07.2009 12:42 (UTC+2), Hans Petter Selasky wrote: >>> On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: >>>> Hello Hans Petter, >>>> >>>> thank you for answering. I am working with newest 8.0-CURRENT. >>>> >>>> Your latest changes in our post were at: >>>> >>>> http://p4db.freebsd.org/chv.cgi?CH=158563 >>>> >>>> >>>> After that patches, I got the following output >>>> >>>> # usbconfig >>>> ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH >>>> (480Mbps) pwr=ON >>> Are you compiling the driver from ports? Did you recompile the port? >> No, that is without any driver from ports (which driver do you mean?). >> My report relates to the (new) usb stack from system, I think. >> >> Actually I get the following message when using usbconfig: >> >> # usbconfig >> ugen1.2: at usbus1, cfg=0 md=HOST >> spd=HIGH (480Mbps) pwr=ON >> > > Ok, now I get it. > > You need to add the "USB_VERBOSE" option to the kernel config. Verbose output > is not compiled by default any more. I added 'options USB_VERBOSE' to my kernel config file. The kernel build stops with 'unknown option "USB_VERBOSE". Any hint? Rainer From paul at fletchermoorland.co.uk Sat Jul 4 14:30:58 2009 From: paul at fletchermoorland.co.uk (Paul Wootton) Date: Sat Jul 4 14:31:05 2009 Subject: Has anyone been able to actually boot the AMD64 kernel afterr194958? In-Reply-To: <200907022136.04164.ken@mthelicon.com> Message-ID: <200907041430.n64EUs1E029080@hydra.fletchermoorland.co.uk> Hi Peg, Yes I do have an r600 series graphics card. Trying John Baldwin's from patch the "panic on acpi_cpu_c1()" thread at http://www.FreeBSD.org/~jhb/patches/msi_assign.patch fixed the boot issues from me Paul -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Pegasus Mc Cleaft Sent: 02 July 2009 21:36 To: freebsd-current@freebsd.org Cc: Thomas Backman; current@freebsd.org; Paul Wootton Subject: Re: Has anyone been able to actually boot the AMD64 kernel afterr194958? On Thursday 02 July 2009 15:50:31 Paul Wootton wrote: > > With you saying this, I decided to try GENERIC kernel configuration and > that builds and runs just fine. I suspect that Peg and myself have > something in our kernel conf files that is causing an issue. I'll have a > go later on and see if I can narrow it down a little bit more > > Paul > Hi Paul, I think I may have tracked down the trigger, although I dont know how to pin- point the cause. It looks like compiling in the radeondrm driver into the kernel is the culprit. if I omit that line from my kernel config, the latest kernels will compile and boot properly on my machine. I'm using a R7xx (but it load the R6xx code) radeon HD card. From talking to you, I know you are using a proper R6xx card. Strangely I can kldload the driver after the machine has booted and all is well, it just seems to hate being compiled into the kernel. Can you see if this is the same on your machine? Peg _______________________________________________ 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" ---------------------------------------------------------------------------- ------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From patfbsd at davenulle.org Sat Jul 4 14:43:46 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Sat Jul 4 14:43:54 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <200907040945.41153.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907040945.41153.hselasky@c2i.net> Message-ID: <20090704164341.0acd0271@baby-jane.lamaiziere.net> Le Sat, 4 Jul 2009 09:45:40 +0200, Hans Petter Selasky a ?crit : > > ulpt_write_callback:220: state=0x1 actlen=2889 > > ulpt_write_callback:220: state=0x1 actlen=3023 > > These two lines are interesting. Are these printed when doing the > same job? Yes. > If the actlen is not a factor of 64 in your case, the printer will > think that the document has ended. Could you verify that, that cups > is feeding too little data into the ULPT port? Sometime cups writes only a litle amount of datas: [Job 40] Read 161 bytes of print data... [Job 40] Wrote 161 bytes of print data... [Job 40] Read 251 bytes of print data... [Job 40] Wrote 251 bytes of print data... [Job 40] Read 162 bytes of print data... [Job 40] Wrote 162 bytes of print data... [Job 40] Read 86 bytes of print data... [Job 40] Wrote 86 bytes of print data... [Job 40] Read 3292 bytes of print data... [Job 40] Wrote 3292 bytes of print data... [Job 40] Read 43 bytes of print data... [Job 40] Wrote 43 bytes of print data... [Job 40] Read 4096 bytes of print data... [Job 40] Wrote 4096 bytes of print data... Cups uses a select() on the input file to print, reads the datas and writes them to the usb port until the input file is empty. There is no warranty that the amount of datas will be a factor of 64 bytes. From hselasky at c2i.net Sat Jul 4 18:25:08 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Jul 4 18:25:15 2009 Subject: Logitech QuickCam 9000 Pro In-Reply-To: <4A4F5167.8080601@gwdg.de> References: <49AAA35F.3080805@gwdg.de> <200907041349.00734.hselasky@c2i.net> <4A4F5167.8080601@gwdg.de> Message-ID: <200907042024.39770.hselasky@c2i.net> On Saturday 04 July 2009 14:56:07 Rainer Hurling wrote: > On 04.07.2009 13:48 (UTC+2), Hans Petter Selasky wrote: > > On Saturday 04 July 2009 12:52:39 Rainer Hurling wrote: > >> On 04.07.2009 12:42 (UTC+2), Hans Petter Selasky wrote: > >>> On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: > >>>> Hello Hans Petter, > >>>> > >>>> thank you for answering. I am working with newest 8.0-CURRENT. > >>>> > >>>> Your latest changes in our post were at: > >>>> > >>>> http://p4db.freebsd.org/chv.cgi?CH=158563 > >>>> > >>>> > >>>> After that patches, I got the following output > >>>> > >>>> # usbconfig > >>>> ugen1.2: at usbus1, cfg=0 md=HOST > >>>> spd=HIGH (480Mbps) pwr=ON > >>> > >>> Are you compiling the driver from ports? Did you recompile the port? > >> > >> No, that is without any driver from ports (which driver do you mean?). > >> My report relates to the (new) usb stack from system, I think. > >> > >> Actually I get the following message when using usbconfig: > >> > >> # usbconfig > >> ugen1.2: at usbus1, cfg=0 md=HOST > >> spd=HIGH (480Mbps) pwr=ON > > > > Ok, now I get it. > > > > You need to add the "USB_VERBOSE" option to the kernel config. Verbose > > output is not compiled by default any more. > > I added 'options USB_VERBOSE' to my kernel config file. The kernel build > stops with 'unknown option "USB_VERBOSE". Any hint? > You need to edit: src/sys/conf/options And change: USBVERBOSE opt_usb.h Into: USB_VERBOSE opt_usb.h --HPS > Rainer > > _______________________________________________ > 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 rivanr at gmail.com Sat Jul 4 18:45:04 2009 From: rivanr at gmail.com (Ivan Radovanovic) Date: Sat Jul 4 18:45:10 2009 Subject: Weird installation issue Message-ID: <4A4F9CC0.70603@gmail.com> Hello, I recently wanted to update FreeBSD on my computer to latest version, but now I am facing weird problem. After completing installation from dvd I can't boot into BSD. I naturally assumed this is some boot manager/boot sector issue, and since I am using Vista also (but on the other hard disk) I first overwrited its boot manager with FreeBSD's but without any luck (when I press F2 to start BSD machine either stops to respond or prints # for any keypress, no any messages from BSD bootloader). After that I tried to make BSD entry in grub from open solaris but with the same symptoms (freezing without any message on the screen). I also tried installing GAG boot manager but with the same results. When I open BSD's partition using some hex editor boot sector seems written correctly. Also if I boot fixit prompt from dvd I can mount partition from hard disk (I tried only mounting a partition where is /) everything looks written correctly. However if I escape to loader prompt at dvd during boot and set currdev to "disk1s1a:" when I issue ls everything freezes. I believe this is some booting issue on my machine, but I am loosing ideas what can I try next. Please advise what I should try (FreeBSD is my first choice for UNIX and now I am stuck with open solaris) Ivan From rhurlin at gwdg.de Sat Jul 4 19:14:10 2009 From: rhurlin at gwdg.de (Rainer Hurling) Date: Sat Jul 4 19:15:16 2009 Subject: Logitech QuickCam 9000 Pro In-Reply-To: <200907042024.39770.hselasky@c2i.net> References: <49AAA35F.3080805@gwdg.de> <200907041349.00734.hselasky@c2i.net> <4A4F5167.8080601@gwdg.de> <200907042024.39770.hselasky@c2i.net> Message-ID: <4A4FA9F6.7070304@gwdg.de> On 04.07.2009 20:24 (UTC+2), Hans Petter Selasky wrote: > On Saturday 04 July 2009 14:56:07 Rainer Hurling wrote: >> On 04.07.2009 13:48 (UTC+2), Hans Petter Selasky wrote: >>> On Saturday 04 July 2009 12:52:39 Rainer Hurling wrote: >>>> On 04.07.2009 12:42 (UTC+2), Hans Petter Selasky wrote: >>>>> On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: >>>>>> Hello Hans Petter, >>>>>> >>>>>> thank you for answering. I am working with newest 8.0-CURRENT. >>>>>> >>>>>> Your latest changes in our post were at: >>>>>> >>>>>> http://p4db.freebsd.org/chv.cgi?CH=158563 >>>>>> >>>>>> >>>>>> After that patches, I got the following output >>>>>> >>>>>> # usbconfig >>>>>> ugen1.2: at usbus1, cfg=0 md=HOST >>>>>> spd=HIGH (480Mbps) pwr=ON >>>>> Are you compiling the driver from ports? Did you recompile the port? >>>> No, that is without any driver from ports (which driver do you mean?). >>>> My report relates to the (new) usb stack from system, I think. >>>> >>>> Actually I get the following message when using usbconfig: >>>> >>>> # usbconfig >>>> ugen1.2: at usbus1, cfg=0 md=HOST >>>> spd=HIGH (480Mbps) pwr=ON >>> Ok, now I get it. >>> >>> You need to add the "USB_VERBOSE" option to the kernel config. Verbose >>> output is not compiled by default any more. >> I added 'options USB_VERBOSE' to my kernel config file. The kernel build >> stops with 'unknown option "USB_VERBOSE". Any hint? >> > > You need to edit: > > src/sys/conf/options > > And change: > > USBVERBOSE opt_usb.h > > Into: > > USB_VERBOSE opt_usb.h Ok, now I get the full message back: # usbconfig ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON But what was the intention to print this message less verbose? And one other question: Do you know a working driver in the ports system for the Quickcam Pro 9000? Thanks for all, Rainer From gelraen.ua at gmail.com Sat Jul 4 21:00:07 2009 From: gelraen.ua at gmail.com (Maxim Ignatenko) Date: Sat Jul 4 21:00:16 2009 Subject: panic on acpi_cpu_c1() In-Reply-To: <4A4D3665.3060502@FreeBSD.org> References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> <4A4D3665.3060502@FreeBSD.org> Message-ID: 2009/7/3 John Baldwin : > Maxim Ignatenko wrote: >>> >>> Fatal trap 30: reserved (unknown) fault while in kernel mode >>> cpuid = 3; apic id = 03 >>> instruction pointer ? ? = 0x20:0xffffffff804bce56 >>> stack pointer ? ? ? ? ? = 0x20:0xffffff8000039b60 >>> frame pointer ? ? ? ? ? = 0x20:0xffffff8000039b70 >>> code segment ? ? ? ? ? ?= base 0x0, limit 0xfffff, type 0x1b >>> ? ? ? ? ? ? ? ? ? ? ? = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags ? ? ? ?= interrupt enabled, IOPL = 0 >>> current process ? ? ? ? = 11 (idle: cpu3) >>> [thread pid 11 tid 100003 ] >>> Stopped at ? ? ?acpi_cpu_c1+0x6: ? ? ? ?leave >>> db> bt >>> Tracing pid 11 tid 100003 td 0xffffff8001863720 >>> acpi_cpu_c1() at acpi_cpu_c1+0x6 >>> acpi_cpu_idle() at acpi_cpu_idle+0x20c >>> sched_idletd() at sched_idletd+0x123 >>> fork_exit() at fork_exit+0x117 >>> fork_trampoline() at fork_trampoline+0xe >> >> As for me, r194984 runs normally, but when I tried to boot with >> r194985 at second try it paniced with backtrace very similar to shown >> in first message, and at first try even earlier: in sched_ideltd and >> again on instruction that uses %ebp when ebp = 0. >> First time I stepped on this panic after updating to r195130: >> >> Trying to mount root from ufs:/dev/ufs/root >> >> >> Fatal trap 30; reserved (unknown) fault while in kernel mode >> cpuid = 1; apic id = 01 >> instruction ponter ? ? ?= 0x20:0xc09252c5 >> stack pointer ? ? ? ? ? = 0x28:0xc4ecec94 >> frame pointer ? ? ? ? ? = 0x28:0xc4ecec94 >> code segment ? ? ? ? ? ?= base 0x0, limit 0xfffff, type 0x1b >> ? ? ? ? ? ? ? ? ? ? ? ?= DPL 0, pres 1, def32 1, gran 1 >> processor eflags ? ? ? ?= interrupt enabled, IOPL = 0 >> current process ? ? ? ? = 11 (idle: cpu1) >> [thread pid 11 tid 100003] >> Stopped at ? ? ?0xc09252c5 = acpi_cpu_c1+0x5: ? ?popl ? ? %ebp >> db> bt >> Tracing pid 11 tid 100003 td 0xc5176af0 >> acpi_cpu_c1(1,c4ececa8,1,0,c4ececc0,...) at 0xc09252c5 = acpi_cpu_c1+0x5 >> acpi_cpu_idle(c4ececd4,c093c0ab,0,c4ececf4,c066fdec,...) at 0xc04acf37 >> = acpi_cpu_idle+0x107 >> cpu_idle_acpi(0,c4ececf4,c066fdec,0,0,...) at 0xc093d5bb = >> cpu_idle_acpi+0x1b >> cpu_idle(0,0,c5176af0,c4ececf4,202,...) at 0xc093c0ab = cpu_idle+0x1b >> sched_idletd(0,c4ececd38,a4108400,2c0a0e,7022d00,...) at 0xc066fdec = >> sched_idletd+0x1c >> fork_exit(c066fdd0,0,c4eced38) at 0xc0623aa1 = fork_exit+0x91 >> fork_trampoline() at 0xc0930c80 = fork_tramoline+0x8 >> --- trap 0, eip = 0, esp = 0xc4ececd70, ebp = 0 --- >> >> >> P.S.: i386, dual-core, drm and radeon compiled as modules >> When I'm trying to boot w/o ACPI support all seems work fine, but >> system hangs just before starting kdm > > Please try http://www.FreeBSD.org/~jhb/patches/msi_assign.patch > Seems to work fine, thanks! From freebsd-current at chrishedley.com Sat Jul 4 21:37:30 2009 From: freebsd-current at chrishedley.com (Chris Hedley) Date: Sat Jul 4 21:37:38 2009 Subject: New builds won't boot (fwd) In-Reply-To: <20090630175731.4c589f80@ernst.jennejohn.org> References: <4A2C124A.1050707@freebsd.org> <3c1674c90906291830g1c79c80bq42ce99f44588e968@mail.gmail.com> <20090630113544.3e2bef31@ernst.jennejohn.org> <20090630175731.4c589f80@ernst.jennejohn.org> Message-ID: On Tue, 30 Jun 2009, Gary Jennejohn wrote: > Ah, yes. Now that I think about it again, you're right. That's also > when I started seeing it. > > I'm now running mav's ata-cam patches and took ATA_STATIC_ID out of > my config file. I'd sort of forgotten when/why I'd done it. > > Sorry for the confusion. No problems, I may have a look at the ata-cam patch myself to see if that's any more successful. So thanks for the idea. :) On a completely different subject (and unrelated to the kind souls who have helped out), I'm a bit miffed to find these messages have been gated onto the web by freebsd.org, kerneltrap.org et al with complete, intact email addresses making them easily available to every spammer, 419er and other miscreant on the net. I was wondering why the amount of spam I was getting had tripled in the last fortnight. >:( From oberman at es.net Sat Jul 4 23:24:08 2009 From: oberman at es.net (Kevin Oberman) Date: Sat Jul 4 23:24:15 2009 Subject: nice work on ntp.conf! In-Reply-To: Your message of "Fri, 03 Jul 2009 22:48:52 +0200." <4A4E6EB4.9000000@phat.za.net> Message-ID: <20090704232317.2D0991CC09@ptavv.es.net> > Date: Fri, 03 Jul 2009 22:48:52 +0200 > From: Aragon Gouveia > Sender: owner-freebsd-current@freebsd.org > > Anton Shterenlikht wrote: > > ntp.conf update from 2009/06/07 is very welcome, > > works great straight out of the box, much better than before! > > > > many thanks to whoever worked on this. > > Agreed, thanks! > > Just wish there were a simple solution to the restriction directives... Really nice, although I feel uncomfortable about the use of LOCAL. It is a great opportunity for foot shooting and, since most systems running NTP are not used as serves, I think that it should be left commented out in the default case. -- 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 h.schmalzbauer at omnilan.de Sat Jul 4 23:54:51 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Sat Jul 4 23:54:58 2009 Subject: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) In-Reply-To: <4A4517BE.9040504@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> Message-ID: <4A4FEBBC.30203@omnilan.de> Alexander Motin schrieb am 26.06.2009 20:47 (localtime): ... > I would like to present for testing and feedback present state of my and > Scott work on extending CAM subsystem to support ATA in addition to > SCSI. At this moment we have: ... > - patch your recently updated 8-CURRENT with this patch: > http://people.freebsd.org/~mav/cam-ata.20090626.patch > - rebuild and install world and kernel; > - read new ahci man page; > - make sure that you will be able to boot if your SATA disk devices > name change from some ad4 to ada0; ... > Waiting for your feedback. Late, but now I'd like to jump in. I have a gournaled FS whoch lists it's consumer as ad12p6 Otherwise I only use labels (ufs) for quiet some time, so I thought testing would be painless... Can I safely remove glabel from the unmounted fs and relabel the new device? Any Experiences? Thanks, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090704/8b846d91/signature.pgp From mike at sentex.net Sun Jul 5 00:33:17 2009 From: mike at sentex.net (Mike Tancsa) Date: Sun Jul 5 00:33:29 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> Message-ID: <200907050030.n650UkEu028408@lava.sentex.ca> At 05:30 PM 7/3/2009, Mike Tancsa wrote: >At 03:31 PM 7/3/2009, Alexander Motin wrote: >>It would be more interesting to investigate benefits on NCQ >>suitable workload, as that are new for us. Something like unpacking >>a lot of small files to normal or async-mounted or gjournalled FS, >>or some multi-threaded read, or something else. Would be nice to >>understand on which types of workload NCQ could give us visible effects. >> >>You can track real requests parallelism by looking on dev_active >>field of `camcontrol tags ada0 -v`. > > >We dont have too many disk I/O bound apps here. Where we do, we >typically have used raid controllers in RAID10. But I will >experiment a little more over the weekend. For us, we are >interested in large amounts of storage for backup purposes. Having >things like port multiplier features are very nice to have. But I >will try some random io tests to see if I can measure a difference. I hooked up a Vantec eSata enclosure using a SATA to eSATA cable off the main motherboard. One small difference I noticed is that camcontrol does not get the info from the drive like it does on other devices. Perhaps thats the enclosure messing things up ? 0(ich10)# camcontrol identify ada2 pass2: < > ATA/ATAPI-0 device Protocol ATA/ATAPI revision 0 device model serial number firmware revision cylinders 0 heads 0 sectors/track 0 lba not supported lba48 not supported dma not supported overlap not supported Feature Support Enable Value Vendor write cache no no read ahead no no Tagged Command Queuing (TCQ) no no 0/0x00 SMART no no microcode download no no security no no power management no no advanced power management no no 0/0x00 automatic acoustic management no no 0/0x00 0/0x00 0(ich10)# 0(ich10)# camcontrol identify ada1 pass1: ATA/ATAPI-7 SATA 2.x device Protocol SATA revision 2.x device model ST380811AS serial number 6PS03G9Z firmware revision 3.AAE cylinders 16383 heads 16 sectors/track 63 lba supported 156301488 sectors lba48 supported 156301488 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 65278/0xFEFE automatic acoustic management no no 0/0x00 208/0xD0 0(ich10)# camcontrol identify ada0 pass0: ATA/ATAPI-8 SATA 2.x device Protocol SATA revision 2.x device model ST3500410AS serial number 5VM0X6FG firmware revision CC34 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 976773168 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 0/0x00 automatic acoustic management yes yes 0/0x00 254/0xFE 0(ich10)# There was a previous drive connected. We powered off the external drive, disconnected the cable, hooked up the new drive, powered up the enclosure and then I did a camcontrol rescan all Jul 4 20:19:22 ich10 kernel: (ada2:ahcich2:0:0:0): lost device Jul 4 20:19:22 ich10 kernel: (ada2:ahcich2:0:0:0): removing device entry Jul 4 20:19:37 ich10 kernel: (probe0:ahcich2:0:0:0): SIGNATURE: 0000 Jul 4 20:19:37 ich10 kernel: ada2 at ahcich2 bus 0 target 0 lun 0 Jul 4 20:19:37 ich10 kernel: ada2: ATA/ATAPI-8 SATA 1.x device Jul 4 20:19:37 ich10 kernel: ada2: 150.000MB/s transfers Jul 4 20:19:37 ich10 kernel: ada2: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) Jul 4 20:19:37 ich10 kernel: ada2: Native Command Queueing Enabled The drive we connected has some bad sectors, so I wanted to try a secure wipe as much as possible before RMAing the drive. I also thought it would be useful to test with the new driver how it handles bad disks Is this such an error ? Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is 40000001 cs 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 ---Mike From geekounet at poildetroll.net Sun Jul 5 01:02:57 2009 From: geekounet at poildetroll.net (Pierre Guinoiseau) Date: Sun Jul 5 01:03:04 2009 Subject: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 In-Reply-To: <3bbf2fe10906281051k1da8d1edwc49388e30d3df492@mail.gmail.com> References: <951233.95131.qm@web39108.mail.mud.yahoo.com> <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> <4A23919F.8050905@mail.zedat.fu-berlin.de> <4A2B3040.7020509@poildetroll.net> <3bbf2fe10906070339k663bace7qe5142702248ce6c9@mail.gmail.com> <4A2BBDC0.6000801@poildetroll.net> <3bbf2fe10906070623o65ce021fkb7f59fe1924cc1ec@mail.gmail.com> <4A353E21.1080001@poildetroll.net> <2BE0378C-96A3-4714-A5C3-7B1A6AA0DCE2@lakerest.net> <3bbf2fe10906281051k1da8d1edwc49388e30d3df492@mail.gmail.com> Message-ID: <4A4FFBB0.5050903@poildetroll.net> Hi, I have some good news: the problem seems to be solved (at least for me) since I updated to r195011 about 2 weeks ago. I think it may be related to the MSI fixes (and the drm module may have been the cause, even if not used?), but I might be wrong. After this update, the permanent slowdown issue disappeared, but I still had some slowdown on high CPU load (but it was back to normal soon after coming back to a low load). I then figured out that it was due to an overheat problem on my laptop, slowing down the wall machine in some way... I've cleaned it up (there was a 5mm wall of dust in the fan!), and no more overheat nor slowdown since then. I'm sorry I can't reproduce it anymore now. ;) And I hope Randall's problem is fixed as well. :) Thanks for your help anyway! Pierre Guinoiseau Attilio Rao wrote: > 2009/6/24 Randall Stewart : >> One thing I have noticed for a while.. and have not >> been able to track down.. >> >> If one runs >> >> /usr/src/tools/tools/syscall_timing/syscall_timing >> >> On a 7.2 kernel and compare it on the same machine to an 8.0 kernel >> you will see almost a 3x slow down in 8. > > So, as long as I think that for the pressing, next release, it is very > important to track such regressions down, I hope both Pierre and > Randall want to lend an hand. > > First thing, Randall, could you recompile your kernel with > HWPMC_HOOKS, device hwpmc, and do some pmcstat runs in order to see > where/how the slowdown happens? > For example you could check if the number of cache misses increases, or similar. > > Both could provide, instead, once the slowdown takes place, verbose > top, ps and possibly vmstat, just to be sure in case. > > If you are unable to reproduce the slowdown or give an hand, please let me know. > > Thanks, > Attilio > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090705/f9a879cd/signature.pgp From scottl at samsco.org Sun Jul 5 03:02:52 2009 From: scottl at samsco.org (Scott Long) Date: Sun Jul 5 03:03:25 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A4F3B18.5010905@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4F3B18.5010905@FreeBSD.org> Message-ID: <6E8AB140-4BF4-4CBC-BC96-D620F7A7CDFE@samsco.org> On Jul 4, 2009, at 5:20 AM, Alexander Motin wrote: > Mike Tancsa wrote: >> On the ich10 board, its trying to boot up now, but I am getting >> uhub8: 4 ports with 4 removable, self powered >> (probe2:ahcich2:0:0:0): SIGNATURE: eb14 >> run_interrupt_driven_hooks: still waiting after 60 seconds for >> xpt_config >> ahcich2: Timeout on slot 4 >> run_interrupt_driven_hooks: still waiting after 120 seconds for >> xpt_config >> ahcich2: Timeout on slot 5 >> run_interrupt_driven_hooks: still waiting after 180 seconds for >> xpt_config >> ahcich2: Timeout on slot 6 >> run_interrupt_driven_hooks: still waiting after 240 seconds for >> xpt_config >> ahcich2: Timeout on slot 7 >> run_interrupt_driven_hooks: still waiting after 300 seconds for >> xpt_config >> ahcich2: Timeout on slot 8 >> ada0 at ahcich1 bus 0 target 0 lun 0 >> ada0: ATA/ATAPI-8 SATA 2.x device >> ada0: 300.000MB/s transfers >> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada0: Native Command Queueing Enabled > > I've found how to make this DVD work. It refused to process PACKET > command until I have explicitly set it's PATA-legacy transfer mode > to the maximal supported. > > %camcontrol devlist > at scbus0 target 0 lun 0 > (pass0,ada0) > at scbus2 target 0 lun 0 > (cd0,pass1) > > Patch committed to P4. > > -- > Alexander Motin I mentioned this a few months ago. Both atapi and ata devices need a state machine to set their max transfer parameters, regardless if they are sata or pata. Newer sata devices might not need it, but older ones definitely do. IMHO, it's easiest to just do the negotiation for all sata devices instead of trying to be selective about it. Scott From mav at FreeBSD.org Sun Jul 5 06:41:32 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Jul 5 06:41:40 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <200907050030.n650UkEu028408@lava.sentex.ca> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> Message-ID: <4A504B0C.2060406@FreeBSD.org> Mike Tancsa wrote: > I hooked up a Vantec eSata enclosure using a SATA to eSATA cable off the > main motherboard. One small difference I noticed is that camcontrol > does not get the info from the drive like it does on other devices. > Perhaps thats the enclosure messing things up ? > > 0(ich10)# camcontrol identify ada2 > pass2: < > ATA/ATAPI-0 device That's strange. IDENTIFY is a basic ATA command, which must work always. > There was a previous drive connected. We powered off the external > drive, disconnected the cable, hooked up the new drive, powered up the > enclosure and then I did a camcontrol rescan all > > Jul 4 20:19:22 ich10 kernel: (ada2:ahcich2:0:0:0): lost device > Jul 4 20:19:22 ich10 kernel: (ada2:ahcich2:0:0:0): removing device entry > Jul 4 20:19:37 ich10 kernel: (probe0:ahcich2:0:0:0): SIGNATURE: 0000 > Jul 4 20:19:37 ich10 kernel: ada2 at ahcich2 bus 0 target 0 lun 0 > Jul 4 20:19:37 ich10 kernel: ada2: ATA/ATAPI-8 SATA > 1.x device > Jul 4 20:19:37 ich10 kernel: ada2: 150.000MB/s transfers > Jul 4 20:19:37 ich10 kernel: ada2: 715404MB (1465149168 512 byte > sectors: 16H 63S/T 16383C) > Jul 4 20:19:37 ich10 kernel: ada2: Native Command Queueing Enabled Looking to this, it was working. > The drive we connected has some bad sectors, so I wanted to try a secure > wipe as much as possible before RMAing the drive. I also thought it > would be useful to test with the new driver how it handles bad disks > > Is this such an error ? > > Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is 40000001 cs > 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 This is AHCI driver debugging. I've removed it in latest patch. In this case it means that drive signals some command error. -- Alexander Motin From mav at FreeBSD.org Sun Jul 5 07:18:17 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Jul 5 07:18:24 2009 Subject: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) In-Reply-To: <4A4FEBBC.30203@omnilan.de> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> Message-ID: <4A5053A8.2060902@FreeBSD.org> Harald Schmalzbauer wrote: > Late, but now I'd like to jump in. It's never late. I have just uploaded fresh patch: http://people.freebsd.org/~mav/cam-ata.20090704.patch > I have a gournaled FS whoch lists it's consumer as ad12p6 You mean gjournal has provider names hardcoded to it's meta data? It could be a problem. If it detects it's parts freely, then it should not notice the change. > Otherwise I only use labels (ufs) for quiet some time, so I thought > testing would be painless... > Can I safely remove glabel from the unmounted fs and relabel the new > device? I don't very understand whet you mean by "safe"? Safe for what? -- Alexander Motin From hselasky at c2i.net Sun Jul 5 07:29:33 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Jul 5 07:29:47 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <20090704164341.0acd0271@baby-jane.lamaiziere.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907040945.41153.hselasky@c2i.net> <20090704164341.0acd0271@baby-jane.lamaiziere.net> Message-ID: <200907050929.07784.hselasky@c2i.net> On Saturday 04 July 2009 16:43:41 Patrick Lamaiziere wrote: > Le Sat, 4 Jul 2009 09:45:40 +0200, > > Hans Petter Selasky a ?crit : > > > ulpt_write_callback:220: state=0x1 actlen=2889 > > > ulpt_write_callback:220: state=0x1 actlen=3023 > > > > These two lines are interesting. Are these printed when doing the > > same job? > > Yes. > > > If the actlen is not a factor of 64 in your case, the printer will > > think that the document has ended. Could you verify that, that cups > > is feeding too little data into the ULPT port? > > Sometime cups writes only a litle amount of datas: > > [Job 40] Read 161 bytes of print data... > [Job 40] Wrote 161 bytes of print data... > [Job 40] Read 251 bytes of print data... > [Job 40] Wrote 251 bytes of print data... > [Job 40] Read 162 bytes of print data... > [Job 40] Wrote 162 bytes of print data... > [Job 40] Read 86 bytes of print data... > [Job 40] Wrote 86 bytes of print data... > [Job 40] Read 3292 bytes of print data... > [Job 40] Wrote 3292 bytes of print data... > [Job 40] Read 43 bytes of print data... > [Job 40] Wrote 43 bytes of print data... > [Job 40] Read 4096 bytes of print data... > [Job 40] Wrote 4096 bytes of print data... > > Cups uses a select() on the input file to print, reads the datas and > writes them to the usb port until the input file is empty. > > There is no warranty that the amount of datas will be a factor of 64 > bytes. It is not right to defragment the data in /dev/ulpt either. Maybe I can make a variant device, /dev/udlpt, that will automatically defrag the data. What happens if you dd if=myjob.pcl.or.ps of=/dev/ulpt bs=1024 --HPS From serenity at exscape.org Sun Jul 5 08:17:19 2009 From: serenity at exscape.org (Thomas Backman) Date: Sun Jul 5 08:17:26 2009 Subject: kern/127441: [dtrace] Dtrace timestamp variable is wrapping as if define as uint32_t Message-ID: <31D779DF-EFD0-4255-9177-0F88CA7067CC@exscape.org> Could we have this patch merged in time for 8.0? I don't know if the problems in the PR followups are big enough, but considering that the current implementation is horribly broken for everyone, and the patch fixes it for a large number of people, I don't really see the downside in merging it for the time being. Regards, Thomas From hselasky at c2i.net Sun Jul 5 08:39:45 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Jul 5 08:39:52 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <20090704164341.0acd0271@baby-jane.lamaiziere.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907040945.41153.hselasky@c2i.net> <20090704164341.0acd0271@baby-jane.lamaiziere.net> Message-ID: <200907051039.19584.hselasky@c2i.net> On Saturday 04 July 2009 16:43:41 Patrick Lamaiziere wrote: > Le Sat, 4 Jul 2009 09:45:40 +0200, > > Hans Petter Selasky a ?crit : > > > ulpt_write_callback:220: state=0x1 actlen=2889 > > > ulpt_write_callback:220: state=0x1 actlen=3023 > > > > These two lines are interesting. Are these printed when doing the > > same job? > > Yes. > Can you try the attached patch for 8-current. Please provide ulpt debug prints in either failing or succeeding case. cd /sys/dev/usb cat ulpt.diff | patch Build a new kernel and modules. --HPS -------------- next part -------------- A non-text attachment was scrubbed... Name: ulpt.diff Type: text/x-patch Size: 7588 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090705/108352ff/ulpt.bin From ianf at clue.co.za Sun Jul 5 10:07:25 2009 From: ianf at clue.co.za (Ian Freislich) Date: Sun Jul 5 10:07:32 2009 Subject: pebkac, but is it a mergemaster bug? Message-ID: Hi Due to not paying attention my ntp.conf on several of my time servers was updated (and broken) by mergemaster. I had the automatic update options set for files that I had not modified. My ntp.conf had no VCS id and the files differed, obviously. Was mergemaster correct in its assesment that this file was a candidate for automatic installation? -U Attempt to auto upgrade files that have not been user modified Ian -- Ian Freislich From spambox at haruhiism.net Sun Jul 5 10:47:06 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Sun Jul 5 10:47:14 2009 Subject: r194546 amd64: kernel panic in tcp_sack.c In-Reply-To: <4A4E77EA.7030803@freebsd.org> References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> <4A4E77EA.7030803@freebsd.org> Message-ID: <4A5084A9.8060607@haruhiism.net> Lawrence Stewart wrote: > The SACK code puts a global cap on the amount of memory that can be > used for SACK accounting. The variable V_tcp_sack_globalholes tracks > how many SACK holes are currently allocated across all active TCP > connections. It gets incremented in tcp_sackhole_alloc() and > decremented in tcp_sackhole_free() in netinet/tcp_sack.c. > It turns out that there is currently no lock synchronising access to > the variable, and the incrementing/decrementing is not being done > atomically. In Kamigishi's case, the server had a traffic profile > consisting of a large number of clients simultaneously connecting over > cruddy links which was giving the SACK accounting a real workout. The > inevitable race would strike one or more times, leaving the count of > holes not in tune with reality, and eventually when traffic died down > the variable would decrement down below 0, triggering the panic. Note > that this panic only occurs if INVARIANTS is compiled into the kernel > so the issue has been around for some time but not noticed. > The attached patch makes use of the atomic(9) KPI to ensure > incrementing/decrementing the variable is done atomically, which > should fix the bug. > Reviews/testing would be good so that we can get this into 8.0. After applying the patch and rebuilding the kernel I've been getting (similar) kernel panics way too often. Two backtraces follow (note the uptime; it can vary from 4 minutes to 5-7 hours, but average time between traps is approximately 2 hours): Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1321288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8058ac15 stack pointer = 0x28:0xffffff80403d45f0 frame pointer = 0x28:0xffffff80403d4620 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 2350 (mysqld) trap number = 12 panic: page fault cpuid = 0 Uptime: 3h28m59s (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff80599a63 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff80599ebc in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xffffffff80861f8d in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:852 #4 0xffffffff80862c25 in trap (frame=0xffffff80403d4540) at /usr/src/sys/amd64/amd64/trap.c:345 #5 0xffffffff80848f13 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #6 0xffffffff8058ac15 in _mtx_lock_sleep (m=0xffffffff80e98863, tid=18446742975233083168, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 #7 0xffffffff8058ad6e in _mtx_lock_flags (m=Variable "m" is not available. ) at /usr/src/sys/kern/kern_mutex.c:203 #8 0xffffffff80647125 in netisr_queue_internal (proto=1, m=0xffffff0004ed1e00, cpuid=Variable "cpuid" is not available. ) at /usr/src/sys/net/netisr.c:830 #9 0xffffffff80647209 in netisr_queue_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:860 #10 0xffffffff80643180 in if_simloop (ifp=0xffffff0004609800, m=0xffffff0004ed1e00, af=2, hlen=0) at /usr/src/sys/net/if_loop.c:400 #11 0xffffffff806432d6 in looutput (ifp=0xffffff0004609800, m=0xffffff0004ed1e00, dst=0xffffff80403d47a0, ro=Variable "ro" is not available. ) at /usr/src/sys/net/if_loop.c:296 #12 0xffffffff806a2237 in ip_output (m=0xffffff0004ed1e00, opt=Variable "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:624 #13 0xffffffff80707874 in tcp_output (tp=0xffffff00137292d8) at /usr/src/sys/netinet/tcp_output.c:1188 #14 0xffffffff80713f29 in tcp_usr_send (so=0xffffff002bc32550, flags=0, m=Variable "m" is not available. ) at tcp_offload.h:269 #15 0xffffffff805fd197 in sosend_generic (so=0xffffff002bc32550, addr=0x0, uio=0xffffff80403d4b10, top=0xffffff0004efeb00, control=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/uipc_socket.c:1257 #16 0xffffffff805e18a7 in soo_write (fp=Variable "fp" is not available. ) at /usr/src/sys/kern/sys_socket.c:102 #17 0xffffffff805dad25 in dofilewrite (td=0xffffff003db34720, fd=30, fp=0xffffff0013d35a50, auio=0xffffff80403d4b10, offset=Variable "offset" is not available. ) at file.h:239 #18 0xffffffff805dc300 in kern_writev (td=0xffffff003db34720, fd=30, auio=0xffffff80403d4b10) at /usr/src/sys/kern/sys_generic.c:445 #19 0xffffffff805dc405 in write (td=Variable "td" is not available. ) at /usr/src/sys/kern/sys_generic.c:361 #20 0xffffffff808624cf in syscall (frame=0xffffff80403d4c90) at /usr/src/sys/amd64/amd64/trap.c:984 #21 0xffffffff808491a0 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #22 0x00000008014d8efc in ?? () Previous frame inner to this frame (corrupt stack?) Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1321288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8058ac15 stack pointer = 0x28:0xffffff8040145600 frame pointer = 0x28:0xffffff8040145630 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 1932 (lighttpd) trap number = 12 panic: page fault cpuid = 1 Uptime: 1h0m9s (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff80599a63 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff80599ebc in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xffffffff80861f8d in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:852 #4 0xffffffff80862c25 in trap (frame=0xffffff8040145550) at /usr/src/sys/amd64/amd64/trap.c:345 #5 0xffffffff80848f13 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #6 0xffffffff8058ac15 in _mtx_lock_sleep (m=0xffffffff80e98863, tid=18446742974276744992, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 #7 0xffffffff8058ad6e in _mtx_lock_flags (m=Variable "m" is not available. ) at /usr/src/sys/kern/kern_mutex.c:203 #8 0xffffffff80647125 in netisr_queue_internal (proto=1, m=0xffffff002453d400, cpuid=Variable "cpuid" is not available. ) at /usr/src/sys/net/netisr.c:830 #9 0xffffffff80647209 in netisr_queue_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:860 #10 0xffffffff80643180 in if_simloop (ifp=0xffffff0004609800, m=0xffffff002453d400, af=2, hlen=0) at /usr/src/sys/net/if_loop.c:400 #11 0xffffffff806432d6 in looutput (ifp=0xffffff0004609800, m=0xffffff002453d400, dst=0xffffff80401457b0, ro=Variable "ro" is not available. ) at /usr/src/sys/net/if_loop.c:296 #12 0xffffffff806a2237 in ip_output (m=0xffffff002453d400, opt=Variable "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:624 #13 0xffffffff80707874 in tcp_output (tp=0xffffff0014bb5b60) at /usr/src/sys/netinet/tcp_output.c:1188 #14 0xffffffff80713f29 in tcp_usr_send (so=0xffffff00047fb2a8, flags=0, m=Variable "m" is not available. ) at tcp_offload.h:269 #15 0xffffffff805fd197 in sosend_generic (so=0xffffff00047fb2a8, addr=0x0, uio=0xffffff000f4d4100, top=0xffffff00236c5d00, control=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/uipc_socket.c:1257 #16 0xffffffff805e18a7 in soo_write (fp=Variable "fp" is not available. ) at /usr/src/sys/kern/sys_socket.c:102 #17 0xffffffff805dad25 in dofilewrite (td=0xffffff0004b2b720, fd=10, fp=0xffffff0070f18a50, auio=0xffffff000f4d4100, offset=Variable "offset" is not available. ) at file.h:239 #18 0xffffffff805dc300 in kern_writev (td=0xffffff0004b2b720, fd=10, auio=0xffffff000f4d4100) at /usr/src/sys/kern/sys_generic.c:445 #19 0xffffffff805dc381 in writev (td=0xffffff0004b2b720, uap=0xffffff8040145c00) at /usr/src/sys/kern/sys_generic.c:431 #20 0xffffffff808624cf in syscall (frame=0xffffff8040145c90) at /usr/src/sys/amd64/amd64/trap.c:984 #21 0xffffffff808491a0 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #22 0x0000000800c5aacc in ?? () Previous frame inner to this frame (corrupt stack?) -- Kamigishi Rei KREI-RIPE From kamikaze at bsdforen.de Sun Jul 5 11:05:04 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sun Jul 5 11:05:15 2009 Subject: Selection using mouse aborts unexpectedly In-Reply-To: <20090703221810.GA31128@lizzy.catnook.local> References: <20090703221810.GA31128@lizzy.catnook.local> Message-ID: <4A508426.3010100@bsdforen.de> Jos Backus wrote: > Hi, > > For a few weeks now, when I drag my mouse over some text with the left button > pressed down, the selection will reproducibly abort after a second or so and > start re-selecting even though I never let go of the mouse button. This used > to work fine and is very annoying, to say the least. Sounds like your mouse button is worn out. Did you verify this with a different mouse? From mike at sentex.net Sun Jul 5 11:29:15 2009 From: mike at sentex.net (Mike Tancsa) Date: Sun Jul 5 11:29:21 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <4A504B0C.2060406@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> Message-ID: <200907051126.n65BQhie032549@lava.sentex.ca> At 02:41 AM 7/5/2009, Alexander Motin wrote: >>The drive we connected has some bad sectors, so I wanted to try a >>secure wipe as much as possible before RMAing the drive. I also >>thought it would be useful to test with the new driver how it handles bad disks >>Is this such an error ? >>Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is >>40000001 cs 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 > >This is AHCI driver debugging. I've removed it in latest patch. In >this case it means that drive signals some command error. Actually, looks like the box panic'd, but it seems to be elsewhere. After hitting the bad sectors for some time, g_vfs_done():ada2[WRITE(offset=6193152, length=14336)]error = 5 ahcich2: Timeout on slot 17 ahcich2: Timeout on slot 5 ahcich2: Timeout on slot 25 ahcich2: Timeout on slot 13 ahcich2: Timeout on slot 1 g_vfs_done():ada2[WRITE(offset=65536, length=2048)]error = 5 ahcich2: Timeout on slot 21 ahcich2: Timeout on slot 8 ahcich2: Timeout on slot 27 ahcich2: Timeout on slot 14 ahcich2: Timeout on slot 1 g_vfs_done():ada2[WRITE(offset=98304, length=16384)]error = 5 panic: softdep_move_dependencies: need merge code cpuid = 0 Uptime: 2h25m8s (ada2:ahcich2:0:0:0): Synchronize cache failed Physical memory: 3560 MB Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from /boot/kernel/ichwd.ko.symbols...done. done. Loaded symbols for /boot/kernel/ichwd.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc0812787 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc0812a79 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc0a354d4 in softdep_move_dependencies (oldbp=0xdaede7f0, newbp=0xdaec2c50) at /usr/src/sys/ufs/ffs/ffs_softdep.c:991 #4 0xc0a3d48e in ffs_backgroundwritedone (bp=0xdaede7f0) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1756 #5 0xc08854d7 in bufdone (bp=0xdaede7f0) at /usr/src/sys/kern/vfs_bio.c:3254 #6 0xc07b3765 in g_vfs_done (bip=0xc7d68c94) at /usr/src/sys/geom/geom_vfs.c:97 #7 0xc087faa9 in biodone (bp=0xc7d68c94) at /usr/src/sys/kern/vfs_bio.c:3095 #8 0xc07b0c0f in g_io_schedule_up (tp=0xc6e8f240) at /usr/src/sys/geom/geom_io.c:669 #9 0xc07b0fc8 in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95 #10 0xc07e8421 in fork_exit (callout=0xc07b0f60 , arg=0x0, frame=0xc6937d38) at /usr/src/sys/kern/kern_fork.c:842 #11 0xc0b180a0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 From bf1783 at googlemail.com Sun Jul 5 09:15:03 2009 From: bf1783 at googlemail.com (b. f.) Date: Sun Jul 5 12:29:55 2009 Subject: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) Message-ID: Alexander Motin wrote: >Harald Schmalzbauer wrote: >> I have a gournaled FS whoch lists it's consumer as ad12p6 >You mean gjournal has provider names hardcoded to it's meta data? It >could be a problem. If it detects it's parts freely, then it should not >notice the change. I just changed provider names for a gjournal'ed disk when my disks were reordered, and with the proper corresponding changes to fstab, there were no problems -- everything was mounted and loaded upon reboot without me having to make any other changes. However, if you used the "-h" option with "gjournal label" you may have to manually relabel. >> Otherwise I only use labels (ufs) for quiet some time, so I thought >> testing would be painless... >> Can I safely remove glabel from the unmounted fs and relabel the new >> device? >I don't very understand whet you mean by "safe"? Safe for what? He means, can he relabel the disks without losing any data on them? I think that the answer is yes, provided he doesn't do anything foolish -- like relabel an existing file system with journal and data on the same provider, while increasing the size of the journal, which would cause all data on the space allocated to the new journal to be lost. He may have to use the "-f" flag with "gjournal label", or issue "gjournal clear" before relabeling, and he may lose the last sector of the file system and anything on the journal, but that usually isn't of any consequence. In any event, unless he hardcoded his provider names, this probably isn't necessary. If it does prove to be necessary, it would be wise to back up any data just to be safe, and to experiment on a test provider first, before trying to relabel. b. From lwindschuh at googlemail.com Sun Jul 5 14:29:18 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Sun Jul 5 14:29:25 2009 Subject: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) In-Reply-To: <4A5053A8.2060902@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> Message-ID: <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> Hi Alexander. 2009/7/5 Alexander Motin : > It's never late. I have just uploaded fresh patch: > http://people.freebsd.org/~mav/cam-ata.20090704.patch "make buildworld" with this patch stops in my configuration with: (cd /usr/src/rescue/rescue/../../usr.sbin/chown && /usr/obj/usr/src/make.i386/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ depend && /usr/obj/usr/src/make.i386/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ chown.o) `chown.o' is up to date. cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo sconfig.lo fdisk.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -larchive -lcrypto -lm /usr/obj/usr/src/tmp/usr/lib/libcam.a(ata_all.o)(.text+0x263): In function `ata_max_mode': : undefined reference to `min' *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Simply adding #ifndef min #define min(a,b) (((a)<(b))?(a):(b)) #endif in ata_all.c helps, obviously. Regards, Lucius From mav at FreeBSD.org Sun Jul 5 15:14:03 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Jul 5 15:14:10 2009 Subject: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) In-Reply-To: <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> Message-ID: <4A50C331.3040505@FreeBSD.org> Lucius Windschuh wrote: > Hi Alexander. > > 2009/7/5 Alexander Motin : >> It's never late. I have just uploaded fresh patch: >> http://people.freebsd.org/~mav/cam-ata.20090704.patch > > "make buildworld" with this patch stops in my configuration with: > > /usr/obj/usr/src/tmp/usr/lib/libcam.a(ata_all.o)(.text+0x263): In > function `ata_max_mode': > : undefined reference to `min' > > Simply adding > #ifndef min > #define min(a,b) (((a)<(b))?(a):(b)) > #endif > in ata_all.c helps, obviously. Thanks. -- Alexander Motin From mike at sentex.net Sun Jul 5 16:24:55 2009 From: mike at sentex.net (Mike Tancsa) Date: Sun Jul 5 16:25:01 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <7.1.0.9.0.20090705072517.1b1f2338@sentex.net> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <7.1.0.9.0.20090705072517.1b1f2338@sentex.net> Message-ID: <200907051622.n65GMNWh034062@lava.sentex.ca> At 07:29 AM 7/5/2009, Mike Tancsa wrote: >At 02:41 AM 7/5/2009, Alexander Motin wrote: > >>>The drive we connected has some bad sectors, so I wanted to try a >>>secure wipe as much as possible before RMAing the drive. I also >>>thought it would be useful to test with the new driver how it handles bad disks >>>Is this such an error ? >>>Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is >>>40000001 cs 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 >> >>This is AHCI driver debugging. I've removed it in latest patch. In >>this case it means that drive signals some command error. > > >Actually, looks like the box panic'd, but it seems to be >elsewhere. After hitting the bad sectors for some time, Here is another with invariants compiled in. Again, this is writing to a disk that has bad sectors and is failing, so not sure if this is a case of "dont do that" ---Mike Synchronize cache failed Physical memory: 3556 MB Dumping 223 MB:ahcich2: ahci_ch_intr ERROR is 40000008 cs 00000000 ss 00010000 rs 00010000 tfd 441 serr 00000000 Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0xb68dc371 fault code = supervisor read, page not present ahcich2: Error while READ LOG EXT ahcich2: ahci_ch_intr ERROR is 40000008 cs 00000000 ss 00000400 rs 00000400 tfd 441 serr 00000000 ahcich2: ahci_ch_intr ERROR is 40000001 cs 00000800 ss 00000000 rs 00000800 tfd 471 serr 00000000 ahcich2: Error while READ LOG EXT ahcich2: ahci_ch_intr ERROR is 40000008 cs 00000000 ss 00001000 rs 00001000 tfd 441 serr 00000000 ahcich2: ahci_ch_intr ERROR is 40000001 cs 00002000 ss 00000000 rs 00002000 tfd 471 serr 00000000 ahcich2: Error while READ LOG EXT ahcich2: ahci_ch_intr ERROR is 40000008 cs 00000000 ss 00004000 rs 00004000 tfd 441 serr 00000000 panic: initiate_write_inodeblock_ufs2: already started cpuid = 6 Uptime: 1h13m8s ahcich2: ahci_ch_intr ERROR is 40000001 cs 00008000 ss 00000000 rs 00008000 tfd 471 serr 00000000 ahcich2: Error while READ LOG EXT (ada2:g_vfs_done():ahcich2:0:ada2[READ(offset=56068767744, length=16384)]0:error = 50): Synchronize cache failed Physical memory: 3556 MB Dumping 223 MB:ahcich2: ahci_ch_intr ERROR is 40000008 cs 00000000 ss 00010000 rs 00010000 tfd 441 serr 00000000 Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0xb68dc371 fault code = supervisor read, page not present instruction pointer = 0x20:0xc047f02b stack pointer = 0x28:0xc6e69bf0 frame pointer = 0x28:0xc6e69c08 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 = 12 (irq257: ahci0) trap number = 12 208 192 176 160 144 128 112 96 80 64 48 32 16 Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from /boot/kernel/ichwd.ko.symbols...done. done. Loaded symbols for /boot/kernel/ichwd.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc086c59e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc086c839 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc0a87a1e in softdep_disk_io_initiation (bp=0xdb115fe0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4056 #4 0xc0a8b98c in ffs_geom_strategy (bo=0xc810fc2c, bp=0xdb115fe0) at buf.h:404 #5 0xc08e1b79 in bufwrite (bp=0xdb115fe0) at buf.h:397 #6 0xc0a8b0bb in ffs_bufwrite (bp=0xdb115fe0) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1893 #7 0xc08ded28 in vfs_bio_awrite (bp=0xdb115fe0) at buf.h:385 #8 0xc08e851b in vop_stdfsync (ap=0xe77a8c7c) at /usr/src/sys/kern/vfs_default.c:608 #9 0xc07f31cc in devfs_fsync (ap=0xe77a8c7c) at /usr/src/sys/fs/devfs/devfs_vnops.c:556 #10 0xc0b8fb95 in VOP_FSYNC_APV (vop=0xc0d1a020, a=0xe77a8c7c) at vnode_if.c:1267 #11 0xc08f8308 in sync_vnode (slp=0xc76a27e4, bo=0xe77a8ce8, td=0xc78ad6c0) at vnode_if.h:549 #12 0xc08f8653 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1799 #13 0xc0843f78 in fork_exit (callout=0xc08f83e0 , arg=0x0, frame=0xe77a8d38) at /usr/src/sys/kern/kern_fork.c:842 #14 0xc0b677b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) From jos at catnook.com Sun Jul 5 17:02:03 2009 From: jos at catnook.com (Jos Backus) Date: Sun Jul 5 17:02:11 2009 Subject: Selection using mouse aborts unexpectedly In-Reply-To: <4A508426.3010100@bsdforen.de> References: <20090703221810.GA31128@lizzy.catnook.local> <4A508426.3010100@bsdforen.de> Message-ID: <20090705170225.GA24253@lizzy.catnook.local> On Sun, Jul 05, 2009 at 12:44:54PM +0200, Dominic Fandrey wrote: > Sounds like your mouse button is worn out. Did you verify this with a different > mouse? No, but I don't think I need to because selection works okay in an xterm. I.e. when I click-drag the left mouse button inside an xterm the selection stays active just fine as long as I hold down the mouse button. But when I go to some webpage inside Opera and try to select text, the selection aborts and starts reselecting right away. Same on the console. I could swear this used to work before. -- Jos Backus jos at catnook.com From dwmalone at maths.tcd.ie Sun Jul 5 20:24:45 2009 From: dwmalone at maths.tcd.ie (David Malone) Date: Sun Jul 5 20:24:53 2009 Subject: nice work on ntp.conf! In-Reply-To: <20090704232317.2D0991CC09@ptavv.es.net> References: <4A4E6EB4.9000000@phat.za.net> <20090704232317.2D0991CC09@ptavv.es.net> Message-ID: <20090705202441.GA4644@walton.maths.tcd.ie> On Sat, Jul 04, 2009 at 04:23:17PM -0700, Kevin Oberman wrote: > Really nice, although I feel uncomfortable about the use of LOCAL. It is > a great opportunity for foot shooting and, since most systems running > NTP are not used as serves, I think that it should be left commented > out in the default case. We're currently talking about this on -net. We'll probably also change the way we're using the pool, as the current file breaks the pool's advice to vendors. David. From tinderbox at freebsd.org Sun Jul 5 20:27:24 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Jul 5 20:27:36 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20090705202720.963057302F@freebsd-current.sentex.ca> TB --- 2009-07-05 18:43:25 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-05 18:43:25 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-07-05 18:43:25 - cleaning the object tree TB --- 2009-07-05 18:43:57 - cvsupping the source tree TB --- 2009-07-05 18:43:57 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-07-05 18:44:05 - building world TB --- 2009-07-05 18:44:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 18:44:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 18:44:05 - TARGET=powerpc TB --- 2009-07-05 18:44:05 - TARGET_ARCH=powerpc TB --- 2009-07-05 18:44:05 - TZ=UTC TB --- 2009-07-05 18:44:05 - __MAKE_CONF=/dev/null TB --- 2009-07-05 18:44:05 - cd /src TB --- 2009-07-05 18:44:05 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 5 18:44: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 Sun Jul 5 20:10:29 UTC 2009 TB --- 2009-07-05 20:10:29 - generating LINT kernel config TB --- 2009-07-05 20:10:29 - cd /src/sys/powerpc/conf TB --- 2009-07-05 20:10:29 - /usr/bin/make -B LINT TB --- 2009-07-05 20:10:30 - building LINT kernel TB --- 2009-07-05 20:10:30 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 20:10:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 20:10:30 - TARGET=powerpc TB --- 2009-07-05 20:10:30 - TARGET_ARCH=powerpc TB --- 2009-07-05 20:10:30 - TZ=UTC TB --- 2009-07-05 20:10:30 - __MAKE_CONF=/dev/null TB --- 2009-07-05 20:10:30 - cd /src TB --- 2009-07-05 20:10:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 5 20:10:30 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 [...] ieee80211_node.o(.text+0x38f0): In function `ieee80211_node_attach': : undefined reference to `ieee80211_ageq_init' ieee80211_node.o(.text+0x3bf4): In function `node_cleanup': : undefined reference to `ieee80211_ageq_drain_node' ieee80211_wds.o(.text+0x138): In function `ieee80211_dwds_discover': : undefined reference to `ieee80211_ageq_append' ieee80211_wds.o(.text+0x8a4): In function `wds_newstate': : undefined reference to `ieee80211_ageq_remove' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-05 20:27:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-05 20:27:20 - ERROR: failed to build lint kernel TB --- 2009-07-05 20:27:20 - 4969.61 user 438.16 system 6234.77 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Sun Jul 5 20:39:37 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Jul 5 20:39:44 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090705203932.D62DB7302F@freebsd-current.sentex.ca> TB --- 2009-07-05 18:59:07 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-05 18:59:07 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-07-05 18:59:07 - cleaning the object tree TB --- 2009-07-05 18:59:50 - cvsupping the source tree TB --- 2009-07-05 18:59:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-07-05 18:59:58 - building world TB --- 2009-07-05 18:59:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 18:59:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 18:59:58 - TARGET=sparc64 TB --- 2009-07-05 18:59:58 - TARGET_ARCH=sparc64 TB --- 2009-07-05 18:59:58 - TZ=UTC TB --- 2009-07-05 18:59:58 - __MAKE_CONF=/dev/null TB --- 2009-07-05 18:59:58 - cd /src TB --- 2009-07-05 18:59:58 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 5 18:59: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 >>> World build completed on Sun Jul 5 20:22:15 UTC 2009 TB --- 2009-07-05 20:22:15 - generating LINT kernel config TB --- 2009-07-05 20:22:15 - cd /src/sys/sparc64/conf TB --- 2009-07-05 20:22:15 - /usr/bin/make -B LINT TB --- 2009-07-05 20:22:15 - building LINT kernel TB --- 2009-07-05 20:22:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 20:22:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 20:22:15 - TARGET=sparc64 TB --- 2009-07-05 20:22:15 - TARGET_ARCH=sparc64 TB --- 2009-07-05 20:22:15 - TZ=UTC TB --- 2009-07-05 20:22:15 - __MAKE_CONF=/dev/null TB --- 2009-07-05 20:22:15 - cd /src TB --- 2009-07-05 20:22:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 5 20:22:16 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 [...] ieee80211_node.o(.text+0x3db8): In function `ieee80211_node_attach': : undefined reference to `ieee80211_ageq_init' ieee80211_node.o(.text+0x4214): In function `node_cleanup': : undefined reference to `ieee80211_ageq_drain_node' ieee80211_wds.o(.text+0x16c): In function `ieee80211_dwds_discover': : undefined reference to `ieee80211_ageq_append' ieee80211_wds.o(.text+0x8a8): In function `wds_newstate': : undefined reference to `ieee80211_ageq_remove' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-05 20:39:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-05 20:39:32 - ERROR: failed to build lint kernel TB --- 2009-07-05 20:39:32 - 4755.13 user 434.60 system 6024.88 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From hselasky at c2i.net Sun Jul 5 21:30:36 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Jul 5 21:30:44 2009 Subject: FreeBSD Kernel Panic during backup to USB external drive. In-Reply-To: <9072a4470907051118o6c14e19cs670981a500fc6375@mail.gmail.com> References: <9072a4470907051118o6c14e19cs670981a500fc6375@mail.gmail.com> Message-ID: <200907052330.07792.hselasky@c2i.net> On Sunday 05 July 2009 20:18:24 Robert Jameson wrote: > Hello everyone, recently i've been experience kernel panics whenever > attempting to run my backup to my usb external drive. > Here is the information i have, whatever else is needed please reply, thank > you. Hi, This issue doesn't look directly related to USB. I'm forwarding it to the freebsd-current e-mail list! Thanks for testing FreeBSD 8-current. --HPS > > > (02:11 PM):(root@cube)/var/crash$ kgdb /boot/kernel/kernel > /var/crash/vmcore.1 > 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: > panic: ffs_clusteralloc: map mismatch > cpuid = 1 > Uptime: 4d10h42m10s > Physical memory: 2546 MB > Dumping 249 MB: 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 > > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > Reading symbols from /boot/kernel/pflog.ko...Reading symbols from > /boot/kernel/pflog.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/pflog.ko > Reading symbols from /boot/kernel/pf.ko...Reading symbols from > /boot/kernel/pf.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/pf.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 > #0 doadump () at pcpu.h:196 > 196 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) quit > > > my backup script: > > #!/usr/local/bin/bash -x > # > # creates backups of essential files > # > DATA="/usr/home /root" > CONFIG="/etc /usr/local/etc /var/lib /etc/namedb" > LIST="/tmp/backlist_$$.txt" > # > mount /backup > set $(date) > # > if test "$1" = "Sun" ; then > # weekly a full backup of all data and config. settings: > # > tar cfz "/backup/data/data_full_$6-$2-$3.tgz" $DATA > rm -f /backup/data/data_diff* > # > tar cfz "/backup/config/config_full_$6-$2-$3.tgz" $CONFIG > rm -f /backup/config/config_diff* > else > # incremental backup: > # > find $DATA -depth -type f \( -ctime -1 -o -mtime -1 \) -print > > $LIST > tar cfzT "/backup/data/data_diff_$6-$2-$3.tgz" "$LIST" > rm -f "$LIST" > # > find $CONFIG -depth -type f \( -ctime -1 -o -mtime -1 \) -print > > $LIST > tar cfzT "/backup/config/config_diff_$6-$2-$3.tgz" "$LIST" > rm -f "$LIST" > fi > # > # create sql dump of databases: > mysqldump -u root --password=XXXXXXXXX --opt information_schema > > "/backup/database/information_schema_$6-$2-$3.sql" > gzip "/backup/database/information_schema_$6-$2-$3.sql" > mysqldump -u root --password=XXXXXXXXX --opt denora > > "/backup/database/denora_$6-$2-$3.sql" > gzip "/backup/database/denora_$6-$2-$3.sql" > mysqldump -u root --password=XXXXXXXXX --opt evilnet > > "/backup/database/evilnet_$6-$2-$3.sql" > gzip "/backup/database/evilnet_$6-$2-$3.sql" > mysqldump -u root --password=XXXXXXXXX --opt mysql > > "/backup/database/mysql_$6-$2-$3.sql" > gzip "/backup/database/mysql_$6-$2-$3.sql" > mysqldump -u root --password=XXXXXXXXX --opt quotes_db > > "/backup/database/quotes_db_$6-$2-$3.sql" > gzip "/backup/database/quotes_db_$6-$2-$3.sql" > > # > umount /backup > > > fstab: > > # Device Mountpoint FStype Options Dump > Pass# > /dev/ad0s1b none swap sw 0 0 > /dev/ad0s1a / ufs rw 1 1 > /dev/ad1s1d /usr/home ufs rw 1 1 > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > /dev/da0s1d /backup ufs rw,noauto 1 1 From tinderbox at freebsd.org Sun Jul 5 21:57:11 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Jul 5 21:57:18 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090705215708.1AB1C7302F@freebsd-current.sentex.ca> TB --- 2009-07-05 20:27:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-05 20:27:20 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-07-05 20:27:20 - cleaning the object tree TB --- 2009-07-05 20:27:48 - cvsupping the source tree TB --- 2009-07-05 20:27:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-07-05 20:27:57 - building world TB --- 2009-07-05 20:27:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 20:27:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 20:27:57 - TARGET=sun4v TB --- 2009-07-05 20:27:57 - TARGET_ARCH=sparc64 TB --- 2009-07-05 20:27:57 - TZ=UTC TB --- 2009-07-05 20:27:57 - __MAKE_CONF=/dev/null TB --- 2009-07-05 20:27:57 - cd /src TB --- 2009-07-05 20:27:57 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 5 20:27:58 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 Jul 5 21:41:32 UTC 2009 TB --- 2009-07-05 21:41:32 - generating LINT kernel config TB --- 2009-07-05 21:41:32 - cd /src/sys/sun4v/conf TB --- 2009-07-05 21:41:32 - /usr/bin/make -B LINT TB --- 2009-07-05 21:41:32 - building LINT kernel TB --- 2009-07-05 21:41:32 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 21:41:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 21:41:32 - TARGET=sun4v TB --- 2009-07-05 21:41:32 - TARGET_ARCH=sparc64 TB --- 2009-07-05 21:41:32 - TZ=UTC TB --- 2009-07-05 21:41:32 - __MAKE_CONF=/dev/null TB --- 2009-07-05 21:41:32 - cd /src TB --- 2009-07-05 21:41:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 5 21:41: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 [...] ieee80211_node.o(.text+0x3db8): In function `ieee80211_node_attach': : undefined reference to `ieee80211_ageq_init' ieee80211_node.o(.text+0x4214): In function `node_cleanup': : undefined reference to `ieee80211_ageq_drain_node' ieee80211_wds.o(.text+0x16c): In function `ieee80211_dwds_discover': : undefined reference to `ieee80211_ageq_append' ieee80211_wds.o(.text+0x8a8): In function `wds_newstate': : undefined reference to `ieee80211_ageq_remove' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-05 21:57:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-05 21:57:08 - ERROR: failed to build lint kernel TB --- 2009-07-05 21:57:08 - 4695.66 user 428.96 system 5387.30 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From bryanv at daemoninthecloset.org Sun Jul 5 23:33:50 2009 From: bryanv at daemoninthecloset.org (Bryan Venteicher) Date: Sun Jul 5 23:33:57 2009 Subject: Selection using mouse aborts unexpectedly In-Reply-To: <1028722209.151246835679099.JavaMail.root@bayleaf> Message-ID: <1590020694.171246835811926.JavaMail.root@bayleaf> ----- "Jos Backus" wrote: > On Sun, Jul 05, 2009 at 12:44:54PM +0200, Dominic Fandrey wrote: > > Sounds like your mouse button is worn out. Did you verify this with > a different > > mouse? > > No, but I don't think I need to because selection works okay in an > xterm. I.e. > when I click-drag the left mouse button inside an xterm the selection > stays > active just fine as long as I hold down the mouse button. But when I > go to > some webpage inside Opera and try to select text, the selection aborts > and > starts reselecting right away. Same on the console. I could swear this > used to > work before. A Microsoft mouse of mine had similar behavior. The mouse is probably sending spurious up events. There's a flag for this in the ums driver: UMS_FLAG_SBU. Try or'ing that to sc_flag at attach time. > -- > Jos Backus > jos at catnook.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 jos at catnook.com Sun Jul 5 23:42:16 2009 From: jos at catnook.com (Jos Backus) Date: Sun Jul 5 23:42:24 2009 Subject: Selection using mouse aborts unexpectedly In-Reply-To: <1590020694.171246835811926.JavaMail.root@bayleaf> References: <1028722209.151246835679099.JavaMail.root@bayleaf> <1590020694.171246835811926.JavaMail.root@bayleaf> Message-ID: <20090705234238.GA1448@lizzy.catnook.local> On Sun, Jul 05, 2009 at 06:16:51PM -0500, Bryan Venteicher wrote: > A Microsoft mouse of mine had similar behavior. The mouse is probably > sending spurious up events. There's a flag for this in the ums driver: > UMS_FLAG_SBU. Try or'ing that to sc_flag at attach time. Thanks Bryan, that change makes it mostly usable again. So basically it's time to go look for a new mouse? Or does it make sense to add a quirk for this mouse? -- Jos Backus jos at catnook.com From cavac at magicbooks.org Mon Jul 6 07:23:01 2009 From: cavac at magicbooks.org (Rene Schickbauer) Date: Mon Jul 6 07:23:08 2009 Subject: RFC: powerd Patch & proposed future changes Message-ID: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> Hi! Yesterday i submitted a patch for powerd to set maximum allowed CPU speed for adaptive modes (to keep the system cool and using less power). PR: 136354 Would it also make sense to have powerd run an (optional) user configureable script on ac state change? I'm thinking about things like dimming TFT backlight, on EEE PC turning of the webcam and so on. Another option that could make sense in powerd is checking the battery state and running a user configureable script when ac-state is set to battery and battery falls below a configured threshold. The script could do a number of things like warning the user, scheduling a shutdown and so on in order to give the user a fair chance to save his/her work and do a clean shutdown (or just plugin the ac adapter). powerd currently only adjusts CPU speed, but having a *second* programm monitor the same kernel variables to work on another part of the same problem does not seem to make sense. BTW, i'm also thinking of having the option to have powerd log the battery status (ac mode + load + charge level) every 5 Minutes or so to syslog. That way, a second script (log parser) may be able to determine information about the battery - like how long does it take to charge, rough capacity estimation and possible degradation of battery. Just throwing ideas... LLAP & LG Rene -- Hackerkey: http://tinyurl.com/pof37z From gergely.czuczy at harmless.hu Mon Jul 6 08:18:47 2009 From: gergely.czuczy at harmless.hu (Gergely CZUCZY) Date: Mon Jul 6 08:18:55 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> Message-ID: <20090706100602.00003969@unknown> Hello, I think this is a very nice idea, especially the TFT backlight part. It also might be useful to adjust the WiFi transmit power level according to battery state. That can also save some power, especially on portables. On Mon, 6 Jul 2009 09:22:58 +0200 (CEST) "Rene Schickbauer" wrote: > Hi! > > Yesterday i submitted a patch for powerd to set maximum allowed CPU > speed for adaptive modes (to keep the system cool and using less > power). > > PR: 136354 > > Would it also make sense to have powerd run an (optional) user > configureable script on ac state change? I'm thinking about things > like dimming TFT backlight, on EEE PC turning of the webcam and so on. > > Another option that could make sense in powerd is checking the > battery state and running a user configureable script when ac-state > is set to battery and battery falls below a configured threshold. The > script could do a number of things like warning the user, scheduling > a shutdown and so on in order to give the user a fair chance to save > his/her work and do a clean shutdown (or just plugin the ac adapter). > > powerd currently only adjusts CPU speed, but having a *second* > programm monitor the same kernel variables to work on another part of > the same problem does not seem to make sense. > > BTW, i'm also thinking of having the option to have powerd log the > battery status (ac mode + load + charge level) every 5 Minutes or so > to syslog. That way, a second script (log parser) may be able to > determine information about the battery - like how long does it take > to charge, rough capacity estimation and possible degradation of > battery. > > Just throwing ideas... > > LLAP & LG > Rene -- Sincerely, Gergely CZUCZY Harmless Digital Bt +36-30-9702963 From patfbsd at davenulle.org Mon Jul 6 08:36:06 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Mon Jul 6 08:36:13 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> Message-ID: <20090706103602.394c463a@baby-jane.lamaiziere.net> Le Mon, 6 Jul 2009 09:22:58 +0200 (CEST), "Rene Schickbauer" a ?crit : > Hi! Hello, > Yesterday i submitted a patch for powerd to set maximum allowed CPU > speed for adaptive modes (to keep the system cool and using less > power). > > PR: 136354 I would like an option to set the minimum allowed CPU speed, instead the use of the sysctl debug.cpufreq.lowest. > Would it also make sense to have powerd run an (optional) user > configureable script on ac state change? I'm thinking about things > like dimming TFT backlight, on EEE PC turning of the webcam and so on. We can do this with devd. (my 0.42 euro) From cavac at magicbooks.org Mon Jul 6 08:56:20 2009 From: cavac at magicbooks.org (Rene Schickbauer) Date: Mon Jul 6 08:56:27 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <20090706100602.00003969@unknown> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706100602.00003969@unknown> Message-ID: <12908.213.150.228.38.1246870577.squirrel@mail.magicbooks.org> Hi! > I think this is a very nice idea, especially the TFT backlight part. It > also might be useful to adjust the WiFi transmit power level according > to battery state. That can also save some power, especially on > portables. Yes, changing the transmit power would be possible. Although adjusting the transmit power via script on a *mobile* computer is likely to get the user offline rather quickly. On the other hand, powerd would just run a script. This script could start a user-written daemon to continually adjust power level.. and when ac is plugged in again, the script kills that daemon. I sincerely doubt that would save you any amount of power worth mentioning, though but may give you additional troubles. But maybe you could restrict an a/b/g card to b/g or a and thus save some power. Some laptops let you power down the normal (cabled) network adapter. When your out of reach for AC power, you're very unlikely lugging a network cable around the building. Also, you may power down/unload inbuild audio, webcam, bluetooth, modem, serial port etc. If you're desperate, disallowing CDROM and SWAP operation may save you a ton of power, too. As i said, with user scripting triggered by powerd state changes, you could get *really* creative (like temporarly halting any mencoder and ffmpeg process while on battery power ;-). LLAP & LG Rene Schickbauer -- Hackerkey: http://tinyurl.com/pof37z From cavac at magicbooks.org Mon Jul 6 09:03:32 2009 From: cavac at magicbooks.org (Rene Schickbauer) Date: Mon Jul 6 09:03:40 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <20090706103602.394c463a@baby-jane.lamaiziere.net> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706103602.394c463a@baby-jane.lamaiziere.net> Message-ID: <37078.213.150.228.38.1246871005.squirrel@mail.magicbooks.org> Hi! >> Yesterday i submitted a patch for powerd to set maximum allowed CPU >> speed for adaptive modes (to keep the system cool and using less >> power). >> >> PR: 136354 > > I would like an option to set the minimum allowed CPU speed, instead > the use of the sysctl debug.cpufreq.lowest. This is so that powerd doesn't take so long to spin up power in the adaptive modes? Never thought of that, but makes sense to me. i will adapt the patch. >> Would it also make sense to have powerd run an (optional) user >> configureable script on ac state change? I'm thinking about things >> like dimming TFT backlight, on EEE PC turning of the webcam and so on. > > We can do this with devd. I'm not really familiar with devd. Could you give me a pointer how that would work? LLAP & LG Rene Schickbauer -- Hackerkey: http://tinyurl.com/pof37z From raj at semihalf.com Mon Jul 6 09:39:31 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Mon Jul 6 09:39:40 2009 Subject: MD5 test slowdown In-Reply-To: <20090703082040.GN2884@deviant.kiev.zoral.com.ua> References: <200907030204.51415.max@love2party.net> <20090703082040.GN2884@deviant.kiev.zoral.com.ua> Message-ID: On 2009-07-03, at 10:20, Kostik Belousov wrote: > On Fri, Jul 03, 2009 at 02:04:50AM +0200, Max Laier wrote: >> On Thursday 02 July 2009 13:32:08 Rafal Jaworowski wrote: >>> I'm observing some heavy slowdown seen with md5 test on PowerPC: >>> >>> 1. On the MPC8572 machine with today's HEAD I'm getting: >>> >>> # md5 -t >>> MD5 time trial. Digesting 100000 10000-byte blocks ... done >>> Digest = 766a2bb5d24bddae466c572bcabca3ee >>> Time = 36.930565 seconds >>> Speed = 27077842.000000 bytes/second >>> >>> 2. While a couple of months back it yielded 6x shorter times on this >>> very same hardware, like this one: >>> >>> # md5 -t >>> MD5 time trial. Digesting 100000 10000-byte blocks ... done >>> Digest = 766a2bb5d24bddae466c572bcabca3ee >>> Time = 6.027277 seconds >>> Speed = 165912400.000000 bytes/second >>> >>> Timers work fine, the slowdown is real. I don't know if this is >>> PowerPC related, and was wondering if anybody observed something >>> similar on other archs perhaps? Any suggestions what could be >>> causing >>> this or where to look? I cannot see immediate suspects in the arch/ >>> platform code. >> >> "signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64" to this >> mailing list >> reports something that might be related. It seems there is a patch >> available, but not committed yet. Though I'm not sure about the >> nature of >> the problem exactly. Jeff? > > I want to make some points clear to avoid a confusion and spread of > FUD. > It seems we have at least three issues, all different: > 1. Syscalls slowdown on amd64. To see this, you need to microbenchmark > syscall enter/leave sequence. I doubt that it can be seen on any > load except while (1) {getpid();} loops or such. The issue is valid > _only_ for amd64. > I developed the patch with the input from Jeff who confirmed that > this slowdown is solved by the change. > 2. There are enough independent reports of i/o slowdown to believe > that > some problem is real; but we have not seen numbers or detailed > configurations or (most desirable) the revision after which the > slowdown started. Note the i/o part. > > This report is for PPC (right ?) and for workload that is purely > CPU-bounded. After additional testing my slowdown looks more like a PowerPC (E500 only) issue: nwhitehorn@ checked his G4 (AIM) system and could not observe this, so it seems something local to E500. Rafal From rea-fbsd at codelabs.ru Mon Jul 6 09:43:10 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Jul 6 09:43:19 2009 Subject: pebkac, but is it a mergemaster bug? In-Reply-To: References: Message-ID: Ian, Doug, *, good day. Sun, Jul 05, 2009 at 12:07:18PM +0200, Ian Freislich wrote: > Due to not paying attention my ntp.conf on several of my time servers > was updated (and broken) by mergemaster. I had the automatic update > options set for files that I had not modified. My ntp.conf had no > VCS id and the files differed, obviously. What happened is the following: when mergemaster does automated upgrades, it consults the existing mtree database in /var/db/mergemaster.mtree that carries information about the state of the files created when the temproot was populated. When you start mergemaster, it will use the saved database from the previous run, so when you was hit the ntp.conf issue, that file was not in the mtree database yet. When mergemaster determines the list of changed files for auto-upgrade ($CHANGED), it just runs mtree against the current contents of the DESTDIR and looks for the 'changed' lines. Mtree is invoked with '-e', so it won't pay attention to the files that are present in the file hierarchy (your own /etc/ntp.conf), but not in the specification (remember, mtree database is from the previous run, so ntp.conf isn't there yet). And when a decision on the file's auto-upgrade is done, the following sequence is invoked: - mm checks that both source and destination files are present (your case); - mm checks that the destination file name isn't in the ${CHANGED} list (it isn't, as explained in the previous paragraph). So, it's how your ntp.conf ended up overwritten (if I am catching mm's logics well). > Was mergemaster correct in its assesment that this file was a > candidate for automatic installation? I'd say, "No it was mistaken". Basically, there should be a way to determine new files that were added to the tree since the last mergemaster run. And there is a way: ----- mtree -f ${MTREENEW} -f ${MTREEFILE} | \ awk '/^[^[:space:]]/ && $2 == "file" { print $1; }' ----- So, we should additionally check if the auto-installed files are present in the list produced by the latter command and refuse to copy them over. Doug, I am going to implement this stuff. May be I am overseeing something and there are another ways to overcome this problem? Will you commit such an extension to the mergemaster? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From patfbsd at davenulle.org Mon Jul 6 09:47:45 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Mon Jul 6 09:47:53 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <37078.213.150.228.38.1246871005.squirrel@mail.magicbooks.org> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706103602.394c463a@baby-jane.lamaiziere.net> <37078.213.150.228.38.1246871005.squirrel@mail.magicbooks.org> Message-ID: <20090706114742.4bd52252@baby-jane.lamaiziere.net> Le Mon, 6 Jul 2009 11:03:25 +0200 (CEST), "Rene Schickbauer" a ?crit : > Hi! > > >> Yesterday i submitted a patch for powerd to set maximum allowed CPU > >> speed for adaptive modes (to keep the system cool and using less > >> power). > >> > >> PR: 136354 > > > > I would like an option to set the minimum allowed CPU speed, instead > > the use of the sysctl debug.cpufreq.lowest. > > This is so that powerd doesn't take so long to spin up power in the > adaptive modes? If the speed is too low, my machine is not very interactive here (running KDE and all...). And with ndis if the speed is to low, my laptop hangs (on FreeBSD 7.2) > Never thought of that, but makes sense to me. i will adapt the patch. > > >> Would it also make sense to have powerd run an (optional) user > >> configureable script on ac state change? I'm thinking about things > >> like dimming TFT backlight, on EEE PC turning of the webcam and so > >> on. > > > > We can do this with devd. > > I'm not really familiar with devd. Could you give me a pointer how > that would work? See devd.conf, On ac state change a script is called (power_profile). # cat /var/run/devd.pipe (unplug) !system=ACPI subsystem=ACAD type=\_SB_.ADP1 notify=0x00 !system=ACPI subsystem=CMBAT type=\_SB_.BAT0 notify=0x80 (plug) !system=ACPI subsystem=ACAD type=\_SB_.ADP1 notify=0x01 !system=ACPI subsystem=CMBAT type=\_SB_.BAT0 notify=0x80 From dalroi at solfertje.student.utwente.nl Mon Jul 6 10:01:12 2009 From: dalroi at solfertje.student.utwente.nl (Alban Hertroys) Date: Mon Jul 6 10:01:19 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> Message-ID: <2A58225C-B4F9-40E5-8AFE-D169F391B4C2@solfertje.student.utwente.nl> On Jul 6, 2009, at 9:22 AM, Rene Schickbauer wrote: > BTW, i'm also thinking of having the option to have powerd log the > battery > status (ac mode + load + charge level) every 5 Minutes or so to > syslog. That > way, a second script (log parser) may be able to determine > information about > the battery - like how long does it take to charge, rough capacity > estimation and possible degradation of battery. Currently some similar information is available through sysctl's (cpu load + temperature for example). To me that seems to be a bit more flexible as a means of providing such information about battery status (you don't depend on a 5 minute interval in a log-file) and probably easier to read (programmatically) than parsing a file. And it doesn't need writing to a file-system that's trying to safe power while being carried around with the system off AC. OTOH, a sysctl doesn't keep a history of past events while a log-file does; you could write something that parsed an existing log-file to determine battery life expectations immediately (provided the log-file wasn't rotated too recent) while reading sysctl's would need some time to collect enough statistics. Just an idea. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:909,4a51cb65759151706116102! From cavac at magicbooks.org Mon Jul 6 10:56:33 2009 From: cavac at magicbooks.org (Rene Schickbauer) Date: Mon Jul 6 10:57:55 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <2A58225C-B4F9-40E5-8AFE-D169F391B4C2@solfertje.student.utwente.nl> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <2A58225C-B4F9-40E5-8AFE-D169F391B4C2@solfertje.student.utwente.nl> Message-ID: <34809.213.150.228.38.1246877791.squirrel@mail.magicbooks.org> Hi! > And it doesn't need writing to a file-system that's trying to > safe power while being carried around with the system off AC. You're right, that would be a bit stupid. Heisenberg at work, it seems. Point taken. LLAP & LG Rene Schickbauer -- Hackerkey: http://tinyurl.com/pof37z From ed at 80386.nl Mon Jul 6 11:08:54 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Jul 6 11:11:07 2009 Subject: pebkac, but is it a mergemaster bug? In-Reply-To: References: Message-ID: <20090706110852.GD48776@hoeg.nl> Hi Eygene, * Eygene Ryabinkin wrote: > Doug, I am going to implement this stuff. May be I am overseeing > something and there are another ways to overcome this problem? Will > you commit such an extension to the mergemaster? While you're hacking on mergemaster, could you please change mergemaster to install files when the files are exactly the same, except for the $FreeBSD$ string? It makes switching to different CVS/SVN branches of the FreeBSD source tree a lot harder. ;-) -- Ed Schouten WWW: http://80386.nl/ -------------- 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/20090706/d76d1a8c/attachment.pgp From rdivacky at freebsd.org Mon Jul 6 11:12:52 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Jul 6 11:13:01 2009 Subject: pebkac, but is it a mergemaster bug? In-Reply-To: <20090706110852.GD48776@hoeg.nl> References: <20090706110852.GD48776@hoeg.nl> Message-ID: <20090706111107.GA19818@freebsd.org> On Mon, Jul 06, 2009 at 01:08:52PM +0200, Ed Schouten wrote: > Hi Eygene, > > * Eygene Ryabinkin wrote: > > Doug, I am going to implement this stuff. May be I am overseeing > > something and there are another ways to overcome this problem? Will > > you commit such an extension to the mergemaster? > > While you're hacking on mergemaster, could you please change mergemaster > to install files when the files are exactly the same, except for the > $FreeBSD$ string? It makes switching to different CVS/SVN branches of > the FreeBSD source tree a lot harder. ;-) there's mergemaster -F From ed at 80386.nl Mon Jul 6 11:14:13 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Jul 6 11:14:22 2009 Subject: pebkac, but is it a mergemaster bug? In-Reply-To: <20090706111107.GA19818@freebsd.org> References: <20090706110852.GD48776@hoeg.nl> <20090706111107.GA19818@freebsd.org> Message-ID: <20090706111403.GE48776@hoeg.nl> * Roman Divacky wrote: > On Mon, Jul 06, 2009 at 01:08:52PM +0200, Ed Schouten wrote: > > Hi Eygene, > > > > * Eygene Ryabinkin wrote: > > > Doug, I am going to implement this stuff. May be I am overseeing > > > something and there are another ways to overcome this problem? Will > > > you commit such an extension to the mergemaster? > > > > While you're hacking on mergemaster, could you please change mergemaster > > to install files when the files are exactly the same, except for the > > $FreeBSD$ string? It makes switching to different CVS/SVN branches of > > the FreeBSD source tree a lot harder. ;-) > > there's mergemaster -F Ooh. Thanks! I just ran `mergemaster -U' and hoped it would do the right thing. I think it would be expected behaviour if -U implied -F... -- Ed Schouten WWW: http://80386.nl/ -------------- 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/20090706/e81db4f2/attachment.pgp From ianf at clue.co.za Mon Jul 6 11:18:08 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Mon Jul 6 11:18:16 2009 Subject: pebkac, but is it a mergemaster bug? In-Reply-To: <20090706110852.GD48776@hoeg.nl> References: <20090706110852.GD48776@hoeg.nl> Message-ID: Ed Schouten wrote: > * Eygene Ryabinkin wrote: > > Doug, I am going to implement this stuff. May be I am overseeing > > something and there are another ways to overcome this problem? Will > > you commit such an extension to the mergemaster? > > While you're hacking on mergemaster, could you please change mergemaster > to install files when the files are exactly the same, except for the > $FreeBSD$ string? It makes switching to different CVS/SVN branches of > the FreeBSD source tree a lot harder. ;-) I believe that the '-F' option does this. Ian -- Ian Freislich From rea-fbsd at codelabs.ru Mon Jul 6 11:31:08 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Jul 6 11:31:15 2009 Subject: pebkac, but is it a mergemaster bug? In-Reply-To: <20090706110852.GD48776@hoeg.nl> References: <20090706110852.GD48776@hoeg.nl> Message-ID: Ed, good day. Mon, Jul 06, 2009 at 01:08:52PM +0200, Ed Schouten wrote: > While you're hacking on mergemaster, could you please change mergemaster > to install files when the files are exactly the same, except for the > $FreeBSD$ string? It makes switching to different CVS/SVN branches of > the FreeBSD source tree a lot harder. ;-) It's 'mergemaster -F'. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From doconnor at gsoft.com.au Mon Jul 6 11:36:32 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon Jul 6 11:36:38 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> Message-ID: <200907062137.52621.doconnor@gsoft.com.au> On Mon, 6 Jul 2009, Rene Schickbauer wrote: > Would it also make sense to have powerd run an (optional) user > configureable script on ac state change? I'm thinking about things > like dimming TFT backlight, on EEE PC turning of the webcam and so > on. devd can already do this.. Create a file for /usr/local/etc/devd (doesn't matter what it's called) with this in it.. notify 10 { match "system" "ACPI"; action "/usr/local/bin/acpi-ev $system $subsystem $type $notify"; }; The script will be called with "ACPI ACAD _SB_.AC__ 0x00" on power failure and "ACPI ACAD _SB_.AC__ 0x01" when connected. (It is easy to call logger $0 $* in your script to check various events out.. -- 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/20090706/1d416b93/attachment.pgp From ertr1013 at student.uu.se Mon Jul 6 11:38:32 2009 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Mon Jul 6 11:38:39 2009 Subject: pebkac, but is it a mergemaster bug? In-Reply-To: <20090706110852.GD48776@hoeg.nl> References: <20090706110852.GD48776@hoeg.nl> Message-ID: <20090706111501.GA59991@owl.midgard.homeip.net> On Mon, Jul 06, 2009 at 01:08:52PM +0200, Ed Schouten wrote: > Hi Eygene, > > * Eygene Ryabinkin wrote: > > Doug, I am going to implement this stuff. May be I am overseeing > > something and there are another ways to overcome this problem? Will > > you commit such an extension to the mergemaster? > > While you're hacking on mergemaster, could you please change mergemaster > to install files when the files are exactly the same, except for the > $FreeBSD$ string? It makes switching to different CVS/SVN branches of > the FreeBSD source tree a lot harder. ;-) Isn't that exactly what the '-F' flag for mergemaster already does? -- Erik Trulsson ertr1013@student.uu.se From cavac at magicbooks.org Mon Jul 6 12:11:17 2009 From: cavac at magicbooks.org (Rene Schickbauer) Date: Mon Jul 6 12:11:24 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <200907062137.52621.doconnor@gsoft.com.au> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <200907062137.52621.doconnor@gsoft.com.au> Message-ID: <34960.213.150.228.38.1246882274.squirrel@mail.magicbooks.org> Hi! >> Would it also make sense to have powerd run an (optional) user >> configureable script on ac state change? I'm thinking about things >> like dimming TFT backlight, on EEE PC turning of the webcam and so >> on. > > devd can already do this.. [...] Wow, thanks. You just made my day! Its really astonishing what FreeBSD is capable of. Maybe it's finally time to kill OSX on my MacMini and install FreeBSD... uh, still need to get my DisplayLink adapter supported - one Monitor is *not* enough ;-) LLAP & LG Rene -- Hackerkey: http://tinyurl.com/pof37z From aragon at phat.za.net Mon Jul 6 12:53:46 2009 From: aragon at phat.za.net (Aragon Gouveia) Date: Mon Jul 6 12:53:52 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> Message-ID: <4A51F3D3.5000304@phat.za.net> Hi, Rene Schickbauer wrote: > Yesterday i submitted a patch for powerd to set maximum allowed CPU speed > for adaptive modes (to keep the system cool and using less power). Thank you for your work. > Would it also make sense to have powerd run an (optional) user configureable > script on ac state change? I'm thinking about things like dimming TFT > backlight, on EEE PC turning of the webcam and so on. No. As pointed out, devd(8) does this already. > Another option that could make sense in powerd is checking the battery state > and running a user configureable script when ac-state is set to battery and > battery falls below a configured threshold. The script could do a number of > things like warning the user, scheduling a shutdown and so on in order to > give the user a fair chance to save his/her work and do a clean shutdown (or > just plugin the ac adapter). As for the notification script at low capacity, in theory devd(8) should be able to do this as well. A notebook ought to generate a battery event when capacity hits its factory set "warning" and "low" marks. Of course I say this without having tested it on mine. :) > powerd currently only adjusts CPU speed, but having a *second* programm > monitor the same kernel variables to work on another part of the same > problem does not seem to make sense. > > BTW, i'm also thinking of having the option to have powerd log the battery > status (ac mode + load + charge level) every 5 Minutes or so to syslog. That > way, a second script (log parser) may be able to determine information about > the battery - like how long does it take to charge, rough capacity > estimation and possible degradation of battery. Seems unnecessary. That information is already available with acpiconf(8) and via sysctl(8) (see hw.acpi.acline, hw.acpi.battery), so someone is able to write their own logger if they wish. IMHO, I think powerd should be kept doing only work that's most useful. As I've experienced with power saving, the moment you start doing more and more work to save power, you also end up consuming more power. Keep it simple. Regards, Aragon From aragon at phat.za.net Mon Jul 6 12:55:39 2009 From: aragon at phat.za.net (Aragon Gouveia) Date: Mon Jul 6 12:55:45 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <12908.213.150.228.38.1246870577.squirrel@mail.magicbooks.org> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706100602.00003969@unknown> <12908.213.150.228.38.1246870577.squirrel@mail.magicbooks.org> Message-ID: <4A51F444.7050803@phat.za.net> Rene Schickbauer wrote: > Hi! > >> I think this is a very nice idea, especially the TFT backlight part. It >> also might be useful to adjust the WiFi transmit power level according >> to battery state. That can also save some power, especially on >> portables. > > Yes, changing the transmit power would be possible. Although adjusting the > transmit power via script on a *mobile* computer is likely to get the user > offline rather quickly. > > On the other hand, powerd would just run a script. This script could start a > user-written daemon to continually adjust power level.. and when ac is > plugged in again, the script kills that daemon. I sincerely doubt that would > save you any amount of power worth mentioning, though but may give you > additional troubles. But maybe you could restrict an a/b/g card to b/g or a > and thus save some power. FWIW, changing transmit power on my Intel 4965 based system made zero difference to overall power consumption. Regards, Aragon From aragon at phat.za.net Mon Jul 6 13:04:57 2009 From: aragon at phat.za.net (Aragon Gouveia) Date: Mon Jul 6 13:05:04 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <20090706114742.4bd52252@baby-jane.lamaiziere.net> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706103602.394c463a@baby-jane.lamaiziere.net> <37078.213.150.228.38.1246871005.squirrel@mail.magicbooks.org> <20090706114742.4bd52252@baby-jane.lamaiziere.net> Message-ID: <4A51F673.5010007@phat.za.net> Hi, Patrick Lamaiziere wrote: >>> I would like an option to set the minimum allowed CPU speed, instead >>> the use of the sysctl debug.cpufreq.lowest. >> This is so that powerd doesn't take so long to spin up power in the >> adaptive modes? > > If the speed is too low, my machine is not very interactive here > (running KDE and all...). Have you tried disabling throttling (P4TCC)? Add these to your loader.conf: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 When you reboot you'll notice a lot of frequencies missing from dev.cpu.0.freq_levels. The remaining ones are those affected by EIST only. The difference? EIST controls CPU frequency *and* voltage. Throttling controls only frequency, and is much less effective at saving power (while being very effective at slowing your system down). If you disable throttling and use just EIST, your system will be much more responsive at a very small power cost. The power cost above can be made up by setting C-state to C2 or even C3. If you're running FreeBSD 8, another way of saving a lot of power on a notebook is to power down USB devices. Most notebooks' webcams and fingerprint readers are internally connected to the USB bus. Alexander Motin did a lot of testing a while ago. Take a look at this thread: http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006436.html Regards, Aragon From Krasznai.Andras at mands.hu Mon Jul 6 07:12:02 2009 From: Krasznai.Andras at mands.hu (=?ISO-8859-1?Q?M=26S_-_Krasznai_Andr=E1s?=) Date: Mon Jul 6 14:11:13 2009 Subject: k3b and mkisofs problems on freebsd-current Message-ID: <402C2D9299C36C4BB1C89C5E3539706E5C6012@pdc.mands.hu> Good morning! Since I upgraded my laptop to freebsd-8 k3b freezes after displaying the splash screen. Earlier I used freebsd-7.2 stable. If I start k3b from a terminal window it gives back the terminal prompt after the splash screen is displayed, and the GUI does not start. The k3b process remains in memory, together with mkisofs. There are as many mkisofs processes as many times I started k3b. k3b can be killed with pkill k3b, but the mkisofs can not. Starting mkisofs from the command line works perfectly. If I move mkisofs out of the search path then k3b can be started, and I could copy a CD with it. I reinstalled k3b, cdrtools, I recompiled k3b with all its dependencies, but there was no success. I refreshed the sources last time on Friday, and recompiled k3b and cdrtools again but it is still not working correctly. Did anybody experience such problems with k3b? rgds Krasznai Andras From patfbsd at davenulle.org Mon Jul 6 14:12:02 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Mon Jul 6 14:12:10 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <200907051039.19584.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907040945.41153.hselasky@c2i.net> <20090704164341.0acd0271@baby-jane.lamaiziere.net> <200907051039.19584.hselasky@c2i.net> Message-ID: <20090706161154.06abb3cd@baby-jane.lamaiziere.net> Le Sun, 5 Jul 2009 10:39:18 +0200, Hans Petter Selasky a ?crit : > Can you try the attached patch for 8-current. > Please provide ulpt > debug prints in either failing or succeeding case. Thanks a lot. I've commented the ulpt_reset(sc) in urlpt_open() because it does not work at all with it and I have to use unlpt. But no luck. I'm still using cups because I have to figure how I can get the PCL file sent to the printer. I'm using /dev/urlpt. ulpt0: on usbus0 ulpt_attach:610: setting alternate config number: 0 ulpt0: using bi-directional mode ulpt_write_callback:237: state=0x0 actlen=0 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=16384 last message repeated 12 times ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8173 ulpt_write_callback:237: state=0x0 actlen=8173 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_status_callback:369: error=USB_ERR_STALLED ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_write_callback:237: state=0x1 actlen=14989 ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x0 actlen=14989 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_write_callback:237: state=0x1 actlen=1563 ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x0 actlen=1563 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x0 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=8192 ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 last message repeated 2 times ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 last message repeated 2 times ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 last message repeated 2 times ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_write_callback:237: state=0x1 actlen=16384 last message repeated 2 times ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 last message repeated 5 times ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 last message repeated 2 times ulpt_status_callback:369: error=USB_ERR_IOERROR ulpt_write_callback:237: state=0x1 actlen=16384 ulpt_write_callback:237: state=0x1 actlen=4836 ulpt_status_callback:369: error=USB_ERR_IOERROR last message repeated 31 times last message repeated 121 times last message repeated 544 times ... Shall I setup another box with current to be sure that's a problem with the printer and not with the hardware? Regards. From hselasky at c2i.net Mon Jul 6 15:51:04 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jul 6 15:51:11 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <20090706161154.06abb3cd@baby-jane.lamaiziere.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907051039.19584.hselasky@c2i.net> <20090706161154.06abb3cd@baby-jane.lamaiziere.net> Message-ID: <200907061750.39084.hselasky@c2i.net> On Monday 06 July 2009 16:11:54 Patrick Lamaiziere wrote: > Le Sun, 5 Jul 2009 10:39:18 +0200, > > Hans Petter Selasky a ?crit : > > Can you try the attached patch for 8-current. > > Please provide ulpt > > debug prints in either failing or succeeding case. > > Thanks a lot. > I've commented the ulpt_reset(sc) in urlpt_open() because it does not work > at all with it and I have to use unlpt. > > But no luck. I'm still using cups because I have to figure how I can get > the PCL file sent to the printer. I'm using /dev/urlpt. > > ulpt0: on > usbus0 ulpt_attach:610: setting alternate config number: 0 > ulpt0: using bi-directional mode > ulpt_write_callback:237: state=0x0 actlen=0 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=16384 > last message repeated 12 times > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8173 > ulpt_write_callback:237: state=0x0 actlen=8173 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_status_callback:369: error=USB_ERR_STALLED > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_write_callback:237: state=0x1 actlen=14989 > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x0 actlen=14989 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_write_callback:237: state=0x1 actlen=1563 > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x0 actlen=1563 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x0 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=8192 > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > last message repeated 2 times > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > last message repeated 2 times > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > last message repeated 2 times > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_write_callback:237: state=0x1 actlen=16384 > last message repeated 2 times > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > last message repeated 5 times > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > last message repeated 2 times > ulpt_status_callback:369: error=USB_ERR_IOERROR > ulpt_write_callback:237: state=0x1 actlen=16384 > ulpt_write_callback:237: state=0x1 actlen=4836 > ulpt_status_callback:369: error=USB_ERR_IOERROR > last message repeated 31 times > last message repeated 121 times > last message repeated 544 times > ... > > Shall I setup another box with current to be sure that's a problem > with the printer and not with the hardware? Hi, urlpt was just for backwards compatibility. Could you try printing using /dev/unlpt0 ? And send me resulting dmesg? Power cycle your printer before testing. --HPS From gary.jennejohn at freenet.de Mon Jul 6 17:27:37 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Mon Jul 6 17:27:45 2009 Subject: k3b and mkisofs problems on freebsd-current In-Reply-To: <402C2D9299C36C4BB1C89C5E3539706E5C6012@pdc.mands.hu> References: <402C2D9299C36C4BB1C89C5E3539706E5C6012@pdc.mands.hu> Message-ID: <20090706192732.4e23f53a@ernst.jennejohn.org> On Mon, 6 Jul 2009 08:59:54 +0200 M&S - Krasznai Andr__s wrote: > Good morning! > > Since I upgraded my laptop to freebsd-8 k3b freezes after displaying the splash screen. Earlier I used freebsd-7.2 stable. > > If I start k3b from a terminal window it gives back the terminal prompt after the splash screen is displayed, and the GUI does not start. The k3b process remains in memory, together with mkisofs. There are as many mkisofs processes as many times I started k3b. k3b can be killed with pkill k3b, but the mkisofs can not. Starting mkisofs from the command line works perfectly. > > If I move mkisofs out of the search path then k3b can be started, and I could copy a CD with it. > > I reinstalled k3b, cdrtools, I recompiled k3b with all its dependencies, but there was no success. > > > I refreshed the sources last time on Friday, and recompiled k3b and cdrtools again but it is still not working correctly. > > > Did anybody experience such problems with k3b? > Yes, I've been seeing this for months. I ditched k3b and started using tkdvd. Much smaller and doesn't require all that KDE stuff. --- Gary Jennejohn From sam at freebsd.org Mon Jul 6 17:31:21 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Jul 6 17:31:27 2009 Subject: RFC: powerd Patch & proposed future changes [wifi tx power] In-Reply-To: <4A51F444.7050803@phat.za.net> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706100602.00003969@unknown> <12908.213.150.228.38.1246870577.squirrel@mail.magicbooks.org> <4A51F444.7050803@phat.za.net> Message-ID: <4A5234E6.2000900@freebsd.org> Aragon Gouveia wrote: > Rene Schickbauer wrote: >> Hi! >> >>> I think this is a very nice idea, especially the TFT backlight part. It >>> also might be useful to adjust the WiFi transmit power level according >>> to battery state. That can also save some power, especially on >>> portables. >> >> Yes, changing the transmit power would be possible. Although >> adjusting the >> transmit power via script on a *mobile* computer is likely to get the >> user >> offline rather quickly. >> >> On the other hand, powerd would just run a script. This script could >> start a >> user-written daemon to continually adjust power level.. and when ac is >> plugged in again, the script kills that daemon. I sincerely doubt >> that would >> save you any amount of power worth mentioning, though but may give you >> additional troubles. But maybe you could restrict an a/b/g card to >> b/g or a >> and thus save some power. > > FWIW, changing transmit power on my Intel 4965 based system made zero > difference to overall power consumption. Changing the tx power is unlikely to save you much. What you want to do is switch between sta mode power save when you switch between AC and battery and/or change the PS parameters depending on the power config and battery level. I don't recall if iwn is hooked up properly to ifconfig to control power save operation. FWIW wifi tx power control (TPC) is best used to avoid saturating the rx radio when in close proximity. It's also good to reduce the power so you don't splatter adjacent channels (mostly in 2.4GHz). Some devices do this automatically. Sam From james-freebsd-current at jrv.org Mon Jul 6 18:21:05 2009 From: james-freebsd-current at jrv.org (James R. Van Artsdalen) Date: Mon Jul 6 18:21:12 2009 Subject: ahci: wait for !BSY fails Message-ID: <4A52407B.1040009@jrv.org> Quick synopsis: 1. The CAM AHCI driver fails for me every time detecting disks waiting for !BSY. The ATA driver works every time in the same configuration. The option ROM for the eSATA card ID's the drive correctly every time. 2. Both a WD 1TB and a Seagate 2TB fail/work the same way. 3. The system under test is a Via VB8001 with Via Nano (Isaiah) CPU in amd64 mode. 8.0-CURRENT svn 195136 June 28, 2009 with cam-ata.20090704.patch (other patch versions and -CURRENT revs tried too) 4. The AHCI adapter is a JMicron JMB363-based Syba SD-PEX-JM1A2E card: this one http://www.newegg.com/Product/Product.aspx?Item=N82E16816124022 The option ROM does not support RAID and there is no option ROM menu. 5, I've spent a couple of days looking at the code and putting in debugging to trace the I/Os and I can't find the problem. The old ATA and new CAM AHCI drivers are doing the same thing except for some timing differences, and eliminating those timing differences doesn't seem to help. Without the AHCI cam-ata.20090704.patch the disk is seen: atapci0: port 0xac00-0xac07,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9c00-0x9c0f mem 0xdfbfe000-0xdfbfffff irq 24 at device 0.0 on pci2 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x9c00 ioapic1: routing intpin 0 (PCI IRQ 24) to lapic 0 vector 49 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xdfbfe000 atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.00 controller with 2 3Gbps ports, PM supported atapci0: Caps: 64bit NCQ ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd 2ports ata2: on atapci0 ata2: AHCI reset... ata2: hardware reset ... ata2: SATA connect time=0ms status=00000113 ata2: ready wait time=12ms ata2: software reset port 15... ata2: ready wait time=0ms ata2: SIGNATURE: 00000101 ata2: AHCI reset done: devices=00000001 ata2: [MPSAFE] ata2: [ITHREAD] ... ata2: Identifying devices: 00000001 ata2: New devices: 00000001 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 953869MB at ata2-master SATA150 ad4: 1953525168 sectors [1938021C/16H/63S] 16 sectors/interrupt 1 depth queue uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered GEOM: new disk ad4 ad4: JMicron check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed But with the AHCI cam-ata.20090704.patch there is an error: (note that I increased the !BSY timeout to no avail here) ahci0: port 0xac00-0xac07,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9c00-0x9c0f mem 0xdfbfe000-0xdfbfffff irq 24 at device 0.0 on pci2 ahci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xdfbfe000 ioapic1: routing intpin 0 (PCI IRQ 24) to lapic 0 vector 49 ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.00 controller with 2 3Gbps ports, PM supported ahci0: Caps: 64bit NCQ ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd 2ports ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ... ahcich0: AHCI reset... ahcich0: hardware reset ... ahcich0: SATA connect time=0ms status=00000113 ahcich0: port is not ready (timeout 30000ms) tfd = 000000ff ahcich0: device ready timeout ahcich0: AHCI reset done: devices=00000001 ... ahcich0: Poll error on slot 1, TFD: 0077 (probe0:ahcich0:0:15:0): Request completed with CAM_ATA_STATUS_ERROR (probe0:ahcich0:0:15:0): error 5 (probe0:ahcich0:0:15:0): Retries Exhausted ahcich0: Poll error on slot 2, TFD: 0077 (probe0:ahcich0:0:0:0): Request completed with CAM_ATA_STATUS_ERROR (probe0:ahcich0:0:0:0): error 5 (probe0:ahcich0:0:0:0): Retries Exhausted From patfbsd at davenulle.org Mon Jul 6 18:39:34 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Mon Jul 6 18:39:41 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <200907061750.39084.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907051039.19584.hselasky@c2i.net> <20090706161154.06abb3cd@baby-jane.lamaiziere.net> <200907061750.39084.hselasky@c2i.net> Message-ID: <20090706203930.7b0f1f20@baby-jane.lamaiziere.net> Le Mon, 6 Jul 2009 17:50:37 +0200, Hans Petter Selasky a ?crit : > urlpt was just for backwards compatibility. Ah ok! > Could you try printing using /dev/unlpt0 ? And send me resulting > dmesg? > > Power cycle your printer before testing. It looks better, I still have some USB_ERR_IOERROR. But I was able to print 4 times the same document: It's long, please see http://user.lamaiziere.net/patrick/ulpt-debug1.txt I notice that there is always an error ulpt_status_callback:369: error=USB_ERR_STALLED before an USB_ERR_IOERROR. Thanks. From dougb at FreeBSD.org Mon Jul 6 19:05:39 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jul 6 19:05:46 2009 Subject: pebkac, but is it a mergemaster bug? In-Reply-To: References: Message-ID: <4A524AE2.2020902@FreeBSD.org> Eygene Ryabinkin wrote: >> Was mergemaster correct in its assesment that this file was a >> candidate for automatic installation? > > I'd say, "No it was mistaken". Overall I tend to agree with you, however I'll use this as yet another reminder that my resistance to making mergemaster more "automatic" by default has a solid basis. > Basically, there should be a way to > determine new files that were added to the tree since the last > mergemaster run. And there is a way: > ----- > mtree -f ${MTREENEW} -f ${MTREEFILE} | \ > awk '/^[^[:space:]]/ && $2 == "file" { print $1; }' > ----- > So, we should additionally check if auto-installed files are present > in the list produced by the latter command and refuse to copy them > over. This situation with ntp.conf is the first time I remember that we've ever added an example config file to the base that the user is likely to have already in /etc (as opposed to /usr/local/etc which is where user-originated stuff usually goes). So I'm not sure that this feature as described is the most efficient way to solve the problem. We just had a thread on this topic recently where I suggested that the proper solution is to teach mtree to issue a list of files that have _not_ changed and have mergemaster depend on that list instead of getting the list of things that have changed and assuming that anything not on that list is safe to replace. Alternatively, if you really want to work on a patch that is for mergemaster only you could get the list of files that have changed, and parse the existing mtree db file against that list to generate a list of files that have not changed. > Doug, I am going to implement this stuff. Maybe I am overseeing > something and there are another ways to overcome this problem? Will > you commit such an extension to the mergemaster? I currently lack the time to do the mtree stuff, but I will gladly make the change to mergemaster if someone else can implement it. hth, Doug From nox at jelal.kn-bremen.de Mon Jul 6 21:20:03 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Mon Jul 6 21:20:12 2009 Subject: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) In-Reply-To: <4A50C331.3040505@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> Message-ID: <200907062116.n66LGk5t013830@triton.kn-bremen.de> In article <4A50C331.3040505@FreeBSD.org> you write: >Lucius Windschuh wrote: >> Hi Alexander. >> >> 2009/7/5 Alexander Motin : >>> It's never late. I have just uploaded fresh patch: >>> http://people.freebsd.org/~mav/cam-ata.20090704.patch >> >> "make buildworld" with this patch stops in my configuration with: >> >> /usr/obj/usr/src/tmp/usr/lib/libcam.a(ata_all.o)(.text+0x263): In >> function `ata_max_mode': >> : undefined reference to `min' >> >> Simply adding >> #ifndef min >> #define min(a,b) (((a)<(b))?(a):(b)) >> #endif >> in ata_all.c helps, obviously. > >Thanks. I tried this on the box with that optical drive that head no longer likes (fails to be probed and generates an irq storm, see http://docs.freebsd.org/cgi/mid.cgi?20090628101656.GA38983 ), and with ahci.ko loaded by loader.conf I got timeouts followed by a panic: http://people.freebsd.org/~nox/cam-ata.20090704-panic1.jpg http://people.freebsd.org/~nox/cam-ata.20090704-panic2.jpg The panic seems to be in cam_periph_lock: (kgdb) l *(cdioctl+0x4e) 0xffffffff801a937e is in cdioctl (cam_periph.h:183). 178 u_int32_t sense_flags, union ccb *save_ccb); 179 180 static __inline void 181 cam_periph_lock(struct cam_periph *periph) 182 { 183 mtx_lock(periph->sim->mtx); 184 } 185 186 static __inline void 187 cam_periph_unlock(struct cam_periph *periph) (kgdb) Without ahci.ko loaded it boots, but the original problems remain, here is the dmesg from that 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 #0: Mon Jul 6 21:22:05 CEST 2009 nox@triton.kn-bremen.de:/usr/obj/usr/home/nox/src8camata/src/sys/TRITON8 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81025000. module_register: module probe already exists! Module probe failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2812820279 Hz CPU: AMD Phenom(tm) II X4 920 Processor (2812.82-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant L1 2MB data TLB: 48 entries, fully associative L1 2MB instruction TLB: 16 entries, fully associative L1 4KB data TLB: 48 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB data TLB: 128 entries, 2-way associative L2 2MB instruction TLB: 0 entries, 2-way associative L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 9395240960 (8960 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x000000000104f000 - 0x00000000cfddffff, 3470331904 bytes (847249 pages) 0x0000000100000000 - 0x0000000220a2ffff, 4842520576 bytes (1182256 pages) avail memory = 8270852096 (7887 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf6fe0 00014 (v0 GBT ) ACPI: RSDT 0xcfde3000 0003C (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: FACP 0xcfde3040 00074 (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: DSDT 0xcfde30c0 05E2B (v1 GBT GBTUACPI 00001000 MSFT 03000000) ACPI: FACS 0xcfde0000 00040 ACPI: SSDT 0xcfde8fc0 0088C (v1 PTLTD POWERNOW 00000001 LTP 00000001) ACPI: HPET 0xcfde9880 00038 (v1 GBT GBTUACPI 42302E31 GBTU 00000098) ACPI: MCFG 0xcfde98c0 0003C (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: TAMG 0xcfde9900 00302 (v1 GBT GBT B0 5455312E BG\^A\^A 53450101) ACPI: APIC 0xcfde8f00 00084 (v1 GBT GBTUACPI 42302E31 GBTU 01010101) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 wlan: <802.11 Link Layer> random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jul 6 2009 21:21:34) acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff8000012000 pa 0x4000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SACS -> bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.BAR1 -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SMB0.HETT -> bus 0 dev 20 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfce0000 (3) failed ACPI timer: 1/2 1/2 1/1 1/2 1/1 1/1 1/1 1/2 1/2 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x4353 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1002, dev=0x5957, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[1c]: type Memory, range 64, base 0xe0000000, size 29, enabled found-> vendor=0x1002, dev=0x5978, revid=0x00 domain=0, bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x597d, revid=0x00 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.7.INTA pcib0: slot 7 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x597f, revid=0x00 domain=0, bus=0, slot=10, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.10.INTA pcib0: slot 10 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4391, revid=0x00 domain=0, bus=0, slot=17, func=0 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xff00, size 3, enabled map[14]: type I/O Port, range 32, base 0xfe00, size 2, enabled map[18]: type I/O Port, range 32, base 0xfd00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xfc00, size 2, enabled map[20]: type I/O Port, range 32, base 0xfb00, size 4, enabled map[24]: type Memory, range 32, base 0xfe02f000, size 10, enabled pcib0: matched entry for 0.17.INTA pcib0: slot 17 INTA hardwired to IRQ 22 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=18, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 map[10]: type Memory, range 32, base 0xfe02e000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=18, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 map[10]: type Memory, range 32, base 0xfe02d000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=18, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02c000, size 8, enabled pcib0: matched entry for 0.18.INTB pcib0: slot 18 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type Memory, range 32, base 0xfe02b000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type Memory, range 32, base 0xfe02a000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe029000, size 8, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4385, revid=0x3a domain=0, bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0403, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x439c, revid=0x00 domain=0, bus=0, slot=20, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 MSI supports 1 message map[20]: type I/O Port, range 32, base 0xfa00, size 4, enabled found-> vendor=0x1002, dev=0x4383, revid=0x00 domain=0, bus=0, slot=20, func=2 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0410, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xfe024000, size 14, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x439d, revid=0x00 domain=0, bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4384, revid=0x00 domain=0, bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0027, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4399, revid=0x00 domain=0, bus=0, slot=20, func=5 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 map[10]: type Memory, range 32, base 0xfe028000, size 12, enabled pcib0: matched entry for 0.20.INTC pcib0: slot 20 INTC hardwired to IRQ 18 found-> vendor=0x1022, dev=0x1200, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1201, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1202, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1203, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1204, revid=0x00 domain=0, bus=0, slot=24, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: irq 18 at device 2.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfde00000-0xfdefffff pcib1: prefetched decode 0xd0000000-0xdfffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x9498, revid=0x00 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib1: requested memory range 0xd0000000-0xdfffffff: good map[18]: type Memory, range 64, base 0xfdee0000, size 16, enabled pcib1: requested memory range 0xfdee0000-0xfdeeffff: good map[20]: type I/O Port, range 32, base 0xee00, size 8, enabled pcib1: requested I/O range 0xee00-0xeeff: in range pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0xaa38, revid=0x00 domain=0, bus=1, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfdefc000, size 14, enabled pcib1: requested memory range 0xfdefc000-0xfdefffff: good pcib1: matched entry for 1.0.INTB pcib1: slot 0 INTB hardwired to IRQ 19 vgapci0: port 0xee00-0xeeff mem 0xd0000000-0xdfffffff,0xfdee0000-0xfdeeffff irq 18 at device 0.0 on pci1 pci1: at device 0.1 (no driver attached) pcib2: irq 19 at device 7.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfdd00000-0xfddfffff pcib2: prefetched decode 0xfdc00000-0xfdcfffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x10b9, revid=0x06 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfdde0000, size 17, enabled pcib2: requested memory range 0xfdde0000-0xfddfffff: good map[14]: type Memory, range 32, base 0xfddc0000, size 17, enabled pcib2: requested memory range 0xfddc0000-0xfdddffff: good map[18]: type I/O Port, range 32, base 0xdf00, size 5, enabled pcib2: requested I/O range 0xdf00-0xdf1f: in range pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 em0: port 0xdf00-0xdf1f mem 0xfdde0000-0xfddfffff,0xfddc0000-0xfdddffff irq 19 at device 0.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfdde0000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1b:21:34:ef:46 pcib3: irq 18 at device 10.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfda00000-0xfdafffff pcib3: prefetched decode 0xfdf00000-0xfdffffff pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xce00, size 8, enabled pcib3: requested I/O range 0xce00-0xceff: in range map[18]: type Prefetchable Memory, range 64, base 0xfdfff000, size 12, enabled pcib3: requested memory range 0xfdfff000-0xfdffffff: good map[20]: type Prefetchable Memory, range 64, base 0xfdfe0000, size 16, enabled pcib3: requested memory range 0xfdfe0000-0xfdfeffff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 18 re0: port 0xce00-0xceff mem 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 18 at device 0.0 on pci3 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfdfff000 re0: MSI count : 2 re0: attempting to allocate 1 MSI vectors (2 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 50 re0: using IRQ 257 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:1f:d0:d7:4c:1b re0: [MPSAFE] re0: [FILTER] atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfb00 atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe02f000 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 51 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 6 3Gbps ports, PM supported atapci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd CCC 6ports ata2: on atapci0 ata2: AHCI reset... ata2: hardware reset ... ata2: SATA connect time=0ms status=00000123 ata2: ready wait time=23ms ata2: software reset port 15... ata2: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata2: port is not ready (timeout 0ms) tfd = 000001d0 ata2: software reset clear timeout ata2: software reset port 0... ata2: ready wait time=0ms ata2: SIGNATURE: 00000101 ata2: AHCI reset done: devices=00000001 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: AHCI reset... ata3: hardware reset ... ata3: SATA connect time=10ms status=00000113 ata3: ready wait time=183ms ata3: software reset port 15... ata3: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata3: port is not ready (timeout 0ms) tfd = 00000180 ata3: software reset clear timeout ata3: software reset port 0... ata3: ready wait time=0ms ata3: SIGNATURE: eb140101 ata3: AHCI reset done: devices=00010000 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 ata4: AHCI reset... ata4: hardware reset ... ata4: SATA connect time=0ms status=00000123 ata4: ready wait time=16ms ata4: software reset port 15... ata4: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata4: port is not ready (timeout 0ms) tfd = 000001d0 ata4: software reset clear timeout ata4: software reset port 0... ata4: ready wait time=0ms ata4: SIGNATURE: 00000101 ata4: AHCI reset done: devices=00000001 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci0 ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: [MPSAFE] ata5: [ITHREAD] ata6: on atapci0 ata6: AHCI reset... ata6: hardware reset ... ata6: SATA connect timeout status=00000000 ata6: AHCI reset done: phy reset found no device ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci0 ata7: AHCI reset... ata7: hardware reset ... ata7: SATA connect timeout status=00000000 ata7: AHCI reset done: phy reset found no device ata7: [MPSAFE] ata7: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02e000 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 52 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02d000 ohci1: [MPSAFE] ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe02c000 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 53 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at device 19.0 on pci0 ohci2: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02b000 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 54 ohci2: [MPSAFE] ohci2: [ITHREAD] usbus3: on ohci2 ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 ohci3: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 ohci3: [MPSAFE] ohci3: [ITHREAD] usbus4: on ohci3 ehci1: mem 0xfe029000-0xfe0290ff irq 19 at device 19.2 on pci0 ehci1: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe029000 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 55 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfa00 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=7f ostat1=7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 56 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 57 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xb000-0xbfff pcib4: memory decode 0xf8000000-0xfcffffff pcib4: prefetched decode 0xfdb00000-0xfdbfffff pcib4: Subtractively decoded bridge. pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x14f1, dev=0x8800, revid=0x05 domain=0, bus=4, slot=6, func=0 class=04-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x14 (5000 ns), maxlat=0x37 (13750 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf9000000, size 24, enabled pcib4: requested memory range 0xf9000000-0xf9ffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8811, revid=0x05 domain=0, bus=4, slot=6, func=1 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf8000000, size 24, enabled pcib4: requested memory range 0xf8000000-0xf8ffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8802, revid=0x05 domain=0, bus=4, slot=6, func=2 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x06 (1500 ns), maxlat=0x58 (22000 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfb000000, size 24, enabled pcib4: requested memory range 0xfb000000-0xfbffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8804, revid=0x05 domain=0, bus=4, slot=6, func=4 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfa000000, size 24, enabled pcib4: requested memory range 0xfa000000-0xfaffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x104c, dev=0x8024, revid=0x00 domain=0, bus=4, slot=14, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfcfff000, size 11, enabled pcib4: requested memory range 0xfcfff000-0xfcfff7ff: good map[14]: type Memory, range 32, base 0xfcff8000, size 14, enabled pcib4: requested memory range 0xfcff8000-0xfcffbfff: good pcib4: matched entry for 4.14.INTA pcib4: slot 14 INTA hardwired to IRQ 22 pci4: at device 6.0 (no driver attached) pci4: at device 6.1 (no driver attached) pci4: at device 6.2 (no driver attached) pci4: at device 6.4 (no driver attached) fwohci0: mem 0xfcfff000-0xfcfff7ff,0xfcff8000-0xfcffbfff irq 22 at device 14.0 on pci4 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfcfff000 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:ef:de:f8:00:00:1f:d0 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xcfdd8000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:ef:de:00:1f:d0 fwe0: bpf attached fwe0: Ethernet address: 02:ef:de:00:1f:d0 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:ef:de:f8:00:00:1f:d0 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 ohci4: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe028000 ohci4: [MPSAFE] ohci4: [ITHREAD] usbus6: on ohci4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 58 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 59 uart0: [FILTER] uart0: fast interrupt psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 60 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 61 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 atrtc0: port 0x70-0x73 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) cpu0: on acpi0 cpu0: switching to generic Cx mode hwpstate0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 ex_isa_identify() ahc_isa_probe 0: ioport 0xc00 alloc failed isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 uart2: not probed (disabled) uart3: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 513579 -> 100000 procfs registered lapic: Divisor 2, Frequency 100457873 hz Timecounter "TSC" frequency 2812820279 Hz quality -100 Timecounters tick every 1.000 msec pfsync0: bpf attached lo0: bpf attached pflog0: bpf attached ata5: CONNECT requested firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 hptrr: no controller detected. ata0: Identifying devices: 00000000 ata0: New devices: 00000000 ata1: Identifying devices: 00000000 ata1: New devices: 00000000 ata2: Identifying devices: 00000001 ata2: New devices: 00000001 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: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... 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 uhub6: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ataata5: DISCONNECT requested 5: reinit done .. ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 953868MB at ata2-master SATA300 ad4: 1953523055 sectors [1938018C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: Silicon Image check3 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed GEOM: ad4s2: geometry does not match label (255h,63s != 16h,63s). ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3: Identifying devices: 00010000 ata3: New devices: 00010000 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire ata3: device_reset timeout=120us acd0: DVDR drive at ata3 as master acd0: read 6890KB/s (6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata4: Identifying devices: 00000001 ata4: New devices: 00000001 uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 953869MB at ata4-master SATA300 ad8: 1953525168 sectors [1938021C/16H/63S] 16 sectors/interrupt 1 depth queue ad8: Silicon Image check3 failed ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LSI (v2) check1 failed ad8: FreeBSD check1 failed ata5: Identifying devices: 00000000 ata5: New devices: 00000000 ata6: Identifying devices: 00000000 ata6: New devices: 00000000 ata7: Identifying devices: 00000000 ata7: New devices: 00000000 GEOM: new disk ad8 GEOM: ad8: partition 1 does not start on a track boundary. GEOM: ad8: partition 1 does not end on a track boundary. GEOM: ad8s3: geometry does not match label (255h,63s != 16h,63s). ugen1.2: at usbus1 (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ATA PseudoRAID loaded SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 1 vector 48 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 2 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 1 vector 49 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 2 vector 49 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 3 vector 49 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 50 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 2 vector 50 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 3 vector 50 msi: Assigning MSI IRQ 257 to local APIC 1 vector 51 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ufsid/49bca1defbad5bce ct_to_ts([2009-07-06 21:47:17]) = 1246916837.000000000 start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done ..ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... lock order reversal: 1st 0xffffffff80c0ffe0 pf task mtx (pf task mtx) @ /usr/home/nox/src8camata/src/sys/contrib/pf/net/pf_ioctl.c:1394 2nd 0xffffffff80e09240 ifnet (ifnet) @ /usr/home/nox/src8camata/src/sys/net/if.c:1887 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _rw_rlock() at _rw_rlock+0x5f ifunit() at ifunit+0x22 pfioctl() at pfioctl+0x1f6d devfs_ioctl_f() at devfs_ioctl_f+0x76 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80098798c, rsp = 0x7fffffffb568, rbp = 0x7fffffffb6c0 --- tun0: bpf attached altq: emulate 256000000Hz cpu clock WARNING: attempt to net_add_domain(netgraph) after domainfinalize() ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. From mike at sentex.net Mon Jul 6 21:20:49 2009 From: mike at sentex.net (Mike Tancsa) Date: Mon Jul 6 21:20:59 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <4A504B0C.2060406@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> Message-ID: <200907062118.n66LIGRg043316@lava.sentex.ca> At 02:41 AM 7/5/2009, Alexander Motin wrote: >>Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is >>40000001 cs 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 > >This is AHCI driver debugging. I've removed it in latest patch. In >this case it means that drive signals some command error. Hi, With the latest patch (cam-ata.20090704.patch), writing to the disk with physical errors looks like this now Jul 6 13:56:17 ich10 last message repeated 4 times Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42003431424, length=16384)]error = 5 Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:17 ich10 last message repeated 4 times Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42196107264, length=16384)]error = 5 Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:17 ich10 last message repeated 4 times Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42388783104, length=16384)]error = 5 Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:17 ich10 last message repeated 4 times Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42581458944, length=16384)]error = 5 Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:17 ich10 last message repeated 4 times Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42774134784, length=16384)]error = 5 Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:18 ich10 last message repeated 4 times Jul 6 13:56:18 ich10 kernel: g_vfs_done():ada2[READ(offset=42966810624, length=16384)]error = 5 Jul 6 13:56:18 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:18 ich10 last message repeated 4 times Still the box does a panic when writing to the disk that has bad sectors on it. (I do newfs it between reboots). Again, not sure if this is a "well, dont use a bad disk", but here is the panic again in case it shows something useful. Unread portion of the kernel message buffer: ahcich2: Error while READ LOG EXT ahcich2: Error while READ LOG EXT g_vfs_done():ada2s1d[READ(offset=36418928640, length=16384)]error = 5 ahcich2: Error while READ LOG EXT ahcich2: Error while READ LOG EXT ahcich2: Error while READ LOG EXT panic: initiate_write_inodeblock_ufs2: already started cpuid = 6 Uptime: 5m55s ahcich2: Error while READ LOG EXT (ada2:ahcich2:0:0:0): Synchronize cache failed Physical memory: 3556 MB Dumping 220 MB: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0xb0014 fault code = supervisor read, page not present instruction pointer = 0x20:0xc047f14b stack pointer = 0x28:0xc6e69c08 frame pointer = 0x28:0xc6e69c20 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 = 12 (irq257: ahci0) trap number = 12 205 189 173 157 141 125 109 93 77 61 45 29 13 Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc086ca3e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc086ccd9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc0a87ebe in softdep_disk_io_initiation (bp=0xdb2bbf60) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4056 #4 0xc0a8be2c in ffs_geom_strategy (bo=0xc803c2c0, bp=0xdb2bbf60) at buf.h:404 #5 0xc08e2019 in bufwrite (bp=0xdb2bbf60) at buf.h:397 #6 0xc0a8b55b in ffs_bufwrite (bp=0xdb2bbf60) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1893 #7 0xc08df1c8 in vfs_bio_awrite (bp=0xdb2bbf60) at buf.h:385 #8 0xc08e89bb in vop_stdfsync (ap=0xe7798c7c) at /usr/src/sys/kern/vfs_default.c:608 #9 0xc07f366c in devfs_fsync (ap=0xe7798c7c) at /usr/src/sys/fs/devfs/devfs_vnops.c:556 #10 0xc0b90095 in VOP_FSYNC_APV (vop=0xc0d1a580, a=0xe7798c7c) at vnode_if.c:1267 #11 0xc08f87a8 in sync_vnode (slp=0xc76a27f4, bo=0xe7798ce8, td=0xc78ad6c0) at vnode_if.h:549 #12 0xc08f8af3 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1799 #13 0xc0844418 in fork_exit (callout=0xc08f8880 , arg=0x0, frame=0xe7798d38) at /usr/src/sys/kern/kern_fork.c:842 #14 0xc0b67cb0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) Unless you would like me to test some other features of the driver, I will just RMA the drive tomorrow. ---Mike From scottl at samsco.org Mon Jul 6 21:25:02 2009 From: scottl at samsco.org (Scott Long) Date: Mon Jul 6 21:25:09 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <200907062118.n66LIGRg043316@lava.sentex.ca> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <200907062118.n66LIGRg043316@lava.sentex.ca> Message-ID: <20090706152351.S26418@pooker.samsco.org> On Mon, 6 Jul 2009, Mike Tancsa wrote: > At 02:41 AM 7/5/2009, Alexander Motin wrote: >>> Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is 40000001 cs >>> 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 >> >> This is AHCI driver debugging. I've removed it in latest patch. In this >> case it means that drive signals some command error. > > > Hi, > > With the latest patch (cam-ata.20090704.patch), writing to the disk with > physical errors looks like this now > > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42003431424, > length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42196107264, > length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42388783104, > length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42581458944, > length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42774134784, > length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:18 ich10 last message repeated 4 times > Jul 6 13:56:18 ich10 kernel: g_vfs_done():ada2[READ(offset=42966810624, > length=16384)]error = 5 > Jul 6 13:56:18 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:18 ich10 last message repeated 4 times > > Still the box does a panic when writing to the disk that has bad sectors on > it. (I do newfs it between reboots). Again, not sure if this is a "well, > dont use a bad disk", but here is the panic again in case it shows something > useful. > This is a 'don't use a bad disk' panic; FreeBSD UFS and VM simply can't handle errors on reads or writes. Scott From hrs at FreeBSD.org Mon Jul 6 22:11:24 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Jul 6 22:11:33 2009 Subject: RFC: set_rcvar in rc.subr Message-ID: <20090707.070545.02771440.hrs@allbsd.org> Skipped content of type multipart/mixed-------------- 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/20090706/99aa7f49/attachment-0001.pgp From oberman at es.net Mon Jul 6 23:36:19 2009 From: oberman at es.net (Kevin Oberman) Date: Mon Jul 6 23:36:26 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: Your message of "Mon, 06 Jul 2009 15:04:51 +0200." <4A51F673.5010007@phat.za.net> Message-ID: <20090706233614.293AA1CC09@ptavv.es.net> > Date: Mon, 06 Jul 2009 15:04:51 +0200 > From: Aragon Gouveia > Sender: owner-freebsd-current@freebsd.org > > Hi, > > Patrick Lamaiziere wrote: > >>> I would like an option to set the minimum allowed CPU speed, instead > >>> the use of the sysctl debug.cpufreq.lowest. > >> This is so that powerd doesn't take so long to spin up power in the > >> adaptive modes? > > > > If the speed is too low, my machine is not very interactive here > > (running KDE and all...). > > Have you tried disabling throttling (P4TCC)? Add these to your loader.conf: > > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > > When you reboot you'll notice a lot of frequencies missing from > dev.cpu.0.freq_levels. The remaining ones are those affected by EIST only. > > The difference? EIST controls CPU frequency *and* voltage. Throttling > controls only frequency, and is much less effective at saving power > (while being very effective at slowing your system down). If you > disable throttling and use just EIST, your system will be much more > responsive at a very small power cost. It's really even worse than this. Throttling/TCC don't actually change clock speed. Thy simply "skip" N of every 8 clock cycles. The result is that power and performance under load are reduced by exactly the same amount and the effect of throttling drops with CPU load and is zero on an idle system. EST and C3 (or higher when available) are a much bigger wins. I see little value in the use of TCC or throttling. > The power cost above can be made up by setting C-state to C2 or even C3. > > If you're running FreeBSD 8, another way of saving a lot of power on a > notebook is to power down USB devices. Most notebooks' webcams and > fingerprint readers are internally connected to the USB bus. Note that even having the USB drivers loaded runs up battery use and blocks C3 even if no devices are connected to the USB. This is fixed in current by the new USB stack, but in v7, I build the kernel on my laptop without USB and load as needed. > > Alexander Motin did a lot of testing a while ago. Take a look at this > thread: > > http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006436.html -- 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 kensmith at cse.Buffalo.EDU Tue Jul 7 00:51:13 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Tue Jul 7 00:51:26 2009 Subject: FreeBSD 8.0-BETA1 Available Message-ID: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> The first public test build of the FreeBSD 8.0-RELEASE test cycle is now available, 8.0-BETA1. Through the next week or so more information about the release will be posted but here is the current target schedule for the other 'major events': BETA2: July 13, 2009 BETA3: July 20, 2009 RC1: July 27, 2009 RC2: August 17, 2009 RELEASE:August 31, 2009 People with the resources to do so (test machines...) are encouraged to give 8.0-BETA1 a try. At this point it is not quite ready for production systems but mostly because there is still some ongoing work in a few areas that may cause some changes in things like ABI/API. Debugging support (WITNESS, malloc debugging, etc.) are also still turned on and those tend to cause a performance hit. As far as we know there are no known issues that would cause data corruption or anything like that, just the issues with performance and potential for changes caused by ongoing work. If you find problems they can be reported through the normal Gnats based PR system or posted to the mailing lists. Note that for BETA1 no packages were included with any of the images. The amd64 and i386 architectures include a file named: 8.0-BETA1--memstick.img If you copy that to a USB memory stick newer machines should be able to boot from it and use it to install from. Note that you need to overwrite the contents of the memory stick completely, not copy it into an existing filesystem on the memory stick. Exactly how you do that depends on your machine but just to give you an example this works on the machine I tested it with: dd if=8.0-BETA1-amd64-memstick.img of=/dev/da0 bs=10240 conv=sync Be careful if you have SCSI drives, more USB disks than just the memory stick, etc - make sure /dev/da0 (or whatever you use) is the memory stick. Using this image for livefs based rescue mode is known to not work, that is one of the things still being worked on. FreeBSD Update was not ready for updates to 8.0 at the point this message was sent but it is also being worked on. A separate message will be posted when it's ready. Checksums for the images: MD5 (8.0-BETA1-amd64-bootonly.iso) = e7cc0b3b022775f6be058044f171e3d2 MD5 (8.0-BETA1-amd64-disc1.iso) = ad259bc0d57e1a7ae1afdc04bbb87cfd MD5 (8.0-BETA1-amd64-dvd1.iso) = f240e48be3db47ed338bb157244b874d MD5 (8.0-BETA1-amd64-livefs.iso) = 2a0f06d61d2722efe68cf8c6a14de0c6 MD5 (8.0-BETA1-amd64-memstick.img) = 10bc42a388c213497f03aadad30e0486 MD5 (8.0-BETA1-i386-bootonly.iso) = cadcdb82377705061a0d464569ecfef7 MD5 (8.0-BETA1-i386-disc1.iso) = 9e19a4edcc3b2d7f594cbcdc7fcabace MD5 (8.0-BETA1-i386-dvd1.iso) = 98a2f5e05391eb4ab2b421443296cd7b MD5 (8.0-BETA1-i386-livefs.iso) = c1d35cd8a15434b2af0bc1f27ddb48a1 MD5 (8.0-BETA1-i386-memstick.img) = c6a0fbe8e31b2987b5da47c52705fa8e MD5 (8.0-BETA1-ia64-bootonly.iso) = d40385e657477566100ae66485a98bb3 MD5 (8.0-BETA1-ia64-disc1.iso) = 216b4e54536bb41c5a9543ce88f288bc MD5 (8.0-BETA1-ia64-disc2.iso) = 790eb3e163aee02c7c6dddcfa54cc167 MD5 (8.0-BETA1-ia64-disc3.iso) = b59510898c2ce1cfe594620cc2f9de97 MD5 (8.0-BETA1-ia64-dvd1.iso) = ce7d5abec2aaed9028b82c66445e2734 MD5 (8.0-BETA1-ia64-livefs.iso) = 5021774a2349d960e859082065c1bc86 MD5 (8.0-BETA1-pc98-bootonly.iso) = 9a421562167c5d6806784151c26694fe MD5 (8.0-BETA1-pc98-disc1.iso) = b5ca7555697677eb23057fffe2c47062 MD5 (8.0-BETA1-pc98-livefs.iso) = 0c8a405c394651ea61dee34d9637b47e MD5 (8.0-BETA1-powerpc-bootonly.iso) = e982f204c4024c544f88753b400007a5 MD5 (8.0-BETA1-powerpc-disc1.iso) = 0e59688100a8288e2bee87c4d0f9b0ee MD5 (8.0-BETA1-powerpc-disc2.iso) = 1426a523d1b2480c4f546422934d1cc4 MD5 (8.0-BETA1-powerpc-disc3.iso) = d6b7505441c756be547b4587331af6b9 MD5 (8.0-BETA1-powerpc-livefs.iso) = 2dbf7c3543fcd35c834fd19f64f240cf MD5 (8.0-BETA1-sparc64-bootonly.iso) = 24004c2014edcbafb68f09399db1b74d MD5 (8.0-BETA1-sparc64-disc1.iso) = 96e7a0b14581fac7ab845a4e9916d393 MD5 (8.0-BETA1-sparc64-dvd1.iso) = efcc5a4923f335cd483d76395333b639 SHA256 (8.0-BETA1-amd64-bootonly.iso) = d49e8651f71c1a4a4d2ad9b4e391e7dfea2fec159a716876c4c0a547b346d34d SHA256 (8.0-BETA1-amd64-disc1.iso) = 692eb89c0ba07dc161ad2ea366516a2210c5d5e5cf90a48ed6316e67b7ebb5e4 SHA256 (8.0-BETA1-amd64-dvd1.iso) = eaf4a18c269589af516f6c96af164f918345a34e2fb1e5273762479a7779c4cd SHA256 (8.0-BETA1-amd64-livefs.iso) = b9e68d7944707f73f0894e0f610ff73ff5c5350e9dbc15d980a4d9413d61daf8 SHA256 (8.0-BETA1-amd64-memstick.img) = c3ece618be54d4c51400945d8922f6724547453a133c32450ac2ebbacaabaa65 SHA256 (8.0-BETA1-i386-bootonly.iso) = d82918557e595fdb76ae8d4158e0f5738a3879985d6c5109b944d382c9f767af SHA256 (8.0-BETA1-i386-disc1.iso) = 398a93e851088391fc1cca6c3ff50494afc4e5471791cff12204ef8673b81472 SHA256 (8.0-BETA1-i386-dvd1.iso) = b61e14733e498fe83e482010b036f3aabb8d7dace2ed5fb8b8dbe371141a2caa SHA256 (8.0-BETA1-i386-livefs.iso) = 6d47e830bea1a96d851490d41b4a47248a03ec2a6c39df534ca407aba2daf58a SHA256 (8.0-BETA1-i386-memstick.img) = b7561c27ea789447e368a1e2398249282ae46e8752a82bbb3614cb5db3d606e7 SHA256 (8.0-BETA1-ia64-bootonly.iso) = 6e9b9cc92a82b062cc5d9d51da7652a79097894b16e8c2cf8bcdb7b51c3aa576 SHA256 (8.0-BETA1-ia64-disc1.iso) = 52ca59f0129cda5651bf0aad3daa57a07a719580c3ece28be63178e40e6f0613 SHA256 (8.0-BETA1-ia64-disc2.iso) = f6e1bded3aec557e19ef0249b9c3b17ba3c5e0aca99d98ae697e6107c9bb3061 SHA256 (8.0-BETA1-ia64-disc3.iso) = b8b8e5ce0cca5eb3dd0dc8ea05b7de399cb937ecc4b960eb092e621cda22bbd5 SHA256 (8.0-BETA1-ia64-dvd1.iso) = 29d5852bef2d09c73075242ea2e2d35072a51b30b624d5229ed8aec6737cfbc5 SHA256 (8.0-BETA1-ia64-livefs.iso) = 0a92eb0f09dfd4f4ab0694fd94482e4682eded3425186737bd0e2440e957dd3b SHA256 (8.0-BETA1-pc98-bootonly.iso) = 5d77d1fb6a5d7e819b0d90d1848f7d029d64ce456ca550e3049d63eb5fc8891a SHA256 (8.0-BETA1-pc98-disc1.iso) = 5e11719fd24d8f8a9fd0fd4ce07c72509c197e48b1e45060d931b0f8bcad9335 SHA256 (8.0-BETA1-pc98-livefs.iso) = 271056add63d5e82f85a482cfd0efcfaaacb1b5941337fc459782e97577f3e0e SHA256 (8.0-BETA1-powerpc-bootonly.iso) = 60c984e47d8e71eb87ae382cb1bc19a0abd982095b5906dafb539e799ad0a51e SHA256 (8.0-BETA1-powerpc-disc1.iso) = 647b51471e71a8de9ab4a0c42fa94d869fae33a2f5f3a0aaa07592bb9854a49f SHA256 (8.0-BETA1-powerpc-disc2.iso) = 9a46aecda07f6b6fa040bf7c852c3a99eb27e8db529c8f26974d5a9a2ecf0b8d SHA256 (8.0-BETA1-powerpc-disc3.iso) = efe792cb535ea2a6ee821cdcd5fd1e5306e116e32b57e2f1e6d4309f672830ab SHA256 (8.0-BETA1-powerpc-livefs.iso) = 1b8e5c401bf5b14c0a14d91b21895ed2273287158e59a158313bcec43aead8ff SHA256 (8.0-BETA1-sparc64-bootonly.iso) = 2775ceec218f5fef0bc2d17ea80e1492f423307f27cec38df352b1e9ee6f96a4 SHA256 (8.0-BETA1-sparc64-disc1.iso) = 9eac5684c3c650e2cac01343c7933931aef0227bdb6e9a4931402ad0dd41b9c8 SHA256 (8.0-BETA1-sparc64-dvd1.iso) = 207268ec113811213d73b571c2322585c26cf6beae88e27e5680e77c93e249b2 -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090707/a58c784d/attachment.pgp From erich at apsara.com.sg Tue Jul 7 02:16:00 2009 From: erich at apsara.com.sg (Erich Dollansky) Date: Tue Jul 7 02:34:51 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> Message-ID: <200907070815.34876.erich@apsara.com.sg> Hi, On 06 July 2009 pm 15:22:58 Rene Schickbauer wrote: > > Would it also make sense to have powerd run an (optional) user > configureable script on ac state change? I'm thinking about > things like dimming TFT backlight, on EEE PC turning of the > webcam and so on. > I did some work on powerd to regulate the speed better but never finished it. Let me share my experience. Yes, it makes sense that powerd is enabled to run external programs triggered by events powerd has to monitor. I would not limit it to AC/DC changes. powerd could also run external programs when falling below a certain speed and coming back above a certain speed again. This would allow also to dim the LCD when less power is used because notbody is using the screen. It might will not make sense for most uses but for some. powerd's main idea is to save energy. Allowing a second program to parse through a file is not what will save energy. Erich From aragon at phat.za.net Tue Jul 7 03:58:44 2009 From: aragon at phat.za.net (Aragon Gouveia) Date: Tue Jul 7 03:58:51 2009 Subject: RFC: powerd Patch & proposed future changes In-Reply-To: <200907070815.34876.erich@apsara.com.sg> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <200907070815.34876.erich@apsara.com.sg> Message-ID: <4A52C7E3.4000304@phat.za.net> Erich Dollansky wrote: > Yes, it makes sense that powerd is enabled to run external > programs triggered by events powerd has to monitor. > > I would not limit it to AC/DC changes. powerd could also run > external programs when falling below a certain speed and coming > back above a certain speed again. > > This would allow also to dim the LCD when less power is used > because notbody is using the screen. It might will not make sense > for most uses but for some. Can you think of a better example? LCD dimming can already by handled by Xorg's DPMS. And LCD dimming and CPU usage are not directly related. If I walk away from a port compiling, I don't want powerd to keep my LCD on because the CPU is at 100%. > powerd's main idea is to save energy. Allowing a second program to > parse through a file is not what will save energy. Neither will constant spawning of new processes. JMHO. Regards, Aragon From gnemmi at gmail.com Tue Jul 7 05:54:52 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Jul 7 05:54:58 2009 Subject: Fatal trap 9 on -BETA1 on boot "with ACPI disabled" or "Safe Mode": Message-ID: <19e9a5dc0907062254u528c4a8ahea2a605e80b1feea@mail.gmail.com> Can reproduce it on -CURRENT-200906 and -BETA1 whenever I try to boot "with ACPI disabled" or "Safe Mode": Fatal trap 9: general protection fault while in kernel mode cpuid = 0; acpic id = 00 instruction pointer = 0x70:0xbfe4 stack pointer = 0x28:0xfa4 frame pointer = 0x28:0xfd4 code segment = base 0xc00f0000, limit 0xffff, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 100000 ] Stopped at 0xbfe4: *** error reading from address bfe4 *** db> bt Tracing pid 0 tid 100000 td 0x0da9b50 uart_z8530_class(780001,0,b0202,ffe,0,...) at 0xbfe4 db> more info at http://forums.freebsd.org/showthread.php?t=4988 verbose boot: http://pastebin.com/f604c1399 Willing to do everything I can to solve it. Best regards Gonzalo From gnemmi at gmail.com Tue Jul 7 06:06:29 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Jul 7 06:06:36 2009 Subject: LOR on umount on -BETA1 Message-ID: <19e9a5dc0907062242qe6ec24br677c79996623c3e5@mail.gmail.com> LOR on -CURRENT and -BETA1. plug pen-drive: Jul 7 01:45:42 gargoyle root: Unknown USB device: vendor 0x08ec product 0x0008 bus uhub3 Jul 7 01:45:42 gargoyle kernel: ugen6.2: at usbus6 Jul 7 01:45:42 gargoyle kernel: umass0: on usbus6 Jul 7 01:45:42 gargoyle kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 Jul 7 01:45:43 gargoyle kernel: umass0:1:0:-1: Attached to scbus1 Jul 7 01:45:43 gargoyle kernel: (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed Jul 7 01:45:45 gargoyle kernel: Retrying Command (per Sense Data) Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): Retrying Command Jul 7 01:45:45 gargoyle kernel: pass0 at umass-sim0 bus 0 target 0 lun 0 Jul 7 01:45:45 gargoyle kernel: pass0: Removable Direct Access SCSI-0 device Jul 7 01:45:45 gargoyle kernel: pass0: 40.000MB/s transfers Jul 7 01:45:45 gargoyle kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Jul 7 01:45:45 gargoyle kernel: da0: Removable Direct Access SCSI-0 device Jul 7 01:45:45 gargoyle kernel: da0: 40.000MB/s transfers Jul 7 01:45:45 gargoyle kernel: da0: 490MB (1003520 512 byte sectors: 64H 32S/T 490C) Jul 7 01:45:45 gargoyle kernel: GEOM: new disk da0 Jul 7 01:45:46 gargoyle kernel: GEOM: da0: partition 1 does not start on a track boundary. Jul 7 01:45:46 gargoyle kernel: GEOM: da0: partition 1 does not end on a track boundary. # mount_msdosfs /dev/da0s1 pen/, write and then # umount pen/: Jul 7 01:56:45 gargoyle kernel: lock order reversal: Jul 7 01:56:45 gargoyle kernel: 1st 0xc4e63bdc ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1199 Jul 7 01:56:45 gargoyle kernel: 2nd 0xc4e63ce8 devfs (devfs) @ /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:944 Jul 7 01:56:45 gargoyle kernel: KDB: stack backtrace: Jul 7 01:56:45 gargoyle kernel: db_trace_self_wrapper(c0c5b564,e6da0a48,c08b5b35,c08a68db,c0c5e3f9,...) at db_trace_self_wrapper+0x26 Jul 7 01:56:45 gargoyle kernel: kdb_backtrace(c08a68db,c0c5e3f9,c4530430,c4530360,e6da0aa4,...) at kdb_backtrace+0x29 Jul 7 01:56:45 gargoyle kernel: _witness_debugger(c0c5e3f9,c4e63ce8,c0c4d3c5,c4530360,c0c4dba9,...) at _witness_debugger+0x25 Jul 7 01:56:45 gargoyle kernel: witness_checkorder(c4e63ce8,9,c0c4dba9,3b0,c4e63d04,...) at witness_checkorder+0x839 Jul 7 01:56:45 gargoyle kernel: __lockmgr_args(c4e63ce8,80400,c4e63d04,0,0,...) at __lockmgr_args+0x7a7 Jul 7 01:56:45 gargoyle kernel: vop_stdlock(e6da0bac,c0ee9a48,c4afc9a4,80400,c4e63c90,...) at vop_stdlock+0x62 Jul 7 01:56:45 gargoyle kernel: VOP_LOCK1_APV(c0d38d00,e6da0bac,e6da0bcc,c0d75c00,c4e63c90,...) at VOP_LOCK1_APV+0xb5 Jul 7 01:56:45 gargoyle kernel: _vn_lock(c4e63c90,80400,c0c4dba9,3b0,c4add284,...) at _vn_lock+0x5e Jul 7 01:56:45 gargoyle kernel: msdosfs_sync(c4add284,1,c0c64e9d,4f4,80,...) at msdosfs_sync+0x29c Jul 7 01:56:45 gargoyle kernel: dounmount(c4add284,8000000,c4afc900,479,2,...) at dounmount+0x44e Jul 7 01:56:45 gargoyle kernel: unmount(c4afc900,e6da0cf8,8,c4afc900,c0d3c288,...) at unmount+0x30f Jul 7 01:56:45 gargoyle kernel: syscall(e6da0d38) at syscall+0x2a3 Jul 7 01:56:45 gargoyle kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 7 01:56:45 gargoyle kernel: --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d91ff, esp = 0xbfbfe52c, ebp = 0xbfbfe5f8 --- bervose boot: http://pastebin.com/f604c1399 some more info can be found at http://forums.freebsd.org/showthread.php?t=5025 Willing to try patches or solutions at your request. Best Regards. Gonzalo From gnemmi at gmail.com Tue Jul 7 06:10:03 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Jul 7 06:10:09 2009 Subject: Can't get resume to work on -BETA1/-CURRENT-200906, help needed Message-ID: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> log in acpiconf -s 3 suspend works opened the lid and the screen doesn't come back (backlight never gets back) hard reset login again and checked /var/log/messages .. this is what I found: Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 (disconnected) Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 (disconnected) Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: on usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 any hints on how to further debug or redirect this mail to the right list will be greatly appreciated. more info can be found in here: http://forums.freebsd.org/showthread.php?t=3886 Best Regards Gonzalo Nemmi From onemda at gmail.com Tue Jul 7 08:23:59 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Jul 7 08:24:06 2009 Subject: Can't get resume to work on -BETA1/-CURRENT-200906, help needed In-Reply-To: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> Message-ID: <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> On 7/7/09, Gonzalo Nemmi wrote: > log in > acpiconf -s 3 > suspend works > opened the lid and the screen doesn't come back (backlight never gets back) > hard reset > login again and checked /var/log/messages .. this is what I found: > > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 > (disconnected) > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 > (disconnected) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, > val 32768) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val > 0xffffffff) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, > val 0xffffffff) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, > val 0xffffffff) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, > val 0) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, > val 0xffffffff) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, > val 0) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, > val 18) > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init failed > Jul 7 00:33:18 gargoyle kernel: bge0: initialization failure > Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 ports. > Jul 7 00:33:18 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. > Jul 7 00:33:18 gargoyle kernel: fwohci0: Initiate bus reset > Jul 7 00:33:18 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset > Jul 7 00:33:18 gargoyle kernel: fwohci0: fwohci_intr_core: > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM > irm(0) (me) > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept 00:01:03) > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 > Jul 7 00:33:18 gargoyle kernel: ums0: class 0/0, rev 2.00/0.10, addr 2> on usbus3 > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] coordinates ID=1 > Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 00:33:18 > Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 > > any hints on how to further debug or redirect this mail to the right list > will be greatly appreciated. > > more info can be found in here: > http://forums.freebsd.org/showthread.php?t=3886 > > Best Regards > Gonzalo Nemmi i386 resume doesn't work with SMP kernel and SMP CPU. On amd64 make sure that you have right file loaded in kernel: for example i915.ko for intel cards. -- Paul From shuvaev at physik.uni-wuerzburg.de Tue Jul 7 09:16:35 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Tue Jul 7 09:16:42 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <200907062118.n66LIGRg043316@lava.sentex.ca> References: <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <200907062118.n66LIGRg043316@lava.sentex.ca> Message-ID: <20090707091624.GA7770@wep4035.physik.uni-wuerzburg.de> On Mon, Jul 06, 2009 at 05:20:45PM -0400, Mike Tancsa wrote: > At 02:41 AM 7/5/2009, Alexander Motin wrote: > >>Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is > >>40000001 cs 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 > > > >This is AHCI driver debugging. I've removed it in latest patch. In > >this case it means that drive signals some command error. > > > Hi, > > With the latest patch (cam-ata.20090704.patch), writing to the disk > with physical errors looks like this now > > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: > g_vfs_done():ada2[READ(offset=42003431424, length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: > g_vfs_done():ada2[READ(offset=42196107264, length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: > g_vfs_done():ada2[READ(offset=42388783104, length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: > g_vfs_done():ada2[READ(offset=42581458944, length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: > g_vfs_done():ada2[READ(offset=42774134784, length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:18 ich10 last message repeated 4 times > Jul 6 13:56:18 ich10 kernel: > g_vfs_done():ada2[READ(offset=42966810624, length=16384)]error = 5 > Jul 6 13:56:18 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:18 ich10 last message repeated 4 times > > Still the box does a panic when writing to the disk that has bad > sectors on it. (I do newfs it between reboots). Again, not sure if > this is a "well, dont use a bad disk", but here is the panic again in > case it shows something useful. > > > Unread portion of the kernel message buffer: > ahcich2: Error while READ LOG EXT > ahcich2: Error while READ LOG EXT > g_vfs_done():ada2s1d[READ(offset=36418928640, length=16384)]error = 5 > ahcich2: Error while READ LOG EXT > ahcich2: Error while READ LOG EXT > ahcich2: Error while READ LOG EXT > panic: initiate_write_inodeblock_ufs2: already started > cpuid = 6 > Uptime: 5m55s > ahcich2: Error while READ LOG EXT > (ada2:ahcich2:0:0:0): Synchronize cache failed > Physical memory: 3556 MB > Dumping 220 MB: > > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0xb0014 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc047f14b > stack pointer = 0x28:0xc6e69c08 > frame pointer = 0x28:0xc6e69c20 > 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 = 12 (irq257: ahci0) > trap number = 12 > 205 189 173 157 141 125 109 93 77 61 45 29 13 > > Reading symbols from /boot/kernel/ahci.ko...Reading symbols from > /boot/kernel/ahci.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ahci.ko > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:246 > #1 0xc086ca3e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 > #2 0xc086ccd9 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xc0a87ebe in softdep_disk_io_initiation (bp=0xdb2bbf60) > at /usr/src/sys/ufs/ffs/ffs_softdep.c:4056 > #4 0xc0a8be2c in ffs_geom_strategy (bo=0xc803c2c0, bp=0xdb2bbf60) > at buf.h:404 > #5 0xc08e2019 in bufwrite (bp=0xdb2bbf60) at buf.h:397 > #6 0xc0a8b55b in ffs_bufwrite (bp=0xdb2bbf60) > at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1893 > #7 0xc08df1c8 in vfs_bio_awrite (bp=0xdb2bbf60) at buf.h:385 > #8 0xc08e89bb in vop_stdfsync (ap=0xe7798c7c) > at /usr/src/sys/kern/vfs_default.c:608 > #9 0xc07f366c in devfs_fsync (ap=0xe7798c7c) > at /usr/src/sys/fs/devfs/devfs_vnops.c:556 > #10 0xc0b90095 in VOP_FSYNC_APV (vop=0xc0d1a580, a=0xe7798c7c) > at vnode_if.c:1267 > #11 0xc08f87a8 in sync_vnode (slp=0xc76a27f4, bo=0xe7798ce8, td=0xc78ad6c0) > at vnode_if.h:549 > #12 0xc08f8af3 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1799 > #13 0xc0844418 in fork_exit (callout=0xc08f8880 , arg=0x0, > frame=0xe7798d38) at /usr/src/sys/kern/kern_fork.c:842 > #14 0xc0b67cb0 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:270 > (kgdb) > > > Unless you would like me to test some other features of the driver, I > will just RMA the drive tomorrow. > It seems you are doing newfs and then mounting it. Why? If you want to remove the data do something like dd if=/dev/zero of=/dev/ada2 bs=1m or dd if=/dev/random of=/dev/ada2 bs=1m You could also try smaller block sizes (bs argument) near the bad blocks. Just 0.02$, Alexey. From mexas at bristol.ac.uk Tue Jul 7 09:48:14 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 7 09:48:22 2009 Subject: buildworld panic on ia64 Message-ID: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> this is FreeBSD 8.0-current 200906 snapshot on ia64. Updated src this morning, following the standard procedure, on make -j6 buildworld the process stops at: ===> gnu/usr.bin/cc/cc1 (all) cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/main.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-parser.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-pa rser.o c-lang.o /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbac kend.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /usr/o bj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /usr/ob j/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a -legacy ../cc_tools/genchecksum cc1-dummy > cc1-checksum.c on the console I get: panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 cpuid = 0 KDB: enter: panic [thread pid 67078 tid 100097 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; db> -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From rink at FreeBSD.org Tue Jul 7 10:06:47 2009 From: rink at FreeBSD.org (Rink Springer) Date: Tue Jul 7 10:06:54 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> Message-ID: <20090707095058.GC7827@rink.nu> On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > cpuid = 0 > KDB: enter: panic > [thread pid 67078 tid 100097 ] > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; Do you have a backtrace ? Regards, -- Rink P.W. Springer - http://rink.nu "Doom, gloom and despair. I like it!" - Tiresias From avg at icyb.net.ua Tue Jul 7 10:12:48 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Jul 7 10:12:57 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <20090706152351.S26418@pooker.samsco.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <200907062118.n66LIGRg043316@lava.sentex.ca> <20090706152351.S26418@pooker.samsco.org> Message-ID: <4A531F8D.5040009@icyb.net.ua> on 07/07/2009 00:24 Scott Long said the following: >> Still the box does a panic when writing to the disk that has bad >> sectors on it. (I do newfs it between reboots). Again, not sure if >> this is a "well, dont use a bad disk", but here is the panic again in >> case it shows something useful. >> > > This is a 'don't use a bad disk' panic; FreeBSD UFS and VM simply can't > handle errors on reads or writes. I think that this is not generally true, especially about reads. And wasn't there a FreeBSD Foundation sponsored project to fix panics caused by media going away? I think that panics on I/O errors are related to that. trasz might be interested in this particular one. -- Andriy Gapon From lstewart at freebsd.org Tue Jul 7 10:35:03 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Tue Jul 7 10:35:11 2009 Subject: "filesystem goof: vop_panic[vop_revoke]" panic In-Reply-To: <20090629114516.GY2884@deviant.kiev.zoral.com.ua> References: <4A48942A.7030307@freebsd.org> <20090629114516.GY2884@deviant.kiev.zoral.com.ua> Message-ID: <4A5324C1.5080203@freebsd.org> Kostik Belousov wrote: > On Mon, Jun 29, 2009 at 11:15:06AM +0100, Lawrence Stewart wrote: >> Hi All, >> >> My laptop panicked whilst shutting down yesterday. The shutdown sequence >> seemed to terminate kde4/X correctly but got wedged prior to completing >> the rest as seen on the console. Details below... [snip] Been running with your patch for well over a week now and no recurrence of the panic. I think it's safe to say the patch has fixed the issue for me. Cheers, Lawrence From gavin at FreeBSD.org Tue Jul 7 10:50:45 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Jul 7 10:50:52 2009 Subject: Fatal trap 9 on -BETA1 on boot "with ACPI disabled" or "Safe Mode": In-Reply-To: <19e9a5dc0907062254u528c4a8ahea2a605e80b1feea@mail.gmail.com> References: <19e9a5dc0907062254u528c4a8ahea2a605e80b1feea@mail.gmail.com> Message-ID: <1246963840.48637.44.camel@buffy.york.ac.uk> On Tue, 2009-07-07 at 02:54 -0300, Gonzalo Nemmi wrote: > Can reproduce it on -CURRENT-200906 and -BETA1 whenever I try to boot "with > ACPI disabled" or "Safe Mode": > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; acpic id = 00 > instruction pointer = 0x70:0xbfe4 > stack pointer = 0x28:0xfa4 > frame pointer = 0x28:0xfd4 > code segment = base 0xc00f0000, limit 0xffff, type 0x1b > = DPL 0, pres 1, def32 0, gran 0 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 100000 ] > Stopped at 0xbfe4: *** error reading from address bfe4 *** > db> bt > Tracing pid 0 tid 100000 td 0x0da9b50 > uart_z8530_class(780001,0,b0202,ffe,0,...) at 0xbfe4 > db> This may well be a known problem that has affected certain Intel motherboards since around 5.x. Although this problem may well be solvable, perhaps the better approach is to fix whatever is stopping you from booting with ACPI enabled? If for some reason you cannot have ACPI enabled, I guess knowing more output than the above would be useful. For example, when booting verbose and with ACPI disabled, what lines are printed before the above? (to do this, break to the loader prompt, and: setenv hint.acpi.0.disabled=1 setenv hint.apic.0.disabled=1 boot -v it's also worth trying just with the first one to just disable ACPI, then just trying the APIC option, to see which of those two are causing you problems) By the way, is this i386 or amd64? Gavin From mike at sentex.net Tue Jul 7 11:38:47 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue Jul 7 11:38:53 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <20090707091624.GA7770@wep4035.physik.uni-wuerzburg.de> References: <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <200907062118.n66LIGRg043316@lava.sentex.ca> <20090707091624.GA7770@wep4035.physik.uni-wuerzburg.de> Message-ID: <200907071136.n67BaEYR048532@lava.sentex.ca> At 05:16 AM 7/7/2009, Alexey Shuvaev wrote: >It seems you are doing newfs and then mounting it. Why? Just to make sure that post crash, I dont have to fsck it, or that as part of the crash some undetected ufs corruption happened. ---Mike >If you want to remove the data do something like >dd if=/dev/zero of=/dev/ada2 bs=1m >or >dd if=/dev/random of=/dev/ada2 bs=1m > >You could also try smaller block sizes (bs argument) near the bad blocks. > >Just 0.02$, >Alexey. From mexas at bristol.ac.uk Tue Jul 7 12:44:19 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 7 12:44:28 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707095058.GC7827@rink.nu> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> Message-ID: <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > cpuid = 0 > > KDB: enter: panic > > [thread pid 67078 tid 100097 ] > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > Do you have a backtrace ? no, sorry, I was too quick to reboot. I tried to reproduce the error, got this on the way: # XXX: bogusly disabled high FP regs which is reported from by sys/ia64/ia64/trap.c, and then this error (but no panic this time): ===> usr.bin/yacc (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/closure. c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/error.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/lalr.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/lr0.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/mkpar.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/output.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/reader.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/main.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/skeleton .c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/symtab.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/verbose. c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/warshall .c gzip -cn /usr/src/usr.bin/yacc/yacc.1 > yacc.1.gz gzip -cn /usr/src/usr.bin/yacc/yyfix.1 > yyfix.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o yacc closure.o error.o lalr.o lr0.o main.o mkpar.o output.o reader.o skeleton.o symtab.o verbose.o warshall.o ===> usr.bin/yes (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yes/yes.c gzip -cn /usr/src/usr.bin/yes/yes.1 > yes.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o yes yes.o ===> usr.bin/ypcat (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/ypcat/ypcat.c gzip -cn /usr/src/usr.bin/ypcat/ypcat.1 > ypcat.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypcat ypcat.o ===> usr.bin/ypmatch (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/ypmatch/ypmat ch.c gzip -cn /usr/src/usr.bin/ypmatch/ypmatch.1 > ypmatch.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypmatch ypmatch.o ===> usr.bin/ypwhich (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/ypwhich/ypwhi ch.c gzip -cn /usr/src/usr.bin/ypwhich/ypwhich.1 > ypwhich.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypwhich ypwhich.o 1 error *** Error code 2 1 error *** Error code 2 1 error # ********************** Below are dmesg and make.conf, if it matters. There are several backtraces in dmesg, but I'm not sure now at what stage they appeared. many thanks ********************** GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb 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-200906 #0: Fri Jun 12 22:56:41 UTC 2009 root@hob.lan.xcllnt.net:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. CPU: Madison (1500.00-Mhz Itanium 2) Origin = "GenuineIntel" Revision = 5 Features = 0x1 real memory = 2126766080 (2028 MB) avail memory = 2013437952 (1920 MB) FPSWA Revision = 0x10012, Entry = 0xe00000407fe60050 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: SAPIC Id=0, SAPIC Eid=0 (BSP) cpu1: SAPIC Id=1, SAPIC Eid=0 ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 20090521 tbfadt-625 ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 20090521 tbfadt-625 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> iomem 0xff5c1004-0xff5c1007 on acpi0 acpi_tz0: on acpi0 pcib0: on acpi0 pci0: on pcib0 ohci0: mem 0x80023000-0x80023fff irq 16 at device 1.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0x80022000-0x80022fff irq 17 at device 1.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0x80021000-0x800210ff irq 18 at device 1.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 0.95 usbus2: on ehci0 atapci0: port 0xd58-0xd5f,0xd64-0xd67,0xd50-0xd57,0xd60-0xd63,0xd40-0xd4f irq 21 at device 2.0 on pci0 atapci0: [ITHREAD] atapci0: HW has secondary channel disabled ata2: on atapci0 ata2: [ITHREAD] fxp0: port 0xd00-0xd3f mem 0x80020000-0x80020fff,0x80000000-0x8001ffff irq 20 at device 3.0 on pci0 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:11:0a:31:d6:ec fxp0: [ITHREAD] pcib1: on acpi0 pci32: on pcib1 mpt0: port 0x2100-0x21ff mem 0x90840000-0x9084ffff,0x90830000-0x9083ffff irq 27 at device 1.0 on pci32 mpt0: [ITHREAD] mpt0: MPI Version=1.2.12.0 mpt1: port 0x2000-0x20ff mem 0x90820000-0x9082ffff,0x90810000-0x9081ffff irq 28 at device 1.1 on pci32 mpt1: [ITHREAD] mpt1: MPI Version=1.2.12.0 bge0: mem 0x90800000-0x9080ffff irq 29 at device 2.0 on pci32 miibus1: on bge0 brgphy0: PHY 1 on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:11:0a:31:36:40 bge0: [ITHREAD] pcib2: on acpi0 pci64: on pcib2 pcib3: on acpi0 pci96: on pcib3 pcib4: on acpi0 pci128: on pcib4 pcib5: on acpi0 pci192: on pcib5 pcib6: on acpi0 pci224: on pcib6 uart0: <16550 or compatible> mem 0xf4051000-0xf405100f irq 82 at device 1.0 on pci224 uart0: [FILTER] puc0: mem 0xf4050000-0xf4050fff,0xf4020000-0xf403ffff irq 82 at device 1.1 on pci224 puc0: [FILTER] uart1: on puc0 uart1: [FILTER] uart1: console (9600,n,8,1) uart2: on puc0 uart2: [FILTER] vgapci0: port 0xe000-0xe0ff mem 0xf0000000-0xf3ffffff,0xf4040000-0xf404ffff at device 2.0 on pci224 uart3: <16550 or compatible> iomem 0xff5e0000-0xff5e0007 irq 34 on acpi0 uart3: [FILTER] uart4: <16550 or compatible> iomem 0xff5e2000-0xff5e2007 irq 35 on acpi0 uart4: [FILTER] uart4: debug port (9600,n,8,1) cpu0: on acpi0 cpu1: on acpi0 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub2: on usbus2 acd0: DVDROM at ata2-master PIO4 Waiting 5 seconds for SCSI devices to settle uhub1: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub2: 5 ports with 5 removable, self powered WARNING: WITNESS option enabled, expect reduced performance. da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da0: Command Queueing Enabled da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da1: Command Queueing Enabled da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) GEOM_MIRROR: Device mirror/efi launched (2/2). GEOM_MIRROR: Device mirror/root launched (2/2). GEOM_MIRROR: Device mirror/swap launched (2/2). GEOM_MIRROR: Device mirror/var launched (2/2). GEOM_MIRROR: Device mirror/tmp launched (1/2). GEOM_MIRROR: Device tmp: rebuilding provider da0p5. GEOM_MIRROR: Device mirror/usr launched (1/2). GEOM_MIRROR: Device usr: rebuilding provider da0p6. Trying to mount root from ufs:/dev/mirror/root WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted /tmp: mount pending error: blocks 24 files 6 WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted GEOM_MIRROR: Device tmp: rebuilding provider da0p5 finished. lock order reversal: 1st 0xe0000000109596b8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 2nd 0xa00000001e4bad40 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 3rd 0xe000000010792448 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b71740) at _witness_debugger+0x60 witness_checkorder(0xe000000010792448, 0x9, 0x0, 0x220, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe000000010792448, 0x80100, 0xe000000010792470, 0xe000000004b3a158, 0x50, 0x33, 0xe000000004b71740, 0x220) at __lockmgr_args+0xe10 ffs_lock(0xa000000032a78dd0, 0xe000000010792448, 0x80100) at ffs_lock+0x130 VOP_LOCK1_APV(0xe000000004cc19f0, 0xa000000032a78db0, 0xe0000000045d5b90) at VOP_LOCK1_APV+0x1d0 _vn_lock(0xe0000000107923b0, 0x80100, 0xe000000004b71740, 0x220, 0xe0000000107923c0, 0xa000000032a78dd0, 0xa000000032a78dc8, 0xa000000032a78dc0) at _vn_lock+0xf0 ffs_snapshot(0xe0000000107b45e0, 0xa000000032a78fc8, 0xe0000000107923b0, 0xe000000010792470, 0x1, 0x0, 0xa00000000037a000, 0x0) at ffs_snapshot+0x2280 ffs_mount(0x0, 0xe000000004b735e8, 0xa000000032a79100, 0xa000000032a79100) at ffs_mount+0x2160 vfs_donmount(0x0, 0x211000, 0xe0000000106c5400) at vfs_donmount+0x1d80 nmount(0xe000000010886000, 0xa000000032a794e8, 0x0, 0xe000000004ac03e0) at nmount+0xe0 syscall(0xa000000032a79400, 0x17a, 0x201000, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c99a28, 0x17a, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return lock order reversal: 1st 0xa00000001e4bad40 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xe000000010a2a330 snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:793 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b71740) at _witness_debugger+0x60 witness_checkorder(0xe000000010a2a330, 0x9, 0xffffffffffffffff, 0x319, 0xe0000000109596e0) at witness_checkorder+0x12c0 __lockmgr_args(0xe000000010a2a330, 0x80400, 0xe0000000109596e0, 0xe000000004b717a8, 0x50, 0x33, 0xe000000004b71740, 0x319) at __lockmgr_args+0xe10 ffs_lock(0xa000000032a78dd0, 0xe000000010a2a330, 0x80400) at ffs_lock+0x130 VOP_LOCK1_APV(0xe000000004cc19f0, 0xa000000032a78db0, 0xe000000004b51bb0) at VOP_LOCK1_APV+0x1d0 _vn_lock(0xe000000010959620, 0x80400, 0xe000000004b71740, 0x319, 0xe000000010959630, 0xa000000032a78dd0, 0xa000000032a78dc8, 0xa000000032a78dc0) at _vn_lock+0xf0 ffs_snapshot(0xe0000000107b45e0, 0xa000000032a78fc8, 0xa000000032a78e08, 0xe0000000107ae000, 0xe00000001096d100, 0x0, 0xe00000001062a030, 0xe00000001096d000) at ffs_snapshot+0x3f50 ffs_mount(0x0, 0xe000000004b735e8, 0xa000000032a79100, 0xa000000032a79100) at ffs_mount+0x2160 vfs_donmount(0x0, 0x211000, 0xe0000000106c5400) at vfs_donmount+0x1d80 nmount(0xe000000010886000, 0xa000000032a794e8, 0x0, 0xe000000004ac03e0) at nmount+0xe0 syscall(0xa000000032a79400, 0x17a, 0x201000, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c99a28, 0x17a, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return lock order reversal: 1st 0xe000000010a2a330 snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:295 2nd 0xe0000000109596b8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1587 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b71740) at _witness_debugger+0x60 witness_checkorder(0xe0000000109596b8, 0x9, 0xffffffffffffffff, 0x633, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe0000000109596b8, 0x80000, 0x0, 0xe000000004b3a158, 0x50, 0x33, 0xe000000004b71740, 0x633) at __lockmgr_args+0xe10 ffs_snapremove(0xe000000010959620, 0xe000000004b71740, 0xe000000004b55ab8, 0xe0000000109596b8) at ffs_snapremove+0x200 softdep_releasefile(0xe00000001086f6f8, 0xa000000032a792d0, 0x29f, 0xe000000004a12470, 0x48e) at softdep_releasefile+0x90 ufs_inactive(0xe000000010886000, 0xe00000001086f6f8, 0xe000000010959710) at ufs_inactive+0x400 VOP_INACTIVE_APV(0xe000000004cc21c0, 0xa000000032a792e0, 0xe000000004b54550, 0xe00000000470f940) at VOP_INACTIVE_APV+0x1c0 vinactive(0xe000000010959620, 0xe000000010886000, 0x800, 0xe0000000109596e0) at vinactive+0x110 vput(0xe000000010959620, 0xa000000032a79308, 0xe000000004b55ab8, 0xe0000000109596e0) at vput+0x3f0 vn_close(0xe000000010959620, 0x1, 0xe000000010363c00, 0xe000000010886000) at vn_close+0x310 vn_closefile(0xe000000010723590, 0xe000000010886000, 0xe000000010959620) at vn_closefile+0x1e0 _fdrop(0xe000000010723590, 0xe000000010886000, 0xe000000004589d10, 0xb9b) at _fdrop+0xb0 closef(0xe000000010723590, 0xe000000010886000, 0x0, 0xe00000000458a4c0) at closef+0x570 kern_close(0xe000000010886000, 0xe000000004b3c520) at kern_close+0x270 close(0xe000000010886000, 0xa000000032a794e8, 0xe000000004ac03e0, 0x58f) at close+0x30 syscall(0xa000000032a79400, 0x6, 0x0, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c95468, 0x6, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return GEOM_MIRROR: Device usr: rebuilding provider da0p6 finished. lock order reversal: 1st 0xa00000001e6a59c8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xe0000000107bcc00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b73fd0) at _witness_debugger+0x60 witness_checkorder(0xe0000000107bcc00, 0x9, 0xffffffffffffffff, 0x11d, 0x0) at witness_checkorder+0x12c0 _sx_xlock(0xe0000000107bcc00, 0x0, 0xe000000004b73fd0, 0x11d) at _sx_xlock+0xc0 ufsdirhash_acquire(0xe000000010abbd88, 0xe0000000107bcc00, 0xe000000004a0ef40, 0x38b) at ufsdirhash_acquire+0x50 ufsdirhash_remove(0xe000000010abbd88, 0xa000000023710018, 0x18, 0xa000000032a79328) at ufsdirhash_remove+0x20 ufs_dirremove(0xe000000012b997f8, 0xe000000010bee2a0, 0x0, 0x1, 0xa000000023710018) at ufs_dirremove+0x240 ufs_rmdir(0xa000000032a79390, 0xe000000010bee2a0, 0xe000000010abbd88) at ufs_rmdir+0x230 VOP_RMDIR_APV(0xe000000004cc21c0, 0xa000000032a793d8, 0x2, 0xe00000000471aff0) at VOP_RMDIR_APV+0x1c0 kern_rmdirat(0xe000000010886000, 0xffffffffffffff9c, 0x200000004041a508, 0x0) at kern_rmdirat+0x340 kern_rmdir(0xe000000010886000, 0x200000004041a508, 0x0) at kern_rmdir+0x30 rmdir(0xe000000010886000, 0xa000000032a794e8, 0xe000000004ac03e0, 0x58f) at rmdir+0x30 syscall(0xa000000032a79400, 0x89, 0x200000004041a400, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c96cf8, 0x89, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return XXX: bogusly disabled high FP regs --->>> make.conf <<<--- # $FreeBSD: src/share/examples/etc/make.conf,v 1.279 2007/01/17 12:43:06 des Exp $ # copied from /usr/share/examples/etc/make.conf # # Currently the following CPU types are recognized: # Intel x86 architecture: # (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4 # athlon-tbird athlon k8 k6-3 k6-2 k6 k5 # (Intel CPUs) core2 core nocona pentium4m pentium4 prescott # pentium3m pentium3 pentium-m pentium2 # pentiumpro pentium-mmx pentium i486 i386 # (Via CPUs) c3 c3-2 # Alpha/AXP architecture: ev67 ev6 pca56 ev56 ev5 ev45 ev4 # AMD64 architecture: opteron, athlon64, nocona, prescott, core2 # Intel ia64 architecture: itanium2, itanium # # (?= allows to buildworld for a different CPUTYPE.) # CPUTYPE=ia64 #NO_CPU_CFLAGS= # Don't add -march= to CFLAGS automatically #NO_CPU_COPTFLAGS= # Don't add -march= to COPTFLAGS automatically # # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings other than -O and -O2 are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to "-O" or "-O2 -fno-strict-aliasing" # before submitting bug reports without patches to the developers. # # Compiling with -fstrict-aliasing optimization breaks some [notable] ports. # GCC turns on -fstrict-aliasing optimization at all levels above -O[1], so # explicitly turn it off when using compiling with the -O2 optimization level. # CFLAGS= -O2 -fno-strict-aliasing -pipe # # CXXFLAGS controls the compiler settings used when compiling C++ code. # Note that CXXFLAGS is initially set to the value of CFLAGS. If you wish # to add to CXXFLAGS value, "+=" must be used rather than "=". Using "=" # alone will remove the often needed contents of CFLAGS from CXXFLAGS. # CXXFLAGS+= -fconserve-space # # MAKE_SHELL controls the shell used internally by make(1) to process the # command scripts in makefiles. Three shells are supported, sh, ksh, and # csh. Using sh is most common, and advised. Using ksh *may* work, but is # not guaranteed to. Using csh is absurd. The default is to use sh. # MAKE_SHELL=sh # # BDECFLAGS are a set of gcc warning settings that Bruce Evans has suggested # for use in developing FreeBSD and testing changes. They can be used by # putting "CFLAGS+=${BDECFLAGS}" in /etc/make.conf. -Wconversion is not # included here due to compiler bugs, e.g., mkdir()'s mode_t argument. # BDECFLAGS= -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align \ -Wcast-qual -Wchar-subscripts -Winline \ -Wmissing-prototypes -Wnested-externs -Wpointer-arith \ -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings # # To compile just the kernel with special optimizations, you should use # this instead of CFLAGS (which is not applicable to kernel builds anyway). # There is very little to gain by using higher optimization levels, and doing # so can cause problems. # COPTFLAGS= -O -pipe # # Compare before install INSTALL=install -C # # Mtree will follow symlinks #MTREE_FOLLOWS_SYMLINKS= -L # # To enable installing ssh(1) with the setuid bit turned on #ENABLE_SUID_SSH= # # To enable installing newgrp(1) with the setuid bit turned on. # Without the setuid bit, newgrp cannot change users' groups. #ENABLE_SUID_NEWGRP= # # To avoid building various parts of the base system: #NO_MODULES= # do not build modules with the kernel #NO_SHARE= # do not go into the share subdir #NO_SHARED= # build /bin and /sbin statically linked (bad idea) # # Variables that control how ppp(8) is built. #PPP_NO_NAT= # do not build with NAT support (see make.conf(5)) #PPP_NO_NETGRAPH= # do not build with Netgraph support #PPP_NO_RADIUS= # do not build with RADIUS support #PPP_NO_SUID= # build with normal permissions # #TRACEROUTE_NO_IPSEC= # do not build traceroute(8) with IPSEC support # # To build sys/modules when building the world (our old way of doing things) #MODULES_WITH_WORLD= # do not build modules when building kernel # # The list of modules to build instead of all of them. MODULES_OVERRIDE= # # The list of modules to never build, applied *after* MODULES_OVERRIDE. #WITHOUT_MODULES= bktr plip # # If you do not want unformatted manual pages to be compressed # when they are installed: # #NO_MANCOMPRESS= # # # Default format for system documentation, depends on your printer. # Set this to "ascii" for simple printers or screen # #PRINTERDEVICE= ps # # # How long to wait for a console keypress before booting the default kernel. # This value is approximately in milliseconds. Keypresses are accepted by the # BIOS before booting from disk, making it possible to give custom boot # parameters even when this is set to 0. # #BOOTWAIT=0 #BOOTWAIT=30000 # # By default, the system will always use the keyboard/video card as system # console. However, the boot blocks may be dynamically configured to use a # serial port in addition to or instead of the keyboard/video console. # # By default we use COM1 as our serial console port *if* we're going to use # a serial port as our console at all. Alter as necessary. # # COM1: = 0x3F8, COM2: = 0x2F8, COM3: = 0x3E8, COM4: = 0x2E8 # #BOOT_COMCONSOLE_PORT= 0x3F8 # # The default serial console speed is 9600. Set the speed to a larger value # for better interactive response. # #BOOT_COMCONSOLE_SPEED= 115200 # # By default the 'pxeboot' loader retrieves the kernel via NFS. Defining # this and recompiling /usr/src/sys/boot will cause it to retrieve the kernel # via TFTP. This allows pxeboot to load a custom BOOTP diskless kernel yet # still mount the server's '/' (i.e. rather than load the server's kernel). # #LOADER_TFTP_SUPPORT= YES # # # Kerberos 5 su (k5su) # If you want to use the k5su utility, define this to have it installed # set-user-ID. #ENABLE_SUID_K5SU= # # # CVSup update flags. Edit SUPFILE settings to reflect whichever distribution # file(s) you use on your site (see /usr/share/examples/cvsup/README for more # information on CVSup and these files). To use, do "make update" in /usr/src. # #SUP_UPDATE= # #SUP= /usr/bin/csup #SUPFLAGS= -g -L 2 #SUPHOST= cvsup.uk.FreeBSD.org #SUPFILE= /usr/share/examples/cvsup/standard-supfile #PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile #DOCSUPFILE= /usr/share/examples/cvsup/doc-supfile # # top(1) uses a hash table for the user names. The size of this hash # can be tuned to match the number of local users. The table size should # be a prime number approximately twice as large as the number of lines in # /etc/passwd. The default number is 20011. # #TOP_TABLE_SIZE= 101 # # Documentation # # The list of languages and encodings to build and install # DOC_LANG= en_US.ISO8859-1 # # # sendmail # # The following sets the default m4 configuration file to use at # install time. Use with caution as a make install will overwrite # any existing /etc/mail/sendmail.cf. Note that SENDMAIL_CF is now # deprecated. The value should be a fully qualified path name. # #SENDMAIL_MC=/etc/mail/myconfig.mc # # The following sets the default m4 configuration file for mail # submission to use at install time. Use with caution as a make # install will overwrite any existing /etc/mail/submit.cf. The # value should be a fully qualified path name. # #SENDMAIL_SUBMIT_MC=/etc/mail/mysubmit.mc # # If you need to build additional .cf files during a make buildworld, # include the full paths to the .mc files in SENDMAIL_ADDITIONAL_MC. # #SENDMAIL_ADDITIONAL_MC=/etc/mail/foo.mc /etc/mail/bar.mc # # The following overrides the default location for the m4 configuration # files used to build a .cf file from a .mc file. # #SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf # # Setting the following variable modifies the flags passed to m4 when # building a .cf file from a .mc file. It can be used to enable # features disabled by default. # #SENDMAIL_M4_FLAGS= # # Setting the following variables modifies the build environment for # sendmail and its related utilities. For example, SASL support can be # added with settings such as: # # with SASLv1: # SENDMAIL_CFLAGS=-I/usr/local/include/sasl1 -DSASL # SENDMAIL_LDFLAGS=-L/usr/local/lib # SENDMAIL_LDADD=-lsasl # # with SASLv2: # SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 # SENDMAIL_LDFLAGS=-L/usr/local/lib # SENDMAIL_LDADD=-lsasl2 # # Note: If you are using Cyrus SASL with other applications which require # access to the sasldb file, you should add the following to your # sendmail.mc file: # # define(`confDONT_BLAME_SENDMAIL',`GroupReadableSASLDBFile') # #SENDMAIL_CFLAGS= #SENDMAIL_LDFLAGS= #SENDMAIL_LDADD= #SENDMAIL_DPADD= # # Setting SENDMAIL_SET_USER_ID will install the sendmail binary as a # set-user-ID root binary instead of a set-group-ID smmsp binary and will # prevent the installation of /etc/mail/submit.cf. # This is a deprecated mode of operation. See etc/mail/README for more # information. # #SENDMAIL_SET_USER_ID= # # The permissions to use on alias and map databases generated using # /etc/mail/Makefile. Defaults to 0640. # #SENDMAIL_MAP_PERMS= -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From aragon at phat.za.net Tue Jul 7 13:07:54 2009 From: aragon at phat.za.net (Aragon Gouveia) Date: Tue Jul 7 13:08:02 2009 Subject: Can't get resume to work on -BETA1/-CURRENT-200906, help needed In-Reply-To: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> Message-ID: <4A5348A4.60401@phat.za.net> Hi, Gonzalo Nemmi wrote: > log in > acpiconf -s 3 > suspend works > opened the lid and the screen doesn't come back (backlight never gets back) > hard reset > login again and checked /var/log/messages .. this is what I found: I have problems with suspend too, on AMD64. Basically it works and my systems comes back up, but some devices are hosed afterwards. My bge network interface is one. I get precisely the same PHY timeout errors you're getting after a suspend. The iwn network driver screams the following if I try use it after a suspend: > Jul 7 14:53:17 fuzz kernel: iwn0: iwn_mem_lock: could not lock memory > Jul 7 14:53:17 fuzz last message repeated 7 times > Jul 7 14:53:17 fuzz kernel: iwn0: iwn_transfer_microcode: could not load boot firmware > Jul 7 14:53:17 fuzz kernel: iwn0: iwn_transfer_firmware: could not load boot firmware, error 60 > Jul 7 14:53:17 fuzz kernel: iwn0: iwn_init_locked: could not load firmware, error 60 USB ports resume sometimes, sometimes not: > Jul 7 14:58:44 fuzz kernel: usbus2: port reset timeout > Jul 7 14:58:44 fuzz kernel: uhub_reattach_port:369: port 1 reset failed, error=USB_ERR_TIMEOUT > Jul 7 14:58:44 fuzz kernel: uhub_reattach_port:456: device problem (USB_ERR_TIMEOUT), disabling port 1 > Jul 7 14:58:44 fuzz kernel: usbus6: port reset timeout > Jul 7 14:58:44 fuzz kernel: uhub_reattach_port:369: port 5 reset failed, error=USB_ERR_TIMEOUT > Jul 7 14:58:44 fuzz kernel: uhub_reattach_port:456: device problem (USB_ERR_TIMEOUT), disabling port 5 > Jul 7 14:58:55 fuzz kernel: uhci_interrupt: resume detect > Jul 7 14:58:55 fuzz kernel: ugen6.2: at usbus6 (disconnected) > Jul 7 14:58:55 fuzz kernel: ugen5.2: at usbus5 (disconnected) > Jul 7 14:58:56 fuzz kernel: usbus6: port reset timeout > Jul 7 14:58:56 fuzz kernel: uhub_reattach_port:369: port 6 reset failed, error=USB_ERR_TIMEOUT > Jul 7 14:58:56 fuzz kernel: uhub_reattach_port:456: device problem (USB_ERR_TIMEOUT), disabling port 6 And I just noticed this message: > Jul 7 14:53:36 fuzz kernel: calcru: runtime went backwards from 18237633 usec to 9377885 usec for pid 10 (idle) Unloading modules from the kernel prior to suspending doesn't seem to work either. On the upside, FreeBSD 8.0 boots rather quickly! :) Regards, Aragon From trasz at FreeBSD.org Tue Jul 7 13:08:13 2009 From: trasz at FreeBSD.org (Edward Tomasz Napierala) Date: Tue Jul 7 13:08:20 2009 Subject: RFC: ATA to CAM integration patch (INTEL DX58SO) In-Reply-To: <4A531F8D.5040009@icyb.net.ua> References: <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <200907062118.n66LIGRg043316@lava.sentex.ca> <20090706152351.S26418@pooker.samsco.org> <4A531F8D.5040009@icyb.net.ua> Message-ID: <20090707124956.GA31310@pin.if.uz.zgora.pl> On 0707T1312, Andriy Gapon wrote: > >> Still the box does a panic when writing to the disk that has bad > >> sectors on it. (I do newfs it between reboots). Again, not sure if > >> this is a "well, dont use a bad disk", but here is the panic again in > >> case it shows something useful. > >> > > > > This is a 'don't use a bad disk' panic; FreeBSD UFS and VM simply can't > > handle errors on reads or writes. > > I think that this is not generally true, especially about reads. > And wasn't there a FreeBSD Foundation sponsored project to fix panics caused by > media going away? I think that panics on I/O errors are related to that. Device going away is slightly different case, but I believe it shouldn't be generally true, except for filesystems with softupdates enabled. For the most part, softupdates don't even try to handle I/O errors - they just panic (e.g. "panic: softdep_move_dependencies: need merge code"). -- If you cut off my head, what would I say? Me and my head, or me and my body? From dan.naumov at gmail.com Tue Jul 7 13:05:34 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Tue Jul 7 13:22:51 2009 Subject: FreeBSD 8.0-BETA1 Available In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Message-ID: On Tue, Jul 7, 2009 at 3:33 AM, Ken Smith wrote: > Be careful if you have SCSI drives, more USB disks than just the memory > stick, etc - make sure /dev/da0 (or whatever you use) is the memory > stick. ?Using this image for livefs based rescue mode is known to not > work, that is one of the things still being worked on. Hey Just wanted a small clarification, does livefs based rescue mode mean "fixit environment" or not? I would like to do some configuration testing with 8.0-beta1, but applying the configuration pretty much requires working in FIXIT, since sysinstall isn't exactly up to the task. - Sincerely, Dan Naumov From rink at FreeBSD.org Tue Jul 7 13:35:10 2009 From: rink at FreeBSD.org (Rink Springer) Date: Tue Jul 7 13:35:18 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> Message-ID: <20090707133611.GA66072@rink.nu> On Tue, Jul 07, 2009 at 01:44:05PM +0100, Anton Shterenlikht wrote: > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > cpuid = 0 > > > KDB: enter: panic > > > [thread pid 67078 tid 100097 ] > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > Do you have a backtrace ? > > no, sorry, I was too quick to reboot. Shame... well, if you hit it again, please let me know. Haven't yet gotten it myself on my rx2600. > I tried to reproduce the error, got this on the way: > > # XXX: bogusly disabled high FP regs I get this message quite often as well; I intend to figure out what's going on. Marcel, if you have any idea, please let me know. Regards, -- Rink P.W. Springer - http://rink.nu "Doom, gloom and despair. I like it!" - Tiresias From mexas at bristol.ac.uk Tue Jul 7 14:42:25 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 7 14:42:37 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707133611.GA66072@rink.nu> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> Message-ID: <20090707144208.GA49582@mech-cluster238.men.bris.ac.uk> On Tue, Jul 07, 2009 at 03:36:11PM +0200, Rink Springer wrote: > On Tue, Jul 07, 2009 at 01:44:05PM +0100, Anton Shterenlikht wrote: > > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > > cpuid = 0 > > > > KDB: enter: panic > > > > [thread pid 67078 tid 100097 ] > > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > > > Do you have a backtrace ? > > > > no, sorry, I was too quick to reboot. > > Shame... well, if you hit it again, please let me know. Haven't yet > gotten it myself on my rx2600. > > > I tried to reproduce the error, got this on the way: > > > > # XXX: bogusly disabled high FP regs > > I get this message quite often as well; I intend to figure out what's > going on. Marcel, if you have any idea, please let me know. got it again. Note that I was doing "make -j10 buildworld", and when I got it first time I did "make -j6 buildworld". When I only run one process "make buildworld" I didn't get the panic, but stopped at some other error message. So, buildworld stops at: ===> gnu/usr.bin/cc/cc1 (all) cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/main.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-parser.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-pa rser.o c-lang.o /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbac kend.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /usr/o bj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /usr/ob j/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a -legacy ../cc_tools/genchecksum cc1-dummy > cc1-checksum.c and on the console (MP via LAN on rx2600): # panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 cpuid = 1 KDB: enter: panic [thread pid 46793 tid 100148 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; db> bt Tracing pid 46793 tid 100148 td 0xe000000011b22760 kdb_enter(0xe000000004b43148, 0xe000000004b43148, 0xe0000000045f2a20, 0x793) at kdb_enter+0x92 panic(0xe000000004b41618, 0xe000000004b810c0, 0x2a8, 0xe000000011b229dc, 0xe0000 00011b229da) at panic+0x2f0 _mtx_lock_spin_flags(0xe000000015220a70, 0x0, 0xe000000004b810c0, 0x2a8, 0x20000 00000072200, 0x2000000040107010, 0xe000000004ac1c30, 0x716) at _mtx_lock_spin_fl ags+0x90 trap(0x19, 0xa000000032c09400) at trap+0xdb0 ivt_Disabled_FP_Register() at ivt_Disabled_FP_Register+0x30 db> I'Il try to start just 2 processes and see what happens. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From dnelson at allantgroup.com Tue Jul 7 14:46:43 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Tue Jul 7 14:46:50 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> Message-ID: <20090707144554.GF5574@dan.emsphone.com> In the last episode (Jul 07), Anton Shterenlikht said: > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > cpuid = 0 > > > KDB: enter: panic > > > [thread pid 67078 tid 100097 ] > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > Do you have a backtrace ? > > no, sorry, I was too quick to reboot. > I tried to reproduce the error, got this on the way: If you add "options KDB_TRACE" to your kernel config, you'll get a stack trace automatically on every panic. > # XXX: bogusly disabled high FP regs > > which is reported from by sys/ia64/ia64/trap.c, and then this error > (but no panic this time): > > ===> usr.bin/yacc (all) > cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/closure.c [...] > cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypwhich ypwhich.o > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error There are no errors in this output; just make reporting that there was an error. At -j6, the error message itself may be hundreds of lines back. Make lets all remaining parallel jobs finish before exiting. -- Dan Nelson dnelson@allantgroup.com From matheus at eternamente.info Tue Jul 7 14:57:56 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Tue Jul 7 14:58:03 2009 Subject: FreeBSD 8.0-BETA1 Available In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Message-ID: <8c26b091724a0709f2749cc3e8951f50.squirrel@cygnus.homeunix.com> great this new usb image. will be pretty handy I'm sure :) matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From mexas at bristol.ac.uk Tue Jul 7 15:00:59 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 7 15:01:06 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707144554.GF5574@dan.emsphone.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707144554.GF5574@dan.emsphone.com> Message-ID: <20090707150052.GA49701@mech-cluster238.men.bris.ac.uk> On Tue, Jul 07, 2009 at 09:45:54AM -0500, Dan Nelson wrote: > In the last episode (Jul 07), Anton Shterenlikht said: > > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > > cpuid = 0 > > > > KDB: enter: panic > > > > [thread pid 67078 tid 100097 ] > > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > > > Do you have a backtrace ? > > > > no, sorry, I was too quick to reboot. > > I tried to reproduce the error, got this on the way: > > If you add "options KDB_TRACE" to your kernel config, you'll get a stack > trace automatically on every panic. actually, I'll rebuild a kernel first, and then try to rebuid world. I'll put this in as well. Do I still need options KDB # Enable kernel debugger support if I put options KDB_TRACE? > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > There are no errors in this output; just make reporting that there was an > error. At -j6, the error message itself may be hundreds of lines back. > Make lets all remaining parallel jobs finish before exiting. ok, thanks, will keep in mind. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From sagara at tomahawk.com.sg Tue Jul 7 14:40:35 2009 From: sagara at tomahawk.com.sg (Sagara Wijetunga) Date: Tue Jul 7 15:48:52 2009 Subject: FreeBSD 8.0-BETA1 Available In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Message-ID: <20090707105550.23013.qmail@us1.tomahawkonline.net> Ken Smith writes: > > The first public test build of the FreeBSD 8.0-RELEASE test cycle is now > available, 8.0-BETA1. Through the next week or so more information > about the release will be posted but here is the current target schedule > for the other 'major events': > > BETA2: July 13, 2009 > BETA3: July 20, 2009 > RC1: July 27, 2009 > RC2: August 17, 2009 > RELEASE:August 31, 2009 > Hi all Congratulations! This is a very good news though we did not expect FreeBSD 8.0 this soon. We planed our Tomahawk Desktop 3.0 to be based on FreeBSD 8.0. Now days we are very busy finalising the Tomahawk Desktop 2.0 beta to be released somewhere in August. Will sure give FreeBSD 8.0 a try after we released our 2.0 beta. We wish good luck to FreeBSD 8.0 team. Best regards Sagara From dnelson at allantgroup.com Tue Jul 7 17:57:40 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Tue Jul 7 17:57:47 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707150052.GA49701@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707144554.GF5574@dan.emsphone.com> <20090707150052.GA49701@mech-cluster238.men.bris.ac.uk> Message-ID: <20090707175735.GG5574@dan.emsphone.com> In the last episode (Jul 07), Anton Shterenlikht said: > On Tue, Jul 07, 2009 at 09:45:54AM -0500, Dan Nelson wrote: > > In the last episode (Jul 07), Anton Shterenlikht said: > > > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > > > cpuid = 0 > > > > > KDB: enter: panic > > > > > [thread pid 67078 tid 100097 ] > > > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > > > > > Do you have a backtrace ? > > > > > > no, sorry, I was too quick to reboot. I tried to reproduce the error, > > > got this on the way: > > > > If you add "options KDB_TRACE" to your kernel config, you'll get a stack > > trace automatically on every panic. > > actually, I'll rebuild a kernel first, and then try to rebuid world. I'll > put this in as well. Do I still need > > options KDB # Enable kernel debugger support > > if I put options KDB_TRACE? I always have both, so I don't know if one requires the other. You should get a compile error if KDB is required and it's not listed. -- Dan Nelson dnelson@allantgroup.com From kensmith at cse.Buffalo.EDU Tue Jul 7 18:07:49 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Tue Jul 7 18:08:03 2009 Subject: FreeBSD 8.0-BETA1 Available In-Reply-To: References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Message-ID: <1246990063.25765.18.camel@bauer.cse.buffalo.edu> On Tue, 2009-07-07 at 16:05 +0300, Dan Naumov wrote: > Just wanted a small clarification, does livefs based rescue mode mean > "fixit environment" or not? Yes, that's what it means. It's known to not work at the moment but it's being worked on. I wanted to mention that because it might have been confusing given what I put onto it (the files needed for livefs mode are on it, sysinstall itself needs a bit more work though). But once that is working this is my guess as to what people would find most useful on such an image so I wanted to give people a feel for roughly how big they'll wind up being. It will basically be the dvd minus packages. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090707/6df82179/attachment.pgp From hselasky at c2i.net Tue Jul 7 18:39:53 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Jul 7 18:40:01 2009 Subject: ulpt problem (USB_ERR_IOERROR) In-Reply-To: <200907061750.39084.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <20090706161154.06abb3cd@baby-jane.lamaiziere.net> <200907061750.39084.hselasky@c2i.net> Message-ID: <200907072039.27811.hselasky@c2i.net> On Monday 06 July 2009 17:50:37 Hans Petter Selasky wrote: > On Monday 06 July 2009 16:11:54 Patrick Lamaiziere wrote: > > > > Shall I setup another box with current to be sure that's a problem > > with the printer and not with the hardware? > > Hi, > > urlpt was just for backwards compatibility. > > Could you try printing using /dev/unlpt0 ? And send me resulting dmesg? > > Power cycle your printer before testing. Hi, There was a small bug in my patch. Could you post-patching edit /sys/dev/serial/ulpt.c And move the: /* set raw write mode */ if (fflags & FWRITE) { usb_fifo_set_write_defrag(fifo, 0); } And: /* set defrag write mode */ if (fflags & FWRITE) { usb_fifo_set_write_defrag(fifo, 1); } outside the "if (sc->sc_fflags == 0)", so that the code looks like this: static int urlpt_open(struct usb_fifo *fifo, int fflags) { struct ulpt_softc *sc = usb_fifo_softc(fifo); /* we assume that open is a serial process */ if (sc->sc_fflags == 0) { /* reset USB paralell port */ ulpt_reset(sc); } /* set raw write mode */ if (fflags & FWRITE) { usb_fifo_set_write_defrag(fifo, 0); } return (unlpt_open(fifo, fflags)); } static int ulpt_open(struct usb_fifo *fifo, int fflags) { struct ulpt_softc *sc = usb_fifo_softc(fifo); /* we assume that open is a serial process */ if (sc->sc_fflags == 0) { /* reset USB paralell port */ ulpt_reset(sc); } /* set defrag write mode */ if (fflags & FWRITE) { usb_fifo_set_write_defrag(fifo, 1); } return (unlpt_open(fifo, fflags)); } --HPS From h.schmalzbauer at omnilan.de Tue Jul 7 18:49:34 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Tue Jul 7 18:49:41 2009 Subject: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) In-Reply-To: <4A5053A8.2060902@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> Message-ID: <4A5398B5.40308@omnilan.de> Alexander Motin schrieb am 05.07.2009 09:18 (localtime): ... >> Can I safely remove glabel from the unmounted fs and relabel the new >> device? > > I don't very understand whet you mean by "safe"? Safe for what? I tuned off journaling in UFS and removed the journal from the partition. Although gjournal told me that the existing filesystem will be destroyed this didn't happen since I did the newfs on the .journal partition originally. That's what I meant as "safe". In theory it was clear that I can safely relabel the partition, but I was not sure if I understood everything correctly. So far I have not had any problems with ahci, works great! (ich9) At least with HDs, haven't tested ODDs yet. (I'm having burning problems for a long time so I'm not used to use ODDs with FreeBSD) One thing I'm missing is the possibility to spin down the drive. I have my system on a SSD, the HD is just for ports nad stuff which usually I don't make use of. Is that planned to be integrated? Another question is why "camcontrol tur ada0" returns "Unit is not ready" readcap also doesn't work. My SSD reports write and read cache present, but disabled. Is the report or the status bad? camcontrol iden ada0 pass1: ATA/ATAPI-8 SATA 2.x device Protocol SATA revision 2.x device model OCZ SOLID SSD serial number MK0508480C17B0004 firmware revision 02.10104 cylinders 16383 heads 16 sectors/track 63 lba supported 62586880 sectors lba48 not supported dma supported overlap not supported Feature Support Enable Value Vendor write cache yes no read ahead yes no Native Command Queuing (NCQ) no - 0/0x00 Tagged Command Queuing (TCQ) no no 0/0x00 SMART yes yes microcode download no no security no no power management yes yes advanced power management no no 0/0x00 automatic acoustic management no no 254/0xFE 128/0x80 Thansk for your great work so far! Best regards, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090707/40613275/signature.pgp From h.schmalzbauer at omnilan.de Tue Jul 7 18:57:40 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Tue Jul 7 18:57:47 2009 Subject: Where to report LORs? (ffs and unionfs LORs included Message-ID: <4A539AA0.3030901@omnilan.de> Hello, I remember when 7.0 was -current there was a specioal LOR reporting site. Is it still the best place to report LORs? Currently I have some of them: lock order reversal: 1st 0xc88d88b8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:492 2nd 0xd9ae0fb0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6170 3rd 0xc9d6a9c4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,ec8272cc,c05cfd9f,c05c170b,c0845f64,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f64,c5a0ee28,c5a12a48,ec827328,...) at kdb_backtrace+0x29 _witness_debugger(c0845f64,c9d6a9c4,c0838ab3,c5a12a48,c084d2d2,...) at _witness_debugger+0x1e witness_checkorder(c9d6a9c4,9,c084d2d2,823,0,...) at witness_checkorder+0x815 __lockmgr_args(c9d6a9c4,80100,c9d6a9e0,0,0,...) at __lockmgr_args+0x771 ffs_lock(ec827430,c05cfb7b,c084c7c5,80100,c9d6a96c,...) at ffs_lock+0x7d VOP_LOCK1_APV(c08ad460,ec827430,cae79524,c08c33a0,c9d6a96c,...) at VOP_LOCK1_APV+0xaf _vn_lock(c9d6a96c,80100,c084d2d2,823,4,...) at _vn_lock+0x5e vget(c9d6a96c,80100,cae79480,50,0,...) at vget+0xb8 vfs_hash_get(cb207c94,9bc0b,80000,cae79480,ec82758c,...) at vfs_hash_get+0xdf ffs_vgetf(cb207c94,9bc0b,80000,ec82758c,1,...) at ffs_vgetf+0x43 softdep_sync_metadata(c88d8860,0,c085ff5b,146,0,...) at softdep_sync_metadata+0x5a6 ffs_syncvnode(c88d8860,1,ec827624,c05cfb7b,c083e509,...) at ffs_syncvnode+0x3c9 ffs_truncate(c88d8860,200,0,880,cb0fc400,...) at ffs_truncate+0x644 ufs_direnter(c88d8860,cd399d9c,ec8278e4,ec827bd8,0,...) at ufs_direnter+0x8e0 ufs_makeinode(ec827bd8) at ufs_makeinode+0x4df ufs_create(ec827acc,ec827ae4,0,0,ec827bac,...) at ufs_create+0x2c VOP_CREATE_APV(c08ad460,ec827acc,ec827bd8,ec827a64,0,...) at VOP_CREATE_APV+0xa2 vn_open_cred(ec827bac,ec827c60,1a4,0,cb0fc400,...) at vn_open_cred+0x1fc vn_open(ec827bac,ec827c60,1a4,c7e080e0,c08e0102,...) at vn_open+0x3b kern_openat(cae79480,ffffff9c,33f53970,0,602,...) at kern_openat+0x116 kern_open(cae79480,33f53970,0,601,1b6,...) at kern_open+0x35 open(cae79480,ec827cf8,c,ec827d2c,c088e6ec,...) at open+0x30 syscall(ec827d38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x33dd10fb, esp = 0xbfbfe02c, ebp = 0xbfbfe0b8 --- These two are with unionfs: lock order reversal: 1st 0xc62f08b8 unionfs (unionfs) @ /usr/src/sys/fs/unionfs/union_subr.c:356 2nd 0xc62f09c4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2188 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,e83a1868,c05cfd9f,c05c170b,c0845f4b,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f4b,c5a12b80,c5a12a48,e83a18c4,...) at kdb_backtrace+0x29 _witness_debugger(c0845f4b,c62f09c4,c0838ab3,c5a12a48,c084d2d2,...) at _witness_debugger+0x1e witness_checkorder(c62f09c4,9,c084d2d2,88c,0,...) at witness_checkorder+0x815 __lockmgr_args(c62f09c4,80100,c62f09e0,0,0,...) at __lockmgr_args+0x771 ffs_lock(e83a19cc,c5a12b80,c084d2d2,80100,c62f096c,...) at ffs_lock+0x7d VOP_LOCK1_APV(c08ad460,e83a19cc,c0582686,c08c33a0,c62f096c,...) at VOP_LOCK1_APV+0xaf _vn_lock(c62f096c,80100,c084d2d2,88c,c07ff2d1,...) at _vn_lock+0x5e vrele(c62f096c,e83a1a54,c62f08d4,0,0,...) at vrele+0x126 unionfs_noderem(c62f0860,c61d6480,e83a1a94,c07fe256,e83a1ab4,...) at unionfs_noderem+0x4ac unionfs_reclaim(e83a1ab4,1,0,c62f0860,e83a1ad8,...) at unionfs_reclaim+0x1b VOP_RECLAIM_APV(c088b7c0,e83a1ab4,0,0,c62f08d4,...) at VOP_RECLAIM_APV+0x9f vgonel(c62f08d4,0,c084d2d2,9c5,e83a1b38,...) at vgonel+0x1a9 vrecycle(c62f0860,c61d6480,e83a1b20,c07fe326,e83a1b38,...) at vrecycle+0x45 unionfs_inactive(e83a1b38,c62f08d4,c62f0860,c62f08d4,e83a1b50,...) at unionfs_inactive+0x28 VOP_INACTIVE_APV(c088b7c0,e83a1b38,c084d2d2,924,c08c3360,...) at VOP_INACTIVE_APV+0xa0 vinactive(c088b7c0,e83a1b6c,c084d2d2,8aa,e83a1bfc,...) at vinactive+0x82 vput(c62f0860,e83a1c1c,c08409ec,64a,400,...) at vput+0x1c0 kern_readlinkat(c61d6480,ffffff9c,33d7898f,0,bfbfe003,...) at kern_readlinkat+0x16d kern_readlink(c61d6480,33d7898f,0,bfbfe003,0,...) at kern_readlink+0x3c readlink(c61d6480,e83a1cf8,c,c0846dc1,c088ecb8,...) at readlink+0x38 syscall(e83a1d38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (58, FreeBSD ELF32, readlink), eip = 0x33cfb3ff, esp = 0xbfbfdf8c, ebp = 0xbfbfe418 --- lock order reversal: 1st 0xc794082c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1088 2nd 0xc7f4bce8 ufs (ufs) @ /usr/src/sys/fs/unionfs/union_vnops.c:1821 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,e847b9d0,c05cfd9f,c05c170b,c0845f4b,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f4b,c5a0f100,c5a12a48,e847ba2c,...) at kdb_backtrace+0x29 _witness_debugger(c0845f4b,c7f4bce8,c0838ab3,c5a12a48,c0834c57,...) at _witness_debugger+0x1e witness_checkorder(c7f4bce8,9,c0834c57,71d,0,...) at witness_checkorder+0x815 __lockmgr_args(c7f4bce8,80500,c7f4bd04,0,0,...) at __lockmgr_args+0x771 ffs_lock(e847bb4c,df,80500,80500,c7f5210c,...) at ffs_lock+0x7d VOP_LOCK1_APV(c08ad460,e847bb4c,c0834c57,71a,100000,...) at VOP_LOCK1_APV+0xaf unionfs_lock(e847bb9c,4,0,80400,c7f5210c,...) at unionfs_lock+0x1d2 VOP_LOCK1_APV(c088b7c0,e847bb9c,c083acd9,c08c33a0,c7f5210c,...) at VOP_LOCK1_APV+0xaf _vn_lock(c7f5210c,80400,c084d2d2,ffb,e847bbf8,...) at _vn_lock+0x5e vfs_knllock(c7f5210c,0,c083acd9,696,c7f4d088,...) at vfs_knllock+0x29 knlist_remove_kq(0,e847bc18,c0618395,c7d3801c,c7f4d088,...) at knlist_remove_kq+0x85 knlist_remove(c7d3801c,c7f4d088,0,e847bc44,c05625ae,...) at knlist_remove+0x1b filt_vfsdetach(c7f4d088,0,c083acd9,777,d,...) at filt_vfsdetach+0x39 knote_fdclose(c70f3b40,12cd,c083a810,440,c794082c,...) at knote_fdclose+0xec kern_close(c70f3b40,12cd,e847bd2c,c07f304a,c70f3b40,...) at kern_close+0xc8 close(c70f3b40,e847bcf8,4,c0846835,c088e708,...) at close+0x1a syscall(e847bd38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x33f6de2b, esp = 0xbfbfe71c, ebp = 0xbfbfe738 --- Some more: lock order reversal: 1st 0xd9914750 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xc613f800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,e850e864,c05cfd9f,c05c170b,c0845f4b,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f4b,c5a0ee28,c5a12ab0,e850e8c0,...) at kdb_backtrace+0x29 _witness_debugger(c0845f4b,c613f800,c0860649,c5a12ab0,c08602e2,...) at _witness_debugger+0x1e witness_checkorder(c613f800,9,c08602e2,11d,0,...) at witness_checkorder+0x815 _sx_xlock(c613f800,0,c08602e2,11d,c70ca244,...) at _sx_xlock+0x7f ufsdirhash_acquire(d99146f0,e850e9d8,174,da423aa4,e850e990,...) at ufsdirhash_acquire+0x31 ufsdirhash_add(c70ca244,e850e9d8,aa4,e850e97c,e850e980,...) at ufsdirhash_add+0x13 ufs_direnter(c70d2a78,c799e430,e850e9d8,e850ebe0,0,...) at ufs_direnter+0x713 ufs_makeinode(e850ebe0) at ufs_makeinode+0x4df ufs_create(e850ec04,e850ec18,e850eb4c,e850eb4c,0,...) at ufs_create+0x2c VOP_CREATE_APV(c08ad460,e850ec04,e850ebe0,e850eb4c,c6408aac,...) at VOP_CREATE_APV+0xa2 uipc_bind(c7266ce0,c70df300,c7272b40,e850ec64,c05fa439,...) at uipc_bind+0x31f sobind(c7266ce0,c70df300,c7272b40,c70df300,c71fee70,...) at sobind+0x23 kern_bind(c7272b40,4,c70df300,c70df300,c71c8d48,...) at kern_bind+0xaf bind(c7272b40,e850ecf8,c,c0846835,c088f1c0,...) at bind+0x42 syscall(e850ed38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (104, FreeBSD ELF32, bind), eip = 0x33d91bd3, esp = 0xbfbfe87c, ebp = 0xbfbfe978 --- lock order reversal: 1st 0xc7fb012c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1088 2nd 0xcac46ad0 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_subr.c:4091 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,e84fba44,c05cfd9f,c05c170b,c0845f4b,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f4b,c5a0f100,c5a12be8,e84fbaa0,...) at kdb_backtrace+0x29 _witness_debugger(c0845f4b,cac46ad0,c08340c3,c5a12be8,c084d2d2,...) at _witness_debugger+0x1e witness_checkorder(cac46ad0,9,c084d2d2,ffb,cac46aec,...) at witness_checkorder+0x815 __lockmgr_args(cac46ad0,80400,cac46aec,0,0,0,c084d2d2,ffb) at __lockmgr_args+0x771 vop_stdlock(e84fbb9c,4,0,80400,cac46a78,...) at vop_stdlock+0x5c VOP_LOCK1_APV(c088b540,e84fbb9c,c083acd9,c08c33a0,cac46a78,...) at VOP_LOCK1_APV+0xaf _vn_lock(cac46a78,80400,c084d2d2,ffb,e84fbbf8,...) at _vn_lock+0x5e vfs_knllock(cac46a78,0,c083acd9,696,c703a94c,...) at vfs_knllock+0x29 knlist_remove_kq(0,e84fbc18,c0618395,cacf0364,c703a94c,...) at knlist_remove_kq+0x85 knlist_remove(cacf0364,c703a94c,0,e84fbc44,c05625ae,...) at knlist_remove+0x1b filt_vfsdetach(c703a94c,0,c083acd9,777,16,...) at filt_vfsdetach+0x39 knote_fdclose(c70f4b40,d6,c083a810,440,c7fb012c,...) at knote_fdclose+0xec kern_close(c70f4b40,d6,e84fbd2c,c07f304a,c70f4b40,...) at kern_close+0xc8 close(c70f4b40,e84fbcf8,4,c085afd4,c088e708,...) at close+0x1a syscall(e84fbd38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x33f6de2b, esp = 0xbfbfe5bc, ebp = 0xbfbfe5d8 --- lock order reversal: 1st 0xc7917880 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1112 2nd 0xc1c900e8 system map (system map) @ /usr/src/sys/vm/vm_map.c:2762 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,e847b960,c05cfd9f,c05c170b,c0845f4b,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f4b,c5a0c318,c5a0c178,e847b9bc,...) at kdb_backtrace+0x29 _witness_debugger(c0845f4b,c1c900e8,c0861f20,c5a0c178,c086243d,...) at _witness_debugger+0x1e witness_checkorder(c1c900e8,9,c086243d,aca,0,...) at witness_checkorder+0x815 _mtx_lock_flags(c1c900e8,0,c086243d,aca,c7b3c000,...) at _mtx_lock_flags+0xb8 _vm_map_lock(c1c9008c,c086243d,aca,c79956a8,c7b3a000,...) at _vm_map_lock+0x31 vm_map_remove(c1c9008c,c7b3a000,c7b3c000,e847ba48,c078d0b9,...) at vm_map_remove+0x2a kmem_free(c1c9008c,c7b3a000,2000,e847ba60,c078df06,...) at kmem_free+0x30 page_free(c7b3a000,2000,22,2000,e847ba84,...) at page_free+0x46 uma_large_free(c79956a8,c083acd9,458,c7b3a000,600,...) at uma_large_free+0x89 free(c7b3a000,c0892874,1400,458,c7917880,...) at free+0xe9 kqueue_expand(0,500,e847baec,328,df,...) at kqueue_expand+0xf4 kqueue_register(1,e847bb48,1,0,0,...) at kqueue_register+0x11e kern_kevent(c70f3b40,3,1,0,e847bc5c,...) at kern_kevent+0xd7 kevent(c70f3b40,e847bcf8,18,c0846c74,c0890e14,...) at kevent+0x197 syscall(e847bd38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (363, FreeBSD ELF32, kevent), eip = 0x33f50c2b, esp = 0xbfbfe48c, ebp = 0xbfbfe6a8 --- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090707/6692a3a3/signature.pgp From mav at FreeBSD.org Tue Jul 7 19:06:28 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jul 7 19:06:34 2009 Subject: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) In-Reply-To: <4A5398B5.40308@omnilan.de> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <4A5398B5.40308@omnilan.de> Message-ID: <4A539CA3.5030104@FreeBSD.org> Harald Schmalzbauer wrote: > One thing I'm missing is the possibility to spin down the drive. > I have my system on a SSD, the HD is just for ports nad stuff which > usually I don't make use of. > Is that planned to be integrated? There is no problem, it just wasn't done yet. It should be possible to submit respective ATA command via CAM pass interface to spin-down drive immediately or to set wanted power management level, but respective user-level part in camcontrol is also not implemented yet. > Another question is why "camcontrol tur ada0" returns "Unit is not ready" > readcap also doesn't work. It is all SCSI commands. This implementation expects real direct ATA operation without SCSI emulation parts. But this commands should work for ATAPI devices, that are really SCSI deep inside. > My SSD reports write and read cache present, but disabled. Is the report > or the status bad? > Feature Support Enable Value Vendor > write cache yes no > read ahead yes no It is probably the truth. Existing ATA driver enables this features during drive reset sequence. New one doesn't do it yet. -- Alexander Motin From h.schmalzbauer at omnilan.de Tue Jul 7 19:10:53 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Tue Jul 7 19:11:00 2009 Subject: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) In-Reply-To: <4A539CA3.5030104@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <4A5398B5.40308@omnilan.de> <4A539CA3.5030104@FreeBSD.org> Message-ID: <4A539DBA.3080702@omnilan.de> Alexander Motin schrieb am 07.07.2009 21:06 (localtime): ... Thanks for your aeplanations! >> Feature Support Enable Value Vendor >> write cache yes no >> read ahead yes no > > It is probably the truth. Existing ATA driver enables this features > during drive reset sequence. New one doesn't do it yet. Ic, but my "real" HD ast it enabled: camcontrol iden ada1 pass2: ATA/ATAPI-7 SATA 2.x device Protocol SATA revision 2.x device model SAMSUNG HD322HJ serial number S17AJ9AS305229 firmware revision 1AG01113 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 625142448 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management yes no 0/0x00 254/0xFE Does the old school HD enable caches itself? Thanks, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090707/b4247ba4/signature.pgp From mav at FreeBSD.org Tue Jul 7 19:16:01 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jul 7 19:16:07 2009 Subject: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) In-Reply-To: <4A539DBA.3080702@omnilan.de> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <4A5398B5.40308@omnilan.de> <4A539CA3.5030104@FreeBSD.org> <4A539DBA.3080702@omnilan.de> Message-ID: <4A539EDF.8080302@FreeBSD.org> Harald Schmalzbauer wrote: > Alexander Motin schrieb am 07.07.2009 21:06 (localtime): > ... > Thanks for your aeplanations! > >>> Feature Support Enable Value Vendor >>> write cache yes no >>> read ahead yes no >> >> It is probably the truth. Existing ATA driver enables this features >> during drive reset sequence. New one doesn't do it yet. > > Ic, but my "real" HD ast it enabled: > > Does the old school HD enable caches itself? Yes. At least this specific one. My OCZ Vertex SSD also has them enabled by default. -- Alexander Motin From alexbestms at math.uni-muenster.de Tue Jul 7 19:34:05 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Tue Jul 7 19:34:12 2009 Subject: Where to report LORs? (ffs and unionfs LORs included Message-ID: try http://sources.zabbadoz.net/freebsd/lor.html alex From ianjhart at ntlworld.com Tue Jul 7 20:03:52 2009 From: ianjhart at ntlworld.com (Ian J Hart) Date: Tue Jul 7 20:03:59 2009 Subject: zpool scrub errors on 3ware 9550SXU In-Reply-To: <20090624153442.137934uzyotkb5og@10.248.192.16> References: <20090624153442.137934uzyotkb5og@10.248.192.16> Message-ID: <20090707210345.13681mi2dwvan78k@webmail.private.lan> Quoting ianjhart@ntlworld.com: > Quoting ianjhart@ntlworld.com: > >> Quoting Kip Macy : >> >>>> >>>> As usual scrubs cleanly on 7.2. Started throwing errors within a >>>> few minutes under 8. Then it paniced, possibly due to scrub -s. >>>> >>>> It's sat at the DB prompt if there's anything I can do. I'll need >>>> idiots guide level instruction. I have a screen dump if someone >>>> want to step up. Off list? >>>> >>>> Highlight seems to be... >>>> >>>> Memory modified after free 0xffffff0004da0c00(248) val=3000000 @ >>>> 0xffffff0004dc00 >>>> Panic: most recently used by none >>> >>> Can you test with recent 7-STABLE? That would tell me whether or not >>> your hitting a general HEAD issues or problems with the v13 import. >> >> It's doing a scrub under 7.2 following another failed test. I'll >> pull it up to stable after that. >> >> Have more data will post that once I've done a couple a jobs. >> >>> >>> Thanks, >>> Kip > > Here's that extra data. > > Updated 3ware/AMCC card firmware. > > Enable onboard SATA and fit a 300GB SATA disk. Remove the floppy and > fit a second 300GB SATA disk. > > Remove the two 500GB disks and replace with 1.5TB units. I can now > create two 8 disk raidz2 giving the same 12 disks worth of storage I > had with one 14 disk raidz2. > > Reinstall the two O/S on the 300GB drives. > > > May be of use to someone, so bear with me. > > Reset to BIOS defaults. Some issues! Disabling sound helps. > > Now suspect motherboard BIOS may be part of the problem. Removed > both cards and tested each version in turn. > > ref: http://www.tyan.com.tw/support_download_bios.aspx?model=S.S2895 > > Started with 1.04 ended up with 1.04. Versions after, detect the > internal; SATA disks as 150 not 300. Most versions lock the keyboard > (KVM) when legacy USB is enabled. That's a PITA when you've just > taken the floopy disk out.No internal SATA disk settings. Be nice to > check the geometry as 7 and 8 sysinstall seem to be behaving > differently. > > With the cards back in. > > Add an ATA disk and CDROM while testing.Easyboot order is SATA0 ATA0 > SATA1. Fdisk the so far blank ATA disk :) > > On board audio clashes with something. BIOS 1.03 and later supports > 16 SCSI boot devices. I disabled booting from the RAID card to allow > the onboard SATA drives to boot. > > Out of space for option ROM error has gone. > > AFAIK CPUs are late enough to support DDR400. Check anyway. Clock > down to 333Mhz. Still fails. > > > > There's one last thing, this BIOS (1.04) does not supply the fix for > AMD errata 169. Later BIOS incorrectly detect the onboard SATA disks. > > Northbridge System Request Queue may stall. > > ref: > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf > > We don't seem to have /dev/msr. Could I fix this using (the shiny > new) cpucontrol? > > Thanks > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > _______________________________________________ > 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" > FWIW this is still reproducable with 8.0-BETA1. -- ian j hart ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From kmacy at freebsd.org Tue Jul 7 21:12:05 2009 From: kmacy at freebsd.org (Kip Macy) Date: Tue Jul 7 21:12:12 2009 Subject: zpool scrub errors on 3ware 9550SXU In-Reply-To: <20090707210345.13681mi2dwvan78k@webmail.private.lan> References: <20090624153442.137934uzyotkb5og@10.248.192.16> <20090707210345.13681mi2dwvan78k@webmail.private.lan> Message-ID: <3c1674c90907071412t346b1591rfecfae22bb60a8f5@mail.gmail.com> Did you answer my question of whether or not this can be reproduced on 7-STABLE? -Kip On Tue, Jul 7, 2009 at 1:03 PM, Ian J Hart wrote: > Quoting ianjhart@ntlworld.com: > >> Quoting ianjhart@ntlworld.com: >> >>> Quoting Kip Macy : >>> >>>>> >>>>> As usual scrubs cleanly on 7.2. Started throwing errors within a few >>>>> minutes under 8. Then it paniced, possibly due to scrub -s. >>>>> >>>>> It's sat at the DB prompt if there's anything I can do. I'll need >>>>> idiots guide level instruction. I have a screen dump if someone want to step >>>>> up. Off list? >>>>> >>>>> Highlight seems to be... >>>>> >>>>> Memory modified after free 0xffffff0004da0c00(248) val=3000000 @ >>>>> 0xffffff0004dc00 >>>>> Panic: most recently used by none >>>> >>>> Can you test with recent 7-STABLE? That would tell me whether or not >>>> your hitting a general HEAD issues or problems with the v13 import. >>> >>> It's doing a scrub under 7.2 following another failed test. I'll pull it >>> up to stable after that. >>> >>> Have more data will post that once I've done a couple a jobs. >>> >>>> >>>> Thanks, >>>> Kip >> >> Here's that extra data. >> >> Updated 3ware/AMCC card firmware. >> >> Enable onboard SATA and fit a 300GB SATA disk. Remove the floppy and fit a >> second 300GB SATA disk. >> >> Remove the two 500GB disks and replace with 1.5TB units. I can now create >> two 8 disk raidz2 giving the same 12 disks worth of storage I had with one >> 14 disk raidz2. >> >> Reinstall the two O/S on the 300GB drives. >> >> >> May be of use to someone, so bear with me. >> >> Reset to BIOS defaults. Some issues! Disabling sound helps. >> >> Now suspect motherboard BIOS may be part of the problem. Removed both >> cards and tested each version in turn. >> >> ref: http://www.tyan.com.tw/support_download_bios.aspx?model=S.S2895 >> >> Started with 1.04 ended up with 1.04. Versions after, detect the internal; >> SATA disks as 150 not 300. Most versions lock the keyboard (KVM) when legacy >> USB is enabled. That's a PITA when you've just taken the floopy disk out.No >> internal SATA disk settings. Be nice to check the geometry as 7 and 8 >> sysinstall seem to be behaving differently. >> >> With the cards back in. >> >> Add an ATA disk and CDROM while testing.Easyboot order is SATA0 ATA0 >> SATA1. Fdisk the so far blank ATA disk :) >> >> On board audio clashes with something. BIOS 1.03 and later supports 16 >> SCSI boot devices. I disabled booting from the RAID card to allow the >> onboard SATA drives to boot. >> >> Out of space for option ROM error has gone. >> >> AFAIK CPUs are late enough to support DDR400. Check anyway. Clock down to >> 333Mhz. Still fails. >> >> >> >> There's one last thing, this BIOS (1.04) does not supply the fix for AMD >> errata 169. Later BIOS incorrectly detect the onboard SATA disks. >> >> Northbridge System Request Queue may stall. >> >> ref: >> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf >> >> We don't seem to ?have /dev/msr. Could I fix this using (the shiny new) >> cpucontrol? >> >> Thanks >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> _______________________________________________ >> 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" >> > > FWIW this is still reproducable with 8.0-BETA1. > > -- > ian j hart > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > _______________________________________________ > 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 xcllnt at mac.com Wed Jul 8 00:13:21 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Jul 8 00:13:27 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> Message-ID: On Jul 7, 2009, at 2:48 AM, Anton Shterenlikht wrote: > on the console I get: > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/ > trap.c:680 > cpuid = 0 > KDB: enter: panic > [thread pid 67078 tid 100097 ] > Stopped at kdb_enter+0x92: [I2] addl > r14=0xffffffffffe2a8e8,gp ;; > db> This is already fixed. Just update your sources, build a new kernel, install it and reboot. Then you can continue the buildworld safely... FYI, -- Marcel Moolenaar xcllnt@mac.com From gnemmi at gmail.com Wed Jul 8 00:28:56 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Wed Jul 8 00:29:03 2009 Subject: Fatal trap 9 on -BETA1 on boot "with ACPI disabled" or "Safe Mode": In-Reply-To: <1246963840.48637.44.camel@buffy.york.ac.uk> References: <19e9a5dc0907062254u528c4a8ahea2a605e80b1feea@mail.gmail.com> <1246963840.48637.44.camel@buffy.york.ac.uk> Message-ID: <200907072129.01232.gnemmi@gmail.com> On Tuesday 07 July 2009 7:50:40 am Gavin Atkinson wrote: > On Tue, 2009-07-07 at 02:54 -0300, Gonzalo Nemmi wrote: > > Can reproduce it on -CURRENT-200906 and -BETA1 whenever I try to > > boot "with ACPI disabled" or "Safe Mode": > > > > Fatal trap 9: general protection fault while in kernel mode > > cpuid = 0; acpic id = 00 > > instruction pointer = 0x70:0xbfe4 > > stack pointer = 0x28:0xfa4 > > frame pointer = 0x28:0xfd4 > > code segment = base 0xc00f0000, limit 0xffff, type 0x1b > > = DPL 0, pres 1, def32 0, gran 0 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 0 (swapper) > > [thread pid 0 tid 100000 ] > > Stopped at 0xbfe4: *** error reading from address bfe4 *** > > db> bt > > Tracing pid 0 tid 100000 td 0x0da9b50 > > uart_z8530_class(780001,0,b0202,ffe,0,...) at 0xbfe4 > > db> > > This may well be a known problem that has affected certain Intel > motherboards since around 5.x. Although this problem may well be > solvable, perhaps the better approach is to fix whatever is stopping > you from booting with ACPI enabled? Hello Gavin :) Actually I can boot with ACPI enabled (default boot), what I can't boot is "with ACPI disabled" or in "Safe Mode" since both of them throw a Fatal trap 9. > If for some reason you cannot have ACPI enabled, I guess knowing more > output than the above would be useful. For example, when booting > verbose and with ACPI disabled, what lines are printed before the > above? > > (to do this, break to the loader prompt, and: > > setenv hint.acpi.0.disabled=1 > setenv hint.apic.0.disabled=1 > boot -v setenv hint.acpi.0.disabled=1 and setenv hint.apic.0.disabled=1 yielded a stack overflow each one, so I tried booting to the loader (#6) and then: OK set hint.acpi.0.disabled=1 OK set hint.apic.0.disabled=1 OK boot -v That resulted in the very same Fatal trap 9 described above :s The lines before I get the Fatal trap are: pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() pnpbios: 13 devices, largest 146 bytes PNP0a3: adding io range 0xcf8-0xcff, size=0x8, align=0x2 pnpbios: handle 0 device ID PNP0a03 (030ad041) Fatal trap 9: general protection fault while in kernel mode ... > it's also worth trying just with the first one to just disable ACPI, > then just trying the APIC option, to see which of those two are > causing you problems) > > By the way, is this i386 or amd64? CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz 686-class CPU) You'll fin my boot -v in here should you like to take a look at it: http://pastebin.com/f604c1399 > Gavin Thanks for your concern :) -- Blessings Gonzalo Nemmi From xcllnt at mac.com Wed Jul 8 00:29:09 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Jul 8 00:29:20 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707133611.GA66072@rink.nu> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> Message-ID: <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: >> I tried to reproduce the error, got this on the way: >> >> # XXX: bogusly disabled high FP regs > > I get this message quite often as well; I intend to figure out what's > going on. Marcel, if you have any idea, please let me know. It's a race condition. The high FP registers are lazily context-switched and this error is emitted when a thread wants to use the high FP registers when they are disabled and the CPU onto which the thread is running has the high FP registers corresponding to that thread in registers. In that scenario the high FP registers should not even be disabled. In the above case the kernel simply enables the high FP registers and continues the thread. For the most part the condition is harmless, but I've been looking at a panic that's the result of inconsistency in the high FP state, so the race is potentially fatal. BTW: I never got the error when doing a buildworld. I think Anton's non-standard compiler options make GCC much more FP intensive and thus prone to causing the race. FYI, -- Marcel Moolenaar xcllnt@mac.com From gnemmi at gmail.com Wed Jul 8 00:47:50 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Wed Jul 8 00:47:57 2009 Subject: Can't get resume to work on -BETA1/-CURRENT-200906, help needed In-Reply-To: <4A5348A4.60401@phat.za.net> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <4A5348A4.60401@phat.za.net> Message-ID: <200907072147.55632.gnemmi@gmail.com> On Tuesday 07 July 2009 10:07:48 am Aragon Gouveia wrote: > Hi, > > Gonzalo Nemmi wrote: > > log in > > acpiconf -s 3 > > suspend works > > opened the lid and the screen doesn't come back (backlight never > > gets back) hard reset > > login again and checked /var/log/messages .. this is what I found: > > I have problems with suspend too, on AMD64. Basically it works and > my systems comes back up, but some devices are hosed afterwards. > > My bge network interface is one. I get precisely the same PHY > timeout errors you're getting after a suspend. Thos timeouts are all over 7.X, -CURRENT and now -BETA1 .. hope they don't make it into 8.0-RELEASE !!! > The iwn network driver screams the following if I try use it after a > > suspend: > > Jul 7 14:53:17 fuzz kernel: iwn0: iwn_mem_lock: could > > not lock memory Jul 7 14:53:17 fuzz last message > > repeated 7 times Jul 7 14:53:17 fuzz kernel: iwn0: > > iwn_transfer_microcode: could not load boot firmware Jul 7 > > 14:53:17 fuzz kernel: iwn0: iwn_transfer_firmware: > > could not load boot firmware, error 60 Jul 7 14:53:17 > > fuzz kernel: iwn0: iwn_init_locked: could not load firmware, error > > 60 At least you wifi card is supported .. mine is not :( > USB ports resume sometimes, sometimes not: > > Jul 7 14:58:44 fuzz kernel: usbus2: port reset timeout > > Jul 7 14:58:44 fuzz kernel: uhub_reattach_port:369: > > port 1 reset failed, error=USB_ERR_TIMEOUT Jul 7 14:58:44 > > fuzz kernel: uhub_reattach_port:456: device problem > > (USB_ERR_TIMEOUT), disabling port 1 Jul 7 14:58:44 > > fuzz kernel: usbus6: port reset timeout Jul 7 14:58:44 > > fuzz kernel: uhub_reattach_port:369: port 5 reset failed, > > error=USB_ERR_TIMEOUT Jul 7 14:58:44 fuzz kernel: > > uhub_reattach_port:456: device problem (USB_ERR_TIMEOUT), disabling > > port 5 Jul 7 14:58:55 fuzz kernel: uhci_interrupt: > > resume detect Jul 7 14:58:55 fuzz kernel: ugen6.2: > > at usbus6 (disconnected) Jul 7 > > 14:58:55 fuzz kernel: ugen5.2: at > > usbus5 (disconnected) Jul 7 14:58:56 fuzz kernel: > > usbus6: port reset timeout Jul 7 14:58:56 fuzz kernel: > > uhub_reattach_port:369: port 6 reset failed, error=USB_ERR_TIMEOUT > > Jul 7 14:58:56 fuzz kernel: uhub_reattach_port:456: > > device problem (USB_ERR_TIMEOUT), disabling port 6 Never got them .. but now that you mention it .. I think I never tried acpiconf -s 3 with a usb dongle attached to the system .. will try though !! > And I just noticed this message: > > Jul 7 14:53:36 fuzz kernel: calcru: runtime went > > backwards from 18237633 usec to 9377885 usec for pid 10 (idle) > > Unloading modules from the kernel prior to suspending doesn't seem to > work either. Nop .. unloading modules doesn't help at all in here neither :( > On the upside, FreeBSD 8.0 boots rather quickly! :) Yup .. nice boot times ! > > Regards, > Aragon Best Regards Gonzalo -- Blessings Gonzalo Nemmi From gnemmi at gmail.com Wed Jul 8 00:50:31 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Wed Jul 8 00:50:39 2009 Subject: Can't get resume to work on -BETA1/-CURRENT-200906, help needed In-Reply-To: <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> Message-ID: <200907072150.36428.gnemmi@gmail.com> On Tuesday 07 July 2009 5:23:57 am Paul B. Mahol wrote: > On 7/7/09, Gonzalo Nemmi wrote: > > log in > > acpiconf -s 3 > > suspend works > > opened the lid and the screen doesn't come back (backlight never > > gets back) hard reset > > login again and checked /var/log/messages .. this is what I found: > > > > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 > > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 > > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend > > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 > > (disconnected) > > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 > > (disconnected) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 0, val 32768) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 0, val 0xffffffff) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 24, val 0xffffffff) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 16, val 0xffffffff) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 16, val 0) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 16, val 0xffffffff) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 16, val 0) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 23, val 18) > > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init > > failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization > > failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a > > available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: > > Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: > > fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: > > fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle > > kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID > > Count=1, CYCLEMASTER mode > > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 > > cable IRM irm(0) (me) > > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 > > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error > > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept > > 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: > > at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: > Optical Mouse, class 0/0, rev 2.00/0.10, addr 2> on usbus3 > > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] > > coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 > > 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 > > > > any hints on how to further debug or redirect this mail to the > > right list will be greatly appreciated. > > > > more info can be found in here: > > http://forums.freebsd.org/showthread.php?t=3886 > > > > Best Regards > > Gonzalo Nemmi > > i386 resume doesn't work with SMP kernel and SMP CPU. > On amd64 make sure that you have right file loaded in kernel: > for example i915.ko for intel cards. I shoul've mentioned I'm on a: CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz 686-class CPU) and that I've added: hint.smp.disabled=1 to my /boot/device.hints This is what I get: Jul 7 21:35:03 gargoyle login: ROOT LOGIN (root) ON ttyv0 Jul 7 21:40:19 gargoyle acpi: suspend at 20090707 21:40:19 Jul 7 21:40:25 gargoyle kernel: fwohci0: fwohci_pci_suspend Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Jul 7 21:41:44 gargoyle kernel: bge0: flow-through queue init failed Jul 7 21:41:44 gargoyle kernel: bge0: initialization failure Jul 7 21:41:44 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 ports. Jul 7 21:41:44 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. Jul 7 21:41:44 gargoyle kernel: fwohci0: Initiate bus reset Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Jul 7 21:41:44 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Jul 7 21:41:44 gargoyle kernel: firewire0: bus manager 0 Jul 7 21:41:44 gargoyle kernel: fwohci0: unrecoverable error Jul 7 21:41:44 gargoyle kernel: wakeup from sleeping state (slept 00:01:19) Jul 7 21:41:44 gargoyle acpi: resumed at 20090707 21:41:44 Jul 7 21:42:45 gargoyle syslogd: exiting on signal 15 Should I file a PR? Once again, boot -v in here: http://pastebin.com/f604c1399 More info on my hardware and other messages: http://forums.freebsd.org/showthread.php?t=3886 Best Regards Gonzalo -- Blessings Gonzalo Nemmi From gnemmi at gmail.com Wed Jul 8 01:13:56 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Wed Jul 8 01:14:02 2009 Subject: LOR on kldunload snd_hda Message-ID: <200907072214.01645.gnemmi@gmail.com> log in kldload snd_hda cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32 bit 20090615000/i386) Installed devices: pcm0: at cad 0 nid 1 on hdac0 kld snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex default) mixer Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 75:75 Mixer mic is currently set to 0:0 Mixer rec is currently set to 0:0 "insert cd" cdcontrol -f /dev/acd0 play 1 "no sound at all" cdcontrol eject kldunload snd_hda Jul 7 21:44:15 gargoyle login: ROOT LOGIN (root) ON ttyv0 Jul 7 21:54:27 gargoyle kernel: hdac0: mem 0xf6dfc000-0xf6dfffff irq 21 at device 27.0 on pci0 Jul 7 21:54:27 gargoyle kernel: hdac0: HDA Driver Revision: 20090624_0136 Jul 7 21:54:27 gargoyle kernel: hdac0: [ITHREAD] Jul 7 21:54:27 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel STAC9228X Jul 7 21:54:27 gargoyle kernel: pcm0: at cad 0 nid 1 on hdac0 Jul 7 22:03:27 gargoyle kernel: lock order reversal: Jul 7 22:03:27 gargoyle kernel: 1st 0xc0da8cdc kernel linker (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1079 Jul 7 22:03:27 gargoyle kernel: 2nd 0xc0daa4e4 sysctl lock (sysctl lock) @ /usr/src/sys/kern/kern_sysctl.c:255 Jul 7 22:03:27 gargoyle kernel: KDB: stack backtrace: Jul 7 22:03:27 gargoyle kernel: db_trace_self_wrapper(c0c5b564,e6df7ac0,c08b5b35,c08a68db,c0c5e3f9,...) at db_trace_self_wrapper+0x26 Jul 7 22:03:27 gargoyle kernel: kdb_backtrace(c08a68db,c0c5e3f9,c452cae8,c452ad40,e6df7b1c,...) at kdb_backtrace+0x29 Jul 7 22:03:27 gargoyle kernel: _witness_debugger(c0c5e3f9,c0daa4e4,c0c58fbb,c452ad40,c0c58ec2,...) at _witness_debugger+0x25 Jul 7 22:03:27 gargoyle kernel: witness_checkorder(c0daa4e4,9,c0c58ec2,ff,0,...) at witness_checkorder+0x839 Jul 7 22:03:27 gargoyle kernel: _sx_xlock(c0daa4e4,0,c0c58ec2,ff,0,...) at _sx_xlock+0x85 Jul 7 22:03:27 gargoyle kernel: sysctl_ctx_free(c4d7379c,0,c4e1c712,4a1,c4ca9480,...) at sysctl_ctx_free+0x30 Jul 7 22:03:27 gargoyle kernel: pcm_unregister(c488f800,c4da3860,c0d3b6c8,a3c,c4887a80,...) at pcm_unregister+0x4e1 Jul 7 22:03:27 gargoyle kernel: device_detach(c488f800,c0865663,c0da9df0,c4dd22d4,c4a95100,...) at device_detach+0x8c Jul 7 22:03:27 gargoyle kernel: driver_module_handler(c4887a80,1,c4dd22d4,109,0,...) at driver_module_handler+0x29c Jul 7 22:03:27 gargoyle kernel: module_unload(c4887a80,c0c54c7c,273,270,c08592b6,...) at module_unload+0x43 Jul 7 22:03:27 gargoyle kernel: linker_file_unload(c4a92600,0,c0c54c7c,437,c4dba000,...) at linker_file_unload+0x15e Jul 7 22:03:27 gargoyle kernel: kern_kldunload(c4ca9480,2,0,e6df7d2c,c0b98e73,...) at kern_kldunload+0xd5 Jul 7 22:03:27 gargoyle kernel: kldunloadf(c4ca9480,e6df7cf8,8,c0c5f4bb,c0d3f0b0,...) at kldunloadf+0x2b Jul 7 22:03:27 gargoyle kernel: syscall(e6df7d38) at syscall+0x2a3 Jul 7 22:03:27 gargoyle kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 7 22:03:27 gargoyle kernel: --- syscall (444, FreeBSD ELF32, kldunloadf), eip = 0x280d573b, esp = 0xbfbfe47c, ebp = 0xbfbfecc8 --- Jul 7 22:03:27 gargoyle kernel: pcm0: detached Jul 7 22:03:27 gargoyle kernel: hdac0: detached Any pointers?? Best Regards Gonzalo -- Blessings Gonzalo Nemmi From sfourman at gmail.com Wed Jul 8 01:54:34 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Wed Jul 8 01:54:41 2009 Subject: LOR on kldunload snd_hda In-Reply-To: <200907072214.01645.gnemmi@gmail.com> References: <200907072214.01645.gnemmi@gmail.com> Message-ID: <11167f520907071854q5e7e9658mfd082fbd95c5c8a0@mail.gmail.com> On Tue, Jul 7, 2009 at 8:14 PM, Gonzalo Nemmi wrote: > log in > kldload snd_hda > cat /dev/sndstat > > FreeBSD Audio Driver (newpcm: 32 bit 20090615000/i386) > Installed devices: > pcm0: at cad 0 nid 1 on hdac0 kld > snd_hda > [MPSAFE] (1p:1v/1r:1v channels duplex default) > > mixer > Mixer vol is currently set to 75:75 > Mixer pcm is currently set to 75:75 > Mixer speaker is currently set to 75:75 > Mixer mic is currently set to 0:0 > Mixer rec is currently set to 0:0 > > "insert cd" > > cdcontrol -f /dev/acd0 play 1 > > "no sound at all" > > cdcontrol eject > kldunload snd_hda I have a similar problem with snd_hda on a 6-1-2009 -CURRENT i386 kernel everything is fine but on a 6-24-2009 -CURRENT i386 kernel I have sound in vlc, but not in my wine applications the moment I boot into a 6-1-2009 kernel everything works fine. Sam Fourman Jr. From onemda at gmail.com Wed Jul 8 03:39:49 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Jul 8 03:39:55 2009 Subject: Can't get resume to work on -BETA1/-CURRENT-200906, help needed In-Reply-To: <200907072150.36428.gnemmi@gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> <200907072150.36428.gnemmi@gmail.com> Message-ID: <3a142e750907072039w3c5d6557ia374920a3787cf1c@mail.gmail.com> On 7/8/09, Gonzalo Nemmi wrote: > On Tuesday 07 July 2009 5:23:57 am Paul B. Mahol wrote: >> On 7/7/09, Gonzalo Nemmi wrote: >> > log in >> > acpiconf -s 3 >> > suspend works >> > opened the lid and the screen doesn't come back (backlight never >> > gets back) hard reset >> > login again and checked /var/log/messages .. this is what I found: >> > >> > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 >> > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 >> > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend >> > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 >> > (disconnected) >> > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 >> > (disconnected) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 0, val 32768) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 0, val 0xffffffff) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 24, val 0xffffffff) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 16, val 0xffffffff) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 16, val 0) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 16, val 0xffffffff) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 16, val 0) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 23, val 18) >> > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init >> > failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization >> > failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a >> > available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: >> > Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: >> > fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: >> > fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle >> > kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID >> > Count=1, CYCLEMASTER mode >> > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 >> > cable IRM irm(0) (me) >> > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 >> > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error >> > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept >> > 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: >> > at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: > > Optical Mouse, class 0/0, rev 2.00/0.10, addr 2> on usbus3 >> > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] >> > coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 >> > 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 >> > >> > any hints on how to further debug or redirect this mail to the >> > right list will be greatly appreciated. >> > >> > more info can be found in here: >> > http://forums.freebsd.org/showthread.php?t=3886 >> > >> > Best Regards >> > Gonzalo Nemmi >> >> i386 resume doesn't work with SMP kernel and SMP CPU. >> On amd64 make sure that you have right file loaded in kernel: >> for example i915.ko for intel cards. > > I shoul've mentioned I'm on a: > CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz > 686-class CPU) > > and that I've added: hint.smp.disabled=1 to my /boot/device.hints > > This is what I get: > > Jul 7 21:35:03 gargoyle login: ROOT LOGIN (root) ON ttyv0 > Jul 7 21:40:19 gargoyle acpi: suspend at 20090707 21:40:19 > Jul 7 21:40:25 gargoyle kernel: fwohci0: fwohci_pci_suspend > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 0, val 32768) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, > val 0xffffffff) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > 24, val 0xffffffff) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > 16, val 0xffffffff) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 16, val 0) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > 16, val 0xffffffff) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 16, val 0) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 23, val 18) > Jul 7 21:41:44 gargoyle kernel: bge0: flow-through queue init failed > Jul 7 21:41:44 gargoyle kernel: bge0: initialization failure > Jul 7 21:41:44 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 > ports. > Jul 7 21:41:44 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. > Jul 7 21:41:44 gargoyle kernel: fwohci0: Initiate bus reset > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > Jul 7 21:41:44 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable > IRM irm(0) (me) > Jul 7 21:41:44 gargoyle kernel: firewire0: bus manager 0 > Jul 7 21:41:44 gargoyle kernel: fwohci0: unrecoverable error > Jul 7 21:41:44 gargoyle kernel: wakeup from sleeping state (slept > 00:01:19) > Jul 7 21:41:44 gargoyle acpi: resumed at 20090707 21:41:44 > Jul 7 21:42:45 gargoyle syslogd: exiting on signal 15 > > Should I file a PR? > > Once again, boot -v in here: http://pastebin.com/f604c1399 > > More info on my hardware and other messages: > http://forums.freebsd.org/showthread.php?t=3886 > > Best Regards > Gonzalo > -- > Blessings > Gonzalo Nemmi > Sorry, but I dont see what graphic card you are using. Anyway, on i386 you must load vesa.ko if ypu want that resume also resumes video -- Paul From gnemmi at gmail.com Wed Jul 8 03:59:40 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Wed Jul 8 03:59:47 2009 Subject: Can't get resume to work on -BETA1/-CURRENT-200906, help needed In-Reply-To: <3a142e750907072039w3c5d6557ia374920a3787cf1c@mail.gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> <200907072150.36428.gnemmi@gmail.com> <3a142e750907072039w3c5d6557ia374920a3787cf1c@mail.gmail.com> Message-ID: <19e9a5dc0907072059p600fbe75ha44bc5d5f1cac7d8@mail.gmail.com> On Wed, Jul 8, 2009 at 12:39 AM, Paul B. Mahol wrote: > On 7/8/09, Gonzalo Nemmi wrote: > > On Tuesday 07 July 2009 5:23:57 am Paul B. Mahol wrote: > >> On 7/7/09, Gonzalo Nemmi wrote: > >> > log in > >> > acpiconf -s 3 > >> > suspend works > >> > opened the lid and the screen doesn't come back (backlight never > >> > gets back) hard reset > >> > login again and checked /var/log/messages .. this is what I found: > >> > > >> > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 > >> > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 > >> > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend > >> > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 > >> > (disconnected) > >> > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 > >> > (disconnected) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 0, val 32768) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 0, val 0xffffffff) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 24, val 0xffffffff) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 16, val 0xffffffff) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 16, val 0) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 16, val 0xffffffff) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 16, val 0) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 23, val 18) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init > >> > failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization > >> > failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a > >> > available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: > >> > Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: > >> > fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: > >> > fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle > >> > kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID > >> > Count=1, CYCLEMASTER mode > >> > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 > >> > cable IRM irm(0) (me) > >> > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 > >> > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error > >> > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept > >> > 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: > >> > at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: >> > Optical Mouse, class 0/0, rev 2.00/0.10, addr 2> on usbus3 > >> > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] > >> > coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 > >> > 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 > >> > > >> > any hints on how to further debug or redirect this mail to the > >> > right list will be greatly appreciated. > >> > > >> > more info can be found in here: > >> > http://forums.freebsd.org/showthread.php?t=3886 > >> > > >> > Best Regards > >> > Gonzalo Nemmi > >> > >> i386 resume doesn't work with SMP kernel and SMP CPU. > >> On amd64 make sure that you have right file loaded in kernel: > >> for example i915.ko for intel cards. > > > > I shoul've mentioned I'm on a: > > CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz > > 686-class CPU) > > > > and that I've added: hint.smp.disabled=1 to my /boot/device.hints > > > > This is what I get: > > > > Jul 7 21:35:03 gargoyle login: ROOT LOGIN (root) ON ttyv0 > > Jul 7 21:40:19 gargoyle acpi: suspend at 20090707 21:40:19 > > Jul 7 21:40:25 gargoyle kernel: fwohci0: fwohci_pci_suspend > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 0, val 32768) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, > > val 0xffffffff) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > > 24, val 0xffffffff) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > > 16, val 0xffffffff) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 16, val 0) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > > 16, val 0xffffffff) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 16, val 0) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 23, val 18) > > Jul 7 21:41:44 gargoyle kernel: bge0: flow-through queue init failed > > Jul 7 21:41:44 gargoyle kernel: bge0: initialization failure > > Jul 7 21:41:44 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 > > ports. > > Jul 7 21:41:44 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. > > Jul 7 21:41:44 gargoyle kernel: fwohci0: Initiate bus reset > > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset > > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: > > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > > Jul 7 21:41:44 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable > > IRM irm(0) (me) > > Jul 7 21:41:44 gargoyle kernel: firewire0: bus manager 0 > > Jul 7 21:41:44 gargoyle kernel: fwohci0: unrecoverable error > > Jul 7 21:41:44 gargoyle kernel: wakeup from sleeping state (slept > > 00:01:19) > > Jul 7 21:41:44 gargoyle acpi: resumed at 20090707 21:41:44 > > Jul 7 21:42:45 gargoyle syslogd: exiting on signal 15 > > > > Should I file a PR? > > > > Once again, boot -v in here: http://pastebin.com/f604c1399 > > > > More info on my hardware and other messages: > > http://forums.freebsd.org/showthread.php?t=3886 > > > > Best Regards > > Gonzalo > > -- > > Blessings > > Gonzalo Nemmi > > > > Sorry, but I dont see what graphic card you are using. > Anyway, on i386 you must load vesa.ko if ypu want that resume also resumes > video > > -- > Paul 322 vgapci0: port 0xeff8-0xefff mem 0xf6e00000-0xf6efffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 323 agp0: on vgapci0 324 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xe0000000 325 vgapci0: Reserved 0x100000 bytes for rid 0x10 type 3 at 0xf6e00000 326 agp0: detected 7676k stolen memory 327 agp0: aperture size is 256M 328 vgapci1: mem 0xf6f00000-0xf6ffffff at device 2.1 on pci0 im not running X or anything .. so I guess im using whatever module 8 uses by default (actually I thought it was the vesa module), this is just a plain 8.0-BETA1 install (not even a single port installed). will try loading vesa, see what happens and report back. Thanks for your interest and help Best Regards Gonzalo From onemda at gmail.com Wed Jul 8 04:04:53 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Jul 8 04:05:01 2009 Subject: Can't get resume to work on -BETA1/-CURRENT-200906, help needed In-Reply-To: <19e9a5dc0907072059p600fbe75ha44bc5d5f1cac7d8@mail.gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> <200907072150.36428.gnemmi@gmail.com> <3a142e750907072039w3c5d6557ia374920a3787cf1c@mail.gmail.com> <19e9a5dc0907072059p600fbe75ha44bc5d5f1cac7d8@mail.gmail.com> Message-ID: <3a142e750907072104m2787e7f0p5dd30008ad11170d@mail.gmail.com> On 7/8/09, Gonzalo Nemmi wrote: > On Wed, Jul 8, 2009 at 12:39 AM, Paul B. Mahol wrote: > >> On 7/8/09, Gonzalo Nemmi wrote: >> > On Tuesday 07 July 2009 5:23:57 am Paul B. Mahol wrote: >> >> On 7/7/09, Gonzalo Nemmi wrote: >> >> > log in >> >> > acpiconf -s 3 >> >> > suspend works >> >> > opened the lid and the screen doesn't come back (backlight never >> >> > gets back) hard reset >> >> > login again and checked /var/log/messages .. this is what I found: >> >> > >> >> > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 >> >> > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 >> >> > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend >> >> > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 >> >> > (disconnected) >> >> > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 >> >> > (disconnected) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> >> > reg 0, val 32768) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> >> > reg 0, val 0xffffffff) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> >> > reg 24, val 0xffffffff) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> >> > reg 16, val 0xffffffff) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> >> > reg 16, val 0) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> >> > reg 16, val 0xffffffff) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> >> > reg 16, val 0) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> >> > reg 23, val 18) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init >> >> > failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization >> >> > failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a >> >> > available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: >> >> > Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: >> >> > fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: >> >> > fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle >> >> > kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID >> >> > Count=1, CYCLEMASTER mode >> >> > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 >> >> > cable IRM irm(0) (me) >> >> > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 >> >> > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error >> >> > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept >> >> > 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: >> >> > at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: > >> > Optical Mouse, class 0/0, rev 2.00/0.10, addr 2> on usbus3 >> >> > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] >> >> > coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 >> >> > 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 >> >> > >> >> > any hints on how to further debug or redirect this mail to the >> >> > right list will be greatly appreciated. >> >> > >> >> > more info can be found in here: >> >> > http://forums.freebsd.org/showthread.php?t=3886 >> >> > >> >> > Best Regards >> >> > Gonzalo Nemmi >> >> >> >> i386 resume doesn't work with SMP kernel and SMP CPU. >> >> On amd64 make sure that you have right file loaded in kernel: >> >> for example i915.ko for intel cards. >> > >> > I shoul've mentioned I'm on a: >> > CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz >> > 686-class CPU) >> > >> > and that I've added: hint.smp.disabled=1 to my /boot/device.hints >> > >> > This is what I get: >> > >> > Jul 7 21:35:03 gargoyle login: ROOT LOGIN (root) ON ttyv0 >> > Jul 7 21:40:19 gargoyle acpi: suspend at 20090707 21:40:19 >> > Jul 7 21:40:25 gargoyle kernel: fwohci0: fwohci_pci_suspend >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg >> > 0, val 32768) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg >> > 0, >> > val 0xffffffff) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg >> > 24, val 0xffffffff) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg >> > 16, val 0xffffffff) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg >> > 16, val 0) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg >> > 16, val 0xffffffff) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg >> > 16, val 0) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg >> > 23, val 18) >> > Jul 7 21:41:44 gargoyle kernel: bge0: flow-through queue init failed >> > Jul 7 21:41:44 gargoyle kernel: bge0: initialization failure >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 >> > ports. >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Link S400, max_rec 2048 >> > bytes. >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Initiate bus reset >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: >> > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode >> > Jul 7 21:41:44 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable >> > IRM irm(0) (me) >> > Jul 7 21:41:44 gargoyle kernel: firewire0: bus manager 0 >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: unrecoverable error >> > Jul 7 21:41:44 gargoyle kernel: wakeup from sleeping state (slept >> > 00:01:19) >> > Jul 7 21:41:44 gargoyle acpi: resumed at 20090707 21:41:44 >> > Jul 7 21:42:45 gargoyle syslogd: exiting on signal 15 >> > >> > Should I file a PR? >> > >> > Once again, boot -v in here: http://pastebin.com/f604c1399 >> > >> > More info on my hardware and other messages: >> > http://forums.freebsd.org/showthread.php?t=3886 >> > >> > Best Regards >> > Gonzalo >> > -- >> > Blessings >> > Gonzalo Nemmi >> > >> >> Sorry, but I dont see what graphic card you are using. >> Anyway, on i386 you must load vesa.ko if ypu want that resume also >> resumes >> video >> >> -- >> Paul > > > 322 vgapci0: port 0xeff8-0xefff mem > 0xf6e00000-0xf6efffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > 323 agp0: on vgapci0 > 324 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xe0000000 > 325 vgapci0: Reserved 0x100000 bytes for rid 0x10 type 3 at 0xf6e00000 > 326 agp0: detected 7676k stolen memory > 327 agp0: aperture size is 256M > 328 vgapci1: mem 0xf6f00000-0xf6ffffff at device > 2.1 on pci0 > > im not running X or anything .. so I guess im using whatever module 8 uses > by default (actually I thought it was the vesa module), this is just a > plain No, you need to load i915.ko or vesa.ko to make video resuming working. > 8.0-BETA1 install (not even a single port installed). > will try loading vesa, see what happens and report back. > > Thanks for your interest and help > Best Regards > Gonzalo > -- Paul From gnemmi at gmail.com Wed Jul 8 04:29:49 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Wed Jul 8 04:29:57 2009 Subject: Can't get resume to work on -BETA1/-CURRENT-200906, help needed In-Reply-To: <3a142e750907072104m2787e7f0p5dd30008ad11170d@mail.gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> <200907072150.36428.gnemmi@gmail.com> <3a142e750907072039w3c5d6557ia374920a3787cf1c@mail.gmail.com> <19e9a5dc0907072059p600fbe75ha44bc5d5f1cac7d8@mail.gmail.com> <3a142e750907072104m2787e7f0p5dd30008ad11170d@mail.gmail.com> Message-ID: <19e9a5dc0907072129q2564839o687524a2261370e8@mail.gmail.com> On Wed, Jul 8, 2009 at 1:04 AM, Paul B. Mahol wrote: > On 7/8/09, Gonzalo Nemmi wrote: > > On Wed, Jul 8, 2009 at 12:39 AM, Paul B. Mahol wrote: > > > >> On 7/8/09, Gonzalo Nemmi wrote: > >> > On Tuesday 07 July 2009 5:23:57 am Paul B. Mahol wrote: > >> >> On 7/7/09, Gonzalo Nemmi wrote: > >> >> > log in > >> >> > acpiconf -s 3 > >> >> > suspend works > >> >> > opened the lid and the screen doesn't come back (backlight never > >> >> > gets back) hard reset > >> >> > login again and checked /var/log/messages .. this is what I found: > >> >> > > >> >> > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 > >> >> > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 > >> >> > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend > >> >> > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 > >> >> > (disconnected) > >> >> > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 > >> >> > (disconnected) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> >> > reg 0, val 32768) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> >> > reg 0, val 0xffffffff) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> >> > reg 24, val 0xffffffff) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> >> > reg 16, val 0xffffffff) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> >> > reg 16, val 0) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> >> > reg 16, val 0xffffffff) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> >> > reg 16, val 0) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> >> > reg 23, val 18) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init > >> >> > failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization > >> >> > failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a > >> >> > available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: > >> >> > Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: > >> >> > fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: > >> >> > fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle > >> >> > kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID > >> >> > Count=1, CYCLEMASTER mode > >> >> > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 > >> >> > cable IRM irm(0) (me) > >> >> > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 > >> >> > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error > >> >> > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept > >> >> > 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: > >> >> > at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: >> >> > Optical Mouse, class 0/0, rev 2.00/0.10, addr 2> on usbus3 > >> >> > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] > >> >> > coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 > >> >> > 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 > >> >> > > >> >> > any hints on how to further debug or redirect this mail to the > >> >> > right list will be greatly appreciated. > >> >> > > >> >> > more info can be found in here: > >> >> > http://forums.freebsd.org/showthread.php?t=3886 > >> >> > > >> >> > Best Regards > >> >> > Gonzalo Nemmi > >> >> > >> >> i386 resume doesn't work with SMP kernel and SMP CPU. > >> >> On amd64 make sure that you have right file loaded in kernel: > >> >> for example i915.ko for intel cards. > >> > > >> > I shoul've mentioned I'm on a: > >> > CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz > >> > 686-class CPU) > >> > > >> > and that I've added: hint.smp.disabled=1 to my /boot/device.hints > >> > > >> > This is what I get: > >> > > >> > Jul 7 21:35:03 gargoyle login: ROOT LOGIN (root) ON ttyv0 > >> > Jul 7 21:40:19 gargoyle acpi: suspend at 20090707 21:40:19 > >> > Jul 7 21:40:25 gargoyle kernel: fwohci0: fwohci_pci_suspend > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > >> > 0, val 32768) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > >> > 0, > >> > val 0xffffffff) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > >> > 24, val 0xffffffff) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > >> > 16, val 0xffffffff) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > >> > 16, val 0) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > >> > 16, val 0xffffffff) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > >> > 16, val 0) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > >> > 23, val 18) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: flow-through queue init failed > >> > Jul 7 21:41:44 gargoyle kernel: bge0: initialization failure > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 > >> > ports. > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Link S400, max_rec 2048 > >> > bytes. > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Initiate bus reset > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: > >> > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > >> > Jul 7 21:41:44 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable > >> > IRM irm(0) (me) > >> > Jul 7 21:41:44 gargoyle kernel: firewire0: bus manager 0 > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: unrecoverable error > >> > Jul 7 21:41:44 gargoyle kernel: wakeup from sleeping state (slept > >> > 00:01:19) > >> > Jul 7 21:41:44 gargoyle acpi: resumed at 20090707 21:41:44 > >> > Jul 7 21:42:45 gargoyle syslogd: exiting on signal 15 > >> > > >> > Should I file a PR? > >> > > >> > Once again, boot -v in here: http://pastebin.com/f604c1399 > >> > > >> > More info on my hardware and other messages: > >> > http://forums.freebsd.org/showthread.php?t=3886 > >> > > >> > Best Regards > >> > Gonzalo > >> > -- > >> > Blessings > >> > Gonzalo Nemmi > >> > > >> > >> Sorry, but I dont see what graphic card you are using. > >> Anyway, on i386 you must load vesa.ko if ypu want that resume also > >> resumes > >> video > >> > >> -- > >> Paul > > > > > > 322 vgapci0: port 0xeff8-0xefff mem > > 0xf6e00000-0xf6efffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > > 323 agp0: on vgapci0 > > 324 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xe0000000 > > 325 vgapci0: Reserved 0x100000 bytes for rid 0x10 type 3 at 0xf6e00000 > > 326 agp0: detected 7676k stolen memory > > 327 agp0: aperture size is 256M > > 328 vgapci1: mem 0xf6f00000-0xf6ffffff at device > > 2.1 on pci0 > > > > im not running X or anything .. so I guess im using whatever module 8 > uses > > by default (actually I thought it was the vesa module), this is just a > > plain > > No, you need to load i915.ko or vesa.ko to make video resuming working. > > > 8.0-BETA1 install (not even a single port installed). > > will try loading vesa, see what happens and report back. > > > > Thanks for your interest and help > > Best Regards > > Gonzalo > > > > > -- > Paul > Thanks Paul, it kinda worked. I loaded vesa.ko then "acpiconf -s 3", the system _resumed_ but not after the time outs and upon resuming the screen backlight was really dim. Wil try with i915.ko and see what happens. Any ways, heres are the messages I got: Jul 8 01:01:16 gargoyle login: ROOT LOGIN (root) ON ttyv0 Jul 8 01:01:39 gargoyle acpi: suspend at 20090708 01:01:39 Jul 8 01:01:45 gargoyle kernel: fwohci0: fwohci_pci_suspend Jul 8 01:02:27 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Jul 8 01:02:27 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Jul 8 01:02:27 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Jul 8 01:02:27 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:02:27 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:02:27 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:02:27 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:02:27 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Jul 8 01:02:27 gargoyle kernel: bge0: flow-through queue init failed Jul 8 01:02:27 gargoyle kernel: bge0: initialization failure Jul 8 01:02:27 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 ports. Jul 8 01:02:27 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. Jul 8 01:02:27 gargoyle kernel: fwohci0: Initiate bus reset Jul 8 01:02:27 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset Jul 8 01:02:27 gargoyle kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Jul 8 01:02:27 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Jul 8 01:02:27 gargoyle kernel: firewire0: bus manager 0 Jul 8 01:02:27 gargoyle kernel: fwohci0: unrecoverable error Jul 8 01:02:27 gargoyle kernel: wakeup from sleeping state (slept 00:00:43) Jul 8 01:02:27 gargoyle acpi: resumed at 20090708 01:02:27 after that, I got my screen back, then I did a sysctl hw.acpi.lid_close_state=S3 and suspended again .. closed the lid, suspended, opened the lid and got the system back, dim light again .. messages: Jul 8 01:06:24 gargoyle acpi: suspend at 20090708 01:06:24 Jul 8 01:06:37 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Jul 8 01:06:37 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Jul 8 01:06:37 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Jul 8 01:06:37 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:06:37 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:06:37 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:06:37 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:06:37 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Jul 8 01:06:39 gargoyle kernel: fwohci0: fwohci_pci_suspend Jul 8 01:09:29 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Jul 8 01:09:29 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Jul 8 01:09:29 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Jul 8 01:09:29 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:09:29 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:09:29 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:09:29 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:09:29 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Jul 8 01:09:29 gargoyle kernel: bge0: flow-through queue init failed Jul 8 01:09:29 gargoyle kernel: bge0: initialization failure Jul 8 01:09:29 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 ports. Jul 8 01:09:29 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. Jul 8 01:09:29 gargoyle kernel: fwohci0: Initiate bus reset Jul 8 01:09:29 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset Jul 8 01:09:29 gargoyle kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Jul 8 01:09:29 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Jul 8 01:09:29 gargoyle kernel: firewire0: bus manager 0 Jul 8 01:09:29 gargoyle kernel: fwohci0: unrecoverable error Jul 8 01:09:29 gargoyle kernel: wakeup from sleeping state (slept 00:02:51) Jul 8 01:09:29 gargoyle acpi: resumed at 20090708 01:09:29 Notice how upon the second "resume" I get PHY timeouts at 01:06:37, before the machine enters the suspend state, which actually takes place at 01:06:39 :s Anyways, it did resume again 01:09:29 :) Will give take a shot at i915.ko and see how it goes. Thanks for your help Paul :) Best Regards Gonzalo From chflags at gmail.com Wed Jul 8 09:00:55 2009 From: chflags at gmail.com (Kevin Foo) Date: Wed Jul 8 09:01:39 2009 Subject: regression in atkbd? Message-ID: <25cb30907080133l656fb10s6221607f00b3d193@mail.gmail.com> Hi hackers, Did anyone experience issue with atkbd on 8.0? I encountered issue with keyboard and touchpad on HP presario V3400 when trying to upgrade from 7.2-RELEASE to 8.0 prior to and on BETA1.The keyboard and touchpad are working fine on 7.2. On 8.0 prior to BETA1, I managed to obtain dmesg via ssh despite having a non-operational keyboard. The laptop was totally inaccessible on 8.0 BETA1 as it freezed after the line atkbdc0. No information could be obtained. Any ideas? Thanks. /boot/device.hints (default, no changes made) hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.psm.0.at="atkbdc" hint.psm.0.irq="12" 1) FreeBSD 8.0-BETA1 amd64 as of today with GENERIC kernel:- <---snip---< atkbdc0: port 0x60,0x64 irq 1 on acpi0 system hangs...... 2) FreeBSD 8.0-CURRENT amd64 prior to BETA1 custom kernel without debug/invariant/witness:- <---snip---< atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: unable to set the command byte. kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 55 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: unable to set the command byte. <---snip---< Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.8.txt 3) FreeBSD 7.2-RELEASE-p2 amd64:- <---snip---< atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 58 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 <---snip---< Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.7.txt -- Regards Kevin Foo From gavin.atkinson at ury.york.ac.uk Wed Jul 8 09:45:00 2009 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Wed Jul 8 09:45:07 2009 Subject: Fatal trap 9 on -BETA1 on boot "with ACPI disabled" or "Safe Mode": In-Reply-To: <200907072129.01232.gnemmi@gmail.com> References: <19e9a5dc0907062254u528c4a8ahea2a605e80b1feea@mail.gmail.com> <1246963840.48637.44.camel@buffy.york.ac.uk> <200907072129.01232.gnemmi@gmail.com> Message-ID: <034E7108-6F28-47A9-896B-F9E126BACF93@ury.york.ac.uk> On 8 Jul 2009, at 01:29, Gonzalo Nemmi wrote: > On Tuesday 07 July 2009 7:50:40 am Gavin Atkinson wrote: >> On Tue, 2009-07-07 at 02:54 -0300, Gonzalo Nemmi wrote: >>> Can reproduce it on -CURRENT-200906 and -BETA1 whenever I try to >>> boot "with ACPI disabled" or "Safe Mode": >>> >>> Fatal trap 9: general protection fault while in kernel mode >>> cpuid = 0; acpic id = 00 >>> instruction pointer = 0x70:0xbfe4 >>> stack pointer = 0x28:0xfa4 >>> frame pointer = 0x28:0xfd4 >>> code segment = base 0xc00f0000, limit 0xffff, type 0x1b >>> = DPL 0, pres 1, def32 0, gran 0 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 0 (swapper) >>> [thread pid 0 tid 100000 ] >>> Stopped at 0xbfe4: *** error reading from address bfe4 *** >>> db> bt >>> Tracing pid 0 tid 100000 td 0x0da9b50 >>> uart_z8530_class(780001,0,b0202,ffe,0,...) at 0xbfe4 >>> db> >> >> This may well be a known problem that has affected certain Intel >> motherboards since around 5.x. Although this problem may well be >> solvable, perhaps the better approach is to fix whatever is stopping >> you from booting with ACPI enabled? > > Hello Gavin :) > > Actually I can boot with ACPI enabled (default boot), what I can't > boot > is "with ACPI disabled" or in "Safe Mode" since both of them throw a > Fatal trap 9. If there is no reason not to run with ACPI enabled, I'd recommend you do so. It would also be fair to say that the ACPI code receives far more testing than the non-ACPI code. However... > >> If for some reason you cannot have ACPI enabled, I guess knowing more >> output than the above would be useful. For example, when booting >> verbose and with ACPI disabled, what lines are printed before the >> above? >> >> (to do this, break to the loader prompt, and: >> >> setenv hint.acpi.0.disabled=1 >> setenv hint.apic.0.disabled=1 >> boot -v > > setenv hint.acpi.0.disabled=1 and setenv hint.apic.0.disabled=1 > yielded > a stack overflow each one, so I tried booting to the loader (#6) and > then: > > OK set hint.acpi.0.disabled=1 > OK set hint.apic.0.disabled=1 > OK boot -v > > That resulted in the very same Fatal trap 9 described above :a Can you just try with one or the other? I suspect you'll find it is the disabling of ACPI that is causing the issue, but it's worth checking. > > The lines before I get the Fatal trap are: > > pnp_identify: Trying Read_Port at 283 > pnp_identify: Trying Read_Port at 2c3 > pnp_identify: Trying Read_Port at 303 > pnp_identify: Trying Read_Port at 343 > pnp_identify: Trying Read_Port at 383 > pnp_identify: Trying Read_Port at 3c3 > PNP Identify complete > ex_isa_identify() > pnpbios: 13 devices, largest 146 bytes > PNP0a3: adding io range 0xcf8-0xcff, size=0x8, align=0x2 > pnpbios: handle 0 device ID PNP0a03 (030ad041) > > Fatal trap 9: general protection fault while in kernel mode ... > >> it's also worth trying just with the first one to just disable ACPI, >> then just trying the APIC option, to see which of those two are >> causing you problems) >> >> By the way, is this i386 or amd64? > > CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz > 686-class CPU) This cpu will run either the i386 or the amd64 version of FreeBSD. Which are you using? (it's not possible to determine from your dmesg). If it's FreeBSD/amd64 you are running, all bets are off: that pretty much requires ACPI now to function. > You'll fin my boot -v in here should you like to take a look at it: > http://pastebin.com/f604c1399 > >> Gavin > > Thanks for your concern :) Gavin From doconnor at gsoft.com.au Wed Jul 8 10:13:20 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Jul 8 10:13:28 2009 Subject: k3b and mkisofs problems on freebsd-current In-Reply-To: <402C2D9299C36C4BB1C89C5E3539706E5C6012@pdc.mands.hu> References: <402C2D9299C36C4BB1C89C5E3539706E5C6012@pdc.mands.hu> Message-ID: <200907082013.04661.doconnor@gsoft.com.au> On Mon, 6 Jul 2009, M&S - Krasznai Andr?s wrote: > I refreshed the sources last time on Friday, and recompiled k3b and > cdrtools again but it is still not working correctly. > > > Did anybody experience such problems with k3b? k3b works for me with -current from April 5th. Tried ktracing it? eg ktrace -dcif k3b.ktr k3b --nocrashhandler --nofork -- 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/20090708/4d3fa0ac/attachment.pgp From ianjhart at ntlworld.com Wed Jul 8 11:24:39 2009 From: ianjhart at ntlworld.com (Ian J Hart) Date: Wed Jul 8 11:24:47 2009 Subject: zpool scrub errors on 3ware 9550SXU In-Reply-To: <3c1674c90907071412t346b1591rfecfae22bb60a8f5@mail.gmail.com> References: <20090624153442.137934uzyotkb5og@10.248.192.16> <20090707210345.13681mi2dwvan78k@webmail.private.lan> <3c1674c90907071412t346b1591rfecfae22bb60a8f5@mail.gmail.com> Message-ID: <20090708122417.14619w86w7wfu4ms@10.248.192.16> Quoting Kip Macy : > Did you answer my question of whether or not this can be reproduced > on 7-STABLE? Yes I did, but the threading is a little broken, sorry that's my fault. To reiterate, with 7 stable circa Jun 25th scrubs complete okay on the exact same hardware and v6 zpool as fails under 8.0-BETA1. I'm scrubbing under 7 every time a run under 8 fails. A reminder of the setup. 3ware 9550SXU-16 16x 1.5TB seagate. These drives throw bad sectors! 2 8 disk raidz2 vdevs combined into one pool.21.8TB. Test file system with compression on copies 2 I don't think this is a zfs error as such, it looks like the card gives up, which then spawns a whole series of bogus checksum errors (but what do I know). It's odd that it seems to take 40m+ to fail. Offsets are always large. How can I test for/eliminate any LBA error? What else might cause the card to fail (after 40m)? BTW I have to put this into production soon, so I can start testing all the other stuff which might not work (ie samba). Thanks for your help. > > > -Kip > > > > On Tue, Jul 7, 2009 at 1:03 PM, Ian J Hart wrote: >> Quoting ianjhart@ntlworld.com: >> >>> Quoting ianjhart@ntlworld.com: >>> >>>> Quoting Kip Macy : >>>> >>>>>> >>>>>> As usual scrubs cleanly on 7.2. Started throwing errors within a few >>>>>> minutes under 8. Then it paniced, possibly due to scrub -s. >>>>>> >>>>>> It's sat at the DB prompt if there's anything I can do. I'll need >>>>>> idiots guide level instruction. I have a screen dump if someone >>>>>> want to step >>>>>> up. Off list? >>>>>> >>>>>> Highlight seems to be... >>>>>> >>>>>> Memory modified after free 0xffffff0004da0c00(248) val=3000000 @ >>>>>> 0xffffff0004dc00 >>>>>> Panic: most recently used by none >>>>> >>>>> Can you test with recent 7-STABLE? That would tell me whether or not >>>>> your hitting a general HEAD issues or problems with the v13 import. >>>> >>>> It's doing a scrub under 7.2 following another failed test. I'll pull it >>>> up to stable after that. >>>> >>>> Have more data will post that once I've done a couple a jobs. >>>> >>>>> >>>>> Thanks, >>>>> Kip >>> >>> Here's that extra data. >>> >>> Updated 3ware/AMCC card firmware. >>> >>> Enable onboard SATA and fit a 300GB SATA disk. Remove the floppy and fit a >>> second 300GB SATA disk. >>> >>> Remove the two 500GB disks and replace with 1.5TB units. I can now create >>> two 8 disk raidz2 giving the same 12 disks worth of storage I had with one >>> 14 disk raidz2. >>> >>> Reinstall the two O/S on the 300GB drives. >>> >>> >>> May be of use to someone, so bear with me. >>> >>> Reset to BIOS defaults. Some issues! Disabling sound helps. >>> >>> Now suspect motherboard BIOS may be part of the problem. Removed both >>> cards and tested each version in turn. >>> >>> ref: http://www.tyan.com.tw/support_download_bios.aspx?model=S.S2895 >>> >>> Started with 1.04 ended up with 1.04. Versions after, detect the internal; >>> SATA disks as 150 not 300. Most versions lock the keyboard (KVM) >>> when legacy >>> USB is enabled. That's a PITA when you've just taken the floopy disk out.No >>> internal SATA disk settings. Be nice to check the geometry as 7 and 8 >>> sysinstall seem to be behaving differently. >>> >>> With the cards back in. >>> >>> Add an ATA disk and CDROM while testing.Easyboot order is SATA0 ATA0 >>> SATA1. Fdisk the so far blank ATA disk :) >>> >>> On board audio clashes with something. BIOS 1.03 and later supports 16 >>> SCSI boot devices. I disabled booting from the RAID card to allow the >>> onboard SATA drives to boot. >>> >>> Out of space for option ROM error has gone. >>> >>> AFAIK CPUs are late enough to support DDR400. Check anyway. Clock down to >>> 333Mhz. Still fails. >>> >>> >>> >>> There's one last thing, this BIOS (1.04) does not supply the fix for AMD >>> errata 169. Later BIOS incorrectly detect the onboard SATA disks. >>> >>> Northbridge System Request Queue may stall. >>> >>> ref: >>> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf >>> >>> We don't seem to ?have /dev/msr. Could I fix this using (the shiny new) >>> cpucontrol? >>> >>> Thanks >>> >>> ---------------------------------------------------------------- >>> This message was sent using IMP, the Internet Messaging Program. >>> >>> >>> _______________________________________________ >>> 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" >>> >> >> FWIW this is still reproducable with 8.0-BETA1. >> >> -- >> ian j hart >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> _______________________________________________ >> 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 > _______________________________________________ > 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" > -- ian j hart -- ian j hart ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From mexas at bristol.ac.uk Wed Jul 8 11:40:26 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 8 11:40:38 2009 Subject: buildworld panic on ia64 In-Reply-To: <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> Message-ID: <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> On Tue, Jul 07, 2009 at 05:29:06PM -0700, Marcel Moolenaar wrote: > > On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: > >> I tried to reproduce the error, got this on the way: > >> > >> # XXX: bogusly disabled high FP regs > > > > I get this message quite often as well; I intend to figure out what's > > going on. Marcel, if you have any idea, please let me know. > > It's a race condition. The high FP registers are lazily > context-switched and this error is emitted when a thread > wants to use the high FP registers when they are disabled > and the CPU onto which the thread is running has the high > FP registers corresponding to that thread in registers. > In that scenario the high FP registers should not even be > disabled. > > In the above case the kernel simply enables the high FP > registers and continues the thread. For the most part the > condition is harmless, but I've been looking at a panic > that's the result of inconsistency in the high FP state, > so the race is potentially fatal. > > BTW: I never got the error when doing a buildworld. I > think Anton's non-standard compiler options make GCC much > more FP intensive and thus prone to causing the race. hey, my compiler options are just a copy from /usr/share/examples/etc/make.conf with obvious changes, e.g. CPUTYPE=itanium2 The CFLAGS, COPTFLAGS, CXXFLAGS are as in the example make.conf. Which non-standard options did you spot? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Wed Jul 8 11:49:32 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 8 11:49:44 2009 Subject: buildworld panic on ia64 In-Reply-To: <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> Message-ID: <20090708114925.GA19854@mech-cluster238.men.bris.ac.uk> On Tue, Jul 07, 2009 at 05:29:06PM -0700, Marcel Moolenaar wrote: > > On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: > >> I tried to reproduce the error, got this on the way: > >> > >> # XXX: bogusly disabled high FP regs > > > > I get this message quite often as well; I intend to figure out what's > > going on. Marcel, if you have any idea, please let me know. > > It's a race condition. The high FP registers are lazily > context-switched and this error is emitted when a thread > wants to use the high FP registers when they are disabled > and the CPU onto which the thread is running has the high > FP registers corresponding to that thread in registers. > In that scenario the high FP registers should not even be > disabled. > > In the above case the kernel simply enables the high FP > registers and continues the thread. For the most part the > condition is harmless, but I've been looking at a panic > that's the result of inconsistency in the high FP state, > so the race is potentially fatal. > > BTW: I never got the error when doing a buildworld. I > think Anton's non-standard compiler options make GCC much > more FP intensive and thus prone to causing the race. Marcel, sorry, I probably misunderstood "compiler options" in the previous reply. Did you mean -j option in make -j10 buildworld? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Wed Jul 8 13:19:30 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 8 13:19:49 2009 Subject: is it safe to reboot while gmirror is rebuilding? Message-ID: <20090708131923.GA20219@mech-cluster238.men.bris.ac.uk> On FBSD 8.0-current ia64 I've gmirror on 63GB partition, which takes quite a long time to rebuild, perhaps 30 min. Is it safe to reboot, or write to this filesystem, while it is being rebuilt (gmirror status DEGRADED) ? many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From spambox at haruhiism.net Wed Jul 8 13:22:41 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Wed Jul 8 13:22:48 2009 Subject: is it safe to reboot while gmirror is rebuilding? In-Reply-To: <20090708131923.GA20219@mech-cluster238.men.bris.ac.uk> References: <20090708131923.GA20219@mech-cluster238.men.bris.ac.uk> Message-ID: <4A549D9F.9030209@haruhiism.net> Anton Shterenlikht wrote: > On FBSD 8.0-current ia64 I've gmirror on 63GB partition, which > takes quite a long time to rebuild, perhaps 30 min. Is it > safe to reboot, or write to this filesystem, while it is > being rebuilt (gmirror status DEGRADED) ? > > Doesn't matter which version it is; gmirror checkpoints the rebuild process so you can safely reboot/write/etc. -- Kamigishi Rei KREI-RIPE From ariff at FreeBSD.org Wed Jul 8 14:44:34 2009 From: ariff at FreeBSD.org (Ariff Abdullah) Date: Wed Jul 8 14:44:41 2009 Subject: LOR on kldunload snd_hda In-Reply-To: <200907072214.01645.gnemmi@gmail.com> References: <200907072214.01645.gnemmi@gmail.com> Message-ID: <20090708224429.7d2bb3c0.ariff@FreeBSD.org> On Tue, 7 Jul 2009 22:14:01 -0300 Gonzalo Nemmi wrote: > log in > kldload snd_hda > cat /dev/sndstat > > FreeBSD Audio Driver (newpcm: 32 bit 20090615000/i386) > Installed devices: > pcm0: at cad 0 nid 1 on hdac0 > kld snd_hda > [MPSAFE] (1p:1v/1r:1v channels duplex default) > > mixer > Mixer vol is currently set to 75:75 > Mixer pcm is currently set to 75:75 > Mixer speaker is currently set to 75:75 > Mixer mic is currently set to 0:0 > Mixer rec is currently set to 0:0 > > "insert cd" > > cdcontrol -f /dev/acd0 play 1 > > "no sound at all" > Hardware vendors nowadays tend to ignore analog connection between cd drive and sound card. Obviously, you don't have "cd" mixer . cdcontrol Instead, try dd if=/dev/acd0t01 of=/dev/dspcd bs=2352 . Or use other proper multimedia player with digital audio extraction support. > cdcontrol eject > kldunload snd_hda > > Jul 7 21:44:15 gargoyle login: ROOT LOGIN (root) ON ttyv0 > Jul 7 21:54:27 gargoyle kernel: hdac0: Definition Audio Controller> mem 0xf6dfc000-0xf6dfffff irq 21 at > device 27.0 on pci0 > Jul 7 21:54:27 gargoyle kernel: hdac0: HDA Driver Revision: > 20090624_0136 > Jul 7 21:54:27 gargoyle kernel: hdac0: [ITHREAD] > Jul 7 21:54:27 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel > STAC9228X Jul 7 21:54:27 gargoyle kernel: pcm0: STAC9228X PCM #0 Analog> at cad 0 nid 1 on hdac0 > Jul 7 22:03:27 gargoyle kernel: lock order reversal: > Jul 7 22:03:27 gargoyle kernel: 1st 0xc0da8cdc kernel linker > (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1079 > Jul 7 22:03:27 gargoyle kernel: 2nd 0xc0daa4e4 sysctl lock (sysctl > lock) @ /usr/src/sys/kern/kern_sysctl.c:255 This probably has nothing or little to do with snd_hda. There are other kernel modules that might trigger this kind of LOR during detach due to freeing sysctl context. > Jul 7 22:03:27 gargoyle kernel: KDB: stack backtrace: > Jul 7 22:03:27 gargoyle kernel: > db_trace_self_wrapper(c0c5b564,e6df7ac0,c08b5b35,c08a68db,c0c5e3f9, > ...) at db_trace_self_wrapper+0x26 > Jul 7 22:03:27 gargoyle kernel: > kdb_backtrace(c08a68db,c0c5e3f9,c452cae8,c452ad40,e6df7b1c,...) at > kdb_backtrace+0x29 > Jul 7 22:03:27 gargoyle kernel: > _witness_debugger(c0c5e3f9,c0daa4e4,c0c58fbb,c452ad40,c0c58ec2,...) > at _witness_debugger+0x25 > Jul 7 22:03:27 gargoyle kernel: > witness_checkorder(c0daa4e4,9,c0c58ec2,ff,0,...) at > witness_checkorder+0x839 > Jul 7 22:03:27 gargoyle kernel: > _sx_xlock(c0daa4e4,0,c0c58ec2,ff,0,...) at _sx_xlock+0x85 > Jul 7 22:03:27 gargoyle kernel: > sysctl_ctx_free(c4d7379c,0,c4e1c712,4a1,c4ca9480,...) at > sysctl_ctx_free+0x30 > Jul 7 22:03:27 gargoyle kernel: > pcm_unregister(c488f800,c4da3860,c0d3b6c8,a3c,c4887a80,...) at > pcm_unregister+0x4e1m,ksd > Jul 7 22:03:27 gargoyle kernel: > device_detach(c488f800,c0865663,c0da9df0,c4dd22d4,c4a95100,...) at > device_detach+0x8c > Jul 7 22:03:27 gargoyle kernel: > driver_module_handler(c4887a80,1,c4dd22d4,109,0,...) at > driver_module_handler+0x29c > Jul 7 22:03:27 gargoyle kernel: > module_unload(c4887a80,c0c54c7c,273,270,c08592b6,...) at > module_unload+0x43 > Jul 7 22:03:27 gargoyle kernel: > linker_file_unload(c4a92600,0,c0c54c7c,437,c4dba000,...) at > linker_file_unload+0x15e > Jul 7 22:03:27 gargoyle kernel: > kern_kldunload(c4ca9480,2,0,e6df7d2c,c0b98e73,...) at > kern_kldunload+0xd5 > Jul 7 22:03:27 gargoyle kernel: > kldunloadf(c4ca9480,e6df7cf8,8,c0c5f4bb,c0d3f0b0,...) at > kldunloadf+0x2b > Jul 7 22:03:27 gargoyle kernel: syscall(e6df7d38) at syscall+0x2a3 > Jul 7 22:03:27 gargoyle kernel: Xint0x80_syscall() at > Xint0x80_syscall+0x20 > Jul 7 22:03:27 gargoyle kernel: --- syscall (444, FreeBSD ELF32, > kldunloadf), eip = 0x280d573b, esp = 0xbfbfe47c, ebp = 0xbfbfecc8 > --- Jul 7 22:03:27 gargoyle kernel: pcm0: detached > Jul 7 22:03:27 gargoyle kernel: hdac0: detached > > -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ ... Going with the standard and orthodox is the death of intellect .............. -------------- 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/20090708/3fc27650/attachment.pgp From ariff at FreeBSD.org Wed Jul 8 14:51:31 2009 From: ariff at FreeBSD.org (Ariff Abdullah) Date: Wed Jul 8 14:51:38 2009 Subject: LOR on kldunload snd_hda In-Reply-To: <11167f520907071854q5e7e9658mfd082fbd95c5c8a0@mail.gmail.com> References: <200907072214.01645.gnemmi@gmail.com> <11167f520907071854q5e7e9658mfd082fbd95c5c8a0@mail.gmail.com> Message-ID: <20090708225124.69372b06.ariff@FreeBSD.org> On Tue, 7 Jul 2009 20:54:33 -0500 "Sam Fourman Jr." wrote: > [....] > I have a similar problem with snd_hda > on a 6-1-2009 -CURRENT i386 kernel everything is fine > but on a 6-24-2009 -CURRENT i386 kernel > I have sound in vlc, but not in my wine applications > > the moment I boot into a 6-1-2009 kernel everything works fine. > Wine has its own issues. Either set audio Hardware Acceleration to "Emulation" through winecfg , or rebuild wine with this patch: http://people.freebsd.org/~ariff/ports/emulators_wine/patch-xzz -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ ... Going with the standard and orthodox is the death of intellect .............. -------------- 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/20090708/61ee3024/attachment.pgp From hopet at ics.muni.cz Wed Jul 8 14:52:38 2009 From: hopet at ics.muni.cz (Petr Holub) Date: Wed Jul 8 14:52:47 2009 Subject: 8.0-BETA1 lock reversal Message-ID: <005a01c9ffd8$4db1b340$e91519c0$@muni.cz> Hi, after upgrading from 7.2 to 8.0-BETA1 today, I've noticed the lock reversal notifications in various parts of the storage subsystem. Examples are shown below. I'm running i386 with GENERIC kernel. Let me know if more info is needed. Petr -----Original Message----- From: Petr Holub [mailto:hopet@evenstar.ics.muni.cz] Sent: Wednesday, July 08, 2009 1:18 PM To: hopet@ics.muni.cz Subject: kloboucek-8.0-BETA1-problem Jul 8 13:04:02 kloboucek kernel: lock order reversal: Jul 8 13:04:02 kloboucek kernel: 1st 0xc744437c ntfs (ntfs) @ /usr/src/sys/kern /vfs_subr.c:2404 Jul 8 13:04:02 kloboucek kernel: 2nd 0xc737b724 ntnode (ntnode) @ /usr/src/sys/ modules/ntfs/../../fs/ntfs/ntfs_subr.c:361 Jul 8 13:04:02 kloboucek kernel: KDB: stack backtrace: Jul 8 13:04:02 kloboucek kernel: db_trace_self_wrapper(c0c5b564,e973b978,c08b5b 35,c08a68db,c0c5e3f9,...) at db_trace_self_wrapper+0x26 Jul 8 13:04:02 kloboucek kernel: kdb_backtrace(c08a68db,c0c5e3f9,c6d310c8,c6d30 ff8,e973b9d4,...) at kdb_backtrace+0x29 Jul 8 13:04:02 kloboucek kernel: _witness_debugger(c0c5e3f9,c737b724,c7453600,c 6d30ff8,c745391f,...) at _witness_debugger+0x25 Jul 8 13:04:02 kloboucek kernel: witness_checkorder(c737b724,9,c745391f,169,0,. ..) at witness_checkorder+0x839 Jul 8 13:04:02 kloboucek kernel: __lockmgr_args(c737b724,80100,c737b740,0,0,... ) at __lockmgr_args+0x7a7 Jul 8 13:04:02 kloboucek kernel: ntfs_ntget(c737b700,c74443f0,c74443e0,c737b700 ,e973bb04,...) at ntfs_ntget+0x75 Jul 8 13:04:02 kloboucek kernel: ntfs_reclaim(e973bb04,1,0,c7444324,e973bb28,.. .) at ntfs_reclaim+0x3b Jul 8 13:04:02 kloboucek kernel: VOP_RECLAIM_APV(c7454200,e973bb04,0,0,c7444398 ,...) at VOP_RECLAIM_APV+0xa5 Jul 8 13:04:02 kloboucek kernel: vgonel(c7444398,0,c0c6567e,986,1,...) at vgone l+0x1a4 Jul 8 13:04:02 kloboucek kernel: vflush(c73a4c94,0,1,c75e1240,c75e1240,...) at vflush+0x337 Jul 8 13:04:02 kloboucek kernel: ntfs_unmount(c73a4c94,8000000,c0c64e9d,4f4,80, ...) at ntfs_unmount+0x59 Jul 8 13:04:02 kloboucek kernel: dounmount(c73a4c94,8000000,c75e1240,479,7,...) at dounmount+0x46d Jul 8 13:04:02 kloboucek kernel: unmount(c75e1240,e973bcf8,8,c75e1240,c0d3c288, ...) at unmount+0x30f Jul 8 13:04:02 kloboucek kernel: syscall(e973bd38) at syscall+0x2a3 Jul 8 13:04:02 kloboucek kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 8 13:04:02 kloboucek kernel: --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280c59af, esp = 0xbfbfe5bc, ebp = 0xbfbfe678 --- Jul 8 13:04:02 kloboucek kernel: lock order reversal: Jul 8 13:04:02 kloboucek kernel: 1st 0xc7445058 ufs (ufs) @ /usr/src/sys/kern/v fs_mount.c:1199 Jul 8 13:04:02 kloboucek kernel: 2nd 0xc74447ac devfs (devfs) @ /usr/src/sys/ke rn/vfs_subr.c:2188 Jul 8 13:04:02 kloboucek kernel: KDB: stack backtrace: Jul 8 13:04:02 kloboucek kernel: db_trace_self_wrapper(c0c5b564,e973ba2c,c08b5b 35,c08a68db,c0c5e3f9,...) at db_trace_self_wrapper+0x26 Jul 8 13:04:02 kloboucek kernel: kdb_backtrace(c08a68db,c0c5e3f9,c6d30d88,c6d30 cb8,e973ba88,...) at kdb_backtrace+0x29 Jul 8 13:04:02 kloboucek kernel: _witness_debugger(c0c5e3f9,c74447ac,c0c4d3c5,c 6d30cb8,c0c6567e,...) at _witness_debugger+0x25 Jul 8 13:04:02 kloboucek kernel: witness_checkorder(c74447ac,9,c0c6567e,88c,0,. ..) at witness_checkorder+0x839 Jul 8 13:04:02 kloboucek kernel: __lockmgr_args(c74447ac,80100,c74447c8,0,0,... ) at __lockmgr_args+0x7a7 Jul 8 13:04:02 kloboucek kernel: vop_stdlock(e973bb90,4,c0c56a67,80100,c7444754 ,...) at vop_stdlock+0x62 Jul 8 13:04:02 kloboucek kernel: VOP_LOCK1_APV(c0d38d00,e973bb90,c0da89d8,c0d75 c00,c7444754,...) at VOP_LOCK1_APV+0xb5 Jul 8 13:04:02 kloboucek kernel: _vn_lock(c7444754,80100,c0c6567e,88c,c74534f8, ...) at _vn_lock+0x5e Jul 8 13:04:02 kloboucek kernel: vrele(c7444754,c0c64e9d,469,200,c75e1240,...) at vrele+0x137 Jul 8 13:04:02 kloboucek kernel: ntfs_unmount(c73a4c94,8000000,c0c64e9d,4f4,80, ...) at ntfs_unmount+0x1a0 Jul 8 13:04:02 kloboucek kernel: dounmount(c73a4c94,8000000,c75e1240,479,7,...) at dounmount+0x46d Jul 8 13:04:02 kloboucek kernel: unmount(c75e1240,e973bcf8,8,c75e1240,c0d3c288, ...) at unmount+0x30f Jul 8 13:04:02 kloboucek kernel: syscall(e973bd38) at syscall+0x2a3 Jul 8 13:04:02 kloboucek kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 8 13:04:02 kloboucek kernel: --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280c59af, esp = 0xbfbfe5bc, ebp = 0xbfbfe678 --- Jul 8 13:04:14 kloboucek kernel: lock order reversal: Jul 8 13:04:14 kloboucek kernel: 1st 0xdace6460 bufwait (bufwait) @ /usr/src/sy s/kern/vfs_bio.c:2558 Jul 8 13:04:14 kloboucek kernel: 2nd 0xc73b9c00 dirhash (dirhash) @ /usr/src/sy s/ufs/ufs/ufs_dirhash.c:285 Jul 8 13:04:14 kloboucek kernel: KDB: stack backtrace: Jul 8 13:04:14 kloboucek kernel: db_trace_self_wrapper(c0c5b564,e97a0768,c08b5b 35,c08a68db,c0c5e3f9,...) at db_trace_self_wrapper+0x26 Jul 8 13:04:14 kloboucek kernel: kdb_backtrace(c08a68db,c0c5e3f9,c6d2cf60,c6d30 df0,e97a07c4,...) at kdb_backtrace+0x29 Jul 8 13:04:14 kloboucek kernel: _witness_debugger(c0c5e3f9,c73b9c00,c0c7e6a2,c 6d30df0,c0c7e33b,...) at _witness_debugger+0x25 Jul 8 13:04:14 kloboucek kernel: witness_checkorder(c73b9c00,9,c0c7e33b,11d,0,. ..) at witness_checkorder+0x839 Jul 8 13:04:14 kloboucek kernel: _sx_xlock(c73b9c00,0,c0c7e33b,11d,c73aed24,... ) at _sx_xlock+0x85 Jul 8 13:04:14 kloboucek kernel: ufsdirhash_acquire(dace6400,e97a08dc,200,daf57 800,e97a0894,...) at ufsdirhash_acquire+0x35 Jul 8 13:04:14 kloboucek kernel: ufsdirhash_add(c73aed24,e97a08dc,800,e97a0880, e97a0884,...) at ufsdirhash_add+0x13 Jul 8 13:04:14 kloboucek kernel: ufs_direnter(c71a5c90,c75bd754,e97a08dc,e97a0b d4,0,...) at ufs_direnter+0x729 Jul 8 13:04:14 kloboucek kernel: ufs_makeinode(e97a0bd4,0,e97a0ac8,e97a0a24,c0b a67e5,...) at ufs_makeinode+0x4f8 Jul 8 13:04:14 kloboucek kernel: ufs_create(e97a0ac8,e97a0ae0,0,0,e97a0ba8,...) at ufs_create+0x30 Jul 8 13:04:14 kloboucek kernel: VOP_CREATE_APV(c0d5d160,e97a0ac8,e97a0bd4,e97a 0a60,0,...) at VOP_CREATE_APV+0xa5 Jul 8 13:04:14 kloboucek kernel: vn_open_cred(e97a0ba8,e97a0c5c,180,0,c73a8700, ...) at vn_open_cred+0x200 Jul 8 13:04:14 kloboucek kernel: vn_open(e97a0ba8,e97a0c5c,180,c73e71f8,0,...) at vn_open+0x3b Jul 8 13:04:14 kloboucek kernel: kern_openat(c75e2d80,ffffff9c,28e1e6d0,0,a03,. ..) at kern_openat+0x118 Jul 8 13:04:14 kloboucek kernel: kern_open(c75e2d80,28e1e6d0,0,a02,180,...) at kern_open+0x35 Jul 8 13:04:14 kloboucek kernel: open(c75e2d80,e97a0cf8,c,c0c3fdfb,c0d3c0ac,... ) at open+0x30 Jul 8 13:04:14 kloboucek kernel: syscall(e97a0d38) at syscall+0x2a3 Jul 8 13:04:14 kloboucek kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 8 13:04:14 kloboucek kernel: --- syscall (5, FreeBSD ELF32, open), eip = 0x 28a5b13b, esp = 0xbfbfdffc, ebp = 0xbfbfe028 --- lock order reversal: 1st 0xdacfa200 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xc73b8c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper(c0c5b564,e97d4768,c08b5b35,c08a68db,c0c5e3f9,...) at db_tr ace_self_wrapper+0x26 kdb_backtrace(c08a68db,c0c5e3f9,c6d2cf60,c6d30df0,e97d47c4,...) at kdb_backtrace +0x29 _witness_debugger(c0c5e3f9,c73b8c00,c0c7e6a2,c6d30df0,c0c7e33b,...) at _witness_ debugger+0x25 witness_checkorder(c73b8c00,9,c0c7e33b,11d,0,...) at witness_checkorder+0x839 _sx_xlock(c73b8c00,0,c0c7e33b,11d,c7440828,...) at _sx_xlock+0x85 ufsdirhash_acquire(dacfa1a0,e97d48dc,200,db321a18,e97d4894,...) at ufsdirhash_ac quire+0x35 ufsdirhash_add(c7440828,e97d48dc,2a18,e97d4880,e97d4884,...) at ufsdirhash_add+0 x13 ufs_direnter(c744153c,c813953c,e97d48dc,e97d4bd4,0,...) at ufs_direnter+0x729 ufs_makeinode(e97d4bd4,0,e97d4ac8,e97d4a24,c0ba67e5,...) at ufs_makeinode+0x4f8 ufs_create(e97d4ac8,e97d4ae0,0,0,e97d4ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0d5d160,e97d4ac8,e97d4bd4,e97d4a60,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(e97d4ba8,e97d4c5c,180,0,c7357480,...) at vn_open_cred+0x200 vn_open(e97d4ba8,e97d4c5c,180,c73e7690,4a0c65bf,...) at vn_open+0x3b kern_openat(c9119000,ffffff9c,bfbfddec,0,a03,...) at kern_openat+0x118 kern_open(c9119000,bfbfddec,0,a02,180,...) at kern_open+0x35 open(c9119000,e97d4cf8,c,c0c5ec8a,c0d3c0ac,...) at open+0x30 syscall(e97d4d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2815afe3, esp = 0xbfbfd8ec, ebp = 0xbfbfdd98 --- From bzeeb-lists at lists.zabbadoz.net Wed Jul 8 15:05:09 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Jul 8 15:05:16 2009 Subject: 8.0-BETA1 lock reversal In-Reply-To: <005a01c9ffd8$4db1b340$e91519c0$@muni.cz> References: <005a01c9ffd8$4db1b340$e91519c0$@muni.cz> Message-ID: <20090708150031.E245@maildrop.int.zabbadoz.net> On Wed, 8 Jul 2009, Petr Holub wrote: > Hi, > > after upgrading from 7.2 to 8.0-BETA1 today, I've noticed the > lock reversal notifications in various parts of the storage > subsystem. Examples are shown below. I'm running i386 with > GENERIC kernel. Let me know if more info is needed. Please start reading here, take the time to check the LORs and then report back in detail as said on that page; you'll save a lot of time of quiet a few people: http://sources.zabbadoz.net/freebsd/lor.html Thanks a lot Bjoern -- Bjoern A. Zeeb The greatest risk is not taking one. From tevans.uk at googlemail.com Wed Jul 8 15:27:39 2009 From: tevans.uk at googlemail.com (Tom Evans) Date: Wed Jul 8 15:27:45 2009 Subject: LOR on kldunload snd_hda In-Reply-To: <20090708225124.69372b06.ariff@FreeBSD.org> References: <200907072214.01645.gnemmi@gmail.com> <11167f520907071854q5e7e9658mfd082fbd95c5c8a0@mail.gmail.com> <20090708225124.69372b06.ariff@FreeBSD.org> Message-ID: <1247065585.2437.330.camel@strangepork.london.mintel.ad> On Wed, 2009-07-08 at 22:51 +0800, Ariff Abdullah wrote: > On Tue, 7 Jul 2009 20:54:33 -0500 > "Sam Fourman Jr." wrote: > > > > [....] > > I have a similar problem with snd_hda > > on a 6-1-2009 -CURRENT i386 kernel everything is fine > > but on a 6-24-2009 -CURRENT i386 kernel > > I have sound in vlc, but not in my wine applications > > > > the moment I boot into a 6-1-2009 kernel everything works fine. > > > > Wine has its own issues. Either set audio Hardware Acceleration to > "Emulation" through winecfg , or rebuild wine with this patch: > > http://people.freebsd.org/~ariff/ports/emulators_wine/patch-xzz > > Or fire up a terminal, and run: while true; do mixer pcm 80; sleep 1; done while you run your wine apps. Not elegant, but it works. From xcllnt at mac.com Wed Jul 8 16:20:11 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Jul 8 16:20:19 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> Message-ID: <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> On Jul 8, 2009, at 4:40 AM, Anton Shterenlikht wrote: >> BTW: I never got the error when doing a buildworld. I >> think Anton's non-standard compiler options make GCC much >> more FP intensive and thus prone to causing the race. > > hey, my compiler options are just a copy from > /usr/share/examples/etc/make.conf > > with obvious changes, e.g. CPUTYPE=itanium2 > The CFLAGS, COPTFLAGS, CXXFLAGS are as in the example make.conf. > > Which non-standard options did you spot? All of them :-) There is no /etc/make.conf by default, so the existence of /etc/make.conf with CFLAGS, COPTFLAGS, etc makes them non-standard. As a special warning: /usr/share/examples/etc/make.conf is inherently i386 biases (like most of the examples and documentation I might add). It's unwise to copy flags from there and expect good results. Even warnings-only examples can cause build breakages (due to -Werror), because compilers for different architectures emit different warnings or emit the same warning at different times. By all means: experiment. But be very careful not to make the assumption that if the code compiles, it'll also run. The weirder the set of compiler options, the more likely you trip over optimization bugs and end up with an unstable system. And I'm not even talking about whether the set of options give you more optimal code in general. -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Wed Jul 8 16:26:15 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Jul 8 16:26:21 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090708114925.GA19854@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114925.GA19854@mech-cluster238.men.bris.ac.uk> Message-ID: On Jul 8, 2009, at 4:49 AM, Anton Shterenlikht wrote: > On Tue, Jul 07, 2009 at 05:29:06PM -0700, Marcel Moolenaar wrote: >> >> On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: >>>> I tried to reproduce the error, got this on the way: >>>> >>>> # XXX: bogusly disabled high FP regs >>> >>> I get this message quite often as well; I intend to figure out >>> what's >>> going on. Marcel, if you have any idea, please let me know. >> >> It's a race condition. The high FP registers are lazily >> context-switched and this error is emitted when a thread >> wants to use the high FP registers when they are disabled >> and the CPU onto which the thread is running has the high >> FP registers corresponding to that thread in registers. >> In that scenario the high FP registers should not even be >> disabled. >> >> In the above case the kernel simply enables the high FP >> registers and continues the thread. For the most part the >> condition is harmless, but I've been looking at a panic >> that's the result of inconsistency in the high FP state, >> so the race is potentially fatal. >> >> BTW: I never got the error when doing a buildworld. I >> think Anton's non-standard compiler options make GCC much >> more FP intensive and thus prone to causing the race. > > Marcel, sorry, I probably misunderstood "compiler options" > in the previous reply. Did you mean -j option in > make -j10 buildworld? -j is a make option. Modulo the FP race you're perfectly fine with any -j value that matches the number of CPUs in your box (with 4xNCPUS a rule-of-thumb maximum probably). If the compiler isn't FP intensive, then even -j128 on a dual- CPU box is not causing you problems (it's pointless though :-) FYI, -- Marcel Moolenaar xcllnt@mac.com From ubm at u-boot-man.de Wed Jul 8 18:00:06 2009 From: ubm at u-boot-man.de (Marc UBM Bocklet) Date: Wed Jul 8 18:14:28 2009 Subject: run interrupt driven hooks: still waiting for xpt_config Message-ID: <20090708192642.6b30167e.ubm@u-boot-man.de> Hiho! :-) I just put a Highpoint RocketRaid 2322 in our file server. There are no drives connected to it yet. I'm running: FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #15: Sat Jul 4 15:23:12 CEST 2009 Since I put the 2322 in, the machine hangs late in the boot process with above message. It continues to wait until: run interrupt driven hooks: still waiting for xpt_config (300 seconds) and then theres nothing. No panic, keyboard still works, I can still scroll through dmesg, but nothing more. Before it the hptrr(4) attaches, there's the following message: xpt_dev async called. I searched the archives and found some references to firewire, but the machine in question has no firewire controller. Is there anything else I can do to debug this? For the record, the card is PCIe 4x, but I put it in the PCIe 16x slot. The card seems to work fine though, I can access its BIOS and its recognized by the FreeBSD driver. I'm also running with the new ahci driver. Bye Marc -- "A sudden blow: the great wings beating still Above the staggering girl, her thighs caressed By the dark webs, her nape caught in her bill, She holds her helpless breast upon her breast." W.B. Yeats, Leda and the Swan From kmacy at freebsd.org Wed Jul 8 20:13:33 2009 From: kmacy at freebsd.org (Kip Macy) Date: Wed Jul 8 20:13:39 2009 Subject: zpool scrub errors on 3ware 9550SXU In-Reply-To: <20090708122417.14619w86w7wfu4ms@10.248.192.16> References: <20090624153442.137934uzyotkb5og@10.248.192.16> <20090707210345.13681mi2dwvan78k@webmail.private.lan> <3c1674c90907071412t346b1591rfecfae22bb60a8f5@mail.gmail.com> <20090708122417.14619w86w7wfu4ms@10.248.192.16> Message-ID: <3c1674c90907081313q31c48953u8c4bde5d0e156acf@mail.gmail.com> The reason why the results on 7-STABLE are so important is that it is now running the exact same version of ZFS as HEAD. So if you aren't seeing checksum errors on 7-STABLE then the problem lies elsewhere in the storage stack. There are so many things that could cause this that I won't even speculate. Thanks for the information. I'll try to figure out how to narrow it down. -Kip From andreast-list at fgznet.ch Wed Jul 8 20:27:04 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Wed Jul 8 20:27:11 2009 Subject: FreeBSD 8.0-BETA1 Available In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Message-ID: <4A54FB33.8060705@fgznet.ch> Ken Smith wrote: > The amd64 and i386 architectures include a file named: > > 8.0-BETA1--memstick.img > > If you copy that to a USB memory stick newer machines should be able to > boot from it and use it to install from. Note that you need to > overwrite the contents of the memory stick completely, not copy it into > an existing filesystem on the memory stick. Exactly how you do that > depends on your machine but just to give you an example this works on > the machine I tested it with: > > dd if=8.0-BETA1-amd64-memstick.img of=/dev/da0 bs=10240 conv=sync > > Be careful if you have SCSI drives, more USB disks than just the memory > stick, etc - make sure /dev/da0 (or whatever you use) is the memory > stick. Using this image for livefs based rescue mode is known to not > work, that is one of the things still being worked on. Unfortunately my biggest mem stick has only 512MB. So I tried to dd to an usb drive. (Will get a bigger stick tomorrow) I was successful in installing the image, although, a few packages did not install. I did a kern developer package. I guess the packages are missing on the .img? Right now I'm installing the other things via net. Is this method equal to an usb stick install at all? Below the top of dmesg. TIA, Andreas --- 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-BETA1 #0: Sat Jul 4 03:55:14 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 536870912 (512 MB) avail memory = 473395200 (451 MB) --- From ubm at u-boot-man.de Wed Jul 8 20:50:54 2009 From: ubm at u-boot-man.de (Marc UBM Bocklet) Date: Wed Jul 8 21:07:44 2009 Subject: run interrupt driven hooks: still waiting for xpt_config In-Reply-To: <20090708192642.6b30167e.ubm@u-boot-man.de> References: <20090708192642.6b30167e.ubm@u-boot-man.de> Message-ID: <20090708225048.ec9d9cad.ubm@u-boot-man.de> On Wed, 8 Jul 2009 19:26:42 +0200 Marc "UBM" Bocklet wrote: > > Hiho! :-) > > I just put a Highpoint RocketRaid 2322 in our file server. There are > no drives connected to it yet. > > I'm running: > > FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #15: Sat Jul 4 > 15:23:12 CEST 2009 > > Since I put the 2322 in, the machine hangs late in the boot process > with above message. It continues to wait until: > > run interrupt driven hooks: still waiting for xpt_config (300 seconds) > and then theres nothing. No panic, keyboard still works, I can still > scroll through dmesg, but nothing more. > > Before it the hptrr(4) attaches, there's the following message: > > xpt_dev async called. > > I searched the archives and found some references to firewire, but the > machine in question has no firewire controller. > > Is there anything else I can do to debug this? > > For the record, the card is PCIe 4x, but I put it in the PCIe 16x > slot. The card seems to work fine though, I can access its BIOS and > its recognized by the FreeBSD driver. > > I'm also running with the new ahci driver. for the record: verbose boot shows no additional info. Bye Marc From kensmith at cse.Buffalo.EDU Thu Jul 9 03:42:38 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Thu Jul 9 03:42:51 2009 Subject: FreeBSD 8.0-BETA1 Available In-Reply-To: <4A54FB33.8060705@fgznet.ch> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> Message-ID: <1247107223.31816.7.camel@bauer.cse.buffalo.edu> On Wed, 2009-07-08 at 22:01 +0200, Andreas Tobler wrote: > I was successful in installing the image, although, a few packages did > not install. I did a kern developer package. I guess the packages are > missing on the .img? Correct, no packages with BETA1. It's probably the documentation packages it went looking for and couldn't find. I'll be providing at least the docs packages with BETA2. Not sure if I'll start trying to provide a larger set of packages for the DVD or wait for BETA3 for that (leaning towards waiting at the moment). -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090709/9cb60c7c/attachment.pgp From yr.retarded at gmail.com Thu Jul 9 04:27:07 2009 From: yr.retarded at gmail.com (Chris Ruiz) Date: Thu Jul 9 04:27:13 2009 Subject: no em0 with r195477 Message-ID: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> i just upgraded from r194562 to r195477 in order to test BETA1 and my e1000 adapter no longer attaching to the driver. pciconf -lv output em0@pci0:0:25:0: class=0x020000 card=0x00018086 chip=0x10bd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class = network subclass = ethernet here's a quick list of relevant commits since my last kernel build: r195409, r195168, r195049, r194979, r194925, r194911, r194865. thanks, Chris -- @chrisattack ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From greenx at yartv.ru Thu Jul 9 05:33:12 2009 From: greenx at yartv.ru (Andrey Groshev) Date: Thu Jul 9 05:33:19 2009 Subject: RFC: ATA to CAM integration patch Message-ID: <4A557F71.4060700@yartv.ru> Hi, I can not install the patch. Already all try. #rm -R /usr/obj #rm -R /usr/src #cat #cat ~/greenx.sup *default host=cvsup5.ru.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix src-all #csup ~/greenx.sup ...skip... #cd /usr/src #patch -p0 < cam-ata.20090704.patch ...skip... #make buildworld ...skip... cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo sconfig.lo fdisk.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -larchive -lcrypto -lm /usr/obj/usr/src/tmp/usr/lib/libcam.a(ata_all.o)(.text+0x263): In function `ata_max_mode': : undefined reference to `min' *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. What am I doing wrong? From rhurlin at gwdg.de Thu Jul 9 06:09:20 2009 From: rhurlin at gwdg.de (Rainer Hurling) Date: Thu Jul 9 06:09:27 2009 Subject: FreeBSD 8.0-BETA1 Available In-Reply-To: <1247107223.31816.7.camel@bauer.cse.buffalo.edu> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> <1247107223.31816.7.camel@bauer.cse.buffalo.edu> Message-ID: <4A55898C.9050907@gwdg.de> Since ~ yesterday my CURRENT system notifies as BETA1 # uname -a FreeBSD pc028.nfv 8.0-BETA1 FreeBSD 8.0-BETA1 #0: Wed Jul 8 10:13:10 CEST 2009 xxx@xxx.xxx:/usr/obj/usr/src/sys/xxx i386 If I remember right, than CURRENT (HEAD) remained untouched over the last releases and only changes to next version number (i.e. 7.0 towards 8.0) when the next release was branched? Rainer Am 09.07.2009 04:40 (UTC+2) schrieb Ken Smith: > On Wed, 2009-07-08 at 22:01 +0200, Andreas Tobler wrote: >> I was successful in installing the image, although, a few packages did >> not install. I did a kern developer package. I guess the packages are >> missing on the .img? > > Correct, no packages with BETA1. It's probably the documentation > packages it went looking for and couldn't find. I'll be providing at > least the docs packages with BETA2. Not sure if I'll start trying to > provide a larger set of packages for the DVD or wait for BETA3 for that > (leaning towards waiting at the moment). > From john.marshall at riverwillow.com.au Thu Jul 9 06:21:04 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Thu Jul 9 06:21:11 2009 Subject: Process stuck in vmmaps on 8.0-BETA1 Message-ID: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> I haven't been following this list at all and have not been playing with -CURRENT systems. I have source-upgraded an i386 test server from 7.2-RELEASE-p2 to 8.0-BETA1 because I want to help with making the next -STABLE release as stable as possible. I have posted a couple of other reports to -stable but it has been suggested to me that -current is a more appropriate list? - 8.0-BETA1 GSSAPI/sshd problem http://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051061.html - 8.0-BETA1 mergemaster/ntp.conf problems http://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051074.html So,... 8.0-BETA1 VMMAPS PROBLEM After upgrading... - boot new kernel to single-user - make installworld - make delete-old - make delete-old-libs - mergemaster - reboot I re-built a few of my applications. I noticed a problem with ntpd 4.2.4p7. The build was fine, it started fine, but got stuck in vmmaps and I couldn't kill it. Stopping the operating system appears to be the only remedy. I have re-built a few times (starting with 'make distclean') just to make sure. UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 791 1 0 44 0 4944 4920 vmmaps Ds ?? 0:00.01 ntpd I have not come across this before. This ntpd distribution builds and runs happily on earler versions (6.n and 7.n) of FreeBSD. You folks have obviously got ntpd 4.2.4p5 running happily in the base system. I have looked at the configure.h in /usr/src/usr.sbin/ntp and it is identical to the corresponding file in 7.2-RELEASE (apart from version ID). Any ideas as to what may be wrong with: ./configure --disable-debugging \ --disable-all-clocks \ --disable-parse-clocks \ --disable-linuxcaps \ --without-sntp \ CFLAGS='-O -pipe -march=pentium4' make make install and why that has served me well until 8.0-BETA1? If I build ntpd 4.2.4p5 as above on 8.0-BETA1 I have the same (vmmaps) problem. The ntpd 4.2.4p5 from the base system runs fine. Thank you. -- John Marshall -------------- 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/20090709/572c8b07/attachment.pgp From pluknet at gmail.com Thu Jul 9 06:42:50 2009 From: pluknet at gmail.com (pluknet) Date: Thu Jul 9 06:42:57 2009 Subject: Process stuck in vmmaps on 8.0-BETA1 In-Reply-To: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> Message-ID: 2009/7/9 John Marshall : > After upgrading... > - boot new kernel to single-user > - make installworld > - make delete-old > - make delete-old-libs > - mergemaster > - reboot > > I re-built a few of my applications. I noticed a problem with ntpd > 4.2.4p7. The build was fine, it started fine, but got stuck in vmmaps > and I couldn't kill it. Stopping the operating system appears to be the > only remedy. I have re-built a few times (starting with 'make > distclean') just to make sure. > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 0 791 1 0 44 0 4944 4920 vmmaps Ds ?? 0:00.01 ntpd > Can you place here 'procstat -k 791', where 791 is pid of ntpd? It'd be nice also if you go through all ddb steps described in Debugging Deadlocks chapter of FreeBSD Developers' Handbook. -- wbr, pluknet From markocpc at gmail.com Thu Jul 9 06:56:16 2009 From: markocpc at gmail.com (Lagrange Marc) Date: Thu Jul 9 06:56:29 2009 Subject: Building kernel : CPUID_FXSR undeclared (first use...) Message-ID: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> Hi, I've just installed a 8-BETA1 on my new computer, checkouted the sources via svn (http://svn.freebsd.org/base/head). I've recompiled a kernel without debug and whitheness sucessfully, but when i've try to remove some things and it fails. The kernel configuration is here : http://banane.rhaamo.li/NAWAK The CPU is : CPU: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz (2499.73-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10677 Stepping = 7 Features=0xbfebfbff Features2=0x8e3fd AMD Features=0x20000800 AMD Features2=0x1 TSC: P-state invariant The kernel build error: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=native -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/amd64/amd64/in_cksum.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=native -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/amd64/amd64/initcpu.c /usr/src/sys/amd64/amd64/initcpu.c: In function 'initializecpu': /usr/src/sys/amd64/amd64/initcpu.c:146: error: 'CPUID_FXSR' undeclared (first use in this function) /usr/src/sys/amd64/amd64/initcpu.c:146: error: (Each undeclared identifier is reported only once /usr/src/sys/amd64/amd64/initcpu.c:146: error: for each function it appears in.) *** Error code 1 Stop in /usr/obj/usr/src/sys/NAWAK. *** Error code 1 Stop in /usr/src. I've also experiencing the same issue with audio/oss, it failed on CPUID_FXSR, but now fail with CPU_SSE or CPU_SSE2... If someone have an idea with this problem, Thanks. -- rhaamo on irc.freenode.net/oftc/geeknode From john.marshall at riverwillow.com.au Thu Jul 9 07:31:02 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Thu Jul 9 07:31:09 2009 Subject: Process stuck in vmmaps on 8.0-BETA1 In-Reply-To: References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> Message-ID: <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> On Thu, 09 Jul 2009, 10:42 +0400, pluknet wrote: > 2009/7/9 John Marshall : > > After upgrading... > > - boot new kernel to single-user > > - make installworld > > - make delete-old > > - make delete-old-libs > > - mergemaster > > - reboot > > > > I re-built a few of my applications. I noticed a problem with ntpd > > 4.2.4p7. The build was fine, it started fine, but got stuck in vmmaps > > and I couldn't kill it. Stopping the operating system appears to be the > > only remedy. I have re-built a few times (starting with 'make > > distclean') just to make sure. > > > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > > 0 791 1 0 44 0 4944 4920 vmmaps Ds ?? 0:00.01 ntpd > > > > Can you place here 'procstat -k 791', where 791 is pid of ntpd? > It'd be nice also if you go through all ddb steps described in > Debugging Deadlocks chapter of FreeBSD Developers' Handbook. Here is some procstat output. I'm just rebuilding the kernel with the debugging options enabled - not something I've ever done before. rwsrv05# procstat 2788 PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM 2788 1 2788 2788 0 1 john vmmaps FreeBSD ELF32 ntpd rwsrv05# procstat -k 2788 PID TID COMM TDNAME KSTACK 2788 100164 ntpd - mi_switch sleepq_switch sleepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mmap syscall Xint0x80_syscall rwsrv05# procstat -v 2788 PID START END PRT RES PRES REF SHD FL TP PATH 2788 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd 2788 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd 2788 0x8080000 0x8100000 rw- 128 0 1 0 C- df 2788 0x2807e000 0x280ab000 r-x 45 0 171 75 CN vn /libexec/ld-elf.so.1 2788 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 2788 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df 2788 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 2788 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 2788 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 2788 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 2788 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 2788 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 2788 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df 2788 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 2788 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 2788 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 2788 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 2788 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 2788 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 2788 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 2788 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 2788 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 2788 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 2788 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 2788 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 2788 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 2788 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 2788 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 2788 0x28358000 0x2836e000 rw- 22 0 1 0 C- df 2788 0x2836e000 0x2837a000 --- 0 0 0 0 -- -- 2788 0x28400000 0x28500000 rw- 256 0 1 0 C- df 2788 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df rwsrv05# -- John Marshall -------------- 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/20090709/974ca191/attachment.pgp From rwatson at FreeBSD.org Thu Jul 9 07:37:37 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Jul 9 07:37:44 2009 Subject: odd make/build output on ^Z / fg Message-ID: Today I suspended a kernel build with ^Z to free up a bit of I/O bandwidth on a box. When I re-foregrounded, all appeared fine for a bit, but later when I switched back to the xterm I found this: ototypes -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 -fstack-protector -Werror ../../../i386/acpica/acpi_wakeup.c couldn't resume mac_pipe.o: No such process *** Signal 1 couldn't resume audit_arg.o: No such process *** Signal 1 couldn't resume nlm_prot_impl.o: No such process *** Signal 1 couldn't resume nfs_serv.o: No such process *** Signal 1 couldn't resume nfs_vnops.o: No such process *** Signal 1 couldn't resume modules-obj: No such process ===> usb/uether (obj) ===> usb/aue (obj) ... ===> xfs (obj) ===> xl (obj) ===> zfs (obj) ===> zlib (obj) *** Signal 1 6 errors I've never seen that before, but I also don't suspend builds all that frequently. New bug? Old bug? Robert N M Watson Computer Laboratory University of Cambridge From rea-fbsd at codelabs.ru Thu Jul 9 07:53:28 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Jul 9 07:53:41 2009 Subject: Building kernel : CPUID_FXSR undeclared (first use...) In-Reply-To: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> References: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> Message-ID: Thu, Jul 09, 2009 at 08:24:20AM +0200, Lagrange Marc wrote: > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=native > -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 > -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 > -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -Werror /usr/src/sys/amd64/amd64/initcpu.c > /usr/src/sys/amd64/amd64/initcpu.c: In function 'initializecpu': > /usr/src/sys/amd64/amd64/initcpu.c:146: error: 'CPUID_FXSR' undeclared > (first use in this function) > /usr/src/sys/amd64/amd64/initcpu.c:146: error: (Each undeclared > identifier is reported only once > /usr/src/sys/amd64/amd64/initcpu.c:146: error: for each function it appears in.) What output will be produced by the following command (should be invoked from your kernel compile directory, /sys/amd64/compile/ if you compile manually or /usr/obj/usr/src/sys/ for 'make kernel' builds; looks like you is NAWAK): ----- cpp -dD -O2 -frename-registers -pipe -fno-strict-aliasing -march=native \ -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef \ -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys \ -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS \ -include opt_global.h -fno-common -finline-limit=8000 --param \ inline-unit-growth=100 --param large-function-growth=1000 \ -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 \ -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float \ -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector \ -Werror /usr/src/sys/amd64/amd64/initcpu.c 2>&1 ----- And what is inside the file 'machine/specialreg.h' when you're sitting in the same directory? I'd expect that 'make clean && make kernel' invoked from /usr/src should fix your problems, but may be it is not the case, so information requested above will be helpful. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From freebsdlists at bsdunix.ch Thu Jul 9 07:53:31 2009 From: freebsdlists at bsdunix.ch (Thomas Vogt) Date: Thu Jul 9 07:53:42 2009 Subject: USB stick installation problems Message-ID: <4A559E50.3090408@bsdunix.ch> Hi I download and copied 8.0-BETA1-amd64-memstick.img to an usb stick as described at http://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051018.html. I can boot it and sysinstall runs fine. Later i chose USB stick as install medium but then i get a "no USB stick found" error. Is this an know bug? Regards, Thomas From markocpc at gmail.com Thu Jul 9 08:11:13 2009 From: markocpc at gmail.com (Lagrange Marc) Date: Thu Jul 9 08:11:20 2009 Subject: Building kernel : CPUID_FXSR undeclared (first use...) In-Reply-To: References: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> Message-ID: <1b5ab4050907090111q4cb29ea7t2f7518e844efbf54@mail.gmail.com> On Thu, Jul 9, 2009 at 9:53 AM, Eygene Ryabinkin wrote: > Thu, Jul 09, 2009 at 08:24:20AM +0200, Lagrange Marc wrote: >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=native >> -std=c99 ?-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >> ?-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual ?-Wundef >> -Wno-pointer-sign -fformat-extensions -nostdinc ?-I. -I/usr/src/sys >> -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS >> -include opt_global.h -fno-common -finline-limit=8000 --param >> inline-unit-growth=100 --param large-function-growth=1000 >> -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone ?-mfpmath=387 >> -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow ?-msoft-float >> -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector >> -Werror ?/usr/src/sys/amd64/amd64/initcpu.c >> /usr/src/sys/amd64/amd64/initcpu.c: In function 'initializecpu': >> /usr/src/sys/amd64/amd64/initcpu.c:146: error: 'CPUID_FXSR' undeclared >> (first use in this function) >> /usr/src/sys/amd64/amd64/initcpu.c:146: error: (Each undeclared >> identifier is reported only once >> /usr/src/sys/amd64/amd64/initcpu.c:146: error: for each function it appears in.) > > What output will be produced by the following command (should be invoked > from your kernel compile directory, /sys/amd64/compile/ if > you compile manually or /usr/obj/usr/src/sys/ for 'make > kernel' builds; looks like you is NAWAK): > ----- > cpp -dD -O2 -frename-registers -pipe -fno-strict-aliasing -march=native \ > -std=c99 ?-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \ > ?-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual ?-Wundef \ > ?-Wno-pointer-sign -fformat-extensions -nostdinc ?-I. -I/usr/src/sys \ > ?-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS \ > ?-include opt_global.h -fno-common -finline-limit=8000 --param \ > ?inline-unit-growth=100 --param large-function-growth=1000 \ > ?-fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone ?-mfpmath=387 \ > ?-mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow ?-msoft-float \ > ?-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector \ > ?-Werror ?/usr/src/sys/amd64/amd64/initcpu.c 2>&1 > ----- Output here : http://banane.rhaamo.li/bugs/CPUID_FXSR/output_cpp > And what is inside the file 'machine/specialreg.h' when you're sitting > in the same directory? File here : http://banane.rhaamo.li/bugs/CPUID_FXSR/specialreg.h > I'd expect that 'make clean && make kernel' invoked from /usr/src > should fix your problems, but may be it is not the case, so information > requested above will be helpful. Tryied make clean && make kernel after getting requested infos, same error. Thx. > -- > Eygene > ?_ ? ? ? ? ? ? ? ?___ ? ? ? _.--. ? # > ?\`.|\..----...-'` ? `-._.-'_.-'` ? # ?Remember that it is hard > ?/ ?' ` ? ? ? ? , ? ? ? __.--' ? ? ?# ?to read the on-line manual > ?)/' _/ ? ? \ ? `-_, ? / ? ? ? ? ? ?# ?while single-stepping the kernel. > ?`-'" `"\_ ?,_.-;_.-\_ ', ?fsc/as ? # > ? ? _.-'_./ ? {_.' ? ; / ? ? ? ? ? # ? ?-- FreeBSD Developers handbook > ? ?{_.-``-' ? ? ? ? {_/ ? ? ? ? ? ?# > -- rhaamo on irc.freenode.net/oftc/geeknode From lars.engels at 0x20.net Thu Jul 9 08:13:04 2009 From: lars.engels at 0x20.net (Lars Engels) Date: Thu Jul 9 08:13:10 2009 Subject: [regression] em0: watchdog timeout Message-ID: <20090709095655.ekw77l994cggwcc0@0x20.net> Moin! After running 7.2-PRERELEASE for some time on my notebook, I decided to upgrade to 8.0-BETA1. While the em interface worked fine all the time with 7.2 I am now seeing this on the BETA: em0: watchdog timeout -- resetting Some googling told me to enable MSI but MSI was already enabled. -- Lars Engels E-Mail: lars.engels@0x20.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: PGP Digital Signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090709/c4bcd3f1/attachment.pgp From rea-fbsd at codelabs.ru Thu Jul 9 08:19:50 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Jul 9 08:19:57 2009 Subject: Building kernel : CPUID_FXSR undeclared (first use...) In-Reply-To: <1b5ab4050907090111q4cb29ea7t2f7518e844efbf54@mail.gmail.com> References: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> <1b5ab4050907090111q4cb29ea7t2f7518e844efbf54@mail.gmail.com> Message-ID: Thu, Jul 09, 2009 at 10:11:09AM +0200, Lagrange Marc wrote: > > And what is inside the file 'machine/specialreg.h' when you're sitting > > in the same directory? > > File here : http://banane.rhaamo.li/bugs/CPUID_FXSR/specialreg.h Then, it is simple: you had manually commented the line 105: ----- /*#define CPUID_FXSR 0x01000000*/ ----- Uncomment it (inside /sys/amd64/include/specialreg.h) and rebuild the stuff. Better will be to resync the sources, get rid of all local modifications (if any) and rebuild. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From h.schmalzbauer at omnilan.de Thu Jul 9 08:26:56 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Thu Jul 9 08:27:05 2009 Subject: VirtualBox stopped working with -beta1 Message-ID: <4A55A9BA.80108@omnilan.de> Hello, I've been using the great virtualbox port for some weeks with 8-current without problems. Unfortunately it stoped working with recent -current. The complete system hard freezes after starting a vbox machine. Any hints how to obtain a dump? Of course I recompiled virtualbox with the new kernel sources. Thanks, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090709/447ca003/signature.pgp From markocpc at gmail.com Thu Jul 9 08:29:12 2009 From: markocpc at gmail.com (Lagrange Marc) Date: Thu Jul 9 08:29:20 2009 Subject: Building kernel : CPUID_FXSR undeclared (first use...) In-Reply-To: References: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> <1b5ab4050907090111q4cb29ea7t2f7518e844efbf54@mail.gmail.com> Message-ID: <1b5ab4050907090129g5599d754w469170297e1b459a@mail.gmail.com> On Thu, Jul 9, 2009 at 10:19 AM, Eygene Ryabinkin wrote: > Thu, Jul 09, 2009 at 10:11:09AM +0200, Lagrange Marc wrote: >> > And what is inside the file 'machine/specialreg.h' when you're sitting >> > in the same directory? >> >> File here : http://banane.rhaamo.li/bugs/CPUID_FXSR/specialreg.h > > Then, it is simple: you had manually commented the line 105: > ----- > /*#define ? ? ? CPUID_FXSR ? ? ?0x01000000*/ > ----- > Uncomment it (inside /sys/amd64/include/specialreg.h) and rebuild > the stuff. ?Better will be to resync the sources, get rid of all > local modifications (if any) and rebuild. Argl yes... i remember commented this !@# line in oss source (thx symlinks) because oss fail on CPUID_FXSR .. Thx. > -- > Eygene > ?_ ? ? ? ? ? ? ? ?___ ? ? ? _.--. ? # > ?\`.|\..----...-'` ? `-._.-'_.-'` ? # ?Remember that it is hard > ?/ ?' ` ? ? ? ? , ? ? ? __.--' ? ? ?# ?to read the on-line manual > ?)/' _/ ? ? \ ? `-_, ? / ? ? ? ? ? ?# ?while single-stepping the kernel. > ?`-'" `"\_ ?,_.-;_.-\_ ', ?fsc/as ? # > ? ? _.-'_./ ? {_.' ? ; / ? ? ? ? ? # ? ?-- FreeBSD Developers handbook > ? ?{_.-``-' ? ? ? ? {_/ ? ? ? ? ? ?# > -- rhaamo on irc.freenode.net/oftc/geeknode From mexas at bristol.ac.uk Thu Jul 9 08:50:26 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 9 08:50:38 2009 Subject: buildworld panic on ia64 In-Reply-To: <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> Message-ID: <20090709085014.GE43264@mech-cluster238.men.bris.ac.uk> On Wed, Jul 08, 2009 at 09:19:33AM -0700, Marcel Moolenaar wrote: > > On Jul 8, 2009, at 4:40 AM, Anton Shterenlikht wrote: > > >> BTW: I never got the error when doing a buildworld. I > >> think Anton's non-standard compiler options make GCC much > >> more FP intensive and thus prone to causing the race. > > > > hey, my compiler options are just a copy from > > /usr/share/examples/etc/make.conf > > > > with obvious changes, e.g. CPUTYPE=itanium2 > > The CFLAGS, COPTFLAGS, CXXFLAGS are as in the example make.conf. > > > > Which non-standard options did you spot? > > All of them :-) > > There is no /etc/make.conf by default, so the existence > of /etc/make.conf with CFLAGS, COPTFLAGS, etc makes them > non-standard. > > As a special warning: /usr/share/examples/etc/make.conf > is inherently i386 biases (like most of the examples and > documentation I might add). It's unwise to copy flags > from there and expect good results. Even warnings-only > examples can cause build breakages (due to -Werror), > because compilers for different architectures emit > different warnings or emit the same warning at different > times. > > By all means: experiment. But be very careful not to make > the assumption that if the code compiles, it'll also run. > The weirder the set of compiler options, the more likely > you trip over optimization bugs and end up with an unstable > system. And I'm not even talking about whether the set > of options give you more optimal code in general. I see.. Is there any advice for compiler options on ia64? Perhaps a sample make.conf for ia64? Or would you recommend leaving these options empty: CFLAGS, COPTFLAGS, CXXFLAGS ? I'm sorry if I'm asking obvious questions. Perhaps this is documented/disucced somewhere already? I'm new to ia64, most of my FBSD experience is from alpha and i386. many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From john.marshall at riverwillow.com.au Thu Jul 9 08:52:49 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Thu Jul 9 08:52:55 2009 Subject: Process stuck in vmmaps on 8.0-BETA1 In-Reply-To: <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> Message-ID: <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> On Thu, 09 Jul 2009, 17:30 +1000, John Marshall wrote: > On Thu, 09 Jul 2009, 10:42 +0400, pluknet wrote: > > 2009/7/9 John Marshall : > > > After upgrading... > > > - boot new kernel to single-user > > > - make installworld > > > - make delete-old > > > - make delete-old-libs > > > - mergemaster > > > - reboot > > > > > > I re-built a few of my applications. I noticed a problem with ntpd > > > 4.2.4p7. The build was fine, it started fine, but got stuck in vmmaps > > > and I couldn't kill it. Stopping the operating system appears to be the > > > only remedy. I have re-built a few times (starting with 'make > > > distclean') just to make sure. > > > > > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > > > 0 791 1 0 44 0 4944 4920 vmmaps Ds ?? 0:00.01 ntpd > > > > > > > Can you place here 'procstat -k 791', where 791 is pid of ntpd? > > It'd be nice also if you go through all ddb steps described in > > Debugging Deadlocks chapter of FreeBSD Developers' Handbook. > > Here is some procstat output. I'm just rebuilding the kernel with the > debugging options enabled - not something I've ever done before. > > rwsrv05# procstat 2788 > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM > 2788 1 2788 2788 0 1 john vmmaps FreeBSD ELF32 ntpd > rwsrv05# procstat -k 2788 > PID TID COMM TDNAME KSTACK > 2788 100164 ntpd - mi_switch sleepq_switch sleepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mmap syscall Xint0x80_syscall > rwsrv05# procstat -v 2788 > PID START END PRT RES PRES REF SHD FL TP PATH > 2788 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd > 2788 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd > 2788 0x8080000 0x8100000 rw- 128 0 1 0 C- df > 2788 0x2807e000 0x280ab000 r-x 45 0 171 75 CN vn /libexec/ld-elf.so.1 > 2788 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 > 2788 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df > 2788 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 > 2788 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 > 2788 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 > 2788 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 > 2788 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 > 2788 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 > 2788 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df > 2788 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 > 2788 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 > 2788 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 > 2788 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 > 2788 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 > 2788 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 > 2788 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 > 2788 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 > 2788 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 > 2788 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 > 2788 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 > 2788 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 > 2788 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 > 2788 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 > 2788 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 > 2788 0x28358000 0x2836e000 rw- 22 0 1 0 C- df > 2788 0x2836e000 0x2837a000 --- 0 0 0 0 -- -- > 2788 0x28400000 0x28500000 rw- 256 0 1 0 C- df > 2788 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df > rwsrv05# OK, now that I've rebuilt the kernel with the debugging options not commented out, I'm getting a number of 'lock order reversal' messages printed on the console: is that normal? From the Debugging Deadlocks chapter to which I was referred by pluknet (above) it appears that I need to enter 'sysctl debug.kdb.enter=1' or 'sysctl debug.kdb.panic=1' after I get the process into the desired 'stuck' state. If I enter either of those commands, the system reboots. Now *I'm* stuck. -- John Marshall -------------- 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/20090709/f1fee038/attachment.pgp From serenity at exscape.org Thu Jul 9 09:02:26 2009 From: serenity at exscape.org (Thomas Backman) Date: Thu Jul 9 09:02:33 2009 Subject: "New" ZFS crash on FS (pool?) unmount/export In-Reply-To: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> References: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> Message-ID: <766FFF07-181A-4180-B020-AA3EE46CF6F8@exscape.org> On Jun 20, 2009, at 09:11, Thomas Backman wrote: > I just ran into this tonight. Not sure exactly what triggered it - > the box stopped responding to pings at 02:07AM and it has a cron > backup job using zfs send/recv at 02:00, so I'm guessing it's > related, even though the backup probably should have finished before > then... Hmm. Anyway. > > r194478. > > kernel trap 12 with interrupts disabled > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x288 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff805a4989 > stack pointer = 0x28:0xffffff803e8b57e0 > frame pointer = 0x28:0xffffff803e8b5840 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 57514 (zpool) > panic: from debugger > cpuid = 0 > Uptime: 10h22m13s > Physical memory: 2027 MB > > (kgdb) bt > #0 doadump () at pcpu.h:223 > #1 0xffffffff8059c409 in boot (howto=260) at /usr/src/sys/kern/ > kern_shutdown.c:419 > #2 0xffffffff8059c85c in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xffffffff801f1377 in db_panic (addr=Variable "addr" is not > available. > ) at /usr/src/sys/ddb/db_command.c:478 > #4 0xffffffff801f1781 in db_command (last_cmdp=0xffffffff80c38620, > cmd_table=Variable "cmd_table" is not available. > ) at /usr/src/sys/ddb/db_command.c:445 > #5 0xffffffff801f19d0 in db_command_loop () at /usr/src/sys/ddb/ > db_command.c:498 > #6 0xffffffff801f3969 in db_trap (type=Variable "type" is not > available. > ) at /usr/src/sys/ddb/db_main.c:229 > #7 0xffffffff805ce465 in kdb_trap (type=12, code=0, > tf=0xffffff803e8b5730) at /usr/src/sys/kern/subr_kdb.c:534 > #8 0xffffffff8088715d in trap_fatal (frame=0xffffff803e8b5730, > eva=Variable "eva" is not available. > ) at /usr/src/sys/amd64/amd64/trap.c:847 > #9 0xffffffff80887fb2 in trap (frame=0xffffff803e8b5730) at /usr/ > src/sys/amd64/amd64/trap.c:345 > #10 0xffffffff8086e007 in calltrap () at /usr/src/sys/amd64/amd64/ > exception.S:223 > #11 0xffffffff805a4989 in _sx_xlock_hard (sx=0xffffff0043557d50, > tid=18446742975830720512, opts=Variable "opts" is not available. > ) > at /usr/src/sys/kern/kern_sx.c:575 > #12 0xffffffff805a52fe in _sx_xlock (sx=Variable "sx" is not > available. > ) at sx.h:155 > #13 0xffffffff80fe2995 in zfs_freebsd_reclaim () from /boot/kernel/ > zfs.ko > #14 0xffffffff808cefca in VOP_RECLAIM_APV (vop=0xffffff0043557d38, > a=0xffffff0043557d50) at vnode_if.c:1926 > #15 0xffffffff80626f6e in vgonel (vp=0xffffff00437a7938) at > vnode_if.h:830 > #16 0xffffffff8062b528 in vflush (mp=0xffffff0060f2a000, rootrefs=0, > flags=0, td=0xffffff0061528000) > at /usr/src/sys/kern/vfs_subr.c:2450 > #17 0xffffffff80fdd3a8 in zfs_umount () from /boot/kernel/zfs.ko > #18 0xffffffff8062420a in dounmount (mp=0xffffff0060f2a000, > flags=1626513408, td=Variable "td" is not available. > ) > at /usr/src/sys/kern/vfs_mount.c:1287 > #19 0xffffffff80624975 in unmount (td=0xffffff0061528000, > uap=0xffffff803e8b5c00) > at /usr/src/sys/kern/vfs_mount.c:1172 > #20 0xffffffff8088783f in syscall (frame=0xffffff803e8b5c90) at /usr/ > src/sys/amd64/amd64/trap.c:984 > #21 0xffffffff8086e290 in Xfast_syscall () at /usr/src/sys/amd64/ > amd64/exception.S:364 > #22 0x000000080104e49c in ?? () > Previous frame inner to this frame (corrupt stack?) I might have hit the same thing again... only it didn't *crash* this time, just freeze! I got a "GEOM_GATE: Device ggateX destroyed" on my console, and it stopped responding to pings, keyboard input, etc. (NOTE: The GEOM_GATE message MAY have been an old one. I *think* it was from the night before but can't be sure...) It obviously happened while running my ugly-hack backup script this time too, since it stopped responding to pings ~02:02AM with the script running at 02:00. I'm not sure where it crashed, since snapshots were NOT taken on the "local box". It usually crashes during export, long after taking the snapshots. BTW, current system is BETA1 r195422M (dtrace timestamp patch + libzfs_sendrecv.c patch ( http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006814.html ). Here's the script in its relevant entirety (I removed the "initial backup" part since it never runs using cron anyway). I realize it's an ugly hack (and that my bash-fu could be stronger), but what the heck. Essentially, it creates a GEOM provider of a file, containing a zpool, imports the pool and creates a clone to it, and then exports the pool. The export appears to be what causes all the trouble - usually, not this time around. Every time it crashes it seems to be during or very soon after the export - only this time it didn't even take the snapshots. #!/bin/bash PATH="$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/ sbin" function die() { echo "$@" 2>&1 zpool export slave 2>&1 > /dev/null ggatel destroy -u 666 2>&1 > /dev/null exit 1 } function mount_unmount { if [ -z "$1" ]; then die 'Invalid argument given to mount_unmount' elif [[ "$1" == "mount" ]]; then zpool list | grep -q slave if [ "$?" = "0" ]; then echo Already mounted return 0 fi echo Creating ggate device ggatel create -u 666 /mnt/backup/chaos/slavefile || die 'Unable to create GEOM provider from file' echo 'Sleeping for 5 seconds...' sleep 5 echo Importing pool zpool import -R /slave slave || die 'Unable to import slave pool' elif [[ "$1" == "unmount" ]]; then echo Exporting pool zpool export slave || die 'Unable to export slave pool' ggatel destroy -u 666 || die 'Unable to destroy GEOM provider' fi } f [ ! -z "$1" ]; then case $1 in mount) mount_unmount mount; exit 0;; unmount) mount_unmount unmount; exit 0;; initial) initial; exit 0;; backup) ;; *) help;; esac else help fi if [ ! -f "/mnt/backup/chaos/slavefile" ]; then echo 'Backup error! slavefile does not exist!' | mail -s "Backup error" root echo 'Slavefile does not exist!' exit 1 fi mount_unmount mount CURR=$(date +"backup-%F-%H%M") echo Taking snapshots zfs snapshot -r tank@$CURR || die 'Unable to create $CURR snapshot' echo Starting backup... LAST=$(cat /root/.last-backup) zfs send -R -I $LAST tank@$CURR | zfs recv -Fvd slave echo $CURR > /root/.last-backup mount_unmount unmount echo Running rsync rsync -av --delete /bootdir/boot exscape::backup-freebsd/chaos rsync -av --delete /root exscape::backup-freebsd/chaos rsync -av --delete ~serenity exscape::backup-freebsd/chaos echo 'All done!' ------------------- So, in *normal* cases, everything runs just fine. This is the case perhaps 90% of the time. In normal *crashes*, it hangs on export with the above backtrace. This time, all I know is that it crashes soon after starting the backup... during import, perhaps? Regards, Thomas From gary.jennejohn at freenet.de Thu Jul 9 10:33:55 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Thu Jul 9 10:34:02 2009 Subject: RFC: ATA to CAM integration patch In-Reply-To: <4A557F71.4060700@yartv.ru> References: <4A557F71.4060700@yartv.ru> Message-ID: <20090709123351.267dd48a@ernst.jennejohn.org> On Thu, 09 Jul 2009 09:26:09 +0400 Andrey Groshev wrote: > I can not install the patch. > Already all try. > [snip error output] > > What am I doing wrong? > Nothing. Lucius Windschuh posted a fix in a previous message. Quoting from Lucius' mail Simply adding #ifndef min #define min(a,b) (((a)<(b))?(a):(b)) #endif in ata_all.c helps, obviously. --- Gary Jennejohn From stas at FreeBSD.org Thu Jul 9 11:39:47 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Jul 9 11:39:54 2009 Subject: no em0 with r195477 In-Reply-To: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> Message-ID: <20090709153940.4544bfa8.stas@FreeBSD.org> On Wed, 8 Jul 2009 22:58:27 -0500 Chris Ruiz mentioned: > i just upgraded from r194562 to r195477 in order to test BETA1 and my > e1000 adapter no longer attaching to the driver. > > pciconf -lv output > > em0@pci0:0:25:0: class=0x020000 card=0x00018086 chip=0x10bd8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' > class = network > subclass = ethernet > > here's a quick list of relevant commits since my last kernel build: > r195409, r195168, r195049, r194979, r194925, r194911, r194865. > Hi, Chris! Can you provide the verbose boot log? -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090709/ef2efd03/attachment.pgp From greenx at yartv.ru Thu Jul 9 11:45:15 2009 From: greenx at yartv.ru (Andrey Groshev) Date: Thu Jul 9 11:45:22 2009 Subject: panic while configuring vlan on msk Message-ID: <4A55D83E.4020206@yartv.ru> Hi, again :) it was necessary to work with vlan-s, but did not succeed ... #ifconfig vlan7 create #ifconfig vlan7 vlan 7 vlandev msk0 panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/dev/e1000/if_em.c:1623 cpuid = 1 KBD: enter: panic [thread pid 43561 tid 100322 ] Stopped at kdb_enter+0x3a: movl $0,kbd_why db> bt Tracing pid 43561 tid 100322 td 0xc9967d80 kdb_enter(c0cb1978,c0cb1978,c0cb03e4,eab05a70,1,...) at kdb_enter+0x03 panic(c0cb03e4,0,c0c79470,657,c9967e24,...) at panic+0x136 _mtx_lock_flags(c60db4e4,0,c0c79470,657,c60d7000,...) at _mtx_lock_flags+0x9a em_init(c60d7000) at em_init+0x35 em_register_vlan(0,c60cd400,7,430,c696fb84,...) at em_register_vlan+0x44 vlan_config(eab05b16,eab05b16,12,eab05b24,c6978220,...) at vlan_config+0x316 vlan_ioctl(c6135400,80206939,c6978220,c9967d80,eab05bac,...) at vlan_ioctl+0x2d5 ifioctl(c9520338,80306939,c6978220,c9967d80,ca243500,...) at ifioctl+0x11a8 soo_ioctl(c6d02e38,80206939,c6978220,c65a0b80,c9967d80,...) at soo_ioctl+0x415 kern_ioctl(c9967d80,3,80206939,c6978220,8f52d0,...) at kern_ioctl+0x1fd ioctl(c9967d80,eab05cf8,c,c0cc863f,c0d996dc8,...) at ioctl+0x134 syscall(eab05d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x33dbda23, esp = 0xbfbfe1ec, ebp = 0xbfbfe208 --- $uname -a FreeBSD greenx.yartelenet.ru 8.0-BETA1 FreeBSD 8.0-BETA1 #0: Thu Jul 9 10:55:08 MSD 2009 greenx@greenx.yartelenet.ru:/usr/obj/usr/src/sys/greenx i386 $pciconf -vl|grep -A4 msk mskc0@pci0:2:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' class = network subclass = ethernet From serenity at exscape.org Thu Jul 9 12:36:28 2009 From: serenity at exscape.org (Thomas Backman) Date: Thu Jul 9 12:36:41 2009 Subject: "New" ZFS crash on FS (pool?) unmount/export In-Reply-To: <766FFF07-181A-4180-B020-AA3EE46CF6F8@exscape.org> References: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> <766FFF07-181A-4180-B020-AA3EE46CF6F8@exscape.org> Message-ID: <9FAC783B-5709-460B-B6DA-364DCD0DE8DA@exscape.org> On Jul 9, 2009, at 11:01, Thomas Backman wrote: > On Jun 20, 2009, at 09:11, Thomas Backman wrote: > >> I just ran into this tonight. Not sure exactly what triggered it - >> the box stopped responding to pings at 02:07AM and it has a cron >> backup job using zfs send/recv at 02:00, so I'm guessing it's >> related, even though the backup probably should have finished >> before then... Hmm. Anyway. >> >> r194478. >> >> kernel trap 12 with interrupts disabled >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x288 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff805a4989 >> stack pointer = 0x28:0xffffff803e8b57e0 >> frame pointer = 0x28:0xffffff803e8b5840 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 57514 (zpool) >> panic: from debugger >> cpuid = 0 >> Uptime: 10h22m13s >> Physical memory: 2027 MB >> >> (kgdb) bt >> #0 doadump () at pcpu.h:223 >> #1 0xffffffff8059c409 in boot (howto=260) at /usr/src/sys/kern/ >> kern_shutdown.c:419 >> #2 0xffffffff8059c85c in panic (fmt=Variable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:575 >> #3 0xffffffff801f1377 in db_panic (addr=Variable "addr" is not >> available. >> ) at /usr/src/sys/ddb/db_command.c:478 >> #4 0xffffffff801f1781 in db_command (last_cmdp=0xffffffff80c38620, >> cmd_table=Variable "cmd_table" is not available. >> ) at /usr/src/sys/ddb/db_command.c:445 >> #5 0xffffffff801f19d0 in db_command_loop () at /usr/src/sys/ddb/ >> db_command.c:498 >> #6 0xffffffff801f3969 in db_trap (type=Variable "type" is not >> available. >> ) at /usr/src/sys/ddb/db_main.c:229 >> #7 0xffffffff805ce465 in kdb_trap (type=12, code=0, >> tf=0xffffff803e8b5730) at /usr/src/sys/kern/subr_kdb.c:534 >> #8 0xffffffff8088715d in trap_fatal (frame=0xffffff803e8b5730, >> eva=Variable "eva" is not available. >> ) at /usr/src/sys/amd64/amd64/trap.c:847 >> #9 0xffffffff80887fb2 in trap (frame=0xffffff803e8b5730) at /usr/ >> src/sys/amd64/amd64/trap.c:345 >> #10 0xffffffff8086e007 in calltrap () at /usr/src/sys/amd64/amd64/ >> exception.S:223 >> #11 0xffffffff805a4989 in _sx_xlock_hard (sx=0xffffff0043557d50, >> tid=18446742975830720512, opts=Variable "opts" is not available. >> ) >> at /usr/src/sys/kern/kern_sx.c:575 >> #12 0xffffffff805a52fe in _sx_xlock (sx=Variable "sx" is not >> available. >> ) at sx.h:155 >> #13 0xffffffff80fe2995 in zfs_freebsd_reclaim () from /boot/kernel/ >> zfs.ko >> #14 0xffffffff808cefca in VOP_RECLAIM_APV (vop=0xffffff0043557d38, >> a=0xffffff0043557d50) at vnode_if.c:1926 >> #15 0xffffffff80626f6e in vgonel (vp=0xffffff00437a7938) at >> vnode_if.h:830 >> #16 0xffffffff8062b528 in vflush (mp=0xffffff0060f2a000, >> rootrefs=0, flags=0, td=0xffffff0061528000) >> at /usr/src/sys/kern/vfs_subr.c:2450 >> #17 0xffffffff80fdd3a8 in zfs_umount () from /boot/kernel/zfs.ko >> #18 0xffffffff8062420a in dounmount (mp=0xffffff0060f2a000, >> flags=1626513408, td=Variable "td" is not available. >> ) >> at /usr/src/sys/kern/vfs_mount.c:1287 >> #19 0xffffffff80624975 in unmount (td=0xffffff0061528000, >> uap=0xffffff803e8b5c00) >> at /usr/src/sys/kern/vfs_mount.c:1172 >> #20 0xffffffff8088783f in syscall (frame=0xffffff803e8b5c90) at / >> usr/src/sys/amd64/amd64/trap.c:984 >> #21 0xffffffff8086e290 in Xfast_syscall () at /usr/src/sys/amd64/ >> amd64/exception.S:364 >> #22 0x000000080104e49c in ?? () >> Previous frame inner to this frame (corrupt stack?) > > > Here's the script in its relevant entirety [...] > > #!/bin/bash > > PATH="$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/ > sbin" > > function die() { > echo "$@" 2>&1 > zpool export slave 2>&1 > /dev/null > ggatel destroy -u 666 2>&1 > /dev/null > exit 1 > } > > function mount_unmount { > if [ -z "$1" ]; then > die 'Invalid argument given to mount_unmount' > elif [[ "$1" == "mount" ]]; then > zpool list | grep -q slave > if [ "$?" = "0" ]; then > echo Already mounted > return 0 > fi > echo Creating ggate device > ggatel create -u 666 /mnt/backup/chaos/slavefile || die 'Unable to > create GEOM provider from file' > echo 'Sleeping for 5 seconds...' > sleep 5 > echo Importing pool > zpool import -R /slave slave || die 'Unable to import slave pool' > elif [[ "$1" == "unmount" ]]; then > echo Exporting pool > zpool export slave || die 'Unable to export slave pool' > ggatel destroy -u 666 || die 'Unable to destroy GEOM provider' > fi > } > > f [ ! -z "$1" ]; then > case $1 in > mount) mount_unmount mount; exit 0;; > unmount) mount_unmount unmount; exit 0;; > initial) initial; exit 0;; > backup) ;; > *) help;; > esac > else > help > fi > > if [ ! -f "/mnt/backup/chaos/slavefile" ]; then > echo 'Backup error! slavefile does not exist!' | mail -s "Backup > error" root > echo 'Slavefile does not exist!' > exit 1 > fi > > mount_unmount mount > > CURR=$(date +"backup-%F-%H%M") > > echo Taking snapshots > zfs snapshot -r tank@$CURR || die 'Unable to create $CURR snapshot' > > echo Starting backup... > LAST=$(cat /root/.last-backup) > zfs send -R -I $LAST tank@$CURR | zfs recv -Fvd slave > > echo $CURR > /root/.last-backup > > mount_unmount unmount > > echo Running rsync > rsync -av --delete /bootdir/boot exscape::backup-freebsd/chaos > rsync -av --delete /root exscape::backup-freebsd/chaos > rsync -av --delete ~serenity exscape::backup-freebsd/chaos > > echo 'All done!' > > ------------------- Sorry for the monologue, but I ran in to this again, this time with a panic again. Similar but not identical to the old one. OK, so I figured I would update my "untouched" src clone (used to save bandwidth from the FBSD SVN server when I feel I need to start with a *clean* source tree), now that there have been quite a few changes since that revision. I pretty much did this (if other shells are different, !$ in bash is the last argument to the previous command.) 1) Clean up /usr/src from "my" stuff 2) svn update 3) svn diff and svn status, to make sure it was clean 4) zfs promote tank/usr/src ## usr/src was a clone of the untouched, read-only fs "tank/usr/src_r194478-UNTOUCHED" 5) zfs destroy -r tank/usr/src_r194478-UNTOUCHED ## The old one, obviously 6) zfs snapshot tank/usr/src@r195488_UNTOUCHED 7) zfs clone !$ tank/usr/src_r195488-UNTOUCHED 8) zfs promote !$ 9) zfs set readonly=on !$ 10) And, in case it may matter, I slightly modified the contents of / usr/src afterwards (applied two patches that aren't merged into HEAD (yet?)). ... I THINK that's it. Since my bash_history got killed in the panic, I may be slighty wrong. In any case, usr/src is now a clone of the readonly UNTOUCHED fs: [root@chaos ~]# zfs get origin tank/usr/src NAME PROPERTY VALUE SOURCE tank/usr/src origin tank/usr/ src_r195488_UNTOUCHED@r195488_UNTOUCHED - I then ran the backup script just posted in this thread: [root@chaos ~]# bash backup.sh backup Creating ggate device Sleeping for 5 seconds... Importing pool Taking snapshots Starting backup... attempting destroy slave/usr/src_r194478-UNTOUCHED@backup-20090709-1250 success attempting destroy slave/usr/src_r194478-UNTOUCHED@r194478-UNTOUCHED failed - trying rename to slave/usr/src_r194478-UNTOUCHED@recv-38883-1 failed (2) - will try again on next pass attempting destroy slave/usr/src_r194478-UNTOUCHED@backup-20090709-1235 success attempting destroy slave/usr/src_r194478-UNTOUCHED failed - trying rename to slave/recv-38883-2 failed (2) - will try again on next pass promoting slave/usr/src another pass: attempting destroy slave/usr/src_r194478-UNTOUCHED success attempting destroy slave/usr/src@r194478-UNTOUCHED success attempting rename slave/usr/src to slave/usr/src_r195488_UNTOUCHED success receiving incremental stream of tank@backup-20090709-1328 into slave@backup-20090709-1328 received 312B stream in 1 seconds (312B/sec) receiving incremental stream of tank/tmp@backup-20090709-1328 into slave/tmp@backup-20090709-1328 received 119KB stream in 1 seconds (119KB/sec) receiving incremental stream of tank/var@backup-20090709-1328 into slave/var@backup-20090709-1328 received 211KB stream in 1 seconds (211KB/sec) receiving incremental stream of tank/var/log@backup-20090709-1328 into slave/var/log@backup-20090709-1328 received 468KB stream in 1 seconds (468KB/sec) receiving incremental stream of tank/var/crash@backup-20090709-1328 into slave/var/crash@backup-20090709-1328 received 312B stream in 1 seconds (312B/sec) receiving incremental stream of tank/root@backup-20090709-1328 into slave/root@backup-20090709-1328 received 156KB stream in 1 seconds (156KB/sec) receiving incremental stream of tank/usr@backup-20090709-1328 into slave/usr@backup-20090709-1328 received 302KB stream in 1 seconds (302KB/sec) receiving incremental stream of tank/usr/obj@backup-20090709-1328 into slave/usr/obj@backup-20090709-1328 received 8.52MB stream in 8 seconds (1.07MB/sec) receiving incremental stream of tank/usr/ src_r195488_UNTOUCHED@r195488_UNTOUCHED into slave/usr/ src_r195488_UNTOUCHED@r195488_UNTOUCHED received 112MB stream in 43 seconds (2.60MB/sec) receiving incremental stream of tank/usr/ src_r195488_UNTOUCHED@backup-20090709-1328 into slave/usr/ src_r195488_UNTOUCHED@backup-20090709-1328 received 312B stream in 1 seconds (312B/sec) receiving incremental stream of tank/usr/ports@backup-20090709-1328 into slave/usr/ports@backup-20090709-1328 received 312B stream in 1 seconds (312B/sec) receiving incremental stream of tank/usr/ports/ distfiles@backup-20090709-1328 into slave/usr/ports/ distfiles@backup-20090709-1328 received 312B stream in 1 seconds (312B/sec) found clone origin slave/usr/src_r195488_UNTOUCHED@r195488_UNTOUCHED receiving incremental stream of tank/usr/src@backup-20090709-1328 into slave/usr/src@backup-20090709-1328 received 216KB stream in 1 seconds (216KB/sec) local fs slave/usr/src does not have fromsnap (backup-20090709-1250 in stream); must have been deleted locally; ignoring Exporting pool Read from remote host 192.168.1.10: Operation timed out ... and the DDB output (first part copy/paste from kgdb, second part handwritten since the kgdb BT was totally broken, as I expected.) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x70 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8036e855 stack pointer = 0x28:0xffffff803ea637d0 frame pointer = 0x28:0xffffff803ea637e0 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 = 38905 (zpool) _sx_slock() dmu_buf_update_user()+0x47 zfs_znode_dmu_fini() zfs_freebsd_reclaim() VOP_RECLAIM_APV() vgonel() vflush() zfs_umount() dounmount() unmount() syscall() Xfast_syscall() BTW, what's with the "local fs slave/usr/src does not have fromsnap (backup-20090709-1250 in stream); must have been deleted locally; ignoring" part? This is what I get when I try an incremental backup now: [root@chaos ~]# bash backup.sh backup Creating ggate device Sleeping for 5 seconds... Importing pool Taking snapshots Starting backup... local fs slave/usr/src does not have fromsnap (backup-20090709-1250 in stream); must have been deleted locally; ignoring receiving incremental stream of tank@backup-20090709-1328 into slave@backup-20090709-1328 snap slave@backup-20090709-1328 already exists; ignoring local fs slave/usr/src does not have fromsnap (backup-20090709-1250 in stream); must have been deleted locally; ignoring warning: cannot send 'tank/tmp@backup-20090709-1328': Broken pipe warning: cannot send 'tank/tmp@backup-20090709-1406': Broken pipe Exporting pool Running rsync ... rsync runs, no panic, but no ZFS backup, either. Guess it's time for another "initial" backup, i.e. start all over with 0 snapshots... The initial backup worked just fine, it found the clone/origin etc. and made it work. Stripped from comments and echo statements, the function is simply: function initial { for BACK in $(zfs list -t snapshot -H -r tank | awk '{print $1}'); do zfs destroy $BACK; done zpool destroy slave 2>/dev/null; sleep 3; ggatel destroy -u 666 2>/dev/null; sleep 3 # Clean up if needed ggatel create -u 666 /mnt/backup/chaos/slavefile; sleep 3 zpool create -f -R /slave slave ggate666 && NOW=$(date +"backup-%Y %m%d-%H%M") || die 'Unable to create pool' zfs snapshot -r tank@$NOW || die 'Unable to snapshot' zfs send -R tank@$NOW | zfs recv -vFd slave mount_unmount unmount echo $NOW > /root/.last-backup } After that, incrementals are fine again. Regards, Thomas From gelraen.ua at gmail.com Thu Jul 9 13:24:46 2009 From: gelraen.ua at gmail.com (Maxim Ignatenko) Date: Thu Jul 9 13:24:54 2009 Subject: panic while configuring vlan on msk In-Reply-To: References: <4A55D83E.4020206@yartv.ru> Message-ID: 2009/7/9 Andrey Groshev : > Hi, again :) > > it was necessary to work with vlan-s, but did not succeed ... > > #ifconfig vlan7 create > #ifconfig vlan7 vlan 7 vlandev msk0 > > panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/dev/e1000/if_em.c:1623 > cpuid = 1 > KBD: enter: panic > [thread pid 43561 tid 100322 ] > Stopped at ? ?kdb_enter+0x3a: movl ? ?$0,kbd_why > db> bt > Tracing pid 43561 tid 100322 td 0xc9967d80 > kdb_enter(c0cb1978,c0cb1978,c0cb03e4,eab05a70,1,...) at kdb_enter+0x03 > panic(c0cb03e4,0,c0c79470,657,c9967e24,...) at panic+0x136 > _mtx_lock_flags(c60db4e4,0,c0c79470,657,c60d7000,...) at > _mtx_lock_flags+0x9a > em_init(c60d7000) at em_init+0x35 > em_register_vlan(0,c60cd400,7,430,c696fb84,...) at em_register_vlan+0x44 > vlan_config(eab05b16,eab05b16,12,eab05b24,c6978220,...) at vlan_config+0x316 > vlan_ioctl(c6135400,80206939,c6978220,c9967d80,eab05bac,...) at > vlan_ioctl+0x2d5 > ifioctl(c9520338,80306939,c6978220,c9967d80,ca243500,...) at ifioctl+0x11a8 > soo_ioctl(c6d02e38,80206939,c6978220,c65a0b80,c9967d80,...) at > soo_ioctl+0x415 > kern_ioctl(c9967d80,3,80206939,c6978220,8f52d0,...) at kern_ioctl+0x1fd > ioctl(c9967d80,eab05cf8,c,c0cc863f,c0d996dc8,...) at ioctl+0x134 > syscall(eab05d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x33dbda23, esp = 0xbfbfe1ec, > ebp = 0xbfbfe208 --- It seems you stepped on the problem described in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/132715 em_register_vlan was rewritten r194865, but patch in followup to PR quite trivial and can be applied manually. From avg at icyb.net.ua Thu Jul 9 14:20:05 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Jul 9 14:20:16 2009 Subject: [Fwd: AMD SB700/SB710/SB750 docs have been released!] Message-ID: <4A55FC92.5040205@icyb.net.ua> Might be useful for people hacking on AMD platform drivers and related. -------- Original Message -------- Subject: AMD SB700/SB710/SB750 docs have been released! Date: Thu, 09 Jul 2009 03:59:36 +0200 From: Carl-Daniel Hailfinger To: Coreboot AMD just released the following docs we need for SB700/SB710/SB750 coreboot support: * AMD SB700/710/750 Register Reference Guide * AMD SB700/710/750 BIOS Developer?s Guide * AMD SB700/710/750 Register Programming Requirements * AMD SB710 Databook Links to all data sheets are at http://www.coreboot.org/Datasheets#AMD_SB700.2FSB710.2FSB750 This is a great step towards supporting current RS780/SB700 family systems. Immediate benefits of this doc release are: - We can implement SB700/SB710/SB750 support without NDA. - We can study the embedded controller environment and the SuperI/O functionality in some SB7x0 southbridges. Future benefits are: - We can support 690/SB700 boards once the SB700 code is done. - We can test SB700 code in 690/SB700 boards and make sure it works perfectly before we start working on RS780 code. - We have 50% of the docs we need for almost all boards with AMD chipset on sale today. What can we do next? - Implement SB700 code. - RS690/SB700 boards do not exist. However, it seems that RS740 is RS690 with a modified graphics core, so RS740/SB700 boards are the best targets we can pick. List of possible targets with RS740/SB700: - ECS Elitegroup A740GM-M (89-206-V15102) http://www.ecs.com.tw/ECSWebSite/Products/ProductsDetail.aspx?detailid=864&CategoryID=1&DetailName=Specification&MenuID=1&LanID=0 - Gigabyte GA-MA74GM-S2 (rev 1.x and 2.0) http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=3063 http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2813 - Gigabyte GA-MA74GM-S2 (rev 1.x and 2.0) http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2775 http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=3062 - ASUS M2A74-AM http://www.asus.com/product.aspx?P_ID=YPZrr3KRcW3MBX5G - MSI K9A2GM-F V3 (MS-7302-020, there seem to be many variants of this board, some of them may have a 740 variant which is not compatible with 690) http://us.msi.com/product/p_spec.asp?model=K9A2GM-F_V3&class=mb Thanks to AMD for releasing these docs! Regards, Carl-Daniel -- Andriy Gapon From kostikbel at gmail.com Thu Jul 9 14:21:28 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Jul 9 14:21:36 2009 Subject: Process stuck in vmmaps on 8.0-BETA1 In-Reply-To: <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> Message-ID: <20090709142121.GS55190@deviant.kiev.zoral.com.ua> On Thu, Jul 09, 2009 at 06:52:42PM +1000, John Marshall wrote: > On Thu, 09 Jul 2009, 17:30 +1000, John Marshall wrote: > > On Thu, 09 Jul 2009, 10:42 +0400, pluknet wrote: > > > 2009/7/9 John Marshall : > > > > After upgrading... > > > > - boot new kernel to single-user > > > > - make installworld > > > > - make delete-old > > > > - make delete-old-libs > > > > - mergemaster > > > > - reboot > > > > > > > > I re-built a few of my applications. I noticed a problem with ntpd > > > > 4.2.4p7. The build was fine, it started fine, but got stuck in vmmaps > > > > and I couldn't kill it. Stopping the operating system appears to be the > > > > only remedy. I have re-built a few times (starting with 'make > > > > distclean') just to make sure. > > > > > > > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > > > > 0 791 1 0 44 0 4944 4920 vmmaps Ds ?? 0:00.01 ntpd > > > > > > > > > > Can you place here 'procstat -k 791', where 791 is pid of ntpd? > > > It'd be nice also if you go through all ddb steps described in > > > Debugging Deadlocks chapter of FreeBSD Developers' Handbook. > > > > Here is some procstat output. I'm just rebuilding the kernel with the > > debugging options enabled - not something I've ever done before. > > > > rwsrv05# procstat 2788 > > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM > > 2788 1 2788 2788 0 1 john vmmaps FreeBSD ELF32 ntpd > > rwsrv05# procstat -k 2788 > > PID TID COMM TDNAME KSTACK > > 2788 100164 ntpd - mi_switch sleepq_switch sleepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mmap syscall Xint0x80_syscall > > rwsrv05# procstat -v 2788 > > PID START END PRT RES PRES REF SHD FL TP PATH > > 2788 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd > > 2788 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd > > 2788 0x8080000 0x8100000 rw- 128 0 1 0 C- df > > 2788 0x2807e000 0x280ab000 r-x 45 0 171 75 CN vn /libexec/ld-elf.so.1 > > 2788 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 > > 2788 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df > > 2788 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 > > 2788 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 > > 2788 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 > > 2788 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 > > 2788 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 > > 2788 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 > > 2788 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df > > 2788 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 > > 2788 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 > > 2788 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 > > 2788 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 > > 2788 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 > > 2788 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 > > 2788 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 > > 2788 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 > > 2788 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 > > 2788 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 > > 2788 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 > > 2788 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 > > 2788 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 > > 2788 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 > > 2788 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 > > 2788 0x28358000 0x2836e000 rw- 22 0 1 0 C- df > > 2788 0x2836e000 0x2837a000 --- 0 0 0 0 -- -- > > 2788 0x28400000 0x28500000 rw- 256 0 1 0 C- df > > 2788 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df > > rwsrv05# > > OK, now that I've rebuilt the kernel with the debugging options not > commented out, I'm getting a number of 'lock order reversal' messages > printed on the console: is that normal? > > From the Debugging Deadlocks chapter to which I was referred by pluknet > (above) it appears that I need to enter 'sysctl debug.kdb.enter=1' or > 'sysctl debug.kdb.panic=1' after I get the process into the desired > 'stuck' state. If I enter either of those commands, the system reboots. > Now *I'm* stuck. Since you have mostly working system, and interesting information most easy accessible by kgdb, attach it to the live kernel: kgdb /dev/mem From there, switch to the stuck process, process do bt find the frame for vm_map_delete, and print the entry: p entry Also, I need to see the information you posted earlier, namely, procstat -k and -v output for the process. -------------- 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/20090709/a7c23758/attachment.pgp From deischen at freebsd.org Thu Jul 9 14:47:48 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Thu Jul 9 14:47:55 2009 Subject: [Fwd: AMD SB700/SB710/SB750 docs have been released!] In-Reply-To: <4A55FC92.5040205@icyb.net.ua> References: <4A55FC92.5040205@icyb.net.ua> Message-ID: On Thu, 9 Jul 2009, Andriy Gapon wrote: > > Might be useful for people hacking on AMD platform drivers and related. > > -------- Original Message -------- > Subject: AMD SB700/SB710/SB750 docs have been released! > Date: Thu, 09 Jul 2009 03:59:36 +0200 > From: Carl-Daniel Hailfinger > To: Coreboot > > AMD just released the following docs we need for SB700/SB710/SB750 > coreboot support: > > * AMD SB700/710/750 Register Reference Guide > * AMD SB700/710/750 BIOS Developer?s Guide > * AMD SB700/710/750 Register Programming Requirements > * AMD SB710 Databook > > Links to all data sheets are at > http://www.coreboot.org/Datasheets#AMD_SB700.2FSB710.2FSB750 > > This is a great step towards supporting current RS780/SB700 family systems. > > Immediate benefits of this doc release are: > - We can implement SB700/SB710/SB750 support without NDA. > - We can study the embedded controller environment and the SuperI/O [ snip ] I am running -current on an ASUS M4A78T-E which has the SB750 chipset. Seems to work fine, -j8 buildworld is 21 minutes, buildkernel with modules is about 7 minutes. I'm not using any of the RAID functionality. The dmesg is here: http://people.freebsd.org/~deischen/asus_m4a78t-e.dmesg -- DE From kostikbel at gmail.com Thu Jul 9 16:09:02 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Jul 9 16:09:09 2009 Subject: Process stuck in vmmaps on 8.0-BETA1 In-Reply-To: <20090709142121.GS55190@deviant.kiev.zoral.com.ua> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> Message-ID: <20090709160855.GU55190@deviant.kiev.zoral.com.ua> On Thu, Jul 09, 2009 at 05:21:21PM +0300, Kostik Belousov wrote: > From there, switch to the stuck process, > process > do > bt > find the frame for vm_map_delete, and print the entry: > p entry ^^^^^^^^^^This shall be p *entry > > Also, I need to see the information you posted earlier, namely, procstat > -k and -v output for the process. -------------- 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/20090709/4d00778f/attachment.pgp From jkim at FreeBSD.org Thu Jul 9 16:19:52 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Thu Jul 9 16:19:59 2009 Subject: [Fwd: AMD SB700/SB710/SB750 docs have been released!] In-Reply-To: References: <4A55FC92.5040205@icyb.net.ua> Message-ID: <200907091219.41323.jkim@FreeBSD.org> On Thursday 09 July 2009 10:47 am, Daniel Eischen wrote: > On Thu, 9 Jul 2009, Andriy Gapon wrote: > > Might be useful for people hacking on AMD platform drivers and > > related. > > > > -------- Original Message -------- > > Subject: AMD SB700/SB710/SB750 docs have been released! > > Date: Thu, 09 Jul 2009 03:59:36 +0200 > > From: Carl-Daniel Hailfinger > > To: Coreboot > > > > AMD just released the following docs we need for > > SB700/SB710/SB750 coreboot support: > > > > * AMD SB700/710/750 Register Reference Guide > > * AMD SB700/710/750 BIOS Developer?s Guide > > * AMD SB700/710/750 Register Programming Requirements > > * AMD SB710 Databook > > > > Links to all data sheets are at > > http://www.coreboot.org/Datasheets#AMD_SB700.2FSB710.2FSB750 > > > > This is a great step towards supporting current RS780/SB700 > > family systems. > > > > Immediate benefits of this doc release are: > > - We can implement SB700/SB710/SB750 support without NDA. > > - We can study the embedded controller environment and the > > SuperI/O > > [ snip ] > > I am running -current on an ASUS M4A78T-E which has the SB750 > chipset. Seems to work fine, -j8 buildworld is 21 minutes, > buildkernel with modules is about 7 minutes. I'm not using any of > the RAID functionality. > > The dmesg is here: > > http://people.freebsd.org/~deischen/asus_m4a78t-e.dmesg I implemented SB700 combined mode support for ata(4) on -CURRENT: http://svn.freebsd.org/changeset/base/191568 I did it without the docs and I had many unanswered questions. Now I am very happy to see they are finally released without NDA. :-) Jung-uk Kim From randi at freebsd.org Thu Jul 9 16:34:15 2009 From: randi at freebsd.org (Randi Harper) Date: Thu Jul 9 16:34:22 2009 Subject: USB stick installation problems In-Reply-To: <4A559E50.3090408@bsdunix.ch> References: <4A559E50.3090408@bsdunix.ch> Message-ID: On Thu, Jul 9, 2009 at 12:37 AM, Thomas Vogt wrote: > Hi > > I download and copied 8.0-BETA1-amd64-memstick.img to an usb stick as > described at > http://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051018.html. > > I can boot it and sysinstall runs fine. Later i chose USB stick as > install medium but then i get a "no USB stick found" error. Is this an > know bug? > > Regards, > Thomas Possibly. Can you please tell sysinstall to rescan devices or restart the sysinstall process and tell me if that makes a difference? -- randi From xcllnt at mac.com Thu Jul 9 16:39:50 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Jul 9 16:39:58 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090709085014.GE43264@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> <20090709085014.GE43264@mech-cluster238.men.bris.ac.uk> Message-ID: <8B6FE903-10E5-4A32-8E2E-482595D8F495@mac.com> On Jul 9, 2009, at 1:50 AM, Anton Shterenlikht wrote: >> By all means: experiment. But be very careful not to make >> the assumption that if the code compiles, it'll also run. >> The weirder the set of compiler options, the more likely >> you trip over optimization bugs and end up with an unstable >> system. And I'm not even talking about whether the set >> of options give you more optimal code in general. > > I see.. > > Is there any advice for compiler options on ia64? My advise at this time is to not change from the default. I haven't done any kind of experimentation or know of any- one else who did, to make any kind of claim as to the effectiveness or harm of various compiler options. I'm not talking cleanroom experiments here. I'm sure that there have been plenty of people looking at SPECcpu and who came up with a very creative set of compiler options that make SPECcpu perform "optimally" (for each program). This normally also includes fixing the compiler (and even adding special case code) to have correct code generated in that case. I'm talking about a safe set of options that people can use and that yields correct code 99.9% of the time and gives acceptable (if not good) code. I cannot stress the importance of having the toolchain generate correct code when working on a FreeBSD port to a different architecture. > I'm sorry if I'm asking obvious questions. > Perhaps this is documented/disucced somewhere > already? I'm new to ia64, most of my FBSD > experience is from alpha and i386. These aren't obvious questions. Compiler options, if they are being discussed, are primarily discussed for i386 or amd64. -- Marcel Moolenaar xcllnt@mac.com From sfourman at gmail.com Thu Jul 9 17:15:35 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Thu Jul 9 17:15:43 2009 Subject: FreeBSD 8 BETA1 DHCP trouble Message-ID: <11167f520907091015l35827121r30b848922425d840@mail.gmail.com> Hello list, I have had issues obtaining DHCP address on Asus dual nic motherboards with kernels built after ~ 6-6-2009 (eg nfe0 will not dhcp just times out but nfe1 will work) I played with my hardware for a bit before I noticed it was a FreeBSD bug. sure enough revert back to a 6-1-2009 kernel and nfe0 and 1 dhcp again. Sam Fourman Jr. sfourman@ ~/.wine/drive_c/Program Files/World of Warcraft]$ 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-BETA1 #0: Tue Jul 7 21:47:44 CDT 2009 sfourman@:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz (2666.64-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x408e3bd AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3135557632 (2990 MB) ACPI APIC Table: <022609 APIC1009> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <022609 XSDT1009> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 1.4 (no driver attached) pci0: at device 1.5 (no driver attached) pci0: at device 1.6 (no driver attached) pci0: at device 1.7 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xdc00-0xdc7f mem 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcib2: irq 17 at device 4.0 on pci0 pci2: on pcib2 pci0: at device 9.0 (no driver attached) isab0: port 0x2f00-0x2f7f at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) ohci0: mem 0xf7ffb000-0xf7ffbfff irq 22 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xf7ffac00-0xf7ffacff irq 23 at device 11.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 13.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xc400-0xc407,0xc080-0xc083,0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb88f mem 0xf7ff9000-0xf7ff9fff irq 21 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0xb800-0xb807,0xb480-0xb483,0xb400-0xb407,0xb080-0xb083,0xb000-0xb00f mem 0xf7ff8000-0xf7ff8fff irq 22 at device 14.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f mem 0xf7ff7000-0xf7ff7fff irq 23 at device 14.2 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] pcib3: at device 15.0 on pci0 pci3: on pcib3 fwohci0: port 0xec00-0xec7f mem 0xfbfff800-0xfbffffff irq 18 at device 7.0 on pci3 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:1e:8c:00:01:af:44:a4 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xbcbb0000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:1e:8c:af:44:a4 fwe0: Ethernet address: 02:1e:8c:af:44:a4 fwip0: on firewire0 fwip0: Firewire address: 00:1e:8c:00:01:af:44:a4 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode hdac0: mem 0xf7ff0000-0xf7ff3fff irq 21 at device 15.1 on pci0 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] nfe0: port 0xa080-0xa087 mem 0xf7ff6000-0xf7ff6fff,0xf7ffa800-0xf7ffa8ff,0xf7ffa400-0xf7ffa40f irq 20 at device 17.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:23:54:96:dd:8d nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe1: port 0xa000-0xa007 mem 0xf7ff5000-0xf7ff5fff,0xf7ffa000-0xf7ffa0ff,0xf7ff4c00-0xf7ff4c0f irq 20 at device 18.0 on pci0 miibus1: on nfe1 e1000phy1: PHY 2 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe1: Ethernet address: 00:23:54:96:de:2f nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] pcib4: at device 19.0 on pci0 pci4: on pcib4 pcib5: at device 22.0 on pci0 pci5: on pcib5 pcib6: at device 23.0 on pci0 pci6: on pcib6 pcib7: at device 24.0 on pci0 pci7: on pcib7 acpi_button0: on acpi0 ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found Package, expected Buffer 20090521 nspredef-1051 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] atrtc1: port 0x70-0x71 on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - CA, should be C2 20090521 tbutils-275 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 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 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. ppc0: parallel port not found. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ad4: 152627MB at ata2-master SATA300 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ad6: 152627MB at ata3-master SATA300 GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). ad10: 238475MB at ata5-master SATA300 acd0: DVDR at ata6-master SATA150 acd1: DVDR at ata7-master SATA150 hdac0: HDA Codec #0: Analog Devices AD1988B pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 GEOM: ad6s1: geometry does not match label (255h,63s != 16h,63s). uhub0: 10 ports with 10 removable, self powered SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus1 uhub1: 10 ports with 10 removable, self powered Root mount waiting for: usbus1 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 Trying to mount root from ufs:/dev/ad6s1a uhub2: 4 ports with 2 removable, bus powered ugen0.3: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 uhid0: on usbus0 ugen0.4: at usbus0 ums0: on usbus0 ums0: 8 buttons and [XYZ] coordinates ID=0 ugen0.5: at usbus0 hid_get_item:304: Number of items truncated to 255 hid_get_item:304: Number of items truncated to 255 uhid1: on usbus0 hid_get_item:304: Number of items truncated to 255 hid_get_item:304: Number of items truncated to 255 hid_get_item:304: Number of items truncated to 255 lock order reversal: 1st 0xc7826270 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1054 2nd 0xc7827df4 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,e9884818,c08b5f35,c08a6cdb,c0c5eef9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5eef9,c6d30910,c6d30840,e9884874,...) at kdb_backtrace+0x29 _witness_debugger(c0c5eef9,c7827df4,c0c4dec5,c6d30840,c0c6617e,...) at _witness_debugger+0x25 witness_checkorder(c7827df4,9,c0c6617e,823,0,...) at witness_checkorder+0x839 __lockmgr_args(c7827df4,80100,c7827e10,0,0,...) at __lockmgr_args+0x7a7 vop_stdlock(e988497c,c08b5cdb,c0c4e0f6,80100,c7827d9c,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0d39660,e988497c,c7677764,c0d76700,c7827d9c,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c7827d9c,80100,c0c6617e,823,8,...) at _vn_lock+0x5e vget(c7827d9c,80100,c76776c0,15e,c0c4e018,...) at vget+0xb9 devfs_allocv(c7431480,c7619000,e9884a14,9d,c0f17a58,...) at devfs_allocv+0x102 devfs_root(c7619000,80000,e9884c30,42c,0,...) at devfs_root+0x4a vfs_donmount(c76776c0,0,c7437300,c7437300,bfbfde39,...) at vfs_donmount+0x14bb nmount(c76776c0,e9884cf8,c,c76776c0,c0d3f3b8,...) at nmount+0x75 syscall(e9884d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x33ce7d3b, esp = 0xbfbfde0c, ebp = 0xbfbfe368 --- nfe1: link state changed to DOWN nfe1: link state changed to UP lock order reversal: 1st 0xdad11570 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xc747c200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,e991c860,c08b5f35,c08a6cdb,c0c5eef9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5eef9,c6d2cf60,c6d30978,e991c8bc,...) at kdb_backtrace+0x29 _witness_debugger(c0c5eef9,c747c200,c0c7f0d0,c6d30978,c0c7ed69,...) at _witness_debugger+0x25 witness_checkorder(c747c200,9,c0c7ed69,11d,0,...) at witness_checkorder+0x839 _sx_xlock(c747c200,0,c0c7ed69,11d,c7823414,...) at _sx_xlock+0x85 ufsdirhash_acquire(dad11510,e991c9d4,3c,db78b5e4,e991c98c,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c7823414,e991c9d4,5e4,e991c978,e991c97c,...) at ufsdirhash_add+0x13 ufs_direnter(c78c2754,c7cf2c90,e991c9d4,e991cbdc,0,...) at ufs_direnter+0x729 ufs_makeinode(e991cbdc,e991cb48,e991cc00,e991cb1c,c0ba7255,...) at ufs_makeinode+0x4f8 ufs_create(e991cc00,e991cc14,e991cb48,e991cb48,0,...) at ufs_create+0x30 VOP_CREATE_APV(c0d5dc60,e991cc00,e991cbdc,e991cb48,c7a857fc,...) at VOP_CREATE_APV+0xa5 uipc_bind(c7a7c9a8,c7682180,c78ad6c0,e991cc60,c08e1e02,...) at uipc_bind+0x32e sobind(c7a7c9a8,c7682180,c78ad6c0,c7682180,c7532188,...) at sobind+0x23 kern_bind(c78ad6c0,3,c7682180,c7682180,8094884,...) at kern_bind+0xc2 bind(c78ad6c0,e991ccf8,c,c0c5f78a,c0d3d5c0,...) at bind+0x46 syscall(e991cd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (104, FreeBSD ELF32, bind), eip = 0x33d9bdff, esp = 0xbfbfe85c, ebp = 0xbfbfe958 --- lock order reversal: 1st 0xc838b164 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3496 2nd 0xdadbd5c0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6170 3rd 0xc838b058 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,eb9ed8c0,c08b5f35,c08a6cdb,c0c5ef12,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5ef12,c6d2cf60,c6d30910,eb9ed91c,...) at kdb_backtrace+0x29 _witness_debugger(c0c5ef12,c838b058,c0c51b6a,c6d30910,c0c6617e,...) at _witness_debugger+0x25 witness_checkorder(c838b058,9,c0c6617e,823,0,...) at witness_checkorder+0x839 __lockmgr_args(c838b058,80100,c838b074,0,0,...) at __lockmgr_args+0x7a7 ffs_lock(eb9eda2c,c08b5cdb,c0c65671,80100,c838b000,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d5dc60,eb9eda2c,c83ab0a4,c0d76700,c838b000,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c838b000,80100,c0c6617e,823,4,...) at _vn_lock+0x5e vget(c838b000,80100,c83ab000,50,0,...) at vget+0xb9 vfs_hash_get(c761ea10,11606,80000,c83ab000,eb9edb88,...) at vfs_hash_get+0xe6 ffs_vgetf(c761ea10,11606,80000,eb9edb88,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c838b10c,0,c0c7e9e2,146,0,...) at softdep_sync_metadata+0x5ba ffs_syncvnode(c838b10c,1,c83c7e58,dad,c838b1b4,...) at ffs_syncvnode+0x3e2 ffs_fsync(eb9edc5c,eb9edcf8,0,eb9edc5c,eb9edc80,...) at ffs_fsync+0x27 VOP_FSYNC_APV(c0d5dc60,eb9edc5c,c0c67206,dad,0,...) at VOP_FSYNC_APV+0xa5 fsync(c83ab000,eb9edcf8,4,c0c7d380,c0d3d4c4,...) at fsync+0x1df syscall(eb9edd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (95, FreeBSD ELF32, fsync), eip = 0x341ec127, esp = 0xbfbfe19c, ebp = 0xbfbfe1b8 --- lock order reversal: 1st 0xc7a6b52c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1088 2nd 0xc8439488 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4091 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,e99b1a2c,c08b5f35,c08a6cdb,c0c5eef9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5eef9,c6d2d238,c6d30910,e99b1a88,...) at kdb_backtrace+0x29 _witness_debugger(c0c5eef9,c8439488,c0c51b6a,c6d30910,c0c6617e,...) at _witness_debugger+0x25 witness_checkorder(c8439488,9,c0c6617e,ffb,c84394a4,...) at witness_checkorder+0x839 __lockmgr_args(c8439488,80400,c84394a4,0,0,...) at __lockmgr_args+0x7a7 ffs_lock(e99b1b98,4,0,80400,c8439430,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d5dc60,e99b1b98,c0c53d5d,c0d76700,c8439430,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c8439430,80400,c0c6617e,ffb,e99b1bf4,...) at _vn_lock+0x5e vfs_knllock(c8439430,0,c0c53d5d,696,c836b4c8,...) at vfs_knllock+0x29 knlist_remove_kq(0,e99b1c14,c0900ee9,c8438580,c836b4c8,...) at knlist_remove_kq+0x85 knlist_remove(c8438580,c836b4c8,0,e99b1c40,c0844625,...) at knlist_remove+0x1b filt_vfsdetach(c836b4c8,0,c0c53d5d,777,19,...) at filt_vfsdetach+0x39 knote_fdclose(c7995240,12b9,c0c538a5,440,c7a6b52c,...) at knote_fdclose+0xf5 kern_close(c7995240,12b9,e99b1d2c,c0b998e3,c7995240,...) at kern_close+0xd2 close(c7995240,e99b1cf8,4,c0c5f78a,c0d3cb08,...) at close+0x1a syscall(e99b1d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x33f7a9e3, esp = 0xbfbfe6bc, ebp = 0xbfbfe6d8 --- acquiring duplicate lock of same type: "ftlk" 1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:177 2nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:203 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,eba20b58,c08b5f35,c08a6cdb,c0c5edec,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5edec,c1104957,c6d30ec0,eba20bb4,...) at kdb_backtrace+0x29 _witness_debugger(c0c5edec,c1104993,c1104957,cb,0,...) at _witness_debugger+0x25 witness_checkorder(c7d2fc00,9,c1104957,cb,0,...) at witness_checkorder+0x469 _sx_xlock(c7d2fc00,0,c1104957,cb,0,...) at _sx_xlock+0x85 futex_get0(c0ee7cf0,c862b9a4,c0ee7cf0,c0d44960,c0c9133c,...) at futex_get0+0x116 linux_sys_futex(c862b900,eba20cf8,eba20d18,eba20d1c,c1107f40,...) at linux_sys_futex+0x6f syscall(eba20d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (240, Linux ELF, linux_sys_futex), eip = 0x34399533, esp = 0xbfbfbeec, ebp = 0x4000001 --- lock order reversal: 1st 0xc7a6b52c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1088 2nd 0xcc545ce8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_subr.c:4091 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,e99b1a34,c08b5f35,c08a6cdb,c0c5eef9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5eef9,c6d2d238,c6d30b80,e99b1a90,...) at kdb_backtrace+0x29 _witness_debugger(c0c5eef9,cc545ce8,c0c4e978,c6d30b80,c0c6617e,...) at _witness_debugger+0x25 witness_checkorder(cc545ce8,9,c0c6617e,ffb,cc545d04,...) at witness_checkorder+0x839 __lockmgr_args(cc545ce8,80400,cc545d04,0,0,...) at __lockmgr_args+0x7a7 vop_stdlock(e99b1b98,4,0,80400,cc545c90,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0d3a320,e99b1b98,c0c53d5d,c0d76700,cc545c90,...) at VOP_LOCK1_APV+0xb5 _vn_lock(cc545c90,80400,c0c6617e,ffb,e99b1bf4,...) at _vn_lock+0x5e vfs_knllock(cc545c90,0,c0c53d5d,696,c7e16154,...) at vfs_knllock+0x29 knlist_remove_kq(0,e99b1c14,c0900ee9,c9358580,c7e16154,...) at knlist_remove_kq+0x85 knlist_remove(c9358580,c7e16154,0,e99b1c40,c0844625,...) at knlist_remove+0x1b filt_vfsdetach(c7e16154,0,c0c53d5d,777,1,...) at filt_vfsdetach+0x39 knote_fdclose(c7995240,2061,c0c538a5,440,c7a6b52c,...) at knote_fdclose+0xf5 kern_close(c7995240,2061,e99b1d2c,c0b998e3,c7995240,...) at kern_close+0xd2 close(c7995240,e99b1cf8,4,c0c796fe,c0d3cb08,...) at close+0x1a syscall(e99b1d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x33f7a9e3, esp = 0xbfbfe67c, ebp = 0xbfbfe698 --- From avg at freebsd.org Thu Jul 9 17:31:16 2009 From: avg at freebsd.org (Andriy Gapon) Date: Thu Jul 9 17:31:23 2009 Subject: dtrace users opinion solicited (timestamps) Message-ID: <4A562960.3010801@freebsd.org> As you might be aware DTrace timestamps right now are derived from TSC value. http://en.wikipedia.org/wiki/Time_Stamp_Counter DTrace timestamps are measured in nano-seconds and the formula similar to the following is used for calculations: rdtsc() * 1000000000 / tsc_freq where rdtsc is a function that returns current TSC value and tsc_freq is a frequency of TSC. This formula is supposed to produce proper results if tsc_freq stays constant. But there are environment where this might not be the case. If a CPU has a non-invariant TSC and processor's clock frequency changes (e.g. because of powerd), then tsc_freq changes too. As a result, the formula would produce wildly different values and, most importantly, was values would non be monotonic. Timestamp values that jump back and forth would not only be useless for a user, they would also confuse DTrace internal logic. There are at least the following two alternatives: 1. Keep things as they are and warn users not to change CPU clock frequency when they use DTrace and the CPU doesn't have invariant TSC. I think that this should cause only minor inconveniences to a portion of DTrace users. 2. Use raw TSC value as a DTrace timestamp and document this difference from the original DTrace. Advantage: timestamp value is always monotonic. Disadvantage: manual conversion is needed to get "real" time (using the same formula). Please note that in this case timestamps would be in non-linear time dimension if TSC frequency changes, so to get meaningful timestamps (when needed/important) one would still have to make sure that TSC frequency stay constant. Please share your opinion on these approaches. Or suggest yest another alternative. Just in case, related sysctls: machdep.tsc_freq kern.timecounter.invariant_tsc -- Andriy Gapon From yr.retarded at gmail.com Thu Jul 9 17:52:44 2009 From: yr.retarded at gmail.com (Chris Ruiz) Date: Thu Jul 9 17:52:54 2009 Subject: no em0 with r195477 In-Reply-To: <20090709153940.4544bfa8.stas@FreeBSD.org> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> <20090709153940.4544bfa8.stas@FreeBSD.org> Message-ID: <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> On Thu, Jul 9, 2009 at 6:39 AM, Stanislav Sedov wrote: > On Wed, 8 Jul 2009 22:58:27 -0500 > Chris Ruiz mentioned: > >> i just upgraded from r194562 to r195477 in order to test BETA1 and my >> e1000 adapter no longer attaching to the driver. >> >> pciconf -lv output >> >> em0@pci0:0:25:0: ? ? ? ?class=0x020000 card=0x00018086 chip=0x10bd8086 >> rev=0x02 hdr=0x00 >> ? ? vendor ? ? = 'Intel Corporation' >> ? ? device ? ? = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' >> ? ? class ? ? ?= network >> ? ? subclass ? = ethernet >> >> here's a quick list of relevant commits since my last kernel build: >> r195409, r195168, r195049, r194979, r194925, r194911, r194865. >> > > Hi, Chris! > > Can you provide the verbose boot log? Turns out it's caused by the driver thinking the EEPROM checksum is invalid. Here's a verbose 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-BETA1 #0 r195483: Wed Jul 8 21:51:57 CDT 2009 root@attack.young-alumni.com:/usr/obj/usr/src/sys/FAILWHALE WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80dce000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff80dce2b0. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff80dce958. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80dcef88. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3001458636 Hz CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (3001.46-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3f5 AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000040fff, 262144 bytes (64 pages) 0x0000000000051000 - 0x0000000000099fff, 299008 bytes (73 pages) 0x0000000000e01000 - 0x00000000cdbcbfff, 3437015040 bytes (839115 pages) 0x00000000cdc9a000 - 0x00000000ceec4fff, 19050496 bytes (4651 pages) 0x00000000ceec7000 - 0x00000000cef79fff, 733184 bytes (179 pages) 0x00000000cefe5000 - 0x00000000cefe5fff, 4096 bytes (1 pages) 0x00000000ceff2000 - 0x00000000ceff2fff, 4096 bytes (1 pages) 0x00000000cefff000 - 0x00000000ceffffff, 4096 bytes (1 pages) 0x0000000100000000 - 0x000000021cbf3fff, 4777263104 bytes (1166324 pages) avail memory = 8192516096 (7812 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target 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 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu 0 ULE: setup cpu 1 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ACPI: RSDP 0xfe020 00014 (v0 INTEL ) ACPI: RSDT 0xceffd038 00070 (v1 INTEL DQ3510J 000003BA 01000013) ACPI: FACP 0xceffc000 00074 (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: DSDT 0xceff8000 03D6A (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: FACS 0xcef87000 00040 ACPI: APIC 0xceff7000 00078 (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: WDDT 0xceff6000 00040 (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: MCFG 0xceff5000 0003C (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: ASF! 0xceff4000 000A6 (v32 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: HPET 0xceff3000 00038 (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: DMAR 0xceff1000 000F8 (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: ASPT 0xceff0000 0002C (v3 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: WDTT 0xcefef000 002CC (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: SSDT 0xcefee000 00204 (v1 INTEL CpuPm 000003BA MSFT 01000013) ACPI: SSDT 0xcefed000 001F9 (v1 INTEL Cpu0Ist 000003BA MSFT 01000013) ACPI: SSDT 0xcefec000 001F9 (v1 INTEL Cpu1Ist 000003BA MSFT 01000013) ACPI: SSDT 0xcefeb000 001F9 (v1 INTEL Cpu2Ist 000003BA MSFT 01000013) ACPI: SSDT 0xcefea000 001F9 (v1 INTEL Cpu3Ist 000003BA MSFT 01000013) ACPI: SSDT 0xcefe9000 000DD (v1 INTEL Cpu0Cst 000003BA MSFT 01000013) ACPI: SSDT 0xcefe8000 000DD (v1 INTEL Cpu1Cst 000003BA MSFT 01000013) ACPI: SSDT 0xcefe7000 000DD (v1 INTEL Cpu2Cst 000003BA MSFT 01000013) ACPI: SSDT 0xcefe6000 000DD (v1 INTEL Cpu3Cst 000003BA MSFT 01000013) ACPI: TCPA 0xcef7b000 00032 (v2 INTEL TIANO 00000002 MSFT 01000013) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 wlan: <802.11 Link Layer> ichwd module loaded io: kbd0 at kbdmux0 mem: nfslock: pseudo-device null: random: acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff8000011000 pa 0x4000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.TMEM -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.PAMX -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR0 -> bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR1 -> bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.IELK.ELR0 -> bus 0 dev 0 func 0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 Validation 0 11 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 Validation 0 10 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 Validation 0 9 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 Validation 0 11 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 Validation 0 11 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 Validation 0 9 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 Validation 0 10 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 Validation 0 11 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x29b0, revid=0x02 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x29b2, revid=0x02 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xe0380000, size 19, enabled map[14]: type I/O Port, range 32, base 0x2458, size 3, enabled map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, enabled map[1c]: type Memory, range 32, base 0xe0200000, size 20, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x29b3, revid=0x02 domain=0, bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe0300000, size 19, enabled found-> vendor=0x8086, dev=0x29b4, revid=0x02 domain=0, bus=0, slot=3, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0018, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe0427100, size 4, enabled pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x29b6, revid=0x02 domain=0, bus=0, slot=3, func=2 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=9 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type I/O Port, range 32, base 0x2450, size 3, enabled map[14]: type I/O Port, range 32, base 0x246c, size 2, enabled map[18]: type I/O Port, range 32, base 0x2448, size 3, enabled map[1c]: type I/O Port, range 32, base 0x2468, size 2, enabled map[20]: type I/O Port, range 32, base 0x2420, size 4, enabled pcib0: matched entry for 0.3.INTC pcib0: slot 3 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x29b7, revid=0x02 domain=0, bus=0, slot=3, func=3 class=07-00-02, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type I/O Port, range 32, base 0x2440, size 3, enabled map[14]: type Memory, range 32, base 0xe0425000, size 12, enabled pcib0: matched entry for 0.3.INTB pcib0: slot 3 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x10bd, revid=0x02 domain=0, bus=0, slot=25, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xe0400000, size 17, enabled map[14]: type Memory, range 32, base 0xe0424000, size 12, enabled map[18]: type I/O Port, range 32, base 0x2400, size 5, enabled pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x2937, revid=0x02 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 map[20]: type I/O Port, range 32, base 0x20e0, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2938, revid=0x02 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=9 map[20]: type I/O Port, range 32, base 0x20c0, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2939, revid=0x02 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[20]: type I/O Port, range 32, base 0x20a0, size 5, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 17 found-> vendor=0x8086, dev=0x293c, revid=0x02 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe0426c00, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 17 found-> vendor=0x8086, dev=0x293e, revid=0x02 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe0420000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2940, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2942, revid=0x02 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2944, revid=0x02 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=c, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2946, revid=0x02 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2948, revid=0x02 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2934, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0x2080, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2935, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x2060, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2936, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=9 map[20]: type I/O Port, range 32, base 0x2040, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293a, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe0426800, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x92 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2914, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2922, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0x2438, size 3, enabled map[14]: type I/O Port, range 32, base 0x2464, size 2, enabled map[18]: type I/O Port, range 32, base 0x2430, size 3, enabled map[1c]: type I/O Port, range 32, base 0x2460, size 2, enabled map[20]: type I/O Port, range 32, base 0x2020, size 5, enabled map[24]: type Memory, range 32, base 0xe0426000, size 11, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2930, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=9 map[10]: type Memory, range 64, base 0xe0427000, size 8, enabled map[20]: type I/O Port, range 32, base 0x2000, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 18 vgapci0: port 0x2458-0x245f mem 0xe0380000-0xe03fffff,0xd0000000-0xdfffffff,0xe0200000-0xe02fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xe0380000 vgapci0: Reserved 0x100000 bytes for rid 0x1c type 3 at 0xe0200000 agp0: detected 6140k stolen memory agp0: aperture size is 256M vgapci1: mem 0xe0300000-0xe037ffff at device 2.1 on pci0 pci0: at device 3.0 (no driver attached) atapci0: port 0x2450-0x2457,0x246c-0x246f,0x2448-0x244f,0x2468-0x246b,0x2420-0x242f irq 18 at device 3.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x2420 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 49 atapci0: [MPSAFE] atapci0: [ITHREAD] ata2: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x2450 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x246c ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x2448 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0x2468 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] ata3: [ITHREAD] pci0: at device 3.3 (no driver attached) em0: port 0x2400-0x241f mem 0xe0400000-0xe041ffff,0xe0424000-0xe0424fff irq 20 at device 25.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xe0400000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 50 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xe0424000 em0: The EEPROM Checksum Is Not Valid device_attach: em0 attach returned 5 uhci0: port 0x20e0-0x20ff irq 18 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20e0 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x0f10 usbus0: on uhci0 uhci1: port 0x20c0-0x20df irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20c0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x0f10 usbus1: on uhci1 uhci2: port 0x20a0-0x20bf irq 17 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20a0 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 51 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x0f10 usbus2: on uhci2 ehci0: mem 0xe0426c00-0xe0426fff irq 17 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426c00 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pci0: at device 27.0 (no driver attached) pcib1: at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: at device 28.2 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x1000-0x1fff pcib3: memory decode 0xe0100000-0xe01fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x11ab, dev=0x6101, revid=0xb1 domain=0, bus=3, slot=0, func=0 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 2 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x1018, size 3, enabled pcib3: requested I/O range 0x1018-0x101f: in range map[14]: type I/O Port, range 32, base 0x1024, size 2, enabled pcib3: requested I/O range 0x1024-0x1027: in range map[18]: type I/O Port, range 32, base 0x1010, size 3, enabled pcib3: requested I/O range 0x1010-0x1017: in range map[1c]: type I/O Port, range 32, base 0x1020, size 2, enabled pcib3: requested I/O range 0x1020-0x1023: in range map[20]: type I/O Port, range 32, base 0x1000, size 4, enabled pcib3: requested I/O range 0x1000-0x100f: in range map[24]: type Memory, range 32, base 0xe0100000, size 9, enabled pcib3: requested memory range 0xe0100000-0xe01001ff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 18 atapci1: port 0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f mem 0xe0100000-0xe01001ff irq 18 at device 0.0 on pci3 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1000 atapci1: [MPSAFE] atapci1: [ITHREAD] ata4: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1018 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x1024 ata4: reset tp1 mask=03 ostat0=50 ostat1=51 ata4: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata4: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb ata4: reset tp2 stat0=00 stat1=10 devices=0x30000 ata4: [MPSAFE] ata4: [ITHREAD] pcib4: at device 28.3 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x0-0x0 pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 pcib5: at device 28.4 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x0-0x0 pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 uhci3: port 0x2080-0x209f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2080 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 52 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x0f10 usbus4: on uhci3 uhci4: port 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2060 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 53 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup = 0x0f10 usbus5: on uhci4 uhci5: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup = 0x0f10 usbus6: on uhci5 ehci1: mem 0xe0426800-0xe0426bff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426800 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0xf000-0xfff pcib6: memory decode 0xe0000000-0xe00fffff pcib6: no prefetched decode pcib6: Subtractively decoded bridge. pci6: on pcib6 pci6: domain=0, physical bus=6 found-> vendor=0x168c, dev=0x0013, revid=0x01 domain=0, bus=6, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0216, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=9 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe0000000, size 16, enabled pcib6: requested memory range 0xe0000000-0xe000ffff: good pcib6: matched entry for 6.0.INTA pcib6: slot 0 INTA hardwired to IRQ 21 found-> vendor=0x11c1, dev=0x5811, revid=0x70 domain=0, bus=6, slot=3, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0216, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x0c (3000 ns), maxlat=0x18 (6000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xe0010000, size 12, enabled pcib6: requested memory range 0xe0010000-0xe0010fff: good pcib6: matched entry for 6.3.INTA pcib6: slot 3 INTA hardwired to IRQ 19 ath0: mem 0xe0000000-0xe000ffff irq 21 at device 0.0 on pci6 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xe0000000 ath0: [MPSAFE] ath0: [ITHREAD] ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: turboG rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: AR2413 mac 7.9 RF2413 phy 4.5 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons fwohci0: mem 0xe0010000-0xe0010fff irq 19 at device 3.0 on pci6 fwohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe0010000 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:90:27:00:01:d0:dc:04 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x41000 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=2, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0x2438-0x243f,0x2464-0x2467,0x2430-0x2437,0x2460-0x2463,0x2020-0x203f mem 0xe0426000-0xe04267ff irq 21 at device 31.2 on pci0 atapci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2020 atapci2: [MPSAFE] atapci2: [ITHREAD] atapci2: Reserved 0x800 bytes for rid 0x24 type 3 at 0xe0426000 atapci2: AHCI called from vendor specific driver atapci2: AHCI v1.20 controller with 6 3Gbps ports, PM supported atapci2: Caps: 64bit NCQ SNTF ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd CCC EM 6ports ata5: on atapci2 ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect time=0ms status=00000123 ata5: ready wait time=14ms ata5: software reset port 15... ata5: ready wait time=0ms ata5: SIGNATURE: 00000101 ata5: AHCI reset done: devices=00000001 ata5: [MPSAFE] ata5: [ITHREAD] ata6: on atapci2 ata6: AHCI reset... ata6: hardware reset ... ata6: SATA connect time=0ms status=00000123 ata6: ready wait time=49ms ata6: software reset port 15... ata6: ready wait time=0ms ata6: SIGNATURE: 00000101 ata6: AHCI reset done: devices=00000001 ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci2 ata7: AHCI reset... ata7: hardware reset ... ata7: SATA connect time=0ms status=00000123 ata7: ready wait time=26ms ata7: software reset port 15... ata7: ready wait time=0ms ata7: SIGNATURE: 00000101 ata7: AHCI reset done: devices=00000001 ata7: [MPSAFE] ata7: [ITHREAD] ata8: on atapci2 ata8: AHCI reset... ata8: hardware reset ... ata8: SATA connect timeout status=00000000 ata8: AHCI reset done: phy reset found no device ata8: [MPSAFE] ata8: [ITHREAD] ata9: on atapci2 ata9: AHCI reset... ata9: hardware reset ... ata9: SATA connect time=0ms status=00000123 ata9: ready wait time=22ms ata9: software reset port 15... ata9: ready wait time=0ms ata9: SIGNATURE: 00000101 ata9: AHCI reset done: devices=00000001 ata9: [MPSAFE] ata9: [ITHREAD] ata10: on atapci2 ata10: AHCI reset... ata10: hardware reset ... ata10: SATA connect time=0ms status=00000123 ata10: ready wait time=22ms ata10: software reset port 15... ata10: ready wait time=0ms ata10: SIGNATURE: 00000101 ata10: AHCI reset done: devices=00000001 ata10: [MPSAFE] ata10: [ITHREAD] ichsmb0: port 0x2000-0x201f mem 0xe0427000-0xe04270ff irq 18 at device 31.3 on pci0 ichsmb0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2000 ichsmb0: [MPSAFE] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 54 uart0: [FILTER] uart0: fast interrupt uart0: console (115200,n,8,1) cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 est0: Invalid id16 (set, cur) = (2086, 2346) est0: Invalid freq 2664, ignored. est0: Invalid id16 (set, cur) = (1826, 2346) est0: Invalid freq 2331, ignored. est0: Invalid id16 (set, cur) = (1565, 2346) est0: Invalid freq 1998, ignored. p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 est1: Invalid id16 (set, cur) = (2086, 2346) est1: Invalid freq 2664, ignored. est1: Invalid id16 (set, cur) = (1826, 2346) est1: Invalid freq 2331, ignored. est1: Invalid id16 (set, cur) = (1565, 2346) est1: Invalid freq 1998, ignored. p4tcc1: on cpu1 isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer isa_probe_children: disabling PnP devices ichwd0: on isa0 isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer ichwd0: Intel ICH9DO watchdog timer (ICH9 or equivalent) ichwd0: timer disabled atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0 failed to probe at port 0x60 on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 508766 -> 100000 WARNING: ZFS is considered to be an experimental feature in FreeBSD. lapic: Divisor 2, Frequency 166747704 hz Timecounter "TSC" frequency 3001458636 Hz quality -100 Timecounters tick every 1.000 msec pflog0: bpf attached lo0: firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) firewire0: bus manager 1 bpf attached ata2: Identifying devices: 00000000 ata2: New devices: 00000000 ata3: Identifying devices: 00000000 ata3: New devices: 00000000 ata4: Identifying devices: 00030000 ata4: New devices: 00030000 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 ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire ata4-slave: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire 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 ZFS filesystem version 13 ZFS storage pool version 13 acd0: DVDR drive at ata4 as master acd0: read 6890KB/s (6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, UDMA66 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd1: DMA limited to UDMA33, device found non-ATA66 cable acd1: DVDROM drive at ata4 as slave acd1: read 687KB/s (8251KB/s), 512KB buffer, UDMA33 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd1: Writes: acd1: Audio: play, 256 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc ata5: Identifying devices: 00000001 ata5: New devices: 00000001 ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad10: 476940MB at ata5-master SATA300 ad10: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad10 ad10: Intel check1 failed ad10: Adaptec check1 failed ad10: LSI (v3) check1 failed ad10: LSI (v2) check1 failed ad10: FreeBSD check1 failed ata6: Identifying devices: 00000001 ata6: New devices: 00000001 ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad12: 476940MB at ata6-master SATA300 ad12: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad12 firewire0: New S400 device ID:001f5bfffe2776a6 fwohci0: txd err= 3 miss Ack err ad12: Intel check1 failed ad12: Adaptec check1 failed ad12: LSI (v3) check1 failed ad12: LSI (v2) check1 failed ad12: FreeBSD check1 failed ata7: Identifying devices: 00000001 ata7: New devices: 00000001 ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad14: 238475MB at ata7-master SATA300 ad14: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad14 ad14: Intel check1 failed ad14: Adaptec check1 failed ad14: LSI (v3) check1 failed ad14: LSI (v2) check1 failed ad14: FreeBSD check1 failed ata8: Identifying devices: 00000000 ata8: New devices: 00000000 ata9: Identifying devices: 00000001 ata9: New devices: 00000001 ata9-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad18: 715404MB at ata9-master SATA300 ad18: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad18 ad18: Intel check1 failed uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ad18: Adaptec check1 failed uhub4: 2 ports with 2 removable, self powered ad18: LSI (v3) check1 failed uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered ad18: LSI (v2) check1 failed ad18: FreeBSD check1 failed ata10: Identifying devices: 00000001 ata10: New devices: 00000001 ata10-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad20: 715404MB at ata10-master SATA300 ad20: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad20 ad20: Intel check1 failed ad20: Adaptec check1 failed ad20: LSI (v3) check1 failed ad20: LSI (v2) check1 failed ad20: FreeBSD check1 failed (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 49 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 1 vector 50 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen3.2: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus3 umass0:1:0:-1: Attached to scbus1 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? GEOM: new disk da0pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-0 device pass0: 40.000MB/s transfers da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3859MB (7905279 512 byte sectors: 255H 63S/T 492C) Trying to mount root from zfs:alert ugen5.2: at usbus5 ukbd0: on usbus5 kbd: new array size 4 kbd1 at ukbd0 kbd1: ukbd0, generic (0), config:0x0, flags:0x3d0000 ugen2.2: at usbus2 ct_to_ts([2009-07-09 12:36:12]) = 1247142972.000000000 start_init: trying /sbin/init lock order reversal: 1st 0xffffffff80815040 pf task mtx (pf task mtx) @ /usr/src/sys/contrib/pf/net/pf_ioctl.c:1394 2nd 0xffffffff809f7b40 ifnet (ifnet) @ /usr/src/sys/net/if.c:1887 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7d2 _rw_rlock() at _rw_rlock+0x60 ifunit() at ifunit+0x22 pfioctl() at pfioctl+0x20ea devfs_ioctl_f() at devfs_ioctl_f+0x6e kern_ioctl() at kern_ioctl+0xbc ioctl() at ioctl+0xf0 syscall() at syscall+0x18b Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80098a88c, rsp = 0x7fffffffb5c8, rbp = 0x7fffffffb710 --- lock order reversal: 1st 0xffffff0074026098 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1054 2nd 0xffffff007417dba8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7d2 __lockmgr_args() at __lockmgr_args+0xc92 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xc2 _vn_lock() at _vn_lock+0x50 vget() at vget+0x6c devfs_allocv() at devfs_allocv+0xee devfs_root() at devfs_root+0x41 vfs_donmount() at vfs_donmount+0xf93 nmount() at nmount+0x74 syscall() at syscall+0x18b Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007aaffc, rsp = 0x7fffffffdd28, rbp = 0x800a04048 --- Thanks, Chris -- @chrisattack ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From serenity at exscape.org Thu Jul 9 18:01:59 2009 From: serenity at exscape.org (Thomas Backman) Date: Thu Jul 9 18:02:06 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: <4A562960.3010801@freebsd.org> References: <4A562960.3010801@freebsd.org> Message-ID: On Jul 9, 2009, at 19:31, Andriy Gapon wrote: > There are at least the following two alternatives: > > 1. Keep things as they are and warn users not to change CPU clock > frequency when > they use DTrace and the CPU doesn't have invariant TSC. I think that > this should > cause only minor inconveniences to a portion of DTrace users. Hmm, but "things as they are" causes an overflow about every 10 seconds, so the value is quite useless now (which, of course, you know about, having written a patch for it :) Is scenario #1 after the patch (PR kern/127441 for the rest of you) or not? Regards, Thomas From hlh at restart.be Thu Jul 9 18:19:05 2009 From: hlh at restart.be (Henri Hennebert) Date: Thu Jul 9 18:19:12 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: <4A562960.3010801@freebsd.org> References: <4A562960.3010801@freebsd.org> Message-ID: <4A563494.1010209@restart.be> Andriy Gapon wrote: > As you might be aware DTrace timestamps right now are derived from TSC value. > http://en.wikipedia.org/wiki/Time_Stamp_Counter > > DTrace timestamps are measured in nano-seconds and the formula similar to the > following is used for calculations: > rdtsc() * 1000000000 / tsc_freq > where rdtsc is a function that returns current TSC value and tsc_freq is a > frequency of TSC. > > This formula is supposed to produce proper results if tsc_freq stays constant. > But there are environment where this might not be the case. > If a CPU has a non-invariant TSC and processor's clock frequency changes (e.g. > because of powerd), then tsc_freq changes too. > As a result, the formula would produce wildly different values and, most > importantly, was values would non be monotonic. Timestamp values that jump back > and forth would not only be useless for a user, they would also confuse DTrace > internal logic. > > There are at least the following two alternatives: > > 1. Keep things as they are and warn users not to change CPU clock frequency when > they use DTrace and the CPU doesn't have invariant TSC. I think that this should > cause only minor inconveniences to a portion of DTrace users. Im absolutely for this solution with a warning in the doc. It seems to me that when you use dtrace, you don't try at the same time to be power efficient... except if you want to dtrace powerd, of course. henri From avg at freebsd.org Thu Jul 9 18:20:53 2009 From: avg at freebsd.org (Andriy Gapon) Date: Thu Jul 9 18:20:59 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: References: <4A562960.3010801@freebsd.org> Message-ID: <4A563501.1090905@freebsd.org> on 09/07/2009 21:00 Thomas Backman said the following: > On Jul 9, 2009, at 19:31, Andriy Gapon wrote: >> There are at least the following two alternatives: >> >> 1. Keep things as they are and warn users not to change CPU clock >> frequency when >> they use DTrace and the CPU doesn't have invariant TSC. I think that >> this should >> cause only minor inconveniences to a portion of DTrace users. > Hmm, but "things as they are" causes an overflow about every 10 seconds, > so the value is quite useless now (which, of course, you know about, > having written a patch for it :) This is because of a deficiency in the implementation of the formula, not because of the formula itself. > Is scenario #1 after the patch (PR kern/127441 for the rest of you) or not? Yes, after the patch :) -- Andriy Gapon From serenity at exscape.org Thu Jul 9 18:31:00 2009 From: serenity at exscape.org (Thomas Backman) Date: Thu Jul 9 18:31:06 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: <4A563501.1090905@freebsd.org> References: <4A562960.3010801@freebsd.org> <4A563501.1090905@freebsd.org> Message-ID: <732354CB-8FF2-4040-8ABD-B94076551C57@exscape.org> On Jul 9, 2009, at 20:20, Andriy Gapon wrote: > on 09/07/2009 21:00 Thomas Backman said the following: >> On Jul 9, 2009, at 19:31, Andriy Gapon wrote: >>> There are at least the following two alternatives: >>> >>> 1. Keep things as they are and warn users not to change CPU clock >>> frequency when >>> they use DTrace and the CPU doesn't have invariant TSC. I think that >>> this should >>> cause only minor inconveniences to a portion of DTrace users. >> Hmm, but "things as they are" causes an overflow about every 10 >> seconds, >> so the value is quite useless now (which, of course, you know about, >> having written a patch for it :) > > This is because of a deficiency in the implementation of the > formula, not because > of the formula itself. > >> Is scenario #1 after the patch (PR kern/127441 for the rest of you) >> or not? > > Yes, after the patch :) In that case, I too strongly prefer alternative #1. It keeps the timestamp *time*-based, and not tick-based (thus not breaking Solaris/ OS X etc. compatibility), for one. It also makes it a whole lot easier to actually *time* things - is it even possible for a non-kernel- programmer DTrace user to easily convert the ticks to nanoseconds somewhat accurately? I think that's as good a reason as any (the first one, that is). If ZFS is kept as compatible as possible between OSes, then so should DTrace, IMHO. Regards, Thomas From marius at nuenneri.ch Thu Jul 9 18:33:49 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Thu Jul 9 18:33:56 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: <4A562960.3010801@freebsd.org> References: <4A562960.3010801@freebsd.org> Message-ID: On Thu, Jul 9, 2009 at 19:31, Andriy Gapon wrote: > > As you might be aware DTrace timestamps right now are derived from TSC value. > http://en.wikipedia.org/wiki/Time_Stamp_Counter > > DTrace timestamps are measured in nano-seconds and the formula similar to the > following is used for calculations: > rdtsc() * 1000000000 / tsc_freq > where rdtsc is a function that returns current TSC value and tsc_freq is a > frequency of TSC. > > This formula is supposed to produce proper results if tsc_freq stays constant. > But there are environment where this might not be the case. > If a CPU has a non-invariant TSC and processor's clock frequency changes (e.g. > because of powerd), then tsc_freq changes too. > As a result, the formula would produce wildly different values and, most > importantly, was values would non be monotonic. Timestamp values that jump back > and forth would not only be useless for a user, they would also confuse DTrace > internal logic. > > There are at least the following two alternatives: > > 1. Keep things as they are and warn users not to change CPU clock frequency when > they use DTrace and the CPU doesn't have invariant TSC. I think that this should > cause only minor inconveniences to a portion of DTrace users. > > 2. Use raw TSC value as a DTrace timestamp and document this difference from the > original DTrace. Advantage: timestamp value is always monotonic. Disadvantage: > manual conversion is needed to get "real" time (using the same formula). > Please note that in this case timestamps would be in non-linear time dimension if > TSC frequency changes, so to get meaningful timestamps (when needed/important) one > would still have to make sure that TSC frequency stay constant. > > Please share your opinion on these approaches. > Or suggest yest another alternative. What about atomically changing tsc_freq every time the frequency is changed? > > Just in case, related sysctls: > machdep.tsc_freq > kern.timecounter.invariant_tsc From jfvogel at gmail.com Thu Jul 9 18:35:06 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Jul 9 18:35:16 2009 Subject: no em0 with r195477 In-Reply-To: <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> <20090709153940.4544bfa8.stas@FreeBSD.org> <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> Message-ID: <2a41acea0907091135j12f4c0efn963859f8def1d9cd@mail.gmail.com> I am looking into this, thanks for the report. Jack On Thu, Jul 9, 2009 at 10:52 AM, Chris Ruiz wrote: > On Thu, Jul 9, 2009 at 6:39 AM, Stanislav Sedov wrote: > > On Wed, 8 Jul 2009 22:58:27 -0500 > > Chris Ruiz mentioned: > > > >> i just upgraded from r194562 to r195477 in order to test BETA1 and my > >> e1000 adapter no longer attaching to the driver. > >> > >> pciconf -lv output > >> > >> em0@pci0:0:25:0: class=0x020000 card=0x00018086 chip=0x10bd8086 > >> rev=0x02 hdr=0x00 > >> vendor = 'Intel Corporation' > >> device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' > >> class = network > >> subclass = ethernet > >> > >> here's a quick list of relevant commits since my last kernel build: > >> r195409, r195168, r195049, r194979, r194925, r194911, r194865. > >> > > > > Hi, Chris! > > > > Can you provide the verbose boot log? > > Turns out it's caused by the driver thinking the EEPROM checksum is > invalid. Here's a verbose 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-BETA1 #0 r195483: Wed Jul 8 21:51:57 CDT 2009 > root@attack.young-alumni.com:/usr/obj/usr/src/sys/FAILWHALE > WARNING: WITNESS option enabled, expect reduced performance. > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80dce000. > Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff80dce2b0. > Preloaded elf obj module "/boot/kernel/opensolaris.ko" at > 0xffffffff80dce958. > Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at > 0xffffffff80dcef88. > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 3001458636 Hz > CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (3001.46-MHz K8-class > CPU) > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > Features=0xbfebfbff > Features2=0xe3f5 > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 8589934592 (8192 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x0000000000040fff, 262144 bytes (64 pages) > 0x0000000000051000 - 0x0000000000099fff, 299008 bytes (73 pages) > 0x0000000000e01000 - 0x00000000cdbcbfff, 3437015040 bytes (839115 pages) > 0x00000000cdc9a000 - 0x00000000ceec4fff, 19050496 bytes (4651 pages) > 0x00000000ceec7000 - 0x00000000cef79fff, 733184 bytes (179 pages) > 0x00000000cefe5000 - 0x00000000cefe5fff, 4096 bytes (1 pages) > 0x00000000ceff2000 - 0x00000000ceff2fff, 4096 bytes (1 pages) > 0x00000000cefff000 - 0x00000000ceffffff, 4096 bytes (1 pages) > 0x0000000100000000 - 0x000000021cbf3fff, 4777263104 bytes (1166324 pages) > avail memory = 8192516096 (7812 MB) > ACPI APIC Table: > INTR: Adding local APIC 1 as a target > 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 > APIC: CPU 0 has ACPI ID 1 > APIC: CPU 1 has ACPI ID 2 > ULE: setup cpu 0 > ULE: setup cpu 1 > This module (opensolaris) contains code covered by the > Common Development and Distribution License (CDDL) > see http://opensolaris.org/os/licensing/opensolaris_license/ > ACPI: RSDP 0xfe020 00014 (v0 INTEL ) > ACPI: RSDT 0xceffd038 00070 (v1 INTEL DQ3510J 000003BA 01000013) > ACPI: FACP 0xceffc000 00074 (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: DSDT 0xceff8000 03D6A (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: FACS 0xcef87000 00040 > ACPI: APIC 0xceff7000 00078 (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: WDDT 0xceff6000 00040 (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: MCFG 0xceff5000 0003C (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: ASF! 0xceff4000 000A6 (v32 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: HPET 0xceff3000 00038 (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: DMAR 0xceff1000 000F8 (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: ASPT 0xceff0000 0002C (v3 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: WDTT 0xcefef000 002CC (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: SSDT 0xcefee000 00204 (v1 INTEL CpuPm 000003BA MSFT 01000013) > ACPI: SSDT 0xcefed000 001F9 (v1 INTEL Cpu0Ist 000003BA MSFT 01000013) > ACPI: SSDT 0xcefec000 001F9 (v1 INTEL Cpu1Ist 000003BA MSFT 01000013) > ACPI: SSDT 0xcefeb000 001F9 (v1 INTEL Cpu2Ist 000003BA MSFT 01000013) > ACPI: SSDT 0xcefea000 001F9 (v1 INTEL Cpu3Ist 000003BA MSFT 01000013) > ACPI: SSDT 0xcefe9000 000DD (v1 INTEL Cpu0Cst 000003BA MSFT 01000013) > ACPI: SSDT 0xcefe8000 000DD (v1 INTEL Cpu1Cst 000003BA MSFT 01000013) > ACPI: SSDT 0xcefe7000 000DD (v1 INTEL Cpu2Cst 000003BA MSFT 01000013) > ACPI: SSDT 0xcefe6000 000DD (v1 INTEL Cpu3Cst 000003BA MSFT 01000013) > ACPI: TCPA 0xcef7b000 00032 (v2 INTEL TIANO 00000002 MSFT 01000013) > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > ioapic0: Changing APIC ID to 2 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > lapic0: Routing NMI -> LINT1 > lapic0: LINT1 trigger: edge > lapic0: LINT1 polarity: high > lapic1: Routing NMI -> LINT1 > lapic1: LINT1 trigger: edge > lapic1: LINT1 polarity: high > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 > wlan: <802.11 Link Layer> > ichwd module loaded > io: > kbd0 at kbdmux0 > mem: > nfslock: pseudo-device > null: > random: > acpi0: on motherboard > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > acpi0: [MPSAFE] > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: wakeup code va 0xffffff8000011000 pa 0x4000 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.TMEM -> bus 0 dev 0 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.PAMX -> bus 0 dev 0 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR0 -> bus 0 dev 31 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR1 -> bus 0 dev 31 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.IELK.ELR0 -> bus 0 dev 0 func 0 > ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 > Validation 0 11 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 > Validation 0 10 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 > Validation 0 9 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 > Validation 0 11 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 > Validation 0 11 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 > Validation 0 9 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 > Validation 0 10 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 > Validation 0 11 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route > 64-bit > Timecounter "HPET" frequency 14318180 Hz quality 900 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x8086, dev=0x29b0, revid=0x02 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x29b2, revid=0x02 > domain=0, bus=0, slot=2, func=0 > class=03-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type Memory, range 32, base 0xe0380000, size 19, enabled > map[14]: type I/O Port, range 32, base 0x2458, size 3, enabled > map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size > 28, enabled > map[1c]: type Memory, range 32, base 0xe0200000, size 20, enabled > pcib0: matched entry for 0.2.INTA > pcib0: slot 2 INTA hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x29b3, revid=0x02 > domain=0, bus=0, slot=2, func=1 > class=03-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xe0300000, size 19, enabled > found-> vendor=0x8086, dev=0x29b4, revid=0x02 > domain=0, bus=0, slot=3, func=0 > class=07-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0018, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 64, base 0xe0427100, size 4, enabled > pcib0: matched entry for 0.3.INTA > pcib0: slot 3 INTA hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x29b6, revid=0x02 > domain=0, bus=0, slot=3, func=2 > class=01-01-85, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=9 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type I/O Port, range 32, base 0x2450, size 3, enabled > map[14]: type I/O Port, range 32, base 0x246c, size 2, enabled > map[18]: type I/O Port, range 32, base 0x2448, size 3, enabled > map[1c]: type I/O Port, range 32, base 0x2468, size 2, enabled > map[20]: type I/O Port, range 32, base 0x2420, size 4, enabled > pcib0: matched entry for 0.3.INTC > pcib0: slot 3 INTC hardwired to IRQ 18 > found-> vendor=0x8086, dev=0x29b7, revid=0x02 > domain=0, bus=0, slot=3, func=3 > class=07-00-02, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=10 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type I/O Port, range 32, base 0x2440, size 3, enabled > map[14]: type Memory, range 32, base 0xe0425000, size 12, enabled > pcib0: matched entry for 0.3.INTB > pcib0: slot 3 INTB hardwired to IRQ 17 > found-> vendor=0x8086, dev=0x10bd, revid=0x02 > domain=0, bus=0, slot=25, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0xe0400000, size 17, enabled > map[14]: type Memory, range 32, base 0xe0424000, size 12, enabled > map[18]: type I/O Port, range 32, base 0x2400, size 5, enabled > pcib0: matched entry for 0.25.INTA > pcib0: slot 25 INTA hardwired to IRQ 20 > found-> vendor=0x8086, dev=0x2937, revid=0x02 > domain=0, bus=0, slot=26, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=9 > map[20]: type I/O Port, range 32, base 0x20e0, size 5, enabled > pcib0: matched entry for 0.26.INTA > pcib0: slot 26 INTA hardwired to IRQ 18 > found-> vendor=0x8086, dev=0x2938, revid=0x02 > domain=0, bus=0, slot=26, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=9 > map[20]: type I/O Port, range 32, base 0x20c0, size 5, enabled > pcib0: matched entry for 0.26.INTB > pcib0: slot 26 INTB hardwired to IRQ 21 > found-> vendor=0x8086, dev=0x2939, revid=0x02 > domain=0, bus=0, slot=26, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=10 > map[20]: type I/O Port, range 32, base 0x20a0, size 5, enabled > pcib0: matched entry for 0.26.INTC > pcib0: slot 26 INTC hardwired to IRQ 17 > found-> vendor=0x8086, dev=0x293c, revid=0x02 > domain=0, bus=0, slot=26, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=10 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xe0426c00, size 10, enabled > pcib0: matched entry for 0.26.INTC > pcib0: slot 26 INTC hardwired to IRQ 17 > found-> vendor=0x8086, dev=0x293e, revid=0x02 > domain=0, bus=0, slot=27, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 64, base 0xe0420000, size 14, enabled > pcib0: matched entry for 0.27.INTA > pcib0: slot 27 INTA hardwired to IRQ 22 > found-> vendor=0x8086, dev=0x2940, revid=0x02 > domain=0, bus=0, slot=28, func=0 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=0x8086, dev=0x2942, revid=0x02 > domain=0, bus=0, slot=28, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=b, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=0x8086, dev=0x2944, revid=0x02 > domain=0, bus=0, slot=28, func=2 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=c, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=0x8086, dev=0x2946, revid=0x02 > domain=0, bus=0, slot=28, func=3 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=d, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=0x8086, dev=0x2948, revid=0x02 > domain=0, bus=0, slot=28, func=4 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=0x8086, dev=0x2934, revid=0x02 > domain=0, bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > map[20]: type I/O Port, range 32, base 0x2080, size 5, enabled > pcib0: matched entry for 0.29.INTA > pcib0: slot 29 INTA hardwired to IRQ 23 > found-> vendor=0x8086, dev=0x2935, revid=0x02 > domain=0, bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > map[20]: type I/O Port, range 32, base 0x2060, size 5, enabled > pcib0: matched entry for 0.29.INTB > pcib0: slot 29 INTB hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x2936, revid=0x02 > domain=0, bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=9 > map[20]: type I/O Port, range 32, base 0x2040, size 5, enabled > pcib0: matched entry for 0.29.INTC > pcib0: slot 29 INTC hardwired to IRQ 18 > found-> vendor=0x8086, dev=0x293a, revid=0x02 > domain=0, bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xe0426800, size 10, enabled > pcib0: matched entry for 0.29.INTA > pcib0: slot 29 INTA hardwired to IRQ 23 > found-> vendor=0x8086, dev=0x244e, revid=0x92 > domain=0, bus=0, slot=30, func=0 > class=06-04-01, hdrtype=0x01, mfdev=0 > cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2914, revid=0x02 > domain=0, bus=0, slot=31, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2922, revid=0x02 > domain=0, bus=0, slot=31, func=2 > class=01-06-01, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=9 > powerspec 3 supports D0 D3 current D0 > MSI supports 16 messages > map[10]: type I/O Port, range 32, base 0x2438, size 3, enabled > map[14]: type I/O Port, range 32, base 0x2464, size 2, enabled > map[18]: type I/O Port, range 32, base 0x2430, size 3, enabled > map[1c]: type I/O Port, range 32, base 0x2460, size 2, enabled > map[20]: type I/O Port, range 32, base 0x2020, size 5, enabled > map[24]: type Memory, range 32, base 0xe0426000, size 11, enabled > pcib0: matched entry for 0.31.INTA > pcib0: slot 31 INTA hardwired to IRQ 21 > found-> vendor=0x8086, dev=0x2930, revid=0x02 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=9 > map[10]: type Memory, range 64, base 0xe0427000, size 8, enabled > map[20]: type I/O Port, range 32, base 0x2000, size 5, enabled > pcib0: matched entry for 0.31.INTB > pcib0: slot 31 INTB hardwired to IRQ 18 > vgapci0: port 0x2458-0x245f mem > 0xe0380000-0xe03fffff,0xd0000000-0xdfffffff,0xe0200000-0xe02fffff irq > 16 at device 2.0 on pci0 > agp0: on vgapci0 > vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 > vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xe0380000 > vgapci0: Reserved 0x100000 bytes for rid 0x1c type 3 at 0xe0200000 > agp0: detected 6140k stolen memory > agp0: aperture size is 256M > vgapci1: mem 0xe0300000-0xe037ffff at device > 2.1 on pci0 > pci0: at device 3.0 (no driver attached) > atapci0: port > 0x2450-0x2457,0x246c-0x246f,0x2448-0x244f,0x2468-0x246b,0x2420-0x242f > irq 18 at device 3.2 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x2420 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 49 > atapci0: [MPSAFE] > atapci0: [ITHREAD] > ata2: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x2450 > atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x246c > ata2: reset tp1 mask=03 ostat0=7f ostat1=7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: reset tp2 stat0=ff stat1=ff devices=0x0 > ata2: [MPSAFE] > ata2: [ITHREAD] > ata3: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x2448 > atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0x2468 > ata3: reset tp1 mask=03 ostat0=7f ostat1=7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: reset tp2 stat0=ff stat1=ff devices=0x0 > ata3: [MPSAFE] > ata3: [ITHREAD] > pci0: at device 3.3 (no driver attached) > em0: port 0x2400-0x241f > mem 0xe0400000-0xe041ffff,0xe0424000-0xe0424fff irq 20 at device 25.0 > on pci0 > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xe0400000 > em0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 50 > em0: using IRQ 256 for MSI > em0: Using MSI interrupt > em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xe0424000 > em0: The EEPROM Checksum Is Not Valid > device_attach: em0 attach returned 5 > uhci0: port 0x20e0-0x20ff irq 18 > at device 26.0 on pci0 > uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20e0 > uhci0: [MPSAFE] > uhci0: [ITHREAD] > uhci0: LegSup = 0x0f10 > usbus0: on uhci0 > uhci1: port 0x20c0-0x20df irq 21 > at device 26.1 on pci0 > uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20c0 > ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 > uhci1: [MPSAFE] > uhci1: [ITHREAD] > uhci1: LegSup = 0x0f10 > usbus1: on uhci1 > uhci2: port 0x20a0-0x20bf irq 17 > at device 26.2 on pci0 > uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20a0 > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 51 > uhci2: [MPSAFE] > uhci2: [ITHREAD] > uhci2: LegSup = 0x0f10 > usbus2: on uhci2 > ehci0: mem > 0xe0426c00-0xe0426fff irq 17 at device 26.7 on pci0 > ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426c00 > ehci0: [MPSAFE] > ehci0: [ITHREAD] > usbus3: EHCI version 1.0 > usbus3: on ehci0 > pci0: at device 27.0 (no driver attached) > pcib1: at device 28.0 on pci0 > pcib1: domain 0 > pcib1: secondary bus 1 > pcib1: subordinate bus 1 > pcib1: I/O decode 0x0-0x0 > pcib1: no prefetched decode > pci1: on pcib1 > pci1: domain=0, physical bus=1 > pcib2: at device 28.1 on pci0 > pcib2: domain 0 > pcib2: secondary bus 2 > pcib2: subordinate bus 2 > pcib2: I/O decode 0x0-0x0 > pcib2: no prefetched decode > pci2: on pcib2 > pci2: domain=0, physical bus=2 > pcib3: at device 28.2 on pci0 > pcib3: domain 0 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode 0x1000-0x1fff > pcib3: memory decode 0xe0100000-0xe01fffff > pcib3: no prefetched decode > pci3: on pcib3 > pci3: domain=0, physical bus=3 > found-> vendor=0x11ab, dev=0x6101, revid=0xb1 > domain=0, bus=3, slot=0, func=0 > class=01-01-8f, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=9 > powerspec 2 supports D0 D1 D3 current D0 > MSI supports 1 message > map[10]: type I/O Port, range 32, base 0x1018, size 3, enabled > pcib3: requested I/O range 0x1018-0x101f: in range > map[14]: type I/O Port, range 32, base 0x1024, size 2, enabled > pcib3: requested I/O range 0x1024-0x1027: in range > map[18]: type I/O Port, range 32, base 0x1010, size 3, enabled > pcib3: requested I/O range 0x1010-0x1017: in range > map[1c]: type I/O Port, range 32, base 0x1020, size 2, enabled > pcib3: requested I/O range 0x1020-0x1023: in range > map[20]: type I/O Port, range 32, base 0x1000, size 4, enabled > pcib3: requested I/O range 0x1000-0x100f: in range > map[24]: type Memory, range 32, base 0xe0100000, size 9, enabled > pcib3: requested memory range 0xe0100000-0xe01001ff: good > pcib3: matched entry for 3.0.INTA > pcib3: slot 0 INTA hardwired to IRQ 18 > atapci1: port > 0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f > mem 0xe0100000-0xe01001ff irq 18 at device 0.0 on pci3 > atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1000 > atapci1: [MPSAFE] > atapci1: [ITHREAD] > ata4: on atapci1 > atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1018 > atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x1024 > ata4: reset tp1 mask=03 ostat0=50 ostat1=51 > ata4: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata4: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb > ata4: reset tp2 stat0=00 stat1=10 devices=0x30000 > ata4: [MPSAFE] > ata4: [ITHREAD] > pcib4: at device 28.3 on pci0 > pcib4: domain 0 > pcib4: secondary bus 4 > pcib4: subordinate bus 4 > pcib4: I/O decode 0x0-0x0 > pcib4: no prefetched decode > pci4: on pcib4 > pci4: domain=0, physical bus=4 > pcib5: at device 28.4 on pci0 > pcib5: domain 0 > pcib5: secondary bus 5 > pcib5: subordinate bus 5 > pcib5: I/O decode 0x0-0x0 > pcib5: no prefetched decode > pci5: on pcib5 > pci5: domain=0, physical bus=5 > uhci3: port 0x2080-0x209f irq 23 > at device 29.0 on pci0 > uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2080 > ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 52 > uhci3: [MPSAFE] > uhci3: [ITHREAD] > uhci3: LegSup = 0x0f10 > usbus4: on uhci3 > uhci4: port 0x2060-0x207f irq 19 > at device 29.1 on pci0 > uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2060 > ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 53 > uhci4: [MPSAFE] > uhci4: [ITHREAD] > uhci4: LegSup = 0x0f10 > usbus5: on uhci4 > uhci5: port 0x2040-0x205f irq 18 > at device 29.2 on pci0 > uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040 > uhci5: [MPSAFE] > uhci5: [ITHREAD] > uhci5: LegSup = 0x0f10 > usbus6: on uhci5 > ehci1: mem > 0xe0426800-0xe0426bff irq 23 at device 29.7 on pci0 > ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426800 > ehci1: [MPSAFE] > ehci1: [ITHREAD] > usbus7: EHCI version 1.0 > usbus7: on ehci1 > pcib6: at device 30.0 on pci0 > pcib6: domain 0 > pcib6: secondary bus 6 > pcib6: subordinate bus 6 > pcib6: I/O decode 0xf000-0xfff > pcib6: memory decode 0xe0000000-0xe00fffff > pcib6: no prefetched decode > pcib6: Subtractively decoded bridge. > pci6: on pcib6 > pci6: domain=0, physical bus=6 > found-> vendor=0x168c, dev=0x0013, revid=0x01 > domain=0, bus=6, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0216, statreg=0x0290, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) > intpin=a, irq=9 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xe0000000, size 16, enabled > pcib6: requested memory range 0xe0000000-0xe000ffff: good > pcib6: matched entry for 6.0.INTA > pcib6: slot 0 INTA hardwired to IRQ 21 > found-> vendor=0x11c1, dev=0x5811, revid=0x70 > domain=0, bus=6, slot=3, func=0 > class=0c-00-10, hdrtype=0x00, mfdev=0 > cmdreg=0x0216, statreg=0x0290, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x0c (3000 ns), maxlat=0x18 (6000 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xe0010000, size 12, enabled > pcib6: requested memory range 0xe0010000-0xe0010fff: good > pcib6: matched entry for 6.3.INTA > pcib6: slot 3 INTA hardwired to IRQ 19 > ath0: mem 0xe0000000-0xe000ffff irq 21 at device 0.0 on pci6 > ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xe0000000 > ath0: [MPSAFE] > ath0: [ITHREAD] > ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > 24Mbps 36Mbps 48Mbps 54Mbps > ath0: turboG rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps > 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > ath0: AR2413 mac 7.9 RF2413 phy 4.5 > ath0: Use hw queue 1 for WME_AC_BE traffic > ath0: Use hw queue 0 for WME_AC_BK traffic > ath0: Use hw queue 2 for WME_AC_VI traffic > ath0: Use hw queue 3 for WME_AC_VO traffic > ath0: Use hw queue 8 for CAB traffic > ath0: Use hw queue 9 for beacons > fwohci0: mem 0xe0010000-0xe0010fff irq 19 at device > 3.0 on pci6 > fwohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe0010000 > fwohci0: [MPSAFE] > fwohci0: [ITHREAD] > fwohci0: OHCI version 1.0 (ROM=0) > fwohci0: No. of Isochronous channels is 8. > fwohci0: EUI64 00:90:27:00:01:d0:dc:04 > fwohci0: Phy 1394a available S400, 2 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x41000 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: fwohci_intr_core: BUS reset > fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=2, CYCLEMASTER > mode > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci2: port > 0x2438-0x243f,0x2464-0x2467,0x2430-0x2437,0x2460-0x2463,0x2020-0x203f > mem 0xe0426000-0xe04267ff irq 21 at device 31.2 on pci0 > atapci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2020 > atapci2: [MPSAFE] > atapci2: [ITHREAD] > atapci2: Reserved 0x800 bytes for rid 0x24 type 3 at 0xe0426000 > atapci2: AHCI called from vendor specific driver > atapci2: AHCI v1.20 controller with 6 3Gbps ports, PM supported > atapci2: Caps: 64bit NCQ SNTF ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd > CCC EM 6ports > ata5: on atapci2 > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect time=0ms status=00000123 > ata5: ready wait time=14ms > ata5: software reset port 15... > ata5: ready wait time=0ms > ata5: SIGNATURE: 00000101 > ata5: AHCI reset done: devices=00000001 > ata5: [MPSAFE] > ata5: [ITHREAD] > ata6: on atapci2 > ata6: AHCI reset... > ata6: hardware reset ... > ata6: SATA connect time=0ms status=00000123 > ata6: ready wait time=49ms > ata6: software reset port 15... > ata6: ready wait time=0ms > ata6: SIGNATURE: 00000101 > ata6: AHCI reset done: devices=00000001 > ata6: [MPSAFE] > ata6: [ITHREAD] > ata7: on atapci2 > ata7: AHCI reset... > ata7: hardware reset ... > ata7: SATA connect time=0ms status=00000123 > ata7: ready wait time=26ms > ata7: software reset port 15... > ata7: ready wait time=0ms > ata7: SIGNATURE: 00000101 > ata7: AHCI reset done: devices=00000001 > ata7: [MPSAFE] > ata7: [ITHREAD] > ata8: on atapci2 > ata8: AHCI reset... > ata8: hardware reset ... > ata8: SATA connect timeout status=00000000 > ata8: AHCI reset done: phy reset found no device > ata8: [MPSAFE] > ata8: [ITHREAD] > ata9: on atapci2 > ata9: AHCI reset... > ata9: hardware reset ... > ata9: SATA connect time=0ms status=00000123 > ata9: ready wait time=22ms > ata9: software reset port 15... > ata9: ready wait time=0ms > ata9: SIGNATURE: 00000101 > ata9: AHCI reset done: devices=00000001 > ata9: [MPSAFE] > ata9: [ITHREAD] > ata10: on atapci2 > ata10: AHCI reset... > ata10: hardware reset ... > ata10: SATA connect time=0ms status=00000123 > ata10: ready wait time=22ms > ata10: software reset port 15... > ata10: ready wait time=0ms > ata10: SIGNATURE: 00000101 > ata10: AHCI reset done: devices=00000001 > ata10: [MPSAFE] > ata10: [ITHREAD] > ichsmb0: port 0x2000-0x201f mem > 0xe0427000-0xe04270ff irq 18 at device 31.3 on pci0 > ichsmb0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2000 > ichsmb0: [MPSAFE] > ichsmb0: [ITHREAD] > smbus0: on ichsmb0 > smb0: on smbus0 > atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 > atrtc0: registered as a time-of-day clock (resolution 1000000us) > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 54 > uart0: [FILTER] > uart0: fast interrupt > uart0: console (115200,n,8,1) > cpu0: on acpi0 > coretemp0: on cpu0 > est0: on cpu0 > est0: Invalid id16 (set, cur) = (2086, 2346) > est0: Invalid freq 2664, ignored. > est0: Invalid id16 (set, cur) = (1826, 2346) > est0: Invalid freq 2331, ignored. > est0: Invalid id16 (set, cur) = (1565, 2346) > est0: Invalid freq 1998, ignored. > p4tcc0: on cpu0 > cpu1: on acpi0 > coretemp1: on cpu1 > est1: on cpu1 > est1: Invalid id16 (set, cur) = (2086, 2346) > est1: Invalid freq 2664, ignored. > est1: Invalid id16 (set, cur) = (1826, 2346) > est1: Invalid freq 2331, ignored. > est1: Invalid id16 (set, cur) = (1565, 2346) > est1: Invalid freq 1998, ignored. > p4tcc1: on cpu1 > isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer > isa_probe_children: disabling PnP devices > ichwd0: on isa0 > isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer > ichwd0: Intel ICH9DO watchdog timer (ICH9 or equivalent) > ichwd0: timer disabled > atrtc: atrtc0 already exists; skipping it > sc: sc0 already exists; skipping it > uart: uart0 already exists; skipping it > isa_probe_children: probing non-PnP devices > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd0, terminal emulator: scteken (teken terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > atkbdc0 failed to probe at port 0x60 on isa0 > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > ppc0 failed to probe at irq 7 on isa0 > uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > isa_probe_children: probing PnP devices > Device configuration finished. > Reducing kern.maxvnodes 508766 -> 100000 > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > lapic: Divisor 2, Frequency 166747704 hz > Timecounter "TSC" frequency 3001458636 Hz quality -100 > Timecounters tick every 1.000 msec > pflog0: bpf attached > lo0: firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) > firewire0: bus manager 1 > bpf attached > ata2: Identifying devices: 00000000 > ata2: New devices: 00000000 > ata3: Identifying devices: 00000000 > ata3: New devices: 00000000 > ata4: Identifying devices: 00030000 > ata4: New devices: 00030000 > 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 > ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire > ata4-slave: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire > 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 > ZFS filesystem version 13 > ZFS storage pool version 13 > acd0: DVDR drive at ata4 as master > acd0: read 6890KB/s (6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, > UDMA66 > acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet > acd0: Writes: CDR, CDRW, DVDR, test write, burnproof > acd0: Audio: play, 256 volume levels > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: no/blank disc > acd1: DMA limited to UDMA33, device found non-ATA66 cable > acd1: DVDROM drive at ata4 as slave > acd1: read 687KB/s (8251KB/s), 512KB buffer, UDMA33 > acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet > acd1: Writes: > acd1: Audio: play, 256 volume levels > acd1: Mechanism: ejectable tray, unlocked > acd1: Medium: no/blank disc > ata5: Identifying devices: 00000001 > ata5: New devices: 00000001 > ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad10: 476940MB at ata5-master SATA300 > ad10: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth > queue > GEOM: new disk ad10 > ad10: Intel check1 failed > ad10: Adaptec check1 failed > ad10: LSI (v3) check1 failed > ad10: LSI (v2) check1 failed > ad10: FreeBSD check1 failed > ata6: Identifying devices: 00000001 > ata6: New devices: 00000001 > ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad12: 476940MB at ata6-master SATA300 > ad12: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth > queue > GEOM: new disk ad12 > firewire0: New S400 device ID:001f5bfffe2776a6 > fwohci0: txd err= 3 miss Ack err > ad12: Intel check1 failed > ad12: Adaptec check1 failed > ad12: LSI (v3) check1 failed > ad12: LSI (v2) check1 failed > ad12: FreeBSD check1 failed > ata7: Identifying devices: 00000001 > ata7: New devices: 00000001 > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad14: 238475MB at ata7-master SATA300 > ad14: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth > queue > GEOM: new disk ad14 > ad14: Intel check1 failed > ad14: Adaptec check1 failed > ad14: LSI (v3) check1 failed > ad14: LSI (v2) check1 failed > ad14: FreeBSD check1 failed > ata8: Identifying devices: 00000000 > ata8: New devices: 00000000 > ata9: Identifying devices: 00000001 > ata9: New devices: 00000001 > ata9-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad18: 715404MB at ata9-master SATA300 > ad18: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth > queue > GEOM: new disk ad18 > ad18: Intel check1 failed > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > ad18: Adaptec check1 failed > uhub4: 2 ports with 2 removable, self powered > ad18: LSI (v3) check1 failed > uhub5: 2 ports with 2 removable, self powered > uhub6: 2 ports with 2 removable, self powered > ad18: LSI (v2) check1 failed > ad18: FreeBSD check1 failed > ata10: Identifying devices: 00000001 > ata10: New devices: 00000001 > ata10-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad20: 715404MB at ata10-master SATA300 > ad20: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth > queue > GEOM: new disk ad20 > ad20: Intel check1 failed > ad20: Adaptec check1 failed > ad20: LSI (v3) check1 failed > ad20: LSI (v2) check1 failed > ad20: FreeBSD check1 failed > (probe0:sbp0:0:0:0): error 22 > (probe0:sbp0:0:0:0): Unretryable Error > (probe1:sbp0:0:1:0): error 22 > (probe1:sbp0:0:1:0): Unretryable Error > (probe2:sbp0:0:2:0): error 22 > (probe2:sbp0:0:2:0): Unretryable Error > (probe3:sbp0:0:3:0): error 22 > (probe3:sbp0:0:3:0): Unretryable Error > (probe4:sbp0:0:4:0): error 22 > (probe4:sbp0:0:4:0): Unretryable Error > (probe5:sbp0:0:5:0): error 22 > (probe5:sbp0:0:5:0): Unretryable Error > (probe6:sbp0:0:6:0): error 22 > (probe6:sbp0:0:6:0): Unretryable Error > ATA PseudoRAID loaded > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 49 > ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 1 vector 50 > WARNING: WITNESS option enabled, expect reduced performance. > Root mount waiting for: usbus7 usbus3 > Root mount waiting for: usbus7 usbus3 > uhub3: 6 ports with 6 removable, self powered > uhub7: 6 ports with 6 removable, self powered > ugen3.2: at usbus3 > umass0: 2> on usbus3 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > Root mount waiting for: usbus3 > umass0:1:0:-1: Attached to scbus1 > (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? > GEOM: new disk da0pass0 at umass-sim0 bus 0 target 0 lun 0 > > pass0: Removable Direct Access SCSI-0 device > pass0: 40.000MB/s transfers > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 3859MB (7905279 512 byte sectors: 255H 63S/T 492C) > Trying to mount root from zfs:alert > ugen5.2: at usbus5 > ukbd0: 2> on usbus5 > kbd: new array size 4 > kbd1 at ukbd0 > kbd1: ukbd0, generic (0), config:0x0, flags:0x3d0000 > ugen2.2: at usbus2 > ct_to_ts([2009-07-09 12:36:12]) = 1247142972.000000000 > start_init: trying /sbin/init > lock order reversal: > 1st 0xffffffff80815040 pf task mtx (pf task mtx) @ > /usr/src/sys/contrib/pf/net/pf_ioctl.c:1394 > 2nd 0xffffffff809f7b40 ifnet (ifnet) @ /usr/src/sys/net/if.c:1887 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7d2 > _rw_rlock() at _rw_rlock+0x60 > ifunit() at ifunit+0x22 > pfioctl() at pfioctl+0x20ea > devfs_ioctl_f() at devfs_ioctl_f+0x6e > kern_ioctl() at kern_ioctl+0xbc > ioctl() at ioctl+0xf0 > syscall() at syscall+0x18b > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80098a88c, rsp = > 0x7fffffffb5c8, rbp = 0x7fffffffb710 --- > lock order reversal: > 1st 0xffffff0074026098 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1054 > 2nd 0xffffff007417dba8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7d2 > __lockmgr_args() at __lockmgr_args+0xc92 > vop_stdlock() at vop_stdlock+0x39 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xc2 > _vn_lock() at _vn_lock+0x50 > vget() at vget+0x6c > devfs_allocv() at devfs_allocv+0xee > devfs_root() at devfs_root+0x41 > vfs_donmount() at vfs_donmount+0xf93 > nmount() at nmount+0x74 > syscall() at syscall+0x18b > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007aaffc, rsp = > 0x7fffffffdd28, rbp = 0x800a04048 --- > > Thanks, > > Chris > -- > @chrisattack > ----------------------------------------- > http://twitter.com/chrisattack > http://chrisattack.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 avg at freebsd.org Thu Jul 9 18:43:40 2009 From: avg at freebsd.org (Andriy Gapon) Date: Thu Jul 9 18:43:47 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: References: <4A562960.3010801@freebsd.org> Message-ID: <4A563A57.8090907@freebsd.org> on 09/07/2009 21:02 Marius N?nnerich said the following: > What about atomically changing tsc_freq every time the frequency is changed? This is what actually does happen, but it doesn't help. Say, there is a moment T1 when TSC has value N and tsc_freq is X, and moment T2 when when TSC value (N + 1) and tsc_freq is 10*X. So the formula gives: t1 = N / X t2 = (N+1) / (10*X) -- Andriy Gapon From andreast-list at fgznet.ch Thu Jul 9 18:52:33 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Thu Jul 9 18:52:40 2009 Subject: FreeBSD 8.0-BETA1 Available In-Reply-To: <1247107223.31816.7.camel@bauer.cse.buffalo.edu> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> <1247107223.31816.7.camel@bauer.cse.buffalo.edu> Message-ID: <4A563C65.20402@fgznet.ch> Ken Smith wrote: > On Wed, 2009-07-08 at 22:01 +0200, Andreas Tobler wrote: >> I was successful in installing the image, although, a few packages did >> not install. I did a kern developer package. I guess the packages are >> missing on the .img? > > Correct, no packages with BETA1. It's probably the documentation > packages it went looking for and couldn't find. I'll be providing at > least the docs packages with BETA2. Not sure if I'll start trying to > provide a larger set of packages for the DVD or wait for BETA3 for that > (leaning towards waiting at the moment). Ok, that means no doc/dict/docproj/man/ports/src (and the ones I didn't choose) in the BETA1? I did the install again with a real stick and everything went fine besides not finding the above packages. Thanks, Andreas From das at FreeBSD.ORG Thu Jul 9 19:55:30 2009 From: das at FreeBSD.ORG (David Schultz) Date: Thu Jul 9 19:55:37 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: <4A562960.3010801@freebsd.org> References: <4A562960.3010801@freebsd.org> Message-ID: <20090709193932.GA54408@zim.MIT.EDU> On Thu, Jul 09, 2009, Andriy Gapon wrote: > > As you might be aware DTrace timestamps right now are derived from TSC value. > http://en.wikipedia.org/wiki/Time_Stamp_Counter > > DTrace timestamps are measured in nano-seconds and the formula similar to the > following is used for calculations: > rdtsc() * 1000000000 / tsc_freq > where rdtsc is a function that returns current TSC value and tsc_freq is a > frequency of TSC. > > This formula is supposed to produce proper results if tsc_freq stays constant. > But there are environment where this might not be the case. > If a CPU has a non-invariant TSC and processor's clock frequency changes (e.g. > because of powerd), then tsc_freq changes too. > As a result, the formula would produce wildly different values and, most > importantly, was values would non be monotonic. Timestamp values that jump back > and forth would not only be useless for a user, they would also confuse DTrace > internal logic. Doesn't Solaris DTRT and compensate for TSC frequency changes? Why can't we do the same thing? From brampton+freebsd at gmail.com Thu Jul 9 22:26:15 2009 From: brampton+freebsd at gmail.com (Andrew Brampton) Date: Thu Jul 9 22:26:25 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: <4A562960.3010801@freebsd.org> References: <4A562960.3010801@freebsd.org> Message-ID: 2009/7/9 Andriy Gapon : > > > There are at least the following two alternatives: > > 1. Keep things as they are and warn users not to change CPU clock frequency when > they use DTrace and the CPU doesn't have invariant TSC. I think that this should > cause only minor inconveniences to a portion of DTrace users. > > 2. Use raw TSC value as a DTrace timestamp and document this difference from the > original DTrace. Advantage: timestamp value is always monotonic. Disadvantage: > manual conversion is needed to get "real" time (using the same formula). > Please note that in this case timestamps would be in non-linear time dimension if > TSC frequency changes, so to get meaningful timestamps (when needed/important) one > would still have to make sure that TSC frequency stay constant. > According to wikipedia newer Intel processors have a constant rate TSC whos freq does not change. If this features is available on most processors today, then I am happy to stick with option 1. Another problem with this is that on a multicore machine each core may have different TSC values. Has anyone thought how to address this issue? Could we calculate the offset of each core from core0, and then ensure the offset is applied to the tsc value when it is needed? thanks Andrew From kensmith at cse.Buffalo.EDU Thu Jul 9 23:12:32 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Thu Jul 9 23:12:39 2009 Subject: USB stick installation problems In-Reply-To: References: <4A559E50.3090408@bsdunix.ch> Message-ID: <1247179202.9053.39.camel@neo.cse.buffalo.edu> On Thu, 2009-07-09 at 09:13 -0700, Randi Harper wrote: > On Thu, Jul 9, 2009 at 12:37 AM, Thomas Vogt wrote: > > > Hi > > > > I download and copied 8.0-BETA1-amd64-memstick.img to an usb stick as > > described at > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051018.html. > > > > I can boot it and sysinstall runs fine. Later i chose USB stick as > > install medium but then i get a "no USB stick found" error. Is this an > > know bug? > > > > Regards, > > Thomas > > Possibly. Can you please tell sysinstall to rescan devices or restart the > sysinstall process and tell me if that makes a difference? > > -- randi Expanding on this slightly - I did have this problem on one of the machines I tested with. What Randi means by having sysinstall rescan devices is go into the "Options" section. Inside the Options Editor on the right side column there is an entry for "Re-scan Devices". Please use that and then try a normal install. That seemed to work for me on the one machine I had this glitch with. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090709/6048c11c/attachment.pgp From jfvogel at gmail.com Fri Jul 10 00:13:36 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Jul 10 00:13:46 2009 Subject: no em0 with r195477 In-Reply-To: <2a41acea0907091135j12f4c0efn963859f8def1d9cd@mail.gmail.com> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> <20090709153940.4544bfa8.stas@FreeBSD.org> <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> <2a41acea0907091135j12f4c0efn963859f8def1d9cd@mail.gmail.com> Message-ID: <2a41acea0907091713v6291f7dbt33b61c10ee7db893@mail.gmail.com> I have tried to reproduce this and cannot, can you tell me more details about this hardware, is it off-the-shelf or something non-production, etc etc. Did an install of a stock ICH9 system with this NIC, and have seen no such checksum failure, everything works fine :( Jack On Thu, Jul 9, 2009 at 11:35 AM, Jack Vogel wrote: > I am looking into this, thanks for the report. > > Jack > > > > On Thu, Jul 9, 2009 at 10:52 AM, Chris Ruiz wrote: > >> On Thu, Jul 9, 2009 at 6:39 AM, Stanislav Sedov wrote: >> > On Wed, 8 Jul 2009 22:58:27 -0500 >> > Chris Ruiz mentioned: >> > >> >> i just upgraded from r194562 to r195477 in order to test BETA1 and my >> >> e1000 adapter no longer attaching to the driver. >> >> >> >> pciconf -lv output >> >> >> >> em0@pci0:0:25:0: class=0x020000 card=0x00018086 chip=0x10bd8086 >> >> rev=0x02 hdr=0x00 >> >> vendor = 'Intel Corporation' >> >> device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' >> >> class = network >> >> subclass = ethernet >> >> >> >> here's a quick list of relevant commits since my last kernel build: >> >> r195409, r195168, r195049, r194979, r194925, r194911, r194865. >> >> >> > >> > Hi, Chris! >> > >> > Can you provide the verbose boot log? >> >> Turns out it's caused by the driver thinking the EEPROM checksum is >> invalid. Here's a verbose 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-BETA1 #0 r195483: Wed Jul 8 21:51:57 CDT 2009 >> root@attack.young-alumni.com:/usr/obj/usr/src/sys/FAILWHALE >> WARNING: WITNESS option enabled, expect reduced performance. >> Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80dce000. >> Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff80dce2b0. >> Preloaded elf obj module "/boot/kernel/opensolaris.ko" at >> 0xffffffff80dce958. >> Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at >> 0xffffffff80dcef88. >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Calibrating TSC clock ... TSC clock: 3001458636 Hz >> CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (3001.46-MHz K8-class >> CPU) >> Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 >> >> Features=0xbfebfbff >> Features2=0xe3f5 >> AMD Features=0x20100800 >> AMD Features2=0x1 >> TSC: P-state invariant >> real memory = 8589934592 (8192 MB) >> Physical memory chunk(s): >> 0x0000000000001000 - 0x0000000000040fff, 262144 bytes (64 pages) >> 0x0000000000051000 - 0x0000000000099fff, 299008 bytes (73 pages) >> 0x0000000000e01000 - 0x00000000cdbcbfff, 3437015040 bytes (839115 pages) >> 0x00000000cdc9a000 - 0x00000000ceec4fff, 19050496 bytes (4651 pages) >> 0x00000000ceec7000 - 0x00000000cef79fff, 733184 bytes (179 pages) >> 0x00000000cefe5000 - 0x00000000cefe5fff, 4096 bytes (1 pages) >> 0x00000000ceff2000 - 0x00000000ceff2fff, 4096 bytes (1 pages) >> 0x00000000cefff000 - 0x00000000ceffffff, 4096 bytes (1 pages) >> 0x0000000100000000 - 0x000000021cbf3fff, 4777263104 bytes (1166324 pages) >> avail memory = 8192516096 (7812 MB) >> ACPI APIC Table: >> INTR: Adding local APIC 1 as a target >> 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 >> APIC: CPU 0 has ACPI ID 1 >> APIC: CPU 1 has ACPI ID 2 >> ULE: setup cpu 0 >> ULE: setup cpu 1 >> This module (opensolaris) contains code covered by the >> Common Development and Distribution License (CDDL) >> see http://opensolaris.org/os/licensing/opensolaris_license/ >> ACPI: RSDP 0xfe020 00014 (v0 INTEL ) >> ACPI: RSDT 0xceffd038 00070 (v1 INTEL DQ3510J 000003BA 01000013) >> ACPI: FACP 0xceffc000 00074 (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: DSDT 0xceff8000 03D6A (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: FACS 0xcef87000 00040 >> ACPI: APIC 0xceff7000 00078 (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: WDDT 0xceff6000 00040 (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: MCFG 0xceff5000 0003C (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: ASF! 0xceff4000 000A6 (v32 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: HPET 0xceff3000 00038 (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: DMAR 0xceff1000 000F8 (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: ASPT 0xceff0000 0002C (v3 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: WDTT 0xcefef000 002CC (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefee000 00204 (v1 INTEL CpuPm 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefed000 001F9 (v1 INTEL Cpu0Ist 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefec000 001F9 (v1 INTEL Cpu1Ist 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefeb000 001F9 (v1 INTEL Cpu2Ist 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefea000 001F9 (v1 INTEL Cpu3Ist 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefe9000 000DD (v1 INTEL Cpu0Cst 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefe8000 000DD (v1 INTEL Cpu1Cst 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefe7000 000DD (v1 INTEL Cpu2Cst 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefe6000 000DD (v1 INTEL Cpu3Cst 000003BA MSFT 01000013) >> ACPI: TCPA 0xcef7b000 00032 (v2 INTEL TIANO 00000002 MSFT 01000013) >> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 >> ioapic0: Changing APIC ID to 2 >> ioapic0: Routing external 8259A's -> intpin 0 >> MADT: Interrupt override: source 0, irq 2 >> ioapic0: Routing IRQ 0 -> intpin 2 >> MADT: Interrupt override: source 9, irq 9 >> ioapic0: intpin 9 trigger: level >> lapic0: Routing NMI -> LINT1 >> lapic0: LINT1 trigger: edge >> lapic0: LINT1 polarity: high >> lapic1: Routing NMI -> LINT1 >> lapic1: LINT1 trigger: edge >> lapic1: LINT1 polarity: high >> ioapic0 irqs 0-23 on motherboard >> cpu0 BSP: >> ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff >> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >> timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 >> wlan: <802.11 Link Layer> >> ichwd module loaded >> io: >> kbd0 at kbdmux0 >> mem: >> nfslock: pseudo-device >> null: >> random: >> acpi0: on motherboard >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >> acpi0: [MPSAFE] >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: wakeup code va 0xffffff8000011000 pa 0x4000 >> acpi_bus_number: root bus has no _BBN, assuming 0 >> AcpiOsDerivePciId: \\_SB_.PCI0.TMEM -> bus 0 dev 0 func 0 >> acpi_bus_number: root bus has no _BBN, assuming 0 >> AcpiOsDerivePciId: \\_SB_.PCI0.PAMX -> bus 0 dev 0 func 0 >> acpi_bus_number: root bus has no _BBN, assuming 0 >> AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR0 -> bus 0 dev 31 func 0 >> acpi_bus_number: root bus has no _BBN, assuming 0 >> AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR1 -> bus 0 dev 31 func 0 >> acpi_bus_number: root bus has no _BBN, assuming 0 >> AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.IELK.ELR0 -> bus 0 dev 0 func 0 >> ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >> pci_link0: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 >> Validation 0 11 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link1: Index IRQ Rtd Ref IRQs >> Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 >> Validation 0 10 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link2: Index IRQ Rtd Ref IRQs >> Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 >> Validation 0 9 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link3: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 >> Validation 0 11 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link4: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 >> Validation 0 11 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link5: Index IRQ Rtd Ref IRQs >> Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 >> Validation 0 9 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link6: Index IRQ Rtd Ref IRQs >> Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 >> Validation 0 10 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link7: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 >> Validation 0 11 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on >> acpi0 >> acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route >> 64-bit >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> acpi_button0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pci0: domain=0, physical bus=0 >> found-> vendor=0x8086, dev=0x29b0, revid=0x02 >> domain=0, bus=0, slot=0, func=0 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x8086, dev=0x29b2, revid=0x02 >> domain=0, bus=0, slot=2, func=0 >> class=03-00-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> map[10]: type Memory, range 32, base 0xe0380000, size 19, enabled >> map[14]: type I/O Port, range 32, base 0x2458, size 3, enabled >> map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size >> 28, enabled >> map[1c]: type Memory, range 32, base 0xe0200000, size 20, enabled >> pcib0: matched entry for 0.2.INTA >> pcib0: slot 2 INTA hardwired to IRQ 16 >> found-> vendor=0x8086, dev=0x29b3, revid=0x02 >> domain=0, bus=0, slot=2, func=1 >> class=03-80-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> powerspec 2 supports D0 D3 current D0 >> map[10]: type Memory, range 32, base 0xe0300000, size 19, enabled >> found-> vendor=0x8086, dev=0x29b4, revid=0x02 >> domain=0, bus=0, slot=3, func=0 >> class=07-80-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0006, statreg=0x0018, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type Memory, range 64, base 0xe0427100, size 4, enabled >> pcib0: matched entry for 0.3.INTA >> pcib0: slot 3 INTA hardwired to IRQ 16 >> found-> vendor=0x8086, dev=0x29b6, revid=0x02 >> domain=0, bus=0, slot=3, func=2 >> class=01-01-85, hdrtype=0x00, mfdev=0 >> cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=9 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type I/O Port, range 32, base 0x2450, size 3, enabled >> map[14]: type I/O Port, range 32, base 0x246c, size 2, enabled >> map[18]: type I/O Port, range 32, base 0x2448, size 3, enabled >> map[1c]: type I/O Port, range 32, base 0x2468, size 2, enabled >> map[20]: type I/O Port, range 32, base 0x2420, size 4, enabled >> pcib0: matched entry for 0.3.INTC >> pcib0: slot 3 INTC hardwired to IRQ 18 >> found-> vendor=0x8086, dev=0x29b7, revid=0x02 >> domain=0, bus=0, slot=3, func=3 >> class=07-00-02, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=10 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type I/O Port, range 32, base 0x2440, size 3, enabled >> map[14]: type Memory, range 32, base 0xe0425000, size 12, enabled >> pcib0: matched entry for 0.3.INTB >> pcib0: slot 3 INTB hardwired to IRQ 17 >> found-> vendor=0x8086, dev=0x10bd, revid=0x02 >> domain=0, bus=0, slot=25, func=0 >> class=02-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type Memory, range 32, base 0xe0400000, size 17, enabled >> map[14]: type Memory, range 32, base 0xe0424000, size 12, enabled >> map[18]: type I/O Port, range 32, base 0x2400, size 5, enabled >> pcib0: matched entry for 0.25.INTA >> pcib0: slot 25 INTA hardwired to IRQ 20 >> found-> vendor=0x8086, dev=0x2937, revid=0x02 >> domain=0, bus=0, slot=26, func=0 >> class=0c-03-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=9 >> map[20]: type I/O Port, range 32, base 0x20e0, size 5, enabled >> pcib0: matched entry for 0.26.INTA >> pcib0: slot 26 INTA hardwired to IRQ 18 >> found-> vendor=0x8086, dev=0x2938, revid=0x02 >> domain=0, bus=0, slot=26, func=1 >> class=0c-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=9 >> map[20]: type I/O Port, range 32, base 0x20c0, size 5, enabled >> pcib0: matched entry for 0.26.INTB >> pcib0: slot 26 INTB hardwired to IRQ 21 >> found-> vendor=0x8086, dev=0x2939, revid=0x02 >> domain=0, bus=0, slot=26, func=2 >> class=0c-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=10 >> map[20]: type I/O Port, range 32, base 0x20a0, size 5, enabled >> pcib0: matched entry for 0.26.INTC >> pcib0: slot 26 INTC hardwired to IRQ 17 >> found-> vendor=0x8086, dev=0x293c, revid=0x02 >> domain=0, bus=0, slot=26, func=7 >> class=0c-03-20, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=10 >> powerspec 2 supports D0 D3 current D0 >> map[10]: type Memory, range 32, base 0xe0426c00, size 10, enabled >> pcib0: matched entry for 0.26.INTC >> pcib0: slot 26 INTC hardwired to IRQ 17 >> found-> vendor=0x8086, dev=0x293e, revid=0x02 >> domain=0, bus=0, slot=27, func=0 >> class=04-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=10 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type Memory, range 64, base 0xe0420000, size 14, enabled >> pcib0: matched entry for 0.27.INTA >> pcib0: slot 27 INTA hardwired to IRQ 22 >> found-> vendor=0x8086, dev=0x2940, revid=0x02 >> domain=0, bus=0, slot=28, func=0 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=255 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> found-> vendor=0x8086, dev=0x2942, revid=0x02 >> domain=0, bus=0, slot=28, func=1 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=255 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> found-> vendor=0x8086, dev=0x2944, revid=0x02 >> domain=0, bus=0, slot=28, func=2 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=255 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> found-> vendor=0x8086, dev=0x2946, revid=0x02 >> domain=0, bus=0, slot=28, func=3 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=d, irq=255 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> found-> vendor=0x8086, dev=0x2948, revid=0x02 >> domain=0, bus=0, slot=28, func=4 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=255 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> found-> vendor=0x8086, dev=0x2934, revid=0x02 >> domain=0, bus=0, slot=29, func=0 >> class=0c-03-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> map[20]: type I/O Port, range 32, base 0x2080, size 5, enabled >> pcib0: matched entry for 0.29.INTA >> pcib0: slot 29 INTA hardwired to IRQ 23 >> found-> vendor=0x8086, dev=0x2935, revid=0x02 >> domain=0, bus=0, slot=29, func=1 >> class=0c-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=11 >> map[20]: type I/O Port, range 32, base 0x2060, size 5, enabled >> pcib0: matched entry for 0.29.INTB >> pcib0: slot 29 INTB hardwired to IRQ 19 >> found-> vendor=0x8086, dev=0x2936, revid=0x02 >> domain=0, bus=0, slot=29, func=2 >> class=0c-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=9 >> map[20]: type I/O Port, range 32, base 0x2040, size 5, enabled >> pcib0: matched entry for 0.29.INTC >> pcib0: slot 29 INTC hardwired to IRQ 18 >> found-> vendor=0x8086, dev=0x293a, revid=0x02 >> domain=0, bus=0, slot=29, func=7 >> class=0c-03-20, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D3 current D0 >> map[10]: type Memory, range 32, base 0xe0426800, size 10, enabled >> pcib0: matched entry for 0.29.INTA >> pcib0: slot 29 INTA hardwired to IRQ 23 >> found-> vendor=0x8086, dev=0x244e, revid=0x92 >> domain=0, bus=0, slot=30, func=0 >> class=06-04-01, hdrtype=0x01, mfdev=0 >> cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x8086, dev=0x2914, revid=0x02 >> domain=0, bus=0, slot=31, func=0 >> class=06-01-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x8086, dev=0x2922, revid=0x02 >> domain=0, bus=0, slot=31, func=2 >> class=01-06-01, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=9 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 16 messages >> map[10]: type I/O Port, range 32, base 0x2438, size 3, enabled >> map[14]: type I/O Port, range 32, base 0x2464, size 2, enabled >> map[18]: type I/O Port, range 32, base 0x2430, size 3, enabled >> map[1c]: type I/O Port, range 32, base 0x2460, size 2, enabled >> map[20]: type I/O Port, range 32, base 0x2020, size 5, enabled >> map[24]: type Memory, range 32, base 0xe0426000, size 11, enabled >> pcib0: matched entry for 0.31.INTA >> pcib0: slot 31 INTA hardwired to IRQ 21 >> found-> vendor=0x8086, dev=0x2930, revid=0x02 >> domain=0, bus=0, slot=31, func=3 >> class=0c-05-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=9 >> map[10]: type Memory, range 64, base 0xe0427000, size 8, enabled >> map[20]: type I/O Port, range 32, base 0x2000, size 5, enabled >> pcib0: matched entry for 0.31.INTB >> pcib0: slot 31 INTB hardwired to IRQ 18 >> vgapci0: port 0x2458-0x245f mem >> 0xe0380000-0xe03fffff,0xd0000000-0xdfffffff,0xe0200000-0xe02fffff irq >> 16 at device 2.0 on pci0 >> agp0: on vgapci0 >> vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 >> vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xe0380000 >> vgapci0: Reserved 0x100000 bytes for rid 0x1c type 3 at 0xe0200000 >> agp0: detected 6140k stolen memory >> agp0: aperture size is 256M >> vgapci1: mem 0xe0300000-0xe037ffff at device >> 2.1 on pci0 >> pci0: at device 3.0 (no driver attached) >> atapci0: port >> 0x2450-0x2457,0x246c-0x246f,0x2448-0x244f,0x2468-0x246b,0x2420-0x242f >> irq 18 at device 3.2 on pci0 >> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x2420 >> ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 49 >> atapci0: [MPSAFE] >> atapci0: [ITHREAD] >> ata2: on atapci0 >> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x2450 >> atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x246c >> ata2: reset tp1 mask=03 ostat0=7f ostat1=7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: reset tp2 stat0=ff stat1=ff devices=0x0 >> ata2: [MPSAFE] >> ata2: [ITHREAD] >> ata3: on atapci0 >> atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x2448 >> atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0x2468 >> ata3: reset tp1 mask=03 ostat0=7f ostat1=7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: reset tp2 stat0=ff stat1=ff devices=0x0 >> ata3: [MPSAFE] >> ata3: [ITHREAD] >> pci0: at device 3.3 (no driver attached) >> em0: port 0x2400-0x241f >> mem 0xe0400000-0xe041ffff,0xe0424000-0xe0424fff irq 20 at device 25.0 >> on pci0 >> em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xe0400000 >> em0: attempting to allocate 1 MSI vectors (1 supported) >> msi: routing MSI IRQ 256 to local APIC 0 vector 50 >> em0: using IRQ 256 for MSI >> em0: Using MSI interrupt >> em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xe0424000 >> em0: The EEPROM Checksum Is Not Valid >> device_attach: em0 attach returned 5 >> uhci0: port 0x20e0-0x20ff irq 18 >> at device 26.0 on pci0 >> uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20e0 >> uhci0: [MPSAFE] >> uhci0: [ITHREAD] >> uhci0: LegSup = 0x0f10 >> usbus0: on uhci0 >> uhci1: port 0x20c0-0x20df irq 21 >> at device 26.1 on pci0 >> uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20c0 >> ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 >> uhci1: [MPSAFE] >> uhci1: [ITHREAD] >> uhci1: LegSup = 0x0f10 >> usbus1: on uhci1 >> uhci2: port 0x20a0-0x20bf irq 17 >> at device 26.2 on pci0 >> uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20a0 >> ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 51 >> uhci2: [MPSAFE] >> uhci2: [ITHREAD] >> uhci2: LegSup = 0x0f10 >> usbus2: on uhci2 >> ehci0: mem >> 0xe0426c00-0xe0426fff irq 17 at device 26.7 on pci0 >> ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426c00 >> ehci0: [MPSAFE] >> ehci0: [ITHREAD] >> usbus3: EHCI version 1.0 >> usbus3: on ehci0 >> pci0: at device 27.0 (no driver attached) >> pcib1: at device 28.0 on pci0 >> pcib1: domain 0 >> pcib1: secondary bus 1 >> pcib1: subordinate bus 1 >> pcib1: I/O decode 0x0-0x0 >> pcib1: no prefetched decode >> pci1: on pcib1 >> pci1: domain=0, physical bus=1 >> pcib2: at device 28.1 on pci0 >> pcib2: domain 0 >> pcib2: secondary bus 2 >> pcib2: subordinate bus 2 >> pcib2: I/O decode 0x0-0x0 >> pcib2: no prefetched decode >> pci2: on pcib2 >> pci2: domain=0, physical bus=2 >> pcib3: at device 28.2 on pci0 >> pcib3: domain 0 >> pcib3: secondary bus 3 >> pcib3: subordinate bus 3 >> pcib3: I/O decode 0x1000-0x1fff >> pcib3: memory decode 0xe0100000-0xe01fffff >> pcib3: no prefetched decode >> pci3: on pcib3 >> pci3: domain=0, physical bus=3 >> found-> vendor=0x11ab, dev=0x6101, revid=0xb1 >> domain=0, bus=3, slot=0, func=0 >> class=01-01-8f, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=9 >> powerspec 2 supports D0 D1 D3 current D0 >> MSI supports 1 message >> map[10]: type I/O Port, range 32, base 0x1018, size 3, enabled >> pcib3: requested I/O range 0x1018-0x101f: in range >> map[14]: type I/O Port, range 32, base 0x1024, size 2, enabled >> pcib3: requested I/O range 0x1024-0x1027: in range >> map[18]: type I/O Port, range 32, base 0x1010, size 3, enabled >> pcib3: requested I/O range 0x1010-0x1017: in range >> map[1c]: type I/O Port, range 32, base 0x1020, size 2, enabled >> pcib3: requested I/O range 0x1020-0x1023: in range >> map[20]: type I/O Port, range 32, base 0x1000, size 4, enabled >> pcib3: requested I/O range 0x1000-0x100f: in range >> map[24]: type Memory, range 32, base 0xe0100000, size 9, enabled >> pcib3: requested memory range 0xe0100000-0xe01001ff: good >> pcib3: matched entry for 3.0.INTA >> pcib3: slot 0 INTA hardwired to IRQ 18 >> atapci1: port >> 0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f >> mem 0xe0100000-0xe01001ff irq 18 at device 0.0 on pci3 >> atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1000 >> atapci1: [MPSAFE] >> atapci1: [ITHREAD] >> ata4: on atapci1 >> atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1018 >> atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x1024 >> ata4: reset tp1 mask=03 ostat0=50 ostat1=51 >> ata4: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb >> ata4: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb >> ata4: reset tp2 stat0=00 stat1=10 devices=0x30000 >> ata4: [MPSAFE] >> ata4: [ITHREAD] >> pcib4: at device 28.3 on pci0 >> pcib4: domain 0 >> pcib4: secondary bus 4 >> pcib4: subordinate bus 4 >> pcib4: I/O decode 0x0-0x0 >> pcib4: no prefetched decode >> pci4: on pcib4 >> pci4: domain=0, physical bus=4 >> pcib5: at device 28.4 on pci0 >> pcib5: domain 0 >> pcib5: secondary bus 5 >> pcib5: subordinate bus 5 >> pcib5: I/O decode 0x0-0x0 >> pcib5: no prefetched decode >> pci5: on pcib5 >> pci5: domain=0, physical bus=5 >> uhci3: port 0x2080-0x209f irq 23 >> at device 29.0 on pci0 >> uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2080 >> ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 52 >> uhci3: [MPSAFE] >> uhci3: [ITHREAD] >> uhci3: LegSup = 0x0f10 >> usbus4: on uhci3 >> uhci4: port 0x2060-0x207f irq 19 >> at device 29.1 on pci0 >> uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2060 >> ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 53 >> uhci4: [MPSAFE] >> uhci4: [ITHREAD] >> uhci4: LegSup = 0x0f10 >> usbus5: on uhci4 >> uhci5: port 0x2040-0x205f irq 18 >> at device 29.2 on pci0 >> uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040 >> uhci5: [MPSAFE] >> uhci5: [ITHREAD] >> uhci5: LegSup = 0x0f10 >> usbus6: on uhci5 >> ehci1: mem >> 0xe0426800-0xe0426bff irq 23 at device 29.7 on pci0 >> ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426800 >> ehci1: [MPSAFE] >> ehci1: [ITHREAD] >> usbus7: EHCI version 1.0 >> usbus7: on ehci1 >> pcib6: at device 30.0 on pci0 >> pcib6: domain 0 >> pcib6: secondary bus 6 >> pcib6: subordinate bus 6 >> pcib6: I/O decode 0xf000-0xfff >> pcib6: memory decode 0xe0000000-0xe00fffff >> pcib6: no prefetched decode >> pcib6: Subtractively decoded bridge. >> pci6: on pcib6 >> pci6: domain=0, physical bus=6 >> found-> vendor=0x168c, dev=0x0013, revid=0x01 >> domain=0, bus=6, slot=0, func=0 >> class=02-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0216, statreg=0x0290, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 >> ns) >> intpin=a, irq=9 >> powerspec 2 supports D0 D3 current D0 >> map[10]: type Memory, range 32, base 0xe0000000, size 16, enabled >> pcib6: requested memory range 0xe0000000-0xe000ffff: good >> pcib6: matched entry for 6.0.INTA >> pcib6: slot 0 INTA hardwired to IRQ 21 >> found-> vendor=0x11c1, dev=0x5811, revid=0x70 >> domain=0, bus=6, slot=3, func=0 >> class=0c-00-10, hdrtype=0x00, mfdev=0 >> cmdreg=0x0216, statreg=0x0290, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x0c (3000 ns), maxlat=0x18 (6000 >> ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> map[10]: type Memory, range 32, base 0xe0010000, size 12, enabled >> pcib6: requested memory range 0xe0010000-0xe0010fff: good >> pcib6: matched entry for 6.3.INTA >> pcib6: slot 3 INTA hardwired to IRQ 19 >> ath0: mem 0xe0000000-0xe000ffff irq 21 at device 0.0 on >> pci6 >> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xe0000000 >> ath0: [MPSAFE] >> ath0: [ITHREAD] >> ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >> ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps >> 24Mbps 36Mbps 48Mbps 54Mbps >> ath0: turboG rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps >> 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps >> ath0: AR2413 mac 7.9 RF2413 phy 4.5 >> ath0: Use hw queue 1 for WME_AC_BE traffic >> ath0: Use hw queue 0 for WME_AC_BK traffic >> ath0: Use hw queue 2 for WME_AC_VI traffic >> ath0: Use hw queue 3 for WME_AC_VO traffic >> ath0: Use hw queue 8 for CAB traffic >> ath0: Use hw queue 9 for beacons >> fwohci0: mem 0xe0010000-0xe0010fff irq 19 at device >> 3.0 on pci6 >> fwohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe0010000 >> fwohci0: [MPSAFE] >> fwohci0: [ITHREAD] >> fwohci0: OHCI version 1.0 (ROM=0) >> fwohci0: No. of Isochronous channels is 8. >> fwohci0: EUI64 00:90:27:00:01:d0:dc:04 >> fwohci0: Phy 1394a available S400, 2 ports. >> fwohci0: Link S400, max_rec 2048 bytes. >> firewire0: on fwohci0 >> dcons_crom0: on firewire0 >> dcons_crom0: bus_addr 0x41000 >> sbp0: on firewire0 >> fwohci0: Initiate bus reset >> fwohci0: fwohci_intr_core: BUS reset >> fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=2, CYCLEMASTER >> mode >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci2: port >> 0x2438-0x243f,0x2464-0x2467,0x2430-0x2437,0x2460-0x2463,0x2020-0x203f >> mem 0xe0426000-0xe04267ff irq 21 at device 31.2 on pci0 >> atapci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2020 >> atapci2: [MPSAFE] >> atapci2: [ITHREAD] >> atapci2: Reserved 0x800 bytes for rid 0x24 type 3 at 0xe0426000 >> atapci2: AHCI called from vendor specific driver >> atapci2: AHCI v1.20 controller with 6 3Gbps ports, PM supported >> atapci2: Caps: 64bit NCQ SNTF ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd >> CCC EM 6ports >> ata5: on atapci2 >> ata5: AHCI reset... >> ata5: hardware reset ... >> ata5: SATA connect time=0ms status=00000123 >> ata5: ready wait time=14ms >> ata5: software reset port 15... >> ata5: ready wait time=0ms >> ata5: SIGNATURE: 00000101 >> ata5: AHCI reset done: devices=00000001 >> ata5: [MPSAFE] >> ata5: [ITHREAD] >> ata6: on atapci2 >> ata6: AHCI reset... >> ata6: hardware reset ... >> ata6: SATA connect time=0ms status=00000123 >> ata6: ready wait time=49ms >> ata6: software reset port 15... >> ata6: ready wait time=0ms >> ata6: SIGNATURE: 00000101 >> ata6: AHCI reset done: devices=00000001 >> ata6: [MPSAFE] >> ata6: [ITHREAD] >> ata7: on atapci2 >> ata7: AHCI reset... >> ata7: hardware reset ... >> ata7: SATA connect time=0ms status=00000123 >> ata7: ready wait time=26ms >> ata7: software reset port 15... >> ata7: ready wait time=0ms >> ata7: SIGNATURE: 00000101 >> ata7: AHCI reset done: devices=00000001 >> ata7: [MPSAFE] >> ata7: [ITHREAD] >> ata8: on atapci2 >> ata8: AHCI reset... >> ata8: hardware reset ... >> ata8: SATA connect timeout status=00000000 >> ata8: AHCI reset done: phy reset found no device >> ata8: [MPSAFE] >> ata8: [ITHREAD] >> ata9: on atapci2 >> ata9: AHCI reset... >> ata9: hardware reset ... >> ata9: SATA connect time=0ms status=00000123 >> ata9: ready wait time=22ms >> ata9: software reset port 15... >> ata9: ready wait time=0ms >> ata9: SIGNATURE: 00000101 >> ata9: AHCI reset done: devices=00000001 >> ata9: [MPSAFE] >> ata9: [ITHREAD] >> ata10: on atapci2 >> ata10: AHCI reset... >> ata10: hardware reset ... >> ata10: SATA connect time=0ms status=00000123 >> ata10: ready wait time=22ms >> ata10: software reset port 15... >> ata10: ready wait time=0ms >> ata10: SIGNATURE: 00000101 >> ata10: AHCI reset done: devices=00000001 >> ata10: [MPSAFE] >> ata10: [ITHREAD] >> ichsmb0: port 0x2000-0x201f mem >> 0xe0427000-0xe04270ff irq 18 at device 31.3 on pci0 >> ichsmb0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2000 >> ichsmb0: [MPSAFE] >> ichsmb0: [ITHREAD] >> smbus0: on ichsmb0 >> smb0: on smbus0 >> atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 >> atrtc0: registered as a time-of-day clock (resolution 1000000us) >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 54 >> uart0: [FILTER] >> uart0: fast interrupt >> uart0: console (115200,n,8,1) >> cpu0: on acpi0 >> coretemp0: on cpu0 >> est0: on cpu0 >> est0: Invalid id16 (set, cur) = (2086, 2346) >> est0: Invalid freq 2664, ignored. >> est0: Invalid id16 (set, cur) = (1826, 2346) >> est0: Invalid freq 2331, ignored. >> est0: Invalid id16 (set, cur) = (1565, 2346) >> est0: Invalid freq 1998, ignored. >> p4tcc0: on cpu0 >> cpu1: on acpi0 >> coretemp1: on cpu1 >> est1: on cpu1 >> est1: Invalid id16 (set, cur) = (2086, 2346) >> est1: Invalid freq 2664, ignored. >> est1: Invalid id16 (set, cur) = (1826, 2346) >> est1: Invalid freq 2331, ignored. >> est1: Invalid id16 (set, cur) = (1565, 2346) >> est1: Invalid freq 1998, ignored. >> p4tcc1: on cpu1 >> isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer >> isa_probe_children: disabling PnP devices >> ichwd0: on isa0 >> isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer >> ichwd0: Intel ICH9DO watchdog timer (ICH9 or equivalent) >> ichwd0: timer disabled >> atrtc: atrtc0 already exists; skipping it >> sc: sc0 already exists; skipping it >> uart: uart0 already exists; skipping it >> isa_probe_children: probing non-PnP devices >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> sc0: fb0, kbd0, terminal emulator: scteken (teken terminal) >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> atkbdc0 failed to probe at port 0x60 on isa0 >> fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 >> ppc0 failed to probe at irq 7 on isa0 >> uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 >> isa_probe_children: probing PnP devices >> Device configuration finished. >> Reducing kern.maxvnodes 508766 -> 100000 >> WARNING: ZFS is considered to be an experimental feature in FreeBSD. >> lapic: Divisor 2, Frequency 166747704 hz >> Timecounter "TSC" frequency 3001458636 Hz quality -100 >> Timecounters tick every 1.000 msec >> pflog0: bpf attached >> lo0: firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) >> firewire0: bus manager 1 >> bpf attached >> ata2: Identifying devices: 00000000 >> ata2: New devices: 00000000 >> ata3: Identifying devices: 00000000 >> ata3: New devices: 00000000 >> ata4: Identifying devices: 00030000 >> ata4: New devices: 00030000 >> 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 >> ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire >> ata4-slave: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire >> 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 >> ZFS filesystem version 13 >> ZFS storage pool version 13 >> acd0: DVDR drive at ata4 as master >> acd0: read 6890KB/s (6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, >> UDMA66 >> acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet >> acd0: Writes: CDR, CDRW, DVDR, test write, burnproof >> acd0: Audio: play, 256 volume levels >> acd0: Mechanism: ejectable tray, unlocked >> acd0: Medium: no/blank disc >> acd1: DMA limited to UDMA33, device found non-ATA66 cable >> acd1: DVDROM drive at ata4 as slave >> acd1: read 687KB/s (8251KB/s), 512KB buffer, UDMA33 >> acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet >> acd1: Writes: >> acd1: Audio: play, 256 volume levels >> acd1: Mechanism: ejectable tray, unlocked >> acd1: Medium: no/blank disc >> ata5: Identifying devices: 00000001 >> ata5: New devices: 00000001 >> ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad10: 476940MB at ata5-master SATA300 >> ad10: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> GEOM: new disk ad10 >> ad10: Intel check1 failed >> ad10: Adaptec check1 failed >> ad10: LSI (v3) check1 failed >> ad10: LSI (v2) check1 failed >> ad10: FreeBSD check1 failed >> ata6: Identifying devices: 00000001 >> ata6: New devices: 00000001 >> ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad12: 476940MB at ata6-master SATA300 >> ad12: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> GEOM: new disk ad12 >> firewire0: New S400 device ID:001f5bfffe2776a6 >> fwohci0: txd err= 3 miss Ack err >> ad12: Intel check1 failed >> ad12: Adaptec check1 failed >> ad12: LSI (v3) check1 failed >> ad12: LSI (v2) check1 failed >> ad12: FreeBSD check1 failed >> ata7: Identifying devices: 00000001 >> ata7: New devices: 00000001 >> ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad14: 238475MB at ata7-master SATA300 >> ad14: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> GEOM: new disk ad14 >> ad14: Intel check1 failed >> ad14: Adaptec check1 failed >> ad14: LSI (v3) check1 failed >> ad14: LSI (v2) check1 failed >> ad14: FreeBSD check1 failed >> ata8: Identifying devices: 00000000 >> ata8: New devices: 00000000 >> ata9: Identifying devices: 00000001 >> ata9: New devices: 00000001 >> ata9-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad18: 715404MB at ata9-master SATA300 >> ad18: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> GEOM: new disk ad18 >> ad18: Intel check1 failed >> uhub0: 2 ports with 2 removable, self powered >> uhub1: 2 ports with 2 removable, self powered >> uhub2: 2 ports with 2 removable, self powered >> ad18: Adaptec check1 failed >> uhub4: 2 ports with 2 removable, self powered >> ad18: LSI (v3) check1 failed >> uhub5: 2 ports with 2 removable, self powered >> uhub6: 2 ports with 2 removable, self powered >> ad18: LSI (v2) check1 failed >> ad18: FreeBSD check1 failed >> ata10: Identifying devices: 00000001 >> ata10: New devices: 00000001 >> ata10-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad20: 715404MB at ata10-master SATA300 >> ad20: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> GEOM: new disk ad20 >> ad20: Intel check1 failed >> ad20: Adaptec check1 failed >> ad20: LSI (v3) check1 failed >> ad20: LSI (v2) check1 failed >> ad20: FreeBSD check1 failed >> (probe0:sbp0:0:0:0): error 22 >> (probe0:sbp0:0:0:0): Unretryable Error >> (probe1:sbp0:0:1:0): error 22 >> (probe1:sbp0:0:1:0): Unretryable Error >> (probe2:sbp0:0:2:0): error 22 >> (probe2:sbp0:0:2:0): Unretryable Error >> (probe3:sbp0:0:3:0): error 22 >> (probe3:sbp0:0:3:0): Unretryable Error >> (probe4:sbp0:0:4:0): error 22 >> (probe4:sbp0:0:4:0): Unretryable Error >> (probe5:sbp0:0:5:0): error 22 >> (probe5:sbp0:0:5:0): Unretryable Error >> (probe6:sbp0:0:6:0): error 22 >> (probe6:sbp0:0:6:0): Unretryable Error >> ATA PseudoRAID loaded >> SMP: AP CPU #1 Launched! >> cpu1 AP: >> ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff >> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >> timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 >> ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 49 >> ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 1 vector 50 >> WARNING: WITNESS option enabled, expect reduced performance. >> Root mount waiting for: usbus7 usbus3 >> Root mount waiting for: usbus7 usbus3 >> uhub3: 6 ports with 6 removable, self powered >> uhub7: 6 ports with 6 removable, self powered >> ugen3.2: at usbus3 >> umass0: > 2> on usbus3 >> umass0: SCSI over Bulk-Only; quirks = 0x0000 >> Root mount waiting for: usbus3 >> umass0:1:0:-1: Attached to scbus1 >> (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? >> GEOM: new disk da0pass0 at umass-sim0 bus 0 target 0 lun 0 >> >> pass0: Removable Direct Access SCSI-0 device >> pass0: 40.000MB/s transfers >> da0 at umass-sim0 bus 0 target 0 lun 0 >> da0: Removable Direct Access SCSI-0 device >> da0: 40.000MB/s transfers >> da0: 3859MB (7905279 512 byte sectors: 255H 63S/T 492C) >> Trying to mount root from zfs:alert >> ugen5.2: at usbus5 >> ukbd0: > 2> on usbus5 >> kbd: new array size 4 >> kbd1 at ukbd0 >> kbd1: ukbd0, generic (0), config:0x0, flags:0x3d0000 >> ugen2.2: at usbus2 >> ct_to_ts([2009-07-09 12:36:12]) = 1247142972.000000000 >> start_init: trying /sbin/init >> lock order reversal: >> 1st 0xffffffff80815040 pf task mtx (pf task mtx) @ >> /usr/src/sys/contrib/pf/net/pf_ioctl.c:1394 >> 2nd 0xffffffff809f7b40 ifnet (ifnet) @ /usr/src/sys/net/if.c:1887 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> _witness_debugger() at _witness_debugger+0x49 >> witness_checkorder() at witness_checkorder+0x7d2 >> _rw_rlock() at _rw_rlock+0x60 >> ifunit() at ifunit+0x22 >> pfioctl() at pfioctl+0x20ea >> devfs_ioctl_f() at devfs_ioctl_f+0x6e >> kern_ioctl() at kern_ioctl+0xbc >> ioctl() at ioctl+0xf0 >> syscall() at syscall+0x18b >> Xfast_syscall() at Xfast_syscall+0xd0 >> --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80098a88c, rsp = >> 0x7fffffffb5c8, rbp = 0x7fffffffb710 --- >> lock order reversal: >> 1st 0xffffff0074026098 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1054 >> 2nd 0xffffff007417dba8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> _witness_debugger() at _witness_debugger+0x49 >> witness_checkorder() at witness_checkorder+0x7d2 >> __lockmgr_args() at __lockmgr_args+0xc92 >> vop_stdlock() at vop_stdlock+0x39 >> VOP_LOCK1_APV() at VOP_LOCK1_APV+0xc2 >> _vn_lock() at _vn_lock+0x50 >> vget() at vget+0x6c >> devfs_allocv() at devfs_allocv+0xee >> devfs_root() at devfs_root+0x41 >> vfs_donmount() at vfs_donmount+0xf93 >> nmount() at nmount+0x74 >> syscall() at syscall+0x18b >> Xfast_syscall() at Xfast_syscall+0xd0 >> --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007aaffc, rsp = >> 0x7fffffffdd28, rbp = 0x800a04048 --- >> >> Thanks, >> >> Chris >> -- >> @chrisattack >> ----------------------------------------- >> http://twitter.com/chrisattack >> http://chrisattack.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 kientzle at freebsd.org Fri Jul 10 02:54:15 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Fri Jul 10 02:54:22 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: <4A563A57.8090907@freebsd.org> References: <4A562960.3010801@freebsd.org> <4A563A57.8090907@freebsd.org> Message-ID: <4A56AD55.2010201@freebsd.org> Andriy Gapon wrote: > on 09/07/2009 21:02 Marius N?nnerich said the following: >> What about atomically changing tsc_freq every time the frequency is changed? > > This is what actually does happen, but it doesn't help. > > Say, there is a moment T1 when TSC has value N and tsc_freq is X, and moment T2 > when when TSC value (N + 1) and tsc_freq is 10*X. > So the formula gives: > > t1 = N / X > t2 = (N+1) / (10*X) Instead of just storing tsc_freq at each frequency change, you really need: * Last timestamp just before frequency change (t0) * new frequency (f) * TSC value at frequency change (c0) Then t = t0 + (rdtsc() - c0) / f Of course, I haven't looked at the code to tell what your range limitations are. Tim From mrossi at swin.edu.au Fri Jul 10 02:57:20 2009 From: mrossi at swin.edu.au (Mattia Rossi) Date: Fri Jul 10 02:57:26 2009 Subject: Vlc services discovery (SAP) panics kernel In-Reply-To: <4A563C65.20402@fgznet.ch> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> <1247107223.31816.7.camel@bauer.cse.buffalo.edu> <4A563C65.20402@fgznet.ch> Message-ID: <4A56A263.4020307@swin.edu.au> I've tried to use vlc 1.0.0 (goldeneye) - it was also happening with previous versions. Every time I try SAP service discovery the system freezes. Trying on the command line gave me a Fatal error 12 message, page fault while in kernel mode. I've tried to reinstall all ports related to vlc (using portmaster), no changes. Wanted to reinstall all ports from scratch, but as kdelibs3 still doesn't have the latest working libusb2 patch included and kdegraphics4 pulls in sane-backends which does not compile because of libusb2, I actually can't rebuild my system without patching around and stuff - which sucks. Don't know if somebody else is experiencing the same problems... mostly the vlc one. Mat Btw.: no kernel dumps available.. seems that the instructions at http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html do not work (for me). From mezz7 at cox.net Fri Jul 10 03:13:12 2009 From: mezz7 at cox.net (Jeremy Messenger) Date: Fri Jul 10 03:13:20 2009 Subject: Vlc services discovery (SAP) panics kernel In-Reply-To: <4A56A263.4020307@swin.edu.au> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> <1247107223.31816.7.camel@bauer.cse.buffalo.edu> <4A563C65.20402@fgznet.ch> <4A56A263.4020307@swin.edu.au> Message-ID: On Thu, 09 Jul 2009 21:07:31 -0500, Mattia Rossi wrote: > I've tried to use vlc 1.0.0 (goldeneye) - it was also happening with > previous versions. > Every time I try SAP service discovery the system freezes. > > Trying on the command line gave me a Fatal error 12 message, page fault > while in kernel mode. > > I've tried to reinstall all ports related to vlc (using portmaster), no > changes. > > Wanted to reinstall all ports from scratch, but as kdelibs3 still > doesn't have the latest working libusb2 patch included and kdegraphics4 > pulls in sane-backends which does not compile because of libusb2, I > actually can't rebuild my system without patching around and stuff - > which sucks. The kdebase3 (you need to make sure you have latest -CURRENT) should be fixed that was committed a few days ago. As for the sane-backends, I have disabled USB support by default in -CURRENT for us can install KDE3 or KDE4 (don't remember). I agree with you about that broke libusb2 is quiet annoy, but we will get there. Cheers, Mezz > Don't know if somebody else is experiencing the same problems... mostly > the vlc one. > > Mat > > Btw.: no kernel dumps available.. seems that the instructions at > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html > > do not work (for me). -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From john.marshall at riverwillow.com.au Fri Jul 10 03:58:55 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri Jul 10 03:59:03 2009 Subject: Process stuck in vmmaps on 8.0-BETA1 In-Reply-To: <20090709142121.GS55190@deviant.kiev.zoral.com.ua> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> Message-ID: <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> On Thu, 09 Jul 2009, 17:21 +0300, Kostik Belousov wrote: > On Thu, Jul 09, 2009 at 06:52:42PM +1000, John Marshall wrote: > > OK, now that I've rebuilt the kernel with the debugging options not > > commented out, I'm getting a number of 'lock order reversal' messages > > printed on the console: is that normal? > > > > From the Debugging Deadlocks chapter to which I was referred by pluknet > > (above) it appears that I need to enter 'sysctl debug.kdb.enter=1' or > > 'sysctl debug.kdb.panic=1' after I get the process into the desired > > 'stuck' state. If I enter either of those commands, the system reboots. > > Now *I'm* stuck. > > Since you have mostly working system, and interesting information most > easy accessible by kgdb, attach it to the live kernel: > kgdb /dev/mem > > From there, switch to the stuck process, > process I tried that... (kgdb) process 1373 Undefined command: "process". Try "help". It took me several more hours to discover "proc" which I assume is what you meant? > do > bt > find the frame for vm_map_delete, and print the entry: > p entry I have no idea which number(s) to plug in here. I hope I guessed the right one. > Also, I need to see the information you posted earlier, namely, procstat > -k and -v output for the process. rwsrv05# procstat 1373 PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM 1373 1 1373 1373 0 1 john vmmaps FreeBSD ELF32 ntpd rwsrv05# procstat -k 1373 PID TID COMM TDNAME KSTACK 1373 100168 ntpd - mi_switch sleepq_switch sleepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mmap syscall Xint0x80_syscall rwsrv05# procstat -v 1373 PID START END PRT RES PRES REF SHD FL TP PATH 1373 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd 1373 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd 1373 0x8080000 0x8100000 rw- 128 0 1 0 C- df 1373 0x2807e000 0x280ab000 r-x 45 0 143 62 CN vn /libexec/ld-elf.so.1 1373 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 1373 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df 1373 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 1373 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 1373 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 1373 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 1373 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 1373 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 1373 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df 1373 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 1373 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 1373 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 1373 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 1373 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 1373 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 1373 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 1373 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 1373 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 1373 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 1373 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 1373 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 1373 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 1373 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 1373 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 1373 0x28358000 0x2836e000 rw- 22 0 1 0 C- df 1373 0x2836e000 0x2837a000 --- 0 0 0 0 -- -- 1373 0x28400000 0x28500000 rw- 256 0 1 0 C- df 1373 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df rwsrv05# kgdb /spare/obj8/usr/src/sys/RWSRV05/kernel.debug /dev/mem 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"... #0 sched_switch (td=0xc08ad090, newtd=0xc4d4d900, flags=260) at /usr/src/sys/kern/sched_ule.c:1864 1864 cpuid = PCPU_GET(cpuid); Ready to go. Enter 'tr' to connect to the remote target with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port or 'trf portno' to connect to the remote target with the firewire interface. portno defaults to 5556. Type 'getsyms' after connection to load kld symbols. If you're debugging a local system, you can use 'kldsyms' instead to load the kld symbols. That's a less obnoxious interface. (kgdb) proc 1373 [Switching to thread 154 (Thread 100168)]#0 sched_switch (td=0xc5776240, newtd=0xc4d4db40, flags=0x104) at /usr/src/sys/kern/sched_ule.c:1864 1864 cpuid = PCPU_GET(cpuid); (kgdb) bt 1373 #0 sched_switch (td=0xc5776240, newtd=0xc4d4db40, flags=0x104) at /usr/src/sys/kern/sched_ule.c:1864 During symbol reading, Incomplete CFI data; unspecified registers at 0xc05fe876. #1 0xc05e572f in mi_switch (flags=0x104, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:444 #2 0xc06147fc in sleepq_switch (wchan=0xc5a5f338, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:505 #3 0xc0615495 in sleepq_wait (wchan=0xc5a5f338, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:584 #4 0xc05e5bd9 in _sleep (ident=0xc5a5f338, lock=0xc0a243a4, priority=0x244, wmesg=0xc08357af "vmmaps", timo=0x0) at /usr/src/sys/kern/kern_synch.c:232 #5 0xc075f8d7 in vm_map_unlock_and_wait (map=0xc5a5f2b8, timo=0x0) at /usr/src/sys/vm/vm_map.c:638 #6 0xc075f987 in vm_map_delete (map=0xc5a5f2b8, start=0x2836e000, end=0x28374000) at /usr/src/sys/vm/vm_map.c:2703 #7 0xc076136e in vm_map_fixed (map=0xc5a5f2b8, object=0xc52ffc38, offset=0x0, start=0x2836e000, length=0x6000, prot=0x5, max=0x7, cow=0x112) at /usr/src/sys/vm/vm_map.c:1367 #8 0xc0763a48 in vm_mmap (map=0xc5a5f2b8, addr=0xe7840c70, size=0x6000, prot=Variable "prot" is not available. ) at /usr/src/sys/vm/vm_mmap.c:1439 #9 0xc07641ef in mmap (td=0xc5776240, uap=0xe7840cf8) at /usr/src/sys/vm/vm_mmap.c:390 #10 0xc07b955f in syscall (frame=0xe7840d38) at /usr/src/sys/i386/i386/trap.c:1073 #11 0xc079dff0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #12 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) p *0xc5a5f2b8 $1 = 0xc58cb048 -- John Marshall -------------- 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/20090710/4cad3639/attachment.pgp From john.marshall at riverwillow.com.au Fri Jul 10 04:21:12 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri Jul 10 04:21:19 2009 Subject: 8.0-BETA1 bsdlabel broken? Message-ID: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> This system was source-upgrade from 7.2-RELEASE to 8.0-BETA1 a couple of days ago. Today I had a nasty surprise when I fired up bsdlabel to increase the size of a swap partition. I booted the system off the 7.2-RELEASE live filesystem CD and its bsdlabel displayed "normal" labels. I used the bsdlabel off the 7.2 livefs CD to edit the label. Here's what I see from 8.0-BETA1. Scary stuff! rwsrv05# bsdlabel da0s1 # /dev/da0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1048576 16065 4.2BSD 2048 16384 8 b: 8388608 1064641 swap c: 33543720 16065 unused 0 0 # "raw" part, don't edit e: 4194304 9453249 4.2BSD 2048 16384 28552 f: 19912232 13647553 4.2BSD 2048 16384 28552 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition f: partition extends past end of unit rwsrv05# bsdlabel da0s2 # /dev/da0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 67103505 33559785 unused 0 0 # "raw" part, don't edit d: 33554432 33559785 4.2BSD 2048 16384 28552 e: 33549073 67114217 4.2BSD 2048 16384 28552 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition d: partition extends past end of unit partition e: offset past end of unit partition e: partition extends past end of unit rwsrv05# bsdlabel ad0s1 # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 156301425 63 unused 0 0 # "raw" part, don't edit d: 156301409 79 4.2BSD 2048 16384 28552 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition d: partition extends past end of unit -- John Marshall -------------- 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/20090710/feed65f4/attachment.pgp From avg at freebsd.org Fri Jul 10 05:45:42 2009 From: avg at freebsd.org (Andriy Gapon) Date: Fri Jul 10 05:45:49 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: <20090709193932.GA54408@zim.MIT.EDU> References: <4A562960.3010801@freebsd.org> <20090709193932.GA54408@zim.MIT.EDU> Message-ID: <4A56D57D.1090508@freebsd.org> on 09/07/2009 22:39 David Schultz said the following: > Doesn't Solaris DTRT and compensate for TSC frequency changes? > Why can't we do the same thing? That very well may be. I haven't thoroughly checked but I think that even we are doing the right thing when we use TSC as a timecounter. But at this moment I am looking for a quick/simple and "sufficiently good" fix for the bigger problems with DTrace timestamping (kern/127441). Another side of the "simplicity" is that the timestamp function for DTrace needs to be fast and should not itself be probed. -- Andriy Gapon From avg at freebsd.org Fri Jul 10 05:50:52 2009 From: avg at freebsd.org (Andriy Gapon) Date: Fri Jul 10 05:50:58 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: <4A56AD55.2010201@freebsd.org> References: <4A562960.3010801@freebsd.org> <4A563A57.8090907@freebsd.org> <4A56AD55.2010201@freebsd.org> Message-ID: <4A56D6B7.8050100@freebsd.org> on 10/07/2009 05:54 Tim Kientzle said the following: > > Instead of just storing tsc_freq at each frequency change, > you really need: > * Last timestamp just before frequency change (t0) > * new frequency (f) > * TSC value at frequency change (c0) > > Then > t = t0 + (rdtsc() - c0) / f > > Of course, I haven't looked at the code to tell > what your range limitations are. Yes, tracking the TSC frequency changes should allow us to have correct DTrace timecounting. But I am not sure if we really need this (or can have this). Because otherwise I can not see why we have a distinct/specialized DTrace TSC-based timecounting when we already have general purpose TSC timecounting that already works correctly (if I am not mistaken). -- Andriy Gapon From avg at freebsd.org Fri Jul 10 05:58:32 2009 From: avg at freebsd.org (Andriy Gapon) Date: Fri Jul 10 05:58:39 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: <4A56D6B7.8050100@freebsd.org> References: <4A562960.3010801@freebsd.org> <4A563A57.8090907@freebsd.org> <4A56AD55.2010201@freebsd.org> <4A56D6B7.8050100@freebsd.org> Message-ID: <4A56D87B.6000202@freebsd.org> Thinking aloud - maybe we could always use one value of tsc_freq (or something like max_tsc_freq). This wouldn't give us correct timestamps when TSC frequency is changing, but it would give us something that is always proportional to TSC value and thus has its properties - monotonicity in the first place. And, of course, there is no problem when TSC frequency is constant. -- Andriy Gapon From rea-fbsd at codelabs.ru Fri Jul 10 06:14:19 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Fri Jul 10 06:14:27 2009 Subject: 8.0-BETA1 bsdlabel broken? In-Reply-To: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> Message-ID: Jogh, good day. Fri, Jul 10, 2009 at 02:21:06PM +1000, John Marshall wrote: > This system was source-upgrade from 7.2-RELEASE to 8.0-BETA1 a couple of > days ago. > > Today I had a nasty surprise when I fired up bsdlabel to increase the > size of a swap partition. I booted the system off the 7.2-RELEASE live > filesystem CD and its bsdlabel displayed "normal" labels. I used the > bsdlabel off the 7.2 livefs CD to edit the label. > > Here's what I see from 8.0-BETA1. Scary stuff! > > rwsrv05# bsdlabel da0s1 > # /dev/da0s1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 1048576 16065 4.2BSD 2048 16384 8 > b: 8388608 1064641 swap > c: 33543720 16065 unused 0 0 # "raw" part, don't edit > e: 4194304 9453249 4.2BSD 2048 16384 28552 > f: 19912232 13647553 4.2BSD 2048 16384 28552 > partition c: partition extends past end of unit > bsdlabel: partition c doesn't start at 0! > bsdlabel: An incorrect partition c may cause problems for standard system utilities > partition f: partition extends past end of unit And if you'll invoke 'bsdlabel -A da0s1' then it will whine only about 'c' that doesn't start at 0, but no stuff will be marked as 'extends past end of unit' ;)) The problem is that your 8.x kernel is likely misses GEOM_BSD, so gctl_issue() inside readlabel() of bsdlabel.c will choke on it. Mine problems on one of the hosts were solved by adding GEOM_BSD and recompiling the kernel, though it has the only slice that started at 63 (MBR offset). > rwsrv05# bsdlabel da0s2 > # /dev/da0s2: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 67103505 33559785 unused 0 0 # "raw" part, don't edit > d: 33554432 33559785 4.2BSD 2048 16384 28552 > e: 33549073 67114217 4.2BSD 2048 16384 28552 > partition c: partition extends past end of unit > bsdlabel: partition c doesn't start at 0! > bsdlabel: An incorrect partition c may cause problems for standard system utilities > partition d: partition extends past end of unit > partition e: offset past end of unit > partition e: partition extends past end of unit This part gets trickier, because partition 'c' reports strange offset. I had reproduced this problem at my notebook, so I'll try to debug it further. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From john.marshall at riverwillow.com.au Fri Jul 10 07:10:27 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri Jul 10 07:10:35 2009 Subject: 8.0-BETA1 bsdlabel broken? In-Reply-To: References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> Message-ID: <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> On Fri, 10 Jul 2009, 10:14 +0400, Eygene Ryabinkin wrote: > Fri, Jul 10, 2009 at 02:21:06PM +1000, John Marshall wrote: > > This system was source-upgrade from 7.2-RELEASE to 8.0-BETA1 a couple of > > days ago. > > > > Today I had a nasty surprise when I fired up bsdlabel to increase the > > size of a swap partition. I booted the system off the 7.2-RELEASE live > > filesystem CD and its bsdlabel displayed "normal" labels. I used the > > bsdlabel off the 7.2 livefs CD to edit the label. > > > > Here's what I see from 8.0-BETA1. Scary stuff! > > > > rwsrv05# bsdlabel da0s1 > > # /dev/da0s1: > > 8 partitions: > > # size offset fstype [fsize bsize bps/cpg] > > a: 1048576 16065 4.2BSD 2048 16384 8 > > b: 8388608 1064641 swap > > c: 33543720 16065 unused 0 0 # "raw" part, don't edit > > e: 4194304 9453249 4.2BSD 2048 16384 28552 > > f: 19912232 13647553 4.2BSD 2048 16384 28552 > > partition c: partition extends past end of unit > > bsdlabel: partition c doesn't start at 0! > > bsdlabel: An incorrect partition c may cause problems for standard system utilities > > partition f: partition extends past end of unit > > And if you'll invoke 'bsdlabel -A da0s1' then it will whine only about > 'c' that doesn't start at 0, but no stuff will be marked as 'extends past > end of unit' ;)) > > The problem is that your 8.x kernel is likely misses GEOM_BSD, so > gctl_issue() inside readlabel() of bsdlabel.c will choke on it. > Mine problems on one of the hosts were solved by adding GEOM_BSD and > recompiling the kernel, though it has the only slice that started at > 63 (MBR offset). > > > rwsrv05# bsdlabel da0s2 > > # /dev/da0s2: > > 8 partitions: > > # size offset fstype [fsize bsize bps/cpg] > > c: 67103505 33559785 unused 0 0 # "raw" part, don't edit > > d: 33554432 33559785 4.2BSD 2048 16384 28552 > > e: 33549073 67114217 4.2BSD 2048 16384 28552 > > partition c: partition extends past end of unit > > bsdlabel: partition c doesn't start at 0! > > bsdlabel: An incorrect partition c may cause problems for standard system utilities > > partition d: partition extends past end of unit > > partition e: offset past end of unit > > partition e: partition extends past end of unit > > This part gets trickier, because partition 'c' reports strange offset. > I had reproduced this problem at my notebook, so I'll try to debug it > further. Thank you Eygene, Rebuilding the kernel with the GEOM_BSD option configured didn't make any difference for me. I notice that the offset for the start of the slice 2 c partition seems to include the size of the entire s1 slice. -- John Marshall -------------- 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/20090710/4e74e878/attachment.pgp From yr.retarded at gmail.com Fri Jul 10 07:58:49 2009 From: yr.retarded at gmail.com (Chris Ruiz) Date: Fri Jul 10 07:58:55 2009 Subject: no em0 with r195477 In-Reply-To: <2a41acea0907091713v6291f7dbt33b61c10ee7db893@mail.gmail.com> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> <20090709153940.4544bfa8.stas@FreeBSD.org> <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> <2a41acea0907091135j12f4c0efn963859f8def1d9cd@mail.gmail.com> <2a41acea0907091713v6291f7dbt33b61c10ee7db893@mail.gmail.com> Message-ID: <58c737d70907100058u263ab795g442c62d67ba2345f@mail.gmail.com> On Thu, Jul 9, 2009 at 7:13 PM, Jack Vogel wrote: > I have tried to reproduce this and cannot,? can you tell me more details > about > this hardware, is it off-the-shelf or something non-production, etc etc. > > Did an install of a stock ICH9 system with this NIC, and have seen no > such checksum failure, everything works fine :( I've never had any problems with my network controller before now (driver version 6.9.9 works) so this is indeed strange. This is an Intel? Desktop Board DQ35JO (1), so the nic is built in. This is off the shelf two year old equipment used for a home server, nothing spectacular. Thanks, Chris (1) http://www.intel.com/support/motherboards/desktop/dq35jo/ From kostikbel at gmail.com Fri Jul 10 08:24:05 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Jul 10 08:24:12 2009 Subject: Process stuck in vmmaps on 8.0-BETA1 In-Reply-To: <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> Message-ID: <20090710082356.GZ55190@deviant.kiev.zoral.com.ua> On Fri, Jul 10, 2009 at 01:58:49PM +1000, John Marshall wrote: > On Thu, 09 Jul 2009, 17:21 +0300, Kostik Belousov wrote: > > On Thu, Jul 09, 2009 at 06:52:42PM +1000, John Marshall wrote: > > > OK, now that I've rebuilt the kernel with the debugging options not > > > commented out, I'm getting a number of 'lock order reversal' messages > > > printed on the console: is that normal? > > > > > > From the Debugging Deadlocks chapter to which I was referred by pluknet > > > (above) it appears that I need to enter 'sysctl debug.kdb.enter=1' or > > > 'sysctl debug.kdb.panic=1' after I get the process into the desired > > > 'stuck' state. If I enter either of those commands, the system reboots. > > > Now *I'm* stuck. > > > > Since you have mostly working system, and interesting information most > > easy accessible by kgdb, attach it to the live kernel: > > kgdb /dev/mem > > > > From there, switch to the stuck process, > > process > > I tried that... > > (kgdb) process 1373 > Undefined command: "process". Try "help". > > It took me several more hours to discover "proc" which I assume is what > you meant? Yes. > > > do > > bt > > find the frame for vm_map_delete, and print the entry: > > p entry > > I have no idea which number(s) to plug in here. I hope I guessed the > right one. > > > Also, I need to see the information you posted earlier, namely, procstat > > -k and -v output for the process. > > rwsrv05# procstat 1373 > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM > 1373 1 1373 1373 0 1 john vmmaps FreeBSD ELF32 ntpd > rwsrv05# procstat -k 1373 > PID TID COMM TDNAME KSTACK > 1373 100168 ntpd - mi_switch sleepq_switch sleepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mmap syscall Xint0x80_syscall > rwsrv05# procstat -v 1373 > PID START END PRT RES PRES REF SHD FL TP PATH > 1373 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd > 1373 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd > 1373 0x8080000 0x8100000 rw- 128 0 1 0 C- df > 1373 0x2807e000 0x280ab000 r-x 45 0 143 62 CN vn /libexec/ld-elf.so.1 > 1373 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 > 1373 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df > 1373 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 > 1373 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 > 1373 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 > 1373 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 > 1373 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 > 1373 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 > 1373 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df > 1373 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 > 1373 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 > 1373 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 > 1373 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 > 1373 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 > 1373 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 > 1373 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 > 1373 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 > 1373 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 > 1373 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 > 1373 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 > 1373 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 > 1373 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 > 1373 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 > 1373 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 > 1373 0x28358000 0x2836e000 rw- 22 0 1 0 C- df > 1373 0x2836e000 0x2837a000 --- 0 0 0 0 -- -- > 1373 0x28400000 0x28500000 rw- 256 0 1 0 C- df > 1373 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df > > rwsrv05# kgdb /spare/obj8/usr/src/sys/RWSRV05/kernel.debug /dev/mem > 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"... > #0 sched_switch (td=0xc08ad090, newtd=0xc4d4d900, flags=260) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid = PCPU_GET(cpuid); > Ready to go. Enter 'tr' to connect to the remote target > with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port > or 'trf portno' to connect to the remote target with the firewire > interface. portno defaults to 5556. > > Type 'getsyms' after connection to load kld symbols. > > If you're debugging a local system, you can use 'kldsyms' instead > to load the kld symbols. That's a less obnoxious interface. > (kgdb) proc 1373 > [Switching to thread 154 (Thread 100168)]#0 sched_switch (td=0xc5776240, newtd=0xc4d4db40, flags=0x104) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid = PCPU_GET(cpuid); > (kgdb) bt 1373 > #0 sched_switch (td=0xc5776240, newtd=0xc4d4db40, flags=0x104) at /usr/src/sys/kern/sched_ule.c:1864 > During symbol reading, Incomplete CFI data; unspecified registers at 0xc05fe876. > #1 0xc05e572f in mi_switch (flags=0x104, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:444 > #2 0xc06147fc in sleepq_switch (wchan=0xc5a5f338, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:505 > #3 0xc0615495 in sleepq_wait (wchan=0xc5a5f338, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:584 > #4 0xc05e5bd9 in _sleep (ident=0xc5a5f338, lock=0xc0a243a4, priority=0x244, wmesg=0xc08357af "vmmaps", timo=0x0) > at /usr/src/sys/kern/kern_synch.c:232 > #5 0xc075f8d7 in vm_map_unlock_and_wait (map=0xc5a5f2b8, timo=0x0) at /usr/src/sys/vm/vm_map.c:638 > #6 0xc075f987 in vm_map_delete (map=0xc5a5f2b8, start=0x2836e000, end=0x28374000) at /usr/src/sys/vm/vm_map.c:2703 This frame (vm_map_delete). > #7 0xc076136e in vm_map_fixed (map=0xc5a5f2b8, object=0xc52ffc38, offset=0x0, start=0x2836e000, length=0x6000, > prot=0x5, max=0x7, cow=0x112) at /usr/src/sys/vm/vm_map.c:1367 > #8 0xc0763a48 in vm_mmap (map=0xc5a5f2b8, addr=0xe7840c70, size=0x6000, prot=Variable "prot" is not available. > ) at /usr/src/sys/vm/vm_mmap.c:1439 > #9 0xc07641ef in mmap (td=0xc5776240, uap=0xe7840cf8) at /usr/src/sys/vm/vm_mmap.c:390 > #10 0xc07b955f in syscall (frame=0xe7840d38) at /usr/src/sys/i386/i386/trap.c:1073 > #11 0xc079dff0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 > #12 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) p *0xc5a5f2b8 > $1 = 0xc58cb048 This is useless. You need to do either p *entry or p *(struct vm_map_entry *)
> > -- > John Marshall -------------- 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/20090710/6a47be9c/attachment.pgp From tevans.uk at googlemail.com Fri Jul 10 08:28:34 2009 From: tevans.uk at googlemail.com (Tom Evans) Date: Fri Jul 10 08:28:42 2009 Subject: Process stuck in vmmaps on 8.0-BETA1 In-Reply-To: <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> Message-ID: <1247214510.2437.1693.camel@strangepork.london.mintel.ad> On Fri, 2009-07-10 at 13:58 +1000, John Marshall wrote: > On Thu, 09 Jul 2009, 17:21 +0300, Kostik Belousov wrote: > > On Thu, Jul 09, 2009 at 06:52:42PM +1000, John Marshall wrote: > > > OK, now that I've rebuilt the kernel with the debugging options not > > > commented out, I'm getting a number of 'lock order reversal' messages > > > printed on the console: is that normal? > > > > > > From the Debugging Deadlocks chapter to which I was referred by pluknet > > > (above) it appears that I need to enter 'sysctl debug.kdb.enter=1' or > > > 'sysctl debug.kdb.panic=1' after I get the process into the desired > > > 'stuck' state. If I enter either of those commands, the system reboots. > > > Now *I'm* stuck. > > > > Since you have mostly working system, and interesting information most > > easy accessible by kgdb, attach it to the live kernel: > > kgdb /dev/mem > > > > From there, switch to the stuck process, > > process > > I tried that... > > (kgdb) process 1373 > Undefined command: "process". Try "help". > > It took me several more hours to discover "proc" which I assume is what > you meant? > > > do > > bt > > find the frame for vm_map_delete, and print the entry: > > p entry > > I have no idea which number(s) to plug in here. I hope I guessed the > right one. > > > Also, I need to see the information you posted earlier, namely, procstat > > -k and -v output for the process. > > rwsrv05# procstat 1373 > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM > 1373 1 1373 1373 0 1 john vmmaps FreeBSD ELF32 ntpd > rwsrv05# procstat -k 1373 > PID TID COMM TDNAME KSTACK > 1373 100168 ntpd - mi_switch sleepq_switch sleepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mmap syscall Xint0x80_syscall > rwsrv05# procstat -v 1373 > PID START END PRT RES PRES REF SHD FL TP PATH > 1373 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd > 1373 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd > 1373 0x8080000 0x8100000 rw- 128 0 1 0 C- df > 1373 0x2807e000 0x280ab000 r-x 45 0 143 62 CN vn /libexec/ld-elf.so.1 > 1373 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 > 1373 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df > 1373 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 > 1373 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 > 1373 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 > 1373 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 > 1373 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 > 1373 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 > 1373 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df > 1373 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 > 1373 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 > 1373 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 > 1373 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 > 1373 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 > 1373 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 > 1373 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 > 1373 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 > 1373 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 > 1373 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 > 1373 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 > 1373 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 > 1373 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 > 1373 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 > 1373 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 > 1373 0x28358000 0x2836e000 rw- 22 0 1 0 C- df > 1373 0x2836e000 0x2837a000 --- 0 0 0 0 -- -- > 1373 0x28400000 0x28500000 rw- 256 0 1 0 C- df > 1373 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df > > rwsrv05# kgdb /spare/obj8/usr/src/sys/RWSRV05/kernel.debug /dev/mem > 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"... > #0 sched_switch (td=0xc08ad090, newtd=0xc4d4d900, flags=260) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid = PCPU_GET(cpuid); > Ready to go. Enter 'tr' to connect to the remote target > with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port > or 'trf portno' to connect to the remote target with the firewire > interface. portno defaults to 5556. > > Type 'getsyms' after connection to load kld symbols. > > If you're debugging a local system, you can use 'kldsyms' instead > to load the kld symbols. That's a less obnoxious interface. > (kgdb) proc 1373 > [Switching to thread 154 (Thread 100168)]#0 sched_switch (td=0xc5776240, newtd=0xc4d4db40, flags=0x104) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid = PCPU_GET(cpuid); > (kgdb) bt 1373 > #0 sched_switch (td=0xc5776240, newtd=0xc4d4db40, flags=0x104) at /usr/src/sys/kern/sched_ule.c:1864 > During symbol reading, Incomplete CFI data; unspecified registers at 0xc05fe876. > #1 0xc05e572f in mi_switch (flags=0x104, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:444 > #2 0xc06147fc in sleepq_switch (wchan=0xc5a5f338, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:505 > #3 0xc0615495 in sleepq_wait (wchan=0xc5a5f338, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:584 > #4 0xc05e5bd9 in _sleep (ident=0xc5a5f338, lock=0xc0a243a4, priority=0x244, wmesg=0xc08357af "vmmaps", timo=0x0) > at /usr/src/sys/kern/kern_synch.c:232 > #5 0xc075f8d7 in vm_map_unlock_and_wait (map=0xc5a5f2b8, timo=0x0) at /usr/src/sys/vm/vm_map.c:638 > #6 0xc075f987 in vm_map_delete (map=0xc5a5f2b8, start=0x2836e000, end=0x28374000) at /usr/src/sys/vm/vm_map.c:2703 > #7 0xc076136e in vm_map_fixed (map=0xc5a5f2b8, object=0xc52ffc38, offset=0x0, start=0x2836e000, length=0x6000, > prot=0x5, max=0x7, cow=0x112) at /usr/src/sys/vm/vm_map.c:1367 > #8 0xc0763a48 in vm_mmap (map=0xc5a5f2b8, addr=0xe7840c70, size=0x6000, prot=Variable "prot" is not available. > ) at /usr/src/sys/vm/vm_mmap.c:1439 > #9 0xc07641ef in mmap (td=0xc5776240, uap=0xe7840cf8) at /usr/src/sys/vm/vm_mmap.c:390 > #10 0xc07b955f in syscall (frame=0xe7840d38) at /usr/src/sys/i386/i386/trap.c:1073 > #11 0xc079dff0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 > #12 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) p *0xc5a5f2b8 > $1 = 0xc58cb048 > At this stage, you want to type 'f 6', to go to frame 6, (the vm_map_delete function) and then type 'p *entry' to print the struct pointed to by the local variable entry in that frame. Cheers Tom From rwatson at FreeBSD.org Fri Jul 10 11:12:39 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Jul 10 11:12:46 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: <4A56D87B.6000202@freebsd.org> References: <4A562960.3010801@freebsd.org> <4A563A57.8090907@freebsd.org> <4A56AD55.2010201@freebsd.org> <4A56D6B7.8050100@freebsd.org> <4A56D87B.6000202@freebsd.org> Message-ID: On Fri, 10 Jul 2009, Andriy Gapon wrote: > Thinking aloud - maybe we could always use one value of tsc_freq (or > something like max_tsc_freq). This wouldn't give us correct timestamps when > TSC frequency is changing, but it would give us something that is always > proportional to TSC value and thus has its properties - monotonicity in the > first place. And, of course, there is no problem when TSC frequency is > constant. Just a point from a user perspective: I find it useful (important even) to be able to compare timing between runs on the same box, and while that means I need to control for the frequency changing in an experimental sense, in as much as timestamp measurements in dtrace can be normalized, that would be helpful. Robert N M Watson Computer Laboratory University of Cambridge From john.marshall at riverwillow.com.au Fri Jul 10 11:26:35 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri Jul 10 11:26:43 2009 Subject: 8.0-BETA1 bsdlabel broken? In-Reply-To: <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> Message-ID: <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> On Fri, 10 Jul 2009, 17:10 +1000, John Marshall wrote: > On Fri, 10 Jul 2009, 10:14 +0400, Eygene Ryabinkin wrote: > > Fri, Jul 10, 2009 at 02:21:06PM +1000, John Marshall wrote: > > > This system was source-upgrade from 7.2-RELEASE to 8.0-BETA1 a couple of > > > days ago. > > > > > > Today I had a nasty surprise when I fired up bsdlabel to increase the > > > size of a swap partition. I booted the system off the 7.2-RELEASE live > > > filesystem CD and its bsdlabel displayed "normal" labels. I used the > > > bsdlabel off the 7.2 livefs CD to edit the label. > > > > > > Here's what I see from 8.0-BETA1. Scary stuff! > > > > > > rwsrv05# bsdlabel da0s1 > > > # /dev/da0s1: > > > 8 partitions: > > > # size offset fstype [fsize bsize bps/cpg] > > > a: 1048576 16065 4.2BSD 2048 16384 8 > > > b: 8388608 1064641 swap > > > c: 33543720 16065 unused 0 0 # "raw" part, don't edit > > > e: 4194304 9453249 4.2BSD 2048 16384 28552 > > > f: 19912232 13647553 4.2BSD 2048 16384 28552 > > > partition c: partition extends past end of unit > > > bsdlabel: partition c doesn't start at 0! > > > bsdlabel: An incorrect partition c may cause problems for standard system utilities > > > partition f: partition extends past end of unit > > > > And if you'll invoke 'bsdlabel -A da0s1' then it will whine only about > > 'c' that doesn't start at 0, but no stuff will be marked as 'extends past > > end of unit' ;)) > > > > The problem is that your 8.x kernel is likely misses GEOM_BSD, so > > gctl_issue() inside readlabel() of bsdlabel.c will choke on it. > > Mine problems on one of the hosts were solved by adding GEOM_BSD and > > recompiling the kernel, though it has the only slice that started at > > 63 (MBR offset). > > > > > rwsrv05# bsdlabel da0s2 > > > # /dev/da0s2: > > > 8 partitions: > > > # size offset fstype [fsize bsize bps/cpg] > > > c: 67103505 33559785 unused 0 0 # "raw" part, don't edit > > > d: 33554432 33559785 4.2BSD 2048 16384 28552 > > > e: 33549073 67114217 4.2BSD 2048 16384 28552 > > > partition c: partition extends past end of unit > > > bsdlabel: partition c doesn't start at 0! > > > bsdlabel: An incorrect partition c may cause problems for standard system utilities > > > partition d: partition extends past end of unit > > > partition e: offset past end of unit > > > partition e: partition extends past end of unit > > > > This part gets trickier, because partition 'c' reports strange offset. > > I had reproduced this problem at my notebook, so I'll try to debug it > > further. > > Thank you Eygene, > > Rebuilding the kernel with the GEOM_BSD option configured didn't make > any difference for me. I notice that the offset for the start of the > slice 2 c partition seems to include the size of the entire s1 slice. I don't think it's just bsdlabel. I just noticed this in DMESG... WARNING: da0s1 expected rawoffset 0, found 16065 WARNING: da0s2 expected rawoffset 0, found 33559785 WARNING: da0s4 expected rawoffset 0, found 100663290 WARNING: da1s1 expected rawoffset 0, found 16065 WARNING: da1s2 expected rawoffset 0, found 33559785 WARNING: da1s4 expected rawoffset 0, found 67103505 WARNING: da0s1a expected rawoffset 0, found 16065 WARNING: da0s2d expected rawoffset 0, found 33559785 WARNING: da0s4d expected rawoffset 0, found 100663290 WARNING: ufsid/44cab1426f1a14df expected rawoffset 0, found 100663290 WARNING: da1s1d expected rawoffset 0, found 16065 WARNING: ufsid/44c73ece4c594eee expected rawoffset 0, found 16065 WARNING: da1s2d expected rawoffset 0, found 33559785 WARNING: ufsid/44ca989c1c946f80 expected rawoffset 0, found 33559785 WARNING: da1s4d expected rawoffset 0, found 67103505 WARNING: ufsid/44caacedfa48b1aa expected rawoffset 0, found 67103505 WARNING: ufsid/454bbd55fb8748ad expected rawoffset 0, found 16065 WARNING: ufsid/44cab13667346452 expected rawoffset 0, found 33559785 WARNING: ufsid/44cab1426f1a14dfd expected rawoffset 0, found 100663290 WARNING: ufsid/44c73ece4c594eeed expected rawoffset 0, found 16065 WARNING: ufsid/44ca989c1c946f80d expected rawoffset 0, found 33559785 WARNING: ufsid/44caacedfa48b1aad expected rawoffset 0, found 67103505 Trying to mount root from ufs:/dev/da0s1a WARNING: da0s1a expected rawoffset 0, found 16065 WARNING: ufsid/454bbd55fb8748ad expected rawoffset 0, found 16065 WARNING: ad0s1 expected rawoffset 0, found 63 WARNING: da1s1 expected rawoffset 0, found 16065 WARNING: da1s1d expected rawoffset 0, found 16065 WARNING: ufsid/44c73ece4c594eee expected rawoffset 0, found 16065 WARNING: ufsid/44c73ece4c594eeed expected rawoffset 0, found 16065 WARNING: da1s2 expected rawoffset 0, found 33559785 WARNING: da1s2d expected rawoffset 0, found 33559785 WARNING: ufsid/44ca989c1c946f80 expected rawoffset 0, found 33559785 WARNING: ufsid/44ca989c1c946f80d expected rawoffset 0, found 33559785 WARNING: da1s4 expected rawoffset 0, found 67103505 WARNING: da1s4d expected rawoffset 0, found 67103505 WARNING: da0s2 expected rawoffset 0, found 33559785 WARNING: da0s2d expected rawoffset 0, found 33559785 WARNING: ufsid/44caacedfa48b1aa expected rawoffset 0, found 67103505 WARNING: ufsid/44cab13667346452 expected rawoffset 0, found 33559785 WARNING: ufsid/44caacedfa48b1aad expected rawoffset 0, found 67103505 WARNING: da0s2 expected rawoffset 0, found 33559785 WARNING: da0s4 expected rawoffset 0, found 100663290 WARNING: da0s4d expected rawoffset 0, found 100663290 WARNING: ufsid/44cab1426f1a14df expected rawoffset 0, found 100663290 WARNING: ufsid/44cab1426f1a14dfd expected rawoffset 0, found 100663290 -- John Marshall -------------- 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/20090710/4467fd57/attachment.pgp From onemda at gmail.com Fri Jul 10 11:33:12 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Fri Jul 10 11:33:19 2009 Subject: 8.0-BETA1 bsdlabel broken? In-Reply-To: <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> Message-ID: <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> On 7/10/09, John Marshall wrote: > On Fri, 10 Jul 2009, 17:10 +1000, John Marshall wrote: >> On Fri, 10 Jul 2009, 10:14 +0400, Eygene Ryabinkin wrote: >> > Fri, Jul 10, 2009 at 02:21:06PM +1000, John Marshall wrote: >> > > This system was source-upgrade from 7.2-RELEASE to 8.0-BETA1 a couple >> > > of >> > > days ago. >> > > >> > > Today I had a nasty surprise when I fired up bsdlabel to increase the >> > > size of a swap partition. I booted the system off the 7.2-RELEASE >> > > live >> > > filesystem CD and its bsdlabel displayed "normal" labels. I used the >> > > bsdlabel off the 7.2 livefs CD to edit the label. >> > > >> > > Here's what I see from 8.0-BETA1. Scary stuff! >> > > >> > > rwsrv05# bsdlabel da0s1 >> > > # /dev/da0s1: >> > > 8 partitions: >> > > # size offset fstype [fsize bsize bps/cpg] >> > > a: 1048576 16065 4.2BSD 2048 16384 8 >> > > b: 8388608 1064641 swap >> > > c: 33543720 16065 unused 0 0 # "raw" part, >> > > don't edit >> > > e: 4194304 9453249 4.2BSD 2048 16384 28552 >> > > f: 19912232 13647553 4.2BSD 2048 16384 28552 >> > > partition c: partition extends past end of unit >> > > bsdlabel: partition c doesn't start at 0! >> > > bsdlabel: An incorrect partition c may cause problems for standard >> > > system utilities >> > > partition f: partition extends past end of unit >> > >> > And if you'll invoke 'bsdlabel -A da0s1' then it will whine only about >> > 'c' that doesn't start at 0, but no stuff will be marked as 'extends >> > past >> > end of unit' ;)) >> > >> > The problem is that your 8.x kernel is likely misses GEOM_BSD, so >> > gctl_issue() inside readlabel() of bsdlabel.c will choke on it. >> > Mine problems on one of the hosts were solved by adding GEOM_BSD and >> > recompiling the kernel, though it has the only slice that started at >> > 63 (MBR offset). >> > >> > > rwsrv05# bsdlabel da0s2 >> > > # /dev/da0s2: >> > > 8 partitions: >> > > # size offset fstype [fsize bsize bps/cpg] >> > > c: 67103505 33559785 unused 0 0 # "raw" part, >> > > don't edit >> > > d: 33554432 33559785 4.2BSD 2048 16384 28552 >> > > e: 33549073 67114217 4.2BSD 2048 16384 28552 >> > > partition c: partition extends past end of unit >> > > bsdlabel: partition c doesn't start at 0! >> > > bsdlabel: An incorrect partition c may cause problems for standard >> > > system utilities >> > > partition d: partition extends past end of unit >> > > partition e: offset past end of unit >> > > partition e: partition extends past end of unit >> > >> > This part gets trickier, because partition 'c' reports strange offset. >> > I had reproduced this problem at my notebook, so I'll try to debug it >> > further. >> >> Thank you Eygene, >> >> Rebuilding the kernel with the GEOM_BSD option configured didn't make >> any difference for me. I notice that the offset for the start of the >> slice 2 c partition seems to include the size of the entire s1 slice. > > I don't think it's just bsdlabel. I just noticed this in DMESG... > > WARNING: da0s1 expected rawoffset 0, found 16065 > WARNING: da0s2 expected rawoffset 0, found 33559785 > WARNING: da0s4 expected rawoffset 0, found 100663290 > WARNING: da1s1 expected rawoffset 0, found 16065 > WARNING: da1s2 expected rawoffset 0, found 33559785 > WARNING: da1s4 expected rawoffset 0, found 67103505 > WARNING: da0s1a expected rawoffset 0, found 16065 > WARNING: da0s2d expected rawoffset 0, found 33559785 > WARNING: da0s4d expected rawoffset 0, found 100663290 > WARNING: ufsid/44cab1426f1a14df expected rawoffset 0, found 100663290 > WARNING: da1s1d expected rawoffset 0, found 16065 > WARNING: ufsid/44c73ece4c594eee expected rawoffset 0, found 16065 > WARNING: da1s2d expected rawoffset 0, found 33559785 > WARNING: ufsid/44ca989c1c946f80 expected rawoffset 0, found 33559785 > WARNING: da1s4d expected rawoffset 0, found 67103505 > WARNING: ufsid/44caacedfa48b1aa expected rawoffset 0, found 67103505 > WARNING: ufsid/454bbd55fb8748ad expected rawoffset 0, found 16065 > WARNING: ufsid/44cab13667346452 expected rawoffset 0, found 33559785 > WARNING: ufsid/44cab1426f1a14dfd expected rawoffset 0, found 100663290 > WARNING: ufsid/44c73ece4c594eeed expected rawoffset 0, found 16065 > WARNING: ufsid/44ca989c1c946f80d expected rawoffset 0, found 33559785 > WARNING: ufsid/44caacedfa48b1aad expected rawoffset 0, found 67103505 > Trying to mount root from ufs:/dev/da0s1a > WARNING: da0s1a expected rawoffset 0, found 16065 > WARNING: ufsid/454bbd55fb8748ad expected rawoffset 0, found 16065 > WARNING: ad0s1 expected rawoffset 0, found 63 > WARNING: da1s1 expected rawoffset 0, found 16065 > WARNING: da1s1d expected rawoffset 0, found 16065 > WARNING: ufsid/44c73ece4c594eee expected rawoffset 0, found 16065 > WARNING: ufsid/44c73ece4c594eeed expected rawoffset 0, found 16065 > WARNING: da1s2 expected rawoffset 0, found 33559785 > WARNING: da1s2d expected rawoffset 0, found 33559785 > WARNING: ufsid/44ca989c1c946f80 expected rawoffset 0, found 33559785 > WARNING: ufsid/44ca989c1c946f80d expected rawoffset 0, found 33559785 > WARNING: da1s4 expected rawoffset 0, found 67103505 > WARNING: da1s4d expected rawoffset 0, found 67103505 > WARNING: da0s2 expected rawoffset 0, found 33559785 > WARNING: da0s2d expected rawoffset 0, found 33559785 > WARNING: ufsid/44caacedfa48b1aa expected rawoffset 0, found 67103505 > WARNING: ufsid/44cab13667346452 expected rawoffset 0, found 33559785 > WARNING: ufsid/44caacedfa48b1aad expected rawoffset 0, found 67103505 > WARNING: da0s2 expected rawoffset 0, found 33559785 > WARNING: da0s4 expected rawoffset 0, found 100663290 > WARNING: da0s4d expected rawoffset 0, found 100663290 > WARNING: ufsid/44cab1426f1a14df expected rawoffset 0, found 100663290 > WARNING: ufsid/44cab1426f1a14dfd expected rawoffset 0, found 100663290 > > -- > John Marshall > There is one not so trivial solution. Recreating labels with gpart(8) -- Paul From john.marshall at riverwillow.com.au Fri Jul 10 11:42:38 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri Jul 10 11:42:46 2009 Subject: Process stuck in vmmaps on 8.0-BETA1 In-Reply-To: <1247214510.2437.1693.camel@strangepork.london.mintel.ad> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> <1247214510.2437.1693.camel@strangepork.london.mintel.ad> Message-ID: <20090710114234.GF32316@rwpc12.mby.riverwillow.net.au> On Fri, 10 Jul 2009, 09:28 +0100, Tom Evans wrote: > On Fri, 2009-07-10 at 13:58 +1000, John Marshall wrote: > > On Thu, 09 Jul 2009, 17:21 +0300, Kostik Belousov wrote: > > > Since you have mostly working system, and interesting information most > > > easy accessible by kgdb, attach it to the live kernel: > > > kgdb /dev/mem > > > > > > From there, switch to the stuck process, > > > process > > > > I tried that... > > > > (kgdb) process 1373 > > Undefined command: "process". Try "help". > > > > It took me several more hours to discover "proc" which I assume is what > > you meant? > > > > > do > > > bt > > > find the frame for vm_map_delete, and print the entry: > > > p entry > > > > I have no idea which number(s) to plug in here. I hope I guessed the > > right one. > > > > > Also, I need to see the information you posted earlier, namely, procstat > > > -k and -v output for the process. > > > At this stage, you want to type 'f 6', to go to frame 6, (the > vm_map_delete function) and then type 'p *entry' to print the struct > pointed to by the local variable entry in that frame. Thank you Tom! You could see I was struggling. Now, hopefully, I can provide something useful this time. rwsrv05# procstat 1270 PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM 1270 1 1270 1270 0 1 john vmmaps FreeBSD ELF32 ntpd rwsrv05# procstat -k 1270 PID TID COMM TDNAME KSTACK 1270 100184 ntpd - mi_switch sleepq_switch sleepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mmap syscall Xint0x80_syscall rwsrv05# procstat -v 1270 PID START END PRT RES PRES REF SHD FL TP PATH 1270 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd 1270 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd 1270 0x8080000 0x8100000 rw- 128 0 1 0 C- df 1270 0x2807e000 0x280ab000 r-x 45 0 170 75 CN vn /libexec/ld-elf.so.1 1270 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 1270 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df 1270 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 1270 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 1270 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 1270 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 1270 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 1270 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 1270 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df 1270 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 1270 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 1270 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 1270 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 1270 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 1270 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 1270 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 1270 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 1270 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 1270 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 1270 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 1270 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 1270 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 1270 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 1270 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 1270 0x28358000 0x2836e000 rw- 22 0 1 0 C- df 1270 0x2836e000 0x2837a000 --- 0 0 0 0 -- -- 1270 0x28400000 0x28500000 rw- 256 0 1 0 C- df 1270 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df rwsrv05# kgdb kernel.debug /dev/mem 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"... #0 sched_switch (td=0xc08af410, newtd=0xc4d4db40, flags=260) at /usr/src/sys/kern/sched_ule.c:1864 1864 cpuid = PCPU_GET(cpuid); Ready to go. Enter 'tr' to connect to the remote target with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port or 'trf portno' to connect to the remote target with the firewire interface. portno defaults to 5556. Type 'getsyms' after connection to load kld symbols. If you're debugging a local system, you can use 'kldsyms' instead to load the kld symbols. That's a less obnoxious interface. (kgdb) proc 1270 [Switching to thread 168 (Thread 100184)]#0 sched_switch (td=0xc592fd80, newtd=0xc4d4db40, flags=0x104) at /usr/src/sys/kern/sched_ule.c:1864 1864 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xc592fd80, newtd=0xc4d4db40, flags=0x104) at /usr/src/sys/kern/sched_ule.c:1864 During symbol reading, Incomplete CFI data; unspecified registers at 0xc06009d6. #1 0xc05e788f in mi_switch (flags=0x104, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:444 #2 0xc061695c in sleepq_switch (wchan=0xc5909f00, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:505 #3 0xc06175f5 in sleepq_wait (wchan=0xc5909f00, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:584 #4 0xc05e7d39 in _sleep (ident=0xc5909f00, lock=0xc0a26724, priority=0x244, wmesg=0xc0837aa0 "vmmaps", timo=0x0) at /usr/src/sys/kern/kern_synch.c:232 #5 0xc0761a37 in vm_map_unlock_and_wait (map=0xc5909e80, timo=0x0) at /usr/src/sys/vm/vm_map.c:638 #6 0xc0761ae7 in vm_map_delete (map=0xc5909e80, start=0x2836e000, end=0x28374000) at /usr/src/sys/vm/vm_map.c:2703 #7 0xc07634ce in vm_map_fixed (map=0xc5909e80, object=0xc5254990, offset=0x0, start=0x2836e000, length=0x6000, prot=0x5, max=0x7, cow=0x112) at /usr/src/sys/vm/vm_map.c:1367 #8 0xc0765ba8 in vm_mmap (map=0xc5909e80, addr=0xe787ac70, size=0x6000, prot=Variable "prot" is not available. ) at /usr/src/sys/vm/vm_mmap.c:1439 #9 0xc076634f in mmap (td=0xc592fd80, uap=0xe787acf8) at /usr/src/sys/vm/vm_mmap.c:390 #10 0xc07bb6bf in syscall (frame=0xe787ad38) at /usr/src/sys/i386/i386/trap.c:1073 #11 0xc07a0150 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #12 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 6 #6 0xc0761ae7 in vm_map_delete (map=0xc5909e80, start=0x2836e000, end=0x28374000) at /usr/src/sys/vm/vm_map.c:2703 2703 (void) vm_map_unlock_and_wait(map, 0); (kgdb) p *entry $1 = { prev = 0xc5812b40, next = 0xc59ec7e0, left = 0xc5812b40, right = 0xc59ec7e0, start = 0x2836e000, end = 0x2837a000, avail_ssize = 0x0, adj_free = 0x86000, max_free = 0x976e0000, object = { vm_object = 0x0, sub_map = 0x0 }, offset = 0x0, eflags = 0x600, protection = 0x0, max_protection = 0x7, inheritance = 0x1, wired_count = 0xffffffff, lastr = 0x1c, uip = 0x0 } (kgdb) -- John Marshall -------------- 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/20090710/ca3b9720/attachment.pgp From avg at freebsd.org Fri Jul 10 12:27:20 2009 From: avg at freebsd.org (Andriy Gapon) Date: Fri Jul 10 12:27:31 2009 Subject: dtrace users opinion solicited (timestamps) In-Reply-To: References: <4A562960.3010801@freebsd.org> Message-ID: <4A5733A3.20409@freebsd.org> on 10/07/2009 01:02 Andrew Brampton said the following: > According to wikipedia newer Intel processors have a constant rate TSC > whos freq does not change. If this features is available on most > processors today, then I am happy to stick with option 1. > > Another problem with this is that on a multicore machine each core may > have different TSC values. Has anyone thought how to address this > issue? Could we calculate the offset of each core from core0, and then > ensure the offset is applied to the tsc value when it is needed? Yes. The actual code accounts for inter-CPU/core TSC skew. -- Andriy Gapon From kostikbel at gmail.com Fri Jul 10 13:24:36 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Jul 10 13:24:43 2009 Subject: Process stuck in vmmaps on 8.0-BETA1 In-Reply-To: <20090710114234.GF32316@rwpc12.mby.riverwillow.net.au> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> <1247214510.2437.1693.camel@strangepork.london.mintel.ad> <20090710114234.GF32316@rwpc12.mby.riverwillow.net.au> Message-ID: <20090710132429.GA55190@deviant.kiev.zoral.com.ua> On Fri, Jul 10, 2009 at 09:42:34PM +1000, John Marshall wrote: > rwsrv05# procstat 1270 > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM > 1270 1 1270 1270 0 1 john vmmaps FreeBSD ELF32 ntpd > > rwsrv05# procstat -k 1270 > PID TID COMM TDNAME KSTACK > 1270 100184 ntpd - mi_switch sleepq_switch sleepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mmap syscall Xint0x80_syscall > > rwsrv05# procstat -v 1270 > PID START END PRT RES PRES REF SHD FL TP PATH > 1270 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd > 1270 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd > 1270 0x8080000 0x8100000 rw- 128 0 1 0 C- df > 1270 0x2807e000 0x280ab000 r-x 45 0 170 75 CN vn /libexec/ld-elf.so.1 > 1270 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 > 1270 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df > 1270 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 > 1270 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 > 1270 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 > 1270 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 > 1270 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 > 1270 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 > 1270 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df > 1270 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 > 1270 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 > 1270 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 > 1270 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 > 1270 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 > 1270 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 > 1270 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 > 1270 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 > 1270 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 > 1270 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 > 1270 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 > 1270 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 > 1270 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 > 1270 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 > 1270 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 > 1270 0x28358000 0x2836e000 rw- 22 0 1 0 C- df > 1270 0x2836e000 0x2837a000 --- 0 0 0 0 -- -- > 1270 0x28400000 0x28500000 rw- 256 0 1 0 C- df > 1270 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df > > rwsrv05# kgdb kernel.debug /dev/mem > 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"... > #0 sched_switch (td=0xc08af410, newtd=0xc4d4db40, flags=260) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid = PCPU_GET(cpuid); > Ready to go. Enter 'tr' to connect to the remote target > with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port > or 'trf portno' to connect to the remote target with the firewire > interface. portno defaults to 5556. > > Type 'getsyms' after connection to load kld symbols. > > If you're debugging a local system, you can use 'kldsyms' instead > to load the kld symbols. That's a less obnoxious interface. > (kgdb) proc 1270 > [Switching to thread 168 (Thread 100184)]#0 sched_switch (td=0xc592fd80, newtd=0xc4d4db40, flags=0x104) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid = PCPU_GET(cpuid); > (kgdb) bt > #0 sched_switch (td=0xc592fd80, newtd=0xc4d4db40, flags=0x104) at /usr/src/sys/kern/sched_ule.c:1864 > During symbol reading, Incomplete CFI data; unspecified registers at 0xc06009d6. > #1 0xc05e788f in mi_switch (flags=0x104, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:444 > #2 0xc061695c in sleepq_switch (wchan=0xc5909f00, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:505 > #3 0xc06175f5 in sleepq_wait (wchan=0xc5909f00, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:584 > #4 0xc05e7d39 in _sleep (ident=0xc5909f00, lock=0xc0a26724, priority=0x244, wmesg=0xc0837aa0 "vmmaps", timo=0x0) > at /usr/src/sys/kern/kern_synch.c:232 > #5 0xc0761a37 in vm_map_unlock_and_wait (map=0xc5909e80, timo=0x0) at /usr/src/sys/vm/vm_map.c:638 > #6 0xc0761ae7 in vm_map_delete (map=0xc5909e80, start=0x2836e000, end=0x28374000) at /usr/src/sys/vm/vm_map.c:2703 > #7 0xc07634ce in vm_map_fixed (map=0xc5909e80, object=0xc5254990, offset=0x0, start=0x2836e000, length=0x6000, > prot=0x