Date: Wed, 06 Jul 2005 13:45:18 -0400 From: Mike Tancsa <mike@sentex.net> To: Scott Long <scottl@samsco.org> Cc: freebsd-current@freebsd.org Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (long) Message-ID: <6.2.1.2.0.20050706134221.07c0ec50@64.7.153.2> In-Reply-To: <42CC1085.6090504@samsco.org> References: <70e8236f05070208212e36c375@mail.gmail.com> <42C6DA5F.9070303@gneto.com> <6.2.1.2.0.20050703212843.07889088@64.7.153.2> <20050705011650.R80892@lexi.siliconlandmark.com> <70e8236f050706002655cd9a0c@mail.gmail.com> <42CBE7F4.9040106@samsco.org> <83fb4207210a3f028b8ee2d2289573c4@xcllnt.net> <42CBFC36.1040406@samsco.org> <6.2.1.2.0.20050706115146.07a59d08@64.7.153.2> <6.2.1.2.0.20050706115824.07a58588@64.7.153.2> <42CC1085.6090504@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 01:10 PM 06/07/2005, Scott Long wrote:
>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?
I can try, how do I do that ? :)
---Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.1.2.0.20050706134221.07c0ec50>