On Mon, 21 Sep 2009, Roger wrote: > This bug is caused by either the lirc init.d service and/or it's > lirc_dev & lirc_i2c modules being loaded. > > Grepping the log of a recent kernel syslog using kernel 2.6.30 with all > tracers/debugging enabled plainly showed lirc being loaded just prior to > every occurrence of the s5h1411 i2c error. > > Simply blacklisting the lirc* modules resolves this issue and then > rebooting or reloading the pvrusb2 along with refreshing the firmwares. > > (Simply reloading the pvrusb2 module after unloading the lirc* modules > isn't enough. The firmwares must be refreshed for some reason. > > I sent a log to the list, but the list won't take the large amount of > text. :-/ >
Sorry, the list is configured not to allow large attachments because (1) I don't want my poor server sending out 150 times .5MB through its uplink when something like that appears, and (2) A lot of subscribers to this list are really not going to want to get stuff this big for a low traffic list like this. This *might* be explainable if the lirc module is probing something that is upsetting your s5h1411 which then causes the tuner module to get angry when it loses contact with the chip. With that said however you are still the only person to be seeing this problem and I haven't yet been able to reproduce it. Reloading firmware should be irrelevant. Probably the real effect is that you're reinitializing the device. The pvrusb2 driver upon loading will not actually *reset* the device unless the FX2 firmware gets reloaded. Unfortunately it can't reset the device unconditionally because that reset also causes the device to go offline (i.e. it will look like it has been unplugged from the USB cable), which then causes the pvrusb2 driver to also be cleared out. Of course after a reset the device comes back, the pvrusb2 driver is reassociated and initialization continues - but since the pvrusb2 driver can't have any "knowledge" of anything prior to the reset then it won't know that the device has already been reset so therefore another unconditional reset will just throw you into a forever-loop of initialization. Not sure if you can follow that but it's really a simpler problem than this convoluted explanation. The reason we are OK with a reset upon firmware load is because the driver can tell this case apart and can avoid the loop. (Actually there's no choice here - a device reset is required after a firmware load and happens implicitly when the pvrusb2 driver completes the FX2 firmware download.) -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
