[pvrusb2] Suspend related issues with pvrusb2

Tue Mar 30 19:18:30 CDT 2010

devsk:

I really have effectively zero experience here with suspend / resume and 
this driver.  If that works, great, but if not then there's not a lot I 
can do here.

I can tell you that the pvrusb2 driver instantiates a kernel thread to 
handle some of its housekeeping, one per device attached.  (Another 
thread might be created on the DVB side if you have a hybrid device.)  
Such a thread is effectively an independent context which can execute 
autonomously and touch internal structures in the driver instance.  If 
the system is suspended then I imagine that this thread probably has to 
be frozen or temporarily removed (and then recreated).  But that's just 
a guess.  The oops you are showing does in fact appear to be involving 
that kernel thread :-(

Obviously given what I know here I can't suggest what the different 
kernel version might be doing.  If you however figure this out and can 
come up with a fix, I will do what I can to get it integrated back into 
the driver (said with the knowledge that I'm not an expert on suspend / 
resume)...

  -Mike

On Sun, 28 Mar 2010, devsk wrote:

> Hi Mike,
> 
> These two issues may be related to latest kernels (I am using 2.6.33.1 vanilla) because I haven't seen this happening earlier. The garbage in name has seen earlier but since it didn't hinder any operation, I did not bother.
> 
> 1.
> 
> This is part of suspend operation, when I try to remove the module before suspend:
> 
> [ 1108.817000] pvrusb2: Supported video standard(s) reported available in hardware: PAL-M/N/Nc;NTSC-M/Mj/Mk
> [ 1108.817000] pvrusb2: Mapping standards mask=0xb700 (PAL-M/N/Nc;NTSC-M/Mj/Mk)
> [ 1108.817000] pvrusb2: Setting up 6 unique standard(s)
> [ 1108.817000] pvrusb2: Set up standard idx=0 name=PAL-M
> [ 1108.817000] pvrusb2: Set up standard idx=1 name=PAL-N
> [ 1108.817000] pvrusb2: Set up standard idx=2 name=PAL-Nc
> [ 1108.817000] pvrusb2: Set up standard idx=3 name=NTSC-M
> [ 1108.817000] pvrusb2: Set up standard idx=4 name=NTSC-Mj
> [ 1108.817000] pvrusb2: Set up standard idx=5 name=NTSC-Mk
> [ 1108.817000] pvrusb2: Initial video standard guessed as NTSC-M
> [ 1108.817000] pvrusb2: Device initialization completed successfully.
> [ 1108.817000] usb 2-2: firmware: requesting v4l-cx2341x-enc.fw
> [ 1108.817000] pvrusb2: registered device video0 [mpeg]
> [ 1108.817000] pvrusb2: registered device radio0 [mpeg]
> [ 1109.094000] tuner-simple 1-0061: creating new instance
> [ 1109.094000] tuner-simple 1-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
> [ 1193.215000] usbcore: deregistering interface driver pvrusb2
> [ 1193.215000] pvrusb2: Device being rendered inoperable
> [ 1193.215000] pvrusb2: unregistered device x¼<96>Ý^A<88>ÿÿstats [mpeg]
> [ 1193.215000] pvrusb2: unregistered device ¨¼<96>Ý^A<88>ÿÿradio0 [mpeg]
> [ 1193.215000] tuner-simple 1-0061: destroying instance
> [ 1193.215000] tda9887 1-0043: destroying instance
> 
> 2. 
> Got this oops when I suspended to RAM without removing pvrusb2.
> 
> ar 28 10:54:22 localhost kernel: [  297.556000] PM: Entering mem sleep
> Mar 28 10:54:22 localhost kernel: [  297.556000] Suspending console(s) (use no_console_suspend to debug)
> Mar 28 10:54:22 localhost kernel: [  297.557000] pvrusb2: Device being rendered inoperable
> Mar 28 10:54:22 localhost kernel: [  297.557000] pvrusb2: unregistered device àÀ¬Ý^A~Hÿÿvideo0 [mpeg]
> Mar 28 10:54:22 localhost kernel: [  297.557000] pvrusb2: unregistered device ^PÁ¬Ý^A~Hÿÿradio0 [mpeg]
> Mar 28 10:54:22 localhost kernel: [  297.557000] tuner-simple 1-0061: destroying instance
> Mar 28 10:54:22 localhost kernel: [  297.557000] tda9887 1-0043: destroying instance
> Mar 28 10:54:22 localhost kernel: [  297.557000] general protection fault: 0000 [#1] SMP
> Mar 28 10:54:22 localhost kernel: [  297.557000] last sysfs file: /sys/devices/virtual/mem/random/uevent
> Mar 28 10:54:22 localhost kernel: [  297.557000] CPU 0
> Mar 28 10:54:22 localhost kernel: [  297.557000] Pid: 3477, comm: pvrusb2-context Tainted: P         C 2.6.33.1 #1 132-BL-E758/OEM
> Mar 28 10:54:22 localhost kernel: [  297.557000] RIP: 0010:[<ffffffffa0c28636>]  [<ffffffffa0c28636>] pvr2_context_thread_func+0x11c/0x31a [pvrusb2]
> Mar 28 10:54:22 localhost kernel: [  297.557000] RSP: 0000:ffff8801de553e70  EFLAGS: 00010206
> Mar 28 10:54:22 localhost kernel: [  297.557000] RAX: 3120353737386d77 RBX: ffff8801de553e80 RCX: ffff8801dc20f880
> Mar 28 10:54:22 localhost kernel: [  297.557000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8801dc20fb80
> Mar 28 10:54:22 localhost kernel: [  297.557000] RBP: ffff8801de0ecc60 R08: ffff8801de552000 R09: ffff8801de553e98
> Mar 28 10:54:22 localhost kernel: [  297.557000] R10: 0000000162cd44d6 R11: 0000000000000246 R12: ffff8801de553e98
> Mar 28 10:54:22 localhost kernel: [  297.557000] R13: ffff8801de0ecc60 R14: 0000000000000000 R15: 000000000000000a
> Mar 28 10:54:22 localhost kernel: [  297.557000] FS:  0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
> Mar 28 10:54:22 localhost kernel: [  297.557000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> Mar 28 10:54:22 localhost kernel: [  297.557000] CR2: 0000000008dadc48 CR3: 000000019b0ad000 CR4: 00000000000006f0
> Mar 28 10:54:22 localhost kernel: [  297.557000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> Mar 28 10:54:22 localhost kernel: [  297.557000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Mar 28 10:54:22 localhost kernel: [  297.557000] Process pvrusb2-context (pid: 3477, threadinfo ffff8801de552000, task ffff8801de0ecc60)
> Mar 28 10:54:22 localhost kernel: [  297.557000] Stack:
> Mar 28 10:54:22 localhost kernel: [  297.557000]  ffff8801dc20f880 dead000000200200 0000000000000000 ffff8801de0ecc60
> Mar 28 10:54:22 localhost kernel: [  297.557000] <0> ffffffff81041567 ffff8801de553e98 ffff8801de553e98 0000000000000000
> Mar 28 10:54:22 localhost kernel: [  297.557000] <0> 0000000000000000 ffff8801de755e58 ffff8801de553ef8 ffffffffa0c2851a
> Mar 28 10:54:22 localhost kernel: [  297.557000] Call Trace:
> Mar 28 10:54:22 localhost kernel: [  297.557000]  [<ffffffff81041567>] ? autoremove_wake_function+0x0/0x2a
> Mar 28 10:54:22 localhost kernel: [  297.557000]  [<ffffffffa0c2851a>] ? pvr2_context_thread_func+0x0/0x31a [pvrusb2]
> Mar 28 10:54:22 localhost kernel: [  297.557000]  [<ffffffff810411ad>] ? kthread+0x75/0x7d
> Mar 28 10:54:22 localhost kernel: [  297.557000]  [<ffffffff81002c94>] ? kernel_thread_helper+0x4/0x10
> Mar 28 10:54:22 localhost kernel: [  297.557000]  [<ffffffff81041138>] ? kthread+0x0/0x7d
> Mar 28 10:54:22 localhost kernel: [  297.557000]  [<ffffffff81002c90>] ? kernel_thread_helper+0x0/0x10
> Mar 28 10:54:22 localhost kernel: [  297.557000] Code: a0 31 c0 48 89 0c 24 e8 64 53 76 e0 48 8b 0c 24 48 8b 39 eb 21 48 8b 47 08 48 89 44 24 08 48 8b 47 30 48 85 c0 74 0a 48 89 0c 24 <ff> d0 48 8b 0c 24 48 8b 7c 24 08 48 85 ff 75 da 83 79 70 00 74
> Mar 28 10:54:22 localhost kernel: [  297.557000] RIP  [<ffffffffa0c28636>] pvr2_context_thread_func+0x11c/0x31a [pvrusb2]
> Mar 28 10:54:22 localhost kernel: [  297.557000]  RSP <ffff8801de553e70>
> Mar 28 10:54:22 localhost kernel: [  297.557000] ---[ end trace 67bb5aedb649c9b1 ]---
> Mar 28 10:54:22 localhost kernel: [  297.558000] sd 7:0:0:0: [sde] Synchronizing SCSI cache
> 
> Do you know if this is a known issue with 2.6.33.1?
> 
> One thing to note is that the device and module works fine if I remove the module before suspend and modprobe it after resume.
> 
> Another related change may be that I have been removing ehci_hcd as part of suspend until recently and I removed that now because most suspend related bugs in USB have been fixed and I don't need to remove ehci_hcd. I think ehci_hcd removal may be triggering the removal of pvrusb2, and that's what (i.e. ehci_hcd was removed) we are seeing in the oops above. But then, the question is why does it matter if the removal is done by suspend script or the ehci_hcd. It should not oops in one case and work in the other.
> 
> There were some callback related changes in 2.6.31 (or somewhere close to it). Have you changed anything PM cbks off late? I don't have older kernels to reproduce this now. Also, I have moved rootfs to btrfs, so going back may not be a good idea.
> 
> Thanks!
> -devsk
> 
> 
> 
>       
> _______________________________________________
> 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