[HARDY-LUCID] No DMA nor 32bits IO support

[Skippy le Grand Gourou]

Hi,

I installed Ubuntu Hardy on a Compaq Presario R4206EA (R4000 series) which had Edgy on another partition. This laptop has a DVD-RW burner which works fine under Edgy, however the DMA activation and 32 bits IO support fail under Hardy. The immediate consequence is that it is impossible to watch a DVD on it (too jerky), and that it takes 3h20 to burn a 3.5GB data DVD…

Here is the output of hdparm under Hardy :

------------------------------- 8< -------------------------------
$ sudo hdparm /dev/cdrom (seen as /dev/scd0)
/dev/cdrom:
 IO_support = 0 (default)
16-bit)
 HDIO_GET_UNMASKINTR failed: Inappropriate ioctl for device
 HDIO_GET_DMA failed: Inappropriate ioctl for device
 HDIO_GET_KEEPSETTINGS failed: Inappropriate ioctl for device
 readonly = 0 (off)
 readahead = 256 (on)
 HDIO_GETGEO failed: Inappropriate ioctl for device
------------------------------- 8< -------------------------------

Same under Edgy :

------------------------------- 8< -------------------------------
$ sudo hdparm /dev/hdc
/dev/hdc:
 IO_support = 1 (32-bit)
 unmaskirq = 0 (off)
 using_dma = 1 (on)
 keepsettings = 0 (off)
 readonly = 0 (off)
 readahead = 256 (on)
 HDIO_GETGEO failed: Inappropriate ioctl for device
------------------------------- 8< -------------------------------

Here are the capabilities of the burner (same output in both versions) :

------------------------------- 8< -------------------------------
$ sudo hdparm -i /dev/cdrom
/dev/cdrom:
 Model=TSSTcorpCD/DVDW TS-L532R , FwRev=HA05 ,
SerialNo=454F208147
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=2048kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2
 AdvancedPM=no
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-3,4,5,6,7
 * signifies the current active mode
------------------------------- 8< -------------------------------

And then, under Hardy :

------------------------------- 8< -------------------------------
$ sudo hdparm -c1 -d /dev/cdrom
/dev/cdrom:
 setting 32-bit IO_support flag to 1
 HDIO_SET_32BIT failed: Invalid argument
 IO_support = 0 (default)
16-bit)
 HDIO_GET_DMA failed: Inappropriate ioctl for device
------------------------------- 8< -------------------------------

I used to boot Edgy on a customed 2.6.20 kernel for other reasons. I use Hardy's default one. I cannot perform any other tests on Edgy because I already formated it (may have the kernel config somewhere if needed though). Please find verbose lspci, dmidecode and lshw output in attachment. Forgot dmesg, I will send it asap (laptop not available now).

I was in a hurry and didn't have much time to perform tests on the hard drive. I think it has the same kind of problems, but I don't remember well and am thus not sure. I will communicate about it when available (not before one month though…).

Possibly related reports, at least : #205817, #216878, #224561, #221455, #221455, #135473, #136506, #155511…

[Skippy le Grand Gourou (lecotegougdelaforce)]

Dmidecode output.

[marco_costa (marco-antonio-costa)]

I'm having the same problem. I have a Gigabyte GA-945CGM-S2L mobo, so I must fall into that combined mode issues category. Changed SATA mode in the bios to Enhanced, for what's worth. And I got 1 ATA133 drive (running hardy) and a DVD ( on the same IDE ribbon cable, ata133 capable ) and a separate maxtor 160g SATA2 drive that i use for gen storage. I'm attaching my diag files output for help.

[Yannick (splitsch)]

Same here!
I have a really poor transfer rate to external usb key et from usb key (2 or 3 Mb/sc)

Do you need more info ?

lspci -v | grep HCI
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI])
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI])
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) (prog-if 00 [UHCI])
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI])

-------------------------
sudo hdparm -cd /dev/sda
[sudo] password for splitsch:

/dev/sda:
 IO_support = 0 (default)
16-bit)
 HDIO_GET_DMA failed: Inappropriate ioctl for device

[Skippy le Grand Gourou (lecotegougdelaforce)]

Is anyone even caring about this fucking bug ?!? Two monthes that it has been filed, and still open, still flagged as "New" and even still of "Undecided" importance while the solution is so well-known !!! (I didn't have access to the computer up to now)

The problem is related to the libATA. It is likely to be related to Intel's combined mode, however I found the solutions listed on libATA website only after solving the problem another way.

I suggest people to feedback after testing solutions given here : http://linux-ata.org/faq.html#combined

If it doesn't work (as I said I didn't test myself, found it too late), then try with "my" (actually well disseminated on the web) solution : add those lines to /etc/modprobe.d/blacklist :
blacklist pata_atiixp
blacklist pata_acpi
blacklist sg
blacklist sr_mod
blacklist sd_mod
(NB : it was not necessary for me to blacklist sg and sd_mod, but I had problems only with my DVD recorder)

/dev/sdX will become /dev/hdX and UUIDs will change, so don't forget to change entries in /etc/fstab (and maybe /boot/grub/menu.lst) and swap's UUID in /etc/initramsf-tools/conf.d/resume (and to "update-initramfs -u -k all" after this latter operation). [Reminder: "blkid" for knowing UUIDs]

Old perfs (hdparm -T) :
 Timing cached reads: 2 MB in 2.39 seconds = 856.86 kB/sec
New perfs :
 Timing cached reads: 1028 MB in 2.00 seconds = 514.25 MB/sec

Thanks guys.

[Brian Murray (brian-murray)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in linux the kernel package in Launchpad.

[alexserver (alexserverone)]

SO what's next ?
I've downloaded new intrepid release and I still having troubles with dma !

[Ajay (ajaygautam)]

You have got to be kidding me! I can't believe a bug of this level can exist for SO LONG...

The other day, I had to get some work done, and wanted distraction for my kid. So I put on one of his fav. Disney DVDs in my ubuntu (9.04) system... that should keep him busy...

Lo and behold... a capable system with choppy DVD playback! I didn't have the time to look into it then, so I (guiltily) asked my (first-born) child to sit through choppy video.

Its simple things like these that make me want to switch back to windows. Atleast I shouldn't have to fight with the system to get BASIC FUCKING SERVICES to work! I mean... come on guys... its 2009!! Ubuntu is *supposed* to be THE desktop linux system.

... sigh ... Perhaps 2009 is not going to be the year of the linux desktop, after all.

Things have gotten from OK to bad to worse! I installed ubuntu a few years ago, and things were fine... with each new version, things have gotten noticeably worse!

</rant>

root@Komputor:~# hdparm /dev/sr0

/dev/sr0:
 IO_support = 0 (default)
 readonly = 0 (off)
 readahead = 256 (on)
 HDIO_GETGEO failed: Inappropriate ioctl for device
root@Komputor:~#
root@Komputor:~# hdparm -d /dev/sr0

/dev/sr0:
 HDIO_GET_DMA failed: Inappropriate ioctl for device
root@Komputor:~#
root@Komputor:~# hdparm -d /dev/sda1

/dev/sda1:
 HDIO_GET_DMA failed: Inappropriate ioctl for device

[kernel-janitor (kernel-janitor)]

Hi lecotegougdelaforce,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/releases/ . Please then run following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux-image-`uname -r` 228302

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Skippy le Grand Gourou (lecotegougdelaforce)]

kernel-janitor a écrit :
> Hi lecotegougdelaforce,
>
> Please be sure to confirm this issue exists with the latest development
> release of Ubuntu. […] Please let us know your results.

Unfortunately I think I won't be able to test this before a long while.
Hopefully other subscribers will report on this.

[Skippy le Grand Gourou (lecotegougdelaforce)]

Any update on this ? I still won't have access to my Ubuntu box for months and don't have time to install a new one just for that, but I think this bug should be closed as soon as possible, so if anyone could test and confirm the post #15…

[Vanessa Dannenberg (vanessadannenberg)]

This problem affects Jaunty as well. Will *not* be trying Karmic anytime soon. Like others, the system in question here is an IDE/ATAPI device (in my case, a Memorex Lightscribe-capable DVD burner) and hdparm just won't talk to it because of this /dev/srX business.

Note that this is not something that is being forced by the kernel; on the other machine at my house, a generic kernel is in use (rather than the Ubuntu-supplied one), and it treats IDE devices as /dev/hdX like it *should*.

[Skippy le Grand Gourou (lecotegougdelaforce)]

Didn't want to mark bug #290554 as duplicate since the issue may be a bit different but I doubt it, and Karmic Koala didn't seem to solve anything according to the last comment on it.

[Skippy le Grand Gourou (lecotegougdelaforce)]

Not sure, maybe related : bug #228624

[xteejx (xteejx-deactivatedaccount)]

As the kernel janitor explained, this needs to be tested in Karmic. There are enough duplicates here, surely someone is able to do this.

[Marc Quinton (mquinton)]

as reported in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/175022

hello, I'm using karmic, here is the dmesg related to this BUG :

[ 2.824409] ata6.00: ATAPI: TSSTcorpCD/DVDW SH-S162L, TS04, max UDMA/33
[ 2.824443] ata6.00: WARNING: ATAPI DMA disabled for reliablity issues. It can be enabled
[ 2.824446] ata6.00: WARNING: via pata_ali.atapi_dma modparam or corresponding sysfs node.
[ 2.856347] ata6.00: configured for UDMA/33
[ 2.857264] scsi 5:0:0:0: CD-ROM TSSTcorp CD/DVDW SH-S162L TS04 PQ: 0 ANSI: 5
[ 2.860086] sr0: scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda tray
[ 2.860090] Uniform CD-ROM driver Revision: 3.20
[ 2.860191] sr 5:0:0:0: Attached scsi CD-ROM sr0
[ 2.860255] sr 5:0:0:0: Attached scsi generic sg3 type 5
[ 2.860296] Freeing unused kernel memory: 540k freed

the bug seems to be still present under karmic, but with new message error :
 - still having heavy load by default,
 - Issuing echo 1 > /sys/module/pata_ali/parameters/atapi_dma resolved my problem.

[xteejx (xteejx-deactivatedaccount)]

In Karmic, can you run "apport-collect 228302" without quotes please and let it grab all the debugging info. Thank you.

[Igor Wojnicki (wojnicki)]

Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: wojnicki 1949 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'M5455'/'ALi M5455 with ALC850 at irq 18'
   Mixer name : 'Realtek ALC850 rev 0'
   Components : 'AC97a:414c4790'
   Controls : 42
   Simple ctrls : 27
CurrentDmesg:
 [ 23.426892] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
 [ 30.274717] agpgart-amd64 0000:00:00.0: AGP 3.0 bridge
 [ 30.274738] agpgart-amd64 0000:00:00.0: putting AGP V3 device into 8x mode
 [ 30.274771] nvidia 0000:01:00.0: putting AGP V3 device into 8x mode
 [ 33.640037] eth0: no IPv6 routers present
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=7f5ec356-db73-4828-a34d-80d298501d90
IwConfig:
 lo no wireless extensions.

 eth0 no wireless extensions.
Lsusb:
 Bus 002 Device 002: ID 046e:556e Behavior Tech. Computer Corp.
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
NonfreeKernelModules: nvidia
Package: linux (not installed)
ProcCmdLine: root=UUID=34c64732-dc9e-487b-93cd-f0211b4a771c ro all_generic_ide resume=/dev/sdb6 quiet splash
ProcEnviron:
 LC_PAPER=pl_PL.utf8
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
 LC_CTYPE=pl_PL.utf8
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
RelatedPackageVersions:
 linux-backports-modules-2.6.31-14-generic N/A
 linux-firmware 1.24
RfKill:

Uname: Linux 2.6.31-14-generic i686
UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin plugdev vboxusers video
WpaSupplicantLog:

XsessionErrors:
 (gnome-settings-daemon:1962): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:1962): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (nautilus:1997): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:2024): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (gnome-panel:1996): Gdk-WARNING **: /build/buildd/gtk+2.0-2.18.3/gdk/x11/gdkdrawable-x11.c:952 drawable is not a pixmap or window
dmi.bios.date: 07/21/2005
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F6
dmi.board.name: M1689D
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF6:bd07/21/2005:svn:pn:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnM1689D:rvrx.x:cvn:ct3:cvr:

[Marc Quinton (mquinton)]

Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: marc 1966 F.... pulseaudio
                      tine 4758 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'M5461'/'HDA ULI M5461 at 0xfeaf8000 irq 22'
   Mixer name : 'Realtek ALC880'
   Components : 'HDA:10ec0880,1019e601,00100800'
   Controls : 39
   Simple ctrls : 22
CheckboxSubmission: 651fd9ad5963f1632574fdcdd836f83f
CheckboxSystem: ed860a78372b8df3c145b069c05b29f4
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=2a2cbb41-1f37-4e0a-96b2-819b69cbfb6c
IwConfig:
 lo no wireless extensions.

 eth0 no wireless extensions.
Lsusb:
 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
NonfreeKernelModules: nvidia
Package: linux (not installed)
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-14-generic root=UUID=afc239b4-3496-41cc-a6da-a6cfe45c11b4 ro quiet splash
ProcEnviron:
 PATH=(custom, no user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
RelatedPackageVersions:
 linux-backports-modules-2.6.31-14-generic N/A
 linux-firmware 1.24
RfKill:

Uname: Linux 2.6.31-14-generic i686
UserGroups:

dmi.bios.date: 01/06/2006
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1.0
dmi.board.name: To be filled by O.E.M.
dmi.board.vendor: To be filled by O.E.M.
dmi.board.version: To be filled by O.E.M.
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: peristyle
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.0:bd01/06/2006:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnTobefilledbyO.E.M.:rnTobefilledbyO.E.M.:rvrTobefilledbyO.E.M.:cvnperistyle:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

[Marc Quinton (mquinton)]

sorry for this double post :-)

[Igor Wojnicki (wojnicki)]

I've got the same problem here (apport-collect data included previously).
Issuing echo 1 > /sys/module/pata_ali/parameters/atapi_dma doesn't help. The cdrom stops working, any read/write operation fails.

I fixed it by compiling the kernel myself with:
- disabling pata_ali (Device drivers/Serial ATA.../ALi PATA...)
- enabling ata_generic as a module (sic!) (Device drivers/Serial ATA.../Generic ATA Support)

Additionally I use a kernel option:

all_generic_ide

It does help.

I'm including my kernel config.

[Igor Wojnicki (wojnicki)]

Oh and one more thing. Regarding different ubuntu versions:

  - 8.10 worked if all_generic_ide was specified as a kernel parameter
  - 9.04 worked but only the 386 kernel flavour (linux-image-*-386) if all_generic_ide was specified as a kernel parameter the generic kernel did't work.
  -9.10 no kernel works!

[xteejx (xteejx-deactivatedaccount)]

That's brilliant guys thank you for the info!! This can now be pushed on a step to Triaged status, so now there is enough information for a developer to have a look at this and begin working on it. If they need any more info, please provide it. Thank you again guys for reporting this and helping to make Ubuntu better! :)

[Igor Wojnicki (wojnicki)]

Teej, any progress with the bug? There's been a couple of kernel updates since your post (#60) but none of them includes the proposed solution (#59). Any word from the devolper(s)? If there is any other solution I volunteer to test it since I own a machine which is subject to this bug.

[xteejx (xteejx-deactivatedaccount)]

So far nothing, as there hasn't been any developer comments on here. When they take over and have a look I'm sure they will comment on this bug report and suggest/make any necessary changes/fixes to the packages needed. Also guys, if they ask for or require any further information, please provide it so they can work on getting this fixed.
I will see what I can do to push this through.

[Canada Lee (lee-howard)]

Hello, I am a n00b here with Linux, I have been a Windows user since Win 3.1. I have tried red-hat back in 94 and it required a floppy boot disk everytime to boot into Linux, and was heavy with the terminal commands.

Anyways, I dont know how to supply detailed info like other have in their replies, I wouldnt know if I need to download any of the terminal commands they used like UNAME or whatever.

Here's what I know...

Fresh install of Ubuntu 9.10 Karmic from the Live CD (not the alternate one)...with the regular updates which happen by themselves.

My drives are in 16-bit IO transfer without DMA enabled.

I have a Gigabyte Motherboard (one of the latest ones), and I have a SATA HDD and DVD-RW drive.

And my drives are operating super slow...copying 8gb of files (approx 9 or 10 files) from 1 partition to another partition on the same HDD took over 1 hour and 30 mins!!! USB flash drives are slow too!

I get that loct error when trying to enable 32-bit IO and/or DMA.

My memory runs at 1800mhz in windows...(prob not in ubuntu) and my motherboard has the high speed SATA-II support with the advanced power savings features where is throttles not only the CPU freq, but also the power phase...(definitely not in ubuntu), but sadly the 400gb HDD is not SATA-II.

But I'll tell you a secret... It should be doing Ultra DMA mode 5 or 6 and blazing fast, and it shouldnt be doing 16-bit IO either!

I remember having an 80486DX4 100MHz computer and the HDD back then was using 32-bit IO.

If anyone wants me to supply some detailed info, just tell me how to do it and where to find the software to do it, and it will be done.

I am amazed tho, in this day an age, and looking at how long this bug has been in existence (this post alone is 2 years and running)... I am seeing a pattern...and that pattern is, a new version of Ubuntu will be made...then another one...and so on, then in time a 128-bit Ubuntu Operating System will come out... They'll keep pumping out the Operating Systems, versions...but not fix the previous one...

Imagine how good is that, a 128-bit Ubuntu Operating System, via a 16-bit IO transfer! When they come out with 64-bit IO transfer, we'll be at 32-bit...(maybe...hopefully), and when they come out with 128-bit IO transfer, we'll be at 32-bit (maybe...hopefully). But hey...we'll have loads of new releases of Ubuntu all at 16-bit IO in the meantime.

Its a shame, a friend told me about ubuntu, and I thought I'd try it out, see if it got more like a GUI OS as opposed to that red-hat 94 one I had, and was well impressed with it.

Just drive access like a Commodore Amiga is all...

In the meantime I dual boot into Windows (thank god I kept my Windows) if I wanna copy files around, or burn disks... I can't wait 1 hour and 30 mins for something that takes 15 mins or less in Windows.

Hope a solution to this will be found in the next 2 years!

[Igor Wojnicki (wojnicki)]

Canada Lee, I'm afraid your problem might be unrelated to this very bug, which applies to a regression with handling DMA. Your issue regards fairly new hardware - I'd suggest you to file another bug, just open a terminal and type:
apport-bug linux

[Chase Douglas (chasedouglas)]

@Igor:

You added the regression-potential flag, which means that this is also an issue in Lucid. Have you confirmed that this is still a bug in Lucid?

Thanks

[Steve Murphy (stevemurphy)]

This issue definitely still exists in Lucid.

[Steve Murphy (stevemurphy)]

dmesg output is attached showing that the issue still occurs

[ 1.120376] ata2.00: ATAPI: TOSHIBA DVD-ROM SD-R2312, 1905, max MWDMA2
[ 1.120453] ata2.00: WARNING: ATAPI DMA disabled for reliability issues. It can be enabled
[ 1.120513] ata2.00: WARNING: via pata_ali.atapi_dma modparam or corresponding sysfs node.
[ 1.136287] ata2.00: configured for MWDMA2

[Igor Wojnicki (wojnicki)]

Chase, It's still there! It's been since some time ago, see post #59. There is a solution (see #58) but I'm not sure if it doesn't introduce other problems - it works for me though. But it's really frustrating to configure and compile the kernel everytime...

The solution is there (or workaround), the developers have updated the kernel several times since the bug was submitted and triaged, no developer has confirmed it though... that's why I added the regression-potential tag. There is a regression!!! It's been there for a few years now! Please do sth about it.

[Montblanc (montblanc)]

Please, remember: a workaround is NOT a solution. With this workaround, CPU usage is back to normal, but we can't write to full speed and that's really frustrating. The only way to solve this bug is getting Canonical to change its policy about PATA drivers, or just surrender to new Ubuntu versions solving something and screwing up another one.

[Igor Wojnicki (wojnicki)]

Montblanc. I'm not sure of what kind of 'full speed writting' you are talking about.

My observation is that pata_ali DOES NOT WORK properly with CD/DVD drives. Burinig a disck using pata_ali is hardly possible, takes 100% cpu and takes forever since cdrom DMA transfers are disabled. Enabling DMA through /sys makes reading/writting impossible (errors).

Using ata_generic instead of pata_ali solves all the problems. DMA works fine. Current ubuntu kernels prevent the user to choose ata_generic over pata_ali!

Regarding possible inferior performance of ata_generic I've discovered that there are none. See attached performance and dmesg results.

Files: *.custom hold results for my customized kernel (see post #58) with ata_generic instead of pata_ali driver. Other files hold results for the current Karmic kernel with pata_ali.

So there are two possible solutions:
1. somebody fixes pata_ali driver which seems to be broken - mind the warning: WARNING: ATAPI DMA disabled for reliablity issues - it's ridiculous, especially that ata_generic works fine.
2. ubuntu developers prepare the kernel in such a way which allows to use generic_ata driver! which I agree is kind of workaround, but it might be just good enough, and it's way better that the current situation which prevents using a cdrom/dvd drive!

[Igor Wojnicki (wojnicki)]

Mind also reading performance difffernences between hdparm.cdrom (pata_ali, broken DMA) and hdparm.cdrom.custom (generic_ata, DMA OK)!

[Conn O Griofa (psyke83)]

Igor,

Let's try to get a summary of action needed.

Problem: the "pata_ali" kernel driver does not support ATAPI DMA transfers properly on certain ALI chipsets (even if force-enabled via the driver option "atapi_dma=1"). The "ata_generic" kernel driver supports ATAPI DMA transfers for such chipsets and has a special kernel boot option, "all_generic_ide", which causes it to override the manufacturer-specific drivers. However, this option does not work correctly when the "ata_generic" and "pata_ali" drivers are compiled-in to the kernel, which means that the "ata_generic" driver is impossible to use.

Solution:

Change these kernel config parameters:
CONFIG_PATA_ALI=y
CONFIG_ATA_GENERIC=y

To the following:
CONFIG_PATA_ALI=m
CONFIG_ATA_GENERIC=m

Result:
1. For all other users: there will be no functional difference between the original and modified kernel configuration (as long as the logic to automatically modprobe the "ata_generic"/"pata_ali" kernel modules is properly in place)
2. For users with buggy ALI chipsets, they can now take advantage of the kernel boot options "all_generic_ide" and/or to manually blacklist the "pata_ali" driver, which will cause the ata_generic driver to be used (and as a result, ATAPI DMA will work properly).

Am I missing anything, Igor?

[Igor Wojnicki (wojnicki)]

Conn, You've got it right. I've just verified it.

[Igor Wojnicki (wojnicki)]

By the way, I'm not sure that some "ALI chipsets are buggy". If ata_generic works fine, and pata_ali does not it would point at a bug in the pata_ali driver. But it's just my thought - I haven't investigated the kernel sources or the chipset itself.

[Conn O Griofa (psyke83)]

Andy,

I noticed that you re-modularized the PATA/SATA drivers in kernel 2.6.32-17.26. Unfortunately, you forgot to re-modularize the ata_generic module as well. I tried blacklisting the pata_ali driver and booting with "all_generic_ide", but no hard drives or ATAPI drives were detected, and I was booted to the initramfs shell. I suspect that the boot option isn't parsed because the ata_generic module is still built-in to the kernel.

... or perhaps the option has been renamed; I'll do some experimenting and try to find out.

[Igor Wojnicki (wojnicki)]

I've double checked current lucid kernel linux-image-2.6.32-21-generic_2.6.32-21.32 and it seems that it is not fixed! There is no ata_generic.ko there. So ALI owners will still suffer from disabled DMA! Please alter the package to reflect the changes summarized by Conn in post #80.

[Conn O Griofa (psyke83)]

Igor, Andy &others,

I've done some investigation and found that it's not necessary to build ata_generic.ko as a module. From the kernel-parameters.txt documentation I noticed it says the following:

"Module parameters for modules that are built into the kernel image
are specified on the kernel command line with the module name plus
'.' plus parameter name, with '=' and value if appropriate [...]"

Therefore, the parameter we should use is: ata_generic.all_generic_ide=1

So, this is how to get it working:
1. Add "blacklist pata_ali" to /etc/modprobe.d/blacklist
2. Run "sudo update-initramfs -u"
3. Add "ata_generic.all_generic_ide=1" to the GRUB_CMDLINE_LINUX line in /etc/default/grub
4. Run "sudo update-grub"
5. Reboot (preferably using the recovery option so that you can see the verbose boot information).

WARNING: the above instructions may render your system unbootable (as it did for myself). If that happens, you will need to boot from a live CD, chroot into your installation and undo the blacklisting of the pata_ali module. If you're not comfortable with this risk, then don't follow the steps above.

Unfortunately, this still doesn't solve the problem for me, as the ata_generic driver refuses to work with my hard drive (spewing DMA errors). If I can find some way to make the kernel assign the pata_ali to ATA port 1 (my hard disk) and ata_generic to ATA port 2 (CD-ROM), perhaps that would work. If anyone has suggestions, let me know.

[1] http://www.kernel.org/doc/Documentation/kernel-parameters.txt

[Igor Wojnicki (wojnicki)]

Conn, thanks for the tip. It works fine for me.

Unfortunately I don't know how to assign different drivers for different ATA ports :( I've been poking around but haven't found anything useful. I was also trying to disable pata_ali when compiled in (along with ata_generic) - to no avail :(

Regarding Karmic. Is there any chance that these module arrangements (ata_generic compiled in, pata_ali as a module) could be backported to Karmic?

[Antonio O. (aokenator)]

Hi guys and thank you everybody for your support.

I solved with my pata_sis in a very basic way, perhaps not very orthodox:

I started my s.o. with this (grub) command line:

... ata_generic.all_generic_ide=1 libata.fake_parm=0

It caused libata, pata_sis and pata_acpi fail in module loading.
Once my system mounted any hard-disk partitions as hda instead of sda then I added a grub line with that expedient to my grub menu.
I'm having some minor problems with hdparm to force the flag -c1 at boot.
Somebody talked about a inittab change... I will try.

Hi everybody.

[Montblanc (montblanc)]

Igor,
I really appreciate the efforts you're putting into solving this bug, however I think the changes you made to Lucid kernel brought different troubles to my system (Uli M1575 chipset), forcing me to file bug #591532 . The reason why I think that bug is related to this one is because:

1) I'm affected by this bug since Feisty
2) The DMA errors I get in bug #591532 started appearing with Lucid
3) The changes you committed to Lucid kernel strongly affect my hardware
4) If I follow Antonio O.'s tips about ata_generic, I don't get those errors (but I've double-checked with `hdparm -tT /dev/sdX` and write/read speed is really slow compared to pata_ali, I would say it's halved)

Please, I would really appreciate if you could have a look that bug, because I need to understand the source of those errors, and if you confirm it's really related to this bug, it would be one goal for me and for anybody affected by the same bug.

Thank you in advance,
~montblanc

[Montblanc (montblanc)]

(Sorry Igor, I meant Andy!)

[Igor Wojnicki (wojnicki)]

Montblanc,

The changes Andy committed regard modularization of pata_ali - nothing more. As I underestand correctly you use pata_ali right? And if it reports the errors you mention in bug #591532 , than it seems to be pata_ali issues and I believe they have not much to do with making pata_ali a module - the modulatization should not cause them.

As far as I know ata_generic is reported to poorly perform on some hardware, which confirms your performance issues with ata_generic enabled.

I'd gladly investigate these errors of yours - perhaps they'd appear in my system too but unfortunatelly I'm too scared to switch to Lucid right now because of bug #585765 which affects at least one of my systems. Until it is solved I'm not even touching Lucid.

[Montblanc (montblanc)]

Igor,
I thought the only pata_ali changes were made by Andy, that's why I
thought it could be the reason. Seriously I don't know if bug #591532
could be a symptom of bug #585765 because I've just tried the LiveCD
for short sessions. I won't upgrade to Lucid until I know the source
of those errors and discover a workaround, I would really appreciate
if you could have a look into that.
As regards this bug, I'm really happy I can now easily load/unload
pata_ali as a module on Lucid thanks to Andy's efforts, but since I'm
stuck with a disappoining A8R-MVP (which doesn't even let me have a
working 64bit os with hardware memory hole, by the way) with a buggy
chipset, ata_generic is not helping that much...
Thank you and best regards,

Montblanc

2010/6/10 Igor Wojnicki <email address hidden>:
> Montblanc,
>
> The changes Andy committed regard modularization of pata_ali - nothing
> more. As I underestand correctly you use pata_ali right? And if it
> reports the errors you mention in bug #591532 , than it seems to be
> pata_ali issues and I believe they have not much to do with making
> pata_ali a module - the modulatization should not cause them.
>
> As far as I know ata_generic is reported to poorly perform on some
> hardware, which confirms your performance issues with ata_generic
> enabled.
>
> I'd gladly investigate these errors of yours - perhaps they'd appear in
> my system too but unfortunatelly I'm too scared to switch to Lucid right
> now because of bug  #585765 which affects at least one of my systems.
> Until it is solved I'm not even touching Lucid.
>
> --
> [HARDY-LUCID] No DMA nor 32bits IO support
> https://bugs.launchpad.net/bugs/228302
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[pauls (paulatgm)]

weird, I tried to use apport-collect 228302 and it wouldn't let me add to this bug. So, here's my situation.

I'm successfully running hardy on another partition with snappy response and ability to play dvd's.

I have a fresh install of lucid on another partition. I had to go to icewm because gnome, kde, xfce are too slow. I cannot play dvd's without blurry, dropped frames, etc.

So, finding this bug, I tried enabling ata_generic and blacklist pata-ali. With this, I can boot up but it takes several minutes. And, once up, the dvd is not recognized. dmesg shows:

[ 86.097696] scsi scan: 96 byte inquiry failed. Consider BLIST_INQUIRY_36 for this device
[ 86.099133] scsi 1:0:0:0: CD-ROM TOSHIBA DVD-ROM SD-C2502 1313 PQ: 0 ANSI: 5

 a lot of repeats of this:

[ 217.824138] ata2: lost interrupt (Status 0x58)
[ 217.828030] ata2: drained 65536 bytes to clear DRQ.
[ 217.884599] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x
6 frozen
[ 217.884714] sr 1:0:0:0: [sr0] CDB: Inquiry: 12 00 00 00 fe 00
[ 217.885182] ata2.00: cmd a0/01:00:00:fe:00/00:00:00:00:00/a0 tag 0 dma 16640 in
[ 217.885188] res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[ 217.885387] ata2.00: status: { DRDY }
[ 217.885498] ata2: soft resetting link
[ 218.088730] ata2.00: configured for UDMA/33
[ 218.089575] ata2: EH complete

I decided to try the maverick kernel from the kernel ppa, and it does the same thing. In fact, that's what I'm using now.

Any ideas how to fix this?

Since I don't seem to be able to use apport add my stuff, let me know what I need to post.

[Canada Lee (lee-howard)]

Hey Igor, why do you say that my bug is prob a new bug? I am experiencing the same as everyone in this bug... I too am at 16-bit IO, without UltraDMA, and when I try enabling 32-bit IO I get the same ioctl error...

The only diff is people are reporting this bug with hardy-fiesty etc etc, and karmic, and now lucid... I am using Karmic...my hardware may be new...but I'll tell you a secret, I am not using 32-bit IO and I cannot enable it...

And it sounds like I would have to re-write Karmic just to enable 32-bit IO.

Also which I did not mention, I have a laptop as well and its not spanking new, it may be 2002 or 2004...and I am using 16-bit IO without UDMA in this as well. I may not be a rocket scientist, but I have come to the conclusion that Karmic came out in late 2009, and my laptop came out in 2002 maybe 2004...so I would say Karmic should be BETTER than my laptop. But its not...Karmic cannot fully utilize the massive technological power of the hardware that's being developed now in 2002 or 2004...er, uhm, I mean if you took a copy of Karmic and travelled back to 2002 or 2004, then my last statement makes, er, sense.

You know its 2010...and 25 years ago we had 16-bit IO...and you should have seen the pieces of crap that had 16-bit IO.

I predicted new OS after new OS will come out, and we'll still be at 16-bit IO. I am a bit like Nostradamus then!

And I predict that there are thousands out there maybe more, yea prob more... fiesty, hardy, karmic, lucid who are at 16-bit and don't even know it! So then this is our little secret...

The "switch over to Ubuntu" slogan should be changed to..."UBUNTU! - 1982 brought that 8-bit computer, Commodore 64, faster than one of those... UBUNTU! - And remember in 1985 came the 16-bit Commodore Amiga! Now, welcome to 2010... UBUNTU is more processing power than an Amiga yet preserving the same drive IO access speeds!"

There's gotta be 1 unemployed programmer somewhere...we just gotta find him and we'll do a collection and we'll pay him for an hours work just to repair this bug. Unless of course, you've found him already, and thats why this bug has been around for OVER 2 years, because he knows once he's fixed this bug he will have outlived his usefulness!!!

Can we request Ubuntu, that whenever they finally do release a 32-bit version, they stipulate it in the download name, like for example: Ubuntu 10.4 Lucid 32-bit IO.rar...or even change current ones...Ubuntu 10.4 Lucid 16-bit IO.rar and Ubuntu 10.4 Lucid 8-bit IO (if they invented that)!

Hope I made someone out there laugh...have a good one!

[Igor Wojnicki (wojnicki)]

Canada Lee, you're right to some extent. But if switching to ata_generic (instead od pata_ali) does not help you, I think you should just file another bug report.

[Canada Lee (lee-howard)]

Switching to ata_generic instead of pata_ali... Okay, where are these things... I have sata drives. Okay, so if I wanna try this change, how do I go about doing it?

You can omit the first step, because I already know how to open a terminal window! My drives do not show up as /dev/hdX they show up as /dev/sdX, you prob know that, and this could be the symptom of not having and being able to enable 32-bit IO.

I read an earlier reply, might have been yours Igor, where trying this change might screw the pooch and render your ubuntu inopperable and it did for the person posting that reply... What about if pop in a different hard drive (a IDE one) or just create another partition on my existing SATA so that I can install a fresh copy of Karmic, just so I can TEST out changing to the ata_generic...if it works in there, then it should be fine for me to do it to my real installation of karmic right?

Also, right after your reply to me, I see you posted some kind of...
Changed in linux (Ubuntu):
status: Confirmed → Fix Released

Where, where's this fix...how do I find it?

So do I follow those instructions in that earlier reply where the dude screwed the pooch? And see if it works in a new install, and if so, perform those steps to my real existing karmic?

Is these any program, like a patch file than can just test...or switch things...then if it dont work, it could switch back?

Cheers!

[Canada Lee (lee-howard)]

I followed the instructions in post #85, made backups of the 2 files before I modified them for easy reversal if needed... Here's what I did...

1. Add "blacklist pata_ali" to /etc/modprobe.d/blacklist
2. Run "sudo update-initramfs -u"
3. Add "ata_generic.all_generic_ide=1" to the GRUB_CMDLINE_LINUX line in /etc/default/grub
4. Run "sudo update-grub"
5. Reboot (preferably using the recovery option so that you can see the verbose boot information).

I booted into recovery mode...then when a MS-DOS style windows with ANSI came up, I selected the first option, to continue booting normally.

I did not notice any errors...but then again, I couldnt scroll the display to backtrace...but everything seemed fine...albeit with no GUI...so I shutdown and restarted this time NOT using recovery mode...and I am in Ubuntu Karmic now...everything appears to be the same, unchanged, no difference...

First thing I did is to see if my drives are /dev/sdX or /dev/hdX, and they are still /dev/sdX...so did a

Canada_Lee@HOME:~$ sudo hdparm /dev/hda
/dev/hda: No such file or directory
Canada_Lee@HOME:~$ sudo hdparm /dev/sda

/dev/sda:
 multcount = 16 (on)
 IO_support = 0 (default)
 readonly = 0 (off)
 readahead = 256 (on)
 geometry = 48641/255/63, sectors = 781422768, start = 0
lee@HOME:~$ sudo hdparm -c1 /dev/sda

/dev/sda:
 setting 32-bit IO_support flag to 1
 HDIO_SET_32BIT failed: Invalid argument
 IO_support = 0 (default)

So, is there anything I need to do to make my system change the drives from /dev/sdX to /dev/hdX?

Also, right this second, which is being used right this second? ata_generic or pata_ali? How can I verify which is in use right now?

Also, if any updates happen, with they wipe out this change I am trying to make? And will I have to do this change everytime a certain thing gets updated?

I dont know if this matters, but I am using Prelink and Preload.

Anyone have any suggestions?

Laters.

[Igor Wojnicki (wojnicki)]

> First thing I did is to see if my drives are /dev/sdX or /dev/hdX, and
> they are still /dev/sdX...so did a

What's wrong with having drives named as /dev/sdX ?
Historically SCSI drives were named /dev/sdX, while IDE /dev/hdX.
Since some time ago any hard drive is named /dev/sdX regardless
whether its IDE/ATA, IDE/SATA or SCSI, there is one uniform interface.

> lee@HOME:~$ sudo hdparm -c1 /dev/sda
>
> /dev/sda:
>  setting 32-bit IO_support flag to 1
>  HDIO_SET_32BIT failed: Invalid argument
>  IO_support    =  0 (default)
>
>

Mind that hdparm is a tool which was tailored towards IDE drives only.
It is compatible with old interface (/dev/hdX) but only partially with
the new one (/dev/sdX).

> So, is there anything I need to do to make my system change the drives from /dev/sdX to /dev/hdX?

There is no point in doing that.

> Also, right this second, which is being used right this second?
> ata_generic or pata_ali?  How can I verify which is in use right now?

dmesg will give you all the information you need. It displays kernel
messages (additionally they go to /var/log directory). So you can open
a terminal and try:

dmesg | less

to browse through all the messages. If you want to find out what mode
the hard drive is switched to search (to search press /) for lines
starting with:

ata1 (for the 1st controller) or ata2 (second). In my case I have

[ 0.517229] ata1.00: ATA-7: Maxtor 6L200P0, BAH41G10, max UDMA/133

... a few more lines here

[ 0.572323] ata1.01: ATA-6: WDC WD1200JB-00GVA0, 08.02D08, max UDMA/100

... a few more lines here

[ 0.572362] ata1.00: configured for UDMA/133
[ 0.572365] ata1.01: configured for UDMA/100

Which says what respective DMA modes are enabled for my hard drives.

> Also, if any updates happen, with they wipe out this change I am trying
> to make?  And will I have to do this change everytime a certain thing
> gets updated?

The change you made is permanent, regardless of the updates.

>
> I dont know if this matters, but I am using Prelink and Preload.
>

No It doesn't. However, Preload does not do much from my experience
but it might depend on how much memory you have and how fast the
disk(s) is(are).

[Sing-Tai Mok (stmok)]

I encountered this issue with Ubuntu 10.04 and ASRock K8SLI-eSATA2 motherboard.
=> http://www.asrock.com/mb/overview.asp?Model=K8SLI-eSATA2

The Kernel I'm using is => 2.6.32-27-generic-pae #49-Ubuntu SMP

I tried post #85's instructions, but it causes more problems than it solves...

The DVD burner is connected to PATA connector (Primary - Master). HDD is SATA

[ 0.368462] ata1.00: ATAPI: PIONEER DVD-RW DVR-108, 1.20, max UDMA/66
[ 0.368488] ata1.00: configured for UDMA/66

An issue appears the first time...

[ 6.239211] ata1.00: qc timeout (cmd 0xa0)
[ 6.243553] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 6.243556] ata1.00: BMDMA stat 0x25
[ 6.243561] sr 0:0:0:0: [sr0] CDB: Inquiry: 12 01 00 00 fe 00
[ 6.243573] ata1.00: cmd a0/01:00:00:fe:00/00:00:00:00:00/a0 tag 0 dma 16640 in
[ 6.243574] res 51/50:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
[ 6.243577] ata1.00: status: { DRDY ERR }
[ 6.243588] ata1: soft resetting link
[ 6.659718] ata1.00: configured for UDMA/66
[ 8.979746] ata1: EH complete

And it happens again...

[ 45.520036] ata1.00: qc timeout (cmd 0xa0)
[ 45.520049] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 45.520318] ata1.00: BMDMA stat 0x25
[ 45.520496] sr 0:0:0:0: [sr0] CDB: Inquiry: 12 01 00 00 fe 00
[ 45.520507] ata1.00: cmd a0/01:00:00:fe:00/00:00:00:00:00/a0 tag 0 dma 16640 in
[ 45.520509] res 51/50:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
[ 45.521049] ata1.00: status: { DRDY ERR }
[ 45.521239] ata1: soft resetting link
[ 45.684319] ata1.00: configured for UDMA/66
[ 45.684642] ata1: EH complete

* The system obviously up slower.
* Burning DVDs uses 80% CPU load instead of 95%.
* Burning speed is slower. (From 2.20x down to 1.90x; according to K3b)

...And the whole system feels notably sluggish. Maybe I'll switch to a USB DVD burner as a work-around.

[Sing-Tai Mok (stmok)]

LOL. Never mind! Workaround (for my case) is found on Bug #292142

(1) Create new file => sudo nano /etc/modprobe.d/options
(2) Add this => options pata_ali atapi_dma=1
(3) Edit this => sudo nano /etc/initramfs-tools/modules
(4) Add this => pata_ali atapi_dma=1
(5) Run this => sudo update-initramfs -u
(6) Reboot system.

* System is fast again!
* Burning DVDs never uses more than 28% CPU load.
* Burning speed is now 3.90x (Media is limited to 4.0x)

The above is applicable to Ubuntu 10.04.x LTS.

[wayward4now (wayward4now)]

Sing-Tai Mok,
I just tried that with no joy.
wayward4now@iam:~$ sudo hdparm /dev/sr0
[sudo] password for wayward4now:

/dev/sr0:
 multcount = 0 (off)
 IO_support = 1 (32-bit)
 readonly = 0 (off)
 readahead = 256 (on)
 HDIO_GETGEO failed: Inappropriate ioctl for device
wayward4now@iam:~$

...but it seems I am getting 32bit support. Is this as good as it gets? Ric

[wayward4now (wayward4now)]

Sorry! My DVD audio is no longer choppy!!! Oh happy days and thanks! Ric

[Montblanc (montblanc)]

Does this tweak still apply to Natty? I noticed some pata_ali messages in the .38 linux branch, though I haven't had time to test it thoroughly.

[Miles Sharpe (msdomdonner)]

Hi guys, I am getting this problem in Maverick as well but find the workaround of making /sda to /hda and all that goes with it beyond my capabilities. Has a fix been found yet please?

miles@P4:~$ sudo hdparm -d1 /dev/sda

/dev/sda:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Inappropriate ioctl for device
 HDIO_GET_DMA failed: Inappropriate ioctl for device

Thanks
Miles