On Sun, 2008-11-09 at 14:20 -0500, sam wrote: > I upgraded my distribution/kernel to 2.6.27-7 and thought I'd give this > another try. After recompiling everything, the output is slightly > different, but seems to imply the same thing, not being able to > effectively read the eeprom. > > btw, the card I'm using is an HVR-1600 MCE, not the boxed HVR-1600. The > only noticeable hardware difference is that it comes with an fm radio > coax in. Could this card have different firmware than the stardard > model?
No. I have both an HVR-1600 and an HVR-1600MCE. Both use the same firmware. The differences are external to the CX23418 chip. (The MCE version shouldn't have an IR blaster chip on the primary I2C bus on the board, if I remember correctly.) > Via VT82C693A/694x is my mobo chipset, it's an older chipset from the > Pentium 3 era. I'm not sure of the PCI specification version, or > whether or not that's relevant. Well. Being unable to communicate with device on the I2C bus behind the CX23418 is indicative of one of two things: a device (eeprom, audio mux, dvb demodulator) on the I2C bus being "stuck", or PCI bus errors somewhere between the CPU Host bridge and the CX23418. > Latest output: > > [ 4637.395331] Linux video capture interface: v2.00 > [ 4637.530452] cx18: Start initialization, version 1.0.1 > [ 4637.534807] cx18-0: Initializing card #0 > [ 4637.534843] cx18-0: Autodetected Hauppauge card > [ 4637.535386] cx18-0 info: base addr: 0xd8000000 > [ 4637.535395] cx18-0 info: Enabling pci device > [ 4637.535423] cx18-0 info: cx23418 (rev 0) at 00:11.0, irq: 10, > latency: 64, memory: 0xd8000000 > [ 4637.535430] cx18-0 info: attempting ioremap at 0xd8000000 len > 0x04000000 > [ 4637.540494] cx18-0: cx23418 revision 01010000 (B) > [ 4637.635111] cx18-0 info: GPIO initial dir: 0000ffff/0000ffff out: > 00000000/00000000 > [ 4637.638769] cx18-0 info: activating i2c... > [ 4637.638774] cx18-0 i2c: i2c init > [ 4637.741925] cx18-0 info: Active card count: 1. > [ 4637.880753] tveeprom 1-0050: Huh, no eeprom present (err=-6)? > [ 4637.880775] tveeprom 1-0050: Encountered bad packet header [68]. > Corrupt or not a Hauppauge eeprom. > [ 4637.880783] cx18-0: Invalid EEPROM These i2c bus communications errors indicate some sort of intermittent error. If something was stuck on the i2c bus I would have expected a [00] or [ff], but not a [68]. This makes me lean toward PCI bus errors being to blame. > [ 4637.880791] cx18-0: VBI is not yet supported > [ 4637.983919] cx18-0 info: Loaded module tuner > [ 4638.027212] cx18-0 info: Loaded module cs5345 > [ 4638.027228] cx18-0 i2c: i2c client register > [ 4640.177930] cx18-0 i2c: i2c client register > [ 4640.193689] cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0) > [ 4640.664286] cx18-0 info: Allocate encoder MPEG stream: 63 x 32768 > buffers (2016kB total) > [ 4640.706714] cx18-0 info: Allocate TS stream: 32 x 32768 buffers > (1024kB total) > [ 4641.614548] cx18-0 info: Allocate encoder YUV stream: 16 x 131072 > buffers (2048kB total) > [ 4642.882948] cx18-0 info: Allocate encoder PCM audio stream: 63 x > 16384 buffers (1008kB total) > [ 4642.883199] cx18-0: Disabled encoder IDX device > [ 4642.883894] cx18-0: Registered device video0 for encoder MPEG (2 MB) > [ 4642.883905] DVB: registering new adapter (cx18) > [ 4643.579036] s5h1409_readreg: readreg error (ret == -6) This is also caused by either an i2c bus device being stuck or PCI bus errors. > [ 4643.579825] cx18-0: frontend initialization failed > [ 4643.589595] cx18-0: DVB failed to register > [ 4643.596289] cx18-0: Registered device video32 for encoder YUV (2 MB) > [ 4643.597475] cx18-0: Registered device video24 for encoder PCM audio > (1 MB) > [ 4643.598786] cx18-0: Registered device radio0 for encoder radio > [ 4643.600266] cx18-0: Error -1 registering devices > [ 4643.600311] cx18-0 i2c: i2c exit > [ 4643.601747] cx18-0 i2c: i2c client detach > [ 4643.601761] cx18-0 i2c: i2c detach [client=cs5345,ok] > [ 4643.602557] cx18-0 info: releasing enc_mem > [ 4643.604143] cx18-0: Error -1 on initialization > [ 4643.604161] cx18-0 info: retried_write[0] = 16935 > [ 4643.604166] cx18-0 info: retried_write[1] = 0 > [ 4643.604171] cx18-0 info: retried_write[2] = 0 > [ 4643.604175] cx18-0 info: retried_write[3] = 0 > [ 4643.604179] cx18-0 info: retried_write[4] = 0 > [ 4643.604183] cx18-0 info: retried_write[5] = 0 > [ 4643.604188] cx18-0 info: retried_write[6] = 0 > [ 4643.604192] cx18-0 info: retried_write[7] = 0 > [ 4643.604196] cx18-0 info: retried_write[8] = 0 > [ 4643.604200] cx18-0 info: retried_write[9] = 0 > [ 4643.604205] cx18-0 info: retried_write[10] = 627 Given the version of driver I can tell you are using, those are about 626 more failed writes than I would have expected. When something gets logged in "retried_write[10]" it means the driver tried to write something to a CX23418 register and read back an expected result 10 times without it succeeding. Again, it could be PCI bus errors or something stuck on the i2c bus. So: 1. If you've tried adding very long (~100 msec) reset delays in cx18-cards.c and cx18-i2c.c, you've likely eliminated a device on the i2c bus being stuck. 2. You could try upping CX18_MAX_MMIO_WR_RETRIES in cx18-driver.h, but given that either the write works or never does right now, I'm not hopeful for that working. 3. You could also try setting the mmio_ndelay parameter to 152 or 243, but I doubt it will help. Could you send the output of lspci -vvnn run as root? I suspect that a PCI bridge in subtractive decode is "grabbing" the failed write to the CX23418 and giving the cx18 driver a value from another device (like a legacy ISA device behind a PCI-ISA bridge in subtractive decode). 4. In fact, if you have legacy devices enabled in your BIOS that you aren't using, it may be worth a try to turn them off in the BIOS. 5. You may also want to try a different PCI slot or blowing any dust out of the slot the card is in. All of that is a bit lame I know, but I'm not sure what in the cx18 driver can be done right now to cure your problem. In the long run I hope to replace bit-banging I2C with CX23418 hardware mastered I2C, but PCI bus errors would still plague other operations. Windows and Linux set up the PCI bridges and devices differently, having the card working in Windows eliminates a bad card, but doesn't help figure out what's the problem on the PCI bus. 6. Obviously you could try a linux system with a more modern motherboard. I hope something above helps. Regards, Andy > [ 4643.604209] cx18-0 info: retried_read[0] = 8246 > [ 4643.604214] cx18-0 info: retried_read[1] = 0 > [ 4643.604218] cx18-0 info: retried_read[2] = 1102 > [ 4643.610691] cx18: probe of 0000:00:11.0 failed with error -1 > [ 4643.612024] cx18: End initialization > > > On Sun, 2008-10-26 at 20:07 -0400, Andy Walls wrote: > > On Sun, 2008-10-26 at 12:30 -0400, sam wrote: > > > Thanks for the response. > > > > > > Here is everything between the start and end of the cx18 initialization, > > > including a few seemingly irrelevant entries just in case. > > > > > > [ 47.395294] cx18: Start initialization, version 1.0.1 > > > [ 47.395465] cx18-0: Initializing card #0 > > > [ 47.395474] cx18-0: Autodetected Hauppauge card > > > [ 47.395905] cx18-0: cx23418 revision 01010000 (B) > > > [ 47.892914] tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# > > > 1825556 > > > [ 47.892926] tveeprom 1-0050: MAC address is 00-0D-FE-1B-DB-14 > > > [ 47.892932] tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, > > > type 43) > > > [ 47.892939] tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08) > > > [ 47.892945] tveeprom 1-0050: audio processor is CX23418 (idx 38) > > > [ 47.892950] tveeprom 1-0050: decoder processor is CX23418 (idx 31) > > > [ 47.892955] tveeprom 1-0050: has radio > > > [ 47.892961] cx18-0: Autodetected Hauppauge HVR-1600 > > > [ 47.892966] cx18-0: VBI is not yet supported > > > [ 48.657268] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 > > > [ 48.864454] eth1: link up, 10Mbps, half-duplex, lpa 0x0000 > > > [ 48.895902] eth1: link down > > > [ 49.540757] usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto > > > 2 vid 0x03F0 pid 0xB402 > > > [ 49.540822] usbcore: registered new interface driver usblp > > > [ 49.687630] eth1: link up, 10Mbps, half-duplex, lpa 0x0000 > > > [ 49.698112] tuner 2-0043: chip found @ 0x86 (cx18 i2c driver #0-1) > > > [ 49.791974] eth1: link down > > > [ 50.085526] tda9887 2-0043: creating new instance > > > [ 50.085537] tda9887 2-0043: tda988[5/6/7] found > > > [ 50.087385] tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) > > > [ 50.087434] cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0) > > > [ 50.199493] eth1: link up, 10Mbps, half-duplex, lpa 0x0000 > > > [ 50.228825] eth1: link down > > > [ 50.461207] NET: Registered protocol family 10 > > > [ 50.461772] lo: Disabled Privacy Extensions > > > [ 50.511323] tuner-simple 2-0061: creating new instance > > > [ 50.511338] tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 > > > (FM1236MK3 or FM1236/F)) > > > [ 50.513447] cx18-0: Disabled encoder IDX device > > > [ 50.513582] cx18-0: Registered device video0 for encoder MPEG (2 MB) > > > [ 50.513591] DVB: registering new adapter (cx18) > > > [ 50.567843] NET: Registered protocol family 17 > > > [ 50.583395] eth1: link up, 10Mbps, half-duplex, lpa 0x0000 > > > [ 50.688056] eth1: link down > > > [ 50.759804] s5h1409_readreg: readreg error (ret == -121) > > > [ 50.759912] cx18-0: frontend initialization failed > > > [ 50.760281] cx18-0: DVB failed to register > > > [ 50.760358] cx18-0: Registered device video32 for encoder YUV (2 MB) > > > [ 50.760397] cx18-0: Registered device video24 for encoder PCM audio > > > (1 MB) > > > [ 50.760438] cx18-0: Registered device radio0 for encoder radio > > > [ 50.760880] cx18-0: Error -1 registering devices > > > [ 50.761002] tda9887 2-0043: destroying instance > > > [ 50.761046] tuner-simple 2-0061: destroying instance > > > [ 50.761945] cx18-0: Error -1 on initialization > > > [ 50.761970] cx18: probe of 0000:00:0f.0 failed with error -1 > > > [ 50.762010] cx18: End initialization > > > > > > > > > This appears to be where it fails: > > > > > > [ 50.759804] s5h1409_readreg: readreg error (ret == -121) > > > > -121 is -EREMOTEIO which happens when the I2C subsystem fails to > > transfer data from a device. So OK, you do have an error similar to the > > I2C errors other had, but this one is different. > > > > The s5h1409, eeprom, and cs5345 audio digitizer/mux chips are all hooked > > up to the same I2C bus. The EEPROM and CS5345 were read and initialized > > properly in the output you gave above - so the I2C bus was working. > > > > My guesses now are: > > > > 1. The CX24227 (aka S5H1409) chip didn't get reset properly, or > > > > 2. The PCI bus on your system is so busy at the moment (eth1 going up > > and down repeatedly) that communications with the CX23418 fail despite > > the maximum 10 retries on each access to the chip. > > > > > > So here are some things to try: > > > > 1. In /etc/modprobe.d/options (or you distribution's equivalent) add > > > > options cx18 debug=67 > > options s5h1409 debug=1 > > > > This will turn on info, warning, and i2c debugging in cx18. When the > > cx18 module fails to load, it will also log statistics about read and > > write retries - I would like to see those statistics and the additional > > messages. (I'll only have two-way comms by irc this week though, but I > > will have read only e-mail access.) > > > > The s5h1409 debug messages will just log what functions the module is > > walking through. > > > > > > 2. Blacklist the cx18 module in /etc/modprobe.d/blacklist (or your > > distribution's equivalent) and modprobe it some time later in the boot > > process or manually after boot. Maybe once the PCI bus isn't so busy > > with the disk accesses and eth1 going up and down, things will succeed. > > If this is the case, you may want to increase CX18_MAX_MMIO_RETRIES in > > cx18-driver.h to a number larger than 10. > > > > 3. Change the three 'mdelay(10);' calls in cx18-i2c to 'mdelay(100);' > > and change the '.msecs_asserted = 10,' and '.msecs_recovery = 40,' in > > cx18-cards.c both to 100 as well. This should ensure the CX24227 (aka > > S5H1409) gets enough time to be reset. If those work, try to narrow > > down and pare down to exactly which values you need changed and what > > values to use. > > > > > > > find / -name *s5h1409* reveals: > > > > > > /lib/modules/2.6.24-19-generic/kernel/drivers/media/dvb/frontends/s5h1409.ko > > > /lib/modules/2.6.24-21-generic/kernel/drivers/media/dvb/frontends/s5h1409.ko > > [snip] > > > > As long as one of these is in a directory that matches you kernel, you > > should be fine. In fact, since the module loaded and spit out an error > > message, things are probably fine. > > > > > > > find / -name *mxl5005s* reveals: > > > > > > /lib/modules/2.6.24-21-generic/kernel/drivers/media/common/tuners/mxl5005s.ko > > > > As long as you use a 2.6.24-21-generic kernel as shown by uname, this > > should be fine. > > > > > > > Could something be in the wrong place? > > > > Unlikely, as long as uname and the module directory agree on the running > > kernel version. > > > > > > Regards, > > Andy > > > > > > > > On Sat, 2008-10-25 at 13:23 -0400, Andy Walls wrote: > > > > On Fri, 2008-10-24 at 16:08 -0400, sam wrote: > > > > > So I've searched all over the net, and I'm basically stumped. > > > > > > > > > > I followed the directions here > > > > > (http://www.mythtv.org/wiki/index.php/Hauppauge_HVR-1600) for > > > > > compiling > > > > > and installing the cx-18 driver for use with hvr-1600. I'm using > > > > > ubuntu > > > > > feisty. > > > > > > > > > > Here's the ouput of dmesg | grep cx-18: > > > > > > > > > > [ 47.395294] cx18: Start initialization, version 1.0.1 > > > > > [ 47.395465] cx18-0: Initializing card #0 > > > > > [ 47.395474] cx18-0: Autodetected Hauppauge card > > > > > [ 47.395905] cx18-0: cx23418 revision 01010000 (B) > > > > > [ 47.892961] cx18-0: Autodetected Hauppauge HVR-1600 > > > > > [ 47.892966] cx18-0: VBI is not yet supported > > > > > [ 49.698112] tuner 2-0043: chip found @ 0x86 (cx18 i2c driver #0-1) > > > > > [ 50.087385] tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) > > > > > [ 50.087434] cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0) > > > > > [ 50.513447] cx18-0: Disabled encoder IDX device > > > > > [ 50.513582] cx18-0: Registered device video0 for encoder MPEG (2 > > > > > MB) > > > > > [ 50.513591] DVB: registering new adapter (cx18) > > > > > [ 50.759912] cx18-0: frontend initialization failed > > > > > [ 50.760281] cx18-0: DVB failed to register > > > > > [ 50.760358] cx18-0: Registered device video32 for encoder YUV (2 > > > > > MB) > > > > > [ 50.760397] cx18-0: Registered device video24 for encoder PCM audio > > > > > (1 MB) > > > > > [ 50.760438] cx18-0: Registered device radio0 for encoder radio > > > > > [ 50.760880] cx18-0: Error -1 registering devices > > > > > [ 50.761945] cx18-0: Error -1 on initialization > > > > > [ 50.761970] cx18: probe of 0000:00:0f.0 failed with error -1 > > > > > [ 50.762010] cx18: End initialization > > > > > > > > Please provide the full output (don't grep on cx18) between "cx18: Start > > > > initialization" and "cx18: End initialization" > > > > > > > > Given the grepped output above, everything appears to be OK with the > > > > analog side of the card. The DVB (ATSC) initialization for digital > > > > video failed in linux/drivers/media/video/cx18/cx18-dvb.c:dvb_register() > > > > at about line 291. > > > > > > > > (BTW, I need to fix the return value of -1 to something more meaningful. > > > > -1 is -EPERM, "operation not permitted" which is the wrong error code > > > > here.) > > > > > > > > > > > > > This seems a little bit similar to the "invalid EPROM" errors people > > > > > were getting, > > > > > > > > But it's not, AFAICT. > > > > > > > > My suspicions are either that you don't have the s5h1409 and mxl5005s > > > > modules built and installed, or you have disabled dynamic loading of > > > > modules upon kernel request somehow. > > > > > > > > > > > > > however I tried the fix (reloading cx-18 with mmio_ndelay > > > > > 31) with no success. I'd appreciate any help. > > > > > > > > > > > > With the cx18 driver v1.0.1 default setting of retry_mmio=1 being set, > > > > mmio_ndelay has a vanishingly small effect. Don't bother with it. It > > > > won't help, nor do you have the specific problem with which it could > > > > help, AFAICT. > > > > > > > > Regards, > > > > Andy > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
