[linux-dvb] problems and workaround when tuning to a channel with DD enabled

Oliver Endriss o.endriss at gmx.de
Tue Jun 7 01:42:45 CEST 2005


Johannes Stezenbach wrote:
> Oliver Endriss wrote:
> > Johannes Stezenbach wrote:
> > > The code looks broken. If ret == -ERESTARTSYS (is what you get), then it
> > > is no timeout, but wait_event_interruptible_timeout() got interrupted.
> > > I bet vdr is sending some signals around.
> > > 
> > > Try using wait_event_timeout(..., HZ/5), i.e. non-interruptible but
> > > with a sensible timeout. 10*HZ is much too long, IMHO.
> > 
> > IIRC I increased the timeout to 10*HZ because osd transfers are very
> > slow if there are 3 or 4 recordings running at the same time...
> 
> Well, if you ask for trouble, you get some...
> IMHO it's bad to sleep uninterruptibly for longer than,
> say, one second. But the way OSDSetBlock() is coded
> one cannot interrupt it without messing up the internal
> state. Or, maybe one could bail out after a BlitBitmap()
> and return -ERESTARTSYS, so the whole ioctl will
> be repeated?

With firmware 261d you could do that because Werner added a timeout for
bitmap transfers. 261c and earlier would block until the ARM was
rebooted... :(

Unfortunately, DPRAM bandwidth is a bottleneck. According to my test
results, a short timeout will prevent the bitmap transfer to complete
successfully under heavy load. So aborting+repeating the ioctl would
not help.

Maybe OSD transfers should be given a higher priority?

> > Anyway, I've never seen any -ERESTARTSYS errors.
> 
> Me neither. But this proves nothing.

Sure, but it should not happen unless vdr was killed.
I wonder where this signals come from.

Oliver

-- 
--------------------------------------------------------
VDR Remote Plugin available at
http://www.escape-edv.de/endriss/vdr/
--------------------------------------------------------




More information about the linux-dvb mailing list