manu wrote: > On 10/11/2007 06:41:14 PM, Oliver Endriss wrote: > > manu wrote: > > > On 10/10/2007 01:02:46 PM, Oliver Endriss wrote: > > > > manu wrote: > > > > > On 10/09/2007 06:15:14 PM, Oliver Endriss wrote: > > > > > > @all users of saa7146-based cards > > > > > > > > > > > > (drivers: dvb-ttpci, budget, budget-ci, budget-av) > > > > > > > > > > > > Please test whether the attached patch has any negative > > effects. > > > > > > > > > > > > Two fixes for the 'saa7146_wait_for_debi_done' code: > > > > > > (a) Timeout did not work when the routine was called with > > > > interrupts > > > > > > disabled. > > > > > > (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done. > > > > > > Seems to be very important on fast machines! > > > > > > > > > > > > Based on a patch posted by e9hack@vdr-portal. > > > > > > > > > > > > If nobody complains I will commit this patch next week. > > > > > > > > > > Well sorry it seems to create an oops on my box. Just to make > > sure > > > > > though: it is the first time I compile and load modules from > > > > mercurial > > > > > and so could it just be a compatibility problem with my > > 2.6.20-16 > > > > > Ubuntu Feisty kernel? > > > > > > > > Please make sure that you do not mix v4l/dvb modules from the > > original > > > > kernel and the HG driver, or you will see all kinds of crashes. > > > > > > > > First try the HG driver without my patch. If it works, apply the > > patch > > > > and try again. > > > > > > > > > > OK now everything looks identical to the bug I described in a > > previous > > > post: this time CAM is OK looking at the logs (though gnutv -cammenu > > > > > seems unresponsive whereas it used to work before, did something > > > change, should I recompile it?), but dmesg says no driver found for > > the > > > frontend... > > > > You do not have to recompile the application. > > > > Just to be sure: > > There is no difference whether you apply the patch or not. > > Correct? > > Well at first I thought that no, but it seems that the frontend is > found more easily with this patch, whereas it sometimes fails to be > loaded with the clean tree. See below. That's fine. ;-) > > Are you referring to the thread 'TT S-1500 CI not finding frontend > > driver'? > > Yes > > > Did the card ever work reliably in this machine? > > Type of machine? SMP system? > > Via KM400, yes I know, AMD athlon (single core cpu). > Yes beautifully, but at some point I got a weird error: the cam stopped > working (I got a dvb error in dmesg) and I had either to reboot or just > eject/reinsert I don't remember now. Since then it has been on and off. > And now I get "CAM did not respond" in the logs, even thoughI get the > full cam signature in the logs: so my guess is that the CI interface > works as it is able to retrieve the module name/signature, but the CAM > itself is damaged. > This leads to my next question: is it possible that the bad CAM induces > i2c errors/timeouts leading to the frontend not being found? And in > this respect your patch seems to be helpful, as the frontend is, AFAICT > always found now. Hard to tell. The patch reduces I/O load during some kinds of debi transfers, and the CAM is connected to the debi interface... > > Did the problem appear after updating the driver? > > Nope > > > I2C bus problems might be caused by a broken power supply or > > mainboard. > > You might also try a different pci slot. > > Well the power supply of the beast is certailny not very good, but now > I think that th CAM is faulty. CAM problems are sometimes caused by a broken cable between CI and DVB card. CU Oliver -- ---------------------------------------------------------------- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ---------------------------------------------------------------- _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
