On Sun, 2008-07-20 at 07:36 -0700, Matt Loomis wrote: > > > > > > 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... > >
> > > > 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+. Yes the CPU host bridge and the AGP bridge. As far as I've seen, this is not unusual for most systems that have an AGP bridge with an AGP video card installed. The fact that the video card and the host CPU had an errant video data exchange since boot up is usually not enlightening. > > 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 understand. Proceed with only what you are comfortable with and if you think it will provide benefit. (No need to take risk if there's no reward.) Corrective action would usually be to cycle power, if the system hangs badly. If you are booted into single user mode, there usually aren't major things to cleanup in the filesystem. "modprobe -r" usually gripes when a module is in use and won't let you do it. I would think that a mounted disk partition would have modprobe exhibit this kind of behavior if you tried to unload a module need for your disk, etc. > I've attached the new lsmod output (the sound modules are not there > now). If you are booted into single user mode, you can likely remove (via modprobe -r) cx18 80320 0 dvb_core 69504 1 cx18 compat_ioctl32 5248 1 cx18 i2c_algo_bit 9157 1 cx18 cx2341x 13956 1 cx18 tveeprom 14852 1 cx18 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 ipv6 224901 20 nf_conntrack_ipv6,ip6t_REJECT s5h1409 11908 0 cs5345 7132 0 tuner 26056 0 floppy 52133 0 3c59x 40169 0 mii 8385 1 3c59x videodev 34432 2 cx18,tuner v4l1_compat 16260 1 videodev parport_pc 26596 0 parport 32301 1 parport_pc sr_mod 17541 0 cdrom 32865 1 sr_mod v4l2_common 12928 4 cx18,cx2341x,cs5345,tuner pcspkr 6593 0 If you don't have a USB keyboard or disk, you can modprobe -r these as well: uhci_hcd 22865 0 ohci_hcd 22725 0 ehci_hcd 32205 0 These are video card related, you can try removing these, but only in single user mode (no X windows): radeon 117345 2 drm 66009 3 radeon I'm not sure about these, most are motherboard hardware monitoring related (I think): serio_raw 8901 0 via686a 16205 0 hwmon 6493 1 via686a i2c_viapro 10965 0 button 10321 0 i2c_core 20949 8 cx18,i2c_algo_bit,tveeprom,s5h1409,cs5345,tuner,v4l2_common,i2c_viapro These are all disk related, leave them alone: sg 31733 0 dm_multipath 18505 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 > > 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 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). You can drop the "bit_test" module parameter from i2c_algo_bit. It just aborts the process early when there are problems - and right now I'd like to see the problem logs. OK, so your output4.2.txt log shows you are experiencing the essentially same symptoms as Gerhard on the users list: Jul 20 09:54:54 localhost kernel: cx18: Start initialization, version 1.0.0 Jul 20 09:54:54 localhost kernel: cx18-0: Initializing card #0 Jul 20 09:54:54 localhost kernel: cx18-0: Autodetected Hauppauge card Jul 20 09:54:54 localhost kernel: cx18-0: cx23418 revision 01010000 (B) Jul 20 09:54:54 localhost kernel: cx18-0 i2c: i2c init Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setscl: On entry CX18_REG_I2C_1_WR = 0x7 Jul 20 09:54:54 localhost kernel: cx18-0 warning: cx18_setscl: On entry read value (0x7) and previously written value (0x21c0b) upper bytes differ. Using previous value as it should be correct. Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setscl: Wrote CX18_REG_I2C_1_WR = 0x21c0b Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setscl: Readback CX18_REG_I2C_1_WR = 0x7 Jul 20 09:54:54 localhost kernel: cx18-0 warning: cx18_setscl: On exit readback value (0x7) and written value (0x21c0b) upper bytes differ Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setsda: On entry CX18_REG_I2C_1_WR = 0x7 Jul 20 09:54:54 localhost kernel: cx18-0 warning: cx18_setsda: On entry read value (0x7) and previously written value (0x21c0b) upper bytes differ. Using previous value as it should be correct. Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setsda: Wrote CX18_REG_I2C_1_WR = 0x21c0b Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setsda: Readback CX18_REG_I2C_1_WR = 0x7 Jul 20 09:54:54 localhost kernel: cx18-0 warning: cx18_setsda: On exit readback value (0x7) and written value (0x21c0b) upper bytes differ Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setscl: On entry CX18_REG_I2C_2_WR = 0x7 Jul 20 09:54:54 localhost kernel: cx18-0 warning: cx18_setscl: On entry read value (0x7) and previously written value (0x21c0b) upper bytes differ. Using previous value as it should be correct. Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setscl: Wrote CX18_REG_I2C_2_WR = 0x21c0b Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setscl: Readback CX18_REG_I2C_2_WR = 0x7 Jul 20 09:54:54 localhost kernel: cx18-0 warning: cx18_setscl: On exit readback value (0x7) and written value (0x21c0b) upper bytes differ Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setsda: On entry CX18_REG_I2C_2_WR = 0x7 Jul 20 09:54:54 localhost kernel: cx18-0 warning: cx18_setsda: On entry read value (0x7) and previously written value (0x21c0b) upper bytes differ. Using previous value as it should be correct. Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setsda: Wrote CX18_REG_I2C_2_WR = 0x21c0b Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setsda: Readback CX18_REG_I2C_2_WR = 0x7 Jul 20 09:54:54 localhost kernel: cx18-0 warning: cx18_setsda: On exit readback value (0x7) and written value (0x21c0b) upper bytes differ Readbacks from the I2C control registers almost always return 0xf or 0x7 depending on the register read. These are in fact the *exact* values that Gerhard's log show. The bad news for you is that both your sets of I2C controls registers are affected, so neither I2C bus on your HVR-1600 will work. Also later, I noticed that the I2C control registers for the second bus started returning 0xffffffff: Jul 20 09:54:56 localhost kernel: cx180 i2c: cx18_setsda: On entry CX18_REG_I2C_2_WR = 0xffffffff Jul 20 09:54:56 localhost kernel: cx18-0 warning: cx18_setsda: On entry read value (0xffffffff) and previously written value (0x21c0b) upper bytes differ. Using previous value as it should be correct. Jul 20 09:54:56 localhost kernel: cx180 i2c: cx18_setsda: Wrote CX18_REG_I2C_2_WR = 0x21c09 Jul 20 09:54:56 localhost kernel: cx180 i2c: cx18_setsda: Readback CX18_REG_I2C_2_WR = 0xffffffff Jul 20 09:54:56 localhost kernel: cx18-0 warning: cx18_setsda: On exit readback value (0xffffffff) and written value (0x21c09) upper bytes differ So even though the driver last wrote 0x21c0b, it magically changed to 0xffffffff and never recovers. This could be a bona fide PCI bus read error, which will return 0xffffffff, but there are so many of them in a row I find it really hard to believe since that pair of control registers never "recovers". Reads and writes to the first set of control registers proceed as before with no potential PCI bus read errors. So what does all that mean? Here are my guesses on causes: 1. The cx18 driver really isn't setting up the I2C hardware block of the CX23418 properly. I cannot estimate the likelyhood of that being the case, since it obviously does work for other people. I'm waiting on getting access to a datasheet for the CX23418 - until then I can't pursue this further. 2. There is a software module or hardware device that is regularly/rapidly updating the wrong section of memory (but why? kernel bug, PCI address mapping problem, or PCI address register misconfiguration?). The change in behavior when disabling the sound device gives this some plausibility. The reads from the I2C control registers for the second I2C bus changing from 0x7 and 0xf to 0xffffffff consistently also lends this some plausibility. 3. Bona fide PCI hardware problems or bus errors. I think this is very unlikely. Reading 0x7 or 0xf back is wrong for the CX23418 device, but not a bus error. Plus the values exactly match what another user is experiencing on another machine. What can you do? 1. Test with another linux distro or OS to eliminate the problem being faulty HVR-1600 hardware. 2. Test in another machine to eliminate the possibility of bad PCI hardware. 3. Test with the minimum set of kernel modules loaded as possible. If it's a kernel bug or kernel module bug, maybe we can get the offending code out of kernel space, or at least have it corrupt some other section of virtual memory space aside from where the CX23418 is mapped. 4. Compare your setup with Gerhard's to see what's common and what's not. Differential analysis can help focus in on potential bad actors. Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
