Ubuntu

Automatically enable DMA on CD-ROMs where it is known to work

Reported by Edd Dumbill on 2004-11-12
164
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux-source-2.6.15 (Ubuntu)
Wishlist
Ben Collins

Bug Description

I don't know if this is a general problem or just specific to this laptop, but
CD/DVD DMA was not enabled by default on my laptop (piix driver). I had to
customise /etc/hdparm.conf to switch it on. DMA was OK for my hard drive, however.

Ruben Vermeersch (ruben) wrote :

I'm having the same problem on my Dell Inspiron 8600, the hard disk (hda) get's
DMA by default, the DVD+RW (hdc) doesn't.

Matt Zimmerman (mdz) wrote :

This is intentional. Too many CD-ROM devices fail to work correctly when DMA is
enabled, and this prevented many users from being able to even install Ubuntu,
so it is disabled by default. We will need the support of the proposed hardware
database (http://www.ubuntulinux.org/wiki/HardwareDatabase) in order to enable
it automatically.

In my case, a PC with Asus A7N8X Deluxe with nForce2 chipset, I couldn't force
DMA using hdparm for IDE devices. This is because ide-* modules was loaded
before the specific amd74xx module. When I added this module to /etc/modules at
the beginning of the file, then I could activate DMA. It would be great if this
kind of IDE modules was detected and added automatically.

Matt Zimmerman (mdz) wrote :

*** Bug 14085 has been marked as a duplicate of this bug. ***

Matt Zimmerman (mdz) wrote :

*** Bug 14351 has been marked as a duplicate of this bug. ***

Sebastien Bacher (seb128) wrote :

*** Bug 14492 has been marked as a duplicate of this bug. ***

reh4c (gene-hoffler) wrote :

Here's how I successfully got dma to work on my DVD+/-RW drive (Gateway 7405GX laptop):
Use nano to edit /etc/hdparm.conf.
Uncomment the line about hda and dma being on.
Change hda to hdc to enable dma on the Gateway 7405GX dvd burner drive.
DVD Playback is now smoother without having to use the command line each time before playing DVDs.
I make the following proposal, which is especially helpful for newbies (like me) and advanced users:
Add a GUI check box option for enabling dma under removable drives and media within preferences.
Eliminate the term "removable" and include hard drive settings in this section as well. This change
would help keep new users from having to directly edit configuration files and provide easy access to
settings for all drives. Thanks.

Corey Burger (corey.burger) wrote :

*** Bug 16816 has been marked as a duplicate of this bug. ***

Matt Zimmerman (mdz) wrote :

*** Bug 18001 has been marked as a duplicate of this bug. ***

Matt Zimmerman (mdz) wrote :

*** Bug 17803 has been marked as a duplicate of this bug. ***

Corey Burger (corey.burger) wrote :

*** Bug 18407 has been marked as a duplicate of this bug. ***

*** Bug 13244 has been marked as a duplicate of this bug. ***

Martin Pitt (pitti) wrote :

*** Bug 16170 has been marked as a duplicate of this bug. ***

Richard Kleeman (kleeman) wrote :

Will dma be enabled by default on suitable cdrom drives in breezy? I am active
on the ubuntu fora and
enabling this comes up repeatedly with the comment by newbies that the fix is
too hard for windows switchers.
Playing dvds without jerkiness seems to be in high demand by ubuntu users......

Matthew East (mdke) wrote :

(In reply to comment #14)

> Will dma be enabled by default on suitable cdrom drives in breezy? I am active
> on the ubuntu fora and
> enabling this comes up repeatedly with the comment by newbies that the fix is
> too hard for windows switchers.
> Playing dvds without jerkiness seems to be in high demand by ubuntu users......

Yeah for the reasons given above, IMO this bug deserves a higher severity.

reh4c (gene-hoffler) wrote :

I agree with comments about this "bug" or drive enhancement needing to be a higher priority. Even if
DMA can't be enabled by default due to installation issues, can a check box option to enable DMA be
placed under "System"..."Preferences"..."Removable Drives and Media"? At that point, maybe a script
could be executed to get it going??? Sorry that I'm not a programmer.

Simon Howard (fraggle-alkali) wrote :

To make it clear on the importance of this bug: this makes DVDs unwatchable on
almost every machine I've installed Ubuntu on.

Matt Zimmerman (mdz) wrote :

*** Bug 20816 has been marked as a duplicate of this bug. ***

Matt Zimmerman (mdz) wrote :

*** Bug 20949 has been marked as a duplicate of this bug. ***

Matt Zimmerman (mdz) wrote :

(this is post-breezy stuff, naturally)

Ben, we need to find out which bits of hardware are important in this equation
so that we know whether a given device will work or not. It's not only the
drive, is it? Combination of drive and controller?

Ben Collins (ben-collins) wrote :

I believe some controllers are known to have buggy DMA, but those are mostly
already handled by the IDE driver.

For CDROM's maybe we can have a minimum criteria to start with for allowing a
drive to have DMA enabled by default. Something like:

1) Is it DVD capable? Most of the complaints about DMA by default revolve around
playback of DVD video. If the drive is not capable of reading DVD's, then DMA is
not as important (by default).

2) Since there's no universal way of detecting "newer" DVD drives, possibly we
can just check for something like supporting a minimum drive speed (say 24x
CDROM speed), maybe enable DMA on all DVD recorders.

3) If we can get the above criteria to give us like 99% reliability that it is
only enabled by default on hardware that works, then we can start a black/white
list of vendor/model/firmware for the few cases left.

The alternative is to disable DMA always during installation and let the kernel
do its normal thing when booting into the system (in fact, I think we should
always disable DMA during installation for reliable CD installs). This wouldn't
work for live-cd of course.

Matt Zimmerman (mdz) wrote :

(In reply to comment #17)
> To make it clear on the importance of this bug: this makes DVDs unwatchable on
> almost every machine I've installed Ubuntu on.

Yes, this is unfortunate, but to be clear:

Enabling DMA by default on CD-ROMs makes it impossible for many users to even
INSTALL Ubuntu, which is much worse.

DVDs can't be played on Ubuntu out of the box anyway, unfortunately, for
non-technical reasons.

Simon Howard (fraggle-alkali) wrote :

(In reply to comment #22)
> Yes, this is unfortunate, but to be clear:
>
> Enabling DMA by default on CD-ROMs makes it impossible for many users to even
> INSTALL Ubuntu, which is much worse.
>
> DVDs can't be played on Ubuntu out of the box anyway, unfortunately, for
> non-technical reasons.

Ok, I appreciate that.

Obviously, this needs some serious thought put into it to develop a proper
solution as there are thousands of different types of CDROM out there. For the
time being, it would be nice if the new Ubuntu release set DMA on some of the
most popular types of CDROM drive out there. You have the Ubuntu hardware
database now, what are the top ten CDROM drives out there?

For reference, my CDROM is a "TOSHIBA CD/DVDW SD-R5372" and DMA works on there.
 My work machine is a "HL-DT-ST RW/DVD GCC-4481B" and DMA works on there as well.

Simon Howard (fraggle-alkali) wrote :

(In reply to comment #22)
> DVDs can't be played on Ubuntu out of the box anyway, unfortunately, for
> non-technical reasons.

And just to be clear, DVD playback isn't the only issue. The system becomes
slow and unresponsive when reading from disks if DMA is disabled.

Is it at all possible to make sweeping generalisations that would help this
issue? For example, "all drives faster than 48x are new and all new drives
support DMA"? Or, "all DVD-R drives must support DMA"?

Also, how do other distributions deal with this issue?

Matt Zimmerman (mdz) wrote :

(In reply to comment #23)
> Obviously, this needs some serious thought put into it to develop a proper
> solution as there are thousands of different types of CDROM out there. For the
> time being, it would be nice if the new Ubuntu release set DMA on some of the
> most popular types of CDROM drive out there. You have the Ubuntu hardware
> database now, what are the top ten CDROM drives out there?
>
> For reference, my CDROM is a "TOSHIBA CD/DVDW SD-R5372" and DMA works on there.
> My work machine is a "HL-DT-ST RW/DVD GCC-4481B" and DMA works on there as well.

It isn't at all clear that it is safe to enable DMA on a drive simply because it
is popular. In fact, as mentioned earlier in this bug, it isn't clear that the
drive is the only variable. In the past, we've seen different behaviour with
the same drive in two different systems.

We don't have enough information to make an educated guess yet, and given that
the consequence of disabling it by default is that CD-ROM access is slow, while
enabling it in some configurations results in the system locking up, we have
little choice but to choose the safe route for now.

Matt Zimmerman (mdz) wrote :

(In reply to comment #24)
> Is it at all possible to make sweeping generalisations that would help this
> issue? For example, "all drives faster than 48x are new and all new drives
> support DMA"? Or, "all DVD-R drives must support DMA"?

It is possible, but we have no way to know if it is correct.

> Also, how do other distributions deal with this issue?

An excellent question, and one that would be very beneficial to research. If
anyone following this bug is interested in helping to get it fixed, this would
be a good starting point.

I know that some distributions simply enable it by default, which might be
acceptable for their audience, but not for Ubuntu.

If anyone can find out about prior efforts in this area in other projects in
order to provide us with a starting point, we could perhaps get started on
implementing a solution as early as the developer summit in November.

Stéphane Marguet (stemp) wrote :

(In reply to comment #18)
> *** Bug 20816 has been marked as a duplicate of this bug. ***

I'm sorry but this bug is NOT concerning enabling dma by default.
It's a probleme between using hdparm.conf and the command hdparm !!

Matt Zimmerman (mdz) wrote :

(In reply to comment #27)
> (In reply to comment #18)
> > *** Bug 20816 has been marked as a duplicate of this bug. ***
>
> I'm sorry but this bug is NOT concerning enabling dma by default.
> It's a probleme between using hdparm.conf and the command hdparm !!

There isn't much that we can do if the hardware doesn't support DMA properly;
the best we can do is try to enable it where it works

Stéphane Marguet (stemp) wrote :

(In reply to comment #28)
> (In reply to comment #27)
> > (In reply to comment #18)
> > > *** Bug 20816 has been marked as a duplicate of this bug. ***
> >
> > I'm sorry but this bug is NOT concerning enabling dma by default.
> > It's a probleme between using hdparm.conf and the command hdparm !!
>
> There isn't much that we can do if the hardware doesn't support DMA properly;
> the best we can do is try to enable it where it works

I think I wasn't clear enough (probably my bad english) :
when I'm changing the file /etc/hdparm.conf to automaticaly enable the dma on my
/dev/hdc & /dev/hdd dvd drives, my /dev/hdd is freezing and not responding to
any command.
but when I'm using the command sudo hdparm to enable them , there is no problems
and the drives are working fine

Gavin McCullagh (gmccullagh) wrote :

(In reply to comment #26)

> I know that some distributions simply enable it by default, which might be
> acceptable for their audience, but not for Ubuntu.

Would it be acceptable to have two installation targets say "default" and
"failsafe". So, by default DMA would be switched on (both during and after the
install) but if that failed you could install using "failsafe" which would
disable DMA (not to mention APIC, LAPIC and any others that cause issues) during
and after install. If it were clearly documented I would say most users would
be happy enough with this. If extra stuff could be added to the default where
it sensed a known bad dvdrom/controller and dropped back that would be better
again so as to expose as few people as possible to any kind of failure.

> If anyone can find out about prior efforts in this area in other projects in
> order to provide us with a starting point, we could perhaps get started on
> implementing a solution as early as the developer summit in November.

One thing that seems fairly apparent is that if those distros get away with this
then relatively few installations fail despite DMA being enabled. Ubuntu
understandably doesn't want to lock that hardware out. It seems that few would
need the "failsafe" option but it's important that it's there.

Matt Zimmerman (mdz) wrote :

(In reply to comment #30)
> (In reply to comment #26)
>
> > I know that some distributions simply enable it by default, which might be
> > acceptable for their audience, but not for Ubuntu.
>
> Would it be acceptable to have two installation targets say "default" and
> "failsafe". So, by default DMA would be switched on (both during and after the
> install) but if that failed you could install using "failsafe" which would
> disable DMA (not to mention APIC, LAPIC and any others that cause issues) during
> and after install. If it were clearly documented I would say most users would
> be happy enough with this.

This is essentially the approach used by Knoppix for CD DMA ("turn it on unless
the user tells us otherwise"). This causes the boot to fail on systems where
DMA doesn't work properly, requiring the user to a) be persistent and try to
continue installing, despite a catastrophic failure, b) find the appropriate
documentation, and c) interact with the unfriendly isolinux command line. This
seems like more than enough to stop a first-time user in their tracks.

Also, I don't think it would be best to mix this with other hardware-related
parameters; disabling other features like APIC support can cause a new failure
which didn't happen when it was enabled.

I much prefer that we get this right, and enable DMA only where it is known to work.

> If extra stuff could be added to the default where
> it sensed a known bad dvdrom/controller and dropped back that would be better
> again so as to expose as few people as possible to any kind of failure.

See earlier comments; we don't yet know what to look for.

> One thing that seems fairly apparent is that if those distros get away with this
> then relatively few installations fail despite DMA being enabled. Ubuntu
> understandably doesn't want to lock that hardware out. It seems that few would
> need the "failsafe" option but it's important that it's there.

Ubuntu has tried this once already (Warty inadvertently shipped with DMA enabled
on CD-ROMs), and the number of failed installations was significant.

Martin Pitt (pitti) wrote :

*** Bug 14907 has been marked as a duplicate of this bug. ***

Matt Zimmerman (mdz) wrote :

*** Bug 22464 has been marked as a duplicate of this bug. ***

Martijn vdS (martijn) wrote :

For the record, turning off DMA also breaks high-speed CD writing on my systems.
So maybe all writers are safe(?)

Matt Zimmerman (mdz) wrote :

This will be a priority item for the 6.04 release. As one of the very first
changes to the Dapper kernel, we should disable CONFIG_IDEDMA_ONLYDISK and
solicit widespread testing to see how the situation has changed since we first
set this option. Depending on the results, we should pursue either a whitelist
or blacklist approach to allow DMA to be used in configurations where it works.

Ben, please make sure this gets done.

Matt Zimmerman (mdz) wrote :

*** Bug 24504 has been marked as a duplicate of this bug. ***

Ben Collins (ben-collins) wrote :

Option is now enabled in the git repo for the dapper kernel. Once that gets into
the archive, I'll update this bug report as needinfo. Anyone testing who feels
that dma is breaking their cdrom should send the output of "hdparm -I /dev/hdX"

Matt Zimmerman (mdz) wrote :

This is now done in the 2.6.15 kernel available in dapper

Ben Collins (ben-collins) wrote :

This bug was pending on an upload which is complete now. Closing.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.