Date: Fri, 27 Apr 2007 16:29:36 -0600 From: Scott Long <scottl@samsco.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-current@freebsd.org, Tom Cumming <tcumming123@gmail.com>, Steve Kargl <sgk@troutmask.apl.washington.edu>, Kris Kennaway <kris@obsecurity.org> Subject: Re: Panic on boot. How do I get a kernel dump. Message-ID: <46327950.7030900@samsco.org> In-Reply-To: <20070427222116.GG840@turion.vk2pj.dyndns.org> References: <de193d070704231519h671193emdd5f8673246559ad@mail.gmail.com> <20070426204602.GA81382@keltia.freenix.fr> <de193d070704261535k11e5de1eh12842a4ab340a971@mail.gmail.com> <20070427012401.GZ2445@obelix.dsto.defence.gov.au> <20070427013742.GA51877@troutmask.apl.washington.edu> <20070427014317.GA17436@xor.obsecurity.org> <20070427030017.GA52347@troutmask.apl.washington.edu> <20070427031124.GA18527@xor.obsecurity.org> <de193d070704270831y6f57e559xfaf036338c263100@mail.gmail.com> <20070427180021.GA57409@xor.obsecurity.org> <20070427222116.GG840@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: > On 2007-Apr-27 14:00:21 -0400, Kris Kennaway <kris@obsecurity.org> wrote: >> On Fri, Apr 27, 2007 at 08:31:16AM -0700, Tom Cumming wrote: >>> One possibility is to hard code dumpdev in the kernel, then boot that >>> kernel. >> I don't know many different ways I can say "there is no way to do it". > > I think Tom is saying that he needs to do something that _used_ to be > possible. Normally the Project is careful to avoid regressions so > this was a surprise to me as well. (It looks like it's demise wasn't > clearly spelt out at the time). > > Since dumpdev is now intertwined with geom and the geom tasting is > quite late in the boot process, I agree that the current crashdump > code does not seem amenable to use early in the boot process. > > Having a kernel crash before it reaches userland is not unheard of. > Whilst it may be possible to debug this using DDB or remote GDB in > some cases, I can think of two cases where this is not practical: > 1) It is a production server that can't be left down for extended periods. > 2) It is a remote system without remote console access. > > Lets put the original question slightly differently: How can the > kernel state be saved if the kernel crashes before it's possible to > invoke dumpon(8)? IMHO, "there is no way to do it" is not a > satisfactory answer for the reasons above. > Implement network crashdumps. This involves writing a new, separate, stripped down network stack, dealing with network configuration headaches, etc. It it will address the problem, though, albeit with a lot of development effort and pain. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46327950.7030900>