> > > > 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.
I disabled the onboard VIA soundcard, pulled down your code and recompiled, now (as you'll see in the attached output), the consistent "86" has magically turned into a consistent "d2"... > > > > 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. > I will try this out separately (unless you think this is a prerequisite to getting the preceding issues fixed) > > 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? > Unfortunately no. I was hoping to get a "working prototype" of a multimedia system with this old hardware, and if the wife (and less importantly, I) liked it, would upgrade to new hardware... > > > 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 also attached the full output of lspci -vvvxxx. It does show two devices with MAbort+, one of which also has 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 was able to disable the onboard sound through the BIOS configuration. let me know if you see any other VIA modules that I could safely disable. I'm a little scared that I might disable a needed module... I've attached the new lsmod output (the sound modules are not there now). > > > 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. I've attached a tar.gz file with outputs for each of the above... The first time I did the 4th item, it gave a little output (output4.txt). Then I did it again and it gave alot more output (output4.2.txt). > > > Thanks again for all your help, > > You're welcome. > > > Matt > > Regards, > Andy
output.tar.gz
Description: GNU Zip compressed data
_______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
