[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