Bug 352241

Summary: [pata_via]: Cable detect problem
Product: [Fedora] Fedora Reporter: Alan Cox <alan>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 7CC: cebbert, chris.brown, davej, lowen, robatino
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-14 11:34:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 248665    
Bug Blocks:    
Attachments:
Description Flags
DMIdecode, ASUS A8V-XE
none
lspci -vvxxx, ASUS A8V-XE
none
dmesg, ASUS A8V-XE none

Description Alan Cox 2007-10-25 13:23:21 UTC
+++ This bug was initially created as a clone of Bug #248665 +++

Description of problem:
libata/pata_ali configures UDMA/100 drive as UDMA/33

Version-Release number of selected component (if applicable):
kernel-2.6.21-1.3228.fc7.x86_64
kernel-2.6.21-1.3255.fc7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install F7 on pata_ali UDMA/100-compatible hardware with UDMA/100 drive
2. Boot.
  
Actual results:
ata1.00: ATA-5: HITACHI_DK23DA-20, 00J2A0A1, max UDMA/100
ata1.00: configured for UDMA/33

Expected results:
ata1.00: ATA-5: HITACHI_DK23DA-20, 00J2A0A1, max UDMA/100
ata1.00: configured for UDMA/100

Additional info:
kernel-2.6.21-1.3228.fc7.x86_64 dmesg attached.

kernel-2.6.21-1.3255.fc7.x86_64 dmesg output to follow.

-- Additional comment from jasonq13 on 2007-07-17 21:46 EST --
Created an attachment (id=159488)
dmesg from kernel-2.6.21-1.3228.fc7.x86_64


-- Additional comment from jasonq13 on 2007-07-17 23:54 EST --
Created an attachment (id=159494)
dmesg from kernel-2.6.21-1.3228.fc7.x86_64


-- Additional comment from jasonq13 on 2007-07-18 11:54 EST --
Created an attachment (id=159531)
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

-- Additional comment from jasonq13 on 2007-07-18 12:51 EST --
(From update of attachment 159494 [details])
dmesg-2.6.21-1.3255.fc7.txt


-- Additional comment from jasonq13 on 2007-07-18 12:53 EST --
Created an attachment (id=159540)
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


-- Additional comment from cebbert on 2007-07-18 13:01 EST --
(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?



-- Additional comment from jasonq13 on 2007-07-18 13:38 EST --
I believe it is an 80 wire "cable" -- the system is a laptop so there isn't
really a cable.


-- Additional comment from andre.edu on 2007-08-11 17:38 EST --
  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

-- Additional comment from andre.edu on 2007-08-11 19:23 EST --
  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.

-- Additional comment from andre.edu on 2007-08-24 13:14 EST --
  This bug still exists with kernel-2.6.22.4-65.fc7 on 32-bit.

-- Additional comment from snecklifter on 2007-09-19 10:02 EST --
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

-- Additional comment from andre.edu on 2007-09-19 12:09 EST --
  Yes, this bug still exists with kernel-2.6.22.5-76.fc7 on 32-bit at least.

-- Additional comment from snecklifter on 2007-09-20 05:57 EST --
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

-- Additional comment from andre.edu on 2007-09-26 22:24 EST --
  Still broken for me with kernel-2.6.22.7-85.fc7.

-- Additional comment from jasonq13 on 2007-10-16 00:02 EST --
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


-- Additional comment from alan on 2007-10-25 09:21 EST --
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

Comment 1 Lamar Owen 2007-12-12 06:06:42 UTC
I'm having this issue on an ASUS A8V-XE; I just swapped the motherboard out (had
a tyan k8e in there, but it didn't like the new PCI-express U320 controller).

An excerpt from /var/log/messages for the boot on the Tyan K8E (an nForce4
motherboard):
Dec  6 19:19:03 localhost kernel: ata5.00: ATA-7: ST3300831A, 3.03, max UDMA/100
Dec  6 19:19:03 localhost kernel: ata5.00: 586072368 sectors, multi 16: LBA48
Dec  6 19:19:03 localhost kernel: ata5.00: configured for UDMA/100
Dec  6 19:19:03 localhost kernel: ata6.00: ATAPI: LITE-ON DVDRW SOHW-1613S,
AS04, max UDMA/66
Dec  6 19:19:03 localhost kernel: ata6.00: configured for UDMA/66

I'm attaching lspci -vvxxx and dmesg for the ASUS.  Cables have not changed from
when it was working with the Tyan and now.  Kernel is latest Fedora 7
(2.6.23.8-34.fc7).

Comment 2 Lamar Owen 2007-12-12 06:07:22 UTC
Created attachment 285121 [details]
DMIdecode, ASUS A8V-XE

Comment 3 Lamar Owen 2007-12-12 06:07:56 UTC
Created attachment 285131 [details]
lspci -vvxxx, ASUS A8V-XE

Comment 4 Lamar Owen 2007-12-12 06:08:27 UTC
Created attachment 285141 [details]
dmesg, ASUS A8V-XE

Comment 5 Lamar Owen 2007-12-12 06:12:02 UTC
One other quick note: the subject line on this bug says pata_via; the A8V-XE is
a pata_via machine.  Not sure why the body of this bug is about pata_ali... but,
in any case, I'm having the cable issue on pata_via, not pata_ali.