random FreeBSD panics

[C. P. Ghost]

On Mon, Mar 29, 2010 at 8:27 PM, John Baldwin <jhb at freebsd.org> wrote:
>> To developers: what incentives would help get this issue well-needed
>> attention?  This problem makes kernel debugging, panic analysis, and
>> other console-oriented viewing basically impossible.
>
> I was recently going to look at it.  The somewhat drastic approach I was going
> to take was to add a simple serializing lock around trap_fatal() and a few
> other places that do similar block prints (e.g. mca_log()).  One of the issues
> with fixing this in printf itself is that you'd want probably want to
> serialize complete lines of text on a per-thread basis.  You would want to be
> able to accumulate this line of text across multiple calls to printf (think of
> it as line-buffering ala stdio).  However, some folks may be nervous about
> printf not printing things immediately.
>
> The other issue is that lots of code assumes it can call printf from anywhere
> and everywhere.  Mostly this just means that if you add locking and line-
> buffering to printf(9) you have to be very careful to make sure it works in
> odd places.  Probably a lot of this could be solved by deferring things like
> trap_fatal() until panic() has already been called (which is bde's preferred
> solution I think).

How about serializing all printf(9) through a dedicated kernel thread? Maybe
something as flexible as syslogd for kernel space (klogd), that could also
redirect output to a file, to a serial console etc...?

> John Baldwin

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/