Bug 248665

Created attachment 159488 [details]
dmesg from kernel-2.6.21-1.3228.fc7.x86_64

Created attachment 159494 [details]
dmesg from kernel-2.6.21-1.3255.fc7.x86_64

Created attachment 159531 [details]
dmesg from kernel-2.6.22.1-27.fc7.x86_64

Not fixed in kernel-2.6.22.1-27.fc7.x86_64:

ata1: PATA max UDMA/133 cmd 0x00000000000101f0 ctl 0x00000000000103f6 bmdma
0x0000000000011100 irq 14
ata1.00: ATA-5: HITACHI_DK23DA-20, 00J2A0A1, max UDMA/100
ata1.00: 39070080 sectors, multi 16: LBA 
ata1.00: limited to UDMA/33 due to 40-wire cable
ata1.00: configured for UDMA/33

Comment on attachment 159494 [details]
dmesg from kernel-2.6.21-1.3255.fc7.x86_64

dmesg-2.6.21-1.3255.fc7.txt

Created attachment 159540 [details]
dmesg from kernel-2.6.22.1-20.fc7.x86_64

Not fixed in kernel-2.6.20.1-27.fc7.x86_64:

ata1: PATA max UDMA/133 cmd 0x00000000000101f0 ctl 0x00000000000103f6 bmdma
0x0000000000011100 irq 14
ata1.00: ATA-5: HITACHI_DK23DA-20, 00J2A0A1, max UDMA/100
ata1.00: 39070080 sectors, multi 16: LBA 
ata1.00: limited to UDMA/33 due to 40-wire cable
ata1.00: configured for UDMA/33

(In reply to comment #5)
> ata1.00: limited to UDMA/33 due to 40-wire cable
> ata1.00: configured for UDMA/33
> 

It's misdetecting the cable then, and it really is 80-wire?

I believe it is an 80 wire "cable" -- the system is a laptop so there isn't
really a cable.

  On my 32-bit box, my DVD drive on the secondary IDE is configured for UDMA/33
due to a false claim that I have a 40-wire cable.  In fact the DVD drive is
connected via a single-drive 80-wire cable with the blue end connected to the MB
and the black end to the drive, which I believe is correct.  The only other
possibility is if the MB can only use UDMA/33 on the secondary IDE, is this likely?

ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14
ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq 15
ata1.00: ATA-7: Maxtor 6L160P0, BAJ41G10, max UDMA/133
ata1.00: 312500000 sectors, multi 8: LBA48 
ata1.00: configured for UDMA/133
usb 1-2: new low speed USB device using uhci_hcd and address 3
usb 1-2: configuration #1 chosen from 1 choice
ata2.00: ATAPI: SONY    DVD RW DW-G120A, MYR5, max UDMA/66
ata2.00: limited to UDMA/33 due to 40-wire cable
input: DELL DELL USB Keyboard as /class/input/input2
input: USB HID v1.10 Keyboard [DELL DELL USB Keyboard] on usb-0000:00:1d.0-2
ata2.00: configured for UDMA/33

  From looking more closely at the above messages it appears that my secondary
IDE has a maximum of UDMA/133, so this is pretty clearly a bug.  Please change
the Hardware setting on this bug from x86_64 to all, since it's not limited to
64-bit.

  This bug still exists with kernel-2.6.22.4-65.fc7 on 32-bit.

Hello Andre,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris

  Yes, this bug still exists with kernel-2.6.22.5-76.fc7 on 32-bit at least.

Okay thanks. I'm re-assigning this to the relevant maintainer who may be able to
shed some more light on the issue.

Cheers
Chris

  Still broken for me with kernel-2.6.22.7-85.fc7.

Still broken in kernel-2.6.22.9-91.fc7.x86_64.

SCSI subsystem initialized
libata version 2.21 loaded.
ACPI: PCI Interrupt 0000:00:1f.0[A] -> GSI 21 (level, low) -> IRQ 21
scsi0 : pata_ali
scsi1 : pata_ali
ata1: PATA max UDMA/133 cmd 0x00000000000101f0 ctl 0x00000000000103f6 bmdma 
0x0000000000011100 irq 14
ata2: PATA max UDMA/133 cmd 0x0000000000010170 ctl 0x0000000000010376 bmdma 
0x0000000000011108 irq 15
ata1.00: ATA-5: HITACHI_DK23DA-20, 00J2A0A1, max UDMA/100
ata1.00: 39070080 sectors, multi 16: LBA 
ata1.00: limited to UDMA/33 due to 40-wire cable
ata1.00: configured for UDMA/33
usb 1-2: new low speed USB device using ohci_hcd and address 3
ata2.01: ATAPI: MATSHITAUJ-840D, 1.00, max UDMA/33
usb 1-2: configuration #1 chosen from 1 choice
ata2.01: configured for UDMA/33
scsi 0:0:0:0: Direct-Access     ATA      HITACHI_DK23DA-2 00J2 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 39070080 512-byte hardware sectors (20004 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] 39070080 512-byte hardware sectors (20004 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:<6>input: HID 04b3:310b as /class/input/input2
input: USB HID v1.00 Mouse [HID 04b3:310b] on usb-0000:00:1c.0-2
 sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 1:0:1:0: CD-ROM            MATSHITA UJ-840D          1.00 PQ: 0 ANSI: 5

Jason: "I believe it is an 80 wire "cable" -- the system is a laptop so there isn't
really a cable."

That may well be why it isn't being correctly detected. Some laptop vendors use
short 40 wire cables or connecting blocks and tell the shipped OS to ignore
cable detection. We've been slowly building up a database of these laptops in
the kernel to sort this out. Can you attach an lspci -vvxxx and dmidecode

Split off the via part of this bug as its unrelated - please use 352241 for that.

Created attachment 237521 [details]
lspci -vvxxx output

Created attachment 237531 [details]
dmidecode output

Thanks - added to the ALi table, and will commit upstream shortly.

Could reporters please test with 2.6.24 to confirm fix.