> > > > 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.
>
Ok, so I swapped in a hard drive with W2k on it, and tried use what I though
were old Win2k versions of drivers for the card... It didn't work, but I
probably wasn't doing something right.
More importantly, I then installed WinXP and used the drivers that came on the
CD with the card. Success!!! I had also went into the BIOS and did a "use
fail-safe defaults". I wasn't sure if using XP or the BIOS changes fixed it...
So I booted back up the Linux hard drive, but still nothing. Got the same
corrupt tveeprom message (although I think it had yet another different value,
like 0xc2 or something...)
So this at least rules out faulty haupauge card, and other hardware. I was
able to watch the analog and digital TV broadcasts, and tune in the radio.
What I'm assuming were lower resolution digital broadcasts looked just fine,
however I think my piddly 800Mhz CPU started choking when I watched the real
high-res channels, as it was maxed out and kept dropping frames and jerking
ahead a half second or so...
I think I'll forge ahead for now running XP, and see how we like the PVR
functionality overall. If I get the thumbs up from the wife, I'll sink some
money into some "real" hardware and start all over again. Maybe by then you'll
have access to the data sheets (just out of curiosity, whats holding that
process up? proprietary reasons? busy Haupauge developers? you (absolutely
understandably so) not having enough time to donate to the project?)
Anyway, another piece of the puzzle for ya'. Thanks for all the help, and I'd
still gladly try other tests for you if it helps out the overall effort. Let
me know if you want me to try something specific out in light up my recent
discoveries.
Thanks!
-Matt
> 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
