[linux-dvb] Kernel locking in dst

[Sigmund Augdal Helberg]

On Tue, 2005-10-18 at 20:33 +0400, Manu Abraham wrote:
> 
> 
> On 10/18/05, Sigmund Augdal Helberg <sigmund at snap.tv> wrote:
>         On Tue, 2005-10-18 at 14:39 +0200, Henrik Sjoberg wrote:
>         > Hi,
>         >
>         > I am playing a bit with getting MythTV to talk high level
>         CI. However, I
>         > have come to a problem in the dst/dst_ca drivers. MythTV
>         have different 
>         > threads running for tuning frequency and doing ca-stuff.
>         This makes me get
>         > simultaneous frontend and ca calls device. However, in the
>         dst driver
>         > these two things both end up in i2c communiation with the
>         card which 
>         > interfere with each other.
>         >
>         > As you can understand this does not work good since there
>         are no locking
>         > mechanism in dst. Is this something that is to go into the
>         driver or
>         > something that should be done on a higher level ( e.g.
>         between all
>         > components in an dvb-adapter)? I guess it should be taken
>         care of by the
>         > driver, since it is the only one that knows when locking is
>         needed, but I
>         > just want to check.
>         
>         I've played around to make vlc speak high level CI. I have
>         code that I'm 
>         fairly confident makes correct capmt messages, but it only
>         works once in
>         a while. I have all sorts of strange behaviour. Some times the
>         system
>         gets in a state where tuning does not work (no calls report
>         any errors, 
>         but the received mux does not change). unloading and reloading
>         the
>         driver fixes this. Some times the dst.session struct get
>         messed up so
>         that the dst_ca belive has_session is set while it actually is
>         not. And
>         even other times the cam or card or smartcard or something
>         gets stuck in
>         a state where any call to the ca device return just garbage.
>         This
>         sometimes solves itself after a minute or two, and other times
>         I need a
>         cold boot to get it working again. I was under the impression
>         that this 
>         had to be caused by a memory corrution caused by a buffer
>         overflow in
>         the i2c trafic(because increasing the size *_buf fields in the
>         state
>         struct stoped the has session flag from being corrupted, but
>         perhaps
>         this is the cause of my problems as well?
> 
> 
> Few weeks back, i had fixed a possible buffer overlow situation, Are
> you talking about that ? If you are not with the updated with the
> latest change. Well that was the last change that i had..
> Maybe you can check it again, incase you are not updated with the
> latest. Maybe you can try the  patch too, to check whether it helps
> you in some manner.
I have unfortunatly had way to many things to do lately, so I haven't
gotten around to testing this lately. Meaning my tree is a bit outdated.
When I get a spare moment I will try to connect everything up again and
try a recent tree, and possibly the patch as well. Just out of
curriosity, could you point me to the file/revision where this fix is,
so I can have a look at the diff?

Thanks

Sigmund
> 
> 
> Regards,
> Manu
>