Panic: zalloc!

[Jon Arney]

Hi there,

This is going to sound a little meandering, but I promise I'm going
somewhere with this.

For several days now I have been enduring a Hurd system which seems to
reboot on me every once in a while when I'm not watching.  Through
plain dumb luck I happened to be in the room with the machine when
it happened (I was re-compiling glibc-2.2.5 natively).  Two interesting
things happened.

1.      The lower-most 'make' in the tree had no children but was not
'doing' anything.  I interrupted it with

$ gdb `which make` <pid-which-i-forget>

It seemed to be 'stuck' in setuid(0) (didn't save the whole backtrace)
but the topmost was intr-msg:118 in something like
_hurd_intr_rpc_msg_...

2.      In the middle of the 'gdb' session (while I'm dutifully
attempting to get details), my 'telnet' session locked up.  I said to
my self "Self, this is not good".

Going to the physical console, I noticed a message 'panic: zalloc....'
and before I could copy it down, the box re-booted on me.

This brings me finally to the point!

Around line 171 of gnumach/kern/debug.c I found the following fragment
from the 'panic' function.  Note the #else case and the argument to
the function 'halt_all_cpus'.  I would like to recommend that the
argument be changed to '0' _OR_ that MACH_KDB be enabled by default
until such panics are not so prevelant, so that when one is not
physically present, one can get information on the panic.  Hindsight
is 20:20 in that I realize I should have enabled the debugger.
Nonetheless, I think my recommendation stands.

#if     MACH_KDB
        Debugger("panic");
#else
        halt_all_cpus (1);
#endif

Humbly yours,

Jon Arney
Software Engineer
jarney1@cox.net
------------------------------------------------------------------------