[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: tstile lockups - test case
On Jun 9, 4:02pm, MacPPC2%c.icompute.com@localhost (Donald Lee) wrote:
-- Subject: Re: tstile lockups - test case
| 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?
All 3 options. Yes, they degrade performance but don't make the machine
unusable. You only need them while we debug this. I run with them all the
time but my machine is quite beefy.
| 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.
It will just print messages on the console or panic on the regular
| 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)
Could be, but it could even make it worse and it will happen more frequently.
| 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?
Most locks are not there anyway. I am not sure if locks are optimized to
NO/OP on ppc.
Main Index |
Thread Index |