Re: [PATCH] xhci - clarify compliance mode debug messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 20 Feb 2013, Don Zickus wrote:

> On Wed, Feb 20, 2013 at 10:54:40AM -0500, Alan Stern wrote:
> > On Wed, 20 Feb 2013, Tony Camuso wrote:
> > 
> > > On 02/20/2013 10:15 AM, Alan Stern wrote:
> > > > On Tue, 19 Feb 2013, Sarah Sharp wrote:
> > > >
> > > >> The one thing I wanted to check was my understanding of the hibernate
> > > >> flow path.  As you mentioned, I thought that xhci_suspend would be
> > > >> called in the hibernate path, but it's not.
> > > >
> > > > Are you sure about that?  AFAICT it should be called -- although it
> > > > gets called during the poweroff phase of hibernation, not the freeze
> > > > phase.
> > > >
> > > > core/hcd-pci.c: usb_hcd_pci_pm_ops.poweroff = hcd_pci_suspend
> > > > core/hcd-pci.c: hcd_pci_suspend calls suspend_common
> > > > core/hcd-pci.c: suspend_common calls hcd->driver->pci_suspend
> > > > host/xhci-pci.c: xhci_pci_hc_driver.pci_suspend = xhci_pci_suspend
> > > > host/xhci-pci.c: xhci_pci_suspend calls xhci_suspend
> > > >
> > > We instrumented the code, and when invoking pm-hibernate, we did
> > > not flow through xhci_suspend(), where the timer is deleted.
> > 
> > If you instrumented the code then you ought to know how the actual 
> > behavior differs from what I outlined above.  Where is the difference?
> 
> Hi Alan,
> 
> I worked with Tony on this issue.  The instrumentation we did was to add
> printks in the xhci_suspend, xhci_resume and
> compliance_mode_recovery_timer_init.
> 
> What we noticed was that the xhci_suspend was not called during hibernate.

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.

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.

> As a result the timer was not deleted.  During the resume, xhci_init
> called compliance_mode_recovery_timer_init which caused the initial panic
> (adding an existing timer).
> 
> We added code to compliance_mode_recovery_timer_init to bail if the timer
> was already enabled.  This lead us to the second problem at the bottom of
> xhci_resume where compliance_mode_recovery_timer_init was called again.
> 
> We did not attempt to understand the mechanics of how suspend/hibernate
> and resume worked.  We just assumed based on the hibernate flag to
> xhci_resume there were two code paths.

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.

> If the expectation is that xhci_suspend should be called during hibernate,
> I can work with Tony to figure out why this is not happening.  Solving
> that problem would partially solve our problem.  We would still need the
> !hibernate flag at the bottom of xhci_resume to surround the timer check
> to deal with xhci_init calling the same init function.

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).

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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux