On Sat, Dec 30, 2000 at 11:46:15AM -0800, Julian Elischer wrote:
> A checkin was just made that fixed a mutex that was being held incorrectly
> in psignal, which features in your stack trace.
>
> It's possible that this has been fixed in the last 24 hours.
Hello Julian!
If you are referring to the commit made by ps to sys/kern/sys_process.c,
than nope, that is not it. I already have the latest revision of that file
and the problem report was sent *after* the upgrade:-( (I was also hoping,
but...)
In the meantime, I compiled and booted a kernel with MUTEX_DEBUG,
reproduced the panic, but the stack trace did not look differently at all.
On the upside, the new option did not render my machine nearly unusable as it
did on a previous occassion when I tried it... as said, disk activity is
unaffected. (And yes, I even can use cvsup to update my sources, so far, so
good. But it is slooooow.)
I am stumped here... I know next to nothing about how the locking system
works but my private theory is that somehow network processes (the actual
network part) do not get their priority right. Eg when I use w3m, the
browsing works as long as I stay on the same page, as works the back
function. But as soon as it has to load a page, it hangs for a long time,
and then is allowed to complete its job burst-like... same for ssh... Next
I will try to see to what extent the console is involved... eg I'll go and
do a network login and see if things are any different...
But surely this is annoying... I had hoped that on New Year's Party FreeBSD
would rock da house:-) (although the mp3 player still works fine, sooo...)
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
