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

From: Con Kolivas
Date: Mon Aug 09 2004 - 23:49:20 EST


Albert Cahalan writes:

On Mon, 2004-08-09 at 18:59, 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'm pretty sure my FireWire CD-RW/CD-R is from
another century. Not that it's unusual in 2004.

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.

That's cool. My hardware won't come close to that.
Burning a coaster costs money.

Let me put it this way: $$ $ $$$ $$ $ $$$ $$ $

The warning, if re-worded, will save people from
frustration and wasted money.

Sounds good; how about something less terrifying? That warning sounds like a ruined cd is likely.

Last time I gave superuser privilege to cdrecord it locked my machine - clearly it wasn't rt_task safe.

So, you've been working on the scheduler anyway...
An option to reserve some portion of CPU time for
emergency use (say, 5% after 1 second has passed)
would let somebody get out of this situation.

This breaks the real time policy entirely. That's why I run it SCHED_ISO ... but of course this isn't available in mainline linux.

Reporting and/or fixing the cdrecord bug is nice too.

It was a hard lockup and randomly happened during a cd write, creating my first coaster in a long time... in rt mode ironically which is how it is recommended to be run. So I removed the foolish superuser bit and have had no problem since. Yes it was unaltered cdrecord source and it was the so-called alpha branch and... Not much else I can say about it really?

Cheers,
Con

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/