Date: Thu, 11 Jul 2013 14:05:54 -0700 From: Artem Belevich <art@freebsd.org> To: "Jordan K. Hubbard" <jordan.hubbard@gmail.com> Cc: hackers@freebsd.org, Kevin Day <toasty@dragondata.com> Subject: Re: Kernel dumps [was Re: possible changes from Panzura] Message-ID: <CAFqOu6j299gbsWh22fTnbKZUFZBVuwwV6M5bcJdH%2Bm%2BCWDin9g@mail.gmail.com> In-Reply-To: <EC032F13-AF97-4A1D-8772-02EF92613DA7@turbofuzz.com> References: <FDEEB55D-823B-4899-8EEC-7F5306D91F5B@elischer.org> <9890DFF1-892A-4DCA-9E33-B70681154F43@mail.turbofuzz.com> <4F0DFAB7-D6D5-4068-A543-C9DF885D1A7D@dragondata.com> <51DEC0E8.7010305@freebsd.org> <EC032F13-AF97-4A1D-8772-02EF92613DA7@turbofuzz.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 11, 2013 at 12:52 PM, Jordan K. Hubbard < jordan.hubbard@gmail.com> wrote: > > On Jul 11, 2013, at 7:27 AM, Julian Elischer <julian@freebsd.org> wrote: > > > I could imagine that we could stash away a vimage stack just for this > purpose. > > yould set it up on boot and leave it detached until you need it. > > > > you just need to switch the interfaces over to the new stack on panic > and put them into 'poll' mode. > > That sounds like a rather clever solution to this problem (OS X doesn't > support vimage, despite repeated attempts on my part to change that). > > It would probably work for most of the crashes, but will not work in few interesting classes of failure. Using in-kernel stack implicitly assumes that your memory allocator still works as both the stack and the interface driver will need to get their mbufs and other data somewhere. Alas it's those unusual cases that are hardest to debug and where you really do want debugger or coredump to work. Back at my previous work we did it 'embedded system way'. Interface driver provided dumb functions to re-init device, send a frame and poll for received frame. All that without using system malloc. There was a dumb malloc that gave few chunks of memory from static buffer to gzip, but the rest of the code was independent of any kernel facilities. We had simple ARP/IP/UDP/TFTP(+gzip) implementation to upload compressed image of physical memory to a specified server. Overall it worked pretty well. Considering that this approach pretty much puts core dump outside of kernel, I wonder if we could start some sort of reverse BTX loader on crash. Instead of downloading the kernel it would upload the core. This way we should be able to produce the core in a fairly generic way on any system where we can use PXE for network I/O. The idea may be a non-starter as I have no clue whether it's possible to use PXE once kernel had booted and took control of NIC hardware. --Artem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFqOu6j299gbsWh22fTnbKZUFZBVuwwV6M5bcJdH%2Bm%2BCWDin9g>