Description of problem: libata/ata_piix fails to configure transfer rate on ICH7M pata device. Works fine with old ide-generic. Motherboard as shown here http://www.commell.com.tw/Support/SBC/LV-677(S).htm. The device in question is an A-DATA COMPACT FLASH 266X 4GB (ACFC004G266ZZ) configured as master on ide0. No other ata devices present. sata disabled in BIOS configured (also tried with Enhanced IDE and Combined set in BIOS) with same result. Also tried with a SanDisk Extreme III 8GB Compact Flash with same results. Have tried libata.dma=0 (libata.pata_dma=0 in f7) (disable dma I believe) yet still attempts to find a UDMA mode. Tried setting disable dma in BIOS but still attempts to find UDMA. Tried libata.ignore_hpa=0 but still tries UDMA. Think I must be missing something. Do not know how to cut and past this as cannot even boot kernel. Key points are: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1.00: status: {DRDY} ata1: soft resetting link ata1.00: configured for UDMA/25 ata1: EH complete ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1.00: status: {DRDY} ata1: soft resetting link ata1.00: configured for UDMA/25 sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK sd 0:0:0:0: [sda] Sense Key : Aborted Command [current] [descriptor] Descriptor sense data with sense descriptors (in hex): 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 00 00 00 00 sd 0:0:0:0: [sda] Add. Sense: No additional sense information end_request: I/O error, dev sda, sector 8043648 Buffer: I/O error on device sda, logical block 1005456 ata1: EH complete After a long time it may say: SCSI Device Attached Loaded pata_acpi.ko Loaded ata_generic.ko or similar (I'm copying this from screen, this is the first time I've seen this though) After which it continues with the timeouts. Version-Release number of selected component (if applicable): 2.6.23.8-63.fc8 and 2.6.24-0.77.rc4.git4.fc9 confirmed. f7+ suspected. How reproducible: Always Steps to Reproduce: 1. Had to install FC6 first due to same problem with f7/f8 install. 2. yum updated to f7 and f8 on separate occasions with same result. 3. try to boot f7+ kernels. Actual results: libata timeouts Expected results: should just work Additional info:
Created attachment 282431 [details] hdparm -I /dev/hda on latest (final) fc6 kernel
Created attachment 282441 [details] lspci -vvvv on latest fc6 kernel
This looks unusual: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1.00: status: {DRDY}
We issued a read command There was a timeout (command didn't finish) The drive is now saying it wants data to be transferred still. Do you see the same with other brands of CF card ?
Yes with a SanDisk Extreme III 8GB card. I have a few others that I'll try out tomorrow.
Ok, testing with the SanDisk again, and the kernel on f8 dvd gives the same result. (This time I have a DVD drive in parallel with the CF.) card info: ata1.00 CFA: SanDisk SDCFX3-8192, HDX 4.08, max MWDMA2 write protect is off Mode Sense: 003a 00 00 write cache disabled, read cache enabled, doesn't support fua or dpo When trying to configure: ata1.00: configured for MWDMA2 (later MWDMA1) ata1: EH complete ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen -ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in +ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1.00: status: {DRDY} ata1: soft resetting link +ata1.00: configured for MWDMA2 -ata1.00: configured for UDMA/25 sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK sd 0:0:0:0: [sda] Sense Key : Aborted Command [current] [descriptor] Descriptor sense data with sense descriptors (in hex): 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 00 00 00 00 sd 0:0:0:0: [sda] Add. Sense: No additional sense information -end_request: I/O error, dev sda, sector 8043648 +end_request: I/O error, dev sda, sector 0 -Buffer: I/O error on device sda, logical block 1005456 +Buffer: I/O error on device sda, logical block 0 ata1: EH complete
Created attachment 285671 [details] Works with a Hitachi CVM1.1.1 Rev (old 64MB card)
SanDisk SDCFH-51 HDX (SanDisk Ultra II) exactly as with other SanDisk. MWDMA2 -> MWDMA1:PIO4
Thats it for the CF cards I have. Anything else you need? I'm on #fedora and #fedora-devel if needed, HazzaUK.
concerning the SanDisk SDCFX3-8192 the status {DRDY} is not displayed, perhaps a different debug level on the f8 dvd install kernel?
Ok firstly someone needs to workout why libata.dma=0 isnt having an effect on your system. After that I'll take a look at the incompatibility.
Where are you adding the "libata.dma=0"? You'll need to put it in /etc/modprobe.conf and re-mkinitrd for it to take effect. A line like: options libata dma=0 should be sufficient. cheers, Kyle
I had similar problems using ata1.00: CFA: SanDisk SDCFX3-4096, HDX 4.03, max MWDMA2 on sata_via or pata_via Kernels: kernel-2.6.23.15-137.fc8 kernel-2.6.24.3-22.fc8 While with 2.6.23.15-137.fc8 using the IDE adaptor, enabling DMA causes an instant hanging during booting. Switching to sata_via using a CF-to-SATA adapter, the kernel hangs without any comments during network setup (init 3) or after ls/dmesg in single user mode. Disabling DMA (options libata dma=3) for CF helps, but data transfer drops under 3 MByte/s (hdparm -tT) Is this a general problem with DMA and compact flash cards? SanDisk SDCFX3-4096 is labeld as "Extreme III"
There are two problems with CF cards and DMA - Most older CF/Disk adapters are not wired to support DMA - they lack the needed pins - The newer ones wired to do DMA often don't meet the proper signalling standards. That is usually a problem with UDMA on the same cable as the CF adapter rather than MWDMA however as MWDMA and PIO timings are fairly similar.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I have the same issue here now using a OCZ OCZ SOLID_SSD 30 GB flash disk with 2.6.27.12-170.2.5.fc10.i686 on F10 on the SATA port. 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02) @Bugreporter: pls. change version to F10 @Alan Cox: is there any fix in upcoming 2.6.28 planned for that issue? Currently, the drive is unusuable on SATA port (but thanks to the additional USB port I can use it booting from USB...but this should not be the final solution).
Happen also during try to burn a DVD, connected to Parallel ATA: Feb 7 23:12:44 *** kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Feb 7 23:12:44 *** kernel: ata2.01: cmd a0/00:00:00:00:00/00:00:00:00:00/b0 tag 0 Feb 7 23:12:44 *** kernel: cdb 35 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Feb 7 23:12:44 *** kernel: res 40/00:02:00:0c:00/00:00:00:00:00/b0 Emask 0x4 (timeout) Feb 7 23:12:44 *** kernel: ata2.01: status: { DRDY } Feb 7 23:12:50 *** kernel: ata2: link is slow to respond, please be patient (ready=0) Feb 7 23:12:54 *** kernel: ata2: device not ready (errno=-16), forcing hardreset Feb 7 23:12:54 *** kernel: ata2: soft resetting link Feb 7 23:12:55 *** kernel: ata2.01: revalidation failed (errno=-2) Feb 7 23:13:00 *** kernel: ata2: soft resetting link Feb 7 23:13:00 *** kernel: ata2.01: configured for UDMA/33 Feb 7 23:13:00 *** kernel: ata2: EH complete Board is MSI-9830 (IM-945GSE-A)
News at least from me: a BIOS setting switching the IDE/ATA chip into "Compatible" mode was the reason for my timeouts. See also https://bugzilla.redhat.com/show_bug.cgi?id=486829 Perhaps this mode should be re-set to "Enhanced" mode in the Linux kernel module during loading the module.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.