Bug 12734

The following patch prevents the 80 wire check:

*** drivers/ide/ide-iops.c      Tue Feb 17 17:17:00 2009
--- drivers/ide/ide-iops.c.new  Tue Feb 17 17:18:04 2009
***************
*** 644,660 ****
                return 1;

  no_80w:
!       if (drive->dev_flags & IDE_DFLAG_UDMA33_WARNED)
!               return 0;

        printk(KERN_WARNING "%s: %s side 80-wire cable detection failed, "
!                           "limiting max speed to UDMA33\n",
                            drive->name,
                            hwif->cbl == ATA_CBL_PATA80 ? "drive" : "host");

!       drive->dev_flags |= IDE_DFLAG_UDMA33_WARNED;

!       return 0;
  }

  int ide_driveid_update(ide_drive_t *drive)
--- 644,661 ----
                return 1;

  no_80w:
!       // *** 80 wire patch applied
!       //if (drive->dev_flags & IDE_DFLAG_UDMA33_WARNED)
!       //#     return 0;

        printk(KERN_WARNING "%s: %s side 80-wire cable detection failed, "
!                           "NOT limiting max speed to UDMA33 (Patch)\n",
                            drive->name,
                            hwif->cbl == ATA_CBL_PATA80 ? "drive" : "host");

!       //drive->dev_flags |= IDE_DFLAG_UDMA33_WARNED;

!       return 1;
  }

  int ide_driveid_update(ide_drive_t *drive)

It would be nicer to have a .config option like CONFIG_IDE_80_WIRE_OVERRIDE that does the same thing. 

Thanks very much -- this is my first kernel patch!

Reassigned to IDE.

There is no way to detect 80-wires cable for CF cards and some hosts don't implement host-side cable detection so this is not really a kernel bug.

[ Please try using "ide_core.ignore_cable=[interface_number]" boot option
  to override the cable detection ("ide_core.ignore_cable=0" for /dev/hda). ]

OK not really a kernel bug, in the sense that there's nothing broken. Still, with the number of SSD's out there growing and growing, we need a way to override the default behavior in .config without making people write their own patch. 

A trivial exercise for someone who knows what they're doing.

SSDs != CFs and should be handled just fine.

I'm closing this bug.

The ssd in my laptop exhibits the same behavior. 

Some SSDs present themlselves as CF devices.

Anyway please post dmesg and 'hdparm --Istdout' from this machine.  Thanks.

Created attachment 20308 [details]
dmesg  and hdparm output, unpatched kernel

Created attachment 20309 [details]
dmesg for patched kernel

I see nothing wrong in dmesg/hdparm outputs:
- is this SSD integrated into laptop by manufacter or an add-on hardware?
- if an add-on, is it also directly plugged into IDE slot?

See in the first case the 80-wire detection limits the speed to UDMA/33, whereas in the second (patched kernel) it goes to UDMA/66. This one is AFAIK soldered onto the motherboard, a Sony TZ-90. On my old R505 I did the same thing but the interface was still slower than the CF card, so it made no difference. 

On my HTPC at home the patched kernel makes it to UDMA/133 -- it's a new CF card, direct plugged. That *doubles* the throughput measured by hdparm. The tech on CF cards is evolving rapidly. 

True that this is relevant to a limited

Cheers, 

Jon Snow

jesnow@Merckx ~ $ grep hda dmesg-28.txt
hda: MCBOE32GQAPQ, ATA DISK drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: drive side 80-wire cable detection failed, limiting max speed to UDMA33
hda: UDMA/33 mode selected
hda: max request size: 128KiB
hda: 63963136 sectors (32749 MB), CHS=63455/16/63
hda: cache flushes not supported
 hda: hda1 hda2 hda3
hda-codec: No codec parser is available
EXT3 FS on hda3, internal journal
Adding 514072k swap on /dev/hda2.  Priority:-1 extents:1 across:514072k
hda: UDMA/33 mode selected
/dev/hda:

jesnow@Merckx ~ $ grep hda dmesg-28-r1.txt
hda: MCBOE32GQAPQ, ATA DISK drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: drive side 80-wire cable detection failed, NOT limiting max speed to UDMA33 (Patch)
hda: UDMA/66 mode selected
hda: max request size: 128KiB
hda: 63963136 sectors (32749 MB), CHS=63455/16/63
hda: cache flushes not supported
 hda: hda1 hda2 hda3
hda-codec: No codec parser is available
EXT3 FS on hda3, internal journal
Adding 514072k swap on /dev/hda2.  Priority:-1 extents:1 across:514072k
hda: drive side 80-wire cable detection failed, NOT limiting max speed to UDMA33 (Patch)
hda: UDMA/66 mode selected
jesnow@Merckx ~ $

On Thursday 19 February 2009, bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=12734
> 
> 
> 
> 
> 
> ------- Comment #12 from jesnow@uh.edu  2009-02-19 08:08 -------
> 
> See in the first case the 80-wire detection limits the speed to UDMA/33,
> whereas in the second (patched kernel) it goes to UDMA/66. This one is AFAIK
> soldered onto the motherboard, a Sony TZ-90. On my old R505 I did the same

If it is soldered we may be able to handle it using either PCI device
subsystem data for PATA controller or BIOS DMI data to detect this laptop
and add the usual quirk for skipping cable detection to the correspoding
host driver (for piix.c please see ich_laptop[] table).

Please post 'lspci -vxxx' and dmidecode outputs (also if you want to give
a try adding this laptop data to ich_laptop[] please go ahead).

> thing but the interface was still slower than the CF card, so it made no
> difference. 
> 
> On my HTPC at home the patched kernel makes it to UDMA/133 -- it's a new CF
> card, direct plugged. That *doubles* the throughput measured by hdparm. The
> tech on CF cards is evolving rapidly. 

I'm not arguing about performance improvements.  The problem is that the
whole cable detection for PATA is big ugly mess and for hardware detection
directly plugged == 40-wires cable (not no-cable, unfortunately)...

The fact that some hosts don't have hardware cable detection (they always
pretend to detect 80-wires cable) and depend solely on the device side cable
detection only adds more confusion.

As for changing the default through .config -- sorry but this is not really
an user-friendly and scalable solution -- we have "ide_core.ignore_cable"
which can be used for all existing setups and can be changed on the runtime
without the need for recompiling/upgrading the kernel.

We may change the global kernel default given that is it safe (UDMA has CRC
checking so it might be safe -- still this needs to be verified with spec)
and that somebody puts the work into improving the error handling so after
first BadCRC error we recover rapidly by going straight to UDMA33 without
retrying (which if fails few times results in lowering the speed + reset).

[ This will of course need some real testing before merge, also please keep
  in mind that this is a quick idea which may miss some details... ]

Ping.  Can we get the output of 'dmidecode' command from TZ-90 (so we can detect this machine automatically and override cable detection in piix)?

Created attachment 21138 [details]
dmidecode from my tz-90

Ok thats got enough to identify it. An lspci -vvxxx would be useful too in case we can identify it by pci sub identifiers (which is easier)

Created attachment 21139 [details]
lspci -vvxxx on my tz-90

Thanks - patch committed for libata

On Monday 27 April 2009 18:11:59 bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=12734
> 
> 
> 
> 
> 
> --- Comment #18 from Alan <alan@lxorguk.ukuu.org.uk>  2009-04-27 16:11:58 ---
> Thanks - patch committed for libata

Alan, did you by any chance forget to post/commit the patch?

Created attachment 21277 [details]
piix: The Sony TZ90 needs the cable type hardcoding

Ok, I found it now:

	http://marc.info/?l=linux-ide&m=124162279705265&w=2

I took the liberty of doing the port since I couldn't find the piix version (which is weird given that the bug has been opened against piix and piix's table matches ata_piix's one so making another patch was quite easy):

From: Alan Cox <alan@linux.intel.com>
Subject: [PATCH] piix: The Sony TZ90 needs the cable type hardcoding

The Sony TZ90 needs the cable type hardcoding. See bug #12734

Signed-off-by: Alan Cox <alan@linux.intel.com>
Reported-by:  Jonathan E. Snow <jesnow@uh.edu>
[bart: port it from ata_piix to piix and give reporter the proper credit]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ide/piix.c |    1 +
 1 file changed, 1 insertion(+)


Index: b/drivers/ide/piix.c
===================================================================
--- a/drivers/ide/piix.c
+++ b/drivers/ide/piix.c
@@ -263,6 +263,7 @@ static const struct ich_laptop ich_lapto
        { 0x24CA, 0x1025, 0x003d },     /* ICH4 on ACER TM290 */
        { 0x266F, 0x1025, 0x0066 },     /* ICH6 on ACER Aspire 1694WLMi */
        { 0x2653, 0x1043, 0x82D8 },     /* ICH6M on Asus Eee 701 */
+       { 0x27df, 0x104d, 0x900e },     /* ICH7 on Sony TZ-90 */
        /* end marker */
        { 0, }
 };