[pvrusb2] driver oops [was: An Apology to the list]

Sat Apr 24 13:23:42 CDT 2010

Mike,

Glad you finally nailed this one! I had a hunch that the garbage characters that I was seeing were the clue to the problem. Moreover, it happened sometime in the last one year or so. It wasn't there from the beginning. So, I think we have got this.

I will gladly test the fix once you publish it.

-devsk

________________________________
From: Mike Isely <isely at isely.net>
To: Communications nexus for pvrusb2 driver <pvrusb2 at isely.net>
Sent: Sat, April 24, 2010 10:56:28 AM
Subject: [pvrusb2] driver oops [was: An Apology to the list]

I believe I've found the source of this oops.  It's also the source of 
the garbage string characters reported in other messages when the driver 
is removed.

A few months back, there was an external patch merged into the pvrusb2 
driver.  This patch changed the way the driver printed its registration 
/ unregistration messages.  Previously the driver was constructing those 
messages completely on its own; the external patch instead changed 
things to call a v4l2 core function (video_device_node_name()) to 
generate some of that text.  This activity makes sense since a lot of 
driver do this - might as well make it common code.

The problem however is that video_device_node_name() is relying on 
internal v4l2 core data and by the time it is being called during 
unregistration, the device structure has already been marked for 
removal.  This is a race - the actual removal does not happen until all 
references are removed but that also means it's not safe to touch that 
state once the unregistration has been done.  Otherwise one could be 
touching deleted memory, thus the garbage string characters and 
potential oops...

I will modify this code to ensure that video_device_node_name() is 
called before the device is unregistered.

It's entirely possible that other v4l drivers might also be suffering 
the same sort of instability upon removal; the patch I had accepted was 
part of a larger one that touched a lot of drivers.

Once I have this fix (and a few others) merged in, I will release a new 
standalone driver.  I'd appreciate it if those who are seeing oopses 
happening could retest with that driver.  I've actually never been able 
to reproduce the oops described below, I found this (possible) cause via 
code inspection and a hunch.  So I can't prove that my fix actually 
fixes this exact problem.

  -Mike

On Wed, 7 Apr 2010, JE Geiger wrote:

> Kind of held off noting the oops pending further testing.
> 
> Kernel is stock downloaded from kernel.org 2.6.33.2 with nvidia 195.36.15.
> 
> /proc/version => Linux version 2.6.33.2 (root at mythtv.localdomain) (gcc
> version 4.4.3 20100401 (Red Hat 4.4.3-14) (GCC) ) #2 SMP Wed Apr 7
> 14:46:50 EDT 2010
> 
> I made no changes to the kernel, other than side compiling the nvidia
> video drivers.  Kernel is stock with in tree v4l video drivers.
> 
> You can see the load/unload trace here:
> 
> On issuing "modprobe pvrusb2"
> 
> I get what looks to be a normal load.
> 
> 
> Linux video capture interface: v2.00
> pvrusb2: Hardware description: WinTV HVR-1950 Model 751xx
> usbcore: registered new interface driver pvrusb2
> pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
> pvrusb2: Debug mask is 31 (0x1f)
> pvrusb2: Binding ir_video to i2c address 0x71.
> cx25840 2-0044: cx25843-24 found @ 0x88 (pvrusb2_a)
> pvrusb2: Attached sub-driver cx25840
> tuner 2-0042: chip found @ 0x84 (pvrusb2_a)
> pvrusb2: Attached sub-driver tuner
> cx25840 2-0044: firmware: requesting v4l-cx25840.fw
> cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
> tveeprom 2-00a2: Hauppauge model 75111, rev C3E9, serial# 5385612
> tveeprom 2-00a2: MAC address is 00-0D-FE-52-2D-8C
> tveeprom 2-00a2: tuner model is Philips 18271_8295 (idx 149, type 54)
> tveeprom 2-00a2: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88)
> tveeprom 2-00a2: audio processor is CX25843 (idx 37)
> tveeprom 2-00a2: decoder processor is CX25843 (idx 30)
> tveeprom 2-00a2: has radio, has IR receiver, has IR transmitter
> pvrusb2: Supported video standard(s) reported available in hardware:
> PAL-M/N/Nc;NTSC-M/Mj/Mk;ATSC-8VSB/16VSB
> pvrusb2: Mapping standards mask=0x300b700
> (PAL-M/N/Nc;NTSC-M/Mj/Mk;ATSC-8VSB/16VSB)
> pvrusb2: Setting up 6 unique standard(s)
> pvrusb2: Set up standard idx=0 name=PAL-M
> pvrusb2: Set up standard idx=1 name=PAL-N
> pvrusb2: Set up standard idx=2 name=PAL-Nc
> pvrusb2: Set up standard idx=3 name=NTSC-M
> pvrusb2: Set up standard idx=4 name=NTSC-Mj
> pvrusb2: Set up standard idx=5 name=NTSC-Mk
> pvrusb2: Initial video standard (determined by device type): NTSC-M
> pvrusb2: Device initialization completed successfully.
> pvrusb2: registered device video0 [mpeg]
> cx25840 2-0044: firmware: requesting v4l-cx25840.fw
> cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
> tda829x 2-0042: setting tuner address to 60
> tda18271 2-0060: creating new instance
> TDA18271HD/C1 detected @ 2-0060
> tda829x 2-0042: type set to tda8295+18271
> usb 1-1: firmware: requesting v4l-cx2341x-enc.fw
> 
> 
> After everything settles, and without actually using the device, I do
> a "rmmod pvrusb2"
> 
> and get
> 
> usbcore: deregistering interface driver pvrusb2
> pvrusb2: Device being rendered inoperable
> BUG: unable to handle kernel paging request at 6b6b6b6b
> IP: [<c0631a1e>] strnlen+0xe/0x20
> *pde = 00000000
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/pci0000:00/0000:00:02.1/usb1/idVendor
> Modules linked in: tda18271 tda8290 tuner cx25840 pvrusb2(-) cx2341x
> v4l2_common videodev v4l1_compat tveeprom hwmon_vid hwmon sunrpc
> nf_conntrack_netbios_ns uinput nvidia(P) snd_intel8x0 snd_ac97_codec
> ac97_bus snd_seq snd_seq_device rt61pci crc_itu_t rt2x00pci rt2x00lib
> snd_pcm snd_timer snd forcedeth joydev i2c_nforce2 pcspkr led_class
> serio_raw i2c_core soundcore eeprom_93cx6 snd_page_alloc pata_acpi
> ata_generic pata_amd [last unloaded: scsi_wait_scan]
> 
> Pid: 1464, comm: pvrusb2-context Tainted: P           2.6.33.2 #2 /
> EIP: 0060:[<c0631a1e>] EFLAGS: 00010097 CPU: 1
> EIP is at strnlen+0xe/0x20
> EAX: 6b6b6b6b EBX: c0d02080 ECX: 6b6b6b6b EDX: fffffffe
> ESI: 6b6b6b6b EDI: c0d01ca0 EBP: f54dfe10 ESP: f54dfe10
>  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> Process pvrusb2-context (pid: 1464, ti=f54de000 task=f54c3fc0 task.ti=f54de000)
> Stack:
>  f54dfe30 c062f9f3 00000000 c0a94dcc ffffffff c0d01ca0 f833f2fe f833f2fc
> <0> f54dfe8c c0630fc9 00000004 00000000 ffffffff 0000000a ffffffff ffffffff
> <0> c0a94dcc f54dfe7c 00000400 c0d01c80 c0d02080 f54dff38 00000004 00000000
> Call Trace:
>  [<c062f9f3>] ? string+0x33/0xe0
>  [<c0630fc9>] ? vsnprintf+0x209/0x430
>  [<c0631296>] ? vscnprintf+0x16/0x24
>  [<c04486c5>] ? vprintk+0xb5/0x4f0
>  [<c0629d28>] ? kobject_release+0x98/0x230
>  [<c0629c90>] ? kobject_release+0x0/0x230
>  [<c0629c90>] ? kobject_release+0x0/0x230
>  [<c062b01d>] ? kref_put+0x2d/0x60
>  [<c0629bbd>] ? kobject_put+0x1d/0x50
>  [<c0629c82>] ? kobject_del+0x22/0x30
>  [<c06da35b>] ? device_del+0x15b/0x190
>  [<c06d9344>] ? put_device+0x14/0x20
>  [<c089dfbe>] ? printk+0x1d/0x1f
>  [<f8336709>] ? pvr2_v4l2_dev_destroy+0x69/0x70 [pvrusb2]
>  [<f833672a>] ? pvr2_v4l2_destroy_no_lock+0x1a/0x70 [pvrusb2]
>  [<f8336927>] ? pvr2_v4l2_internal_check+0x77/0x80 [pvrusb2]
>  [<f8338b7e>] ? pvr2_context_thread_func+0xae/0x2c0 [pvrusb2]
>  [<c04655d0>] ? autoremove_wake_function+0x0/0x50
>  [<f8338ad0>] ? pvr2_context_thread_func+0x0/0x2c0 [pvrusb2]
>  [<c04651ec>] ? kthread+0x7c/0x90
>  [<c0465170>] ? kthread+0x0/0x90
>  [<c0404102>] ? kernel_thread_helper+0x6/0x10
> Code: 57 0f 1f 44 00 00 85 c9 89 c7 74 07 89 d0 f2 ae 75 01 4f 89 f8
> 5f 5d c3 90 8d 74 26 00 55 89 e5 0f 1f 44 00 00 89 c1 89 c8 eb 06 <80>
> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 5d c3 90 90 55 89 e5
> EIP: [<c0631a1e>] strnlen+0xe/0x20 SS:ESP 0068:f54dfe10
> CR2: 000000006b6b6b6b
> ---[ end trace 10abdf68ecf45519 ]---
> pvrusb2-context used greatest stack depth: 5296 bytes left
> 
> 
> 
> The taint comment is due to nvidia proprietary for 1920x1080 support.
> The pvrusb2 does this same thing if I reboot, rmmod nvidia, don't
> start X and then load and unload pvrusb2.
> 
> 
> Unless something appears as a really obvious problem, I will just try
> to use it "as is".
> 
> 
> On Wed, Apr 7, 2010 at 10:32 PM, Mike Isely <isely at isely.net> wrote:
> > On Wed, 7 Apr 2010, JE Geiger wrote:
> >
> >> Thanks.
> >>
> >> I am still tinkering.
> >>
> >> If kernel debug messages are enabled the driver causes the kernel to
> >> puke Object Debug Warning messages, but there is nothing the pvrusb2
> >> driver can do about those.  Something along the lines of "ODEBUG:
> >> object is on stack, but not annotated".   Disabling kernel Object
> >> Debugging causes all those to cease.  It is not your objects, but
> >> objects within the kernel that it is complaining about.
> >>
> >
> >> I do get a kernel oops if I load the driver, allow it to start and
> >> then unload it.
> >
> > This is news to me.  Please send me the oops info so I can take a look.
> > Also, I need to know the kernel version you are running and where the
> > driver came from (bundled with the kernel, from a v4l-dvb snapshot, or
> > if you built the standalone driver).
> >
> >  -Mike
> >
> >
> >>
> >> I will try to actually use the device and see if it "just works".
> >>
> >> Probably better to just plug it in, use it and ignore the log unless
> >> something breaks.
> >>
> >> We also had a sign on the service shop wall:
> >>
> >> "If it works, don't fix it" , I think that is pertinent to this endeavor.
> >>
> >
> > --
> >
> > Mike Isely
> > isely @ isely (dot) net
> > PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
> > _______________________________________________
> > pvrusb2 mailing list
> > pvrusb2 at isely.net
> > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
> >
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
> 

-- 

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