But it works in Windows...I am just kidding...:-D I think what you mean is that you did not do anything specifically to handle the suspend-resume events by providing callbacks.
I think that's fine, as long as we know that's how it is. I can just remove the module and add it after resume. -devsk ________________________________ From: Mike Isely <[email protected]> To: Communications nexus for pvrusb2 driver <[email protected]> Sent: Tue, March 30, 2010 5:18:30 PM Subject: Re: [pvrusb2] Suspend related issues with pvrusb2 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 > [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
