Re: tstile lockups - test case

[christos%zoulas.com@localhost (Christos Zoulas)]

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 
locking
| 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
console.

| 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.

christos