Bug 8142
Summary: | pata_via does not detect SATA cables | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Claas Langbehn (claas) |
Component: | Serial ATA | Assignee: | Alan (alan) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | alan, hild, protasnb |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.21-rc2-mm2 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
hdparm output when using the original pata_via
hdparm output with disabled cable check lspci -nnv |
Description
Claas Langbehn
2007-03-07 09:47:41 UTC
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 |