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?
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.
(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.
OK. How do I load the drivers with the debug options enabled? Is this something that needs to be done at compile time?
(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.
Created attachment 534054 [details] set debug on driver as requested, output of dmesg | grep cx >> logfile dmesg | grep cx
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.
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.
Created attachment 534122 [details] dmesg after boot dmesg from boot
Created attachment 534123 [details] /var/log/message gzipped /var/log/messages - quite long.
Could you please test it on a non-Xen kernel?
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.
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¢.
> 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*)
(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.
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.
>> 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)
(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.
[mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update.
It's all working beautifully now! You are wonderful people and make me very happy :) Many thanks.
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!)
(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