Note that it is perfectly normal for devices to be registered on a bus 
without a driver.  Perhaps the usbhid core doesn't expect this, though, 
or perhaps it doesn't make sense for HID devices.  Regardless, I don't 
see how this could cause the problem.

Earlier, Bruno said that the hang occurs in hid_cancel_delayed_stuff(), 
presumably during one of its cancel_work_sync() calls, and presumably 
because the workqueue has been frozen.  But as far as I can tell, 
cancel_work_sync() should work just fine if the workqueue has been 
frozen.  Maybe this should be investigated more closely.

Bruno, can you confirm that the hang occurs during one of those 
cancel_work_sync() calls?

Alan Stern

--

[ message continues ]

No, it's not one of the cancel_work_sync() that hangs but it's the
del_timer_sync() right before them that hangs!
(del_timer_sync() also hangs if I put it last, so the cancel_work_sync()
don't hang anything)

static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid)
{
	del_timer_sync(&usbhid->io_retry); /* this one never returns */
	cancel_work_sync(&usbhid->restart_work);
	cancel_work_sync(&usbhid->reset_work);
}


Thanks,
Bruno
--

[ message continues ]

This very much reminds me the resume issue with the same keyboard on a
!CONFIG_SMP system back in February when the fix was to copy/move 
usbhid->intf = intf; from usbhid_start() to usbhid_probe()!

Hopefully these are all those initializations that need to be taken
care of...


With this patch system now it passes "devices" level pm_test as well as
full suspend process, even multiple times in a row (though it's still
damn slow to resume IF no_console_suspend is passed to kernel - radeon
KMS?, but that's a new branch from start of this thread)

Reported-by: Bruno Prémont <bonbons@linux-vserver.org>
Tested-By: Bruno Prémont <bonbons@linux-vserver.org>


Now it can continue hunting the next issues preventing smooth S3
experience...

Thanks,
--

[ message continues ]