[linux-dvb] KNC1 DVB-C (MK3) w/ CI causes i2c_timeouts

Andy Walls awalls at radix.net
Fri May 9 05:41:33 CEST 2008

On Thu, 2008-05-08 at 19:29 +0200, Matthias Dahl wrote:
> Hi Andy.
> Sorry for the delay but I was having some hw trouble and other things kept me 
> quite busy as well (studies).
> On Sunday 04 May 2008 02:43:58 you wrote:
> > Maybe.  Given the lspci output, you may have two separate problem, that
> > are now making things noticable.
> Well I fixed the issue with the vt switch not working right after a cold 
> start. I updated the motherboard's bios to its latest revision (after which 
> it was basically brain-dead but that's a different story and fixed now -g-) 
> and the issue is gone for good. Strange as it may seem...

A buggy BIOS or bad ESCD data doesn't seem strange now that you mention

> > That means the bridge is unhappy, and it could very well be something behind
> > it, like the DVB card. 
> I tested it with the old card- it's the same there: the PCI bridge reports the 
> error condition after a cold start and those are gone after a simple reboot.
> The error from the memory controller seems strange but I doubt its really an 
> issue. The memory works just fine and I also tested both dimms seperately. It 
> also happens without the dvb card. Besides I find it strange that I get 6 
> memory controllers and one unnumbered one reported. Something can't be right 
> with that data, can it?

Most likely the ascii label given to the devices by lspci is wrong.  The
lspci command reports things from a static database which may not be
perfect as nVidia may have reused id's on functions within a highly
integrated device.  Those controllers appear to all be functions of one
highly integrated chip.  A block diagram from nVidia literature on the
chipset would probably make things clear.

> > The prefetchable addr limit upper 32 bits differ
> > on the PCI Bridge that the DVB card is behind.
> > Also no SERR is reported by this bridge any longer.
> What's responsible for setting the appropriate value? Maybe that's a clue.

The BIOS is probably responsible for basic setup of the motherboard to
get disks and usb controllers working.  Additional setup is done by the
pci drivers in the linux kernel, if I'm reading the source correctly.
Although it looks like linux may leave bridge configurations alone under
some conditions.

> One other thing. Is the tda10023 module reporting the real BER and UNC values? 
> The reason I ask is with the new card I get a constant BER and UNC of 0 with 
> QAM256 modulated channels even though there are still artefacts due to 
> transmission errors. On the other hand, if those values are correct maybe the 
> stream gets corrupted due to some other issues.

You may have complete MPEG TS packet erasures being introduced somewhere
before or after your digital tuner.  I'd think the tuner hardware
wouldn't count those as bit errors, unless it made the packet erasure

If your cable provider gets a channel via some other digital feed
subject to errors before passing it to you, then his transmission to you
may be "cleaned up" and sent without error, but his original reception
of the program may have experienced errors.

> BTW I have increased the card's latency to 64. So far I haven't had any of 
> those timeouts but I will have to do some more testing this weekend to see if 
> it's really fixed.


>  I actually hoped those timeouts were causing the stream 
> corruptions... well... can't be because I had those issues today and no 
> timeouts.
> If you have any other ideas what I could try to get to the bottom of this, 
> please let me know. Thanks a lot in advance...!

Watch the same digital channel on a dedicated television set at the same
time you watch it on your computer.  That way you can test the
hypothesis that the artifacts are introduced by your cable provider and
not in transmission to your home or playback on your computer hardware.


> Have a nice weekend,
> matthew.
> PS. I have attached some more lspci output.

More information about the linux-dvb mailing list