On Wed, 20 Feb 2013, Tony Camuso wrote: > 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. And you didn't see any indication that xhci_suspend was called? Odd... Did you remember to specify no_console_suspend on the boot command line? > > 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. No, I believe they are synchronous when you use a serial console. Somebody can let us know if I am wrong. > 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. Naturally, since it hadn't been removed from the timer list when the memory image was created. > Don't know why we didn't crash right there. Maybe something needs > to change in list_add(), too. You mean you want the kernel to crash in situations where it currently continues to operate okay (albeit with some memory corruption)? That doesn't seem very productive. :-) > However, we did not see this behavior when returning from suspend. Of course. Suspend does not create or restore a memory image, whereas hibernate does. > > 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 ... My guess is that xhci_suspend _was_ entered and the timer was deleted from the list, but when you resumed from hibernation it was back on the list again. This may sound strangely futile -- changes made during xhci_suspend are gone when hibernation ends. But that's true only for changes to memory. Changes made to the hardware _will_ have an effect (at least until the system shuts down as the final stage of hibernation). 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
