New capture card Hauppauge WinTV-HVR-950Q FE_GET_INFO No Such Device

[Jim Carter <jimc@…>]

Versions:

• Capture device: Hauppauge WinTV-HVR-950Q USB ID 2040:7200 (on USB 2.0)
• MythTV 0.26.0
• Kernel 3.7.10 for i586
• Distro: OpenSuSE 12.3
• Host Hardware: Dell Zino HD 400 with AMD "Fusion Zacate"

I run mythtv-setup and try to add this capture card, but it reports on stderr:

`(timestamp) E FE_GET_INFO ioctl failed (/dev/dvb/adapter0/frontend0)

eno: No such device (19)`

w_scan (available on SuSE Build Service) can report the device's capabilities, gets a signal lock on expected frequencies, and reports expected transport streams, suggesting that the drivers are complete and competently loaded.

So what do the two programs do differently? I'm filling up your disc attaching the complete strace output (feel free to toss it), but the key sections go like this, w_scan first:

` write(2, "Info: using DVB adapter auto det"

open("/dev/dvb/adapter0/frontend0", O_RDWR|O_NONBLOCK) = 3 ioctl(3, FE_GET_INFO, 0x8089d00) = 0 Later, does FE_GET_INFO again and prints out the results. `

mythtv-setup is a whole lot more complicated with multiple threads, but here is the analogous section:

` 3553 open("/dev/dvb/adapter0/frontend0", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 47

3553 ioctl(47, FE_GET_INFO <unfinished ...><... ioctl resumed> , 0xbfebfa04) = 0 3553 close(47) 3553 open("/dev/dvb/adapter0/frontend0", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 47 ioctl(47, FE_GET_INFO, 0xbfebfa04) = -1 ENODEV (No such device) close(47) = 0

`

So both programs opened the frontend O_RDWR and got the info successfully, but mythtv-setup then reopened the frontend O_RDONLY, re-snarfed the info, and it failed. It seems wacko for the driver to prevent you from reading a readonly FD. Here's a wild speculation: reading capabilities could potentially lead to firmware being loaded, which is a write operation. (In my case the firmware was loaded many command lines previously.)

May I suggest to just use the successfully read info from the O_RDWR file descriptor?

This bug report is actually a duplicate of 11312 (date about 2012-12-27) with different information, but following the "don't add to tickets" rule I've made a separate ticket for it.

[Jim Carter <jimc@…>]

Output of mythtv-setup --version

[Jim Carter <jimc@…>]

strace output for w_scan -fa -A1 -c US

[Jim Carter <jimc@…>]

strace output for mythtv-setup (failing)

[dekarl@…]

This is a duplicate of #10830, see ​http://code.mythtv.org/trac/ticket/10830#comment:10

Basically you are seeing a race condition in the linux dvb frontend driver. A fix has been developed, but its state on the patch tracker still says "new" see ​https://patchwork.kernel.org/patch/1309251/

Maybe there's some newer information to be had at the media-info list, see ​http://vger.kernel.org/vger-lists.html#linux-media

[Jim Carter <jimc@…>]

/proc/modules on the affected host

[J.Pilk@…]

This issue has been bugging MythTV users for at least 9 months. Ticket #11058, not 11085 as I reported later. The patch has been scaring the linuxtv devs for 5 months; they feel it's a bug in individual drivers. But I suspect that most drivers are 'write and forget' and will not be fixed.

It's clear that other apps do work - eg femon, wscan. If the fix suggested above could be shown to work and not break other things, wouldn't it be worth modifying the 'not our problem' stance?

[Gary Buhrmaster <gary.buhrmaster@…>]

This should probably be closed as a dup of #10830 and/or closed as an upstream bug (fixed in kernel 3.9, kernel commit 6ae23224557d797439d02f6ce5d10a82ab544b21

[stuartm]

Upstream bug in the kernel.