Comment 11 for bug 1412873

Hi. Sorry for long delay. I had not so much time for intensive testing.
After my further intensive testing, it looks the bad commit is known. I tested dozens of kernel versions, then narrowed the selection and kept bisecting it.
The result is it looks the problem is not among 3.2.60 and 3.2.66, but somewhere in 3.11.0.
My testing ended with this bad commit:

928bea964827d7824b548c1f8e06eccbbc4d0d7d is the first bad commit
commit 928bea964827d7824b548c1f8e06eccbbc4d0d7d
Author: Yinghai Lu <email address hidden>
Date: Mon Jul 22 14:37:17 2013 -0700

    PCI: Delay enabling bridges until they're needed

    We currently enable PCI bridges after scanning a bus and assigning
    resources. This is often done in arch code.

    This patch changes this so we don't enable a bridge until necessary, i.e.,
    until we enable a PCI device behind the bridge. We do this in the generic
    pci_enable_device() path, so this also removes the arch-specific code to
    enable bridges.

    [bhelgaas: changelog]
    Signed-off-by: Yinghai Lu <email address hidden>
    Signed-off-by: Bjorn Helgaas <email address hidden>

:040000 040000 92a05476999d94d327a9a9bde707b639ae289b79 703c1e016855c646e0d46f1713e1e950efe665c5 M arch
:040000 040000 ea2cd89493efd333fb73c88acd229538dcbd9662 ff41b86015d0fd2877a6ee072b95c8aeced83c5d M drivers
:040000 040000 f6c23efa102fc2c2ead5c86bdb65aa70719b1ab9 f3fdcb7b9e96514e4ca46e79a1208e4f6667abc9 M include

At the end I tested this bad commit 5 times also with the adjacent (last good) commit 55ed83a615730c2578da155bc99b68f4417ffe20.
I was able to suspend/resume 13 times with kernel built from commit 55ed83a615730c2578da155bc99b68f4417ffe20 - tested 5 times. Suspend/resume always worked properly.
With the bad commit 928bea964827d7824b548c1f8e06eccbbc4d0d7d I always suspended and resumed the pc 3 times and then fourth attempt to suspend ended with the frozen PC (Display off, HDD stopped spinning, but PC kept on and frozen). As I mentioned above, I repeated this procedure 5 times to prove it is not a coincidence. Interesting it always froze on 4th attempt of suspend.

Is it possible the "PCI: Delay enabling bridges until they're needed" caused this issue?

I also tested with Fedora core 22 with kernel version 4.0.4-301 and the suspend issue is present there as well, so I believe this is not related to Ubuntu system only.