PATCH: cdrecord: avoiding scsi device numbering for ide devices
Subsystems (2)
Quoted 7 lines · Alan Cox
Quoted 6 lines · Joerg Schilling
[Alan Cox writes]
Quoted 3 lines
Linux has capabilities, ACLs and SELinux rulesets which can also be used to manage this. I can give the cd burner a role that permits it certain things.
Quoted 6 lines
Quoted 3 lines
If you are right, why then is SuSE removing the warnings in cdrecord that are there to tell the user that cdrecord is running with insufficient privilleges?
You'd have to ask them. Probably for the reason that most vendors remove a lot of the other weird warnings - it confuses end users.
Oh dear my. I'm going to, at least partially, agree with Joerg. Pigs are cleared for take-off.
The warning about "cdrecord dev=/dev/hdc" is truly crap. The same goes for "unsettled issues with Linux-2.5". The other warnings are sane though, and should not be removed.
If the warnings are confusing, they need to be re-worded. When you remove warnings, users get hurt. The users do things that may well fail, and then have no clue why things are failing.
Shall we rip the printk() calls out of the kernel? Many of them are weird. They might confuse the end users.
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"
Quoted 7 lines · Albert Cahalan
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"
Quoted 6 lines
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.
Con
I have burned one coaster in the last year with CDrecord (running as root) so it's still possible, it's just very rare.
David Lang
Quoted 35 lines · Con Kolivas
Date: Tue, 10 Aug 2004 08:59:25 +1000
From: Con Kolivas <[email protected]>
To: Albert Cahalan <[email protected]>
Cc: linux-kernel mailing list <[email protected]>,
[email protected], [email protected], [email protected], [email protected]
Subject: Re: PATCH: cdrecord: avoiding scsi device numbering for ide devicesQuoted 7 lines · Albert Cahalan
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"Quoted 6 lines
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_tasksafe.Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 3 lines
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Quoted 17 lines · Con Kolivas
Quoted 7 lines · Albert Cahalan
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"Quoted 6 lines
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"
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
Last time I gave
superuser privilege to cdrecord it locked my machine - clearly it wasn'trt_tasksafe.
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.
Reporting and/or fixing the cdrecord bug is nice too.
Quoted 25 lines · Albert Cahalan
Quoted 10 lines · Con Kolivas
Quoted 7 lines · Albert Cahalan
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"Quoted 8 lines
Quoted 6 lines
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.
Quoted 1 line
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.
Quoted 7 lines
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.
Quoted 6 lines
Quoted 1 line
Last time I gave superuser privilege to cdrecord it locked my machine - clearly it wasn't
rt_tasksafe.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.
Quoted 1 line
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
Quoted 31 lines · Con Kolivas
Quoted 30 lines · Albert Cahalan
Quoted 16 lines · Con Kolivas
Quoted 7 lines · Albert Cahalan
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"Quoted 6 lines
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"Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
Quoted 4 lines
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)
Quoted 11 lines
Quoted 8 lines
Quoted 3 lines
Last time I gave
superuser privilege to cdrecord it locked my machine - clearly it wasn'trt_tasksafe.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.
Quoted 46 lines · Albert Cahalan
Quoted 31 lines · Con Kolivas
Quoted 30 lines · Albert Cahalan
Quoted 16 lines · Con Kolivas
Quoted 7 lines · Albert Cahalan
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"Quoted 6 lines
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"Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 6 lines
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)
I've only created coaster _with_ the suid bit while ab^H^Husing the computer to do other things--like compiling a new kernel. 2.6 is much better at setting up DMA access to the drive; 2.4 would use huge amounts of system time (> 90%). When that happened, the system felt like it was out to lunch--mouse cursor updates would sometimes take >2 seconds. Cdrecord used more cpu if it was suid. I haven't had a problem in 2.6. The warning is counter to my expericnce with cdrecord. I think the warning would be worded better as:
"Warning: Cdrecord was unable to get exclusive access to the cpu." "Warning: This may cause Buffer underruns from other activity."
and
"Warning: Cdrecord was unable to get exclusive access to memory." "Warning: This may cause Buffer underruns from other activity."
But drop the first one if you're on >2.6.
Thomas
Quoted 9 lines · Albert Cahalan
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!
Encoding video is a typically CPU-bound task, unless your machine is so fast that it saturates the disk bandwidth. The scheduler should give the encoding lower priority than the "interactive" CD burning.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 2 lines
Light web browsing makes my
mp3 player skip.
What kind of machine is that? I've never needed to boost priority for the mp3 player on my P133, even when running opera and/or mozilla...
Getting offtopic here though :-\
Quoted 5 lines · Jan Knutar
Quoted 2 lines
Light web browsing makes my
mp3 player skip.What kind of machine is that? I've never needed to boost priority for the mp3 player on my P133, even when running opera and/or mozilla...
Since the last time I tested this, things have improved dramatically. This is 2.6.8-rc1 now; I had been mostly using 2.6.0-test5 and 2.6.0-test11. Still, I do get problems from:
1. resizing any window (oroborus wm + GNOME)
2. switching out of X with Alt-Ctrl-F1
3. switching into X with Alt-Ctrl-F7
I suppose this means that it is somewhat likely that burning a CD without CAP_SYS_RESOURCE would work. I doubt I'd like to risk my time and money on this, but at least it isn't looking like failure would be much more likely than success.
It irritates me that I'd need to compile up a hacked cdrecord in order to attempt a dummy burn as a regular user. Those warnings are treated as errors. Grrr... If SuSE, OSDL, IBM, SGI, HP or Red Hat would put up the money, I'd gladly fix this POS. Anybody care enough?
FWIW, my desktop machine is:
450 MHz Mac G4 Cube, 512 MB RAM, 1600x1024 32bpp, 5400 rpm IDE, ext2, no swap, 2.6.8-rc1 kernel, USB audio, ATI Rage 128 PF/PRO AGP 4x TMDS video
I run sound through esd, like this: mpg321 -o esd ...
Commonly, the X server grows to 300 MB and/or Mozilla grows to 200 MB before I restart them. An old GNOME is running with 8 desktops, Evolution and one or two dozen xterms.
Quoted 1 line · Con Kolivas
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?
I said I'd never seen this (true), but it could happen if you were burning an audio CD using the ide-scsi or ATA: interface. In 2.6 the ATAPI: interface uses DMA. I don't know what the program does if you just say dev=/dev/hdx, I don't normally use it that way (I got into the habit of using ATAPI:). Given a fast burner and the interface using PIO, I guess you could slow the system down some!
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Quoted 9 lines · Bill Davidsen
Quoted 6 lines · Con Kolivas
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?
Quoted 4 lines
I said I'd never seen this (true), but it could happen if you were burning an audio CD using the ide-scsi or ATA: interface. In 2.6 the
ATAPI: interface uses DMA. I don't know what the program does if you just say dev=/dev/hdx,
Whatever it does, it doesn't load the system noticeably.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 11 lines · Måns Rullgård
Quoted 9 lines · Bill Davidsen
Quoted 6 lines · Con Kolivas
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?
Quoted 4 lines
Quoted 4 lines
I said I'd never seen this (true), but it could happen if you were burning an audio CD using the ide-scsi or ATA: interface. In 2.6 the
ATAPI: interface uses DMA. I don't know what the program does if you just say dev=/dev/hdx,
This is only true for recent 2.6 kernels.
Quoted 1 line
Whatever it does, it doesn't load the system noticeably.
ATA uses SG_IO. Bill should re-read most of this thread as he is repeating what others have said and have been corrected on (not just this mail, btw).
Signature · 1 line
Jens Axboe
Quoted 8 lines · Albert Cahalan
Quoted 3 lines
Last time I gave
superuser privilege to cdrecord it locked my machine - clearly it wasn'trt_tasksafe.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.
Another option would be an Alt-Sysrq-something that lowered all RT processes to normal levels.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 6 lines · Måns Rullgård
Quoted 4 lines · Albert Cahalan
Quoted 3 lines
Last time I gave
superuser privilege to cdrecord it locked my machine - clearly it wasn'trt_tasksafe.
Quoted 7 lines
Quoted 4 lines
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.
Another option would be an Alt-Sysrq-something that lowered all RT processes to normal levels.
I hate to derail a good flame-fest, but this would be extremely useful, for more than burning CDs. Anytime you are dealing with a SCHED_FIFO process a bug can lock the machine, this would be useful for hacking jackd for example.
If someone wants to code this up I and the other people on jackit-devel would gladly test it.
Lee
Quoted 7 lines · Lee Revell
I hate to derail a good flame-fest, but this would be extremely useful, for more than burning CDs. Anytime you are dealing with a
SCHED_FIFOprocess a bug can lock the machine, this would be useful for hacking jackd for example.If someone wants to code this up I and the other people on jackit-devel would gladly test it.
How much is this actually needed and how much is it just a user debugging method problem. Having done real time stuff on VMS (save the tears) we always had a policy that one serial console was a shell at highest priority and nobody ever used that one top priority.
That gave you an emergency control channel.
Quoted 9 lines · Alan Cox
Quoted 7 lines · Lee Revell
I hate to derail a good flame-fest, but this would be extremely useful, for more than burning CDs. Anytime you are dealing with a
SCHED_FIFOprocess a bug can lock the machine, this would be useful for hacking jackd for example.If someone wants to code this up I and the other people on jackit-devel would gladly test it.
Quoted 6 lines
How much is this actually needed and how much is it just a user debugging method problem. Having done real time stuff on VMS (save the tears) we always had a policy that one serial console was a shell at highest priority and nobody ever used that one top priority.
That gave you an emergency control channel.
Yeah, I haven't yet been in a situation where I needed this, it would be useful only in theory. It sounded like someone was volunteering to code it up.
Lee
Quoted 15 lines · Lee Revell
Quoted 6 lines · Måns Rullgård
Quoted 4 lines · Albert Cahalan
Quoted 3 lines
Last time I gave
superuser privilege to cdrecord it locked my machine - clearly it wasn'trt_tasksafe.Quoted 7 lines
Quoted 4 lines
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.
Another option would be an Alt-Sysrq-something that lowered all RT processes to normal levels.
Quoted 7 lines
I hate to derail a good flame-fest, but this would be extremely useful, for more than burning CDs. Anytime you are dealing with a
SCHED_FIFOprocess a bug can lock the machine, this would be useful for hacking jackd for example.If someone wants to code this up I and the other people on jackit-devel would gladly test it.
Here you go. Some limited testing suggests that it actually works. Pressing Alt-Sysrq-N (as in Nice) changes all RT tasks to SCHED_NORMAL policy.
===== drivers/char/sysrq.c 1.29 vs edited =====
drivers/char/sysrq.c +11 -1
@@ -216,6 +216,16 @@/* END SIGNAL SYSRQ HANDLERS BLOCK */ +static void sysrq_handle_unrt (int key,struct pt_regs *pt_regs, +struct tty_struct *tty) +{ +normalize_rt_tasks (); +} +static struct sysrq_key_op sysrq_unrt_op = { + .handler = sysrq_handle_unrt, + .help_msg ="Nice" , + .action_msg ="Nice All RT Tasks" +};/* Key Operations table and lock */ static spinlock_t sysrq_key_table_lock =SPIN_LOCK_UNLOCKED ;
@@ -250,7 +260,7 @@#endif /* l */ NULL ,/* m */ &sysrq_showmem_op, -/* n */ NULL , +/* n */ &sysrq_unrt_op,/* o */ NULL ,/* This will often be registered as 'Off' at init time */ /* p */ &sysrq_showregs_op,
===== include/linux/sched.h 1.197 vs edited =====
include/linux/sched.h +6 -0
@@ -944,6 +944,12 @@#endif /* CONFIG_SMP */ +#ifdef CONFIG_MAGIC_SYSRQ + +extern void normalize_rt_tasks (void ); + +#endif +#endif /* __KERNEL__ */ #endif
===== kernel/sched.c 1.261 vs edited =====
kernel/sched.c +32 -0
@@ -3053,3 +3053,35 @@EXPORT_SYMBOL (__preempt_write_lock);#endif /* defined(CONFIG_SMP) && defined(CONFIG_PREEMPT) */ + +#ifdef CONFIG_MAGIC_SYSRQ +void normalize_rt_tasks (void ) +{ +struct task_struct *p; +prio_array_t *array; +unsigned long flags; +runqueue_t *rq; + +for_each_process (p) { +if (!rt_task (p)) +continue ; + +read_lock_irq (&tasklist_lock); + rq =task_rq_lock (p, &flags); + + array = p->array; +if (array) +deactivate_task (p,task_rq (p)); +__setscheduler (p,SCHED_NORMAL ,0 ); +if (array) { +__activate_task (p,task_rq (p)); +resched_task (rq->curr); + } + +task_rq_unlock (rq, &flags); +read_unlock_irq (&tasklist_lock); + } +} + +EXPORT_SYMBOL (normalize_rt_tasks); +#endif /* CONFIG_MAGIC_SYSRQ */
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 7 lines · Måns Rullgård
Quoted 5 lines · Lee Revell
Quoted 2 lines · Måns Rullgård
Another option would be an Alt-Sysrq-something that lowered all RT processes to normal levels.
Quoted 7 lines
Quoted 2 lines
If someone wants to code this up I and the other people on jackit-devel would gladly test it.
Here you go. Some limited testing suggests that it actually works. Pressing Alt-Sysrq-N (as in Nice) changes all RT tasks to
SCHED_NORMALpolicy.
I sent this patch to the jackit-devel list, and everyone seems to think this would be a useful feature; had this been around a few years ago it certainly would have aided JACK's development. Debugging an RT process becomes as easy as a regular one (read: reboot free). I see no reason not to merge it once it has been widely tested.
Lee
Quoted 11 lines · Lee Revell
Quoted 10 lines · Måns Rullgård
Quoted 7 lines · Lee Revell
Quoted 2 lines · Måns Rullgård
Another option would be an Alt-Sysrq-something that lowered all RT processes to normal levels.
If someone wants to code this up I and the other people on jackit-devel would gladly test it.
Quoted 8 lines
Quoted 4 lines
Here you go. Some limited testing suggests that it actually works. Pressing Alt-Sysrq-N (as in Nice) changes all RT tasks to
SCHED_NORMALpolicy.I sent this patch to the jackit-devel list, and everyone seems to think this would be a useful feature; had this been around a few years ago it certainly would have aided JACK's development.
So why didn't anyone write it earlier?
Quoted 3 lines
Debugging an RT process becomes as easy as a regular one (read:
reboot free). I see no reason not to merge it once it has been widely tested.
Let me know how the testing works out.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 8 lines · Måns Rullgård
Quoted 4 lines · Lee Revell
I sent this patch to the jackit-devel list, and everyone seems to think this would be a useful feature; had this been around a few years ago it certainly would have aided JACK's development.
So why didn't anyone write it earlier?
Eh, possibly it's one of those things that's very useful in theory but that no one ever actually needed enough to write. JACK has been stable for a while now and has mechanisms for preventing buggy clients from locking the machine.
Lee
Quoted 19 lines · Con Kolivas
Quoted 7 lines · Albert Cahalan
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"Quoted 7 lines
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"
Quoted 1 line
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_tasksafe.
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.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Quoted 7 lines · Albert Cahalan
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"
Quoted 6 lines
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"
That seems reasonable, but _only_ if burnfree is not enabled. If the hardware _supports_ burnfree but it's disabled, the warning should also recommend turning it on.
Signature · 1 line
dwmw2
Quoted 15 lines · David Woodhouse
Quoted 7 lines · Albert Cahalan
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"Quoted 6 lines
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"
Quoted 3 lines
That seems reasonable, but _only_ if burnfree is not enabled. If the hardware _supports_ burnfree but it's disabled, the warning should also recommend turning it on.
I'm also wondering why cdrecord disables it by default. Can it ever do any harm being enabled?
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 10 lines · Måns Rullgård
Quoted 3 lines · David Woodhouse
That seems reasonable, but _only_ if burnfree is not enabled. If the hardware _supports_ burnfree but it's disabled, the warning should also recommend turning it on.
I'm also wondering why cdrecord disables it by default. Can it ever do any harm being enabled?
In theory, yes. It makes the track longer, so it could in theory make something large not fit. In practice, there really are some readers which skip on audio when they see the blanks. As Joerg which ones, but other people have agreed that it does happen.
I have noted that even with it off my recent burners don't mind running out of data, so in most cases it won't hurt. Burning off NFS I see 7-10 underruns typically.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Quoted 6 lines · Bill Davidsen
Quoted 5 lines · Måns Rullgård
Quoted 3 lines · David Woodhouse
That seems reasonable, but _only_ if burnfree is not enabled. If the hardware _supports_ burnfree but it's disabled, the warning should also recommend turning it on.
Quoted 8 lines
Quoted 3 lines
I'm also wondering why cdrecord disables it by default. Can it ever do any harm being enabled?
In theory, yes. It makes the track longer, so it could in theory make something large not fit. In practice, there really are some readers which skip on audio when they see the blanks. As Joerg which ones, but other people have agreed that it does happen.
As has been pointed out by others, the alternative is a wasted disk. Even if the quality is degraded slightly where burnfree kicks in, the disk may still be suitable for its intended use. CDs are often used for moving some data to another machine and discarded after a single use. In these cases, a lower resistance to scratches is not a problem. For long-term storage the situation could of course be different.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 3 lines
That seems reasonable, but _only_ if burnfree is not enabled. If the hardware _supports_ burnfree but it's disabled, the warning should also recommend turning it on.
burnfree causes a few broken pits/lands on the CD-R so it is best avoided if the hardware can do it. That you don't see these is a matter of the reading drive not exporting such information and EFM and CIRC usually correcting them, but it's still lower quality than a burn process that hadn't needed burnfree at all.
Signature · 4 lines
Matthias Andree NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF! Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matthias Andree wrote:
|>That seems reasonable, but _only_ if burnfree is not enabled. If the |>hardware _supports_ burnfree but it's disabled, the warning should also |>recommend turning it on. | | | burnfree causes a few broken pits/lands on the CD-R so it is best | avoided if the hardware can do it. That you don't see these is a matter | of the reading drive not exporting such information and EFM and CIRC | usually correcting them, but it's still lower quality than a burn | process that hadn't needed burnfree at all. |
Well shouldn't that broken pits just happen, wehn the buffer gets empty and the laser continues where it stopped after having data in buffer again? I guess this is better then a coaster.
BTW, I don't have problems burning as a user while doing other things...
Prakash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGJ1nxU2n/+9+t5gRAjljAKCbjbxNX47d7//QDkQNP/e8OMB5aACfXFDa Z3CorT523TXskw4YEBMRaDk=
=cpq7
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matthias Andree wrote:
|>That seems reasonable, but _only_ if burnfree is not enabled. If the |>hardware _supports_ burnfree but it's disabled, the warning should also |>recommend turning it on. | | | burnfree causes a few broken pits/lands on the CD-R so it is best | avoided if the hardware can do it. That you don't see these is a matter | of the reading drive not exporting such information and EFM and CIRC | usually correcting them, but it's still lower quality than a burn | process that hadn't needed burnfree at all.
Some addition: Even if your statement is correct, the data read is not different, as C1 error correction should mask it. Yes, the quality obviosly is lower, but most probably you won't notice it, unless the disk degrades with time/scratches and now more errors appear, so it isn't correctable anymore. But I think it is paranoic to rather have coasters than living with a bit less quality at some spots where buffer underruns occured.
Prakash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGJ5hxU2n/+9+t5gRAtDtAKCnOgqG+6PobYDcDuNxdA6zdjPQwACgxjxL Vy0KwpXHoMixCIvKeuxsZP0=
=WEtE
-----END PGP SIGNATURE-----
Quoted 10 lines · Albert Cahalan
Shall we rip the
printk()calls out of the kernel? Many of them are weird. They might confuse the end users.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"
Quoted 5 lines
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"
"hog" certainly is not the right word here, but let's not discuss application warnings on word level here.
Quoted 1 line
" If the computer is not idle, the CD may be ruined.\n"
The warning still needs to contain a technical information that the end user can report to the support or maintainer. Jörg's warning isn't all too bad only the user may not know what a buffer underrun actually means, so another line of explanation, a recommendation to retry with increased (root) privileges and preferably another 10 s delay would iron this out.
Note that while the burn-proof/just-link feature allows the drive to pick up writing but it comes at a price, a few dozen pits/lands are hosed for every time this feature gets used, so it's best to avoid interrupting the write stream.
One of Jörg's goals appears to let his application do the best possible job without such micro gaps, and that deserves all support he can get.
That the DMA, ide-scsi, interfaces and naming issues can't be settled is sad and it appears as though the naming and it seems these issues cannot be discussed separately for some reason.
Signature · 4 lines
Matthias Andree NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF! Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)
Quoted 7 lines
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"
Does this also apply if burnproof is in use?
Quoted 6 lines
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"