cdrecord: Cannot allocate memory. Cannot get SCSI I/O buffer.

cdrecord 2.01.01_alpha04 without any patches is working fine as root.

As user cdrecord dev=ATA:1,0,0 blank=fast results in:
cdrecord: Cannot allocate memory. Cannot get SCSI I/O buffer

The user is in group burning, the rights are set as with 2.01.01_alpha01, where user burning was possible. kernel is 2.6.14-nitro2.

-------------------------------------------
protect your privacy - encrypt your mails
my key is: 0x2AA933B6

Consider using "sudo".

There are issues with some combinations of kernel and cdrecord versions. setuid doesn't work, but sudo would (as would root access) -- and that's the symptom.

Matthias Andree

and when I want to use k3b? Should I sudo k3b? This could possibly result in a big security problem.

-------------------------------------------
protect your privacy - encrypt your mails
my key is: 0x2AA933B6

No, you could write a wrapper script that looks like

#! /bin/sh
exec /usr/bin/sudo /path/to/cdrecord "$@"

and point k3b to use that.

If it's a single-user desktop machine, /removing/ the setuid bit from cdrecord might actually work, but runs counter to Jörg's recommendations. No memory locking, no real-time priority will work, so it stands a much higher chance of buffer underruns which are detrimental to writing quality even in the light of burnproof, justlink and similar. So in this case, the user needs to make absolutely sure the box is absolutely idle. Better shut off the network so no messages come in and run through the spam filter, don't browse, and at nighttime, shut down cron, too.

I recall someone offering cdrecord patches to overcome part of this problem, to the extent of it dropping its permissions too early, apparently they haven't made 2.01.01a04 yet, if they are correct at all.

Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

This patch is working with alpha04 on my mashine:
http://de.geocities.com/linux_piewie/download/alpha04.txt

So any particular reason you think this is a kernel bug??

Jens Axboe

Perhaps because <http://de.geocities.com/linux_piewie/download/Readme.txt>

contains this text:

"3. solution for the root problem, not existent for kernel >= 2.6.14-rc2"

OTOH, if 2.6.14 and 2.6.15 are fixed, why would a kernel developer take interest? 2.6.X isn't "stable" after all... as fiercely discussed on linux-kernel@ a few weeks ago.

Matthias Andree

Dunno if that is what you meant, but it states that >= 2.6.14-rc2 fixes the root problem - your line states that a solution for kernel >= 2.6.14-rc2 is non-existant.

Well there's nothing to fix if it works in newer kernels, is there? I can't travel back in time and make sure that eg 2.6.10 works.

Jens Axboe

Jens Axboe schrieb am 2006-01-13:

Usually the reference would "root problem": problem fixed as of 2.6.14-rc2.

I don't know if that's what the original author meant, but chances are the problem was fixed in the kernel after being introduced between 2.6.7 and 2.6.10 somewhen. May have been 2.6.8[.1], but don't anyone quote me on that figure.

Let's not open this can of "stable kernel" worms here in -scsi@.

Matthias Andree

I deliberately ignored that bait, yet you continue. Bugs get introduced and bugs get fixed. If you have some agenda on the "stable kernel", please take it to the pub or some place else where we don't have to listen to it. It's surely just about the worst way to try and get an issue resolved.

You are free to use whatever you want, you know.

Jens Axboe

This relies only on q-check functions, like in qpxtool or readcd -cxscan