Most recent kernel where this bug did not occur: not known Distribution: Gentoo linux; linux-2.6.23-rc7 from kernel.org. Hardware Environment: VIA vt8233a; 3 IDE hdds and 1 cdrom plugged as following: primary channel is 80-wired, has 2 udma-capable hdds attached; secondary channel is 40-wired, has udma-capable hdd and cdrom attached. AMD Athlon XP 1700+ Software Environment: linux-2.6.23-rc7 with via_pata. Problem Description: UDMA mode (UDMA 100/133) is set for 40-wired device. (Expected is UDMA 33, because higher speeds would cause ata bus errors). dmesg says: scsi0 : pata_via scsi1 : pata_via ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001dc00 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001dc08 irq 15 and, later, ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata2.00: BMDMA stat 0x64 ata2.00: cmd c8/00:08:6a:40:1d/00:00:00:00:00/e1 tag 0 cdb 0x12 data 4096 in res 51/84:00:71:40:1d/00:00:00:00:00/e1 Emask 0x10 (ATA bus error) ata2: soft resetting port ata2.00: configured for UDMA/100 ata2.01: configured for UDMA/66 ata2: EH complete Steps to reproduce: 1. VIA vt8233a 2. 40-wired cable 3. UDMA-capable HDD
Original bug report: https://bugs.gentoo.org/show_bug.cgi?id=171619 Also wrote a mail to linux-ide about this previously: http://marc.info/?l=linux-ide&m=119058971807318&w=2 (no responses) Here is the info again: This system includes the following IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) with this southbridge: VIA Technologies, Inc. VT8233A ISA Bridge There are 2 disks on the primary IDE channel, and a disk and a cdrom on the secondary IDE channel. There is an 80-wire cable on the primary channel, and a 40 wire one on the secondary. During boot, the secondary channel runs into some problems: hdc: hdc1 hdc2 < hdc5hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc6 hdc7 hdc8 hdc9 hdc10 > or with pata_via: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata2.00: BMDMA stat 0x64 ata2.00: cmd c8/00:08:6a:40:1d/00:00:00:00:00/e1 tag 0 cdb 0x12 data 4096 in res 51/84:00:71:40:1d/00:00:00:00:00/e1 Emask 0x10 (ATA bus error) ata2: soft resetting port ata2.00: configured for UDMA/100 ata2.01: configured for UDMA/66 ata2: EH complete Replacing the 40 wire cable with an 80 makes these problems go away. The driver reads the VIA_UDMA_TIMING register (offset 0x50 into PCI configuration space) in order to determine if 40 or 80 wire cables are in use. pata_via does: if (ata66 & (0x10100000 >> (16 * ap->port_no))) return ATA_CBL_PATA80; according to specs found at http://gkernel.sourceforge.net/specs/via/DS686B200.pdf.bz2 page 71 these 2 bits are: "UltraDMA mode enable" enabled by bit 6 (which is not even checked in pata_via, but is handled in via82cxxx) "Drive transfer mode" (0 is DMA/PIO, 1 is UDMA) Sidenote: bit 4 talks about cable type reporting, but this is not checked (and the specs don't make it clear how to actually detect cable type if that bit is set). Anyway, the user actually added a printk to look at the ata66 values for the two different cable types. 80 wire on primary and 80 wire on secondary: 0xf1f1f1f6 80 wire on primary and 40 wire on secondary: 0xf1f1f6f6 The only bits that changed in this register are related to cycle time. Maybe this is the wrong register to be using for cable detection? Any ideas? and on another run: 80-wired primary and 80-wired secondary: via_cable_detect: ata66 = 0xf1f1f1f2 80-wired primary and 40-wired secondary: via_cable_detect: ata66 = 0xf1f1f6f6
pata_via checks two things Bit 4 of the primary or slave device If the ACPI speed reporting data is telling us the chip is in > UDMA2 the old via driver has a bizarre and rather iffy hack for peeking at the mode. This lot works for just about every system on the planet. Yours being one apparent exception. Even then we check the drive side detect and the drive in your case is also reporting 80wire so at that point I'm not sure we can do anything.
*** This bug has been marked as a duplicate of bug 9048 ***