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
[EMAIL PROTECTED]
------------------------------------------------------------------------
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
