Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#7474 - ATA100 hard drive being configured for ATA33 Xfer speed on Promise Ultra100 Controller using libata

Attached to Project: Arch Linux
Opened by dillweed (dillweed) - Wednesday, 20 June 2007, 07:33 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 23 October 2007, 18:01 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Medium
Priority Normal
Reported Version 2007.05 Duke
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Not sure how to explain this as this is my first bug report. For some reason my ATA100 hard drive is being configured for ATA33 transfer speeds on a Promise Ultra100 Controller. All my HD jumpers and cables are set correctly as far as I can tell.

Additional info:
* I'm running an up current system with all the stable packages and kernel.
* Here is (hopefully) pertinent information:
dmeg:
libata version 2.20 loaded.
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:0f.0[A] -> Link [LNKA] -> GSI 5 (level, low) -> IRQ 5
ata1: PATA max UDMA/100 cmd 0x0001dcd8 ctl 0x0001dcd2 bmdma 0x0001d8c0 irq 5
ata2: PATA max UDMA/100 cmd 0x0001dcc0 ctl 0x0001dc3e bmdma 0x0001d8c8 irq 5
scsi0 : pata_pdc202xx_old
ata1.00: ATA-5: MAXTOR 6L040L2, A93.0500, max UDMA/133
ata1.00: 78177792 sectors, multi 16: LBA
ata1.00: configured for UDMA/33
scsi1 : pata_pdc202xx_old
ata2.01: ATA-4: SAMSUNG SV1533D, ML100-40, max UDMA/66
ata2.01: 29897280 sectors, multi 16: LBA
ata2.01: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA MAXTOR 6L040L2 A93. PQ: 0 ANSI: 5
scsi 1:0:1:0: Direct-Access ATA SAMSUNG SV1533D ML10 PQ: 0 ANSI: 5
ata_piix 0000:00:07.1: version 2.10ac1
ata3: PATA max UDMA/33 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14
ata4: PATA max UDMA/33 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq 15
scsi2 : ata_piix
ata3.00: ATAPI, max MWDMA2
ata3.00: configured for MWDMA2
scsi3 : ata_piix
ata4: port disabled. ignoring.
scsi 2:0:0:0: CD-ROM TOSHIBA CD-ROM XM-6202B 1108 PQ: 0 ANSI: 5

mkinitcpio.conf:

MODULES="pata_pdc202xx_old ata_generic ata_piix"

lsmod:

Module Size Used by
ext3 119304 1
jbd 54312 1 ext3
mbcache 6916 1 ext3
ppdev 7556 0
lp 9220 0
rtc_sysfs 3840 0
rtc_proc 3844 0
parport_pc 35172 1
rtc_dev 6664 0
parport 31176 3 ppdev,lp,parport_pc
rtc_cmos 7188 0
ppp_generic 23572 0
rtc_core 7684 4 rtc_sysfs,rtc_proc,rtc_dev,rtc_cmos
rtc_lib 3456 2 rtc_sysfs,rtc_core
i2c_piix4 7692 0
i2c_core 17536 1 i2c_piix4
pcspkr 2944 0
psmouse 34952 0
serio_raw 5636 0
uhci_hcd 22160 0
sg 26524 0
shpchp 29204 0
pci_hotplug 27720 1 shpchp
intel_agp 21276 1
agpgart 27352 1 intel_agp
tsdev 6464 0
evdev 8192 0
thermal 11528 0
processor 24532 1 thermal
fan 3972 0
button 6288 0
battery 8452 0
ac 4100 0
slhc 5760 1 ppp_generic
eepro100 26896 0
e100 31624 0
mii 4864 2 eepro100,e100
usbcore 111240 2 uhci_hcd
reiserfs 234752 1
sd_mod 17796 4
sr_mod 14372 0
cdrom 34336 1 sr_mod
ata_piix 11780 0
ata_generic 5636 0
pata_pdc202xx_old 6408 3
libata 102932 3 ata_piix,ata_generic,pata_pdc202xx_old

lspci -vv:

00:0f.0 Mass storage controller: Promise Technology, Inc. PDC20267 (FastTrak100/Ultra100) (rev 02)
Subsystem: Promise Technology, Inc. Ultra100
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 5
Region 0: I/O ports at dcd8 [size=8]
Region 1: I/O ports at dcd0 [size=4]
Region 2: I/O ports at dcc0 [size=8]
Region 3: I/O ports at dc3c [size=4]
Region 4: I/O ports at d8c0 [size=64]
Region 5: Memory at ff200000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at 20000000 [disabled] [size=64K]
Capabilities: [58] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Thanks
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Tuesday, 23 October 2007, 18:01 GMT
Reason for closing:  Fixed
Comment by Tobias Powalowski (tpowa) - Wednesday, 20 June 2007, 17:41 GMT
you need a 60 pin cable for higher dma speeds.
if you already have this it would be worth a try to use the rc-kernel of .22 series here:
http://www.archlinux.org/~tpowa/rc-kernel/

Comment by dillweed (dillweed) - Wednesday, 20 June 2007, 18:45 GMT
Yes, I'm using a 80 pin cable. I guess I could get a rc-kernel a go and see what happens. In the meantime, I've compiled my own kernel and am using the legacy drivers with hdparm to get the correct dma settings. I would like however, to go with a stock kernel due to less hassle on my part :P
Comment by dillweed (dillweed) - Thursday, 21 June 2007, 06:27 GMT
Ok I tried a rc-kernel from the link given and still got the incorrect dma speeds. However, the error was different this time stating the dma was limited to udma/33 because I was using a 40 pin cable. I know this isn't correct, because I physically took the cable out and counted 80 pins on the cable.
Comment by Roman Kyrylych (Romashka) - Thursday, 21 June 2007, 10:18 GMT
I've seen such wrong message on one old windows machine too. There was 80-pin cable, but BIOS complained about 40-pin on start. Don't know where is the problem.
As a workaround - try to set correct speeds with hdparm in rc.local
Comment by dillweed (dillweed) - Thursday, 21 June 2007, 15:05 GMT
Hdparm does not work when setting the correct speeds when using libata drivers.

See this link:
http://linux-ata.org/faq.html#old_ioctls

Quote:
Why does HDIO_SET_DMA fail? I want to use DMA!
Why does HDIO_SET_UNMASKINTR fail?

libata intentionally does not support all the HDIO_xxx ioctls that were supported by the older IDE driver. It is now preferred to use SG_IO as a generalized ATA command submission method, rather than creating a myriad of ioctls for each specific purpose.

The design decision was made only to support the HDIO_xxx ioctls that were heavily used by other programs. Generally the driver always programs the hardware to its maximum capability automatically, completely without user intervention. Therefore, for example, HDIO_SET_DMA is not needed for the vast majority of users because DMA is automatically enabled and used where available.
Comment by Tobias Powalowski (tpowa) - Monday, 23 July 2007, 19:05 GMT
well the ATA/PATA subsystem is still under heavy development in kernel so such things can happen from time to time.
you could use the old ide subsystem that should still work as it did in earlier kernels.
but that needs reconfiguring of all your hd stuff in bootloader initcpio and fstab
Comment by Tobias Powalowski (tpowa) - Monday, 15 October 2007, 05:30 GMT
status on 2.6.23 kernel?
Comment by dillweed (dillweed) - Monday, 15 October 2007, 05:45 GMT
I don't know because I haven't tried the 2.6.23 kernel yet. As soon as it goes stable I'll let you know. Thanks for the update. The current .22 kernel is running fine.
Comment by Tobias Powalowski (tpowa) - Monday, 22 October 2007, 17:39 GMT
now status on .23?
Comment by dillweed (dillweed) - Tuesday, 23 October 2007, 17:45 GMT
Seems to be working fine and my dma is being correctly set. You can probably close this bug. thanks.

Loading...