Bug 9258

See also: http://lkml.org/lkml/2007/11/1/163

It has been verified that unloading ehci-hcd before hibernation fixes the problem (http://lkml.org/lkml/2007/10/29/443).

The same issue has been reported to appear on another system and, again, unloading the ehci-hcd before hibernation makes it go away (http://lkml.org/lkml/2007/11/22/33).

I had been observing a similar issue with suspend to RAM on a desktop box I used to have access to (hopefully, I'll have access to it again in the future).  Namely, the box rebooted instead of suspending to RAM and unloading ehci-hcd before the suspend also helped (ie. with ehci-hcd unloaded the box suspended correctly).

Moreover, one report I received said that EHCI caused device_suspend(PMSG_SUSPEND) in hibernation_platform_enter() (as in the current Linus' tree) to fail (ie. when hibernating with ehci-hcd unloaded, the device_suspend(PMSG_SUSPEND) was successfully executed).

Of course, the last issue may be unrelated to the $subject problem, but clearly we have a pattern here.

Do I understand correctly that this hardware has an Intel ICH southbridge, and thus its USB setup has a bunch of UHCIs without PCI PM support combined with one EHCI that does have such support?  (And no other USB controllers?)

Regardless, please provide "lspci -vv" output, /proc/acpi/wakeup, and a dump of the ACPI DSDT.  This isn't a good bug report.  And I think Maxim ought to be on the CC list, since he's the real reporter...

The ACPI wakeup handling has always been problematic, including bad integration with PCI and the driver model.  Some patches over the last year may have worsened the problem.  And since the patches to provide sane integration have remained un-merged (since January) ...

Can you confirm that leaving /proc/acpi/wakeup alone -- everything OFF -- gives a system that hibernates OK?

On Saturday, 24 of November 2007, bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9258
> 
> 
> 
> 
> 
> ------- Comment #3 from dbrownell@users.sourceforge.net  2007-11-24 12:43
> -------
> Do I understand correctly that this hardware has an Intel ICH southbridge,
> and
> thus its USB setup has a bunch of UHCIs without PCI PM support combined with
> one EHCI that does have such support?  (And no other USB controllers?)

Very probably.
 
> Regardless, please provide "lspci -vv" output, /proc/acpi/wakeup, and a dump
> of
> the ACPI DSDT.  This isn't a good bug report.  And I think Maxim ought to be
> on
> the CC list, since he's the real reporter...

Yes, but Martin has no Bugzilla account, apparently.

> The ACPI wakeup handling has always been problematic, including bad
> integration
> with PCI and the driver model.  Some patches over the last year may have
> worsened the problem.  And since the patches to provide sane integration have
> remained un-merged (since January) ...
> 
> Can you confirm that leaving /proc/acpi/wakeup alone -- everything OFF --
> gives
> a system that hibernates OK?

That's been confirmed already, see http://lkml.org/lkml/2007/10/29/45 .

So if leaving /proc/acpi/wakeup alone makes things work better, this is basically an issue with ACPI (non) integration.  I'll have to have a look.

First I have to see if hibernation and STR work again for me.  Last times I've tried (x86_64) STR hung, and hibernation borked on resume (timer irqs seemed to stop firing, only peripheral irqs caused progress).

(In reply to comment #5)
> So if leaving /proc/acpi/wakeup alone makes things work better, this is
> basically an issue with ACPI (non) integration.  I'll have to have a look.

Can you explain what exactly I should test? My /proc/acpi/wakeup has everything but LID and SLPB disabled. But even if I disable these two my notebook will still wake up. The only thing so far that fixes hibernation here is echo shutdown > /sys/power/disk. Note that I have this problem only if the laptop is in the docking station. Outside of it hibernation works perfectly.

My laptop is a Lenovo X61 Tablet with ICH8 southbridge, 4*UHCI+2*EHCI controllers. I will attach lspci, /proc/acpi/wakeup and the acpi tables (if you tell me how to dump those).

(In reply to comment #6)
> (In reply to comment #5)
> > So if leaving /proc/acpi/wakeup alone makes things work better, this is
> > basically an issue with ACPI (non) integration.  I'll have to have a look.
> 
> Can you explain what exactly I should test? My /proc/acpi/wakeup has
> everything
> but LID and SLPB disabled. But even if I disable these two my notebook will
> still wake up. The only thing so far that fixes hibernation here is echo
> shutdown > /sys/power/disk.

Can you try to replace "error = device_suspend(PMSG_SUSPEND);" in kernel/power/disk.c:hibernation_platform_enter() with "device_shutdown();" and see if that works with "platform > /sys/power/disk", please?

Also, if I understood your last reply in the email thread correctly, unloading ehci-hcd before hibernation helps even with "platform > /sys/power/disk".  Can you confirm, please?

(In reply to comment #7)
> Can you try to replace "error = device_suspend(PMSG_SUSPEND);" in
> kernel/power/disk.c:hibernation_platform_enter() with "device_shutdown();"
> and
> see if that works with "platform > /sys/power/disk", please?

Yes, that works.

> Also, if I understood your last reply in the email thread correctly,
> unloading
> ehci-hcd before hibernation helps even with "platform > /sys/power/disk". 
> Can
> you confirm, please?

As of now, there are three possibilities to successfully hibernate my laptop while in the docking station:

1) vanilla kernel without USB
   - works in both platform and shutdown mode

2) vanilla kernel with USB
   - works only in shutdown mode, in platform mode the bug manifests

3) patched kernel (as described in comment #7)
   - works in both platform and shutdown mode

Well, no USB at all is a bit too coarse grained.

Can you try 2), but _without_ the EHCI HCD driver?

It sounds like this particular problem is caused by some interaction between the docking station and the computer.  It would be interesting to find out exactly what is causing the EHCI controller to issue a wakeup signal.  A good place to start would be to edit ehci_bus_resume() in drivers/usb/host/ehci-hub.c.  In the first "while (i--)" loop, add an ehci_dbg() statement displaying the value of i and the value of temp after the ehci_readl() and before the "temp &= ...".

Of course, the BIOS may mess up the port status values before ehci-hcd is able to read them.  Not much we can do about that, although disabling USB Legacy support in the BIOS might help.

The problem about EHCI failing the device_suspend() call is probably completely unrelated.  If it is reproducible, we ought to be able to debug it.

(In reply to comment #9)
> Well, no USB at all is a bit too coarse grained.
> 
> Can you try 2), but _without_ the EHCI HCD driver?

$ grep USB .config | grep -v ^#
CONFIG_USB_HID=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_SUSPEND=y
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_STORAGE=y

1) ehci_hcd loaded
   - platform mode: notebook reboots
   - shutdown mode: works correctly

2) ehci_hcd not loaded
   - platform mode: works correctly
   - shutdown mode: works correctly

No matter how many times I load/unload ehci_hcd, ehci_hcd+platform mode reboots while all other combinations don't. That's consistent with what Maxim said in his email.

Thanks, I misunderstood your previous comment.

BTW, shutdown mode works with ehci_hcd loaded exactly because it uses device_shutdown() to power off devices (that's why I asked you to try to replace device_suspend(PMSG_SUSPEND) with it in Comment #7).

"$i readl() = $temp", wereHamster as prefix so I could easily grep it. This is after one hibernate/resume cycle.

ehci_hcd 0000:00:1a.7: wereHamster: 3 readl() = 0x00001803
ehci_hcd 0000:00:1a.7: wereHamster: 2 readl() = 0x00001000
ehci_hcd 0000:00:1a.7: wereHamster: 1 readl() = 0x00001000
ehci_hcd 0000:00:1a.7: wereHamster: 0 readl() = 0x00001803
ehci_hcd 0000:00:1d.7: wereHamster: 3 readl() = 0x00001000
ehci_hcd 0000:00:1d.7: wereHamster: 2 readl() = 0x00001000
ehci_hcd 0000:00:1d.7: wereHamster: 1 readl() = 0x00001000
ehci_hcd 0000:00:1d.7: wereHamster: 0 readl() = 0x00001000

That's odd.  I would expect to see the PORT_WKOC_E|PORT_WKDISC_E|PORT_WKCONN_E bits set.

Here's another experiment to try.  Before suspending, do:

   echo disabled >/sys/bus/usb/devices/usbN/power/wakeup

where N is the bus number corresponding to the 1a.7 device.

Disabling wakeup only on the bus of the device 1a.7 was not enough, I also had to disable bus 1 (which has device 1a.0). Coincidently it's only these two buses that have devices on them. I have to disable wakeup on both and then hibernate works, disabling only on either one is not enough.

I'm attaching lsusb and lspci.

Created attachment 13740 [details]
lsusb -vv

Created attachment 13741 [details]
lspci -vv

The output from lsusb is very difficult to read.  /proc/bus/usb/devices contains the important information in a much more concise form.

I'm going to go out on a limb and guess that UHCI has nothing to do with the problem.  I bet that if you move that external hub (the ChipsBnk one) to the other ports on that 1a.7 controller, you'll find that on two of the ports you have to disable wakeup on 1a.0 and on the other two you have to disable wakeup on 1a.1 (bus 2).  This would prove that the EHCI controller is handing those ports over to its companions, and most likely the connect-status change is what causes the wakeup.

(In reply to comment #19)
> The output from lsusb is very difficult to read.  /proc/bus/usb/devices
> contains the important information in a much more concise form.

I seem to have disabled procfs support in the usb subsystem, because that file doesn't exist. Is it important?

> I'm going to go out on a limb and guess that UHCI has nothing to do with the
> problem.  I bet that if you move that external hub (the ChipsBnk one) to the
> other ports on that 1a.7 controller, you'll find that on two of the ports you
> have to disable wakeup on 1a.0 and on the other two you have to disable
> wakeup
> on 1a.1 (bus 2).  This would prove that the EHCI controller is handing those
> ports over to its companions, and most likely the connect-status change is
> what
> causes the wakeup.

I had no external usb devices attached to the system. The fingerprint reader is built into the laptop and the hub seems to be one that is built into the docking station - if I have the laptop outside of the dock that device disappears.

On Saturday 24 November 2007 23:16:16 Rafa

Reply-To: david-b@pacbell.net

On Sunday 25 November 2007, Maxim Levitsky wrote:
> I am suggesing to add a module param to ehci_hcd, to make it not 
> call pci_enable_wake if set.

It should be sufficient to use the existing "wakeup" attribute
in sysfs.  Right now it says "enabled"; write "disabled" instead.

On my system the sysfs file is

  /sys/devices/pci0000:00/0000:00:02.2/power/wakeup

but of course that's highly platform-specific.

- Dave

In reply to comment #20:  Don't worry about /proc/bus/usb/devices, it doesn't matter.
The problem appears to be caused by the hub that's built into the dock.  An interesting experiment would be to see what happens when the notebook is undocked and you have a normal high-speed USB device plugged in, like a flash drive.

In reply to comment #21:  It's not at all clear that the PME# from EHCI is the entire cause.  One of Tomas's tests suggests that a wakeup signal actually comes from UHCI, but EHCI is responsible for creating the condition that turns the signal on.  Note that disabling wakeup on the EHCI controller wasn't sufficient to prevent Tomas's machine from resuming immediately.

If you're still looking for an example of a high-speed USB device with wakeup capability, the easiest answer is a hub.

On Monday 26 November 2007 04:38:56 David Brownell wrote:
> On Sunday 25 November 2007, Maxim Levitsky wrote:
> > I am suggesing to add a module param to ehci_hcd, to make it not 
> > call pci_enable_wake if set.
> 
> It should be sufficient to use the existing "wakeup" attribute
> in sysfs.  Right now it says "enabled"; write "disabled" instead.
> 
> On my system the sysfs file is
> 
>   /sys/devices/pci0000:00/0000:00:02.2/power/wakeup
> 
> but of course that's highly platform-specific.
> 
> - Dave
> 


Yes, you are almost right.

This helps:
echo "disabled" > /sys/devices/pci0000:00/0000:00:1a.7/usb3/power/wakeup
echo "disabled" > /sys/devices/pci0000:00/0000:00:1d.7/usb4/power/wakeup

Note that /usb4/ is necessary, since unfortunately generic USB host controller code 
(usb/core/hcd-pci.c) looks at wakeup attribute of usb controller, rather that at 
similar attribute of pci device.
And since like I said it seems like a hardware bug, I have to disable both EHCI controllers.
(And some time before, I brought an old keyboard and mouse, and tested without usb devices, but result
was all but the same. I test this again tomorrow)


Best regards,
	Maxim Levitsky

On Monday 26 November 2007 05:03:01 bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9258
> 
> 
> 
> 
> 
> ------- Comment #23 from stern@rowland.harvard.edu  2007-11-25 19:03 -------
> In reply to comment #20:  Don't worry about /proc/bus/usb/devices, it doesn't
> matter.
> The problem appears to be caused by the hub that's built into the dock.  An
> interesting experiment would be to see what happens when the notebook is
> undocked and you have a normal high-speed USB device plugged in, like a flash
> drive.
> 
> In reply to comment #21:  It's not at all clear that the PME# from EHCI is
> the
> entire cause.  One of Tomas's tests suggests that a wakeup signal actually
> comes from UHCI, but EHCI is responsible for creating the condition that
> turns
> the signal on.  Note that disabling wakeup on the EHCI controller wasn't
> sufficient to prevent Tomas's machine from resuming immediately.
> 
> If you're still looking for an example of a high-speed USB device with wakeup
> capability, the easiest answer is a hub.
Interesting, having 8 USB ports (with a option of addition two) I didn't yet use one.

I keep looking,
	Best regards,
		Maxim Levitsky

PS: BTW the bugzilla isn't bad at all, since it converts mails to comments
and vice verso.

(In reply to comment #23)
> In reply to comment #20:  Don't worry about /proc/bus/usb/devices, it doesn't
> matter.
> The problem appears to be caused by the hub that's built into the dock.  An
> interesting experiment would be to see what happens when the notebook is
> undocked and you have a normal high-speed USB device plugged in, like a flash
> drive.

Even after I plugged in a SanDisk USB 2.0 flash drive it didn't reboot. Should I try with a hub with external power cord? We may have one at home, but I'm not sure.

What did your "wereHamster" patch show with the flash drive plugged in?

(In reply to comment #27)
> What did your "wereHamster" patch show with the flash drive plugged in?
> 

ehci_hcd 0000:00:1a.7: wereHamster: 3 readl() = 0x00001000
ehci_hcd 0000:00:1a.7: wereHamster: 2 readl() = 0x00001803
ehci_hcd 0000:00:1a.7: wereHamster: 1 readl() = 0x00001000
ehci_hcd 0000:00:1a.7: wereHamster: 0 readl() = 0x00001803
ehci_hcd 0000:00:1d.7: wereHamster: 3 readl() = 0x00001000
ehci_hcd 0000:00:1d.7: wereHamster: 2 readl() = 0x00001000
ehci_hcd 0000:00:1d.7: wereHamster: 1 readl() = 0x00001000
ehci_hcd 0000:00:1d.7: wereHamster: 0 readl() = 0x00001000

and 

ehci_hcd 0000:00:1a.7: wereHamster: 3 readl() = 0x00001000
ehci_hcd 0000:00:1a.7: wereHamster: 2 readl() = 0x00001000
ehci_hcd 0000:00:1a.7: wereHamster: 1 readl() = 0x00001000
ehci_hcd 0000:00:1a.7: wereHamster: 0 readl() = 0x00001803
ehci_hcd 0000:00:1d.7: wereHamster: 3 readl() = 0x00001000
ehci_hcd 0000:00:1d.7: wereHamster: 2 readl() = 0x00001000
ehci_hcd 0000:00:1d.7: wereHamster: 1 readl() = 0x00001000
ehci_hcd 0000:00:1d.7: wereHamster: 0 readl() = 0x00001803

depending on where the USB stick was: first in the one slot on the left side of the notebook, then in one of the two slots on the right side. Seems like the one left slot is 1a.7 (i = 2), the two right slots 1d.7 (i = 0 and 1).

While we're debugging it, the following workarounds should be suitable AFAICS:

(1) unload ehci_hcd before hibernation/suspend
(2) hibernate in the shutdown mode (ie. do "echo shutdown > /sys/power/disk" before hibernation or use the "shutdown method = shutdown" for s2disk).

Or even better workaround:

Figure what PCI devices are ehci:

maxim@MAIN:~$ lspci | grep EHCI
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1 (rev 02)

and then:

echo "disabled" > /sys/devices/pci0000:00/0000:00:1d.7/power/wakeup
echo "disabled" > /sys/devices/pci0000:00/0000:00:1a.7/power/wakeup

Tomas, can you try doing the experiment with the external hub and no dock?

(In reply to comment #31)
> Tomas, can you try doing the experiment with the external hub and no dock?

Turns out we don't have a separate USB hub. But I found one built into the TFT monitor on my desktop computer. I hope that's enough of a hub, this is the dmesg output when I plugged it into the laptop:

usb 6-1: new high speed USB device using ehci_hcd and address 8
usb 6-1: configuration #1 chosen from 1 choice
hub 6-1:1.0: USB hub found
hub 6-1:1.0: 2 ports detected
usb 6-1.1: new full speed USB device using ehci_hcd and address 9
usb 6-1.1: configuration #1 chosen from 1 choice
input: Logitech USB Receiver as /devices/pci0000:00/0000:00:1d.7/usb6/6-1/6-1.1/6-1.1:1.0/input/input17
input,hidraw0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:1d.7-1.1
input: Logitech USB Receiver as /devices/pci0000:00/0000:00:1d.7/usb6/6-1/6-1.1/6-1.1:1.1/input/input18
input,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1d.7-1.1

lsusb output shows these two devices:
Bus 006 Device 003: ID 046d:c51a Logitech, Inc. 
Bus 006 Device 002: ID 0409:005a NEC Corp.

As you can see I have a Logitech wireless mouse plugged into the hub. Suspend to Disk, using platform mode, works nicely. This is with 2.6.24-rc5.

With that hub plugged into the notebook while outside of the dock, hibernate works as expected, meaning that no workaround is needed. (The monitor was powered on, so I suppose the hub was, too, during the whole time)

If you really need me to test with a standalone external hub, I guess I could spend a few bucks on that.

There's no need for a standalone hub; the hub in your monitor was good enough.  The result indicates that the ehci-hcd driver isn't doing anything wrong, since the test worked as expected.

I don't have any ideas for fixing this.  It may not be possible to fix it without changing the BIOS.  But you can always work around the problem by disabling remote wakeup on those two controllers, which is a simple solution.

In fact, I have suggested in the past that people might always want to disable remote wakeup on their USB devices or controllers during suspend and hibernation.  A typical case might be suspending a laptop with a USB mouse or keyboard; you wouldn't want the sleeping computer to wake up the moment you unplug the mouse/keyboard!

So, should it be resolved to WILL_NOT_FIX?

Maybe it should.  We should make all the USB host controller drivers automatically disable remote wakeup during initialization, but that would needlessly affect people (how many? -- I don't know) who do rely on USB wakeups during suspend.

If nobody can come up with a better idea, I guess WILL_NOT_FIX is best.  Is there anyone at IBM or Intel who might be able to help?

BTW, recently I tried to dig this bug out, and after lot of work 
I came to conclusion that it is probably a hardware bug.

On my system(and probably most ACPI systems) actual S0->Sn transaction is done
via south bridge.

I modified Suspend to ram code such that it does the same, but at the end it enters S4, and as expected system turned on instantly.

So the conclusion is that if I tell southbridge to go to S3 it works fine.
If I tell it to go to S4 it wakes up the system

Btw, on my system USB doesn't wake from S4, and ACPI wakeup sources for usb also say that.

So maybe as a partial solution (workaround) the ehci_hcd should look at acpi tables, and see whenever ehci controllers have their wakeup source in S4, and if don't don't enable pci wake?

Still this won't fix systems that wake from S3 in same way.

Regards,
    Maxim Levitsky

Reply-To: david-b@pacbell.net

On Sunday 25 November 2007, Maxim Levitsky wrote:
> echo "disabled" > /sys/devices/pci0000:00/0000:00:1d.7/usb4/power/wakeup
> 
> Note that /usb4/ is necessary, since unfortunately generic USB host
> controller code 
> (usb/core/hcd-pci.c) looks at wakeup attribute of usb controller, rather that
> at 
> similar attribute of pci device.

For the record, that code actually looks at both devices:

	int wake = device_can_wakeup(&hcd->self.root_hub->dev);

	wake = wake && device_may_wakeup(hcd->self.controller);

In English:  it will try to enable PME# if the root hub will be
issuing it (sometimes there are silicion errata) and the upstream
(PCI) link policy has been set so it's allowed.

On PCs there are actually three hardware mechanisms interacting:

 - The root hub relates to the downstream (USB) link wakeup
   signaling, which is used among other things for runtime
   suspend (on all non-broken hardware).  This is controlled
   by a driver model flag, defaulting to "enabled".

 - The PCI device relates to the upstream link, saying whether
   or not it should issue PME#; also controlled using driver
   model flags, defaulting to "enabled".

 - ACPI generally needs to enable some GPE associated with that
   device's PME# line ... I'm not quite sure of the model here,
   I guess ACPI presumes a non-shared PME#.  This is currently
   supposed to be controlled by /proc/acpi/wakeup flags (defaulting
   to *DISABLED* note!) and to only affect system sleep.  (Because
   ACPI doesn't yet integrate with driver model wakeup flags.  It
   should use PCI device flags here, instead of nonportable stuff.)

I think *ALL* three mechanisms should be told not to enable wakeup
signaling. Otherwise it's not unlikely that some stray signal path
could trigger an un-asked-for wakeup ... not unlike $BUGREPORT.

Alternatively, the ACPI sequencing issues that have been getting some
discussion elsewhere could explain problems here too.

It should *absolutely* be possible to have EHCI loaded, with FLAG_CF
set, and have system suspend/resume cycle not trigger wakeups.  If
just having CF set causes the resume -- where Linux didn't enable even
one of those mechanisms -- then the issue must be some non-Linux code.
BIOS that is, likely ACPI-ish... either bugs in that code, or in how
Linux talks to it.

it would be interesting to know the symptom of this bug in 2.6.27. :)

Accidentally I  hit that bug few days ago, same thing.

I disable ehci wakeup in sysfs as workaround

I think we've fixed the problem already. But I forget which commit did this. alan, do you have any idea?

Maxim, please re-open this bug if it still exists in the latest kernel release.

*** Bug 12721 has been marked as a duplicate of this bug. ***

*** Bug 12643 has been marked as a duplicate of this bug. ***

Has it been fixed?  I have no idea.  None of the original bug reporters has said what happens with a recent kernel.

It's possible that some of Rafael's changes to the suspend sequence may have fixed the problem.  If they haven't, I don't know what we can do.

Is 2.6.28.3 not recent?

I have no idea about any work gong on to fix this except marking my bug as dupe of this.

I just tried current git (as of 2009-03-19, post 2.6.29-rc8) and the problem is still present.

Details for my system are available in the report that I made and which was now marked as duplicate:

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

(In reply to comment #43)
> Has it been fixed?  I have no idea.  None of the original bug reporters has
> said what happens with a recent kernel.
> 
> It's possible that some of Rafael's changes to the suspend sequence may have
> fixed the problem.  If they haven't, I don't know what we can do.

No, they haven't.

The problem is that on some systems EHCI generates wake-up events even if doesn't appear to be configured to do so.  For now, no one knows what to do to prevent it from doing it.

*** Bug 12643 has been marked as a duplicate of this bug. ***

This problem still remains in 2.6.30-rc1 (I am not able to adjust the version information for this bug).

Rafael, I think you should change this to WILL NOT FIX.  Not only do we not know the cause of the problem, it appears to manifest differently on different systems.

For example, comment #32 says that it occurs only when the laptop is attached to a docking station.  Comment #24 says nothing about a docking station but also says that the problem goes away when the EHCI "wakeup" attributes are turned off.  But in 2.6.30-rc1 those attributes should always be turned off by default.  Daniel, can you check to make sure they are?

> But in 2.6.30-rc1 those attributes should always be turned off by
> default.  Daniel, can you check to make sure they are?

Actually that seems not to be the case here:

localhost:~> uname -a
Linux localhost.localdomain 2.6.30-rc1-00136-g62b8e68 #2 PREEMPT Fri Apr 10 14:32:38 EEST 2009 i686 i686 i386 GNU/Linux
localhost:~> cat /sys/devices/pci0000:00/*/usb*/power/wakeup
enabled
enabled
enabled
enabled
enabled
localhost:~>

> > But in 2.6.30-rc1 those attributes should always be turned off by
> > default.  Daniel, can you check to make sure they are?
> 
> Actually that seems not to be the case here:
> 
> localhost:~> uname -a
> Linux localhost.localdomain 2.6.30-rc1-00136-g62b8e68 #2 PREEMPT Fri Apr 10
> 14:32:38 EEST 2009 i686 i686 i386 GNU/Linux
> localhost:~> cat /sys/devices/pci0000:00/*/usb*/power/wakeup
> enabled
> enabled
> enabled
> enabled
> enabled

You're looking at the attributes for the wrong devices.  Try 
/sys/devices/pci0000:00/*/usb*/../power/wakeup.

> You're looking at the attributes for the wrong devices.  Try
> /sys/devices/pci0000:00/*/usb*/../power/wakeup.

Ok, they're disabled:

localhost:~> uname -a
Linux localhost.localdomain 2.6.30-rc1-00136-g62b8e68 #2 PREEMPT Fri Apr 10 14:32:38 EEST 2009 i686 i686 i386 GNU/Linux
localhost:~> cat /sys/devices/pci0000:00/*/usb*/../power/wakeup
disabled
disabled
disabled
disabled
disabled
disabled
disabled
disabled
disabled
disabled
localhost:~>

In bug #11268 I have hitting the same problem, it turns out it's this USB bug. This is what ASUS has to say about this issue (it also happens in vista):

"If this phenomenon still persists, it may be caused by VISTA OS.  VISTA does
not allow system to enter Standby mode, if "Allow this device to bring the
computer out of standby" for an USB or PS/2 wake-supported device (such as
mouse or keyboard) has been checked under "Device Manager", while the USB or
PS/2 port has not switched its power mode to +5VSB that allows delivery of
standby power to USB or PS/2 ports under soft OFF state. Because VISTA enables
this standby option per default, and motherboards often set USB power modes to
+5V at the same time, these two settings may result in conflict, hence
resulting this phenomenon."

Does turning off the power/wakeup attribute for the EHCI root hubs solve the problem?

> Does turning off the power/wakeup attribute for the EHCI root hubs solve
> the problem?

I did

root@localhost:~# echo disabled > /sys/devices/pci0000:00/0000:00:1d.7/usb1/power/wakeup
root@localhost:~# pm-hibernate

but my system still resumed immediately.

Thanks.

Ouch, I should have answered a lot of time ago...

#54 Yes, I turn off the attributes but that doesn't help (just like #55)

(In reply to comment #56)
> Ouch, I should have answered a lot of time ago...
> 
> #54 Yes, I turn off the attributes but that doesn't help (just like #55)

Well, that was some months ago. It seems to work now...with 2.6.31-05315-gab86e57

I now tested with 2.6.31 and even after echo disable > power/wakeup my system resumes instantly.

Hi, can you test disabling the wakeup-attributes with 2.6.32 or 2.6.33? 

In comment #57 (something/it?) was reported to be fixed _after_ 2.6.31 ... 

cheers,
Flo

> Hi, can you test disabling the wakeup-attributes with 2.6.32 or 2.6.33?

Unfortunately it still does not work:

> Hi, can you test disabling the wakeup-attributes with 2.6.32 or 2.6.33?

Unfortunately it still does not work:

root@localhost:~# uname -a
Linux localhost 2.6.33.2-57.fc13.i686.PAE #1 SMP Tue Apr 20 08:58:17 UTC 2010 i686 i686 i386 GNU/Linux
root@localhost:~# for f in /sys/devices/pci0000:00/*/usb*/power/wakeup ; do echo disabled > $f ; done
root@localhost:~# pm-hibernate 

The machine still resumes immediately.

Thanks.

hi daniel!
sorry if i overlooked it but i have 2 open questions: 
1) unloading the ehci module does fix this for you? (i.e. the computer stays suspended...) 
2) you have bisected your problem to the same commit? if not, do you have a commit to blame?


do you think maybe that this email-thread is relevant to your problem?
http://groups.google.com/group/linux.kernel/browse_thread/thread/65e56723cc19124f/398de1664d2091a1?lnk=raot
if so, can you check if the (2nd) proposed patch works for you?


thx,
Flo

ping...

Hi Florian, thanks for looking into this.

> 1) unloading the ehci module does fix this for you? (i.e. the computer stays
> suspended...) 

Yes, I tested this earlier, please see:

https://lists.linux-foundation.org/pipermail/linux-pm/2009-January/019251.html

> 2) you have bisected your problem to the same commit? if not, do you have a
> commit to blame?

Yes, the offending commit was bisected the it was deemed to necessary anyway, please see:

https://lists.linux-foundation.org/pipermail/linux-pm/2009-January/019225.html

More discussion about my case was in my original report which was marked as a duplicate for this one:

https://bugzilla.kernel.org/show_bug.cgi?id=12721

Thanks.

ok. 

in comment #55 you said that you only disabled your ehci bus wakeup, but Thomas above says he needed to disable it even for some non-ehci bus... did you try to disable all your usb*/power/wakeup too?

Great news, just tested F14ß / 2.6.35.4 and now suspend works ok (=no more instant resume)! This is without disabling anything.

Did you test a fedora kernel, or kernel.org?

If it is still broken on the current kernel.org kernels,  we probably need to poke someone to get the fix into mainline...

> Did you test a fedora kernel, or kernel.org?

I've now tested both, the current F14 kernel and 2.6.36 from kernel.org, both are working fine!

Nice. Another one bites the dust. :)