* DVB suspend/resume regression on 3.19 @ 2015-02-09 10:59 Takashi Iwai 2015-02-13 14:02 ` Takashi Iwai 0 siblings, 1 reply; 7+ messages in thread From: Takashi Iwai @ 2015-02-09 10:59 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, linux-media, linux-kernel Hi, we've got a bug report about the suspend/resume regression of DVB device with 3.19. The symptom is VLC doesn't work after S3 or S4 resume. strace shows that /dev/dvb/adaptor0/dvr returns -ENODEV. The reporter confirmed that 3.18 works fine, so the regression must be in 3.19. There is a relevant kernel warning while suspending: WARNING: CPU: 1 PID: 3603 at ../kernel/module.c:1001 module_put+0xc7/0xd0() Workqueue: events_unbound async_run_entry_fn 0000000000000000 ffffffff81a45779 ffffffff81664f12 0000000000000000 ffffffff81062381 0000000000000000 ffffffffa051eea0 ffff8800ca369278 ffffffffa051a068 ffff8800c0a18090 ffffffff810dfb47 0000000000000000 Call Trace: [<ffffffff810055ac>] dump_trace+0x8c/0x340 [<ffffffff81005903>] show_stack_log_lvl+0xa3/0x190 [<ffffffff81007061>] show_stack+0x21/0x50 [<ffffffff81664f12>] dump_stack+0x47/0x67 [<ffffffff81062381>] warn_slowpath_common+0x81/0xb0 [<ffffffff810dfb47>] module_put+0xc7/0xd0 [<ffffffffa04d98d1>] dvb_usb_adapter_frontend_exit+0x41/0x60 [dvb_usb] [<ffffffffa04d8451>] dvb_usb_exit+0x31/0xa0 [dvb_usb] [<ffffffffa04d84fb>] dvb_usb_device_exit+0x3b/0x50 [dvb_usb] [<ffffffff814cefad>] usb_unbind_interface+0x1ed/0x2c0 [<ffffffff8145ceae>] __device_release_driver+0x7e/0x100 [<ffffffff8145cf52>] device_release_driver+0x22/0x30 [<ffffffff814cf13d>] usb_forced_unbind_intf+0x2d/0x60 [<ffffffff814cf3c3>] usb_suspend+0x73/0x130 [<ffffffff814bd453>] usb_dev_freeze+0x13/0x20 [<ffffffff81468fca>] dpm_run_callback+0x4a/0x150 [<ffffffff81469c81>] __device_suspend+0x121/0x350 [<ffffffff81469ece>] async_suspend+0x1e/0xa0 [<ffffffff81081e63>] async_run_entry_fn+0x43/0x150 [<ffffffff81079e72>] process_one_work+0x142/0x3f0 [<ffffffff8107a234>] worker_thread+0x114/0x460 [<ffffffff8107f3b1>] kthread+0xc1/0xe0 [<ffffffff8166b77c>] ret_from_fork+0x7c/0xb0 So something went wrong in module refcount, which likely leads to disabling the device and returning -ENODEV in the end. Does this ring a bell to you guys? The hardware details and logs are found in the URL below: https://bugzilla.novell.com/show_bug.cgi?id=916577 thanks, Takashi ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DVB suspend/resume regression on 3.19 2015-02-09 10:59 DVB suspend/resume regression on 3.19 Takashi Iwai @ 2015-02-13 14:02 ` Takashi Iwai 2015-02-13 14:41 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 7+ messages in thread From: Takashi Iwai @ 2015-02-13 14:02 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, linux-media, linux-kernel At Mon, 09 Feb 2015 11:59:07 +0100, Takashi Iwai wrote: > > Hi, > > we've got a bug report about the suspend/resume regression of DVB > device with 3.19. The symptom is VLC doesn't work after S3 or S4 > resume. strace shows that /dev/dvb/adaptor0/dvr returns -ENODEV. > > The reporter confirmed that 3.18 works fine, so the regression must be > in 3.19. > > There is a relevant kernel warning while suspending: > > WARNING: CPU: 1 PID: 3603 at ../kernel/module.c:1001 module_put+0xc7/0xd0() > Workqueue: events_unbound async_run_entry_fn > 0000000000000000 ffffffff81a45779 ffffffff81664f12 0000000000000000 > ffffffff81062381 0000000000000000 ffffffffa051eea0 ffff8800ca369278 > ffffffffa051a068 ffff8800c0a18090 ffffffff810dfb47 0000000000000000 > Call Trace: > [<ffffffff810055ac>] dump_trace+0x8c/0x340 > [<ffffffff81005903>] show_stack_log_lvl+0xa3/0x190 > [<ffffffff81007061>] show_stack+0x21/0x50 > [<ffffffff81664f12>] dump_stack+0x47/0x67 > [<ffffffff81062381>] warn_slowpath_common+0x81/0xb0 > [<ffffffff810dfb47>] module_put+0xc7/0xd0 > [<ffffffffa04d98d1>] dvb_usb_adapter_frontend_exit+0x41/0x60 [dvb_usb] > [<ffffffffa04d8451>] dvb_usb_exit+0x31/0xa0 [dvb_usb] > [<ffffffffa04d84fb>] dvb_usb_device_exit+0x3b/0x50 [dvb_usb] > [<ffffffff814cefad>] usb_unbind_interface+0x1ed/0x2c0 > [<ffffffff8145ceae>] __device_release_driver+0x7e/0x100 > [<ffffffff8145cf52>] device_release_driver+0x22/0x30 > [<ffffffff814cf13d>] usb_forced_unbind_intf+0x2d/0x60 > [<ffffffff814cf3c3>] usb_suspend+0x73/0x130 > [<ffffffff814bd453>] usb_dev_freeze+0x13/0x20 > [<ffffffff81468fca>] dpm_run_callback+0x4a/0x150 > [<ffffffff81469c81>] __device_suspend+0x121/0x350 > [<ffffffff81469ece>] async_suspend+0x1e/0xa0 > [<ffffffff81081e63>] async_run_entry_fn+0x43/0x150 > [<ffffffff81079e72>] process_one_work+0x142/0x3f0 > [<ffffffff8107a234>] worker_thread+0x114/0x460 > [<ffffffff8107f3b1>] kthread+0xc1/0xe0 > [<ffffffff8166b77c>] ret_from_fork+0x7c/0xb0 > > So something went wrong in module refcount, which likely leads to > disabling the device and returning -ENODEV in the end. > > Does this ring a bell to you guys? > > The hardware details and logs are found in the URL below: > https://bugzilla.novell.com/show_bug.cgi?id=916577 I wonder whether no one hits the same problem...? Takashi ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DVB suspend/resume regression on 3.19 2015-02-13 14:02 ` Takashi Iwai @ 2015-02-13 14:41 ` Mauro Carvalho Chehab 2015-02-13 15:12 ` Takashi Iwai 0 siblings, 1 reply; 7+ messages in thread From: Mauro Carvalho Chehab @ 2015-02-13 14:41 UTC (permalink / raw) To: Takashi Iwai; +Cc: Hans Verkuil, linux-media, linux-kernel Em Fri, 13 Feb 2015 15:02:42 +0100 Takashi Iwai <tiwai@suse.de> escreveu: > At Mon, 09 Feb 2015 11:59:07 +0100, > Takashi Iwai wrote: > > > > Hi, > > > > we've got a bug report about the suspend/resume regression of DVB > > device with 3.19. The symptom is VLC doesn't work after S3 or S4 > > resume. strace shows that /dev/dvb/adaptor0/dvr returns -ENODEV. > > > > The reporter confirmed that 3.18 works fine, so the regression must be > > in 3.19. > > > > There is a relevant kernel warning while suspending: > > > > WARNING: CPU: 1 PID: 3603 at ../kernel/module.c:1001 module_put+0xc7/0xd0() > > Workqueue: events_unbound async_run_entry_fn > > 0000000000000000 ffffffff81a45779 ffffffff81664f12 0000000000000000 > > ffffffff81062381 0000000000000000 ffffffffa051eea0 ffff8800ca369278 > > ffffffffa051a068 ffff8800c0a18090 ffffffff810dfb47 0000000000000000 > > Call Trace: > > [<ffffffff810055ac>] dump_trace+0x8c/0x340 > > [<ffffffff81005903>] show_stack_log_lvl+0xa3/0x190 > > [<ffffffff81007061>] show_stack+0x21/0x50 > > [<ffffffff81664f12>] dump_stack+0x47/0x67 > > [<ffffffff81062381>] warn_slowpath_common+0x81/0xb0 > > [<ffffffff810dfb47>] module_put+0xc7/0xd0 > > [<ffffffffa04d98d1>] dvb_usb_adapter_frontend_exit+0x41/0x60 [dvb_usb] > > [<ffffffffa04d8451>] dvb_usb_exit+0x31/0xa0 [dvb_usb] > > [<ffffffffa04d84fb>] dvb_usb_device_exit+0x3b/0x50 [dvb_usb] > > [<ffffffff814cefad>] usb_unbind_interface+0x1ed/0x2c0 > > [<ffffffff8145ceae>] __device_release_driver+0x7e/0x100 > > [<ffffffff8145cf52>] device_release_driver+0x22/0x30 > > [<ffffffff814cf13d>] usb_forced_unbind_intf+0x2d/0x60 > > [<ffffffff814cf3c3>] usb_suspend+0x73/0x130 > > [<ffffffff814bd453>] usb_dev_freeze+0x13/0x20 > > [<ffffffff81468fca>] dpm_run_callback+0x4a/0x150 > > [<ffffffff81469c81>] __device_suspend+0x121/0x350 > > [<ffffffff81469ece>] async_suspend+0x1e/0xa0 > > [<ffffffff81081e63>] async_run_entry_fn+0x43/0x150 > > [<ffffffff81079e72>] process_one_work+0x142/0x3f0 > > [<ffffffff8107a234>] worker_thread+0x114/0x460 > > [<ffffffff8107f3b1>] kthread+0xc1/0xe0 > > [<ffffffff8166b77c>] ret_from_fork+0x7c/0xb0 > > > > So something went wrong in module refcount, which likely leads to > > disabling the device and returning -ENODEV in the end. > > > > Does this ring a bell to you guys? > > > > The hardware details and logs are found in the URL below: > > https://bugzilla.novell.com/show_bug.cgi?id=916577 > > I wonder whether no one hits the same problem...? Hi Takashi, There were no recent changes at dvb-usb core or at the dtt200u.c driver. So, I don't think that the regression was caused by a change at the media subsystem. Yet, we've added some patches to fix suspend/resume at the DVB core, but they basically add a new set of optional callbacks. So, it should not cause any regression. The changeset in question is 59d7889ae49f6e3e9d9cff8c0de7ad95d9ca068b. >From those messages: 2015-02-06T15:30:47.468258+01:00 linux-z24t kernel: [ 150.552119] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-fc03.fw' 2015-02-06T15:30:47.468827+01:00 linux-z24t mtp-probe: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4" 2015-02-06T15:30:47.879878+01:00 linux-z24t mtp-probe: bus: 1, device: 5 was not an MTP device 2015-02-06T15:30:47.880192+01:00 linux-z24t kernel: [ 151.992993] usb 1-4: USB disconnect, device number 5 2015-02-06T15:30:47.880839+01:00 linux-z24t kernel: [ 151.993076] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. I _suspect_ that dvb_usb_download_firmware() failed to load the firmware file. That problem actually looks like a recently discovered issue:t request_firmware() fails during resume on some systems. What seems to happen in this case is that the media drivers are resumed _before_ mounting the partition where the firmware file is hosted. Yet, in this case, it should be printing: "did not find the firmware file." I would add a test patch in order to print the return code from dvb_usb_download_firmware(), in order to see if it succeeds or not, e. g. something like the patch below, and then try to narrow down where it is failing, assuming that the new message will be printed. If nothing gets printed, then I would try to discover why the USB stack disconnected the device. Perhaps an ehci/xhci bug? Regards, Mauro diff --git a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c index 733a7ff..184d0290 100644 --- a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c @@ -109,6 +109,10 @@ int dvb_usb_download_firmware(struct usb_device *udev, struct dvb_usb_device_pro } release_firmware(fw); + + if (ret) + err("firmware load failed with %d error code", ret); + return ret; } > > > Takashi > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: DVB suspend/resume regression on 3.19 2015-02-13 14:41 ` Mauro Carvalho Chehab @ 2015-02-13 15:12 ` Takashi Iwai 2015-02-13 15:34 ` Shuah Khan 2015-02-16 16:53 ` Takashi Iwai 0 siblings, 2 replies; 7+ messages in thread From: Takashi Iwai @ 2015-02-13 15:12 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, linux-media, linux-kernel At Fri, 13 Feb 2015 12:41:25 -0200, Mauro Carvalho Chehab wrote: > > Em Fri, 13 Feb 2015 15:02:42 +0100 > Takashi Iwai <tiwai@suse.de> escreveu: > > > At Mon, 09 Feb 2015 11:59:07 +0100, > > Takashi Iwai wrote: > > > > > > Hi, > > > > > > we've got a bug report about the suspend/resume regression of DVB > > > device with 3.19. The symptom is VLC doesn't work after S3 or S4 > > > resume. strace shows that /dev/dvb/adaptor0/dvr returns -ENODEV. > > > > > > The reporter confirmed that 3.18 works fine, so the regression must be > > > in 3.19. > > > > > > There is a relevant kernel warning while suspending: > > > > > > WARNING: CPU: 1 PID: 3603 at ../kernel/module.c:1001 module_put+0xc7/0xd0() > > > Workqueue: events_unbound async_run_entry_fn > > > 0000000000000000 ffffffff81a45779 ffffffff81664f12 0000000000000000 > > > ffffffff81062381 0000000000000000 ffffffffa051eea0 ffff8800ca369278 > > > ffffffffa051a068 ffff8800c0a18090 ffffffff810dfb47 0000000000000000 > > > Call Trace: > > > [<ffffffff810055ac>] dump_trace+0x8c/0x340 > > > [<ffffffff81005903>] show_stack_log_lvl+0xa3/0x190 > > > [<ffffffff81007061>] show_stack+0x21/0x50 > > > [<ffffffff81664f12>] dump_stack+0x47/0x67 > > > [<ffffffff81062381>] warn_slowpath_common+0x81/0xb0 > > > [<ffffffff810dfb47>] module_put+0xc7/0xd0 > > > [<ffffffffa04d98d1>] dvb_usb_adapter_frontend_exit+0x41/0x60 [dvb_usb] > > > [<ffffffffa04d8451>] dvb_usb_exit+0x31/0xa0 [dvb_usb] > > > [<ffffffffa04d84fb>] dvb_usb_device_exit+0x3b/0x50 [dvb_usb] > > > [<ffffffff814cefad>] usb_unbind_interface+0x1ed/0x2c0 > > > [<ffffffff8145ceae>] __device_release_driver+0x7e/0x100 > > > [<ffffffff8145cf52>] device_release_driver+0x22/0x30 > > > [<ffffffff814cf13d>] usb_forced_unbind_intf+0x2d/0x60 > > > [<ffffffff814cf3c3>] usb_suspend+0x73/0x130 > > > [<ffffffff814bd453>] usb_dev_freeze+0x13/0x20 > > > [<ffffffff81468fca>] dpm_run_callback+0x4a/0x150 > > > [<ffffffff81469c81>] __device_suspend+0x121/0x350 > > > [<ffffffff81469ece>] async_suspend+0x1e/0xa0 > > > [<ffffffff81081e63>] async_run_entry_fn+0x43/0x150 > > > [<ffffffff81079e72>] process_one_work+0x142/0x3f0 > > > [<ffffffff8107a234>] worker_thread+0x114/0x460 > > > [<ffffffff8107f3b1>] kthread+0xc1/0xe0 > > > [<ffffffff8166b77c>] ret_from_fork+0x7c/0xb0 > > > > > > So something went wrong in module refcount, which likely leads to > > > disabling the device and returning -ENODEV in the end. > > > > > > Does this ring a bell to you guys? > > > > > > The hardware details and logs are found in the URL below: > > > https://bugzilla.novell.com/show_bug.cgi?id=916577 > > > > I wonder whether no one hits the same problem...? > > Hi Takashi, > > There were no recent changes at dvb-usb core or at the dtt200u.c driver. > So, I don't think that the regression was caused by a change at the media > subsystem. Yet, we've added some patches to fix suspend/resume at the > DVB core, but they basically add a new set of optional callbacks. So, it > should not cause any regression. > > The changeset in question is 59d7889ae49f6e3e9d9cff8c0de7ad95d9ca068b. Hm, is this commit really merged between 3.18 and 3.19? > From those messages: > > 2015-02-06T15:30:47.468258+01:00 linux-z24t kernel: [ 150.552119] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-fc03.fw' > 2015-02-06T15:30:47.468827+01:00 linux-z24t mtp-probe: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4" > 2015-02-06T15:30:47.879878+01:00 linux-z24t mtp-probe: bus: 1, device: 5 was not an MTP device > 2015-02-06T15:30:47.880192+01:00 linux-z24t kernel: [ 151.992993] usb 1-4: USB disconnect, device number 5 > 2015-02-06T15:30:47.880839+01:00 linux-z24t kernel: [ 151.993076] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. > > I _suspect_ that dvb_usb_download_firmware() failed to load the firmware > file. > > That problem actually looks like a recently discovered issue:t > request_firmware() fails during resume on some systems. What > seems to happen in this case is that the media drivers are resumed > _before_ mounting the partition where the firmware file is hosted. > > Yet, in this case, it should be printing: > "did not find the firmware file." Right. This makes me wonder, too. > I would add a test patch in order to print the return code from > dvb_usb_download_firmware(), in order to see if it succeeds or > not, e. g. something like the patch below, and then try to narrow > down where it is failing, assuming that the new message will be printed. > > If nothing gets printed, then I would try to discover why the USB > stack disconnected the device. Perhaps an ehci/xhci bug? OK, I'll give a test kernel to report. Thanks! Takashi ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DVB suspend/resume regression on 3.19 2015-02-13 15:12 ` Takashi Iwai @ 2015-02-13 15:34 ` Shuah Khan 2015-02-13 15:46 ` Shuah Khan 2015-02-16 16:53 ` Takashi Iwai 1 sibling, 1 reply; 7+ messages in thread From: Shuah Khan @ 2015-02-13 15:34 UTC (permalink / raw) To: Takashi Iwai; +Cc: Mauro Carvalho Chehab, Hans Verkuil, linux-media, LKML On Fri, Feb 13, 2015 at 8:12 AM, Takashi Iwai <tiwai@suse.de> wrote: > At Fri, 13 Feb 2015 12:41:25 -0200, > Mauro Carvalho Chehab wrote: >> >> Em Fri, 13 Feb 2015 15:02:42 +0100 >> Takashi Iwai <tiwai@suse.de> escreveu: >> >> > At Mon, 09 Feb 2015 11:59:07 +0100, >> > Takashi Iwai wrote: >> > > >> > > Hi, >> > > >> > > we've got a bug report about the suspend/resume regression of DVB >> > > device with 3.19. The symptom is VLC doesn't work after S3 or S4 >> > > resume. strace shows that /dev/dvb/adaptor0/dvr returns -ENODEV. >> > > >> > > The reporter confirmed that 3.18 works fine, so the regression must be >> > > in 3.19. >> > > >> > > There is a relevant kernel warning while suspending: >> > > >> > > WARNING: CPU: 1 PID: 3603 at ../kernel/module.c:1001 module_put+0xc7/0xd0() >> > > Workqueue: events_unbound async_run_entry_fn >> > > 0000000000000000 ffffffff81a45779 ffffffff81664f12 0000000000000000 >> > > ffffffff81062381 0000000000000000 ffffffffa051eea0 ffff8800ca369278 >> > > ffffffffa051a068 ffff8800c0a18090 ffffffff810dfb47 0000000000000000 >> > > Call Trace: >> > > [<ffffffff810055ac>] dump_trace+0x8c/0x340 >> > > [<ffffffff81005903>] show_stack_log_lvl+0xa3/0x190 >> > > [<ffffffff81007061>] show_stack+0x21/0x50 >> > > [<ffffffff81664f12>] dump_stack+0x47/0x67 >> > > [<ffffffff81062381>] warn_slowpath_common+0x81/0xb0 >> > > [<ffffffff810dfb47>] module_put+0xc7/0xd0 >> > > [<ffffffffa04d98d1>] dvb_usb_adapter_frontend_exit+0x41/0x60 [dvb_usb] >> > > [<ffffffffa04d8451>] dvb_usb_exit+0x31/0xa0 [dvb_usb] >> > > [<ffffffffa04d84fb>] dvb_usb_device_exit+0x3b/0x50 [dvb_usb] >> > > [<ffffffff814cefad>] usb_unbind_interface+0x1ed/0x2c0 >> > > [<ffffffff8145ceae>] __device_release_driver+0x7e/0x100 >> > > [<ffffffff8145cf52>] device_release_driver+0x22/0x30 >> > > [<ffffffff814cf13d>] usb_forced_unbind_intf+0x2d/0x60 >> > > [<ffffffff814cf3c3>] usb_suspend+0x73/0x130 >> > > [<ffffffff814bd453>] usb_dev_freeze+0x13/0x20 >> > > [<ffffffff81468fca>] dpm_run_callback+0x4a/0x150 >> > > [<ffffffff81469c81>] __device_suspend+0x121/0x350 >> > > [<ffffffff81469ece>] async_suspend+0x1e/0xa0 >> > > [<ffffffff81081e63>] async_run_entry_fn+0x43/0x150 >> > > [<ffffffff81079e72>] process_one_work+0x142/0x3f0 >> > > [<ffffffff8107a234>] worker_thread+0x114/0x460 >> > > [<ffffffff8107f3b1>] kthread+0xc1/0xe0 >> > > [<ffffffff8166b77c>] ret_from_fork+0x7c/0xb0 >> > > >> > > So something went wrong in module refcount, which likely leads to >> > > disabling the device and returning -ENODEV in the end. >> > > Hi Takashi and Mauro, Looking at the stack trace usb_forced_unbind_intf() gets called from usb_suspend(). Looks like the suspend path in unbind_no_pm_drivers_interfaces() determines the driver doesn't have suspend/resume support and goes to usb_forced_unbind_intf(). At this point forced unbinding results in release the driver via usb_driver_release_interface(). It is worth looking into if the driver indeed has suspend/resume routines? -- Shuah > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DVB suspend/resume regression on 3.19 2015-02-13 15:34 ` Shuah Khan @ 2015-02-13 15:46 ` Shuah Khan 0 siblings, 0 replies; 7+ messages in thread From: Shuah Khan @ 2015-02-13 15:46 UTC (permalink / raw) To: Takashi Iwai; +Cc: Mauro Carvalho Chehab, Hans Verkuil, linux-media, LKML On Fri, Feb 13, 2015 at 8:34 AM, Shuah Khan <shuahkhan@gmail.com> wrote: > On Fri, Feb 13, 2015 at 8:12 AM, Takashi Iwai <tiwai@suse.de> wrote: >> At Fri, 13 Feb 2015 12:41:25 -0200, >> Mauro Carvalho Chehab wrote: >>> >>> Em Fri, 13 Feb 2015 15:02:42 +0100 >>> Takashi Iwai <tiwai@suse.de> escreveu: >>> >>> > At Mon, 09 Feb 2015 11:59:07 +0100, >>> > Takashi Iwai wrote: >>> > > >>> > > Hi, >>> > > >>> > > we've got a bug report about the suspend/resume regression of DVB >>> > > device with 3.19. The symptom is VLC doesn't work after S3 or S4 >>> > > resume. strace shows that /dev/dvb/adaptor0/dvr returns -ENODEV. >>> > > >>> > > The reporter confirmed that 3.18 works fine, so the regression must be >>> > > in 3.19. >>> > > >>> > > There is a relevant kernel warning while suspending: >>> > > >>> > > WARNING: CPU: 1 PID: 3603 at ../kernel/module.c:1001 module_put+0xc7/0xd0() >>> > > Workqueue: events_unbound async_run_entry_fn >>> > > 0000000000000000 ffffffff81a45779 ffffffff81664f12 0000000000000000 >>> > > ffffffff81062381 0000000000000000 ffffffffa051eea0 ffff8800ca369278 >>> > > ffffffffa051a068 ffff8800c0a18090 ffffffff810dfb47 0000000000000000 >>> > > Call Trace: >>> > > [<ffffffff810055ac>] dump_trace+0x8c/0x340 >>> > > [<ffffffff81005903>] show_stack_log_lvl+0xa3/0x190 >>> > > [<ffffffff81007061>] show_stack+0x21/0x50 >>> > > [<ffffffff81664f12>] dump_stack+0x47/0x67 >>> > > [<ffffffff81062381>] warn_slowpath_common+0x81/0xb0 >>> > > [<ffffffff810dfb47>] module_put+0xc7/0xd0 >>> > > [<ffffffffa04d98d1>] dvb_usb_adapter_frontend_exit+0x41/0x60 [dvb_usb] >>> > > [<ffffffffa04d8451>] dvb_usb_exit+0x31/0xa0 [dvb_usb] >>> > > [<ffffffffa04d84fb>] dvb_usb_device_exit+0x3b/0x50 [dvb_usb] >>> > > [<ffffffff814cefad>] usb_unbind_interface+0x1ed/0x2c0 >>> > > [<ffffffff8145ceae>] __device_release_driver+0x7e/0x100 >>> > > [<ffffffff8145cf52>] device_release_driver+0x22/0x30 >>> > > [<ffffffff814cf13d>] usb_forced_unbind_intf+0x2d/0x60 >>> > > [<ffffffff814cf3c3>] usb_suspend+0x73/0x130 >>> > > [<ffffffff814bd453>] usb_dev_freeze+0x13/0x20 >>> > > [<ffffffff81468fca>] dpm_run_callback+0x4a/0x150 >>> > > [<ffffffff81469c81>] __device_suspend+0x121/0x350 >>> > > [<ffffffff81469ece>] async_suspend+0x1e/0xa0 >>> > > [<ffffffff81081e63>] async_run_entry_fn+0x43/0x150 >>> > > [<ffffffff81079e72>] process_one_work+0x142/0x3f0 >>> > > [<ffffffff8107a234>] worker_thread+0x114/0x460 >>> > > [<ffffffff8107f3b1>] kthread+0xc1/0xe0 >>> > > [<ffffffff8166b77c>] ret_from_fork+0x7c/0xb0 >>> > > >>> > > So something went wrong in module refcount, which likely leads to >>> > > disabling the device and returning -ENODEV in the end. >>> > > > > Hi Takashi and Mauro, > > Looking at the stack trace usb_forced_unbind_intf() gets called from > usb_suspend(). Looks like the suspend path in unbind_no_pm_drivers_interfaces() > determines the driver doesn't have suspend/resume support and goes to > usb_forced_unbind_intf(). > > At this point forced unbinding results in release the driver via > usb_driver_release_interface(). > > It is worth looking into if the driver indeed has suspend/resume > routines? > I am not sure if firmware loading is the issue here. It becomes an issue in resume path if firmware isn't cached. I had to fix xc5000 driver to cache the firmware i.e don't release it after loading so it remains in the firmware cache for suspend/resume to find it. -- Shuah > >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DVB suspend/resume regression on 3.19 2015-02-13 15:12 ` Takashi Iwai 2015-02-13 15:34 ` Shuah Khan @ 2015-02-16 16:53 ` Takashi Iwai 1 sibling, 0 replies; 7+ messages in thread From: Takashi Iwai @ 2015-02-16 16:53 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, linux-media, linux-kernel At Fri, 13 Feb 2015 16:12:40 +0100, Takashi Iwai wrote: > > At Fri, 13 Feb 2015 12:41:25 -0200, > Mauro Carvalho Chehab wrote: > > > > Em Fri, 13 Feb 2015 15:02:42 +0100 > > Takashi Iwai <tiwai@suse.de> escreveu: > > > > > At Mon, 09 Feb 2015 11:59:07 +0100, > > > Takashi Iwai wrote: > > > > > > > > Hi, > > > > > > > > we've got a bug report about the suspend/resume regression of DVB > > > > device with 3.19. The symptom is VLC doesn't work after S3 or S4 > > > > resume. strace shows that /dev/dvb/adaptor0/dvr returns -ENODEV. > > > > > > > > The reporter confirmed that 3.18 works fine, so the regression must be > > > > in 3.19. > > > > > > > > There is a relevant kernel warning while suspending: > > > > > > > > WARNING: CPU: 1 PID: 3603 at ../kernel/module.c:1001 module_put+0xc7/0xd0() > > > > Workqueue: events_unbound async_run_entry_fn > > > > 0000000000000000 ffffffff81a45779 ffffffff81664f12 0000000000000000 > > > > ffffffff81062381 0000000000000000 ffffffffa051eea0 ffff8800ca369278 > > > > ffffffffa051a068 ffff8800c0a18090 ffffffff810dfb47 0000000000000000 > > > > Call Trace: > > > > [<ffffffff810055ac>] dump_trace+0x8c/0x340 > > > > [<ffffffff81005903>] show_stack_log_lvl+0xa3/0x190 > > > > [<ffffffff81007061>] show_stack+0x21/0x50 > > > > [<ffffffff81664f12>] dump_stack+0x47/0x67 > > > > [<ffffffff81062381>] warn_slowpath_common+0x81/0xb0 > > > > [<ffffffff810dfb47>] module_put+0xc7/0xd0 > > > > [<ffffffffa04d98d1>] dvb_usb_adapter_frontend_exit+0x41/0x60 [dvb_usb] > > > > [<ffffffffa04d8451>] dvb_usb_exit+0x31/0xa0 [dvb_usb] > > > > [<ffffffffa04d84fb>] dvb_usb_device_exit+0x3b/0x50 [dvb_usb] > > > > [<ffffffff814cefad>] usb_unbind_interface+0x1ed/0x2c0 > > > > [<ffffffff8145ceae>] __device_release_driver+0x7e/0x100 > > > > [<ffffffff8145cf52>] device_release_driver+0x22/0x30 > > > > [<ffffffff814cf13d>] usb_forced_unbind_intf+0x2d/0x60 > > > > [<ffffffff814cf3c3>] usb_suspend+0x73/0x130 > > > > [<ffffffff814bd453>] usb_dev_freeze+0x13/0x20 > > > > [<ffffffff81468fca>] dpm_run_callback+0x4a/0x150 > > > > [<ffffffff81469c81>] __device_suspend+0x121/0x350 > > > > [<ffffffff81469ece>] async_suspend+0x1e/0xa0 > > > > [<ffffffff81081e63>] async_run_entry_fn+0x43/0x150 > > > > [<ffffffff81079e72>] process_one_work+0x142/0x3f0 > > > > [<ffffffff8107a234>] worker_thread+0x114/0x460 > > > > [<ffffffff8107f3b1>] kthread+0xc1/0xe0 > > > > [<ffffffff8166b77c>] ret_from_fork+0x7c/0xb0 > > > > > > > > So something went wrong in module refcount, which likely leads to > > > > disabling the device and returning -ENODEV in the end. > > > > > > > > Does this ring a bell to you guys? > > > > > > > > The hardware details and logs are found in the URL below: > > > > https://bugzilla.novell.com/show_bug.cgi?id=916577 > > > > > > I wonder whether no one hits the same problem...? > > > > Hi Takashi, > > > > There were no recent changes at dvb-usb core or at the dtt200u.c driver. > > So, I don't think that the regression was caused by a change at the media > > subsystem. Yet, we've added some patches to fix suspend/resume at the > > DVB core, but they basically add a new set of optional callbacks. So, it > > should not cause any regression. > > > > The changeset in question is 59d7889ae49f6e3e9d9cff8c0de7ad95d9ca068b. > > Hm, is this commit really merged between 3.18 and 3.19? > > > From those messages: > > > > 2015-02-06T15:30:47.468258+01:00 linux-z24t kernel: [ 150.552119] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-fc03.fw' > > 2015-02-06T15:30:47.468827+01:00 linux-z24t mtp-probe: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4" > > 2015-02-06T15:30:47.879878+01:00 linux-z24t mtp-probe: bus: 1, device: 5 was not an MTP device > > 2015-02-06T15:30:47.880192+01:00 linux-z24t kernel: [ 151.992993] usb 1-4: USB disconnect, device number 5 > > 2015-02-06T15:30:47.880839+01:00 linux-z24t kernel: [ 151.993076] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. > > > > I _suspect_ that dvb_usb_download_firmware() failed to load the firmware > > file. > > > > That problem actually looks like a recently discovered issue:t > > request_firmware() fails during resume on some systems. What > > seems to happen in this case is that the media drivers are resumed > > _before_ mounting the partition where the firmware file is hosted. > > > > Yet, in this case, it should be printing: > > "did not find the firmware file." > > Right. This makes me wonder, too. > > > I would add a test patch in order to print the return code from > > dvb_usb_download_firmware(), in order to see if it succeeds or > > not, e. g. something like the patch below, and then try to narrow > > down where it is failing, assuming that the new message will be printed. > > > > If nothing gets printed, then I would try to discover why the USB > > stack disconnected the device. Perhaps an ehci/xhci bug? > > OK, I'll give a test kernel to report. The patched kernel didn't show the message. So it's not about the firmware load failure, apparently. Any other point to check? Takashi ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-02-16 16:53 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-02-09 10:59 DVB suspend/resume regression on 3.19 Takashi Iwai 2015-02-13 14:02 ` Takashi Iwai 2015-02-13 14:41 ` Mauro Carvalho Chehab 2015-02-13 15:12 ` Takashi Iwai 2015-02-13 15:34 ` Shuah Khan 2015-02-13 15:46 ` Shuah Khan 2015-02-16 16:53 ` Takashi Iwai
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox