Ian Dowse writes:
 > In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
 > >I see this panic constantly during last month or two, UP machine, no 
 > >softupdates. Anybody else saw it too? Any ideas?
 > The "buffer is not busy" panic is usually a secondary panic that
 > occurs while trying to sync the disks after a different panic.  If
 > possible, try to get the first panic message, or ideally a stack
 > trace.

Why do we dump after sync'ing fs's?  It seems like we should dump
first, then sync later.

Also, with interrupt threads in -current,  panic's are totally
bizzare.  Alphas can't dump because they get into a situation
where some system thread wakes up and can never go to sleep
again (like bufdaemon).  I think the whole set of panicstr
hacks need to be re-thought..

I'd like to do something that (as Julian says) puts a big stick in the
works just after we panic which allows only interrupt threads and
the panic'ing thread to run.  What's the best way to do this?
Should I add to the panicstr hacks, or is there a more elegent way
to achieve this?



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to