Re: it isn't aa's rwsem-generic-6 bug but something else [Re: aa's rwsem-generic-6 bug? Process stuck in 'R' state.]

[Bob McElrath <rsmcelrath@students.wisc.edu>]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

Andrea Arcangeli [andrea@suse.de] wrote:
> On Thu, Apr 26, 2001 at 12:38:02AM -0500, Bob McElrath wrote:
> > When I posted this bug originally, you came right out and said it was
> > probably the rwsemaphores.  I really have no idea how the rwsemaphores
> 
> You were talking about the ps table hang when I told you about the rwsem
> races. I had the same trouble on my alpha and I reproduced the races
> trivially by lanucing:
> 
> 	make MAKE='make -j2' -j2 &
> 
> 	while :; do ps xa ; sleep 1 ; done
> 
> After a few seconds ps deadlocked. Try that on the old asm semaphores.

This does not cause a hang on my machine with your new rwsemaphores.

> It was 100% reproducible, and after I rewrote the rwsemaphores the
> deadlock gone away completly.
> 
> Your X hanging in R state is completly unrelated to the rwsem ps table
> hang problem as far I can tell.

Ok, so what are the other alternatives?  In the R state, the scheduler
should give it some CPU at the first available jiffy, correct?  After
several minutes it was still stuck in the R state, and had received 0
CPU time.

Could this be a scheduler bug?

Another thing I just noticed: watching the ps list, gcc is getting
called with -mcpu=ev56, which in turn is calling as with -mev6.  Since
this is an ev56 processor, not the newer ev6, this could conceivable be
generating illegal instructions, though I haven't ever seen any kernel
illegal instruction faults.

*Sigh*
-- Bob

Bob McElrath (rsmcelrath@students.wisc.edu) 
Univ. of Wisconsin at Madison, Department of Physics

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]