> > I am working around this problem at the moment by disabling the error > > handling in dvb_ca_en50221_set_configoption. > > Oh right, so it works, even though that fails? That is weird. Hmmm, perhaps > I'm not resetting it enough... If you have a moment, can you bung a printk in > to see what the value of configoption is when it fails? >
On further tests I found out, that it has nothing todo with the second driver load. Now it often fails at the first load. I have inserted your suggested printk. The output is: Apr 13 00:56:04 videobox kernel: Valid DVB CAM detected MANID:ffff DEVID:1 CONFIGBASE:0x1fe CONFIGOPTION:0xf Apr 13 00:56:04 videobox kernel: dvb_ca_en50221_set_configoption Apr 13 00:56:04 videobox kernel: configoption=0xff It reads back 0xff from the config register. > BTW: Just committed a fix for a stupid bug when reading packets; I've got the > transport layer protocol up and running now. I can't guarantee it'll work for > packets which require fragmentation, but I'll sort that once I've implemented > the higher layers. It is now working quite well with normal packets, but fragmented packets cause an endless loop in dvb_ca_en50221_io_read_condition. The bug is in dvb_ringbuffer.c. The function dvb_ringbuffer_pkt_next does not return the next packet when called with idx != 0. It is returning the same packet again. The communication with the card is now working well. I can use all options of the card menu. I am looking forward into getting the transport stream routed through the card. Regards, Bernhard PS: To Andrew: Please excuse the direct mail to you instead to the list, it was a mistake. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
