[linux-dvb] Re: OOPS with budget card + cam (in dvb_ca_en50221_io_write)

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Thursday 16 Sep 2004 11:43, Andrew de Quincey wrote:
> > >>Bah! OK, I'll have a look into it later. Thanks for the log.
> > >
> > >Hi, this is coming from the middle of the msleep() call in
> > >dvb_ca_en50221_io_write() - nothing to do with me (heheheh! :)
> > >
> > >You're using kernel 2.6.8.1. I had to downgrade to 2.6.7 because of
> > > massive problems with that kernel (specifically NFS, but this looks
> > > like the same kind of error). Do you have the preemptible kernel stuff
> > > turned on? That was what caused it for me.
> >
> > In which context is this code running? Should it get delayed and get
> > processed in a work queue?
>
> I assume you're talking about the msleep().
>
> The problem with CAMs is that you can't rely on their IRQ support - the
> standard was originally defined without them, so all your code has to be
> able to cope with them not being there.
>
> Therefore, to write data, you have to have a loop which continually asks
> the CAM if its ready for data yet.. if not => sleep+keep looping.
>
> If I moved the stuff in io_write() into a work queue, I would still have to
> have a thread somewhere doing the above loop. It was simpler just to leave
> it in the io_write() itself - easier to handle user aborting the syscall,
> or the CAM being yanked during a write.
>
> It doesn't break the semantics of write() as it is - if you're in blocking
> mode, it will block until the write is complete, if you're in non-blocking,
> it will not proceed unless it can write the data.

Additionally, there's not _that_ much data being sent to the CAM - I didn't 
see the point in overcomplicating things.