Re: [RFT] major libata update

From: Tejun Heo
Date: Wed May 17 2006 - 02:34:42 EST

Tejun Heo wrote:
Andrew Morton wrote:
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)
+ 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;

The above patch doesn't do anything. The only effect it has is setting present_mask according to enabled bits instead of present bits. I think this patch might have helped with probing before the MAP tables for ICH6/7 are fixed.

I've done further testing.

* Symptom

ata_piix tries to probe non-existing slave device resulting in timeouts during boot probing. This problem is aggravated by new probing updates as it retries two more times before giving up.

* Test results

PATA never has any problem with device detection via signature. Only SATA is affected and interestingly only ATAPI device. The following is the test result on my machine (ICH7R + PX716SA).

1. combined mode : MAP [IDE IDE P1 P3]

P1 P3
PX716-SA empty P3 ghosted as ATAPI device
empty PX716-SA okay
PX716-SA HDD okay
HDD PX716-SA okay

2. SATA-only mode : MAP [P0 P2 P1 P3]

P0 P2
PX716-SA empty P2 ghosted as ATAPI device
empty PX716-SA okay
PX716-SA HDD okay
HDD PX716-SA okay

P1 P3
Identical to #1.

To sum up, it happens when the master slot is occupied by an ATAPI device and the corresponding slave slot is empty. The slave slot reports ATAPI signature (probably duplicated from the master) and passes all legacy presence test thus resulting in timeout on IDENTIFY.

In all above cases, the PCS register reported correct presence masks.

* Proposed solution

It seems that the only solution is to make use of the PCS presence bits somehow. It is know that 6300ESB family of controllers have flaky presence bits (ata_piix marks them with PIIX_FLAG_IGNORE_PCS), but I couldn't find any document/errata for PCS bits for any other controllers. So, we can use PCS for all !PIIX_FLAG_IGNORE_PCS controllers or take a conservative approach and make use of it only on cases where ghosting problem is reported (ICH7 and 8, I guess. Can anyone test 6?).

Please note that we already use some use of the PCS value when probing SATA port. If its value is zero, we skip the port. It's done this way mainly due to historical reasons - until recently ata_piix didn't have MAP tables to map PM/PS/SM/SS to specific ports thus used the PCS values in rougher form.

Jeff, what do you think?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at