Bug 753277

Summary: HVR-4000 is broken in F16 - probably upstream
Product: [Fedora] Fedora Reporter: Jon S <jonathanjstevens>
Component: kernelAssignee: Mauro Carvalho Chehab <mchehab>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: gansalmon, hektor, itamar, jonathan, kernel-maint, lwang, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-22 21:12:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
set debug on driver as requested, output of dmesg | grep cx >> logfile
none
dmesg after boot
none
/var/log/message gzipped none

Description Jon S 2011-11-11 18:39:47 UTC 
Description of problem:

Support for Hauupauge HVR-4000 appears to be broken (again) in kernel.
This is a bit of a tale of woe, but this hardware is supposed to have been sorted in kernel 3.0.
Stock f16 kernel cannot scan or tune in mythtv, kaffeine, w_scan, or dvbscan.
Compiled/Installed latest video-media build still no joy.
I used another USB DVB (nova-t) to scan, and using the results obtained from w_scan on this managed to get tzap to FE LOCK. However this only worked with tzap - no other app can get a lock. 

Have tested with i2c reset patch enabled and not, and also with strobing patch enabled and not (cs88-dvb.c). Also with mythtv kludge (delaying on FE close in dvbutils.cpp). All make no difference.

So sad :(


Version-Release number of selected component (if applicable):

Linux mythtvtuner.home 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1 21:10:48 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux


How reproducible:

Install F16 and try to make use of HVR-4000.


Steps to Reproduce:
1. Install F16 on a machine with HVR-4000
2. Try to use it
3. Cry
  
Actual results:

Can't scan or tune.

Expected results:

Can scan and tune and be happy.

Additional info:

Should mention this machine is also running Xen.

If necessary I have a spare machine I can put a HVR-4000 into and can compile whatever you want to try to fix this. Pretty sure this is a problem upstream in video-media, but will report here to try and get some help!
Willing to put in the hours this side to get to the bottom of this.
All the problems historically that the HVR-4000 has had in v4l were supposed to be fixed in 3.0... 
Let me know what additional info you might want?
Comment 1 Jon S 2011-11-13 21:55:50 UTC 
I should add, I've discovered this only occurs when running on Xen. 

It occurs in dom0 (I'm not trying anything fancy like PCI Passthru).

I've found a similar bug report 

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1786

but the "fix" in that report is prior to the kernel version running in F16.

I have messaged the Xen dev list hoping they can help as there do seem to be a few reports of PCI tuner cards not working properly under xen.
Comment 2 Mauro Carvalho Chehab 2011-11-16 12:43:44 UTC 
(In reply to comment #1)
> I should add, I've discovered this only occurs when running on Xen. 
> 
> It occurs in dom0 (I'm not trying anything fancy like PCI Passthru).
> 
> I've found a similar bug report 
> 
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1786

The bug there seems to be related to some bug in Xen code, as the first description says that non-Xen kernel works.

Please load the drivers with the debug options enabled, run scan and post the dmesg logs at the BZ.
Comment 3 Jon S 2011-11-16 14:18:48 UTC 
OK. How do I load the drivers with the debug options enabled? Is this something that needs to be done at compile time?
Comment 4 Mauro Carvalho Chehab 2011-11-16 15:00:22 UTC 
(In reply to comment #3)
> OK. How do I load the drivers with the debug options enabled? Is this something
> that needs to be done at compile time?

No need to re-compile the drivers. All you need it to tell modprobe to use debug.

For cx88, all you need to do is to add:

options cx88xx core_debug=3

at some (new) file under /etc/modprobe.d

and re-load the drivers (or reboot the machine).

Eventually, you may need to enable other debug options for other drivers that your video capture board may need.
Comment 5 Jon S 2011-11-16 16:55:41 UTC 
Created attachment 534054 [details]
set debug on driver as requested, output of dmesg | grep cx >> logfile

dmesg | grep cx
Comment 6 Mauro Carvalho Chehab 2011-11-16 19:17:06 UTC 
The debug is incomplete. It doesn't show device initialization, or DVB-related logs. It is probably a good idea to rotate your log file, and attach it instead.
Comment 7 Jon S 2011-11-16 20:16:27 UTC 
Um.. yes.. sorry!

I'm sure Fedora used to create a dmesg log file, but doesn't seem to now. I'll go find out how to restart that (or where it's putting it) and get back to you.
Comment 8 Jon S 2011-11-16 22:40:42 UTC 
Created attachment 534122 [details]
dmesg after boot

dmesg from boot
Comment 9 Jon S 2011-11-16 22:42:56 UTC 
Created attachment 534123 [details]
/var/log/message gzipped

/var/log/messages - quite long.
Comment 10 Mauro Carvalho Chehab 2011-11-16 23:15:10 UTC 
Could you please test it on a non-Xen kernel?
Comment 11 Jon S 2011-11-17 09:31:40 UTC 
Mauro, 

Not quite sure what you mean? Are you asking me to:

a) run the same kernel without the xen-hypervisor running and get the same diags?

or

b) run a kernel without xen support (i.e. an earlier kernel)? If so things get a bit complicated with this card, the kernel module fixes that make this card work properly coincide (more or less) with the introduction of full xen support in the kernel.
Comment 12 Jens Hektor 2011-11-19 06:49:26 UTC 
I have also a F16 with a HVR 4000 but no XEN active.

The problem for me is that kaffeine does not display the TV image or prduce
sound, but is very well doing the recording, so receiving the signal and also
EPG works, but Video/Audio does not work.

The recordings are fine and can be played with vlc or something similar.

Just my 2ยข.
Comment 13 Jon S 2011-11-19 10:14:44 UTC 
> The problem for me is that kaffeine does not display the TV image or prduce
> sound, but is very well doing the recording, so receiving the signal and also
> EPG works, but Video/Audio does not work

I believe it's necessary to install additional libraries, try

xine-lib and xine-lib-extra (*guess*)
Comment 14 Mauro Carvalho Chehab 2011-11-19 16:18:54 UTC 
(In reply to comment #11)
> Mauro, 
> 
> Not quite sure what you mean? Are you asking me to:
> 
> a) run the same kernel without the xen-hypervisor running and get the same
> diags?
> 
> or
> 
> b) run a kernel without xen support (i.e. an earlier kernel)? If so things get
> a bit complicated with this card, the kernel module fixes that make this card
> work properly coincide (more or less) with the introduction of full xen support
> in the kernel.

Well, we need to identify if the issues are due to XEN patches or due to something broken at the device driver. If the issue is due to XEN (like the BZ# you pointed at xensource), then I can't help on it, as I'm not familiar with Xen tricks to remap i/o and dma.



(In reply to comment #12)
> I have also a F16 with a HVR 4000 but no XEN active.
> 
> The problem for me is that kaffeine does not display the TV image or prduce
> sound, but is very well doing the recording, so receiving the signal and also
> EPG works, but Video/Audio does not work.

If the device is capturing with XEN inactive, it seems that the driver is OK.
It is likely some bug at the XEN patches. Maybe Xen was not able to allocate enough memory for DMA, or is mapping it wrong.
Comment 15 Jon S 2011-11-19 16:42:29 UTC 
If I boot without the hypervisor then all works perfectly (first time ever with a stock kernel and the HVR-4000).

It's almost certainly a Xen thing, and I think you're right about the DMA bit (from some of the digging I have done). I have also raised this on the xen-devel list, and some of the debugs done for that seem to indicate an issue. It looks very much like the tuning occurs OK, but the streams can't be accessed.
Comment 16 Jens Hektor 2011-11-20 05:03:23 UTC 
>> The problem for me is that kaffeine does not display the TV image or prduce
>> sound, but is very well doing the recording, so receiving the signal and also
>> EPG works, but Video/Audio does not work

>I believe it's necessary to install additional libraries, try
>xine-lib and xine-lib-extra (*guess*)


pretty good guess. xine-lib and xine-lib-extra were already installed, but
xine-lib-extras-freeworld (rpmfusion-free) did the trick. Thanks for the hint.

o-o (no Xen here)
Comment 17 Mauro Carvalho Chehab 2011-11-20 10:19:53 UTC 
(In reply to comment #15)
> If I boot without the hypervisor then all works perfectly (first time ever with
> a stock kernel and the HVR-4000).
> 
> It's almost certainly a Xen thing, and I think you're right about the DMA bit
> (from some of the digging I have done). I have also raised this on the
> xen-devel list, and some of the debugs done for that seem to indicate an issue.
> It looks very much like the tuning occurs OK, but the streams can't be
> accessed.

Not actually looked at Xen patches, but it probably uses some iommu strategy to map hypervisor memory into VM memory for DMA. Probably, this code has some bug when handling with large continuous buffer that uses scatter/gather DMA lists.

The cx88 driver allocates from 2 to 32 buffers (each with about 640KB), and dynamically generates a RISC code for writing into those buffers (in fact, it is a little more complex than that, as the RISC code handles 5 different DMA ranges, due to audio, video, VBI, DVB and audio carrier detection - each have its own DMA space). The DMA area is passed to the device as a scatter/gather list.

The (up to) 32 buffers are used as a FIFO, e. g. after buffer 1 is filled by the device, an IRQ is generated, and the kernel passes the DMA scatter/gather pointers to the next buffer.

In the case of DVB, the videobuf-dvb driver will copy data received from each buffer into another buffer that is passed to userspace.

So, it is a fairly complex way of doing DMA. Anything wrong at the iommu emulation at the Xen iommu code will likely affect it.
Comment 18 Dave Jones 2012-03-22 16:48:46 UTC 
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 19 Dave Jones 2012-03-22 16:53:12 UTC 
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 20 Dave Jones 2012-03-22 17:03:50 UTC 
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 21 Jon S 2012-03-22 21:05:38 UTC 
It's all working beautifully now!

You are wonderful people and make me very happy :)

Many thanks.
Comment 22 Jens Hektor 2012-03-31 04:00:18 UTC 
Not me.

Since kernel 3.3 at least viewing/recording with DVB-S is broken.
On screen it looks like bad weather (blocks, broken sound) so that I suspected
a broken cable.

Starting WXP showed me that thecable is o.k.

For me HVR 4000 is now broken (I am *not* using XEN!)
Comment 23 Jens Hektor 2012-04-01 08:51:31 UTC 
(In reply to comment #22)
> Not me.
> 
> Since kernel 3.3 at least viewing/recording with DVB-S is broken.
> On screen it looks like bad weather (blocks, broken sound) so that I suspected
> a broken cable.
> 
> Starting WXP showed me that thecable is o.k.
> 
> For me HVR 4000 is now broken (I am *not* using XEN!)

See also

http://www.spinics.net/lists/linux-media/msg45947.html