Date: Tue, 25 Nov 2008 15:02:30 -0500 From: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> To: Frank Solensky <frank@solensky.org> Cc: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: Kernel crash before dumpon Message-ID: <44iqqb4lrd.fsf@be-well.ilk.org> In-Reply-To: <1227635054.6253.16.camel@frank-laptop> (Frank Solensky's message of "Tue\, 25 Nov 2008 12\:44\:14 -0500") References: <1227635054.6253.16.camel@frank-laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
Frank Solensky <frank@solensky.org> writes: Wow. Frank Solensky. Long time no see. > I'm trying to get a dump off a machine with a 7.1-beta2 kernel that's > been crashing during the boot process, following the instructions on > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN > I've recompiled the kernel with "-g" but no vmcore file appears so I'm > assuming that the crash occurs before dumpon is executed. > > The page includes the following suggestion on how I might be able to > proceed: > Alternatively, the dump device can be hard-coded via the > dump clause in the config(5) line of a kernel configuration > file. This approach is deprecated and should be used only > if a kernel is crashing before dumpon(8) can be executed. > > I tried adding > config dump "/dev/ad4s3b" > to the configuration file but that option appears to be no longer > supported: the config command gives an error message of: > root/dump/swap specification obsolete > > Is the paragraph above obsolete? If so, what's the preferred way to > collect the dump? Yep, it looks like the config(8) code to handle that has been gone for a while. At a quick glance, I can't figure out where the dump device is chosen, but it's supposedly iterating through devices looking for something that would work. Sticking in a device closer to the top of the search order might help. I suppose it's possible that just sticking in an appropriately formatted USB disk might help. Enabling minidumps would let you get away with a smaller space for storing the dump, which would be useful if you have some space to throw at it. Alternatively, in the same spot I would be tempted to build a separate disk just for debugging this particular problem, making sure to leave space for a swap partition close to the front. Using DDB might be an option, but I suspect that if you're having trouble getting a dump, you'll have problems dropping to a live debugger as well. All of my above advice is a bit shot-in-the-dark; if no one else suggests anything better, you may want to go to the freebsd-hackers list, or look at the cvs logs for whoever's modified the dump code in the last year or so. Good luck. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44iqqb4lrd.fsf>