On Thu, Feb 28, 2002 at 12:31:48AM -0700, Jon Arney wrote: > 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.
Indeed. There are some bugs, either resource leaks in the Hurd system or in the kernel (or even some other bug). We are currently lacking data to give a good interpretation for the zalloc problems. When we use oskit-mach we can get better data with gdb over serial line. > Going to the physical console, I noticed a message 'panic: zalloc....' > and before I could copy it down, the box re-booted on me. As it should. The binary packages are what comes closest to a "production system, and for such systems rebooting is a much better behaviour than spinning or halting. Imagine a web server, or a remote-adminstrated machine. > 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. There is the gnumach-dbg package, which has the debugger enabled (but is otherwise identical to the other package. Oh, it also has debugging symbols). However, in this particular case, we probably could not make much use of the data anyway. A panic in zalloc is the number one crash fault right now, and can only be attacked by some serious debugging/monitoring efforts (like gathering data about the memory usage of in-kernel structures etc). We might make it a command line option at some time, but this also requires planning ahead ;) Another option is to have some reserved disk blocks for the kernel to write a memory dump (core file) to. Thanks! Marcus _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
