* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.