Kernel dumps [was Re: possible changes from Panzura]

[Kevin Day]

On Jul 11, 2013, at 4:05 PM, Artem Belevich <art at freebsd.org> wrote:
>  
> 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.

That's the exact reason why we invented our own mini stack and hooks into the network driver. After many failure cases, you can no longer rely on malloc, interrupts, routing tables or other goodies to be working correctly. It's too easy for the rest of the system to be broken enough that touching any of those pieces was enough to crash again.

It really depends on the scope of problem you're trying to debug, but at minimum I think you need to revert to polled networking, disable all interrupts, and use your own stack/memory pool. Even then it's still not foolproof, but at least then you spend less time trying to debug your debugger.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4891 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20130711/9293b20a/attachment.bin>