Oliver Endriss wrote: > Johannes Stezenbach wrote: > > 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. Misunderstanding: When we sleep interruptibly we can use a long timeout. But we need to correct the error handling so that the ioctl is restarted when it got interrrupted, and the current partial transfer (LoadBitmap/BlitBitmap pair) must be terminated so the firmware state is not messed up. > > > 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. vdr sets a watchdog with alarm(). Signals could also come from the kernel (SIGIO, SIGCHLD etc.). (I thought vdr uses signals internally, but this doesn't seem to be true anymore). Johannes
