Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: Kernel-Patch to make VDR undisturbable
On Friday 05 April 2002 14:54, Matthias Lötzke wrote:
> Andreas Schultz (aschultz@cs.uni-magdeburg.de) schrieb:
> > I don't think patching the kernel is the right way to go.
>
> Do you see a possibility in userspace to make sure that VDR runs
> undisturbed? I do not. IMHO a kernel modification is unavoidable.
yep, SCHED_FIFO/SCHED_RR ;-)
> > Besides, you should
> > be able to achive the same thing by using real time scheduling priorities
> > and policy. SCHED_FIFO or SCHED_RR should do the same thing without the
> > kernel patch.
>
> No. Scheduling VDR with realtime priority can cause deadlocks. I did tests
> and whole machine stopped. A hardware reset was needed after.
I'm not surprised, from 'man sched_setscheduler':
As a non-blocking end-less loop in a process scheduled
under SCHED_FIFO or SCHED_RR will block all processes with
lower priority forever, a software developer should always
keep available on the console a shell scheduled under a
higher static priority than the tested application. This
There are quite some non-blocking end-less loops in vdr. As a starter one can
try to replace/enhance all usleep() with sched_yield(). However, the better
solution would to remove all busy type loops and replace the with some sane
synchronisation.
The worst example of this is in dvbapi.c, cReplayBuffer::Input():
while (Busy() && (blockInput || NextFile())) {
if (blockInput) {
if (blockInput > 1)
blockInput = 1;
continue;
}
now, if blockInput is true, this will degrate into a tight non-blocking loop,
no wonder vdr blocks the whole system under real time scheduling.
A patch to fix up the syncing in the ringbuffers, you can have a look at:
http://www.cs.uni-magdeburg.de/~aschultz/dvd/vdr-1.0.0pre3-sync.diff.bz2,
but i'm sure there are plenty of other places left.
Andreas
Home |
Main Index |
Thread Index