USB APM suspend

USB APM suspend

[Alan Stern]

Here's a piece from my system log, when I did "apm --suspend".  The 
usb_device_suspend/resume messages are things I added for debugging.

Sep 19 17:02:35 ida kernel: uhci-hcd 0000:00:07.2: suspend to state 3
Sep 19 17:02:35 ida kernel: drivers/usb/host/uhci-hcd.c: 6400: suspend_hc
Sep 19 17:02:35 ida kernel: usb_device_suspend: 1-1:0
Sep 19 17:02:35 ida kernel: usb_device_suspend: 1-1
Sep 19 17:02:35 ida kernel: usb_device_suspend: 1-0:0
Sep 19 17:02:35 ida kernel: usb_device_suspend: usb1
Sep 19 17:02:45 ida kernel: uhci-hcd 0000:00:07.2: suspend D4 --> D3
Sep 19 17:02:45 ida kernel: drivers/usb/host/uhci-hcd.c: 6400: wakeup_hc
Sep 19 17:02:45 ida kernel: usb_device_resume: usb1
Sep 19 17:02:45 ida kernel: usb_device_resume: 1-0:0
Sep 19 17:02:45 ida kernel: usb_device_resume: 1-1
Sep 19 17:02:45 ida kernel: usb_device_resume: 1-1:0
Sep 19 17:02:45 ida kernel: uhci-hcd 0000:00:07.2: can't resume, not suspended!

This has several odd things.  Note that both the first two "0000:00:07.2"  
messages were created by hcd-pci.c, in its usb_hcd_pci_suspend() routine.  

Why was this routine called twice?  (Don't be fooled by the timestamps; I 
think the "suspend D4 --> D3" message was created during the suspend but 
not read by syslogd until after the resume.)

Why doesn't usb_hcd_pci_resume() log a similar message when it is called?
A simple oversight?

Why was the host controller suspended _before_ its child USB devices?  

And why was it woken up twice?

Alan Stern


P.S.: Greg, what on Earth does "GREG: gregindex = 0" mean?

Re: USB APM suspend

[Greg KH]

On Fri, Sep 19, 2003 at 06:14:29PM -0400, Alan Stern wrote:
> 
> P.S.: Greg, what on Earth does "GREG: gregindex = 0" mean?

Heh, using the linuxusb.bkbits.net/usb-2.5 tree are ya?  :)

It's some debugging code left in by me for some module loading code
changes I've been working on in my spare time.  It's to implement only
loading signed kernel modules.  That message means that the "gregindex"
section in the elf records of the kernel module was not found.  It if
is, lots of other code gets kicked off.  I'll try to clean it all up
into a reasonable state next week and make a patch available for those
that want to play with it.

Sorry about leaving that in there, I'll go delete it.  I try to make all
my debugging code start with GREG: so I'll never send it off for
inclusion in someone else's tree.

greg k-h

Re: USB APM suspend

[David Brownell]

Alan Stern wrote:
> Here's a piece from my system log, when I did "apm --suspend".  The 
> usb_device_suspend/resume messages are things I added for debugging.

That's progress ... last time I tried APM on 2.6 it failed horribly.
(This was after working fine until recently.)


> Why was this routine called twice?  (Don't be fooled by the timestamps; I 
> think the "suspend D4 --> D3" message was created during the suspend but 
> not read by syslogd until after the resume.)

That's happened for as long as I remember (2.4 also).
Still seems buglike to me, maybe 2.6 will finally squish it...

> Why doesn't usb_hcd_pci_resume() log a similar message when it is called?
> A simple oversight?

You mean, why didn't it announce its first resume?  Basically, yes.

> Why was the host controller suspended _before_ its child USB devices?  

Seems buglike to me, with the first call being wrong (before the
children were suspended) and the second being right (after).

> And why was it woken up twice?

The converse of the "suspended-twice" problem:  first call right,
second call (after children) wrong.

- Dave

Re: USB APM suspend

[David Brownell]

Alan Stern wrote:

> 
> I tried the experiment of getting rid of the calls to pm_send_all().  
> Surprisingly enough, it worked.  That is, when I typed:
> 
> 	apm --suspend
> 
> everything was suspended, in the correct order; and when I pressed a key 
> everything awoke and seemed to be functioning properly.  

Just for the record:  I tried this on 2.6.0-test7, on a system where
APM has worked reliably forever, and it failed.  (That was without even
involving USB -- there are still non-USB PM problems.)

The device_suspend() logic did seem to call things in the right order,
on one machine I hacked with some printks, but when the moment came to
actually enter the APM suspend mode nothing happened ... except for a
delay of maybe a minute, before the system resumed itself.  (FWIW the
PCI suspend methods involved were for yenta_cardbus and agpgart-intel.
Both of those were called after "hda" spun itself down.)

What should happen of course is the APM BIOS takes over and blanks the
display, and the power indicator changes (in my case to a low-frequency
amber blink, no longer solid green).

- Dave