Exact Kernel version: 2.5.47-ac3 Distribution: Red Hat Rawhide Hardware Environment: Gigabyte GA -7VAX http://www.giga-byte.com/products/7vax.htm Northbridge : VIA KT400 Southbridge : VIA 8235 latest bios hda : IBM-DJNA-371350, ATA DISK drive hdb : YAMAHA CRW2100E, ATAPI CD/DVD-ROM drive hdc : MAXTOR 6L080J4, ATA DISK drive hdd : TOSHIBA DVD-ROM SD-M1302, ATAPI CD/DVD-ROM drive dmesg declares them as : hda: 26520480 sectors (13578 MB) w/1966KiB Cache, CHS=1650/255/63 hdc: 156355584 sectors (80054 MB) w/1819KiB Cache, CHS=155114/16/63, UDMA(133) hdb: ATAPI 40X CD-ROM CD-R/RW drive, 8192kB Cache, UDMA(25) hdd: ATAPI 40X DVD-ROM drive, 256kB Cache, UDMA(33) Which seems to inply there is no dma on hda. However thi disk is perfectly dma capable, as evidenced by : [root@rousalka root]# /sbin/hdparm -iI /dev/hda /dev/hda: Model=IBM-DJNA-371350, FwRev=J76OA30K, SerialNo=GM0GMHP0111 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34 BuffType=DualPortCache, BuffSize=1966kB, MaxMultSect=16, MultSect=off CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=26520480 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 AdvancedPM=no WriteCache=enabled Drive conforms to: ATA/ATAPI-4 T13 1153D revision 17: 1 2 3 4 ATA device, with non-removable media Model Number: IBM-DJNA-371350 Serial Number: GM0GMHP0111 Firmware Revision: J76OA30K Standards: Used: ATA/ATAPI-4 T13 1153D revision 17 Supported: 4 3 2 1 & some of 5 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 26520480 device size with M = 1024*1024: 12949 MBytes device size with M = 1000*1000: 13578 MBytes (13 GB) Capabilities: LBA, IORDY(can be disabled) Buffer size: 1966.0kB bytes avail on r/w long: 34 Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 0 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=240ns IORDY flow control=120ns Commands/features: Enabled Supported: * NOP cmd * READ BUFFER cmd * WRITE BUFFER cmd * Host Protected Area feature set Release interrupt * Look-ahead * Write cache * Power Management feature set Security Mode feature set SMART feature set Address Offset Reserved Area Boot * READ/WRITE DMA QUEUED * DOWNLOAD MICROCODE cmd Security: supported not enabled not locked not frozen not expired: security count not supported: enhanced erase 18min for SECURITY ERASE UNIT.
ide -> Alan
Bug has owner assigned, moving to Assigned state...
Still here in 2.5.58
Still in 2.5.59-bk2
Still in 2.5.63-bk2
Having looked into this a fait bit I dont think this is actually a bug. Our behaviour is not to enable DMA on a device the BIOS has chosen to exclude from DMA. We work on the basis the BIOS has a reason for this. Really this one wants to go toVojtech however
The bios has ne special restriction on this drive (checked bios screens) and it thinks its an LBA ATA66 just like the second HD is detected as CHS ATA133 (tortured pause key to get the bios startup summary) BTW 2.4 behaviour is consistent with 2.5 as of kernel-2.4.20-2.54 (RH Raw Hide)
The only reason I can find the code would decide to do this is if the bios has chosen not to enable DMA on that drive. If it was blacklisted then -d1 wouild also fail.
Well, right now I'm wondering if this is not purely a dmesg bug. I see in proc for hda/settings : name value min max mode ---- ----- --- --- ---- using_dma 1 0 1 rw So is UDMA enabled or not ? Another thing is that this drive is leftover from a previous computer, so it might not like the way modern setup is done.
The little table summary one gets after bios setup just before it tries to load systems says : LBA, ATA66 13579MB CDRW, UDMA 1 CHS, ATA133 80 GB DVD, ATA 33 so the bios do recognize hda as an ata66 drive
It may be recognizing it as ata66 capable but it really seems to be passing the kernel a drive that is marked as pio
But don't these dmesg lines means the bios passes everything as UDMA ? ide0: BM-DMA at 0xdc00-0xdc07, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hdc:DMA, hdd:DMA (I seem to remember that once upon a time when I had non UDMA devices they were declared as PIO here)
Created attachment 199 [details] dmesg
Created attachment 200 [details] lspci
Created attachment 201 [details] /sbin/hdparm -iI /dev/hda
Created attachment 202 [details] Kernel config
[root@rousalka nim]# /sbin/hdparm -d1 /dev/hda /dev/hda: setting using_dma to 1 (on) using_dma = 1 (on) No blacklisting it seems.
Can this bug be closed? Past two years with no activity. Thanks, Nish
well, dmesg still says this drive has no dma, and at this point I'm ready to accept the drive will die before this is fixed, so do as you wish.
Closing since the hard drive finaly died and is no longer available for testing