Kernel dumps [was Re: possible changes from Panzura]

[Artem Belevich]

On Thu, Jul 11, 2013 at 12:52 PM, Jordan K. Hubbard <
jordan.hubbard at gmail.com> wrote:

>
> On Jul 11, 2013, at 7:27 AM, Julian Elischer <julian at 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