Re: [RFT] major libata update

[Andrew Morton <akpm@osdl.org>]

Tejun Heo <htejun@gmail.com> wrote:
>
> Hello, Andrew.
> 
> Andrew Morton wrote:
> [--snip--]
> > [   44.719422] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
> > [   44.719425] ata2.00: ATAPI, max UDMA/66
> > [   44.765263] ata2.00: applying bridge limits
> > [   74.928836] ata2.01: qc timeout (cmd 0xa1)
> > [   74.977811] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
> > [   75.468853] ata2.00: cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
> > [   75.468856] ata2.00: ATAPI, max UDMA/66
> > [   75.514678] ata2.00: applying bridge limits
> > [  105.674130] ata2.01: qc timeout (cmd 0xa1)
> 
> Did this device work with previous versions of kernel?

No.  In fact, it doesn't even work with the 2.6.17-rc4-mm1 lineup plus the
latest git-libata-all.  It needs this tweak:

--- devel/drivers/scsi/ata_piix.c~2.6.17-rc4-mm1-ich8-fix	2006-05-16 18:36:12.000000000 -0700
+++ devel-akpm/drivers/scsi/ata_piix.c	2006-05-16 18:36:12.000000000 -0700
@@ -542,6 +542,14 @@ static unsigned int piix_sata_probe (str
 		port = map[base + i];
 		if (port < 0)
 			continue;
+		if (ap->flags & PIIX_FLAG_AHCI) {
+			/* FIXME: Port status of AHCI controllers
+			 * should be accessed in AHCI memory space.  */
+			if (pcs & 1 << port)
+				present_mask |= 1 << i;
+			else
+				pcs &= ~(1 << port);
+		}
 		if (ap->flags & PIIX_FLAG_IGNORE_PCS || pcs & 1 << (4 + port))
 			present_mask |= 1 << i;
 		else
_


> libata used to give up on the first failure during probe, so the boot 
> time would have been shorter in failure cases.

I don't recall anyone complaining?

>  I think controlled 
> retries during boot probe is a good thing, but the timeout of 30s for 
> IDENTIFY commands can be shortened, I guess.

We should do something, please.  It'll hurt kernel developers the most.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/