awalls at md
Dec 5, 2010, 1:26 PM
Post #5 of 6
Thanks for the follow-up report. :)
On Sun, 2010-12-05 at 07:54 -0600, Josh Restivo wrote:
> Andy - thanks for the excellent speculation!
You're welcome. (But I now wonder what metrics and criteria should be
applied to measure the "goodness" of speculation. ;)
> Follow-up: Frustration got the best of me after being unable to obtain
> any useful debug output from the tveeprom and cx18 drivers. I
> reinstalled, going from ubuntu 10.10 proper to mythbuntu 10.10. Upon
> reinstall, symptoms went from every channel locking in the mythtv
> scanner to no channels locking. On a lark, I switched to the nouveau X
> driver from the proprietary nvidia driver (the stock nv driver didn't
> seem to like the HDMI output on my card). Upon doing so, I was finally
> able to obtain expected output from the analog portion of the card and
> the mythtv channel scan completed successfully.
OK, good to know.
There is a kernel bug somewhere that is trashing a portion of the
CX23418 registers and on-card RAM. That's a 64 MB region in vmalloc
address space, that nothing but the cx18 driver should be reading or
This explanation is consistent with Dale Pontius' occasional red screen
problem after boot up, if we assume things in the kernel occasionally
get initialized or allocated in a different order on boot up.
It could be a bug in the kernel memory allocator or virtual memory
mapping (doubtful) or a bug in some other driver in the kernel (more
likely). Although I would like to blame the nv driver, we can't know
for sure it is the culprit, since *any* code in kernel address space
could be at fault.
One may be able to trap kernel writes to the addresses shown in
# cat /proc/iomem | grep cx18
and check if the cx18 driver did it or something else.
The in kernel MMIO trace could be used and looking at the "Map ID" that
accesses the CX23418 IO region, and then convert that "MAP ID" back to
the driver that created the IO mapping. But the Kernel MMIO tracer
would have to be started before any of the suspected culprit device
drivers are started:
I'm not sure how much of that is actually possible.
> I'd be curious to know if a switch to the nouveau driver rectifies
> this issue for anyone else.
Do you use Ubuntu and/or the nv driver in your machine?
> josh restivo
> On Sat, Dec 4, 2010 at 2:04 PM, Andy Walls <awalls [at] md> wrote:
> > On Fri, 2010-12-03 at 20:47 -0800, joshr wrote:
> >> AMD64, 2.6.35-23 (ubuntu), hvr1600 w/ TCL M30WTP-4N-E tuner
> >> OTA Digital works great out-of the-box. Analog has been a pita though. I've
> >> tried forcing the tuner to a known working channel and dumped the mpeg
> >> stream to a file for review. Everything turns up with a blank red screen.
> >> Tried setting vmalloc=256M just for fun (it didn't seem to be a necessity)
> >> but same results. Using mythtv's channel scanner, every single channel
> >> scanned locks and is added to the database. Not even the channels that
> >> should be working show up in LiveTV, though - just blank red screen. There
> >> is no cable box involved here and the cable works just fine otherwise.
> >> Thoughts? Suggestions? Wild speculation?
> > This has been reported before, but there is no known solution.
> > <speculation type=mild>
> > Either the CX23418's intergrated '843 Audio/Video decoder isn't
> > converting the analog signals into video and audio properly, or the
> > video data isn't successfuly getting written into the DDR RAM on the
> > HVR-1600.
> > </speculation>
> > <speculation type=wild>
> > The root cause may be:
> > - some PCI bus errors during driver load that messes up the setup of the
> > CX23418's A/V decoder or RAM controller.
> > - you have a marginal or defective HVR-1600 or something about your
> > systems' PCI bus or power is marginal.
> > - some kernel bug somewhere trashing the the CX23418 register space.
> > </speculation>
> > If the problem is reliably reproducable you could:
> > 1. Try the HVR-1600 in a Windows box to see if it is defective
> > 2. Try the HVR-1600 under Windows on the problem machine
> > 3. Remove all uneeded PCI cards and USB devices, and see if it works
> > when there is less power draw by peripherials.
> > 4. ensure you're not using the closed source drivers with your kernel.
> > The CX23418 register space is 32 MB, That's a big target in kernel
> > space for a kernel or driver bug to hit with an errant stray write.
> > Those are just suggestions. None are guaranteed to be sane or make
> > anything better.
> > You can dump the cx23418's '843 register space (from 0x0 - 0x9ff) with
> > v4l2-dbg. However IIRC, the last time someone provided that for the red
> > screen problem, all the '843 registers looked OK.
> > Regards,
> > Andy
ivtv-users mailing list
ivtv-users [at] ivtvdriver