I would not spend a lot of time on it, since the kernel debug code complains about 5 different kernel objects when loading the driver. These are kernel objects not pvrusb2 objects.
I anticipate that the problem is way deep inside the kernel. I did do a test and the composite capture of the mpeg2 encoder is working (which is what I need). As time permits, I will try a compile 2.6.30.current and see if it still happens. On Wed, Apr 7, 2010 at 11:27 PM, Mike Isely <[email protected]> wrote: > > Ugh. That stack trace isn't helping much (not your fault). Looks like > it is touching deleted data somewhere deep inside the code which tears > down the driver. It may take some time to dig out the cause here. > > One thing that may help (a lot) here is if you can verify that this > problem is new for 2.6.33.x or if you can also reproduce it in older > kernels, like 2.6.31.x or 2.6.30.x (two kernels I still test a lot with > here). I haven't exercised 2.6.33.x yet here so it's possible that this > is new behavior triggered by the later kernel. Knowing that the kernel > version is affecting this will be useful. > > -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 ([email protected]) (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 <[email protected]> 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 >> > [email protected] >> > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 >> > >> _______________________________________________ >> pvrusb2 mailing list >> [email protected] >> 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 > _______________________________________________ > pvrusb2 mailing list > [email protected] > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > > _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
