Bug 13882

Created attachment 22547 [details]
dmesg 2.6.30.3

Attaching dmesg output.

It looks like you're indeed getting UDMA CRC errors. The drive is getting configured for UDMA/66. Is it using an 80-wire PATA cable? If not then that would explain why as 40-wire are only good to UDMA/33, however in that case it would point to the cable detection not working properly.

ata1 is using an 80-wire cable, and ata2 is using a 40-wire cable.  So I think you are right about cable detection not working properly.

Created attachment 22551 [details]
dmesg 2.6.24.6

Here is the dmesg output using 2.6.24.6.

As you can see it detects the 40-wire cable properly.

Can you attach an lspci -vvxx

Would also be useful to know if 2.6.29/30 get it right

Created attachment 22555 [details]
lspci -vvxxx 2.6.24.6

Created attachment 22556 [details]
lspci -vvxxx 2.6.30.3

Alan, I'm not sure what you mean by "Would also be useful to know if 2.6.29/30 get it right".  If you are asking whether or not the bug occurs in 2.6.29/30, then the answer is yes (as can be verified by looking at dmesg 2.6.30.3).

Can you rerun the lspci output for 2.6.30 as root? When run as normal user it omits the part of the PCI configuration space that contains the cable detection bits.

Created attachment 22557 [details]
lspci -vvxxx 2.6.30.3

Created attachment 22558 [details]
lspci -vvxxx 2.6.24.6

Ok Robert, I have rerun both lspci outputs as root.

Presumably it's hitting this case:

	pci_read_config_dword(pdev, 0x50, &ata66);
	/* Check both the drive cable reporting bits, we might not have
	   two drives */
	if (ata66 & (0x10100000 >> (16 * ap->port_no)))
		return ATA_CBL_PATA80;

The value at 0x50 is F1F1F6F2, which according to this logic means that an 80-wire cable is detected on all 4 drives. Hmm..

Alan, do you have access to any documentation that indicates what those bits are supposed to actually mean?

For the original reporter, you can try just deleting those lines from drivers/ata/pata_via.c and see if the cable detection then reports 40-wire..

I have complete documentation for them. They are set by the BIOS to indicate whether the cable is 40 or 80 wire. We cannot do drive side detect as there is no guarantee the boards support it.

If the system supports ACPI we also check the ACPI data. There isn't much else we can do and unfortunately the ACPI tells us "80 wire or dunno" not 80/40 so I don't see a good way to use that for both.


The other bits in that register pertain to mode/timing stuff.

--- Comment #15 from Alan <alan@lxorguk.ukuu.org.uk> 2009-08-01 21:30:26 ---
> I have complete documentation for them. They are set by the BIOS to indicate
> whether the cable is 40 or 80 wire. We cannot do drive side detect as there
> is
> no guarantee the boards support it.
>   

I wonder how boards can support (or not) *drive side* cable detection...

Because someone didn't bother fitting a suitable capacitor I would imagine (ATA 5 AnnexB). It may also be the boot process before Linux runs (eg ACPI) samples and confuses stuff. Neither the VIA nor the Nvidia reliabily support drive side detect and Nvidia in fact specify the use of ACPI for detection purposes should always be done.

How does 2.6.24.6 detect the cables correctly?  Does it not use ACPI?

2.6.24 has various differences, without knowing exactly what path is taken it's hard to tell. Most likely the fact the old code erroneously also checked drvie detect on VIA (which broke lots of systems) happened by luck to make yours work.

One way to test that would be to make the cases which return ATA_CBL_PATA80 in the pata_via driver return ATA_CBL_PATA_UNK and see if that helps you. If it does we are probably going to have to special case some boards by PCI svid/sdid 8(

I just replaced my 40-wire cable with an 80-wire cable, reran the md5sum test using 2.6.27.14, and it looks like my DVD drive is working fine now.

I don't have the inclination to spend any more time on the original bug.  Perhaps somebody else with more time and inclination will want to look into this further.