Distribution: Ubuntu Feisty Fawn Hardware Environment: VIA EPIA EX15000G mainboard with CX700M2 chipset, IDE bridge has PCI-ID 1106:5324 Problem Description: When booting, the driver detects a 40pin cable and limits the speed to UDMA/33 (limited to UDMA/33 due to 40-wire cable), BUT in fact it is neither a 40 or 80 pin cable. It is an SATA-cable. Therefore it should not be limited to UDMA/33. /dev/sd[ab] are SATA devices, while /dev/hd[cd] are PATA. Both are handled by pata_via. This is what dmesg says: pata_via 0000:00:0f.0: version 0.2.1 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001fc00 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001fc08 irq 15 scsi0 : pata_via ata1.00: ATA-7: SAMSUNG HM160JI, AD100-10, max UDMA/100 ata1.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: limited to UDMA/33 due to 40-wire cable ata1.00: configured for UDMA/33 scsi1 : pata_via Switched to high resolution mode on CPU 0 ata2.00: ATAPI, max UDMA/33 ata2.00: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA SAMSUNG HM160JI AD10 PQ: 0 ANSI: 5 SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: Attached scsi disk sda scsi 1:0:0:0: CD-ROM Slimtype DVDRW SLW-831S WS01 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 1:0:0:0: Attached scsi CD-ROM sr0 Tell me if you need more information.
It doesn't expect SATA cables because it is a PATA controller. This sounds like a bridge chip is present which might make life more fun.
But then this bridge must be integrated in the CX700M2 chip since there are no other chips. The wires go directly to the SATA connectors. Chipset description: http://www.via.com.tw/en/products/chipsets/c-series/cx700m/ See a photo here: http://picteufelchen.net/pics/EPIAEXHaab63.jpg
I did some testing: I disabled the cable check in drivers/ata/pata_via.c and the drive performance got increased as expected. But since it's a 2,5" hdd the speed gain was not very big. Please see the following attachments.
Created attachment 10673 [details] hdparm output when using the original pata_via
Created attachment 10674 [details] hdparm output with disabled cable check Speed increases by ~8 MB/s
Unfortunately, this problem is not solved by pata_via.c (ver 0.3.1) yet. Is there anything I can do to help? pata_via 0000:00:0f.0: version 0.3.1 scsi0 : pata_via scsi1 : pata_via ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001fc00 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001fc08 irq 15 ata1.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = 312581808 ata1.00: ATA-7: SAMSUNG HM160JI, AD100-10, max UDMA/100 ata1.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: limited to UDMA/33 due to 40-wire cable <------------------------ ata1.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = 312581808 ata1.00: configured for UDMA/33 ATA: abnormal status 0x8 on port 0x00010177 scsi 0:0:0:0: Direct-Access ATA SAMSUNG HM160JI AD10 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: [sda] Attached SCSI disk
For the STA bridge case I've got a patch waiting in my devel tree but at the moment it needs some other change to have been pushed first to avoid cauisng problems.
Alan, care to share the WIP fix? Can't we just quirk this case as force 80c similarly to notebook short 40c cables? Class, can you post the result of "lspci -nnv"? They integrated a bridge chip on silicon but didn't bother to make cable detection report 80c? Come on....
Created attachment 11551 [details] lspci -nnv
But when forcing the cable to be 80c, then this should only apply to /dev/sda and sdb since they are SATA. sdc/sdd are PATA.
For the 40pin short cables on VIA I'm waiting for the dmidecode dump of the reporters laptop on l/k. For the SATA one I've got a patch I'll push Monday now its passed basic testing
Patched posted into -mm
I just tried you patch and the drive is still limited to UDMA/33. pata_via 0000:00:0f.0: version 0.3.1 scsi0 : pata_via scsi1 : pata_via ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001fc00 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001fc08 irq 15 ata1.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = 312581808 ata1.00: ATA-7: SAMSUNG HM160JI, AD100-10, max UDMA/100 ata1.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: limited to UDMA/33 due to 40-wire cable <----------------------- ata1.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = 312581808 ata1.00: configured for UDMA/33 Switched to high resolution mode on CPU 0 ata2.00: ATAPI, max UDMA/33 ata2.00: configured for UDMA/33
Any updates, plans with this issue? Thanks.
Current status: Trying some ACPI based cable tricks in the next -mm. If that works will then propogate to Linus. Tejun is looking at a related CX700 problem with slave devices.
ACPI detect fixes now in the tree and someone found a bug where the reprobe could misconfigure to 40 wire cable. Hopefully one of those is your bug and 2.6.23 when it appears will make it go away. Leaving assigned until we find out for sure its sorted
Believed fixed, re-open if 2.6.24 shows the bug