On 22-Jun-01 Dave Cornejo wrote:
> John Baldwin wrote:
>> Actuually, KTR is your friend here. :)  Read the ktr(4) manpage, then
>> compile a
>> kernel with KTR_MASK and KTR_COMPILE set to KTR_INTR|KTR_PROC.  Then when it
>> hangs, break into DDB and look at the longs via 'show ktr' to see if you can
>> locate any interrutps coming in from ahc0 or ahc1.
> 
> Okay - fired up the box, built a kernel off of a 6/18 source snapshot,
> and it hangs in about the same place - however what I get that as soon
> as I touch a key to invoke the debugger from the console, it continues
> merrily booting and I can't break into DDB until way past the
> problem.  In my mind this kind of confirms something is busted in the
> interrupts.

Hrmm, perhaps you are getting an interrupt storm from ahc.  Ok, try this: find
the ahc driver's interrupt handler, and add a printf.  Then see if the printf
fires while the machine is hung.

> Tried looking back through the show ktr output and I'm not 100% clear
> on what it all means - I guess I'm interested in the ithread stuff and
> the only thing I ever see is swi6: tty:sio+ in the trace buffer
> besides what appears to be normal process rescheduling (?) which is
> mostly idle task time...

Unfortunately, clock interrupts can fill the trace buffer up, yes. :(

If rolling back the source tree gets you a working kernel, then you might want
to do a binary search using date tags to narrow down what commit actually broke
things on your box.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to