Matt, I'm copying the ivtv-devel list (and ivtv-users list just this once) to get this discussion on the list.
On Tue, 2008-07-15 at 18:18 -0700, Matt Loomis wrote: > Andy, > > Pulled your latest repository and it's compiling all 264 mods now. > Not sure if it was my end or the code end... anyway, looking better > now. > > > I modified cx18-cards.c in the following way (in both places where I found > .msecs_... code) : > > //.msecs_asserted = 10, > //.msecs_recovery = 40, > .msecs_asserted = 100, > .msecs_recovery = 100, > > I modified cx18-i2c.c in the following way (only one place I found mdelays() > code) : > > write_reg_sync(0x00c00000, 0xc7001c); > // mdelay(10); > mdelay(100); > write_reg_sync(0x00c000c0, 0xc7001c); > // mdelay(10); > mdelay(100); > write_reg_sync(0x00c00000, 0xc7001c); > // mdelay(10); > mdelay(100); > > > I hope this was the code changes you were referring too... > > I then did a "make", "make install", "make unload", and "modprobe cx18". > > This is what I got in dmesg: > > cx18: Start initialization, version 1.0.0 > cx18-0: Initializing card #0 > cx18-0: Autodetected Hauppauge card > cx18-0: cx23418 revision 01010000 (B) > tveeprom 1-0050: Huh, no eeprom present (err=-121)? > tveeprom 1-0050: Encountered bad packet header [86]. Corrupt or not a > Hauppauge eeprom. > cx18-0: Invalid EEPROM -121 => -EREMOTEIO: I2C bus problems with the CX23418 trying to talk to the EEPROM chip. The "86" is interesting, I haven't seen that before. A "00" would indicate one of the slaves on the I2C bus holding the data line low; this is some other sort of problem. > cx18-0: VBI is not yet supported > cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0) > cx18-0: Disabled encoder IDX device > cx18-0: Registered device video0 for encoder MPEG (2 MB) > DVB: registering new adapter (cx18) > s5h1409_readreg: readreg error (ret == -121) Another -EREMOTEIO. This may be new. Usually by the time the cs5345 is initialized, the I2C bus has cleared up and comms with the cx24227 (aka s5h1409) work. (The CX23418 has 2 I2C busses. On the HVR-1600, only the two analog tuner chips (mixer/oscillator and IF demodulator) are on the second bus. The EEPROM, CS5345 audio mux, Zilog Z8F0811 IR microcontroller, MXL5005 tuner, and CX24227 digital TV demodulator are all on the first I2C bus.) The above symptoms indicate to me that the I2C bus on your HVR-1600 does not have a "stuck" slave. That leaves the CX23418 and the PCI bus and PCI bridges as potential points of failure. > cx18-0: frontend initialization failed > cx18-0: DVB failed to register > cx18-0: Registered device video32 for encoder YUV (2 MB) > cx18-0: Registered device video24 for encoder PCM audio (1 MB) > cx18-0: Registered device radio0 for encoder radio > cx18-0: Error -12 registering devices > cx18-0: Error -12 on initialization > cx18: probe of 0000:00:09.0 failed with error -12 I believe this is -ENOMEM. You may want to try adding a "vmalloc=256M" to your kernel command line to see if that fixes the problem. > cx18: End initialization > > > > Here's the lsmod output: > Module Size Used by > cx18 77632 0 > tveeprom 14852 1 cx18 > s5h1409 11908 0 > cs5345 7132 0 > tuner 26056 0 > dvb_core 69504 1 cx18 > videodev 34432 2 cx18,tuner > v4l1_compat 16260 1 videodev > compat_ioctl32 5248 1 cx18 > cx2341x 13956 1 cx18 > v4l2_common 12928 4 cx18,cs5345,tuner,cx2341x > rfcomm 33105 0 > l2cap 22721 9 rfcomm > bluetooth 48165 4 rfcomm,l2cap > autofs4 20933 2 > sunrpc 151777 3 > nf_conntrack_ipv4 11717 3 > ipt_REJECT 7105 2 > iptable_filter 6721 1 > ip_tables 14033 1 iptable_filter > nf_conntrack_ipv6 16469 3 > xt_state 6209 6 > nf_conntrack 50453 3 nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state > xt_tcpudp 6977 10 > ip6t_ipv6header 6209 2 > ip6t_REJECT 7745 2 > ip6table_filter 6593 1 > ip6_tables 15057 2 ip6t_ipv6header,ip6table_filter > x_tables 15557 7 > ipt_REJECT,ip_tables,xt_state,xt_tcpudp,ip6t_ipv6header,ip6t_REJECT,ip6_tables > dm_multipath 18505 0 > radeon 117345 2 > drm 66009 3 radeon > ipv6 224901 20 nf_conntrack_ipv6,ip6t_REJECT > snd_via82xx 25177 3 > gameport 14029 1 snd_via82xx > snd_ac97_codec 92257 1 snd_via82xx > ac97_bus 5825 1 snd_ac97_codec > snd_seq_dummy 6853 0 > snd_seq_oss 29633 0 > snd_seq_midi_event 9921 1 snd_seq_oss > snd_seq 44913 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event > serio_raw 8901 0 > 3c59x 40169 0 > pcspkr 6593 0 > snd_pcm_oss 37441 0 > floppy 52133 0 > snd_mixer_oss 16577 2 snd_pcm_oss > mii 8385 1 3c59x > snd_pcm 61637 3 snd_via82xx,snd_ac97_codec,snd_pcm_oss > i2c_algo_bit 9157 1 cx18 > snd_timer 21065 2 snd_seq,snd_pcm > snd_page_alloc 11337 2 snd_via82xx,snd_pcm > snd_mpu401_uart 10177 1 snd_via82xx > via686a 16205 0 > hwmon 6493 1 via686a > snd_rawmidi 21441 1 snd_mpu401_uart > snd_seq_device 9933 4 snd_seq_dummy,snd_seq_oss,snd_seq,snd_rawmidi > snd 44517 15 > snd_via82xx,snd_ac97_codec,snd_seq_oss,snd_seq,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device > button 10321 0 > i2c_viapro 10965 0 > soundcore 9633 2 snd > i2c_core 20949 8 > cx18,tveeprom,s5h1409,cs5345,tuner,v4l2_common,i2c_algo_bit,i2c_viapro > parport_pc 26596 0 > parport 32301 1 parport_pc > sr_mod 17541 0 > cdrom 32865 1 sr_mod > sg 31733 0 > dm_snapshot 18661 0 > dm_zero 5825 0 > dm_mirror 25541 0 > dm_mod 49321 9 dm_multipath,dm_snapshot,dm_zero,dm_mirror > pata_acpi 8641 0 > pata_via 12229 2 > ata_generic 9285 0 > libata 126544 3 pata_acpi,pata_via,ata_generic > sd_mod 25817 3 > scsi_mod 121965 4 sr_mod,sg,libata,sd_mod > ext3 109897 2 > jbd 41045 1 ext3 > mbcache 10309 1 ext3 > uhci_hcd 22865 0 > ohci_hcd 22725 0 > ehci_hcd 32205 0 The modules look OK. The VIA chipset causes me some concern. VIA chipsets have a bad reputation of not working well the CX23415/6 chips. I'm wondering if that is true for CX23418 chips. Do you have another, non-VIA based motherboard you can test the card in? > Nothing changes in dmesg if I do a "rmmod tveeprom", "rmmod cx18", "modprobe > tveeprom debug=1" and "modprobe cx18" Too bad. BTW, I use "modprobe -r cx18" instead of rmmod. > Here's the video card portion of a "lspci -vvvxxx" > > 00:09.0 Multimedia video controller: Conexant CX23418 Single-Chip MPEG-2 > Encoder with Integrated Analog Video/Broadcast Audio Decoder > Subsystem: Hauppauge computer works Inc. Unknown device 7444 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 64 (500ns min, 50000ns max), Cache Line Size: 32 bytes > Interrupt: pin A routed to IRQ 5 > Region 0: Memory at dc000000 (32-bit, non-prefetchable) [size=64M] > Capabilities: [44] Vital Product Data <?> > Capabilities: [4c] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Kernel modules: cx18 > 00: f1 14 7a 5b 06 00 90 02 00 00 00 04 08 40 00 00 > 10: 00 00 00 dc 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 70 00 44 74 > 30: 00 00 00 00 44 00 00 00 00 00 00 00 05 01 02 c8 > 40: 7b 1f 00 01 03 4c 00 00 00 00 00 00 01 00 22 00 > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 It would be interesting to note if any devices on the PCI(-e) bus have a "Status:" with TAbort+ MAbort+ SERR+ or PERR+ . > I have 2 video cards (one AGP, one really simple PCI) and a network > card on my pci bus. However I've tried taking all of them out except > for the simple video card with no luck... Instead of removing hardware, you can also try unloading modules for the sound card, etc.. This let you try to eliminate PCI devices integrated onto the motherboard. (Don't unload your disk controller modules obviously.) > I think that's all the info you asked for (plus some you didn't)... > > I pulled your repository by download the Mercurial package, and doing > a "hg clone http://.....";. How do I update that code with the latest > changes? Do I do a "hg pull" in that directory? hg pull hg update (or hg merge and hg commit if hg tells you to do so) I have added the following changes to my repo at http://linuxtv.org/hg/~awalls/cx18-i2c 1. Made the reset delays really long (250 msec each). 2. Made changes to cx18-i2c.c set/get_sda/scl() to have verbose debug logging and be robust against some PCI bus errors. Id recommend testing revised cx18 module by loading it in a few different ways: 1. without debugging enabled 2. with tveeprom debugging 3. with tveeprom and i2c_algo_bit debugging 4. with tveeprom, i2c_algo_bit, and "cx18 debug=321" debugging. The 4th one will give you several lines of log messages for every bit transition on the I2C bus and thus generates a lot of output. It will be too much for the dmesg ring buffer, but it should be captured in /var/log/messages (with an occasional syslog fomatting glitch). The expanded logging will at least tell me if certain types of PCI bus errors are to blame. > Thanks again for all your help, You're welcome. > Matt Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
