Re: umtx/libthr SMP fixes.

On Tue, 3 Jun 2003, Bryan Liesner wrote:

> Actually, no it doesn't.  I was able to use kern_umtx v 1.3 only if I
> removed atapicam from my kernel config.  These patches (now committed?)
> panic the system whether I use atapicam or not.  With kern_umtx v1.2
> there is no panic at all, with or without atapicam. 
> 
> Actually, I think it's cam in general that's causing the panic with
> these changes. 

Bizarre.  Sounds like an errant pointer in some other code, and it's just
a matter of the memory layout as to what gets stepped on.  Alternatively,
it might be affected by the insertion of the MTX sysinit event.  Perhaps
that revision rearranges memory a bit.

Anyhow, here are some things you might consider, since this whole thing is
so odd.  Try merging the addition of the struct mtx declaration from 1.3
into 1.2 and see if you get the same panic.  If you don't, try merging the
MTX_SYSINIT line and see if that triggers the panic.  The other changes
probably wouldn't cause disruptive memory rearrangement, so see what
happens.  If the panics appear with the addition of the variable, it
probably is a memory stepping thing and a bug in some other piece of code
(unfortunately, probably hard to track down).  If it's the addition of the
initializer, it's a different class of problem. 

I have to admit that I'm also fairly baffled: my current reading of the
change suggests there won't be a specific bug in umtx, rather, the
triggering of symptoms from another bug, but I guess we can only find out
with a bit of experimentation.  You might also find the problem
"disappears" if you remove INVARIANTS, although given that you can
reproduce this nicely, I'm reluctant to have you do that for fear the bug
will get away and not get fixed.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Network Associates Laboratories