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/ --------------------------------------------------------
