Hello Oliver,
and thanks for your reply.
On Saturday 16 August 2008 06:31:21 Oliver Endriss wrote:
> Please test the attached patch (untested because I do not own this kind
> of hardware). Please save your work before loading the patched driver,
> since a locking bug might crash your machine...
I will give it a try and let you know as soon as I have some results. Testing
changes or getting more debugging output (see below) is quite time consuming
because you have no idea how long it takes till you'll hit the problem again.
Yesterday it happened several times across the day- and unfortunately over
night (when I was testing changes in the en50221 implementation), everything
was rock stable. :-(
By the way, I spent the last few days hacking on dvb_ca_en50221.c, putting a
lot more debugging output in it and thus trying to narrow the problem down.
There are a few corner cases which IMHO could have been triggered and have
caused this. I'll try to confirm or disprove those and according to this try
to fix those if necessary.
One more thing: the en50221 "driver" assumes that setting bit 7 of the command
register enables/disables irq signaling. According to the en50221 standard
those bits are reserved and shall be always zero. Do you know where I can
find more informations on this...?
Thanks again and have a nice weekend,
Matthias
PS. For now, I am keepking this off the vdr mailing list because I've reviewed
the vdr cicam handling code and everything looks fine- except for maybe
the error handling which could be a bit more flexible. I guess due to the
continued cam monitoring implemented in vdr 1.5.x, the bug just happens to
be triggered more easily/frequently.
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
