Latest working kernel version: none Earliest failing kernel version: all Distribution: gentoo Hardware Environment: several, 2 sony laptops and 1 VIA EPIA Software Environment: Problem Description: In systems with a CF card directly plugged into the motherboard, ide-iops.c incorrectly downgrades to UDMA/33, even though the device can go much paster. Steps to reproduce: Build kernel, boot: "... hda: drive side 80-wire cable detection failed, limiting max speed to UDMA33"
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, } };