Messages in this thread |  | | Subject | Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices | From | Albert Cahalan <> | Date | 09 Aug 2004 22:51:24 -0400 |
| |
On Tue, 2004-08-10 at 00:47, Con Kolivas wrote: > 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.
I'm not about to burn CDs trying, but I do believe that "a ruined cd is likely" would be accurate if I were to keep busy with Mozilla and such. OpenOffice would surely ruin a cd. Light web browsing makes my mp3 player skip.
Not all of us have hardware like you do. Encoding video is something I wouldn't bother to try, even without the CD burner going!
(the box isn't that old; it's fanless though)
> >> 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.
Of course it breaks the real time policy entirely. It would have to be enabled via a sysctl.
The NMI watchdog breaks cli/sti. We have it anyway. This is the same thing.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |