[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Panic: zalloc!

From: Marcus Brinkmann
Subject: Re: Panic: zalloc!
Date: Fri, 1 Mar 2002 20:56:44 -0800
User-agent: Mutt/1.2.5i

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

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]