Bug 841225 - Hauppauge 950Q won't tune reliably
Hauppauge 950Q won't tune reliably
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Mauro Carvalho Chehab
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-18 09:20 EDT by Tristian Celestin
Modified: 2013-07-04 18:59 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-28 09:55:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tristian Celestin 2012-07-18 09:20:00 EDT
Description:
Using Fedora 17 and kernel 3.4.4

Since kernel 3.4.x, I have not been able to get my Hauppauge 950Q to tune reliably using either VLC, smplayer, or w_scan. I presume that other DVB applications would fail similarly. VLC is the easiest for me to demonstrate problems with this tuner.

How reproducible:
This happens often, but not every time.

Steps to reproduce:
1. Open VLC
2. Open a terminal, and run: watch "dmesg -T | tail -20"
2. Open the channels.conf file from VLC.
3. Select a channel

Expected results:
THe channel begins to play, and continues to play for as long as it is selected.

Received results:
Sometimes, there will be no problem, and I will receive the expected results.

Sometimes, if I select a channel in VLC and the channel begins to play, sometimes it ceases to play within 30 minutes. This isn't an issue of poor reception. VLC will display the last frame decoded. No other channel can be selected.

The following messages appear in dmesg while VLC attempts to tune a channel:
Jul  3 10:17:31 ace kernel: [  453.011678] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
Jul  3 10:17:31 ace kernel: [  453.012216] xc5000: firmware uploading...
Jul  3 10:17:39 ace kernel: [  460.258012] xc5000: firmware upload complete...
Jul  3 10:18:00 ace kernel: [  481.942916] au8522_readreg: readreg error (ret == -5)
Jul  3 10:20:35 ace kernel: [  636.934494] au8522_readreg: readreg error (ret == -5)
Jul  3 10:21:08 ace kernel: [  670.065867] au8522_readreg: readreg error (ret == -5)
Jul  3 10:24:02 ace kernel: [  843.653620] au8522_readreg: readreg error (ret == -5)

If I close VLC, then repeat the steps to reproduce, the following messages appear in dmesg:
Jul  3 10:32:04 ace kernel: [ 1325.724170] xc5000: I2C read failed
Jul  3 10:32:04 ace kernel: [ 1325.724174] xc5000: Unable to initialise tuner
Jul  3 10:32:07 ace kernel: [ 1329.023788] xc5000: I2C read failed
Jul  3 10:32:07 ace kernel: [ 1329.023792] xc5000: xc_SetTVStandard failed

If I then attempt to change a channel in VLC, the following appears in dmesg:
au8522_writereg: writereg error (reg == 0x8081, val == 0x00c4, ret == -5)
Comment 1 Mauro Carvalho Chehab 2012-07-30 12:03:31 EDT
There are a series of fixes for this board at:

http://git.kernellabs.com/?p=dheitmueller/cx23885_fixes.git;a=shortlog;h=refs/heads/950q_fixes

The patches are under testing and the developer should be submitting me soon a pull request for this series.
Comment 2 Curtis Taylor 2012-10-20 18:49:22 EDT
3.4.11-1 fc16 kernel. 
Hauppauge HVR950Q

mythtv box is plagued by:

[20259.772884] au8522_readreg: readreg error (ret == -5)

Actual Results: mythtv recordings are incomplete.
The only errors are the readreg errors.  

For instance:

A monk recording scheduled for 2 hours only recorded 29 minutes starting at 20:00.  There is a au58522_readreg error at 20:28:30.

Oct 19 20:28:30 mythtv kernel: [20259.772884] au8522_readreg: readreg error (ret == -5)

I added 22 of the 24 patches (patch 12 and 22 seem mostly applied already except that some of the code in 3.4.11-1 was not as it is in mainline, so these were the two not applied) from the Aug 7th batch including https://patchwork.kernel.org/patch/1282501/ 

After applying the patches things are better than before, but the au8522_readreg error persists.  It's better because the system boots with mythbackend autostarting and can tune without doing resets of the HVR950Q (via echo to usb device's authorized node.)  Prior to application of the xc5000 patchset, the tuner would never tune without post boot resets. (Sometimes multiple resets.)  Plus, after tuning channels that don't come in all of the time, the tuner doesn't lock up like it did before the patchset was applied.

Does anyone have a newer kernel with all of the latest xc5000 patch set, who had this problem before, not experience this problem any longer?
Comment 3 Josh Boyer 2013-01-22 09:31:09 EST
Are there still issues being seen with the 3.7.3-101 kernel update in updates-testing?  This bug is a bit stale at this point.
Comment 4 Josh Boyer 2013-03-28 09:55:39 EDT
This bug is being closed with INSUFFICIENT_DATA as there has not been a
response in 2 weeks.  If you are still experiencing this issue,
please reopen and attach the relevant data from the latest kernel you are
running and any data that might have been requested previously.

Note You need to log in before you can comment on or make changes to this bug.