Hello,

apologies if I am missing some blatant point.

After upgrading from 2.6.30.5 to 2.6.31 one of my machines was not
booting any more, complaining like this (sata disks):

ata2.00: qc timeout (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata1.00: qc timeout (cmd 0xec)
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata3.00: qc timeout (cmd 0xa1)
ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)

Same after installing 2.6.31.1.

It turned out that the problem is the sb600 SATA controller lying
about its 64bit dma capability.

As far as I seem to understand from ahci.c perusal, in >=2.6.31 the
sb600 is forced to 32bit dma *ONLY* on ASUS M2A-VM mother board, while
it was unconditionally (?) reset to 32bit dma before 2.6.31.

I am running on an ASROCK AliveXFire-eSATA2 mother board and
experience the fake 64bit dma advertising of the sb600 controller.

I know 0 (zero) about kernel and/or ATA coding; I can only say that
the following patch:

*** drivers/ata/ahci.c.ORIG     Wed Sep 30 15:37:54 2009
--- drivers/ata/ahci.c  Wed Sep 30 15:37:54 2009
***************
*** 433,438 ****
--- 433,439 ----
        [board_ahci_sb600] =
        {
                AHCI_HFLAGS     (AHCI_HFLAG_IGN_SERR_INTERNAL |
+                                AHCI_HFLAG_32BIT_ONLY | 
                                 AHCI_HFLAG_NO_MSI | AHCI_HFLAG_SECT255),
                .flags          = AHCI_FLAG_COMMON,
                .pio_mask       = ATA_PIO4,


fixes everything for me.

My impression is that the sb600 forcing should be done in more cases
than the single ASUS M2A-VM, or even unconditionally like it used to
be before 2.6.31 (but, as I said above, my understanding is poor and I
might be totally wrong).

I will be glad to send any other detail (dmesg, lspci, mobo specs, ...) if needed.

Hope that libata people will fix this problem easily.


thanks for all your work

ciao
gabriele