Have done some more reboot testing, and the stability is continuing - to a degree.
Problems that are still occuring: 1. The tveeprom on i2c 0x0050 sometimes reports errors: tveeprom 0-0050: Encountered bad packet header [ff]. Corrupt or not a Hauppauge eeprom. -although this doesn't seem to affect operation 2. The i2c tuner device fails to register, before IVTV goes looking for it: i2c_adapter i2c-0: adapter [ivtv i2c driver #0] registered i2c_adapter i2c-0: client [tveeprom] registered with bus id 0-0050 tveeprom 0-0050: Encountered bad packet header [ff]. Corrupt or not a Hauppauge eeprom. ivtv0: No tuner detected, default to NTSC tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0) cx25840 0-0044: cx25841-23 found @ 0x88 (ivtv i2c driver #0) wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0) Is there a way to force IVTV to wait, or check all the i2c devices have registered?? ----- Original Message ----- From: "Simon Baxter" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "User discussion about IVTV" <[email protected]> Sent: Thursday, June 01, 2006 12:28 PM Subject: Re: [ivtv-users] i2c problems with FC5 and svn ivtv 0.8.0 >> vtv0: Autodetected Hauppauge WinTV PVR-150 card (cx23416 based) >> ACPI: PCI Interrupt 0000:02:0e.0[A] -> GSI 17 (level, low) -> IRQ 17 >> tveeprom 0-0050: Hauppauge model 26032, rev C199, serial# 8125669 >> tveeprom 0-0050: tuner model is TCL 2002N 5H (idx 99, type 50) >> tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08) >> tveeprom 0-0050: audio processor is CX25841 (idx 35) >> tveeprom 0-0050: decoder processor is CX25841 (idx 28) >> tveeprom 0-0050: has no radio, has IR remote >> tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0) >> wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0) >> >>> ivtv0: i2c hardware 0x00000001 not found for command 0xc008561c! >>> ivtv0: i2c addr 0x44 not found for command 0x40045613! >>> ivtv0: i2c addr 0x44 not found for command 0x4008646f! >> >> At this point mine is identical, right down to the same hex numbers: > > Stands to reason the hex numbers are the same - the same commands are > being issued. > > It appears to be a problem with the i2c linking with IVTV. Thomas Schmitz > is onto something, when he said: > "better code optimization in gcc-4.1 breaks some assumptions of > the i2c code. The compiler has really no idea about the dependencies > needed for accessing hardware (e.g a specific store that has to > occur before a load) and may reorder C level statements at will as > long as the C semantics are preserved" > > I'm now running kernel 2.6.17-rc5, which included a bunch of patches > relating to v4l and i2c, and have upgraded to GCC 4.1.1. Then recompiled > the ivtv and v4l-dvb sources from svn. I'm tempting fate saying this, but > seem to be experiencing a period of stability - except for a couple of > errors around: > tveeprom 0-0050: Encountered bad packet header [ff]. Corrupt or not a > Hauppauge eeprom. > > Biggest difference I've noticed with this combination is the order the i2c > devices appear on the bus. In 2.6.16.XXX and GCC 4.1.0, they were: > Installed I2C busses: > i2c-1 unknown ivtv i2c driver #0 Algorithm unavailable > i2c-0 unknown SMBus Via Pro adapter at 5000 Algorithm > unavailable > > with 2.6.17-rc5 and GCC 4.1.1 they're: > Installed I2C busses: > i2c-1 unknown SMBus Via Pro adapter at 5000 Algorithm > unavailable > i2c-0 unknown ivtv i2c driver #0 Algorithm unavailable > > > > > _______________________________________________ > ivtv-users mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
