Request for testing remote wakeup during STD

Request for testing remote wakeup during STD

[Alan Stern]

There have been reports of problems related to shutting down with remote 
wakeup enabled on EHCI USB controllers in 2.6.20; see

	http://bugzilla.kernel.org/show_bug.cgi?id=7828

In brief, some people have found that if ehci-hcd is loaded and the 
controller is suspended when they try to shut down their systems, the 
machine reboots immediately instead of turning off.  Apparently this is 
caused by the firmware mistakenly thinking that a remote-wakeup event has 
occurred.  Admittedly, remote wakeup from a system sleep is still black 
magic to most of us...

I wrote a patch to try and fix the problem by turning off EHCI remote
wakeup from within the driver's shutdown() method.  The patch is here:

	http://bugzilla.kernel.org/attachment.cgi?id=10313&action=view

However I'm concerned that this might affect suspend-to-disk.  Some lucky 
people have systems which do keep their EHCI controllers in D3hot during 
STD, and such people might reasonably want Wake-on-USB to work properly.  
It seems likely that the patch would prevent it from working.

Does anyone have a system capable of testing this?  I think Macs are most 
likely to have the necessary hardware support.

Thanks,

Alan Stern

Re: Request for testing remote wakeup during STD

[Nigel Cunningham]

Hi Alan.

On Fri, 2007-02-09 at 22:59 -0500, Alan Stern wrote:
> There have been reports of problems related to shutting down with remote 
> wakeup enabled on EHCI USB controllers in 2.6.20; see
> 
> 	http://bugzilla.kernel.org/show_bug.cgi?id=7828
> 
> In brief, some people have found that if ehci-hcd is loaded and the 
> controller is suspended when they try to shut down their systems, the 
> machine reboots immediately instead of turning off.  Apparently this is 
> caused by the firmware mistakenly thinking that a remote-wakeup event has 
> occurred.  Admittedly, remote wakeup from a system sleep is still black 
> magic to most of us...
> 
> I wrote a patch to try and fix the problem by turning off EHCI remote
> wakeup from within the driver's shutdown() method.  The patch is here:
> 
> 	http://bugzilla.kernel.org/attachment.cgi?id=10313&action=view
> 
> However I'm concerned that this might affect suspend-to-disk.  Some lucky 
> people have systems which do keep their EHCI controllers in D3hot during 
> STD, and such people might reasonably want Wake-on-USB to work properly.  
> It seems likely that the patch would prevent it from working.
> 
> Does anyone have a system capable of testing this?  I think Macs are most 
> likely to have the necessary hardware support.

I'd love to be able to help you. My lappy loads ehci and lsusb shows the
controller, but I'll be darned if I can find the socket! I have other
things to get done right now, but if no-one beats me to it, I'll try the
desktop I have - I think that has ehci somewhere.

Regards,

Nigel

Re: Request for testing remote wakeup during STD

[Alan Stern]

On Sat, 10 Feb 2007, Nigel Cunningham wrote:

> Hi Alan.

> I'd love to be able to help you. My lappy loads ehci and lsusb shows the
> controller, but I'll be darned if I can find the socket! I have other
> things to get done right now, but if no-one beats me to it, I'll try the
> desktop I have - I think that has ehci somewhere.

Thanks, Nigel.  You mean your laptop has an EHCI controller but no USB
ports?  That's odd...

Anyway, here are instructions for you or anyone else who can do the test.  
(I forgot to include them in the original message.)  Running the test
involves two steps.

The first step is to check that an unpatched system supports Wake-on-USB.  
This means enabling it in the BIOS and/or in ACPI (whatever that might
entail; I have no idea what's needed) and actually trying it out.  Either
plugging or unplugging a USB device while the system is in STD should wake
the machine up.

The second step is to see whether Wake-on-USB continues to work after
applying the patch mentioned previously.  That's the real question.

It may turn out that _nobody_ has Wake-on-USB working at all... in which 
case we'd have a different problem to solve.

Alan Stern

Re: Request for testing remote wakeup during STD

[Nigel Cunningham]

Hi.

On Sat, 2007-02-10 at 12:08 -0500, Alan Stern wrote:
> On Sat, 10 Feb 2007, Nigel Cunningham wrote:
> 
> > Hi Alan.
> 
> > I'd love to be able to help you. My lappy loads ehci and lsusb shows the
> > controller, but I'll be darned if I can find the socket! I have other
> > things to get done right now, but if no-one beats me to it, I'll try the
> > desktop I have - I think that has ehci somewhere.
> 
> Thanks, Nigel.  You mean your laptop has an EHCI controller but no USB
> ports?  That's odd...

Yeah. I have three USB ports on it, but two of them seem to be connected
to one controller (going by lsusb after plugging my Palm into each of
them).

> Anyway, here are instructions for you or anyone else who can do the test.  
> (I forgot to include them in the original message.)  Running the test
> involves two steps.
> 
> The first step is to check that an unpatched system supports Wake-on-USB.  
> This means enabling it in the BIOS and/or in ACPI (whatever that might
> entail; I have no idea what's needed) and actually trying it out.  Either
> plugging or unplugging a USB device while the system is in STD should wake
> the machine up.
> 
> The second step is to see whether Wake-on-USB continues to work after
> applying the patch mentioned previously.  That's the real question.
> 
> It may turn out that _nobody_ has Wake-on-USB working at all... in which 
> case we'd have a different problem to solve.

Thanks!

Nigel

Re: Request for testing remote wakeup during STD

[Alan Stern]

On Sun, 11 Feb 2007, Nigel Cunningham wrote:

> Hi.
> 
> On Sat, 2007-02-10 at 12:08 -0500, Alan Stern wrote:
> > On Sat, 10 Feb 2007, Nigel Cunningham wrote:
> > 
> > > Hi Alan.
> > 
> > > I'd love to be able to help you. My lappy loads ehci and lsusb shows the
> > > controller, but I'll be darned if I can find the socket! I have other
> > > things to get done right now, but if no-one beats me to it, I'll try the
> > > desktop I have - I think that has ehci somewhere.
> > 
> > Thanks, Nigel.  You mean your laptop has an EHCI controller but no USB
> > ports?  That's odd...
> 
> Yeah. I have three USB ports on it, but two of them seem to be connected
> to one controller (going by lsusb after plugging my Palm into each of
> them).

The contents of /proc/bus/usb/devices would be easier to read.
Nevertheless, here's a capsule explanation:

Most high-speed USB host controllers aren't capable of supporting full
speed or low speed.  In order to make a completely functional system,
vendors have to pair each high-speed controller with a companion
full-and-low-speed controller.  USB ports are wired internally to both
controllers, and an electronic switch decides which controller actually
manages the port at any time, based on the speed of the device plugged
into the port.

Sometimes a single high-speed controller will have more than one
companion.  For example, each companion controller might handle only two
ports while the high-speed controller can handle six; in that case there
would have to be three companions.

And sometimes controllers aren't connected to anything at all!  For
example, I've got a PCI USB card on my machine.  It contains 1 EHCI (high
speed) controller capable of handling six ports and 3 OHCI (full and low
speed) each capable of handling two ports, as described above.  But the
card has only 4 ports!  Each port is connected to the EHCI controller and
to one of the OHCI controllers, and one OHCI is connected to nothing.  
The card is a cut-down version of a 6-port model, and the manufacturer
simply removed two of the ports while leaving the third OHCI controller on
board.

As another example, my motherboard has three USB ports and three OHCI 
controllers, each of which is capable of driving two ports but is wired up 
only to one.

> > Anyway, here are instructions for you or anyone else who can do the test.  
> > (I forgot to include them in the original message.)  Running the test
> > involves two steps.
> > 
> > The first step is to check that an unpatched system supports Wake-on-USB.  
> > This means enabling it in the BIOS and/or in ACPI (whatever that might
> > entail; I have no idea what's needed) and actually trying it out.  Either
> > plugging or unplugging a USB device while the system is in STD should wake
> > the machine up.
> > 
> > The second step is to see whether Wake-on-USB continues to work after
> > applying the patch mentioned previously.  That's the real question.
> > 
> > It may turn out that _nobody_ has Wake-on-USB working at all... in which 
> > case we'd have a different problem to solve.
> 
> Thanks!

On further thought, I wonder if this could ever work reliably.  During 
suspend-to-disk, after the memory snapshot is created every device is 
woken up to write out the image (or at least, every device that was awake 
before the suspend-to-disk started).  The image is written and then the 
system shuts down, without bothering to suspend anything.

Now I don't know about other subsystems, but in USB we disable remote
wakeup when a device is resumed and enable it when the device is
suspended.  Since the sequence of events is <resume, write image,
shutdown> with no intervening suspend, remote wakeup will not be enabled.

That's true for external devices, anyway.  For devices on the motherboard, 
like host controllers, it's entirely possible that the firmware uses some 
other technique to control remote wakeup (something involving ACPI, for 
example).  Documentation on this point is almost non-existent, so it's 
kind of hard to say anything definite.

This suggests that I shouldn't worry about remote wakeup during
suspend-to-disk at all -- it's a lost cause.

Alan Stern

Re: Request for testing remote wakeup during STD

[Nigel Cunningham]

Hi.

On Sun, 2007-02-11 at 14:44 -0500, Alan Stern wrote:
> On Sun, 11 Feb 2007, Nigel Cunningham wrote:
> 
> > Hi.
> > 
> > On Sat, 2007-02-10 at 12:08 -0500, Alan Stern wrote:
> > > On Sat, 10 Feb 2007, Nigel Cunningham wrote:
> > > 
> > > > Hi Alan.
> > > 
> > > > I'd love to be able to help you. My lappy loads ehci and lsusb shows the
> > > > controller, but I'll be darned if I can find the socket! I have other
> > > > things to get done right now, but if no-one beats me to it, I'll try the
> > > > desktop I have - I think that has ehci somewhere.
> > > 
> > > Thanks, Nigel.  You mean your laptop has an EHCI controller but no USB
> > > ports?  That's odd...
> > 
> > Yeah. I have three USB ports on it, but two of them seem to be connected
> > to one controller (going by lsusb after plugging my Palm into each of
> > them).
> 
> The contents of /proc/bus/usb/devices would be easier to read.
> Nevertheless, here's a capsule explanation:
> 
> Most high-speed USB host controllers aren't capable of supporting full
> speed or low speed.  In order to make a completely functional system,
> vendors have to pair each high-speed controller with a companion
> full-and-low-speed controller.  USB ports are wired internally to both
> controllers, and an electronic switch decides which controller actually
> manages the port at any time, based on the speed of the device plugged
> into the port.
> 
> Sometimes a single high-speed controller will have more than one
> companion.  For example, each companion controller might handle only two
> ports while the high-speed controller can handle six; in that case there
> would have to be three companions.
> 
> And sometimes controllers aren't connected to anything at all!  For
> example, I've got a PCI USB card on my machine.  It contains 1 EHCI (high
> speed) controller capable of handling six ports and 3 OHCI (full and low
> speed) each capable of handling two ports, as described above.  But the
> card has only 4 ports!  Each port is connected to the EHCI controller and
> to one of the OHCI controllers, and one OHCI is connected to nothing.  
> The card is a cut-down version of a 6-port model, and the manufacturer
> simply removed two of the ports while leaving the third OHCI controller on
> board.
> 
> As another example, my motherboard has three USB ports and three OHCI 
> controllers, each of which is capable of driving two ports but is wired up 
> only to one.
> 
> > > Anyway, here are instructions for you or anyone else who can do the test.  
> > > (I forgot to include them in the original message.)  Running the test
> > > involves two steps.
> > > 
> > > The first step is to check that an unpatched system supports Wake-on-USB.  
> > > This means enabling it in the BIOS and/or in ACPI (whatever that might
> > > entail; I have no idea what's needed) and actually trying it out.  Either
> > > plugging or unplugging a USB device while the system is in STD should wake
> > > the machine up.
> > > 
> > > The second step is to see whether Wake-on-USB continues to work after
> > > applying the patch mentioned previously.  That's the real question.
> > > 
> > > It may turn out that _nobody_ has Wake-on-USB working at all... in which 
> > > case we'd have a different problem to solve.
> > 
> > Thanks!
> 
> On further thought, I wonder if this could ever work reliably.  During 
> suspend-to-disk, after the memory snapshot is created every device is 
> woken up to write out the image (or at least, every device that was awake 
> before the suspend-to-disk started).  The image is written and then the 
> system shuts down, without bothering to suspend anything.
> 
> Now I don't know about other subsystems, but in USB we disable remote
> wakeup when a device is resumed and enable it when the device is
> suspended.  Since the sequence of events is <resume, write image,
> shutdown> with no intervening suspend, remote wakeup will not be enabled.
> 
> That's true for external devices, anyway.  For devices on the motherboard, 
> like host controllers, it's entirely possible that the firmware uses some 
> other technique to control remote wakeup (something involving ACPI, for 
> example).  Documentation on this point is almost non-existent, so it's 
> kind of hard to say anything definite.
> 
> This suggests that I shouldn't worry about remote wakeup during
> suspend-to-disk at all -- it's a lost cause.

Or we should change to suspend drivers rather than shutting them down,
if that's possible.

Regards,

Nigel

Re: Request for testing remote wakeup during STD

[Rafael J. Wysocki]

On Sunday, 11 February 2007 21:28, Nigel Cunningham wrote:
> Hi.
> 
> On Sun, 2007-02-11 at 14:44 -0500, Alan Stern wrote:
> > On Sun, 11 Feb 2007, Nigel Cunningham wrote:
> > 
> > > Hi.
> > > 
> > > On Sat, 2007-02-10 at 12:08 -0500, Alan Stern wrote:
> > > > On Sat, 10 Feb 2007, Nigel Cunningham wrote:
> > > > 
> > > > > Hi Alan.
> > > > 
> > > > > I'd love to be able to help you. My lappy loads ehci and lsusb shows the
> > > > > controller, but I'll be darned if I can find the socket! I have other
> > > > > things to get done right now, but if no-one beats me to it, I'll try the
> > > > > desktop I have - I think that has ehci somewhere.
> > > > 
> > > > Thanks, Nigel.  You mean your laptop has an EHCI controller but no USB
> > > > ports?  That's odd...
> > > 
> > > Yeah. I have three USB ports on it, but two of them seem to be connected
> > > to one controller (going by lsusb after plugging my Palm into each of
> > > them).
> > 
> > The contents of /proc/bus/usb/devices would be easier to read.
> > Nevertheless, here's a capsule explanation:
> > 
> > Most high-speed USB host controllers aren't capable of supporting full
> > speed or low speed.  In order to make a completely functional system,
> > vendors have to pair each high-speed controller with a companion
> > full-and-low-speed controller.  USB ports are wired internally to both
> > controllers, and an electronic switch decides which controller actually
> > manages the port at any time, based on the speed of the device plugged
> > into the port.
> > 
> > Sometimes a single high-speed controller will have more than one
> > companion.  For example, each companion controller might handle only two
> > ports while the high-speed controller can handle six; in that case there
> > would have to be three companions.
> > 
> > And sometimes controllers aren't connected to anything at all!  For
> > example, I've got a PCI USB card on my machine.  It contains 1 EHCI (high
> > speed) controller capable of handling six ports and 3 OHCI (full and low
> > speed) each capable of handling two ports, as described above.  But the
> > card has only 4 ports!  Each port is connected to the EHCI controller and
> > to one of the OHCI controllers, and one OHCI is connected to nothing.  
> > The card is a cut-down version of a 6-port model, and the manufacturer
> > simply removed two of the ports while leaving the third OHCI controller on
> > board.
> > 
> > As another example, my motherboard has three USB ports and three OHCI 
> > controllers, each of which is capable of driving two ports but is wired up 
> > only to one.
> > 
> > > > Anyway, here are instructions for you or anyone else who can do the test.  
> > > > (I forgot to include them in the original message.)  Running the test
> > > > involves two steps.
> > > > 
> > > > The first step is to check that an unpatched system supports Wake-on-USB.  
> > > > This means enabling it in the BIOS and/or in ACPI (whatever that might
> > > > entail; I have no idea what's needed) and actually trying it out.  Either
> > > > plugging or unplugging a USB device while the system is in STD should wake
> > > > the machine up.
> > > > 
> > > > The second step is to see whether Wake-on-USB continues to work after
> > > > applying the patch mentioned previously.  That's the real question.
> > > > 
> > > > It may turn out that _nobody_ has Wake-on-USB working at all... in which 
> > > > case we'd have a different problem to solve.
> > > 
> > > Thanks!
> > 
> > On further thought, I wonder if this could ever work reliably.  During 
> > suspend-to-disk, after the memory snapshot is created every device is 
> > woken up to write out the image (or at least, every device that was awake 
> > before the suspend-to-disk started).  The image is written and then the 
> > system shuts down, without bothering to suspend anything.
> > 
> > Now I don't know about other subsystems, but in USB we disable remote
> > wakeup when a device is resumed and enable it when the device is
> > suspended.  Since the sequence of events is <resume, write image,
> > shutdown> with no intervening suspend, remote wakeup will not be enabled.
> > 
> > That's true for external devices, anyway.  For devices on the motherboard, 
> > like host controllers, it's entirely possible that the firmware uses some 
> > other technique to control remote wakeup (something involving ACPI, for 
> > example).  Documentation on this point is almost non-existent, so it's 
> > kind of hard to say anything definite.
> > 
> > This suggests that I shouldn't worry about remote wakeup during
> > suspend-to-disk at all -- it's a lost cause.
> 
> Or we should change to suspend drivers rather than shutting them down,
> if that's possible.

I thought about the same thing.

Greetings,
Rafael

Re: Request for testing remote wakeup during STD

[Pavel Machek]

Hi!

> There have been reports of problems related to shutting down with remote 
> wakeup enabled on EHCI USB controllers in 2.6.20; see
> 
> 	http://bugzilla.kernel.org/show_bug.cgi?id=7828
> 
> In brief, some people have found that if ehci-hcd is loaded and the 
> controller is suspended when they try to shut down their systems, the 
> machine reboots immediately instead of turning off.  Apparently this is 
> caused by the firmware mistakenly thinking that a remote-wakeup event has 
> occurred.  Admittedly, remote wakeup from a system sleep is still black 
> magic to most of us...
> 
> I wrote a patch to try and fix the problem by turning off EHCI remote
> wakeup from within the driver's shutdown() method.  The patch is here:
> 
> 	http://bugzilla.kernel.org/attachment.cgi?id=10313&action=view
> 
> However I'm concerned that this might affect suspend-to-disk.  Some lucky 
> people have systems which do keep their EHCI controllers in D3hot during 
> STD, and such people might reasonably want Wake-on-USB to work properly.  
> It seems likely that the patch would prevent it from working.

I do not think such "lucky people" exist. And not being able to
control the wakeups.... no I do not think that feature is useful,
yet. KISS.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Request for testing remote wakeup during STD

[Alan Stern]

On Tue, 13 Feb 2007, Pavel Machek wrote:

> Hi!
> 
> > There have been reports of problems related to shutting down with remote 
> > wakeup enabled on EHCI USB controllers in 2.6.20; see
> > 
> > 	http://bugzilla.kernel.org/show_bug.cgi?id=7828
> > 
> > In brief, some people have found that if ehci-hcd is loaded and the 
> > controller is suspended when they try to shut down their systems, the 
> > machine reboots immediately instead of turning off.  Apparently this is 
> > caused by the firmware mistakenly thinking that a remote-wakeup event has 
> > occurred.  Admittedly, remote wakeup from a system sleep is still black 
> > magic to most of us...
> > 
> > I wrote a patch to try and fix the problem by turning off EHCI remote
> > wakeup from within the driver's shutdown() method.  The patch is here:
> > 
> > 	http://bugzilla.kernel.org/attachment.cgi?id=10313&action=view
> > 
> > However I'm concerned that this might affect suspend-to-disk.  Some lucky 
> > people have systems which do keep their EHCI controllers in D3hot during 
> > STD, and such people might reasonably want Wake-on-USB to work properly.  
> > It seems likely that the patch would prevent it from working.
> 
> I do not think such "lucky people" exist. And not being able to
> control the wakeups.... no I do not think that feature is useful,
> yet. KISS.

Okay, based on your feedback and that from others, I will submit the 
original simple patch.  Thanks.

Alan Stern