Fw: [Bug 163753] Strange ATA HD configuration

Fw: [Bug 163753] Strange ATA HD configuration

[Adrian POPA]

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

Hi
I have reported this bug quite a while but it was marked as Won't fix
However, I have a patch that you can test and which I am using since then.
Is no big deal and maybe it can be included in new builds. All builds (last
2.6.22-15.40) have the same bug and I have to replace modules after each
update.
Adrian

P.S. If you had the time to read up to this point, I can explain in a few
words what's the issue.
In libata-core.c:
Cable detection (40/80 wire) is now made on each attached drive and this is
not what the standards say. If a drive does not offer detection support or
says "don't care", it will be downgraded with no reason. The patch is doing
the detection by port plus all (one or two) attached HD, using the ATA
standard table to decide if the cable (for ALL drives) is to be declared 40
or 80 wire.

In pata_sis.c
There is a parameter missing in the udma table. It was originaly build for
ATA64 and then included for ATA100_old too. The entry for UDMA100 is
missing, garbage data is used to setup drive parameters and a bunch of
errors will occur until the system decides to downgrade the drive to UDMA64.

That's all



----- Original Message ----- 
From: "Adi POPA" <adrianp@aageneral.ro>
To: <adrianp@aageneral.ro>
Sent: Monday, November 19, 2007 11:21 AM
Subject: [Bug 163753] Strange ATA HD configuration


Public bug reported:

Binary package hint: linux-source-2.6.22

Ubuntu 2.6.22-14.46-server (Ubuntu 4.1.2-16ubuntu2) Sun Oct 14 23:34:23 GMT
2007
MB chipset SIS 730. IDE interface SIS 5513.
Two HDD an the same ATA cable (master/slave by jumpers), ATA 133/100
detected by AMIBIOS and set to ATA100 (max board cap)
One CDROM on IDE2 (checked with both ATA and IDE-40wire cables), UDMA33 by
BIOS
libata 2.21, pata_sis version 0.5.1 detects HD as UDMA/100 and CDROM as
UDMA/33 --> OK
and sis900.c - v1.08.10 loads
--> ata1.00: ... 16Sec max UDMA/133
--> ata1.01: ... 8Sec max UDMA/100
--> ata2.00: ... max UDMA/33
....
ata1.00: configured for UDMA/100 --> normal, board limit
ata1.01: limited to UDMA/33 due to 40-wire cable --> why? same cable!?
ata1.01: configured for UDMA/33 --> is this a bug?
ata2.00: configured for UDMA/33
.... some long (30 sec) stops on ata1.00 exception ... (timeout)
and then ata1.00 is limited even lower
ata1.00 configured for UDMA/66

** Affects: linux-source-2.6.22 (Ubuntu)
     Importance: Undecided
         Status: New

-- 
Strange ATA HD configuration
https://bugs.launchpad.net/bugs/163753
You received this bug notification because you are a direct subscriber
of the bug.

[-- Attachment #2: aag_source.diff --]
[-- Type: application/octet-stream, Size: 2153 bytes --]

--- linux-source-2.6.22-2.6.22/drivers/ata/libata-core.c
+++ linux-source-2.6.22/drivers/ata/libata-core.c
@@ -2180,6 +2180,31 @@
 	/* Now ask for the cable type as PDIAG- should have been released */
 	if (ap->ops->cable_detect)
 		ap->cbl = ap->ops->cable_detect(ap);
+	
+	//<< AAG
+	// Match result with drive(s) indicator if present
+	// Maybe test bit 3 in id[80] for ATA3 compliance and
+	// give more credit to compliant drives.
+	if(ap->cbl == ATA_CBL_PATA80 ||
+	   ap->cbl == ATA_CBL_PATA_UNK) {
+
+	    for(i = (ATA_MAX_DEVICES - 1); i >= 0 && ap->cbl != ATA_CBL_PATA40; i--) {
+		dev = &ap->device[i];
+		if(!ata_dev_enabled(dev))
+		    continue;
+		if((dev->id[93] & 0xC000) == 0x4000) {
+		    // drive offers detection support
+		    int devcbl = (dev->id[93] & 0x2000) ? ATA_CBL_PATA80 : ATA_CBL_PATA40;
+		    if(ap->cbl == ATA_CBL_PATA_UNK)
+			ap->cbl = devcbl; // take whatever the drive says
+		    else if(ap->cbl != devcbl)
+			ap->cbl = ATA_CBL_PATA40; // missmatched report
+		}
+	    }
+	    if(ap->cbl == ATA_CBL_PATA_UNK)
+		ap->cbl = ATA_CBL_PATA40;
+	}
+	//>> AAG
 
 	/* After the identify sequence we can now set up the devices. We do
 	   this in the normal order so that the user doesn't get confused */
@@ -3906,10 +3931,7 @@
 	 */
 	if (xfer_mask & (0xF8 << ATA_SHIFT_UDMA))
 		/* UDMA/44 or higher would be available */
-		if((ap->cbl == ATA_CBL_PATA40) ||
-   		    (ata_drive_40wire(dev->id) &&
-		     (ap->cbl == ATA_CBL_PATA_UNK ||
-                     ap->cbl == ATA_CBL_PATA80))) {
+		if(ap->cbl == ATA_CBL_PATA40) {
 		      	ata_dev_printk(dev, KERN_WARNING,
 				 "limited to UDMA/33 due to 40-wire cable\n");
 			xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);

--- linux-source-2.6.22-2.6.22/drivers/ata/pata_sis.c
+++ linux-source-2.6.22/drivers/ata/pata_sis.c
@@ -371,7 +371,7 @@
 	u16 timing;
 
 	const u16 mwdma_bits[] = { 0x707, 0x202, 0x202 };
-	const u16 udma_bits[]  = { 0xF000, 0xD000, 0xB000, 0xA000, 0x9000};
+	const u16 udma_bits[]  = { 0xF000, 0xD000, 0xB000, 0xA000, 0x9000, 0x8000 };
 
 	pci_read_config_word(pdev, drive_pci, &timing);
 

Re: [Bug 163753] Strange ATA HD configuration

[Alan Cox]

On Wed, 12 Nov 2008 19:16:09 +0200
"Adrian POPA" <adrianp@aageneral.ro> wrote:

> Hi
> I have reported this bug quite a while but it was marked as Won't fix
> However, I have a patch that you can test and which I am using since then.
> Is no big deal and maybe it can be included in new builds. All builds (last
> 2.6.22-15.40) 

The cable detection code has been entirely rewritten since 2.6.22

Alan

Re: [Bug 163753] Strange ATA HD configuration

[Tejun Heo]

Alan Cox wrote:
> On Wed, 12 Nov 2008 19:16:09 +0200
> "Adrian POPA" <adrianp@aageneral.ro> wrote:
> 
>> Hi
>> I have reported this bug quite a while but it was marked as Won't fix
>> However, I have a patch that you can test and which I am using since then.
>> Is no big deal and maybe it can be included in new builds. All builds (last
>> 2.6.22-15.40) 
> 
> The cable detection code has been entirely rewritten since 2.6.22

Yeah, 2.6.22 feels like a life time before at this point.  Adrian, can
you please test 2.6.27.6 and report whether the problems are fixed?

Thanks.

-- 
tejun