I was experimenting, and these are the results I got. I might help out some other people. If you have a kernel with no patches, and cdrtools not patched also. Now apply dsd's kernel message patch. The patch is mentioned in the first post with a link to it. Run cdrecord like this.

Code:

cdrecord dev=/dev/hd* -dao -data #yourfavoriteiso

If it errors out, and complains that it can't init the drive then run:

Code:

dmesg

Look at it, and if there are only

Code:

verify_command: rejected command #what ever command it is

Now there should be a

Code:

scsi: unknown opcode

before the rejected command. If you are missing the scsi: unknown opcode then the command filter isn't working, and the kernel isn't recognizing the command to the burner as a SAFE_WRITE command. Now here is the fix that will let you burn CD's and DVD's again. Here is the kernel code in linux/drivers/block/scsi_ioctl.c before it is patched:

Code:

/* Anybody who can open the device can do a read-safe command */
if (type & CMD_READ_SAFE)
return 0;

please dont do that. that allows every single command to be written to the drive, including the ones which kill hard disks or corrupt drive firmwares. theres a reason why this filter was put in place..._________________http://dev.gentoo.org/~dsd

it doesn't let every command fly for me. Unless it is in the list of allowed commands it get's blocked. The only commands allowed are the commands that have safe_for_write(SOMETHING) still.

I only put that in, because all of the commands that cdrecord was sending weren't being interpreted as safe_for_write commands. NONE. So if cdrecord send a command as 0x55 it got blocked, but it didn't bring back a warning. Every command should be coming back with at least a warning if it is blocked._________________ Hindi ko naintindihan, pakiulit.

Now I went over the code too, but it wasn't working before. I used gnome's nautilus cdburner utility, and it is smart enough not to make the same mistake of dev=ATAPI:0,0,0 and it wasn't working either back a couple of posts. I think I know what the problem is. GCC made a mistake or my computer is just stupid at compiling.

Conclusion:
If you have an MMC compliant drive it should burn using the following command line arguments for cdrecord.

Code:

cdrecord dev=/dev/hdc *.iso

If it doesn't work, or the nautilus cd burner utility doesn't work then you to have a dumb computer that won't compile the code correctly. Maybe it is a gcc error. I don't know. Compile the kernel again could be the work around. My GCC is Version 3.3.4. So there you have it._________________ Hindi ko naintindihan, pakiulit.

MaxDamage: you have to make sure that gtoaster uses device /dev/hdc (for example) as opposed to ATAPI:0,0,0

The problem is Gtoaster needs both the device name (set /dev/hdc) and the SCSI Id (ATAPI:0).

** EDIT **

No problem: I put /dev/hdc in both fields, and now everything works.
Wow, now old programs that were designed for SCSI burning and didn't allow use of "ATAPI:", are going to work again._________________La PDA de tungsteno

*EDIT*
Also, changing cdrecord to not use SUID is all very well but by not using SUID, cdrecord is no longer able to set its priority to RT therefore reducing the possibility of buffer underruns, is this now a likely occurance on slower machines?

Another point, I was under the impression that even though cdrecord has SUID bit set the code itself actually changed its EUID back to a lesser privilaged user after setting the runtime priority???

Also, changing cdrecord to not use SUID is all very well but by not using SUID, cdrecord is no longer able to set its priority to RT therefore reducing the possibility of buffer underruns, is this now a likely occurance on slower machines?

I've also always seen that error about the scheduling. Is there a way to fix it when burning as normal user?_________________La PDA de tungsteno

Should I just be ignoring the errors warning of buffer underrun risks? IIRC this is why cdrecord ran as setuid root before but now it seems this isn't kosher anymore. I turned off setuid to get cdrecord to work again but now I get these warnings._________________"The song I've written for you is so schmultzy it'll make 'Moon River' sound like a farting orangutan." - Homer Simpson

cdrecord not running as root is a cdrecord bug. i can't remember exactly what it is doing wrong, but hopefully this will be fixed soon. on most systems, the extra priority it can get shouldnt really make a lot of difference

you can change a tasks priority while it is running. so you could start a burn as user, then use 'renice' (as root) to set that process to a high priority. i have not tried this , just an idea ..

as mentioned elsewhere in this thread, plextor writers are basically standard cd drives with a few extra commands that are outside of the standard specifications. the kernel currently disallows these extra commands, and i get the picture that this doesnt allow plextor writers to work properly.

i will write a patch to allow the extra commands - i doubt it will be accepted upstream, but at least you plextor customers will be able to burn cd's without having to bypass the command filter entirely.

finally, i believe that a better solution is on its way which will hopefully be included in 2.6.11 - the command filter will be controlled in userspace and should allow for odd situations such as plextor burning._________________http://dev.gentoo.org/~dsd

I'm joining this thread because I can't burn successfully using kernel 2.6.9-r9 (also r4 and r cause me grief. I have tried to follow the advice in this thread and can now burn an image using

Code:

cdrecord dev=/dev/hdc -dao -data my.iso

I am not so lucky while using xcdroast and k3b.

Xcdroast will only let me burn as root which if I understand causes problems with a bug in cdrecord. K3b seems to allow me to burn an iso and doesn't give any errors but then fails in the verification stage.

When I try and calulate an md5sum through the command line using

Quote:

md5sum /dev/hdc

The program seems to run fine until it gets near the end of the disk and then fails with a device error.

Like I said, this only happens after the first burn which works just as it should--so it looks like there is still some kind of permission issue happening somewhere as it works perfectly in root. I only get this error in my user account.