Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

Bill Davidsen
2004-08-12T22:12:00Z

Con Kolivas wrote:
> Albert Cahalan writes:
>
>
>> Joerg:
>> "WARNING: Cannot do mlockall(2).\n"
>> "WARNING: This causes a high risk for buffer underruns.\n"
>> Fixed:
>> "Warning: You don't have permission to lock memory.\n"
>> " If the computer is not idle, the CD may be ruined.\n"
>>
>> Joerg:
>> "WARNING: Cannot set priority class parameters
>> priocntl(PC_SETPARMS)\n"
>> "WARNING: This causes a high risk for buffer underruns.\n"
>> Fixed:
>> "Warning: You don't have permission to hog the CPU.\n"
>> " If the computer is not idle, the CD may be ruined.\n"
>
>
> Huh? That can't be right. Every cd burner this side of the 21st century
> has buffer underrun protection. I've burnt cds _while_ capturing and
> encoding video using truckloads of cpu and I/O without superuser
> privileges, had all the cdrecord warnings and didn't have a buffer
> underrun. Last time I gave superuser privilege to cdrecord it locked my
> machine - clearly it wasn't rt_task safe.

This may be a side effect of your scheduler, then. Cdrecord is run as or
by root on a lot of systems and I've never had any indication that ever
does anything which hurts response, other than to lock down a small
memory section for fifo.

--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me