On 02/20/2013 12:35 PM, Alan Stern wrote:
I bet it really was called, but you didn't realize it because of the way you monitored the output from the printks. You looked at the log buffer or the kernel log file after resuming, right? You didn't have a serial console attached to another machine, to capture the output as it occurred.
Actually, we did have a serial console connected.
This makes a difference, because output that occurs after the memory image is stored on disk will not be present in the image and hence will not be visible after you resume from hibernation. Of course, in your case this doesn't matter. In the memory image, the timer is active. Hence it is still active when the system resumes, even though xhci_suspend _was_ called.
Could be because the printk's are not synchronous with execution. Upon resuming from hibernate, we'd see a the call trace, which indicated list_add() corruption where the compliance mode timer was added to the timer list in xhci. Don't know why we didn't crash right there. Maybe something needs to change in list_add(), too. However, we did not see this behavior when returning from suspend.
If you want to handle hibernation correctly, you have to understand how it works. It is all described in excruciating detail in Documentation/power/devices.txt.
Homework assignment. :)
Resuming from hibernation is not like resuming from system suspend, for two important reasons: After hibernation, the system has gone through a complete reboot. The BIOS has probably made changes, and devices generally need to be completely reinitialized. The state a driver sees following hibernation is the state that existed during the "freeze" phase, which is different from what you get during system suspend (and also different from what you get during later phases of hibernation).
Because we didn't see our printks in xhci_suspend(), we assumed, perhaps erroneously, that we never entered and the compliance mode timer was never deleted. We thought that the call trace with list_add() corruption was a smoking gun, and our patch did make the problem go away. We will have another look ... -- 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
