Bug 15445
Summary: | pata_jmicron incorrectly downgrades CompactFlash to UDMA/33 | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Solomon Peachy (pizza) |
Component: | IDE | Assignee: | io_ide (io_ide) |
Status: | RESOLVED DOCUMENTED | ||
Severity: | normal | CC: | alan, hancockrwd |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.32.9 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Solomon Peachy
2010-03-04 20:41:20 UTC
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. |