On Mon, 26 Aug 2013, Adam Borowski wrote:
> Hi!
>
> I'm afraid that your kernel patch 84ebc10294a3d7be4c66f51070b7aedbaa24de9b
> ("USB: remove CONFIG_USB_SUSPEND option") causes lockups on resume from
> suspend on at least some machines.
>
> On kernels from this patch forward up to some point in 3.11-rc, there is
> nothing but a blank screen after resuming; in later kernels the display
> returns but that's it. With no_console_suspend=1, it appears like it starts
> to dump a trace, yet fails to do so. 120 seconds later, I get a hung_task
> message with the following trace:
>
> schedule_timeout+0x1f9/0x2c0
> set_cpus_allowed_ptr+0x6e/0x100
> kthread_create_on_node+0x100/0x110
> wait_for_completion+0x9a/0x100
> wake_up_state+0x10/0x10
> device_resume+0x42/0x180
> async_resume+0x14/0x40
> async_run_entry_fn+0x2d/0x120
> process_one_work+0x167/0x410
> worker_thread+0x116/0x3a0
> manage_workers.isra.25+0x290/0x290
> kthread+0xaf/0xc0
> kthread_create_on_node+0x110/0x110
> ret_from_fork+0x7c/0xb0
> kthread_create_on_node+0x110/0x110
>
> The config comes from Debian kernel packages, it includes:
> CONFIG_PM_RUNTIME=y
> CONFIG_PM=y
I presume CONFIG_PM_SLEEP is also enabled, since otherwise you wouldn't
be able to suspend the machine.
What happens if go back to a kernel without that commit and enable
CONFIG_USB_SUSPEND? The behavior should be identical -- basically the
commit is supposed to have the effect of always assuming that
CONFIG_USB_SUSPEND has the same value as CONFIG_PM_RUNTIME, except in
one spot where it is assumed to have the same value as CONFIG_PM.
Also, bear in mind that the commit you mentioned was incomplete. It
has to be applied along with 98f541c6e390 (USB: remove remaining
instances of USB_SUSPEND). Of course, the later kernels all have both
commits.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
