2.6.23-rc1: pata_via cable detection differs from via82cxxx

2.6.23-rc1: pata_via cable detection differs from via82cxxx

[Mikael Pettersson]

The machine is an Athlon64 laptop with a K8T800 chipset. With the IDE
VIA driver the disk is detected as udma/100:

VP_IDE: IDE controller at PCI slot 0000:00:11.1
ACPI: PCI Interrupt Link [ALKA] disabled and referenced, BIOS bug
ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 23
ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:11.1[A] -> Link [ALKA] -> GSI 23 (level, low) -> IRQ 17
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci0000:00:11.1
    ide0: BM-DMA at 0x1ce0-0x1ce7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1ce8-0x1cef, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: TOSHIBA MK6021GAS, ATA DISK drive
hda: selected mode 0x45
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: TOSHIBA ODD-DVD SD-R6372, ATAPI CD/DVD-ROM drive
hdc: selected mode 0x42
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 117210240 sectors (60011 MB), CHS=65535/16/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 >

However, the libata pata_via driver complains about the cable and
drops the disk to udma/33:

pata_via 0000:00:11.1: version 0.3.1
ACPI: PCI Interrupt Link [ALKA] disabled and referenced, BIOS bug
ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 23
ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:11.1[A] -> Link [ALKA] -> GSI 23 (level, low) -> IRQ 17
scsi0 : pata_via
scsi1 : pata_via
ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00011ce0 irq 14
ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x00011ce8 irq 15
ata1.00: ATA-5: TOSHIBA MK6021GAS, GA024A, max UDMA/100
ata1.00: 117210240 sectors, multi 16: LBA 
ata1.00: limited to UDMA/33 due to 40-wire cable
ata1.00: configured for UDMA/33
ata2.00: ATAPI: TOSHIBA ODD-DVD SD-R6372, 1030, max UDMA/33
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access     ATA      TOSHIBA MK6021GA GA02 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 117210240 512-byte hardware sectors (60012 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] 117210240 512-byte hardware sectors (60012 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 < sda5 sda6 sda7 sda8 sda9 >
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 1:0:0:0: CD-ROM            TOSHIBA  ODD-DVD SD-R6372 1030 PQ: 0 ANSI: 5

hdparm -i confirms this: with the IDE driver it lists udma5 as
the current mode, with pata_via it lists udma2 as the current mode.

/Mikael

Re: 2.6.23-rc1: pata_via cable detection differs from via82cxxx

[Alan Cox]

On Fri, 3 Aug 2007 20:28:39 +0200 (MEST)
Mikael Pettersson <mikpe@it.uu.se> wrote:

> The machine is an Athlon64 laptop with a K8T800 chipset. With the IDE
> VIA driver the disk is detected as udma/100:

Currently old IDE via driver has a hack in it which goes 'did the BIOS
set UDMA3+' then I guess the cable is 80 wire regardless. libata doesn't
do that as it breaks with hotplug, breaks with suspend/resume before the
driver is loaded and other bits.

Instead we have two things - an ACPI snoop and a table of wonky laptops
(eg those that use 40 wire ultrashort cables which are valid for UDMA133
but not detected as 80 wire). If your laptop is done that way then it
just needs adding to the magic list and/or 2.6.23-rc1-mm should spot it
by ACPI. I'd prefer the table entry anyway as I don't like relying on ACPI
so an lspci -vvxx would be appreciated

Re: 2.6.23-rc1: pata_via cable detection differs from via82cxxx

[Bartlomiej Zolnierkiewicz]

On Saturday 04 August 2007, Alan Cox wrote:
> On Fri, 3 Aug 2007 20:28:39 +0200 (MEST)
> Mikael Pettersson <mikpe@it.uu.se> wrote:
> 
> > The machine is an Athlon64 laptop with a K8T800 chipset. With the IDE
> > VIA driver the disk is detected as udma/100:
> 
> Currently old IDE via driver has a hack in it which goes 'did the BIOS
> set UDMA3+' then I guess the cable is 80 wire regardless. libata doesn't
> do that as it breaks with hotplug, breaks with suspend/resume before the
> driver is loaded and other bits.
> 
> Instead we have two things - an ACPI snoop and a table of wonky laptops
> (eg those that use 40 wire ultrashort cables which are valid for UDMA133
> but not detected as 80 wire). If your laptop is done that way then it
> just needs adding to the magic list and/or 2.6.23-rc1-mm should spot it
> by ACPI. I'd prefer the table entry anyway as I don't like relying on ACPI
> so an lspci -vvxx would be appreciated

Please also add it to the laptop table in IDE VIA driver.

Thanks,
Bart

Re: 2.6.23-rc1: pata_via cable detection differs from via82cxxx

[Mikael Pettersson]

On Fri, 3 Aug 2007 23:32:17 +0100, Alan Cox wrote:
> Mikael Pettersson <mikpe@it.uu.se> wrote:
> 
> > The machine is an Athlon64 laptop with a K8T800 chipset. With the IDE
> > VIA driver the disk is detected as udma/100:
> 
> Currently old IDE via driver has a hack in it which goes 'did the BIOS
> set UDMA3+' then I guess the cable is 80 wire regardless. libata doesn't
> do that as it breaks with hotplug, breaks with suspend/resume before the
> driver is loaded and other bits.
> 
> Instead we have two things - an ACPI snoop and a table of wonky laptops
> (eg those that use 40 wire ultrashort cables which are valid for UDMA133
> but not detected as 80 wire). If your laptop is done that way then it
> just needs adding to the magic list and/or 2.6.23-rc1-mm should spot it
> by ACPI. I'd prefer the table entry anyway as I don't like relying on ACPI
> so an lspci -vvxx would be appreciated

Sure:

00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
	Subsystem: Rioworks: Unknown device 2032
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Interrupt: pin A routed to IRQ 17
	Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
	Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
	Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
	Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
	Region 4: I/O ports at 1ce0 [size=16]
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 06 11 71 05 05 00 90 02 06 8a 01 01 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: e1 1c 00 00 00 00 00 00 00 00 00 00 1f 16 32 20
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 01 00 00

The machine is an Arima W730-K8, rebadged and sold as the
Targa Visionary 811. eMachines and others also had this model.

/Mikael