hibernate/suspend immediately resumes

[Greg Woods]

Judging from the results of Google searches about this, this is a
problem that has been around for a while, but I have not found a
solution that works for my case. Most of the hits were on postings in
the Ubuntu forums, and regarding pretty old versions of Ubuntu at that
(which means they don't account for systemd, grub2, etc. if any of that
comes into play). So I thought I would ask here on the Fedora list.

This is for a brand-new machine with an ASUS Z-87 motherboard, Intel i5
Haswell processor (4 core, 64-bit) and fully updated F19 (64-bit).

The problem is that when doing a suspend or hibernate, the process
completes, but almost immediately the system resumes again. In the case
of hibernation, I have tried forcibly powering it off when the resume
starts. In that case, when I power it on again, the hibernated image
loads, but then the system hangs and never completes the resume. 

Just for completeness, the system also has a Windows 7 64-bit installed
OS, and that one is able to suspend and hibernate just fine, which would
seem to rule out hardware issues.

The solutions I found for Linux were of two types: disabling ACPI
wakeups (using "acpitool -W") and "unbinding" USB drivers (not sure
what
that even means). I've tried both approaches with no success. 

More details: I spent an entire evening last night fiddling with this
with no success, so I really REALLY don't want anyone coming back and
saying I haven't done my homework, or do some Google searches you idiot,
etc. (unless you can point me to the exact Google search I need to do).
I have done these things to the best of my ability already.

# acpitool -w
   Device       S-state   Status   Sysfs node
  ---------------------------------------
  1. UAR1         S4    *disabled  pnp:00:0a
  2. RP01         S4    *disabled  pci:0000:00:1c.0
  3. PXSX         S4    *disabled
  4. RP03         S4    *disabled  pci:0000:00:1c.2
  5. PXSX         S4    *enabled   pci:0000:03:00.0
  6. RP04         S4    *disabled  pci:0000:00:1c.3
  7. PXSX         S4    *disabled  pci:0000:04:00.0
  8. RP08         S4    *disabled  pci:0000:00:1c.7
  9. PXSX         S4    *disabled  pci:0000:08:00.0
  10. RP07        S4    *disabled  pci:0000:00:1c.6
  11. PXSX        S4    *disabled  pci:0000:06:00.0
  12. GLAN        S4    *disabled
  13. EHC1        S4    *enabled   pci:0000:00:1d.0
  14. EHC2        S4    *enabled   pci:0000:00:1a.0
  15. XHC         S4    *enabled   pci:0000:00:14.0
  16. HDEF        S4    *disabled  pci:0000:00:1b.0
  17. PEG0        S4    *disabled  pci:0000:00:01.0
  18. PEGP        S4    *disabled  pci:0000:01:00.0
  19. PEG1        S4    *disabled
  20. PEG2        S4    *disabled

So I tried disabling 5, 13, 14, and 15 ("acpitool -w 5" and so forth). 5
can't be disabled (at least, it still shows as "enabled" after running
"acpitool -W 5), so I assume that's the power button. The others show up
as "disabled" after doing this, but hibernate/suspend still resumes
immediately even after doing this.

"Unbinding" drivers is done with a shell script that looks like this:

==============================================================================
function unbind_usb {
    for driver in ehci-pci  firewire_ohci  ohci-pci  uhci_hcd  xhci_hcd;
do
        cd "/sys/bus/pci/drivers/${driver}";
        ids=$(ls | grep :);
        echo $ids > /var/tmp/DISABLED_$driver;
        for id in $ids; do
            echo "Unbinding $id";
            echo -n "$id" > unbind;
            disabled="$disabled $id";
        done;
    done;
}

function bind_usb {
    for driver in ehci-pci  firewire_ohci  ohci-pci  uhci_hcd  xhci_hcd;
do
        cd "/sys/bus/pci/drivers/${driver}";
        for id in $(cat /var/tmp/DISABLED_$driver); do
            echo "Binding $id";
            echo -n "$id" > bind;
        done;
        rm /var/tmp/DISABLED_$driver;
   done;
}

A script that calls unbind_usb on hibernate/suspend and calls bind_usb
on thaw/resume is placed in /usr/lib64/pm-utils/sleep.d/S50usbbind .
This does not work either.

The most aggravating thing is that I have another machine built from the
same hardware, and suspend/hibernate works fine on that one, without any
of this being necessary. So it may well come down to determining exactly
which drivers need to be unbound. The machine that doesn't work does
have a couple of additional cards in it (that provide extra USB ports
and some Firewire ports) which suggests the driver for one of those
cards is causing the problem. The original script wanted to unbind
everything that had *hci* in the name, but I found that if "ahci" was
unbound, then I could no longer access anything on the disk, and I had
to push the reset button to recover; maybe that is the hard disk driver.
So I can't just try unbinding everything.

Anything that can point me in the right direction here is greatly
appreciated.

--Greg

hibernate/suspend immediately resumes [SOLVED]

[Tim]

Allegedly, on or about 01 November 2013, Greg Woods sent:
>  And for completeness: I did have this same card in the old machine
>  that had the same issue. That machine was weirder because hibernate
>  worked but suspend didn't.  
Many many years ago, I had a similar hibernate/suspend foul-up on a
Windows machine, and fooling around with the plug-in cards sorted things
out.  One card just wouldn't let it work, so it had to be abandoned.
Another card needed moving around into a different slot, so it didn't
share IRQs with something else.

PC cards are notorious for all kinds of bad behaviour (not adhering to
specifications or standards, requiring special drivers to compensate for
bad hardware design, etc.).

-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64

All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.

George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.

hibernate/suspend immediately resumes [SOLVED]

[Greg Woods]

I remain surprised that nobody seems interested in this issue or that
nobody else seems to have seen it. I discovered while searching that I
myself posted about a similar problem on a different machine a couple of
years ago, and got zero response then too.

That said, what happened is that I built another machine from an
identical case, motherboard, and CPU, and lo and behold, the new machine
did not exhibit this problem; hibernate and suspend worked flawlessly.
It's a bit annoying that moving the mouse or pressing ANY key wakes the
machine up again, even from hibernation. Even bumping into the desk can
jiggle the mouse enough to wake the machine up, and there doesn't seem
to be any way to disable that. I couldn't find any relevant BIOS
settings, and even unbinding all the drivers and disabling all the ACPI
wakeups did not stop this from happening. But I can live with this.

So it had to come down to the few hardware differences between the two
machines, which means the PCI expansion cards. I tried removing them one
at a time from the problem system, and found that the problem was caused
by a Belkin x1 card that provides two Firewire and two USB 3.0 ports.
Remove this card from the system, and suspend and hibernate work again.

But I do need to have Firewire ports somewhere; I've got external disk
drives that only have Firewire or (slow) USB 1.0 ports. So I'll put the
Belkin card into the server/router box instead of the desktop box. The
server is up all the time so I don't care if it can't suspend. Not
ideal, but workable.

So I wouldn't really say I "solved" the problem, but I found a way to
work around it. 

And for completeness: I did have this same card in the old machine that
had the same issue. That machine was weirder because hibernate worked
but suspend didn't. 

--Greg