This is with the Fedora 2.6.39-67.x86_64 kernel on an Asus G51Vt laptop. I picked up an SIIG "ExpressCard/54 CF RW" adapter as its native PCIe design makes it much faster than a USB reader, at least in theory. Under WinVista, the card sustains ~40MB/s transfers. Under Linux (2.6.32.9), I'm lucky to get ~25MB/s, not much faster than a good USB reader. The CF card advertises itself capable of UDMA/100, but the PATA layer downgrades it to UDMA/33. hurting performance. partial dmesg showing the hot-insertion: pciehp 0000:00:1c.2:pcie04: Card present on Slot(0) pci 0000:04:00.0: reg 10 io port: [0x00-0x07] pci 0000:04:00.0: reg 14 io port: [0x00-0x03] pci 0000:04:00.0: reg 18 io port: [0x00-0x07] pci 0000:04:00.0: reg 1c io port: [0x00-0x03] pci 0000:04:00.0: reg 20 io port: [0x00-0x0f] pci 0000:04:00.0: reg 30 32bit mmio pref: [0x000000-0x00ffff] pci 0000:04:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pata_jmicron 0000:04:00.0: enabling device (0100 -> 0101) pata_jmicron 0000:04:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 pata_jmicron 0000:04:00.0: setting latency timer to 64 scsi8 : pata_jmicron scsi9 : pata_jmicron ata9: PATA max UDMA/100 cmd 0xc010 ctl 0xc020 bmdma 0xc000 irq 18 ata10: PATA max UDMA/100 cmd 0xc018 ctl 0xc024 bmdma 0xc008 irq 18 ata9.00: CFA: TRANSCEND, 20081024, max UDMA/100 ata9.00: 15924384 sectors, multi 0: LBA ata9.00: limited to UDMA/33 due to 40-wire cable ata9.00: configured for UDMA/33 scsi 8:0:0:0: Direct-Access ATA TRANSCEND 2008 PQ: 0 ANSI: 5 sd 8:0:0:0: Attached scsi generic sg2 type 0 sd 8:0:0:0: [sdb] 15924384 512-byte logical blocks: (8.15 GB/7.59 GiB) sd 8:0:0:0: [sdb] Write Protect is off sd 8:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 8:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 8:0:0:0: [sdb] Attached SCSI disk And then the 'lspci -v' output including the IDE controller: 04:00.0 IDE interface: JMicron Technologies, Inc. JMB368 IDE controller (prog-if 85 [Master SecO PriO]) Subsystem: JMicron Technologies, Inc. JMB368 IDE controller Physical Slot: 0 Flags: bus master, fast devsel, latency 0, IRQ 18 I/O ports at c010 [size=8] I/O ports at c020 [size=4] I/O ports at c018 [size=8] I/O ports at c024 [size=4] I/O ports at c000 [size=16] [virtual] Expansion ROM at f6000000 [disabled] [size=64K] Capabilities: [68] Power Management version 2 Capabilities: [50] Express Legacy Endpoint, MSI 01 Capabilities: [70] MSI: Enable- Count=1/1 Maskable- 64bit- Kernel driver in use: pata_jmicron Kernel modules: ata_generic, pata_acpi, pata_jmicron I can understand the reasoning behind 40/80 wire detection/downgrading, but this is a compactflash card in a PCIe card reader so there's effectively no cable to detect, so forcing the cable type to ATA_CBL_PATA40_SHORT when this particular PCIe CF reader is detected should just work. Unfortunately, I suspect the reported PCI sys/subsys IDs are not unique to this particular card (197b:2368 for both) so I don't know how to go about adding this exception in a sane manner. Thoughts?
Likely the card doesn't implement the cable detection protocol properly and so it appears as a 40-wire cable. I think you can use the libata.force parameter to force detection of a certain cable type (see Documentation/kernel-parameters.txt). I'm not sure there's a good approach to doing this automatically though, if the device IDs for the card aren't unique..
the problem with libata.force= is that the id of the port/device change each time the card is inserted/removed.. I suppose I can set it globally and override the settings for the hard disk and DVD drive... I'll see if I can get this to work; it's not ideal, but better than nothing. (meanwhile, I also have a problem in that a suspend/resume cycle b0rks the pciehp subsystem, but that's another matter...)
When you say 'the card doesn't implement cable detection properly' do you mean the expresscard PCIe->CF/PATA adapter and/or the CF card itself? Neanwhile, using "libata.force=short40c,1:sata,2:sata" seems to do the trick, and I see ~44MB/s sustained throughput off of this CF card now, even though the device ID changes with each hotplug cycle. So I have a workaround in place, but it would be nice if a proper solution could be concocted so things will JustWork for others down the line...
That would be the PCIe->CF adapter.. it should have the hardware set up to look like there's an 80-wire cable if it can supports speeds greater than UDMA/33.