// thanks to @danomac, the feature itself is working for me again - check his link further down, but the real problem isn't solved, yet

After upgrading my kernel from 3.1.1 to 3.3.5 (both times gentoo-sources), I can no longer wake up this machine by pressing a key on the keyboard or clicking/moving the mouse, which used to work flawless before. Shortly pressing a key lights up the numlock-key, indicating it's under power, but nothing more happens - wake up via powerbutton works.

Here's a diff -u (~800 lines) between the two .config's and this is the output of `acpitool -w`

Not that this will help, but I have not been able to wake up via a USB attachment for over a year.
I can no longer hibernate either. Not me, the PC.
I can however suspend. Sure no mouse or keyboard hit or click will awaken, but as soon as I hit the power button, I have a resumed desktop within 5 seconds.
So why not just hit the power button?_________________Whatever you do, do it properly!

Because it's door->desk, reach over it, press key, walk around desk, sit, machine is one vs. walk a few meters more, press button, return - the machine is placed rather far away, which normally doesn't matter.

I googled around a little and so far found no other notices on other distributions where people are newly having this problem, only people who never had it working in the first place.

If I'd were better in kernel stuff or had a clue, where the problem might be located, I'd try to fix it, but I'm not really willing to `git bisect` over dozens of kernel changes._________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Yeah, sorry about that. I was going and documenting step-by-step what I was trying. It might help others troubleshoot this annoying problem though. It seems that /proc/acpi/wakeup now is not connected to /sys/devices/*... only when I directly toggled the hub in /sys/devices did the stupid thing start working again. I guess there's not much reason to keep the deprecated /proc/acpi in the kernel anymore.

Anyway, couldn't find something on gmane or via Google, any clue in what timeframe that thread may have been?_________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

I actually wrote a quick bash script to check and set these things, I posted it in the Tips & Tricks forum.

Testing.

What I'm wondering, if this is somehow device/chipset/... specific, cause my Macbook wakes up just fine without any special treatment, my desktop never did until I played with these things sometime last year.

Edit, Works, thanks.

(marking thread as 'workaround', since obviously there's some kind of misunderstanding or bug here)_________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Doesn't matter, as I said above, I'm running a pretty long time (>1 year) without /proc/acpi and wakeup still worked, up until the point where I did the initial post for this topic._________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Interestingly enough, on my computer /proc/acpi/wakeup still exists, even after removing the deprecated /proc/acpi directories and files from my kernel. I guess acpitool -w is still using /proc/acpi/wakeup but it does not reflect what is actually enabled under /sys/devices.

This patch (as1486) implements the kernel's new wakeup policy for USB
host controllers. Since they don't generate wakeup requests on their
but merely forward requests from their root hubs toward the CPU, they
should be enabled for wakeup by default.

Also, to be compliant with both the old and new policies, root hubs
should not be enabled for remote wakeup by default. Userspace must
enable it explicitly if it is desired.

So it is fully up to userspace tools (or maybe custom udev rules? Haven't tried that) to re-enable devices that no longer work.

Though I must say, this pisses me off more then just a little bit. It's a change in default behaviour and there was no notice while building the kernel. Might as well use Fedora/SUSE and let them work for me _________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Though I must say, this pisses me off more then just a little bit. It's a change in default behaviour and there was no notice while building the kernel. Might as well use Fedora/SUSE and let them work for me

That's an upstream change. They change stuff all the time without warning people. I still remember my scsi driver failing to build because they changed something in the kernel.

Strange, I didn't run any updates for a while and out of the blue, I've got the same problem again - though your tool showing everything as enabled. Updating the system&kernel to the latest revisions in portage didn't help either _________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Aha, for some reason, pretty much everything in /proc/acpi/wakeup was set to disabled. Blindly enabling every device here helped and it's working again. Thanks._________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.