On Fri, 31 Mar 2006, Gunther Mayer wrote: > > 1) lspci -vn after a cold boot wihtout loading the module > > 2) lspci -vn after a warm boot without loading the module (not loaded > > since the machine was powered up) > > 3) lspci -vn after a warm boot where the module was loaded prior to > > the reboot > > > Thanks this proves: > - warm boot leaves the PCI subsystem ID intact > - loading the saa7134 module corrupts some state on the card, > so on the next reboot the PCI subsystem ID is corrput I think it might be safe to narrow it down a bit more than that. This is what James found in the eeprom when his card works: saa7134[1]: subsystem: 185b:c900, board: Compro Videomate DVB-T300 saa7134[1]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 Notice that the first four bytes in the eeprom are the subsystem ID. The saa7134 will read the subsystem ID from a I2C connected eeprom when it resets. In this case, the eeprom looks like it should. Now here is the eeprom when the card doesn't work: saa7134[1]: i2c eeprom 00: 02 10 00 01 04 00 1c 00 40 03 00 10 04 00 82 10 It's totally different! This should not happen. Clearly something the linux driver is doing is messing up the eeprom. The linux code leaves the address counter in the eeprom at 128, instead of 0. I thought maybe the saa7134 didn't reset the eeprom address to 0 before trying to read from it, and so was reading from the wrong location. But that doesn't explain why the driver eeprom dump returns totally different data. It must be something else. What happens if you cold boot, load the driver, unload it, then load it again? Is the eeprom data messed up on the second load? In other words, does the driver mess up the eeprom immediately, or does it only happen after a warm boot? _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
