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