[pvrusb2] pvrusb2 and 2.6.27 - No device

[Mike Isely]

On Thu, 16 Oct 2008, devsk wrote:

> Mike,
> 
> It seems like 2.6.27 has a version of pvrusb2 which doesn't work anymore. The module loads but no device is file is created in /dev/v4l. I am using sys-fs/udev-130-r1.
> 
> Only thing seen in dmesg on loading of the module is
> 
> [   14.918314] usbcore: registered new interface driver pvrusb2
> [   14.918317] pvrusb2: Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner : V4L in-tree version
> [   14.918320] pvrusb2: Debug mask is 31 (0x1f)

Those messages appear when the module gets loaded.  And only at that 
time.

But that's different than the act of associating the module with the 
device.  That association step is outside the control of the driver.  
The USB core (likely in cooperation with udev) uses a database of known 
USB IDs mapped to module names.  Each such module (e.g. pvrusb2) 
logically gets its "own" USB IDs registered when that module is 
depmod'ed from userspace.  If that database is messed up, then the USB 
core can't know to associate the pvrusb2 driver.  I've seen this happen 
if "depmod -a" hasn't been run after the kernel's module tree is updated 
/ changed.  However if you are just running a vanilla kernel with 
pvrusb2 built as part of it, then all that setup should have been taken 
care of when you installed the kernel in your system.

I haven't tried the new 2.6.27 here yet.  This weekend I'll grab the 
new source tree and take a look.

> 
> I don't see anything from any other v4l modules 

And you won't, if the pvrusb2 driver hasn't been associated with the 
device.  That act of the USB core telling pvrusb2 about the new device 
in turn triggers actions within the pvrusb2 driver that cause other V4L 
modules (e.g. cx25840) to take notice and start talking to the device.  
So if the pvrusb2 driver is not reacting, then neither will anything 
else.

> 
> # lsmod
> Module                  Size  Used by
> cifs                  247120  0
> vmnet                  35616  9
> vmmon                 990252  7
> vmblock                13328  3
> nvidia               7795456  26
> compcache               5728  1
> tlsf                    7080  1 compcache
> snd_seq_oss            33472  0
> snd_seq_midi_event      7616  1 snd_seq_oss
> snd_seq                55840  4 snd_seq_oss,snd_seq_midi_event
> snd_seq_device          7380  2 snd_seq_oss,snd_seq
> snd_pcm_oss            42976  0
> snd_mixer_oss          16832  1 snd_pcm_oss
> pvrusb2               135872  0
> cx2341x                13508  1 pvrusb2
> v4l2_common            11712  2 pvrusb2,cx2341x
> tveeprom               14980  1 pvrusb2
> videodev               36480  1 pvrusb2
> v4l1_compat            16132  2 pvrusb2,videodev
> ehci_hcd               36748  0
> uhci_hcd               24728  0
> ohci_hcd               25372  0
> abituguru              20696  0
> evdev                  11808  5
> tun                    12420  0
> forcedeth              57552  0
> snd_intel8x0           34216  1
> snd_ac97_codec        117592  1 snd_intel8x0
> ac97_bus                2176  1 snd_ac97_codec
> snd_pcm                80072  3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec
> snd_timer              22416  2 snd_seq,snd_pcm
> snd                    61192  14 snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
> snd_page_alloc          8912  2 snd_intel8x0,snd_pcm
> usbhid                 30240  1
> usb_storage            36096  0
> usblp                  13824  0
> ahci                   34376  4
> 
> I tried to disconnect the device and then remove the pvrusb2 module with 'modprobe -r pvrusb2' and its hung there. The process modprobe has gone to 'D' state.
> 
> modprobe -r pvrusb2 just added one line to dmesg:
> 
> [173610.390163] usbcore: deregistering interface driver pvrusb2
> 
> Let me know if you need to troubleshoot before I reboot the system.

That's not a good thing at all.  The modprobe -r can jam if something is 
referencing the driver internally - like if a thread is blocked while 
inside the driver's code, which should normally NEVER happen.  A more 
likely scenario is that somebody has the /dev node open - but that can't 
be the case here since you haven't even gotten that far.

At this point the best you can probably do is reboot anyway and see if 
this problem is consistently repeatable.

As I said above, I will build a 2.6.27 kernel here and take a look.  But 
I really won't get a chance to do this until the weekend :-(

  -Mike


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8