Bug #836062 “[media/video] cx88xx HVR-1300,HVR-3000, HVR-4000 tv...” : Bugs : linux package : Ubuntu

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

Revision history for this message

Devin Heitmueller (devin-heitmueller) wrote on 2011-08-28:

#1

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...

Revision history for this message

Gunni (fgunni) wrote on 2011-08-28:

#2

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. */

Revision history for this message

TJ (tj) wrote on 2011-08-28:

#3

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....

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. Hopefully my tracing can help explain it. If those patches solve the issue, I wonder why they've not made it into the mainline v4l-dvb tree in over a year?

Revision history for this message

TJ (tj) wrote on 2011-08-29:

#4

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.

Revision history for this message

TJ (tj) wrote on 2011-08-29:

#5

Workaround: /etc/modprobe.d/cx88xx.conf Edit (18 bytes, text/plain)

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...

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 00 00 00 00 00 00 00 00 00
[   26.365009] tveeprom 1-0050: 80: 00 00 00 00 84 09 00 04 20 77 00 40 ac f1 12 f0
[   26.365024] tveeprom 1-0050: 90: 73 05 21 00 84 08 00 06 91 0d 01 00 50 28 89 72
[   26.365039] tveeprom 1-0050: a0: 07 70 73 09 19 7f 73 0a f4 64 72 0b 2f 72 0e 01
[   26.365054] tveeprom 1-0050: b0: 72 0f 01 72 10 01 72 11 ff 79 2f 00 00 00 00 00
[   26.365069] tveeprom 1-0050: c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   26.365083] tveeprom 1-0050: d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   26.365098] tveeprom 1-0050: e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   26.365113] tveeprom 1-0050: f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   26.365131] tveeprom 1-0050: Tag [04] + 8 bytes: 20 77 00 40 ac f1 12 f0
[   26.365142] tveeprom 1-0050: Tag [05] + 2 bytes: 21 00
[   26.365148] tveeprom 1-0050: Tag [06] + 7 bytes: 91 0d 01 00 50 28 89
[   26.365158] tveeprom 1-0050: Tag [07] + 1 bytes: 70
[   26.365163] tveeprom 1-0050: Tag [09] + 2 bytes: 19 7f
[   26.365169] tveeprom 1-0050: Tag [0a] + 2 bytes: f4 64
[   26.365175] tveeprom 1-0050: Tag [0b] + 1 bytes: 2f
[   26.365181] tveeprom 1-0050: Tag [0e] + 1 bytes: 01
[   26.365186] tveeprom 1-0050: Tag [0f] + 1 bytes: 01
[   26.365191] tveeprom 1-0050: Tag [10] + 1 bytes: 01
[   26.365197] tveeprom 1-0050: Not sure what to do with tag [10]
[   26.365201] tveeprom 1-0050: Tag [11] + 1 bytes: ff
[   26.365206] tveeprom 1-0050: Not sure what to do with tag [11]
[   26.365213] tveeprom 1-0050: Hauppauge model 69009, rev B2A0, serial# 1241516
[   26.365219] tveeprom 1-0050: MAC address is 00:0d:fe:12:f1:ac
[   26.365225] tveeprom 1-0050: tuner model is Philips FMD1216ME (idx 100, type 63)
[   26.365231] tveeprom 1-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4)
[   26.365237] tveeprom 1-0050: audio processor is CX882 (idx 33)
[   26.365242] tveeprom 1-0050: decoder processor is CX882 (idx 25)
[   26.365247] tveeprom 1-0050: has radio, has IR receiver, has no IR transmitter
[   26.365252] cx88[0]: hauppauge eeprom: model=69009
[   26.421553] tuner-simple 1-0061: creating new instance
[   26.421565] tuner-simple 1-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
[   27.092128] Registered IR keymap rc-hauppauge
[   27.092774] input: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:0d.0/rc/rc0/input5
[   27.093190] rc0: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:0d.0/rc/rc0
[   27.097533] input: MCE IR Keyboard/Mouse (cx88xx) as /devices/virtual/input/input6
[   27.099815] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0
[   27.099834] cx88[0]/0: found at 0000:00:0d.0, rev: 5, irq: 11, latency: 255, mmio: 0xca000000
[   27.099860] btcx: riscmem alloc [1] dma=2b408000 cpu=eb408000 size=64
[   27.099875] btcx: riscmem alloc [2] dma=2be01000 cpu=ebe01000 size=64
[   27.184145] wm8775 1-001b: chip found @ 0x36 (cx88[0])
[   27.191688] cx88[0]: set_tvnorm: "NTSC-M" fsc8=28636360 adc=28636363 vdec=28636360 db/dr=28636360/28636360
[   27.191701] cx88[0]: set_pll:    MO_PLL_REG       0x00fffffe [old=0x00f15f18,freq=28636360]
[   27.191708] cx88[0]: pll locked [pre=2,ofreq=28636360]
[   27.191714] cx88[0]: set_tvnorm: MO_INPUT_FORMAT  0x00000001 [old=0x00000007]
[   27.191721] cx88[0]: set_tvnorm: MO_OUTPUT_FORMAT 0x181f0008 [old=0x181f0000]
[   27.191727] cx88[0]: set_tvnorm: MO_SCONV_REG     0x00020000 [old=0x00021f07]
[   27.191734] cx88[0]: set_tvnorm: MO_SUB_STEP      0x00400000 [old=0x0043e0f8]
[   27.191739] cx88[0]: set_tvnorm: MO_SUB_STEP_DR   0x00400000 [old=0x00538e38]
[   27.191746] cx88[0]: set_tvnorm: MO_AGC_BURST     0x00007270 [old=0x00006d63,bdelay=114,agcdelay=112]
[   27.191753] cx88[0]: set_tvnorm: MO_HTOTAL        0x0000038e [old=0x0000035a,htotal=910]
[   27.191761] cx88[0]: set_scale: 320x240 [TB,NTSC-M]
[   27.191765] cx88[0]: set_scale: hdelay  0x0038 (width 754)
[   27.191769] cx88[0]: set_scale: hscale  0x15b3
[   27.191772] cx88[0]: set_scale: hactive 0x0140
[   27.191776] cx88[0]: set_scale: vdelay  0x0018
[   27.191779] cx88[0]: set_scale: vscale  0x1e00
[   27.191783] cx88[0]: set_scale: vactive 0x01e0
[   27.191789] cx88[0]: set_scale: filter  0x80009
[   27.193599] cx88[0]/0: set_control id=0x980900(Brightness) ctrl=0x7f, reg=0x310110 val=0xff (mask 0xff)
[   27.193608] cx88[0]/0: set_control id=0x980901(Contrast) ctrl=0x3f, reg=0x310110 val=0x3f00 (mask 0xff00)
[   27.193616] cx88[0]/0: set_control id=0x980903(Hue) ctrl=0x7f, reg=0x310118 val=0xff (mask 0xff)
[   27.193624] cx88[0]/0: set_control id=0x980902(Saturation) ctrl=0x7f, reg=0x310114 val=0x5a7f (mask 0xffff)
[   27.193633] cx88[0]/0: set_control id=0x98091B(Sharpness) ctrl=0x00, reg=0x310160 val=0x00 (mask 0x380)
[   27.193640] cx88[0]/0: set_control id=0x98091D(Chroma AGC) ctrl=0x01, reg=0x310104 val=0x400 (mask 0x400)
[   27.193648] cx88[0]/0: set_control id=0x98091E(Color killer) ctrl=0x01, reg=0x310104 val=0x200 (mask 0x200)
[   27.193655] cx88[0]/0: set_control id=0x980921(Notch filter) ctrl=0x00, reg=0x310120 val=0x00 (mask 0x1800)
[   27.194701] cx88[0]/0: set_control id=0x980909(Mute) ctrl=0x01, reg=0x320594 val=0x40 (mask 0x40) [shadowed]
[   27.195729] cx88[0]/0: set_control id=0x980905(Volume) ctrl=0x3f, reg=0x320594 val=0x00 (mask 0x3f) [shadowed]
[   27.196773] cx88[0]/0: set_control id=0x980906(Balance) ctrl=0x40, reg=0x320598 val=0x00 (mask 0x7f) [shadowed]
[   27.196780] cx88[0]/0: video_mux: 0 [vmux=0,gpio=0xc4bf,0x0,0x0,0x0]
[   27.199140] cx88[0]/0: registered device video1 [v4l2]
[   27.200061] cx88[0]/0: registered device vbi0
[   27.200679] cx88[0]/0: registered device radio0
[   27.200818] cx88[0]/2: cx2388x 8802 Driver Manager
[   27.200837] cx88-mpeg driver manager 0000:00:0d.2: enabling device (0014 -> 0016)
[   27.200860] cx88-mpeg driver manager 0000:00:0d.2: PCI INT A -> Link[LNKF] -> GSI 11 (level, low) -> IRQ 11
[   27.200872] cx88[0]/2: found at 0000:00:0d.2, rev: 5, irq: 11, latency: 32, mmio: 0xc8000000
[   27.200892] btcx: riscmem alloc [3] dma=2beed000 cpu=ebeed000 size=64
[   27.201124] cx88_audio 0000:00:0d.1: enabling device (0014 -> 0016)
[   27.201135] cx88_audio 0000:00:0d.1: PCI INT A -> Link[LNKF] -> GSI 11 (level, low) -> IRQ 11
[   27.201147] cx88[0]/1: ALSA cx88[0]/0: found at 0000:00:0d.1, rev: 5, irq: 11, latency: 32, mmio: 0xc9000000
[   27.201193] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
[   27.271169] cx88/2: cx2388x dvb driver version 0.0.9 loaded
[   27.271180] cx88/2: registering cx8802 driver, type: dvb access: shared
[   27.271189] cx88[0]/2: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68]
[   27.271196] cx88[0]/2: cx2388x based DVB/ATSC card
[   27.271202] cx8802_alloc_frontends() allocating 2 frontend(s)
[   27.290436] cx88[0]/0: open dev=video1 radio=0 type=vid-cap
[   27.291597] cx88[0]/0: open dev=radio0 radio=1 type=(null)
[   27.298622] cx88[0]/0: open dev=vbi0 radio=0 type=vbi-cap
[   27.485973] tuner-simple 1-0061: attaching existing instance
[   27.485983] tuner-simple 1-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
[   27.493201] DVB: registering new adapter (cx88[0])
[   27.493219] DVB: registering adapter 0 frontend 0 (Conexant CX24116/CX24118)...
[   27.494401] DVB: registering adapter 0 frontend 1 (Conexant CX22702 DVB-T)...
[   27.515752] cx88[0]/0: video_open: setting radio device
...

TJ (tj) on 2012-04-22

Changed in linux (Ubuntu):
assignee:	TJ (intuitivenipple) → nobody
status:	In Progress → Confirmed

Revision history for this message

penalvch (penalvch) wrote on 2012-07-30:

#6

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

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

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-09-28:

#7

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

Changed in linux (Ubuntu):
status:	Incomplete → Expired

Revision history for this message

TJ (tj) wrote on 2012-09-28:

#8

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...

Ubuntu
linux package

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

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Changed in linux (Ubuntu):
status:	Expired → Fix Released

Ubuntulinux package

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

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
linux package