Prev: task_io_accounting, taskstats
Next: [PATCH] ipconfig: document DHCP hostname and DNS record
From: Marc Dionne on 2 Jun 2010 22:00
Since somewhere early in the 2.6.35 merge window I've been seeing a
hang during boot. The hang last roughly 30 seconds and is followed by
this:

ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
ata4.00: failed command: READ FPDMA QUEUED
ata4.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 ncq 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata4.00: status: { DRDY }
ata4: hard resetting link
ahci_is_device_present: status is: 80
ahci_is_device_present: status(2) is: 3
ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4.00: configured for UDMA/133
ata4.00: device reported invalid CHS sector 0
ata4: EH complete

The system works normally once booted. I had some time to do a bisect
today and it cleanly ended up pointing to this commit:
96d60303fd: ahci: Turn off DMA engines when there's no device attached

Reverting the commit makes the system boot cleanly as before. System
has an Intel ICH10 based board, in AHCI mode, disk is an Intel X25M
SSD.

Marc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 2 Jun 2010 22:10
On Wed, Jun 02, 2010 at 09:49:27PM -0400, Marc Dionne wrote:
> Since somewhere early in the 2.6.35 merge window I've been seeing a hang
> during boot. The hang last roughly 30 seconds and is followed by this:
>
> ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
> ata4.00: failed command: READ FPDMA QUEUED
> ata4.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 ncq 4096 in
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata4.00: status: { DRDY }
> ata4: hard resetting link
> ahci_is_device_present: status is: 80
> ahci_is_device_present: status(2) is: 3
> ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata4.00: configured for UDMA/133
> ata4.00: device reported invalid CHS sector 0
> ata4: EH complete
>
> The system works normally once booted. I had some time to do a bisect
> today and it cleanly ended up pointing to this commit:
> 96d60303fd: ahci: Turn off DMA engines when there's no device attached
>
> Reverting the commit makes the system boot cleanly as before. System has
> an Intel ICH10 based board, in AHCI mode, disk is an Intel X25M SSD.

Hm, interesting. Jeff, any immediate ideas? I don't see this behaviour
on my ICH10. Is there actually a device on ata4?

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Marc Dionne on 2 Jun 2010 22:20
On Wed, Jun 2, 2010 at 10:00 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> On Wed, Jun 02, 2010 at 09:49:27PM -0400, Marc Dionne wrote:
>> � �Since somewhere early in the 2.6.35 merge window I've been seeing a hang
>> � �during boot. �The hang last roughly 30 seconds and is followed by this:
>>
>> � �ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
>> � �ata4.00: failed command: READ FPDMA QUEUED
>> � �ata4.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 ncq 4096 in
>> � � � � � � res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
>> � �ata4.00: status: { DRDY }
>> � �ata4: hard resetting link
>> � �ahci_is_device_present: status is: 80
>> � �ahci_is_device_present: status(2) is: 3
>> � �ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>> � �ata4.00: configured for UDMA/133
>> � �ata4.00: device reported invalid CHS sector 0
>> � �ata4: EH complete
>>
>> � �The system works normally once booted. �I had some time to do a bisect
>> � �today and it cleanly ended up pointing to this commit:
>> � � � �96d60303fd: ahci: Turn off DMA engines when there's no device attached
>>
>> � �Reverting the commit makes the system boot cleanly as before. �System has
>> � �an Intel ICH10 based board, in AHCI mode, disk is an Intel X25M SSD.
>
> Hm, interesting. Jeff, any immediate ideas? I don't see this behaviour
> on my ICH10. Is there actually a device on ata4?
>
> --
> Matthew Garrett | mjg59(a)srcf.ucam.org

Yes, ata4 is the Intel SSD:

ata4.00: ATA-7: INTEL SSDSA2MH080G1GC, 045C8610, max UDMA/133

Marc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Marc Dionne on 3 Jun 2010 21:30
On Wed, Jun 2, 2010 at 10:00 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> On Wed, Jun 02, 2010 at 09:49:27PM -0400, Marc Dionne wrote:
>>    Since somewhere early in the 2.6.35 merge window I've been seeing a hang
>>    during boot.  The hang last roughly 30 seconds and is followed by this:
>>
>>    ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
>>    ata4.00: failed command: READ FPDMA QUEUED
>>    ata4.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 ncq 4096 in
>>             res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
>>    ata4.00: status: { DRDY }
>>    ata4: hard resetting link
>>    ahci_is_device_present: status is: 80
>>    ahci_is_device_present: status(2) is: 3
>>    ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>>    ata4.00: configured for UDMA/133
>>    ata4.00: device reported invalid CHS sector 0
>>    ata4: EH complete
>>
>>    The system works normally once booted.  I had some time to do a bisect
>>    today and it cleanly ended up pointing to this commit:
>>        96d60303fd: ahci: Turn off DMA engines when there's no device attached
>>
>>    Reverting the commit makes the system boot cleanly as before.  System has
>>    an Intel ICH10 based board, in AHCI mode, disk is an Intel X25M SSD.
>
> Hm, interesting. Jeff, any immediate ideas? I don't see this behaviour
> on my ICH10. Is there actually a device on ata4?
>
> --
> Matthew Garrett | mjg59(a)srcf.ucam.org

If it's helpful, attached are the dmesg output following a normal boot
and one with the hang.

The only difference in the kernel used for those two boots is that the
return statement in ahci_start_engine following the call to
ahci_is_device_present is commented out for the normal boot case.
When the return statement is active, the 30 second hang occurs.

Marc
From: Robert Hancock on 3 Jun 2010 23:50
On 06/03/2010 07:21 PM, Marc Dionne wrote:
> On Wed, Jun 2, 2010 at 10:00 PM, Matthew Garrett<mjg59(a)srcf.ucam.org> wrote:
>> On Wed, Jun 02, 2010 at 09:49:27PM -0400, Marc Dionne wrote:
>>> Since somewhere early in the 2.6.35 merge window I've been seeing a hang
>>> during boot. The hang last roughly 30 seconds and is followed by this:
>>>
>>> ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
>>> ata4.00: failed command: READ FPDMA QUEUED
>>> ata4.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 ncq 4096 in
>>> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
>>> ata4.00: status: { DRDY }
>>> ata4: hard resetting link
>>> ahci_is_device_present: status is: 80
>>> ahci_is_device_present: status(2) is: 3
>>> ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>>> ata4.00: configured for UDMA/133
>>> ata4.00: device reported invalid CHS sector 0
>>> ata4: EH complete
>>>
>>> The system works normally once booted. I had some time to do a bisect
>>> today and it cleanly ended up pointing to this commit:
>>> 96d60303fd: ahci: Turn off DMA engines when there's no device attached
>>>
>>> Reverting the commit makes the system boot cleanly as before. System has
>>> an Intel ICH10 based board, in AHCI mode, disk is an Intel X25M SSD.
>>
>> Hm, interesting. Jeff, any immediate ideas? I don't see this behaviour
>> on my ICH10. Is there actually a device on ata4?
>>
>> --
>> Matthew Garrett | mjg59(a)srcf.ucam.org
>
> If it's helpful, attached are the dmesg output following a normal boot
> and one with the hang.
>
> The only difference in the kernel used for those two boots is that the
> return statement in ahci_start_engine following the call to
> ahci_is_device_present is commented out for the normal boot case.
> When the return statement is active, the 30 second hang occurs.

Can you try and put a printk in where it's returning out of the
ahci_start_engine method? I wonder if that's getting triggered somewhere
unexpected..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3
Prev: task_io_accounting, taskstats
Next: [PATCH] ipconfig: document DHCP hostname and DNS record