[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: tstile lockups - test case
>In article <email@example.com>,
>Donald Lee <MacPPC2%c.icompute.com@localhost> wrote:
>>At 11:55 PM +0000 3/30/13, Valery Ushakov wrote:
>>>Donald Lee <MacPPC2%c.icompute.com@localhost> wrote:
>>>> At 5:22 PM +0000 3/30/13, Valery Ushakov wrote:
>>>>>Next time it hangs you can break into DDB from console and check with
>>>>>ps (ddb command, not ordinary command; see ddb(4)). I've seen such
>>and it does not fail (so far), so I'm pretty sure it's a macppc-specific
>>Anyone have suggestions on how to track this down? What's the shortest path
>>to my getting enough ddb expertise to help track this down, or getting my
>>test case in the hands of someone with the requisite skill?
>I would stary by running a DIAGNOSTIC/DEBUG/LOCKDEBUG kernel. If that does
>not find the deadlock, at least it will let us look at the locks more easily.
Cool. Just to show how ignorant I am, where would I find such a thing? Do
I have to build it? (It looks like I do. I do know how to build kernels.)
If I build it, should I do all three options? DIAGNOSTIC/DEBUG/LOCKDEBUG?
It sounds like DIAGNOSTIC adds in the ASSERTs, DEBUG adds checking generally,
and LOCKDEBUG adds checking just to the locking machinery. Given that the
machinery is most sensitive to changes in timing for both debug and
performance, how "bad" are these options timing/performance wise?
The serial ports on the newer macs (the ones failing for me) don't really
exist, and where they do, they don't work reliably. I hope debugging can be
done some other way.
You realize, of course, that if I build this DEBUG kernel, the internal timing
will probably change, and the bug may go away. (I suppose if it does, then
I can run that kernel in production as long is the performance isn't too bad)
Come to think of it, since this is a single-CPU machine (all of mine are),
is there a SINGLE_CPU option that makes the locks (mostly) go away?
Main Index |
Thread Index |