Re: Issues with gjournal (heaaaaaaaaaaalp!)
On Wed, Jun 10, 2009 at 10:58 PM, Dan Naumov wrote: > You need to mount your /dev/ad6s1d.journal as /usr and not > /dev/ad6s1d, because this is the new device provided to you by GEOM. > > - Dan Naumov > > > > On Thu, Jun 11, 2009 at 5:50 AM, Garrett Cooper wrote: >> On Wed, Jun 10, 2009 at 7:44 PM, Garrett Cooper wrote: >>> Hi Pawel, ATA, and Stable folks, >>> >>> This time when I did a reinstall I took the bullet and tried to >>> use gjournaling instead of softupdates. The unfortunate thing is that >>> I can't seem to get it to work. >>> >>> Here's the procedure that I'm trying to follow (based off of [1]): >>> - sysinstall from scratch with a minimal distribution. This creates >>> /usr // /dev/ad6s1d as UFS2 with softupdates disabled. >>> - Pull latest stable sources. Rebuild kernel (with `options >>> GEOM_JOURNAL'), world, install kernel, then world after reboot. >>> - gjournal label -f ad6s1d ad6s2d >>> - mount /dev/ad6s1d /usr # That works (I think...), but prints out the >>> error message below: >>> >>> GEOM_JOURNAL: [flush] Error while writing data (error=1) >>> ad6s2d[WRITE(offset=512, length=6656)] >>> >>> gjournal status says: >>> Name Status Components >>> ad6s1d.journal N/A ad6s1d >>> ad6s2d >>> >>> Some issues I noticed: >>> >>> - GJOURNAL ROOT (something) loops infinitely if the device can't be >>> found; this should probably time out and panic / exit if a device >>> becomes unavailable (depends on fstab values in the final 2 fields no >>> doubt). I did this by accident when I forgot to add iir statically to >>> the kernel. >>> - The LiveCD doesn't fully support gjournal (userland's there, kernel >>> support isn't). Kind of annoying and counterproductive... >>> - Existing journal partitions disappeared when I upgraded by accident >>> from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from >>> my server with label=.). That was weird... >>> - When I use gjournal label with an existing filesystem I _must_ use -f. >>> >>> Any help with this endeavor would be more than appreciated, as I want >>> to enable this functionality before I move on to installing X11, as >>> nvidia-driver frequently hardlocks the desktop (or has in the past). >>> >>> Thanks, >>> -Garrett >>> >>> [1] >>> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop/article.html >> >> And to answer another potential question, I've tried mounting both >> with -o rw,async and with -o rw. >> Thanks! >> -Garrett Hi Dan, I'm doing that right now =\... orangebox# mount /dev/ad6s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad6s1d.journal on /usr (ufs, asynchronous, local) /dev/ad6s1e on /usr/home (ufs, local) /dev/ad6s1f on /var (ufs, local) Thanks! -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Issues with gjournal (heaaaaaaaaaaalp!)
You need to mount your /dev/ad6s1d.journal as /usr and not /dev/ad6s1d, because this is the new device provided to you by GEOM. - Dan Naumov On Thu, Jun 11, 2009 at 5:50 AM, Garrett Cooper wrote: > On Wed, Jun 10, 2009 at 7:44 PM, Garrett Cooper wrote: >> Hi Pawel, ATA, and Stable folks, >> >> This time when I did a reinstall I took the bullet and tried to >> use gjournaling instead of softupdates. The unfortunate thing is that >> I can't seem to get it to work. >> >> Here's the procedure that I'm trying to follow (based off of [1]): >> - sysinstall from scratch with a minimal distribution. This creates >> /usr // /dev/ad6s1d as UFS2 with softupdates disabled. >> - Pull latest stable sources. Rebuild kernel (with `options >> GEOM_JOURNAL'), world, install kernel, then world after reboot. >> - gjournal label -f ad6s1d ad6s2d >> - mount /dev/ad6s1d /usr # That works (I think...), but prints out the >> error message below: >> >> GEOM_JOURNAL: [flush] Error while writing data (error=1) >> ad6s2d[WRITE(offset=512, length=6656)] >> >> gjournal status says: >> Name Status Components >> ad6s1d.journal N/A ad6s1d >> ad6s2d >> >> Some issues I noticed: >> >> - GJOURNAL ROOT (something) loops infinitely if the device can't be >> found; this should probably time out and panic / exit if a device >> becomes unavailable (depends on fstab values in the final 2 fields no >> doubt). I did this by accident when I forgot to add iir statically to >> the kernel. >> - The LiveCD doesn't fully support gjournal (userland's there, kernel >> support isn't). Kind of annoying and counterproductive... >> - Existing journal partitions disappeared when I upgraded by accident >> from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from >> my server with label=.). That was weird... >> - When I use gjournal label with an existing filesystem I _must_ use -f. >> >> Any help with this endeavor would be more than appreciated, as I want >> to enable this functionality before I move on to installing X11, as >> nvidia-driver frequently hardlocks the desktop (or has in the past). >> >> Thanks, >> -Garrett >> >> [1] >> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop/article.html > > And to answer another potential question, I've tried mounting both > with -o rw,async and with -o rw. > Thanks! > -Garrett > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Issues with gjournal (heaaaaaaaaaaalp!)
Hi Pawel, ATA, and Stable folks, This time when I did a reinstall I took the bullet and tried to use gjournaling instead of softupdates. The unfortunate thing is that I can't seem to get it to work. Here's the procedure that I'm trying to follow (based off of [1]): - sysinstall from scratch with a minimal distribution. This creates /usr // /dev/ad6s1d as UFS2 with softupdates disabled. - Pull latest stable sources. Rebuild kernel (with `options GEOM_JOURNAL'), world, install kernel, then world after reboot. - gjournal label -f ad6s1d ad6s2d - mount /dev/ad6s1d /usr # That works (I think...), but prints out the error message below: GEOM_JOURNAL: [flush] Error while writing data (error=1) ad6s2d[WRITE(offset=512, length=6656)] gjournal status says: Name Status Components ad6s1d.journal N/A ad6s1d ad6s2d Some issues I noticed: - GJOURNAL ROOT (something) loops infinitely if the device can't be found; this should probably time out and panic / exit if a device becomes unavailable (depends on fstab values in the final 2 fields no doubt). I did this by accident when I forgot to add iir statically to the kernel. - The LiveCD doesn't fully support gjournal (userland's there, kernel support isn't). Kind of annoying and counterproductive... - Existing journal partitions disappeared when I upgraded by accident from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from my server with label=.). That was weird... - When I use gjournal label with an existing filesystem I _must_ use -f. Any help with this endeavor would be more than appreciated, as I want to enable this functionality before I move on to installing X11, as nvidia-driver frequently hardlocks the desktop (or has in the past). Thanks, -Garrett [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop/article.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Issues with gjournal (heaaaaaaaaaaalp!)
On Wed, Jun 10, 2009 at 7:44 PM, Garrett Cooper wrote: > Hi Pawel, ATA, and Stable folks, > > This time when I did a reinstall I took the bullet and tried to > use gjournaling instead of softupdates. The unfortunate thing is that > I can't seem to get it to work. > > Here's the procedure that I'm trying to follow (based off of [1]): > - sysinstall from scratch with a minimal distribution. This creates > /usr // /dev/ad6s1d as UFS2 with softupdates disabled. > - Pull latest stable sources. Rebuild kernel (with `options > GEOM_JOURNAL'), world, install kernel, then world after reboot. > - gjournal label -f ad6s1d ad6s2d > - mount /dev/ad6s1d /usr # That works (I think...), but prints out the > error message below: > > GEOM_JOURNAL: [flush] Error while writing data (error=1) > ad6s2d[WRITE(offset=512, length=6656)] > > gjournal status says: > Name Status Components > ad6s1d.journal N/A ad6s1d > ad6s2d > > Some issues I noticed: > > - GJOURNAL ROOT (something) loops infinitely if the device can't be > found; this should probably time out and panic / exit if a device > becomes unavailable (depends on fstab values in the final 2 fields no > doubt). I did this by accident when I forgot to add iir statically to > the kernel. > - The LiveCD doesn't fully support gjournal (userland's there, kernel > support isn't). Kind of annoying and counterproductive... > - Existing journal partitions disappeared when I upgraded by accident > from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from > my server with label=.). That was weird... > - When I use gjournal label with an existing filesystem I _must_ use -f. > > Any help with this endeavor would be more than appreciated, as I want > to enable this functionality before I move on to installing X11, as > nvidia-driver frequently hardlocks the desktop (or has in the past). > > Thanks, > -Garrett > > [1] > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop/article.html And to answer another potential question, I've tried mounting both with -o rw,async and with -o rw. Thanks! -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Server lock up: kern.maxswzone relate ...
On Wed, 10 Jun 2009, Marc G. Fournier wrote: MGF> MGF> I'm running a couple of brand new servers ... 32G of RAM, very little load MGF> on it right now, and this morning it locked up with that 'kern.maxswzone' MGF> error on the console ... MGF> MGF> The server is running a reasonably current 7.2-STABLE: MGF> MGF> FreeBSD pluto.hub.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 31 14:48:04 MGF> ADT MGF> MGF> And top right now, with everything running, shows no swappping, 19G of Free MGF> memory, 9G of Inact memory ... no reason to do any serious amount of MGF> swapping. MGF> MGF> last pid: 32159; load averages: 0.12, 0.21, 0.47up 0+10:57:56 MGF> 11:53:39 MGF> 573 processes: 1 running, 571 sleeping, 1 zombie MGF> CPU: 2.0% user, 0.0% nice, 1.2% system, 0.0% interrupt, 96.8% idle MGF> Mem: 1331M Active, 9446M Inact, 659M Wired, 35M Cache, 399M Buf, 19G Free MGF> Swap: 32G Total, 32G Free As a workaround, if your machine is usually not going to swap, you can decrease swap space significally, and use otherwise unused partition for crashdumps. For RELENG_7/amd64 with 8G RAM and 16G of swap, on stress tests with tmpfs to avoid such locks I had to tune kern.maxswzone up to 192M, which seems to be kinda overkill... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Server lock up: kern.maxswzone relate ...
On Wednesday 10 June 2009 11:04:48 am Marc G. Fournier wrote: > > I'm running a couple of brand new servers ... 32G of RAM, very little load > on it right now, and this morning it locked up with that 'kern.maxswzone' > error on the console ... > > The server is running a reasonably current 7.2-STABLE: > > FreeBSD pluto.hub.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 31 > 14:48:04 ADT > > And top right now, with everything running, shows no swappping, 19G of > Free memory, 9G of Inact memory ... no reason to do any serious amount of > swapping. > > last pid: 32159; load averages: 0.12, 0.21, 0.47up 0+10:57:56 11:53:39 > 573 processes: 1 running, 571 sleeping, 1 zombie > CPU: 2.0% user, 0.0% nice, 1.2% system, 0.0% interrupt, 96.8% idle > Mem: 1331M Active, 9446M Inact, 659M Wired, 35M Cache, 399M Buf, 19G Free > Swap: 32G Total, 32G Free > > In fact, my other server (same config), has been up 9 days (they were put > online 9 days ago), and tops shows it doing a little bit of swapping, but, > again, huge amounts of Inact memory: > > last pid: 26307; load averages: 0.36, 0.35, 0.36up 9+17:03:48 > 11:57:54 > 680 processes: 2 running, 657 sleeping, 21 zombie > CPU: 0.7% user, 0.0% nice, 0.4% system, 0.0% interrupt, 98.9% idle > Mem: 2915M Active, 25G Inact, 778M Wired, 13M Cache, 399M Buf, 1771M Free > Swap: 32G Total, 1044K Used, 32G Free > > So these servers right now are definitely not feeling any pain ... > > And, based on experiences with another server, I have my /boot/loader.conf > set to: > > kern.maxswzone=67108864 > > So, the question is ... what am I missing? Is there some magical formula > for calculating maxswzone that 7.2 is missing? Some nagios plug-in I > shuld be using to monitor ... what? > > Help? There are changes in 8 that you can ask kib@ to MFC perhaps that help some. They make the kernel kill a process when maxswzone is empty similar to what happens when you run out of swap space. If you break into the debugger and get a crashdump, you can verify 1) that you were swapping, and 2) you can calculate a better value for maxswzone. The problem with making maxswzone really big is that it uses up wired memory that can't be reused for anything else, so you don't just want to blindly use the maximum amount for the swap you have. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic resource_list_alloc 7.2 stable
On Wednesday 10 June 2009 1:15:16 pm M. Warner Losh wrote: > In message: <200906101307.37181@freebsd.org> > John Baldwin writes: > : On Wednesday 10 June 2009 12:45:03 pm Robert wrote: > : > On Wed, 10 Jun 2009 10:38:36 -0400 > : > John Baldwin wrote: > : > > : > > On Wednesday 10 June 2009 9:19:13 am Robert wrote: > : > > > On Mon, 8 Jun 2009 10:45:39 -0400 > : > > > John Baldwin wrote: > : > > > > : > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: > : > > > > > Greetings > : > > > > > > : > > > > > This problem seems the same as this one from May of this year > : > > > > > > : > > > > > > : http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > : > > > > > > : > > : > > : > > : > > > > > : > > > I have installed 7.2 on the laptop because it would panic whenever > : > > > going into multiuser. I would prefer to be on stable. > : > > > > : > > > Here is dmesg.boot. I hope that is what you wanted. > : > > > : > > Hmm, can you get the stack trace from the dump that you have? I'm > : > > curious which device driver is triggering the panic. > : > > > : > > : > (kgdb) bt > : > #0 doadump () at pcpu.h:196 > : > #1 0xc07e4b47 in boot (howto=260) > : > at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic > : > (fmt=Variable "fmt" is not available. ) > : > at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in > : > resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, > : > type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > : > at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in > : > pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, > : > rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > : > at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource > : > (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, > : > count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in > : > cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, > : > callbacks=0xd528a9e4, argp=0xc2a65000) > : > at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in > : > cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) > : > at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in > : > devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 > : > : Hmmm, ok. So the problem appears to be that the cardbus code that parses the > : CIS wants to allocate a resource belonging to a cardbus card device that has > : already been allocated by that device's driver. Warner, what is the best way > : to handle this do you think? Does the bus_alloc_resource() method for a > : cardbus bus need to proxy resource requests to the CIS resource perhaps? > > I thought I already fixed this. We snag the cardbus CIS now on attach > rather than at open time. We just need to MFC it. Oh, ok, that would make sense. Is it easy to merge to 7? > The problem isn't that we're allocating a resource that the device > owns, so much, as that there are technical hurdles to accessing the > CIS after the initial parsing *nod* -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Xorg keyboard and mouse hung
On 10 jun 2009, at 18:58, Paul Schmehl wrote: --On Wednesday, June 10, 2009 10:02:39 -0500 Ben Stuyts > wrote: I've upgrade two FreeBSD 7-stable workstations to the latest kernel/ world of today, and now the mouse and keyboard don't react anymore in the Xorg / KDE login window. Mouse doesn't move, keyboard characters don't appear in the login prompt. I can still switch back with ctl- alt- F1 to a console login, and there both the keyboard and mouse still work. I have attached dmesg.boot and Xorg.0.log. I'm not using a xorg.conf as the default settings used to work fine. Any ideas? Sure. In your Xorg.0.log file: "(==) ModulePath set to "/usr/local/lib/xorg/modules" (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput" add dbus_enable="YES" and hald_enable="YES" to /etc/rc.conf. Then start them both manually (/usr/local/etc/rc.d/hald start and /usr/ local/etc/rc.d/dbus start). Then restart X (Ctrl-Alt-Bkspc) I missed that somehow in UPDATING. Thanks! Kind regards, Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic resource_list_alloc 7.2 stable
In message: <200906101307.37181@freebsd.org> John Baldwin writes: : On Wednesday 10 June 2009 12:45:03 pm Robert wrote: : > On Wed, 10 Jun 2009 10:38:36 -0400 : > John Baldwin wrote: : > : > > On Wednesday 10 June 2009 9:19:13 am Robert wrote: : > > > On Mon, 8 Jun 2009 10:45:39 -0400 : > > > John Baldwin wrote: : > > > : > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: : > > > > > Greetings : > > > > > : > > > > > This problem seems the same as this one from May of this year : > > > > > : > > > > > : http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html : > > > > > : > : > : > : > > > > : > > > I have installed 7.2 on the laptop because it would panic whenever : > > > going into multiuser. I would prefer to be on stable. : > > > : > > > Here is dmesg.boot. I hope that is what you wanted. : > > : > > Hmm, can you get the stack trace from the dump that you have? I'm : > > curious which device driver is triggering the panic. : > > : > : > (kgdb) bt : > #0 doadump () at pcpu.h:196 : > #1 0xc07e4b47 in boot (howto=260) : > at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic : > (fmt=Variable "fmt" is not available. ) : > at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in : > resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, : > type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) : > at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in : > pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, : > rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) : > at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource : > (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, : > count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in : > cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, : > callbacks=0xd528a9e4, argp=0xc2a65000) : > at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in : > cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) : > at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in : > devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 : : Hmmm, ok. So the problem appears to be that the cardbus code that parses the : CIS wants to allocate a resource belonging to a cardbus card device that has : already been allocated by that device's driver. Warner, what is the best way : to handle this do you think? Does the bus_alloc_resource() method for a : cardbus bus need to proxy resource requests to the CIS resource perhaps? I thought I already fixed this. We snag the cardbus CIS now on attach rather than at open time. We just need to MFC it. The problem isn't that we're allocating a resource that the device owns, so much, as that there are technical hurdles to accessing the CIS after the initial parsing Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic resource_list_alloc 7.2 stable
On Wednesday 10 June 2009 12:45:03 pm Robert wrote: > On Wed, 10 Jun 2009 10:38:36 -0400 > John Baldwin wrote: > > > On Wednesday 10 June 2009 9:19:13 am Robert wrote: > > > On Mon, 8 Jun 2009 10:45:39 -0400 > > > John Baldwin wrote: > > > > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: > > > > > Greetings > > > > > > > > > > This problem seems the same as this one from May of this year > > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > > > > > > > > > > > > > > I have installed 7.2 on the laptop because it would panic whenever > > > going into multiuser. I would prefer to be on stable. > > > > > > Here is dmesg.boot. I hope that is what you wanted. > > > > Hmm, can you get the stack trace from the dump that you have? I'm > > curious which device driver is triggering the panic. > > > > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc07e4b47 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic > (fmt=Variable "fmt" is not available. ) > at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in > resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, > type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in > pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, > rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource > (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, > count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in > cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, > callbacks=0xd528a9e4, argp=0xc2a65000) > at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in > cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) > at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in > devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 Hmmm, ok. So the problem appears to be that the cardbus code that parses the CIS wants to allocate a resource belonging to a cardbus card device that has already been allocated by that device's driver. Warner, what is the best way to handle this do you think? Does the bus_alloc_resource() method for a cardbus bus need to proxy resource requests to the CIS resource perhaps? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Xorg keyboard and mouse hung
--On Wednesday, June 10, 2009 10:02:39 -0500 Ben Stuyts wrote: Hi, I've upgrade two FreeBSD 7-stable workstations to the latest kernel/ world of today, and now the mouse and keyboard don't react anymore in the Xorg / KDE login window. Mouse doesn't move, keyboard characters don't appear in the login prompt. I can still switch back with ctl-alt- F1 to a console login, and there both the keyboard and mouse still work. I have attached dmesg.boot and Xorg.0.log. I'm not using a xorg.conf as the default settings used to work fine. Any ideas? Sure. In your Xorg.0.log file: "(==) ModulePath set to "/usr/local/lib/xorg/modules" (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput" add dbus_enable="YES" and hald_enable="YES" to /etc/rc.conf. Then start them both manually (/usr/local/etc/rc.d/hald start and /usr/local/etc/rc.d/dbus start). Then restart X (Ctrl-Alt-Bkspc) -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** Check the headers before clicking on Reply. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step
Scott Long wrote: Andre Oppermann wrote: Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big nasty surprise with the Areca RAID controller: arcmsr0: mem 0xfdbff000-0xfdb40 irq16 at device 14.0 on pci18 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 arcmsr0: [ITHREAD] ... (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config From here on it hangs and repeats the last message with some sort of exponential backoff. Ctrl-Alt-Del to reboot doesn't work but ScrollLock does. Hard reset is required to reboot. Booting the old 6.4 kernel works and the system comes up again with full access to the RAID array. Any help appreciated. I'll try to reproduce this locally. There have been sporadic reports of the "fails comparison" problem, but none as fatal as this. Is it possible to compile your kernel with CAMDEBUG and CAM_DEBUG_FLAGS=CAM_DEBUG_INFO? CAMDEBUG doesn't give any output. As it turns out the hang seems to be related to an interrupt routing problem somehow. I did an BIOS upgrade and BIOS settings factory reset. The mainboard is an ASUS M2N32 WS Professional with an Athlon64 X2 4800+. Enabling all on-board devices including ATA and various SATA controllers together with "PnP OS" set to yes fixed the hand and allowed FreeBSD 7 to boot sucessfully. Why 6.4 doesn't stumble I don't know. The "(probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step" line is still there. Fortunately the boot process simply continues from there without further trouble. If there are any other CAM debug options or patches you want me to try I can do that. The system is only in partial production and I'm allowed to reboot it during workhours. -- Andre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic resource_list_alloc 7.2 stable
On Wed, 10 Jun 2009 10:38:36 -0400 John Baldwin wrote: > On Wednesday 10 June 2009 9:19:13 am Robert wrote: > > On Mon, 8 Jun 2009 10:45:39 -0400 > > John Baldwin wrote: > > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: > > > > Greetings > > > > > > > > This problem seems the same as this one from May of this year > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > > > > > > > > I have installed 7.2 on the laptop because it would panic whenever > > going into multiuser. I would prefer to be on stable. > > > > Here is dmesg.boot. I hope that is what you wanted. > > Hmm, can you get the stack trace from the dump that you have? I'm > curious which device driver is triggering the panic. > (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e4b47 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, callbacks=0xd528a9e4, argp=0xc2a65000) at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 #9 0xc0affad2 in VOP_OPEN_APV (vop=0xc0c4f840, a=0xd528aa88) at vnode_if.c:371 #10 0xc0873329 in vn_open_cred (ndp=0xd528ab7c, flagp=0xd528ac78, cmode=1, cred=0xc2ab3d00, fp=0xc2a4be40) at vnode_if.h:199 #11 0xc0873473 in vn_open (ndp=0xd528ab7c, flagp=0xd528ac78, cmode=1, fp=0xc2a4be40) at /usr/src/sys/kern/vfs_vnops.c:94 #12 0xc0870b7d in kern_open (td=0xc2a91d80, path=0xbfbfef32 , pathseg=UIO_USERSPACE, flags=1, mode=1) at /usr/src/sys/kern/vfs_syscalls.c:1042 #13 0xc08710f0 in open (td=0xc2a91d80, uap=0xd528acfc) at /usr/src/sys/kern/vfs_syscalls.c:1009 #14 0xc0ae9405 in syscall (frame=0xd528ad38) at /usr/src/sys/i386/i386/trap.c:1090 #15 0xc0ace1e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #16 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) Thanks again Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic resource_list_alloc 7.2 stable
On Wednesday 10 June 2009 9:19:13 am Robert wrote:
> On Mon, 8 Jun 2009 10:45:39 -0400
> John Baldwin wrote:
>
> > On Saturday 06 June 2009 10:14:31 am Robert wrote:
> > > Greetings
> > >
> > > This problem seems the same as this one from May of this year
> > >
> > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html
> > >
> > > This happens on an older HP laptop. It was running on 7.1 prerelease
> > > fine and then I updated to 7.2 Stable yesterday.
> > >
> > > FreeBSD hp.shasta204.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri
> > > Jun 5 11:47:29 PDT 2009
> > > r...@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA i386
> > >
> > > The bits from pciconf
> > >
> > > atap...@pci0:0:7:1: class=0x010180 card=0x
> > > chip=0x71118086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation'
> > > device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller'
> > > class = mass storage
> > > subclass = ATA
> > >
> > > The date of ata-chipset.c
> > >
> > > -rw-r--r-- 1 root wheel 188823 May 22 02:21 ata-chipset.c
> > >
> > > The chipset is found in the above file
> > >
> > > ata_intel_ident(device_t dev)
> > > {
> > > struct ata_pci_controller *ctlr = device_get_softc(dev);
> > > static struct ata_chip_id ids[] =
> > > {{ ATA_I82371FB, 0,0, 2, ATA_WDMA2, "PIIX" },
> > > { ATA_I82371SB, 0,0, 2, ATA_WDMA2, "PIIX3" },
> > > { ATA_I82371AB, 0,0, 2, ATA_UDMA2, "PIIX4" },
> > > ^^^
> > > { ATA_I82443MX, 0,0, 2, ATA_UDMA2, "PIIX4" },
> > >
> > > I can include the dump if needed but I am not at this time to
> > > shorten the email. But here is the panic.
> > >
> > > Dump header from device /dev/ad0s1b
> > > Architecture: i386
> > > Architecture Version: 2
> > > Dump Length: 68939776B (65 MB)
> > > Blocksize: 512
> > > Dumptime: Sat Jun 6 05:40:52 2009
> > > Hostname: hp.shasta204.local
> > > Magic: FreeBSD Kernel Dump
> > > Version String: FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT
> > > 2009 r...@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA
> > > Panic String: resource_list_alloc: resource entry is busy
> > > Dump Parity: 3285399556
> > > Bounds: 1
> > > Dump Status: good
> > >
> > >
> > > Any help would be greatly appreciated.
> >
> > The last screen of the dmesg output would be helpful.
> >
> I have installed 7.2 on the laptop because it would panic whenever
> going into multiuser. I would prefer to be on stable.
>
> Here is dmesg.boot. I hope that is what you wanted.
Hmm, can you get the stack trace from the dump that you have? I'm curious
which device driver is triggering the panic.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Dell R710 4GB PERC 6/i crashing on high I/O
Hello all, I wanted to ask if anyone had issues with Dell R710 4GB with PERC 6/i on heavy I/O. I cannot for sure determine that the issue is indeed with the PERC 6/i controller or hardware problem. I got the following output after some hammering with creating localy files 1-10GB with dd and doing rsync via the network interface. I've attached the pictures from the KVM. First one is with the box before upgrade to BIOS 1.1.4 and firmware of PERC 6/i to 6.2.0.0.13 Second one is after the upgrade. Any ideas ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step
Andre Oppermann wrote: Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big nasty surprise with the Areca RAID controller: arcmsr0: mem 0xfdbff000-0xfdb40 irq16 at device 14.0 on pci18 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 arcmsr0: [ITHREAD] ... (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config From here on it hangs and repeats the last message with some sort of exponential backoff. Ctrl-Alt-Del to reboot doesn't work but ScrollLock does. Hard reset is required to reboot. Booting the old 6.4 kernel works and the system comes up again with full access to the RAID array. Any help appreciated. I'll try to reproduce this locally. There have been sporadic reports of the "fails comparison" problem, but none as fatal as this. Is it possible to compile your kernel with CAMDEBUG and CAM_DEBUG_FLAGS=CAM_DEBUG_INFO? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Server lock up: kern.maxswzone relate ...
I'm running a couple of brand new servers ... 32G of RAM, very little load on it right now, and this morning it locked up with that 'kern.maxswzone' error on the console ... The server is running a reasonably current 7.2-STABLE: FreeBSD pluto.hub.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 31 14:48:04 ADT And top right now, with everything running, shows no swappping, 19G of Free memory, 9G of Inact memory ... no reason to do any serious amount of swapping. last pid: 32159; load averages: 0.12, 0.21, 0.47up 0+10:57:56 11:53:39 573 processes: 1 running, 571 sleeping, 1 zombie CPU: 2.0% user, 0.0% nice, 1.2% system, 0.0% interrupt, 96.8% idle Mem: 1331M Active, 9446M Inact, 659M Wired, 35M Cache, 399M Buf, 19G Free Swap: 32G Total, 32G Free In fact, my other server (same config), has been up 9 days (they were put online 9 days ago), and tops shows it doing a little bit of swapping, but, again, huge amounts of Inact memory: last pid: 26307; load averages: 0.36, 0.35, 0.36up 9+17:03:48 11:57:54 680 processes: 2 running, 657 sleeping, 21 zombie CPU: 0.7% user, 0.0% nice, 0.4% system, 0.0% interrupt, 98.9% idle Mem: 2915M Active, 25G Inact, 778M Wired, 13M Cache, 399M Buf, 1771M Free Swap: 32G Total, 1044K Used, 32G Free So these servers right now are definitely not feeling any pain ... And, based on experiences with another server, I have my /boot/loader.conf set to: kern.maxswzone=67108864 So, the question is ... what am I missing? Is there some magical formula for calculating maxswzone that 7.2 is missing? Some nagios plug-in I shuld be using to monitor ... what? Help? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scra...@hub.org MSN . scra...@hub.org Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step
Mike Tancsa wrote: At 08:19 AM 6/10/2009, Andre Oppermann wrote: Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big nasty surprise with the Areca RAID controller: arcmsr0: mem 0xfdbff000-0xfdb40 irq16 at device 14.0 on pci18 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 arcmsr0: [ITHREAD] ... (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config As a further datapoint, I see no problems with amd64 RELENG_7 from May 20th, though I am running an older firmware version. I also don't appear to receive the probe error the two of you are seeing. arcmsr0: > mem 0xf450-0xf4500fff,0xf400-0xf43f irq 18 at device 14.0 on pci7 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 arcmsr0: [ITHREAD] da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: Command Queueing Enabled da0: 1831054MB (374616 512 byte sectors: 255H 63S/T 233426C) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: buildworld fails with "WITHOUT_CDDL=yes" in src.conf
Thanks Kip I greatly appreciate the fix!___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step
Mike Tancsa wrote: At 08:19 AM 6/10/2009, Andre Oppermann wrote: Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big nasty surprise with the Areca RAID controller: arcmsr0: mem 0xfdbff000-0xfdb40 irq16 at device 14.0 on pci18 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 arcmsr0: [ITHREAD] ... (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config Not sure if its a firmware issue or not, but I am running an AMD64 RELENG_7 kernel from Apr 23 and its works fine. The DV1 error seems "normal" in that I get it as well. I dont boot off the controller, so not sure if thats part of the issue or not. I did an firmware update after I encountered the issue the first time. Before it was V1.43. Exactly the same behavior. And yes, I do have to boot off the RAID. After the run_interrupt_driven_hooks everything hangs and no daX drives are ever detected. You don't seem to get this particular error. -- Andre arcmsr0: mem 0xea60-0xea600fff irq 18 at device 14.0 on pci3 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.44 2008-2-1 arcmsr0: [ITHREAD] (probe48:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step da1 at arcmsr0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da1: Command Queueing Enabled da1: 76293MB (156249600 512 byte sectors: 255H 63S/T 9726C) da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers da0: 66747MB (136697856 512 byte sectors: 255H 63S/T 8509C) da2 at arcmsr0 bus 0 target 0 lun 1 da2: Fixed Direct Access SCSI-5 device da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da2: Command Queueing Enabled da2: 2784728MB (5703123456 512 byte sectors: 255H 63S/T 355003C) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step
At 08:19 AM 6/10/2009, Andre Oppermann wrote: Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big nasty surprise with the Areca RAID controller: arcmsr0: mem 0xfdbff000-0xfdb40 irq16 at device 14.0 on pci18 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 arcmsr0: [ITHREAD] ... (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config Not sure if its a firmware issue or not, but I am running an AMD64 RELENG_7 kernel from Apr 23 and its works fine. The DV1 error seems "normal" in that I get it as well. I dont boot off the controller, so not sure if thats part of the issue or not. arcmsr0: mem 0xea60-0xea600fff irq 18 at device 14.0 on pci3 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.44 2008-2-1 arcmsr0: [ITHREAD] (probe48:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step da1 at arcmsr0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da1: Command Queueing Enabled da1: 76293MB (156249600 512 byte sectors: 255H 63S/T 9726C) da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers da0: 66747MB (136697856 512 byte sectors: 255H 63S/T 8509C) da2 at arcmsr0 bus 0 target 0 lun 1 da2: Fixed Direct Access SCSI-5 device da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da2: Command Queueing Enabled da2: 2784728MB (5703123456 512 byte sectors: 255H 63S/T 355003C) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic resource_list_alloc 7.2 stable
On Mon, 8 Jun 2009 10:45:39 -0400
John Baldwin wrote:
> On Saturday 06 June 2009 10:14:31 am Robert wrote:
> > Greetings
> >
> > This problem seems the same as this one from May of this year
> >
> > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html
> >
> > This happens on an older HP laptop. It was running on 7.1 prerelease
> > fine and then I updated to 7.2 Stable yesterday.
> >
> > FreeBSD hp.shasta204.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri
> > Jun 5 11:47:29 PDT 2009
> > r...@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA i386
> >
> > The bits from pciconf
> >
> > atap...@pci0:0:7:1: class=0x010180 card=0x
> > chip=0x71118086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation'
> > device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller'
> > class = mass storage
> > subclass = ATA
> >
> > The date of ata-chipset.c
> >
> > -rw-r--r-- 1 root wheel 188823 May 22 02:21 ata-chipset.c
> >
> > The chipset is found in the above file
> >
> > ata_intel_ident(device_t dev)
> > {
> > struct ata_pci_controller *ctlr = device_get_softc(dev);
> > static struct ata_chip_id ids[] =
> > {{ ATA_I82371FB, 0,0, 2, ATA_WDMA2, "PIIX" },
> > { ATA_I82371SB, 0,0, 2, ATA_WDMA2, "PIIX3" },
> > { ATA_I82371AB, 0,0, 2, ATA_UDMA2, "PIIX4" },
> > ^^^
> > { ATA_I82443MX, 0,0, 2, ATA_UDMA2, "PIIX4" },
> >
> > I can include the dump if needed but I am not at this time to
> > shorten the email. But here is the panic.
> >
> > Dump header from device /dev/ad0s1b
> > Architecture: i386
> > Architecture Version: 2
> > Dump Length: 68939776B (65 MB)
> > Blocksize: 512
> > Dumptime: Sat Jun 6 05:40:52 2009
> > Hostname: hp.shasta204.local
> > Magic: FreeBSD Kernel Dump
> > Version String: FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT
> > 2009 r...@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA
> > Panic String: resource_list_alloc: resource entry is busy
> > Dump Parity: 3285399556
> > Bounds: 1
> > Dump Status: good
> >
> >
> > Any help would be greatly appreciated.
>
> The last screen of the dmesg output would be helpful.
>
I have installed 7.2 on the laptop because it would panic whenever
going into multiuser. I would prefer to be on stable.
Here is dmesg.boot. I hope that is what you wanted.
Thank you
Robert
dmesg.boot
Description: Binary data
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
(probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step
Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big nasty surprise with the Areca RAID controller: arcmsr0: mem 0xfdbff000-0xfdb40 irq16 at device 14.0 on pci18 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 arcmsr0: [ITHREAD] ... (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config From here on it hangs and repeats the last message with some sort of exponential backoff. Ctrl-Alt-Del to reboot doesn't work but ScrollLock does. Hard reset is required to reboot. Booting the old 6.4 kernel works and the system comes up again with full access to the RAID array. Any help appreciated. -- Andre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_7 tinderbox] failure on i386/i386
TB --- 2009-06-10 06:35:37 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-10 06:35:37 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2009-06-10 06:35:37 - cleaning the object tree TB --- 2009-06-10 06:35:52 - cvsupping the source tree TB --- 2009-06-10 06:35:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2009-06-10 06:36:03 - building world TB --- 2009-06-10 06:36:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-10 06:36:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-10 06:36:03 - TARGET=i386 TB --- 2009-06-10 06:36:03 - TARGET_ARCH=i386 TB --- 2009-06-10 06:36:03 - TZ=UTC TB --- 2009-06-10 06:36:03 - __MAKE_CONF=/dev/null TB --- 2009-06-10 06:36:03 - cd /src TB --- 2009-06-10 06:36:03 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 10 06:36:04 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/load_elf64.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/load_elf64_obj.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/reloc_elf64.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/bcache.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/isapnp.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/pnp.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/interp_forth.c make: don't know how to make /obj/src/sys/boot/i386/loader/../../zfs/libzfsboot.a. Stop *** Error code 2 Stop in /src/sys/boot/i386. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Sto
unionfs & unlocking unheld lock
hi, sporadically, I see this: lockmgr: thread 0xff0004a8b390 unlocking unheld lock KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _lockmgr() at _lockmgr+0x6ae VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 unionfs_unlock() at unionfs_unlock+0x22f VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 vn_read() at vn_read+0x264 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x8017545bc, rsp = 0x7fffaf98, rbp = 0x7fffb025 --- sf-02> zgrep 'unlocking unheld lock' /var/log/messages* /var/log/messages:May 25 03:03:37 sf-02 kernel: lockmgr: thread 0xff0004ed0720 unlocking unheld lock /var/log/messages:May 31 03:03:10 sf-02 kernel: lockmgr: thread 0xff0004ed6ab0 unlocking unheld lock /var/log/messages:Jun 10 03:03:19 sf-02 kernel: lockmgr: thread 0xff0004a8b390 unlocking unheld lock it happens around 3 am, so I guess it must be some daily script that trips this. danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
