Problems with cdrecord + ATAPI + D. Ok, what've I missed?

meglamaniac · n00b Joined: 18 Nov 2004 Posts: 14

I've been testing my ATAPI support and I've getting some odd errors (see below), including warnings that DMA isn't enabled.
Is DMA an option I should have set when building the kernel? I've been hunting about for info on it but I'm drawing a blank. The BIOS reports both cd drives as being in UDMA mode 2.
As this machine isn't the fastest (PIII 550) I could really do without it routing cd burning through the processor when I know it does support DMA.
If someone can point out to me which bit of setup I forgot, then I'd be grateful.

Thanks!
[edit]
I've done:

noergeli · Posted: Mon Nov 22, 2004 4:55 pm Post subject:

meglamaniac · n00b Joined: 18 Nov 2004 Posts: 14

Thanks.
I will continue to do some tests, and watch the processor usage while I do so in order to see if it is actually using PIO or DMA.

Doogman · Apprentice Joined: 24 Sep 2004 Posts: 244

Actually, this is a problem I would really like to see resolved. It's one of the few annoying quirks left using my burner with 2.6.x kernels.

To make a long story short, this is what I've found:

Kernel: 2.6.9-ck3 (happens with all 2.6.x kernels though)
Burner: DMA enabled
Interface: IDE interface ala ATAPI 0:0:0

growisofs (DVD program): Works fine!
cdrdao: Works fine!
cdrecord: Doesn't work at all with DMA enabled. I get this error:

Warning: There is absolutely NO DMA, operations thus are slow.

But, in fact, DMA is activated. If I disable DMA on the burner, cdrecord will work fine again but with all the problems associated without using DMA (system hog).

While I can using my burner fine with just growisofs and cdrdao from the command line, quite a few of the GUI burner programs require cdrecord to function correctly. I would like to get cdrecord to working again with DMA.

So, is anyone using cdrecord successfully with a 2.6.x kernel and a IDE burner with DMA enabled? If you are, what are you doing differently than the rest of us?

meglamaniac · n00b Joined: 18 Nov 2004 Posts: 14

I guess it's a case of waiting for whoever maintains cdrecord to update it.
Hopefully it'll be done sometime shortly after 2.6.10 is out, because from what I've been able to gather 2.6.10 should fix the "unresolved issues" that cdrecord warns about (ie. access to the SCSI commands from users other than root).

Doogman · Apprentice Joined: 24 Sep 2004 Posts: 244

Yeah, but my problem has absolutely nothing to do with SCSI commands, notice I said it works fine with DMA disabled. I've had this problem before the kernel crew decided to "censor" the commands sent to the burner, besides the ck patchset removes all this silliness anyway. It has something to do with DMA and cdrecord.

Is anyone else using successfully using cdrecord with DMA enabled?

noergeli · Posted: Wed Nov 24, 2004 12:27 pm Post subject:

Here's what i got

kernel: 2.6.8.1-ck9
cdrecord: 2.1
cdr-drives are set to udma2

I didn't try to burn from command-line yet, cause I'm using k3b as frontend to cdrecord. Well cdrecord -scanbus is also giving me this warning about DMA, but burning with k3b using cdrecord works really fine.

Doogman · Apprentice Joined: 24 Sep 2004 Posts: 244

Thanks for the help, noergeli. I think I have things working fine now.

Apparently the answer was to switch from devfs to udev. It seems that problem with cdrecord wasn't related to DMA, but an odd interaction with device names and devfs in particular. My box is unusual in that it has 3 seperate IDE controllers (6 IDE masters). perhaps that was the cause of the problem with cdrecord?

Anyway, after migrating to udev and fixing a few problems along the way, all my burning apps (including cdrecord) now work fine again with DMA activated. I'm not entirely sure if udev or the minor bit of system tweaking I did afterwards was the fix, but I'm not going to look a gift horse in the mouth.

But you are right, cdrecord still complains about "no DMA", but works fine anyway with DMA activated so perhaps this is just a bogus error.