Description of problem: I upgraded my kernel from 2.6.35.10-74.fc14.x86_64 to 2.6.35.11-83.fc14.x86_64 After doing so, the pvrusb2 driver used for the HVR-1950 no longer works. I am unable to record data from the DVB. Version-Release number of selected component (if applicable): 2.6.35.11-83.fc14.x86_64 How reproducible: Absolute Steps to Reproduce: 1. mplayer dvb://XYZ 2. 3. Actual results: mplayer exits with error message Expected results: mplayer plays video Additional info: One difference I see in the logs files is that after upgrading, there is the following message: [ 22.576134] pvrusb2: firmware2 upload transfer failure [ 22.576450] pvrusb2: failed to grab control of dtv input (code=-1) [ 22.576710] pvrusb2: unregistering DVB devices Perhaps changes to the kernel have broken the ability to properly download firmware to the device.
Firmware upload works fine here, but something else is going awry later on in the device bring-up sequence for me. Haven't tried the older kernel yet. How old is the firmware you're using? I'm using the relevant bits for an HVR-1950, as linked here: http://www.isely.net/pvrusb2/setup.html#Firmware [ 2245.909076] usb 1-3: new high speed USB device using ehci_hcd and address 8 [ 2246.029046] usb 1-3: New USB device found, idVendor=2040, idProduct=7501 [ 2246.029057] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2246.029065] usb 1-3: Product: WinTV [ 2246.029071] usb 1-3: Manufacturer: Hauppauge [ 2246.029076] usb 1-3: SerialNumber: 7300-00-F04CB1F3 [ 2246.117788] Linux video capture interface: v2.00 [ 2246.170078] pvrusb2: Hardware description: WinTV HVR-1950 Model 751xx [ 2246.170434] usbcore: registered new interface driver pvrusb2 [ 2246.170441] pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner [ 2246.170449] pvrusb2: Debug mask is 31 (0x1f) [ 2247.198421] pvrusb2: Device microcontroller firmware (re)loaded; it should now reset and reconnect. [ 2247.230231] usb 1-3: USB disconnect, address 8 [ 2247.230462] pvrusb2: Device being rendered inoperable [ 2248.951094] usb 1-3: new high speed USB device using ehci_hcd and address 9 [ 2249.077593] usb 1-3: New USB device found, idVendor=2040, idProduct=7501 [ 2249.077603] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2249.077612] usb 1-3: Product: WinTV [ 2249.077617] usb 1-3: Manufacturer: Hauppauge [ 2249.077622] usb 1-3: SerialNumber: 7300-00-F04CB1F3 [ 2249.078900] pvrusb2: Hardware description: WinTV HVR-1950 Model 751xx [ 2249.111335] pvrusb2: Binding ir_rx_z8f0811_haup to i2c address 0x71. [ 2249.111394] pvrusb2: Binding ir_tx_z8f0811_haup to i2c address 0x70. [ 2249.167818] cx25840 6-0044: cx25843-24 found @ 0x88 (pvrusb2_a) [ 2249.179691] pvrusb2: Attached sub-driver cx25840 [ 2249.231585] tda8290_probe: tda8290 couldn't read register 0x1f [ 2249.231955] tda8295_probe: tda8290 couldn't read register 0x2f [ 2249.234895] tuner 6-0042: chip found @ 0x84 (pvrusb2_a) [ 2249.246566] tda9887 6-0042: creating new instance [ 2249.246569] tda9887 6-0042: tda988[5/6/7] found [ 2249.247442] pvrusb2: Attached sub-driver tuner [ 2251.428250] cx25840 6-0044: loaded v4l-cx25840.fw firmware (16382 bytes) [ 2251.524754] tveeprom 6-00a2: Hauppauge model 75111, rev C3E9, serial# 5026291 [ 2251.524764] tveeprom 6-00a2: MAC address is 00:0d:fe:4c:b1:f3 [ 2251.524772] tveeprom 6-00a2: tuner model is Philips 18271_8295 (idx 149, type 54) [ 2251.524781] tveeprom 6-00a2: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) [ 2251.524789] tveeprom 6-00a2: audio processor is CX25843 (idx 37) [ 2251.524795] tveeprom 6-00a2: decoder processor is CX25843 (idx 30) [ 2251.524803] tveeprom 6-00a2: has radio, has IR receiver, has IR transmitter [ 2251.524817] pvrusb2: Supported video standard(s) reported available in hardware: PAL-M/N/Nc;NTSC-M/Mj/Mk;ATSC-8VSB/16VSB [ 2251.524829] pvrusb2: Mapping standards mask=0x300b700 (PAL-M/N/Nc;NTSC-M/Mj/Mk;ATSC-8VSB/16VSB) [ 2251.524837] pvrusb2: Setting up 6 unique standard(s) [ 2251.524844] pvrusb2: Set up standard idx=0 name=PAL-M [ 2251.524851] pvrusb2: Set up standard idx=1 name=PAL-N [ 2251.524857] pvrusb2: Set up standard idx=2 name=PAL-Nc [ 2251.524863] pvrusb2: Set up standard idx=3 name=NTSC-M [ 2251.524869] pvrusb2: Set up standard idx=4 name=NTSC-Mj [ 2251.524876] pvrusb2: Set up standard idx=5 name=NTSC-Mk [ 2251.524882] pvrusb2: Initial video standard (determined by device type): NTSC-M [ 2251.524902] pvrusb2: Device initialization completed successfully. [ 2251.525863] pvrusb2: registered device video0 [mpeg] [ 2251.525874] DVB: registering new adapter (pvrusb2-dvb) [ 2253.744162] cx25840 6-0044: loaded v4l-cx25840.fw firmware (16382 bytes) [ 2254.302796] cx25840 6-0044: 0x0000 is not a valid video input! [ 2254.446922] DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... [ 2254.448037] tda8290_probe: tda8290 couldn't read register 0x1f [ 2254.448405] tda8295_probe: tda8290 couldn't read register 0x2f [ 2254.484784] tda18271 6-0060: creating new instance [ 2254.485150] tda18271_read_regs: [6-0060|M] ERROR: i2c_transfer returned: -5 [ 2254.485157] Unknown device (0) detected @ 6-0060, device not supported. [ 2254.485164] tda18271_attach: [6-0060|M] error -22 on line 1270 [ 2254.485169] tda18271 6-0060: destroying instance
I am using the 16KB firmware v4l-cx25840.fw md5sum is: b3704908fd058485f3ef136941b2e513 /lib/firmware/v4l-cx25840.fw The file is dated Jul 1 2008. On the newer kernel, I too have the following lines in my dmesg which seems to indicate some sort of i2c init problem with the tuner chip: [ 14.732633] tda8290_probe: tda8290 couldn't read register 0x1f [ 14.733133] tda8295_probe: tda8290 couldn't read register 0x2f ... [ 21.028590] DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... [ 21.029584] tda8290_probe: tda8290 couldn't read register 0x1f [ 21.030082] tda8295_probe: tda8290 couldn't read register 0x2f [ 21.060964] tda18271 2-0060: creating new instance [ 21.061585] tda18271_read_regs: [2-0060|M] ERROR: i2c_transfer returned: -5 [ 21.061846] Unknown device (0) detected @ 2-0060, device not supported. [ 21.062112] tda18271_attach: [2-0060|M] error -22 on line 1270 [ 21.062389] tda18271 2-0060: destroying instance
Okay, I've verified that my hardware works fine in 2.6.35.10-74 as well, and we're using the same firmware. Looking for possible sources of the regression now...
dmesg from a working kernel: [ 14.140773] cx25840 6-0044: loaded v4l-cx25840.fw firmware (16382 bytes) [ 14.237515] tveeprom 6-00a2: Hauppauge model 75111, rev C3E9, serial# 5026291 [ 14.237522] tveeprom 6-00a2: MAC address is 00:0d:fe:4c:b1:f3 [ 14.237527] tveeprom 6-00a2: tuner model is Philips 18271_8295 (idx 149, type 54) [ 14.237533] tveeprom 6-00a2: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) [ 14.237537] tveeprom 6-00a2: audio processor is CX25843 (idx 37) [ 14.237542] tveeprom 6-00a2: decoder processor is CX25843 (idx 30) [ 14.237547] tveeprom 6-00a2: has radio, has IR receiver, has IR transmitter [ 14.237557] pvrusb2: Supported video standard(s) reported available in hardware: PAL-M/N/Nc;NTSC-M/Mj/Mk;ATSC-8VSB/16VSB [ 14.237565] pvrusb2: Mapping standards mask=0x300b700 (PAL-M/N/Nc;NTSC-M/Mj/Mk;ATSC-8VSB/16VSB) [ 14.237570] pvrusb2: Setting up 6 unique standard(s) [ 14.237575] pvrusb2: Set up standard idx=0 name=PAL-M [ 14.237579] pvrusb2: Set up standard idx=1 name=PAL-N [ 14.237583] pvrusb2: Set up standard idx=2 name=PAL-Nc [ 14.237587] pvrusb2: Set up standard idx=3 name=NTSC-M [ 14.237591] pvrusb2: Set up standard idx=4 name=NTSC-Mj [ 14.237596] pvrusb2: Set up standard idx=5 name=NTSC-Mk [ 14.237600] pvrusb2: Initial video standard (determined by device type): NTSC-M [ 14.237615] pvrusb2: Device initialization completed successfully. [ 14.237735] pvrusb2: registered device video0 [mpeg] [ 14.237745] DVB: registering new adapter (pvrusb2-dvb) [ 14.487359] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null) [ 14.546975] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 15.406077] Adding 2096476k swap on /dev/sda2. Priority:-1 extents:1 across:2096476k [ 16.348677] NET: Registered protocol family 10 [ 16.348890] lo: Disabled Privacy Extensions [ 16.354667] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 16.447296] cx25840 6-0044: loaded v4l-cx25840.fw firmware (16382 bytes) [ 16.555539] tda829x 6-0042: setting tuner address to 60 [ 16.608161] tda18271 6-0060: creating new instance [ 16.638792] TDA18271HD/C1 detected @ 6-0060 [ 17.570551] tda829x 6-0042: type set to tda8295+18271 [ 19.140394] RPC: Registered udp transport module. [ 19.140396] RPC: Registered tcp transport module. [ 19.140398] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 22.514634] cx25840 6-0044: 0x0000 is not a valid video input! [ 22.663612] DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... [ 22.665484] tda829x 6-0042: type set to tda8295 [ 22.698770] tda18271 6-0060: attaching existing instance I'm suspicious of upstream commit 567aba0b7997dad5fe3fb4aeb174ee9018df8c5b right now being the culprit. Building a test kernel with that commit backed out right now.
Yep, with that commit reverted, my HVR-1950 returns to full operational status. In this case, the key bits appear to be the changes to tda8295_probe() in drivers/media/common/tuners/tda8290.c, but I haven't made certain of that yet, nor do I fully understand why they make a difference.
Yes, even though the commit comment says it was to provide atomic read/write, I think the problem might be in the code changes related to how the device is probed. That logic was changed. I notice it is using an i2c address of 0x4b. Where does that come from? If I am reading the working code correctly, it used an i2c address of 0x60. I wonder if someone hard-coded the wrong i2c address? Perhaps it should be using 'i2c_props->addr' instead of 0x4b.
(In reply to comment #7) > Yes, even though the commit comment says it was to provide atomic read/write, I > think the problem might be in the code changes related to how the device is > probed. That logic was changed. I notice it is using an i2c address of 0x4b. > Where does that come from? If I am reading the working code correctly, it used > an i2c address of 0x60. I wonder if someone hard-coded the wrong i2c address? > > Perhaps it should be using 'i2c_props->addr' instead of 0x4b. I agree with your analysis. Here is my *proposed* patch to address this by using the same mechanisms used in other parts of the atomic read/write patch... Currently my system has not completed the build process, so errors are likely. Caveat emptor. diff -uNrp kernel-2.6.35.fc14.orig/drivers/media/common/tuners/tda8290.c kernel-2.6.35.fc14.new/drivers/media/commo n/tuners/tda8290.c --- kernel-2.6.35.fc14.orig/drivers/media/common/tuners/tda8290.c 2011-02-28 19:53:03.800113223 -0800 +++ kernel-2.6.35.fc14.new/drivers/media/common/tuners/tda8290.c 2011-02-28 21:59:45.243052908 -0800 @@ -656,20 +656,16 @@ static int tda829x_find_tuner(struct dvb static int tda8290_probe(struct tuner_i2c_props *i2c_props) { #define TDA8290_ID 0x89 - u8 reg = 0x1f, id; - struct i2c_msg msg_read[] = { - { .addr = 0x4b, .flags = 0, .len = 1, .buf = ® }, - { .addr = 0x4b, .flags = I2C_M_RD, .len = 1, .buf = &id }, - }; + unsigned char tda8290_id[] = { 0x1f, 0x00 }; /* detect tda8290 */ - if (i2c_transfer(i2c_props->adap, msg_read, 2) != 2) { + if (tuner_i2c_xfer_send_recv(i2c_props, &tda8290_id[0], 1, &tda8290_id[1], 1) != 1 { printk(KERN_WARNING "%s: tda8290 couldn't read register 0x%02x\n", - __func__, reg); + __func__, tda8290_id[0]); return -ENODEV; } - if (id == TDA8290_ID) { + if (tda8290_id[1] == TDA8290_ID) { if (debug) printk(KERN_DEBUG "%s: tda8290 detected @ %d-%04x\n", __func__, i2c_adapter_id(i2c_props->adap), @@ -683,23 +679,20 @@ static int tda8295_probe(struct tuner_i2 { #define TDA8295_ID 0x8a #define TDA8295C2_ID 0x8b - u8 reg = 0x2f, id; - struct i2c_msg msg_read[] = { - { .addr = 0x4b, .flags = 0, .len = 1, .buf = ® }, - { .addr = 0x4b, .flags = I2C_M_RD, .len = 1, .buf = &id }, - }; + unsigned char tda8295_id[] = { 0x2f, 0x00 }; - /* detect tda8290 */ - if (i2c_transfer(i2c_props->adap, msg_read, 2) != 2) { - printk(KERN_WARNING "%s: tda8290 couldn't read register 0x%02x\n", - __func__, reg); + /* detect tda8295 */ + if (tuner_i2c_xfer_send_recv(i2c_props, &tda8295_id[0], 1, &tda8295_id[1], 1) != 1 { + + printk(KERN_WARNING "%s: tda8295 couldn't read register 0x%02x\n", + __func__, tda8295_id[0]); return -ENODEV; } - if ((id & 0xfe) == TDA8295_ID) { + if ((tda8295_id[1] & 0xfe) == TDA8295_ID) { if (debug) printk(KERN_DEBUG "%s: %s detected @ %d-%04x\n", - __func__, (id == TDA8295_ID) ? + __func__, (tda8295_id[1] == TDA8295_ID) ? "tda8295c1" : "tda8295c2", i2c_adapter_id(i2c_props->adap), i2c_props->addr);
(In reply to comment #7) > Yes, even though the commit comment says it was to provide atomic read/write, I > think the problem might be in the code changes related to how the device is > probed. That logic was changed. I notice it is using an i2c address of 0x4b. > Where does that come from? If I am reading the working code correctly, it used > an i2c address of 0x60. I wonder if someone hard-coded the wrong i2c address? Close. The tda18271 is at 0x60. The tda829x chip is at 0x42 here. From dmesg: tda829x 6-0042: type set to tda8295+18271 The 0042 is i2c address 0x42. The default i2c address for tda829x devices is 0x4b, but some devices use its alternate address of 0x42, which is the case with this hardware. > Perhaps it should be using 'i2c_props->addr' instead of 0x4b. After some sleep and a chance to read over the code again, yeah, I'm pretty sure that's the ticket right there, I have a new test build going with that minimal change and will push a build with it (and push the patch upstream) as soon as I've verified that it works.
Patch verified and sent upstream: https://patchwork.kernel.org/patch/599721/ I've committed it to kernel 2.6.35.11-85.fc14 as well, which is building now: http://koji.fedoraproject.org/koji/taskinfo?taskID=2876250
Build is done: http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.11/85.fc14/ Yell loudly if anything still isn't working... :)
I have just finished verifying that the 2.6.35.11-85.fc14 kernel fixes this issue. Thank you.
(In reply to comment #12) > I have just finished verifying that the 2.6.35.11-85.fc14 kernel fixes this > issue. I also confirm it has fixed the issue with my HVR-1950. > Thank you. Yes, thank you.
Also confirmed that 2.6.35.11-85.fc14 fixed the HVR-1950 problem but it appears to have broken the NVIDIA kernel module. Had to load NVIDIA because 2.6.35.11-83 broke nouveau and the fix was to load NVIDIA. Now both are broken. Tried removing rdblacklist=nouveau from boot parameter on 2.6.35.11-85.fc14 but the system still hangs on X startup after atd. Choice is now to run MythTV without video with the HVR-1950 working or have video without the HVR-1950. Neither of these options is good.
The binary nVidia drivers not working isn't something Fedora has anything to do with fixing, that's on nVidia or possibly whomever packages the binary nVidia driver you're using.