Bug 8142 - pata_via does not detect SATA cables
pata_via does not detect SATA cables
Status: CLOSED CODE_FIX
Product: IO/Storage
Classification: Unclassified
Component: Serial ATA
i386 Linux
: P2 normal
Assigned To: Alan
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-07 09:47 UTC by Claas Langbehn
Modified: 2008-01-29 08:48 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.21-rc2-mm2
Tree: Mainline
Regression: ---


Attachments
hdparm output when using the original pata_via (987 bytes, text/plain)
2007-03-10 01:34 UTC, Claas Langbehn
Details
hdparm output with disabled cable check (2.25 KB, text/plain)
2007-03-10 01:38 UTC, Claas Langbehn
Details
lspci -nnv (6.08 KB, text/plain)
2007-05-20 06:34 UTC, Claas Langbehn
Details

Description Claas Langbehn 2007-03-07 09:47:41 UTC
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.
Comment 1 Alan 2007-03-07 11:56:13 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.
Comment 2 Claas Langbehn 2007-03-07 13:37:23 UTC
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
Comment 3 Claas Langbehn 2007-03-10 01:32:34 UTC
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.
Comment 4 Claas Langbehn 2007-03-10 01:34:03 UTC
Created attachment 10673 [details]
hdparm output when using the original pata_via
Comment 5 Claas Langbehn 2007-03-10 01:38:04 UTC
Created attachment 10674 [details]
hdparm output with disabled cable check

Speed increases by ~8 MB/s
Comment 6 Claas Langbehn 2007-05-16 05:19:03 UTC
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
Comment 7 Alan 2007-05-16 06:20:49 UTC
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.
Comment 8 Tejun Heo 2007-05-20 03:45:03 UTC
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....
Comment 9 Claas Langbehn 2007-05-20 06:34:14 UTC
Created attachment 11551 [details]
lspci -nnv
Comment 10 Claas Langbehn 2007-05-20 06:37:49 UTC
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.
Comment 11 Alan 2007-05-20 07:34:17 UTC
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
Comment 12 Alan 2007-06-05 06:16:39 UTC
Patched posted into -mm
Comment 13 Claas Langbehn 2007-06-05 11:54:41 UTC
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
Comment 14 Natalie Protasevich 2007-07-08 16:24:35 UTC
Any updates, plans with this issue?
Thanks.
Comment 15 Alan 2007-07-09 02:31:59 UTC
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.
Comment 16 Alan 2007-09-10 08:56:01 UTC
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 
Comment 17 Alan 2008-01-29 08:48:16 UTC
Believed fixed, re-open if 2.6.24 shows the bug

Note You need to log in before you can comment on or make changes to this bug.