Johannes Stezenbach wrote: > 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. Ok. [Sorry, I never worked with signals in the kernel.] If I understood this -ERESTARTSYS thing correctly, the interrupted ioctl will be automagically restarted when the user space signal handler has completed. Signals can occur anytime, so the driver is broken and has to be fixed. The easiest and most robust fix would be to abort OSDSetBlock and restart from the beginning. Can we tell the firmware to abort the current bitmap transfer? We could set IRQ_STATE_EXT = TX_LEN = TX_BUFF = 0 in DATA_BMP_LOAD, if the firmware would accept that. Any comments? Oliver -- -------------------------------------------------------- VDR Remote Plugin available at http://www.escape-edv.de/endriss/vdr/ --------------------------------------------------------
