thanks..
I was aware of he race but it looks as if I miscaldulated it somehow..
I will look at the source again and confirm your patch.
As you say, msleep() is of the same form and has the same problems.
On Mon, 1 Jul 2002, David Xu wrote:
> Now let me describe where the race is:
>
> Thread A:
Now let me describe where the race is:
Thread A: | Thread B:
cv_timedwait() | softclock()
| cv_timedwait_end()
setrunqueue() call can be simply removed from cv_timedwait_end(), because there
is a race in softclock() and callout_stop(), when cv_timedwait_end() losts a
race, it means that that thread is already running(wokenup by another thread),
when you setrunqueue() it, of course it will panic.
in cv_tim
Got a weird one. No backtrace. gdb got confused and wouldn't attach
properly.
-Matt
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0xd0c45a
fault code = supervisor write, page
On Sun, 30 Jun 2002, Matthew Dillon wrote:
>Got another one. Different panic, same place.
>
> panic: setrunqueue: bad thread state
> cpuid = 0; lapic.id = 0100
> Debugger("panic")
> Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
> db> trace
> Debugger(c02ec2ba) at Debugger
:others have seen this one too
:and the common element is that it's always in
:setrunqueue() called from an interrupt.
:it is also often via cv_*SOMETHING*()
:
:I Thought we had cleared these up but apparently not :-/
:
There are a bunch of wakeup race conditions in the CV code where
the
others have seen this one too
and the common element is that it's always in
setrunqueue() called from an interrupt.
it is also often via cv_*SOMETHING*()
I Thought we had cleared these up but apparently not :-/
On Sun, 30 Jun 2002, Matthew Dillon wrote:
>Got another one. Different panic,
