[media/video] cx88xx HVR-1300,HVR-3000, HVR-4000 tveeprom: Huh, no eeprom present

Bug #836062 reported by TJ on 2011-08-28
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Low
Unassigned

Bug Description

A long-standing bug still affecting kernel v3.1-rc3 (affects Ubuntu from Hardy through Oneiric) that occurs during boot where the Hauppauge cx88xx device fails to read the EEPROM using tveeprom_read(), which results in the Infra-Red receiver failing to be initialised, amongst other problems.

WORKAROUND: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/836062/+attachment/2331923/+files/cx88xx.conf

add the cx88xx module option:
i2c_scan=1

and copy the attached file to:
/etc/modprobe.d/cx88xx.conf

A related fix for LP bug #439163 "HVR-1300 HVR-3000 HVR-4000 broken in kernel" submitted to the main-line kernel by Devin Heitmueller of Kernel Labs (commit: 2d196931 in v3.0) addresses a related issue (opening/closing of the tuner frontends in rapid succession causes channel scan failures) but doesn't solve this issue.

The cause appears to be failure to correctly initialise the tuner's i2c bus, or gracefully handle errors from i2c_transfer().

I'm currently working with mainline kernels from Linus' tree with Mythbuntu 11.04 Natty to trace the issue and hopefully resolve it for an HVR-4000. If I can resolve it in main-line hopefully the patch can be backported to LTS releases.

[ 0.000000] Linux version 3.1.0-0301rc3-generic (root@zinc) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #201108231005 SMP Tue Au
g 23 11:10:27 UTC 2011
...
[ 9.901908] IR NEC protocol handler initialized
[ 9.938166] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded
[ 9.938266] cx88[0]: quirk: PCIPCI_TRITON -- set TBFX
[ 9.938271] cx88[0]: quirk: PCIPCI_ALIMAGIK -- latency fixup
[ 9.938286] cx88[0]: setting pci latency timer to -1
[ 9.943547] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded
[ 9.964453] cx88[0]: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68,autodetected], frontend(s): 2
[ 9.964463] cx88[0]: TV tuner type 63, Radio tuner type -1
[ 9.964468] cx88[0]: cx88_reset
[ 10.015789] IR RC5(x) protocol handler initialized
[ 10.041429] IR RC6 protocol handler initialized
[ 10.082720] IR JVC protocol handler initialized
[ 10.112795] IR Sony protocol handler initialized
[ 10.148789] IR MCE Keyboard/mouse protocol handler initialized
[ 10.176078] lirc_dev: IR Remote Control driver registered, major 250
[ 10.182052] IR LIRC bridge handler initialized
[ 10.436710] cx88[0]: i2c register ok
[ 10.436720] cx88[0]: i2c init: enabling analog demod on HVR1300/3000/4000 tuner
[ 10.692251] i2c-core: driver [tuner] using legacy suspend method
[ 10.692259] i2c-core: driver [tuner] using legacy resume method
[ 11.060383] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro
[ 11.079076] cx2388x alsa driver version 0.0.9 loaded
[ 11.270057] tveeprom 1-0050: Huh, no eeprom present (err=-6)?
[ 11.270071] tveeprom 1-0050: Encountered bad packet header [00]. Corrupt or not a Hauppauge eeprom.
[ 11.270077] cx88[0]: warning: unknown hauppauge model #0
[ 11.270081] cx88[0]: hauppauge eeprom: model=0
...
[ 11.652049] Registered IR keymap rc-hauppauge
[ 11.652871] input: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:0d.2/rc/rc0/input5
[ 11.653178] rc0: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:0d.2/rc/rc0
[ 12.348467] input: MCE IR Keyboard/Mouse (cx88xx) as /devices/virtual/input/input6
[ 12.350773] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0
[ 12.350785] cx88[0]/2: cx2388x 8802 Driver Manager
[ 12.350802] cx88-mpeg driver manager 0000:00:0d.2: enabling device (0014 -> 0016)
[ 12.351385] ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 11
[ 12.351395] cx88-mpeg driver manager 0000:00:0d.2: PCI INT A -> Link[LNKF] -> GSI 11 (level, low) -> IRQ 11
[ 12.351408] cx88[0]/2: found at 0000:00:0d.2, rev: 5, irq: 11, latency: 255, mmio: 0xc8000000
[ 12.351504] cx8800 0000:00:0d.0: enabling device (0014 -> 0016)
[ 12.351514] cx8800 0000:00:0d.0: PCI INT A -> Link[LNKF] -> GSI 11 (level, low) -> IRQ 11
[ 12.351525] cx88[0]/0: found at 0000:00:0d.0, rev: 5, irq: 11, latency: 32, mmio: 0xca000000
...
[ 12.773653] wm8775 1-001b: chip found @ 0x36 (cx88[0])
[ 12.847981] cx88[0]: set_tvnorm: "NTSC-M" fsc8=28636360 adc=28636363 vdec=28636360 db/dr=28636360/28636360
[ 12.847994] cx88[0]: set_pll: MO_PLL_REG 0x00fffffe [old=0x00f15f18,freq=28636360]
[ 12.848013] cx88[0]: pll locked [pre=2,ofreq=28636360]
[ 12.848019] cx88[0]: set_tvnorm: MO_INPUT_FORMAT 0x00000001 [old=0x00000000]
[ 12.848026] cx88[0]: set_tvnorm: MO_OUTPUT_FORMAT 0x181f0008 [old=0x181f0000]
[ 12.848033] cx88[0]: set_tvnorm: MO_SCONV_REG 0x00020000 [old=0x00021f07]
[ 12.848039] cx88[0]: set_tvnorm: MO_SUB_STEP 0x00400000 [old=0x0043e0f8]
[ 12.848045] cx88[0]: set_tvnorm: MO_SUB_STEP_DR 0x00400000 [old=0x00538e38]
[ 12.848052] cx88[0]: set_tvnorm: MO_AGC_BURST 0x00007270 [old=0x00006d63,bdelay=114,agcdelay=112]
[ 12.848059] cx88[0]: set_tvnorm: MO_HTOTAL 0x0000038e [old=0x0000135a,htotal=910]
[ 12.848067] cx88[0]: set_scale: 320x240 [TB,NTSC-M]
[ 12.848071] cx88[0]: set_scale: hdelay 0x0038 (width 754)
[ 12.848075] cx88[0]: set_scale: hscale 0x15b3
[ 12.848078] cx88[0]: set_scale: hactive 0x0140
[ 12.848082] cx88[0]: set_scale: vdelay 0x0018
[ 12.848085] cx88[0]: set_scale: vscale 0x1e00
[ 12.848089] cx88[0]: set_scale: vactive 0x01e0
[ 12.848095] cx88[0]: set_scale: filter 0x80009
[ 12.896662] cx88[0]/0: registered device video1 [v4l2]
[ 12.896900] cx88[0]/0: registered device vbi0
[ 12.896970] cx88_audio 0000:00:0d.1: enabling device (0014 -> 0016)
[ 12.896991] cx88_audio 0000:00:0d.1: PCI INT A -> Link[LNKF] -> GSI 11 (level, low) -> IRQ 11
[ 12.897042] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
[ 12.897740] snd_cmipci 0000:00:05.0: enabling device (0084 -> 0085)
[ 12.897756] snd_cmipci 0000:00:05.0: PCI INT A -> Link[LNKF] -> GSI 11 (level, low) -> IRQ 11
[ 12.937107] snd_cmipci 0000:00:0a.0: enabling device (0084 -> 0085)
[ 12.937668] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
[ 12.937675] PCI: setting IRQ 10 as level-triggered
[ 12.937684] snd_cmipci 0000:00:0a.0: PCI INT A -> Link[LNKC] -> GSI 10 (level, low) -> IRQ 10
...
[ 13.712708] cx88/2: cx2388x dvb driver version 0.0.9 loaded
[ 13.712717] cx88/2: registering cx8802 driver, type: dvb access: shared
[ 13.712727] cx88[0]/2: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68]
[ 13.712734] cx88[0]/2: cx2388x based DVB/ATSC card
[ 13.712740] cx8802_alloc_frontends() allocating 2 frontend(s)
[ 14.657161] tuner-simple 1-0061: creating new instance
[ 14.657173] tuner-simple 1-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
[ 14.661849] DVB: registering new adapter (cx88[0])
[ 14.661868] DVB: registering adapter 0 frontend 0 (Conexant CX24116/CX24118)...
[ 14.676705] DVB: registering adapter 0 frontend 1 (Conexant CX22702 DVB-T)...

TJ (tj) on 2011-08-28
Changed in linux (Ubuntu):
status: New → In Progress
assignee: nobody → TJ (intuitivenipple)
summary: - [meida/video] cx88xx HVR-1300,HVR-3000, HVR-4000 tveeprom: Huh, no
+ [media/video] cx88xx HVR-1300,HVR-3000, HVR-4000 tveeprom: Huh, no
eeprom present
description: updated
TJ (tj) on 2011-08-28
description: updated

Does this problem occur 100% of the time at device boot? Or is it an intermittent issue?

Also, are you sure this happens with the 1300, 3000, and 4000? I'm asking because I don't think the 1300's IR receiver is supported at all (it's a zilog as opposed to GPIO based IR).

If this does indeed happen 100% of the time and isn't environmental, I can probably dig up a 4000 to stick in a box and take a look...

Gunni (fgunni) wrote :

You may try one of these patches:
http://hg.kewl.org/pub/v4l-dvb-20100517/rev/b2c126d4f749
http://hg.kewl.org/pub/v4l-dvb-20100517/rev/c2a80a0d86dd

The first one fixed IR for me some time ago. This line was actual the fix (for me), the rest are cleanups only:

   1.114 - udelay(1000);
   1.115 + msleep(10); /* Wait for Z8F0811 to init. */

TJ (tj) wrote :
Download full text (3.3 KiB)

Devin: On earlier kernels the tveeprom only seemed to fail on warm reboots. However, since about 2.6.35-ish it's almost always failed - although there has been the odd cold or warm reboot that has seen it working.

It's been on my list of kernel bugs to fix for some time but I've only just got around to tackling it.

I believe it will affect all three devices for two reasons:

1) I've examined masses of similar reports where tveeprom fails in this way and these devices are almost always being used
2) I've been delving into the code quite extensively and these three models are treated the same way in the cx88xx code. E.g: drivers/media/video/cx88/cx88-i2c.c:166

  dprintk(1, "i2c register ok\n");
  switch( core->boardnr ) {
   int result = 0;
   case CX88_BOARD_HAUPPAUGE_HVR1300:
   case CX88_BOARD_HAUPPAUGE_HVR3000:
   case CX88_BOARD_HAUPPAUGE_HVR4000:
    printk("%s: i2c init: enabling analog demod on HVR1300/3000/4000 tuner\n",
     core->name);

I'm investigating this code in particular since it doesn't check for an error code in the return from i2c_transfer(). I'm currently building a mainline tip with the following patch to check:

diff --git a/drivers/media/video/cx88/cx88-i2c.c b/drivers/media/video/cx88/cx88-i2c.c
index a1fe0ab..5f56320 100644
--- a/drivers/media/video/cx88/cx88-i2c.c
+++ b/drivers/media/video/cx88/cx88-i2c.c
@@ -165,12 +165,16 @@ int cx88_i2c_init(struct cx88_core *core, struct pci_dev *pci)

                dprintk(1, "i2c register ok\n");
                switch( core->boardnr ) {
+ int result = 0;
                        case CX88_BOARD_HAUPPAUGE_HVR1300:
                        case CX88_BOARD_HAUPPAUGE_HVR3000:
                        case CX88_BOARD_HAUPPAUGE_HVR4000:
                                printk("%s: i2c init: enabling analog demod on HVR1300/3000/4000 tuner\n",
                                        core->name);
- i2c_transfer(core->i2c_client.adapter, &tuner_msg, 1);
+ result = i2c_transfer(core->i2c_client.adapter, &tuner_msg, 1);
+ if (result != 1) {
+ printk(KERN_ERR "%s: i2c init: failed, error=%d\n", core->name, result);
+ }
                                break;
                        default:
                                break;

This i2c transfer is unique to these three models and preceeds the standard call to tveeprom_read() in cx880cards.c::cx88_card_setup(). That function does a i2c_master_send() which fails and reports the error:

 if (err != 1) {
  tveeprom_info("Huh, no eeprom present (err=%d)?\n", err);
  return -1;
 }

My suspicion is that the earlier i2c_transfer() either fails or causes the device to be unavailable at this point - I want to check for -EAGAIN or -EBUSY responses from i2c on these in case a greater delay or retry would be appropriate.

Gunni: Thanks for the references. The code you reference only patches the HVR-1300 code-path, but the same timing delay can be applied to the HVR-3000/4000 code-path. My feeling has always been that this is a timing issue, so maybe that will solve it....

Read more...

TJ (tj) wrote :

Update:

Using debugging kernel 3.1.0-rc3+ (commit 7a54f5e19f + debug patches).

dmesg:

cx88[0]: i2c register ok
cx88[0]: i2c init: enabling analog demod on HVR1300/3000/4000 tuner
cx88[0]: i2c init: failed, error=-6

That error is:

#define ENXIO 6 /* No such device or address */

The code in cx88-i2c.c::i2c_transfer() can only return an error code other than -EAGAIN or -EOPNOTSUPP in the code:

  /* Retry automatically on arbitration loss */
  orig_jiffies = jiffies;
  for (ret = 0, try = 0; try <= adap->retries; try++) {
   ret = adap->algo->master_xfer(adap, msgs, num);
   if (ret != -EAGAIN)
    break;
   if (time_after(jiffies, orig_jiffies + adap->timeout))
    break;
  }

I'm investigating that algo->master_xfer() now.

TJ (tj) wrote :
Download full text (10.4 KiB)

Workaround: add the cx88xx module option i2c_scan=1

Copy the attached file to /etc/modprobe.d/cx88xx.conf

Analysis:

Whilst analysing the inter-dependent modules that rely on cx88xx I did some experimentation with controlling the modprobe order using a custom /etc/modprobe.d/cx88xx.conf with various "install..." directives.

Using this I was able to successfully initialise the device on several occassions, but never reliably.

That lead to examining the i2c related kernel debug messages and that gave me a hunch to try the cx88xx option "i2c_scan" which does an i2c bus scan when the module is inserted, rather than later.

The scan is forced immediately after the call to i2c_transfer() in cx88_i2c_init(). This appears to be a viable workaround for now whilst a permanent solution is developed in the kernel code.

[ 23.868451] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded
[ 23.868540] cx8800 0000:00:0d.0: enabling device (0014 -> 0016)
[ 23.868562] cx8800 0000:00:0d.0: PCI INT A -> Link[LNKF] -> GSI 11 (level, low) -> IRQ 11
[ 23.868582] cx88[0]: quirk: PCIPCI_TRITON -- set TBFX
[ 23.868586] cx88[0]: quirk: PCIPCI_ALIMAGIK -- latency fixup
[ 23.868591] cx88[0]: setting pci latency timer to -1
[ 23.871412] cx88[0]: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68,autodetected], frontend(s
): 2
[ 23.871419] cx88[0]: TV tuner type 63, Radio tuner type -1
[ 23.871423] cx88[0]: cx88_reset
[ 23.876122] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded
[ 24.132123] cx88[0]: i2c register ok
[ 24.132132] cx88[0]: i2c init: enabling analog demod on HVR1300/3000/4000 tuner
...
[ 24.422189] cx88[0]: i2c scan: found device @ 0xa [???]
[ 24.507504] cx88[0]: i2c scan: found device @ 0x10 [???]
...
[ 24.781712] cx2388x alsa driver version 0.0.9 loaded
...
[ 26.044629] cx88[0]: i2c scan: found device @ 0x86 [tda9887/cx22702]
[ 26.100345] cx88[0]: i2c scan: found device @ 0xa0 [eeprom]
[ 26.129431] cx88[0]: i2c scan: found device @ 0xc2 [tuner (analog/dvb)]
[ 26.130647] cx88[0]: i2c scan: found device @ 0xc6 [???]
[ 26.206461] i2c-core: driver [tuner] using legacy suspend method
[ 26.206470] i2c-core: driver [tuner] using legacy resume method
...
[ 26.317057] tda9887 1-0043: creating new instance
[ 26.317066] tda9887 1-0043: tda988[5/6/7] found
[ 26.317643] tuner 1-0043: Tuner 74 found with type(s) Radio TV.
[ 26.335103] tuner 1-0061: Tuner -1 found with type(s) Radio TV.
[ 26.364884] tveeprom 1-0050: full 256-byte eeprom dump:
[ 26.364889] tveeprom 1-0050: 00: 17 00 00 00 70 00 02 69 84 09 00 04 20 77 00 40
[ 26.364905] tveeprom 1-0050: 10: ac f1 12 f0 73 05 21 00 84 08 00 06 91 0d 01 00
[ 26.364921] tveeprom 1-0050: 20: 50 28 89 72 07 70 73 09 19 7f 73 0a f4 64 72 0b
[ 26.364936] tveeprom 1-0050: 30: 2f 72 0e 01 72 0f 01 72 10 01 72 11 ff 79 2f 00
[ 26.364951] tveeprom 1-0050: 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 26.364965] tveeprom 1-0050: 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 26.364980] tveeprom 1-0050: 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 26.364995] tveeprom 1-0050: 70: 00 00 00 00 00 00 00 0...

TJ (tj) on 2012-04-22
Changed in linux (Ubuntu):
assignee: TJ (intuitivenipple) → nobody
status: In Progress → Confirmed

TJ, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. As well, please comment on which kernel version specifically you tested.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream', and comment as to why specifically you were unable to test it.

Please let us know your results. Thanks in advance.

Helpful Bug Reporting Links:
https://help.ubuntu.com/community/ReportingBugs#Bug_Reporting_Etiquette
https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported
https://help.ubuntu.com/community/ReportingBugs#Adding_Apport_Debug_Information_to_an_Existing_Launchpad_Bug
https://help.ubuntu.com/community/ReportingBugs#Adding_Additional_Attachments_to_an_Existing_Launchpad_Bug

tags: added: hardy intrepid jaunty karmic lucid maverick natty needs-upstream-testing oneiric
description: updated
Changed in linux (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
TJ (tj) wrote :
Download full text (3.4 KiB)

This seems to have been fixed upstream. Precise doesn't suffer from the issue - although the HVR-4000 has been moved to a different motherboard.

$ uname -a
Linux jeeves 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:04:05 UTC 2012 i686 i686 i386 GNU/Linux

$ egrep '(IR[^Q]|cx88|eeprom)' /var/log/dmesg
[ 60.690226] IR NEC protocol handler initialized
[ 60.691962] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded
[ 60.695916] cx88[0]: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68,autodetected], frontend(s): 2
[ 60.695923] cx88[0]: TV tuner type 63, Radio tuner type -1
[ 60.696666] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded
[ 60.702580] IR RC5(x) protocol handler initialized
[ 60.711817] IR RC6 protocol handler initialized
[ 60.721429] IR JVC protocol handler initialized
[ 60.728527] IR Sony protocol handler initialized
[ 60.737275] IR MCE Keyboard/mouse protocol handler initialized
[ 60.751969] lirc_dev: IR Remote Control driver registered, major 250
[ 60.752640] IR LIRC bridge handler initialized
[ 60.855528] cx88[0]: i2c init: enabling analog demod on HVR1300/3000/4000 tuner
[ 61.003422] tveeprom 1-0050: Hauppauge model 69009, rev B2A0, serial# 1241516
[ 61.003430] tveeprom 1-0050: MAC address is 00:0d:fe:12:f1:ac
[ 61.003435] tveeprom 1-0050: tuner model is Philips FMD1216ME (idx 100, type 63)
[ 61.003440] tveeprom 1-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4)
[ 61.003445] tveeprom 1-0050: audio processor is CX882 (idx 33)
[ 61.003450] tveeprom 1-0050: decoder processor is CX882 (idx 25)
[ 61.003454] tveeprom 1-0050: has radio, has IR receiver, has no IR transmitter
[ 61.003458] cx88[0]: hauppauge eeprom: model=69009
[ 61.192096] Registered IR keymap rc-hauppauge
[ 61.192335] input: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:1c.0/0000:03:02.2/rc/rc0/input4
[ 61.192449] rc0: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:1c.0/0000:03:02.2/rc/rc0
[ 61.196280] input: MCE IR Keyboard/Mouse (cx88xx) as /devices/virtual/input/input5
[ 61.196662] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0
[ 61.196670] cx88[0]/2: cx2388x 8802 Driver Manager
[ 61.196690] cx88-mpeg driver manager 0000:03:02.2: PCI INT A -> GSI 25 (level, low) -> IRQ 25
[ 61.196705] cx88[0]/2: found at 0000:03:02.2, rev: 5, irq: 25, latency: 49, mmio: 0xeb000000
[ 61.196975] cx8800 0000:03:02.0: PCI INT A -> GSI 25 (level, low) -> IRQ 25
[ 61.196989] cx88[0]/0: found at 0000:03:02.0, rev: 5, irq: 25, latency: 165, mmio: 0xe9000000
[ 61.212963] wm8775 1-001b: chip found @ 0x36 (cx88[0])
[ 61.217589] cx88/2: cx2388x dvb driver version 0.0.9 loaded
[ 61.217595] cx88/2: registering cx8802 driver, type: dvb access: shared
[ 61.217601] cx88[0]/2: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68]
[ 61.217605] cx88[0]/2: cx2388x based DVB/ATSC card
[ 61.217609] cx8802_alloc_frontends() allocating 2 frontend(s)
[ 61.264494] DVB: registering new adapter (cx88[0])
[ 61.501662] cx88[0]/0: registered device video0 [v4l2]
[ 61.5017...

Read more...

TJ (tj) on 2012-09-28
Changed in linux (Ubuntu):
status: Expired → Fix Released
Aaron (apelly) wrote :

This problem still exists in Linux 3.13.0-32-generic #56-Ubuntu SMP Mon Jul 7 11:32:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

For the record, the symptom that drew me here was the failure to create a /dev/dvb device. I do not know if the IR device was working.

It does appear to be motherboard related. I have two HVR4000s working in another machine. A third one worked in yet another machine. On two identical, but newer motherboards the third one fails intermittently.

For the record, the actual structure of the suggested option file is:
$ cat /etc/modprobe.d/cx88xx.conf
options cx88xx i2c_debug=1
options cx88xx i2c_scan=1

The debug option may be omitted.

Logs can be posted if required, but I suspect a bug with this longevity, affecting obsolete hardware and with only two subscribers is probably best abandoned.

Aaron, thank you for your comment. As this bug report is marked Status Fix Released, it is considered closed. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into the default Ubuntu kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers