Description of problem: Drives attached to this interface are unable to use UltraDMA, making them slow. For example, a DVD drive is unable to play DVD's smoothly. see: http://www.linuxquestions.org/questions/history/340897 lspci -v shows the following: 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) (prog-if 80 [Master]) Subsystem: Dell: Unknown device 0189 Flags: 66Mhz, medium devsel, IRQ 5 I/O ports at <ignored> I/O ports at <ignored> I/O ports at <ignored> I/O ports at <ignored> I/O ports at bfa0 [size=16] Capabilities: [70] Power Management version 2 Also, on this page ( http://james.jamesandkristin.net/?p=19 ) I found this: âin /usr/src/linux/include/linux/libata.h change #undef ATA_ENABLE_ATAPI /* define to enable ATAPI support */ to #define ATA_ENABLE_ATAPI /* define to enable ATAPI support */â which is supposed to solve the problem. Version-Release number of selected component (if applicable): kernel-2.6.12-1.1483_FC5
Hi, I have the same trouble here. But enabling ATA_ENABLE_ATAPI doesn't solved the problem. any further solutions ???? Michel. (In reply to comment #0) > Description of problem: > > Drives attached to this interface are unable to use UltraDMA, making them slow. > For example, a DVD drive is unable to play DVD's smoothly. > > see: http://www.linuxquestions.org/questions/history/340897 > > lspci -v shows the following: > > 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev > 03) (prog-if 80 [Master]) > Subsystem: Dell: Unknown device 0189 > Flags: 66Mhz, medium devsel, IRQ 5 > I/O ports at <ignored> > I/O ports at <ignored> > I/O ports at <ignored> > I/O ports at <ignored> > I/O ports at bfa0 [size=16] > Capabilities: [70] Power Management version 2 > > Also, on this page ( http://james.jamesandkristin.net/?p=19 ) I found this: > > âin /usr/src/linux/include/linux/libata.h change > #undef ATA_ENABLE_ATAPI /* define to enable ATAPI support */ > to > #define ATA_ENABLE_ATAPI /* define to enable ATAPI support */â > > which is supposed to solve the problem. > > > Version-Release number of selected component (if applicable): > > kernel-2.6.12-1.1483_FC5
I'm trying hard not to pester about this bug, but I really believe that this needs to be addressed before the release of FC5. Let me explain my reasoning. I've just bought a new laptop for both myself and my wife. Both use this IDE interface, along with a large collection of other newer laptops. Obviously, having forked out significant amounts of money I would expect my laptop to work well. Here's the reality at the moment. Creating an ISO for a DVD takes about 50 - 60 minute depending on size. It took just under an hour to create the ISO for a 3300MB DVD. Writing to the DVD takes another hour for the same ISO. These two things I now do over night so that I aren't trying to use my computer while this is happening because any heavy read or (especially write) activity on the HDD or DVD see the mouse either non-reactive, or very stutter and the rest of the system isn't that responsive either. You can't play DVDs. They play a bit and pause, play a bit and pause. An install of FC4 (which took about 15 minutes on my older Dell 8600 laptop) now takes about 1 hour. Play OGG files from the HDD using rhythm-box while trying to do other work can leave your system unreasonably unresponsive. Updating a kernel-devel system takes about 15 minutes and leave the system unreasonably unresponsive. Boot up takes longer than it needs, too, along with starting larger applications like OpenOffice.org. Compared with how Windows handles these things, (because this is the comparison people are going to make a lot) FC5 is going to look slow, awkward and unresponsive. I don't wish to harp on this, but given that this involves a commonly used Intel chipset, I think it's important that this is addressed so that people will see FC5, (FC4 in the hope that this is back ported) and Linux in general in a good light. Personally, I just want the responsive desktop I know Linux can deliver.
Transfert rates: copy a 2Gb file from the DVD to the Harddisk: windows: 4 minutes. linux kernel 2.6.12: 26 minutes hdparm -t give me the indication that my HDD is working nicely (33Mb/s buffered reading) The DVD is detected as hdc. the harddisk as sda. (In reply to comment #0) > Description of problem: > Drives attached to this interface are unable to use UltraDMA, making them slow. > For example, a DVD drive is unable to play DVD's smoothly. > see: http://www.linuxquestions.org/questions/history/340897 > lspci -v shows the following: > 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev > 03) (prog-if 80 [Master]) > Subsystem: Dell: Unknown device 0189 > Flags: 66Mhz, medium devsel, IRQ 5 > I/O ports at <ignored> > I/O ports at <ignored> > I/O ports at <ignored> > I/O ports at <ignored> > I/O ports at bfa0 [size=16] > Capabilities: [70] Power Management version 2 > Also, on this page ( http://james.jamesandkristin.net/?p=19 ) I found this: > âin /usr/src/linux/include/linux/libata.h change > #undef ATA_ENABLE_ATAPI /* define to enable ATAPI support */ > to > #define ATA_ENABLE_ATAPI /* define to enable ATAPI support */â > which is supposed to solve the problem. > Version-Release number of selected component (if applicable): > kernel-2.6.12-1.1483_FC5
michel, there's no need to keep quoting me when replying. If you want to refer to my comments, then reference the post by prefacing in reference to comment #x (where x is the number of the comment in question).
On my laptop: [root@localhost ~]# hdparm -t /dev/hdc /dev/hdc: Timing buffered disk reads: 2 MB in 3.48 seconds = 588.47 kB/sec [root@localhost ~]# hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 8 MB in 3.52 seconds = 2.27 MB/sec On an older server (Duron 1.0GHz with 512MB RAM, lspci shows 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)): [root@fishbowl root]$ hdparm -t /dev/md0 /dev/md0: Timing buffered disk reads: 52 MB in 3.09 seconds = 16.81 MB/sec [root@fishbowl root]$ hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 80 MB in 3.01 seconds = 26.56 MB/sec Michel, can you paste in the output of running 'hdparm -r /dev/hda'? Also, can you paste in your IDE interface information after running 'lspci -v'?
I'm using kernel 2.6.12-1.1398-FC4. (Btw, it's a FC trouble but a kernel trouble). my harddisk is detected as a SATA one. it's name is sda and not hda. [root@localhost ~]# hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 104 MB in 3.05 seconds = 34.06 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device [root@localhost ~]# hdparm -t /dev/hdc /dev/hdc: Timing buffered disk reads: 4 MB in 3.10 seconds = 1.29 MB/sec dmesg shows: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ide0: I/O resource 0x1F0-0x1F7 not free. ide0: ports already in use, skipping probe Probing IDE interface ide1... hdc: _NEC DVD+/-RW ND-6500A, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hdc: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache ata: 0x170 IDE port busy PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14 ata1: dev 0 cfg 49:2f00 82:7c6b 83:5b08 84:4003 85:7c69 86:1a08 87:4003 88:203f ata1: dev 0 ATA, max UDMA/100, 156301488 sectors: ata1: dev 0 configured for UDMA/100 scsi0 : ata_piix Vendor: ATA Model: TOSHIBA MK8026GA Rev: PA00 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sda: drive cache: write back SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 < sda5 > sda4 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 about lspci, I have the same output as u since I'm using the same motherboard ;) 915GM or 915PM ;) as explained before, there is a bug in the kernel (not special to FC), on windows copying a 2Gb file from the DVD to the HDD took 4 minutes, and on linux 26 minutes on the same computer of course. bye. michel.
Hi again, I build the latest kernel 2.6.13-rc7 with the hack which enables ATAPI support in ata_piix driver. now I have the same speed on linux like on windows !!! I'm happy ;) michel.
FC4 test kernels w/ ATAPI enabled for libata drivers available here: http://people.redhat.com/linville/kernels/fc4/ Please report back on any ATAPI-related problems w/ those kernels...thanks!
John, thanks for this. Unfortunately I'm using rawhide, so I'm not able to test this (or am I?) Dave, any chance of getting this patch compiled into a rawhide kernel so that we can test it there? http://people.redhat.com/linville/kernels/fc4/patches/jwltest-libata-atapi.patch I've been trying to compile it into 1505 myself, but I'm not sure what I'm doing wrong. The compile seems to finish, but there's no RPMS produced. I'm using the SRPM which I've install (as a user) and then doing rpmbuild -bb rpmbuild/SPECS/kernel-2.6.spec --target $(uname -m) having added the patch file and inserting a couple of lines into the SPEC file to get the patch to patch. The patch applies, so I'm not sure where I'm messing up. Rodd
Okay, I tried John's patch on the 1505 kernel from rawhide and it hasn't made any difference. I'm still not able to get ultra_dma working on this system I'll have a look at the ata_piix solution (not sure what this is) and see if I can get this working, but I'm a little concern about the quietness of discussion about this bug since it leaves modern hardware running like an old machine.
Okay, I've been doing a little reseach about the ata_piix.c changes and I'd like a little advice. This page: http://marc.theaimsgroup.com/?l=linux-kernel&m=112033009503058&w=2 has a diff for adding support to linux-2.6.12/drivers/ide/pci/piix.c but someone points out that this patch interferes with other references to the ICH6M. This is the patch: (from the thread earlier). diff -ur a/drivers/ide/pci/piix.c linux-2.6.12/drivers/ide/pci/piix.c --- a/drivers/ide/pci/piix.c 2005-06-17 21:48:29.000000000 +0200 +++ b/drivers/ide/pci/piix.c 2005-07-02 12:37:43.000000000 +0200 @@ -133,6 +133,7 @@ case PCI_DEVICE_ID_INTEL_82801EB_11: case PCI_DEVICE_ID_INTEL_ESB_2: case PCI_DEVICE_ID_INTEL_ICH6_19: + case PCI_DEVICE_ID_INTEL_ICH6_5: case PCI_DEVICE_ID_INTEL_ICH7_21: case PCI_DEVICE_ID_INTEL_ESB2_18: mode = 3; @@ -447,6 +448,7 @@ case PCI_DEVICE_ID_INTEL_82801E_11: case PCI_DEVICE_ID_INTEL_ESB_2: case PCI_DEVICE_ID_INTEL_ICH6_19: + case PCI_DEVICE_ID_INTEL_ICH6_5: case PCI_DEVICE_ID_INTEL_ICH7_21: case PCI_DEVICE_ID_INTEL_ESB2_18: { @@ -575,6 +577,7 @@ /* 21 */ DECLARE_PIIX_DEV("ICH7"), /* 22 */ DECLARE_PIIX_DEV("ICH4"), /* 23 */ DECLARE_PIIX_DEV("ESB2"), + /* 24 */ DECLARE_PIIX_DEV("ICH6M"), }; /** @@ -651,6 +654,7 @@ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_21, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 21}, { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 22}, { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB2_18, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 23}, + { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_5, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 24}, { 0, }, }; MODULE_DEVICE_TABLE(pci, piix_pci_tbl); ["ich6m-pciid-piix.patch" (ich6m-pciid-piix.patch)] diff -ur a/drivers/ide/pci/piix.c linux-2.6.12/drivers/ide/pci/piix.c --- a/drivers/ide/pci/piix.c 2005-06-17 21:48:29.000000000 +0200 +++ b/drivers/ide/pci/piix.c 2005-07-02 12:37:43.000000000 +0200 @@ -133,6 +133,7 @@ case PCI_DEVICE_ID_INTEL_82801EB_11: case PCI_DEVICE_ID_INTEL_ESB_2: case PCI_DEVICE_ID_INTEL_ICH6_19: + case PCI_DEVICE_ID_INTEL_ICH6_5: case PCI_DEVICE_ID_INTEL_ICH7_21: case PCI_DEVICE_ID_INTEL_ESB2_18: mode = 3; @@ -447,6 +448,7 @@ case PCI_DEVICE_ID_INTEL_82801E_11: case PCI_DEVICE_ID_INTEL_ESB_2: case PCI_DEVICE_ID_INTEL_ICH6_19: + case PCI_DEVICE_ID_INTEL_ICH6_5: case PCI_DEVICE_ID_INTEL_ICH7_21: case PCI_DEVICE_ID_INTEL_ESB2_18: { @@ -575,6 +577,7 @@ /* 21 */ DECLARE_PIIX_DEV("ICH7"), /* 22 */ DECLARE_PIIX_DEV("ICH4"), /* 23 */ DECLARE_PIIX_DEV("ESB2"), + /* 24 */ DECLARE_PIIX_DEV("ICH6M"), }; /** @@ -651,6 +654,7 @@ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_21, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 21}, { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 22}, { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB2_18, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 23}, + { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_5, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 24}, { 0, }, }; MODULE_DEVICE_TABLE(pci, piix_pci_tbl); These references are in drivers/scsi/ata_piix.c and drivers/scsi/ahci.c Could I apply this patch without causing grief (just to see if it addressed the problem) or should I tread very carefully?
If you use the patch in comment 11 you'll have to replace "ahci" with "ata_piix" in /etc/modprobe.conf and rebuild your initrd before booting with the new kernel. I think you will get poorer performance from your hard drive while using ata_piix, but I'm not 100% sure of that. I think the libata ATAPI is the better solution, but Jeff feels it really isn't ready. I did get a rawhide-based test kernel built w/ ATAPI enabled if you want to try my version: http://people.redhat.com/linville/kernels/fc5/ Use at your own risk. Again, Jeff feels that libata ATAPI is not ready for prime time, and he is the expert. I'm not sure where that leaves you. I would guess that the ata_piix trial is probably the best thing in the short run. Just remember to rebuild your initrd as described above.
Hmmm, here's an interesting twist. I've just done some testing on my wife's laptop (a FC4 machine with the same IDE chipset) and noticed that here HDD works well, but here DVD drive doesn't. I then realized that when I did the initial install of FC4 (to update to rawhide) FC4 saw my HDD as /dev/sda and my DVD drive as /dev/hdc. I rebooted into a working (although unupdated version of FC4 - my wife's FC4 is up-to-date) and ran hdparm -t /dev/sda with the following results: [root@localhost ~]# hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 118 MB in 3.01 seconds = 39.14 MB/sec HDIO_DRIVE_CMB(null) (wait for flush complete) failed: Inappropriate ioctl for device Rebooting to rawhide I get this: [root@localhost ~]# hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 8 MB in 3.63 seconds = 2.20 MB/sec At some time in updating from FC4 to rawhide, FC started to see my primary HDD as /dev/hda instead of /dev/sda. Obviously the later is far better as it works at the right speed. Also of note, this explains why a lot of people are only seeing this problem with there DVD drives. The DVD drives are being seen as /dev/hd? while the HDD is being seen at /dev/sd?. What changed that FC now sees my HDD as a /dev/hd? instead of a /dev/sd?. It's apparent that my drive can work at the right speed, but some recent change has left it handicapped.
Okay, more on the scsi comments. Noticed on this page: http://gentoo.kaeptnovi.ch/ that the person notes that they managed to get better performance from their DVD drive by patching libata.h and also by forcing the kernel to see the DVD drive as a SCSI device. From the page ---------------------- By default the DVD-Drive will not run in DMA mode. With a small change to the kernel-headers you can greatly improve performance: edit the file /(path-to-kernel-source)/include/linux/libata.h change the line #undef ATA_ENABLE_ATAPI to #define ATA_ENABLE_ATAPI and recompile your kernel You might need to pass ide1=noprobe to the kernel -> see my lilo.conf . Note that now your device won't be called /dev/hdc anymore since it's now seen as a SCSI device ----------------------- Why is the kernel giving better performance for drives which are seen as scsi drives, rather than ATA drives?
I have opened a seemingly similar bug #168363... This is on an ICH5 ata_piix SATA controller, that was working great on FC4 but drops from ~56MB/sec down to ~3MB/sec on the rawhide kernels...
I am seeing similar behavior to those in comment #13, using an IBM ThinkPad T43 with an ICH6M SATA controller, and FC4 + updates to date, and either kernel 2.6.12-1.1398_FC4 or 2.6.12-1.1447_FC4: # ------ lspci -v output: 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) (prog-if 80 [Master]) Subsystem: IBM: Unknown device 056a Flags: bus master, 66Mhz, medium devsel, latency 0 I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at 18c0 [size=16] Capabilities: [70] Power Management version 2 # ------------------- The hard disk is seen as /dev/sda and performs appropriately (~30-35 MB/sec using hdparm -t test). The DVD-RW/CD-RW combo is seen as /dev/hdc and performs very poorly when doing disk reads or writes. I am unable to write reliably over 12x, while the advertised drive capability should be 24x without a problem. I am downloading John Linville's kernel-2.6.12-1.1454.2.3_FC4.jwltest.17.i686.rpm package and will test results here.
The kernel-2.6.12-1.1454.2.3_FC4.jwltest.17.i686.rpm package from John Linville works well provided I use "ide0=noprobe ide1=noprobe" in my kernel boot parameters. Hard drive transfer rates are as expected, reading data or audio CD's no longer tortures the CPU, and I can burn CDs at acceptable speeds now without buffer underruns.
Any chance we could get John Linville's patched rolled into a current kernel so that we could test this on rawhide. I know that John did this a while back, but something a little more recent might be more appropriate. I know that what John has done in the patch isn't the best solution, but given this 'best solution' isn't appearing any time soon, and that John's patch might help, it's better than nothing (and now would be the time to test it).
If something is not the best solution possible, it's probably a much more viable plan to work on the proper fix for this. There is really no reason why we'd want to spend time working on something we know up front is not the right thing! This worked in the recent past, so i guess it's fixable for the kernelhackers. I may be missing something, though!
I agree, but... Have a look through some of the links (and beyond) that I provided near the start of this bug report. The conversation seems to be that while the patch 'works' it's not the best way to go. However, no-one seems to have a better option. I'm all for the better option, but I've also have my $3500 laptop for long enough that I'd settle for a workaround in the meantime so that I can watch a DVD, or write CD-Rs are full speed, or just install a kernel-devel without my mouse going to hell and the system being unusable. All I'm suggesting is that we try the work around 'until' someone comes up with something better. I've got my suspicions that the work around won't work for the rawhide kernels. When I installed FC4, it saw my harddisk as /dev/sda, but somewhere in the upgrade to FC5 it now sees the HDD as /dev/hda. Users of FC4 only get shitty performance on their DVD (or CD) drives, but users of rawhide get shitty performance on their harddisks too.
The patch in question merely defines ATA_ENABLE_ATAPI in libata.h. I'm glad this improves things for you, but I don't think we can make this official w/o jgarzik's expressed blessing. However, I'm sure he is glad for the testing datapoint. I'll be happy to carry the ATA_ENABLE_ATAPI patch in my test kernels for the time being -- just don't be mad if things blow-up! :-) Feel free to nudge me to do new kernels if/when I fail to keep-up w/ Dave's releases...
John, The libata.h patch is only confirmed to work on FC4 kernels. I've tried the patch (which you rolled) on the rawhide kernel, but it didn't work. I'm wanting to try with the "ide0=noprobe ide1=noprobe" kernel parameters. Also, could you post where to get your kernels from?
oh, and who is jgarzik? Is there any way that we can help him with this work? Testing?
The locations of my test kernels are listed in comment 8 and comment 12. If FC4 works and FC5 does not, I have no good explanation other than that there might be another problem w/ FC5. Who is jgarzik? For one, he is the asignee for this bug... :-) He also is the maintainer and primary developer for libata, the SATA support in the kernel. You might subscribe to the linux-ide mailing list if you want to keep-up with what he is doing.
ide0=noprobe ide1=noprobe have some serious impact on my system with the normal rawhide 2.6.13-1.1561_FC5{smp,} kernels. changes my disk from hda to sda and ups performance back to expected levels. I still get some "Inappropriate ioctl for device" errors, running hdparm, though
Currently libata doesn't support many/most/all of the ioctls used by hdparm. Hopefully that will change in the future, but for now...
Okay, that part of the mystery demystified, then :o) However, it is stille a huge problem that the kernel does not probe the controllers properly... How to address this issue?
It is expected behavior that CD/DVD drives come up at /dev/hdX, and function without DMA. It is slow, but everything is working properly. Fiddle with BIOS settings to disable "combined mode", to work around this. In a future kernel, we can enable libata's ATAPI support, once a few more bug fixes have been merged.
It's not expected that the IDE chipsets gets probed to thing a SATA harddisk is a normal IDE disk, is it??? our /dev/sd? devices show up like /dev/hd? and performs really badly! This is not only for CD/DVD drives! Also it worked in previous kernels. I may be missing the point but in my mind, with my current understanding of things, this does not qualify as NOTABUG??? Does enabling libata's ATAPI support automagically fix the probing too? Sorry if i'm being lame here!
Please file a separate bug, if your hard drives are being misdetected. It is expected behavior for PATA devices to be driven by the IDE driver -- possibly without DMA support -- and for SATA devices to be driven by the libata driver. Not optimal behavior, and will be fixed eventually, but not a bug either.
Okay... Tracking the device detection problems in bug #168363 thanks for the explaination, Jeff