Tony Nelson wrote: > At 4:28 PM -0400 7/28/07, Gene Heskett wrote: > ... >>> cdrecord: Cannot allocate memory. WARNING: Cannot do mlockall(2). >>> cdrecord: WARNING: This causes a high risk for buffer underruns. >>> cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler >>> cdrecord: Permission denied. WARNING: Cannot set priority using >>> setpriority(). cdrecord: WARNING: This causes a high risk for buffer >>> underruns. > ... >>> cdrecord: Cannot load media with this drive! >>> cdrecord: Try to load media by hand. >>> cdrecord: Cannot load media. > ... >> Known problem. Unknown is why the hell it persists, release after release >> when the fix is so simple. The memory per process limit imposed is to fix a >> runaway process so it can't take the machine clear down. That's very rare, >> and you will normally get a pretty good trace pointing fingers at the guilty >> item so IT can be reported and hopefully fixed ASAP. Unforch, the default >> buffer size k3b asks for exceeds this limit by about 50 times. While >> burning, it uses a considerable amount of memory for the write cache. >> >> The fix? Put this line in at the bottom of the file in your ~/.bashrc >> >> ulimit -l unlimited >> >> End of problem. > > That should take care of the /warning/ about mlockall(2), but it won't help > with the /error/ "Cannot load media". WAG: I wonder if starting with the > tray open would help? I didn't for me. I think the problem may be that two applications are competing for access? I have not had time to dig into it, but I know if you drag files/folders to the blank media icon, you then get the option to burn them on my laptop where k3b does not work... Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
