On Wed, Jun 08, 2005 at 12:59:34PM +0200, Johannes Stezenbach wrote: > On Wed, Jun 08, 2005 at 11:56:24AM +0200, Dr. Werner Fink wrote: > > On Tue, Jun 07, 2005 at 09:53:55PM +0200, Wolfgang Rohdewald wrote: > > > On Dienstag 07 Juni 2005 21:04, Oliver Endriss wrote: > > > > 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? > > > > > > My idea would be: on entry of OSDSetBlock: if there is a current transfer, > > > wait for it to finish, call ReleaseBitmap and start all over. > > > > This does not work. The OSD commands are queued by the > > firmware upto the point where the data load is done. > > I think it does. "wait for current transfer to finish" just > waits for the fw to ack to last DMA, ReleaseBitmap() then > aborts the upload (this wasn't intended, hence the > "paranoia" comment in the fw source in bitmap_loading_finished()), > but it should work nevertheless. OK, Werner is right, this doesn't work :-( (I misread the firmware source code) We need a firmware change to allow aborting OSDSetBlock. Johannes
