Date: Wed, 30 May 2012 11:56:00 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Larry Rosenman <ler@lerctr.org> Cc: freebsd-current@freebsd.org Subject: Re: No reboot on shutdown -r Message-ID: <CAGH67wTjKLEt3L5%2BQqwiYOb1apAsg8Bv8W3rsZaGU3dnzLy6WA@mail.gmail.com> In-Reply-To: <CAGH67wSbEnfhORzm%2BXDZVan9yW1RqPyYYgovaHoLDL=VJzdUmw@mail.gmail.com> References: <alpine.BSF.2.00.1205301329340.1140@borg> <CAGH67wSbEnfhORzm%2BXDZVan9yW1RqPyYYgovaHoLDL=VJzdUmw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 30, 2012 at 11:50 AM, Garrett Cooper <yanegomi@gmail.com> wrote= : > On Wed, May 30, 2012 at 11:31 AM, Larry Rosenman <ler@lerctr.org> wrote: >> For the last month or so, when I reboot via shtudown -r the machine >> sits at "All Buffers Flushed", and I have to hit it with a IPMI reset. >> >> What can I do to help debug this? >> >> Current rev: >> >> FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r236314: W= ed >> May 30 11:10:24 CDT 2012 >> root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE =A0amd64 >> >> >> I can provide anything else needed. > > =A0 =A0I've noticed some funkiness the last 1-2 times I rebooted by > STABLE-9 box as well where it will hang with ada+mfi/ZFS (two separate > pools), but I didn't think much of it at the time. I really don't like > rebooting that box all that often. > =A0 =A0I have another system that has just ada+ada/ZFS (two separate > pools) with approximately the same src version and it doesn't exhibit > the same issue (but I don't remember the last time I shut it down > cleanly because I've paniced the box screwing around with it a few > times), so while my gut feeling goes towards mfi being wonky or > another hardware difference between the two machines -- the root issue > could be (and probably is) something completely different. To answer your original question, something like this would suffice (this isn't tested, look at man 4 ddb, etc): 1. Build the kernel with ddb/kdb. 2. Setup dumpon to point to a swap partition with enough space to store kernel cores and make sure that /var/crash (or wherever you put your dumps) has enough space to store the [mini]dump. 3. Hit CTRL-ALT-ESC if it hangs. 4. Either issue 'call doadump; reboot' and let the system dump core and post the traceback somewhere like a pastebin, or do 'show alllocks; show allprocs' and have a camera ready to take some pictures from the ddb output. 5. Post the data somewhere and provide links to the output in a reply. Cheers, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wTjKLEt3L5%2BQqwiYOb1apAsg8Bv8W3rsZaGU3dnzLy6WA>