Mike Tancsa wrote: > At 11:53 AM 06/07/2005, Mike Tancsa wrote: > >> At 11:43 AM 06/07/2005, Scott Long wrote: >> >>> According to the original dmesg, the hang happens well after bus >>> enumeration is complete and interrupts have been enabled. It's >>> happening on a taste I/O from GEOM. >> >> >> Here is a boot -v that is a little more upto date. I am just >> netbooting with various kernel configs to try and sort out whats going >> on. > > > .... > >> atapci0: Lazy allocation of 0x10 bytes rid 0x20 type 4 at 0 >> ata0: <ATA channel 0> on atapci0 >> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 >> atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 >> ata0: reset tp1 mask=00 ostat0=ff ostat1=ff >> ata0: [MPSAFE] >> ata1: <ATA channel 1> on atapci0 >> atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 >> atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 >> >> It totally hangs here and I cant even break into debugger. Its almost >> as if the thing goes into suspend mode ? > > > OK, some more details. I removed the ata code, and it no longer sends > the box to "sleep" or whatever weird state its in. > > Now its stuck again, but I can break into the debugger from the serial > console > I wonder if the AMR interrupt is getting routed to the ata interrupt pins. With the ata driver enabled, the OS gets stuck in an infinite loop of trying to service what it thinks in an ata interrupt. With the ata driver disabled, the ata interrupt lines stay disabled and the OS sees nothing. Would it be possible to send an NMI to the machine while it's hung with the ata driver enabled? If not, we can probably drop some simple printf into the ata interrupt handler. ScottReceived on Wed Jul 06 2005 - 15:09:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:38 UTC