On Tue, 2005-10-18 at 20:33 +0400, Manu Abraham wrote: > > > On 10/18/05, Sigmund Augdal Helberg <sigmund@xxxxxxx> 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 >
