[Gigabyte GA-H61M-D2H rev. 1.0] Sometimes does not suspend

[stan383]

Hi,
I have this issue since upgrading from ubuntu 13.10 to 14.04. The issue is still present even after upgrade to 14.10.
The problem is that system sometimes does not suspend correctly. After initiating suspend the display is being turned off completely, HDDs are being stopped, but fan remains ON and the PC LED also stays on. The only possibility is to make hard reset using the HW button on the pc. Pressing power button will neither suspend/turn off computer nor turn in on again. I can reproduce this issue randomly - approximately 1 out of 5 suspends will fail. It looks first suspend after reboot will always work fine. Then some of the suspends after successfull resume will fail (randomly). I also tried fresh install of Ubuntu 14.10, but the suspend kept failing as well.
Checking /var/log/pm-suspend.log did not help me as there is always "performing suspend" message either after correct suspend or failed suspend.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: linux-image-3.16.0-24-generic 3.16.0-24.32
ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4
Uname: Linux 3.16.0-24-generic x86_64
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ygzo 5008 F.... pulseaudio
CurrentDesktop: Unity
Date: Tue Jan 20 17:34:22 2015
HibernationDevice: RESUME=UUID=5c7a99f0-ca4d-4b61-bf3c-118fa145440d
InstallationDate: Installed on 2014-04-18 (277 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
MachineType: Gigabyte Technology Co., Ltd. H61M-D2H
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-24-generic root=UUID=0cb350ba-8e96-4ac3-ac78-73547f8ada58 ro quiet splash
RelatedPackageVersions:
 linux-restricted-modules-3.16.0-24-generic N/A
 linux-backports-modules-3.16.0-24-generic N/A
 linux-firmware 1.138
RfKill:

SourcePackage: linux
UpgradeStatus: Upgraded to utopic on 2014-10-28 (84 days ago)
dmi.bios.date: 05/18/2012
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F5
dmi.board.name: H61M-D2H
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF5:bd05/18/2012:svnGigabyteTechnologyCo.,Ltd.:pnH61M-D2H:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnH61M-D2H:rvr:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: H61M-D2H
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.19 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-rc5-vivid/

[stan383 (stan383)]

I tested also with the latest upstream kernel as advised, but unfortunately the issue is still present there.

[stan383 (stan383)]

Mr. Christopher, I have different motheboard than you mentioned. My motherboard is without USB3 support, so it is
GA-H61M-D2H, not GA-H61M-D2H-USB3. Plus, there are 2 revisions of my motherboard - rev 1.0 and rev 1.2. I own rev 1.0 for which the most recent BIOS is version F5 which I already had installed during testing and sending this bug report. The most recent BIOS for my motherboard can be found here - http://www.gigabyte.com/products/product-page.aspx?pid=4002#bios
So the problem is present with the latest version of BIOS for my motherboard.

Output of sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date:

F5
05/18/2012

I do not know if it is important to mention, but maybe it can be helpful, so I will mention it - I tested suspend with debian 7.7.0 which uses much older version of kernel and the problem is not present there - I was able to suspend PC approx. 20 times without problem.

[penalvch (penalvch)]

Stanislav Kukla, thank you for clarifying your motherboard model, and advising to your Debian testing.

Could you please test a similar version number to the Debian kernel in Ubuntu via https://wiki.ubuntu.com/Kernel/MainlineBuilds and advise if you may then suspend?

[stan383 (stan383)]

Mr. Christopher,
I tested with 2 kernel versions:

3.2.66-030266-generic (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2.66-precise/)
--> using this kernel, I was able to boot successfully and then intiated suspend. PC was suspended. But waking the PC by pressing any key on keyboard led to normal boot process instead of resume from suspend. I tried this 2 times - both times PC was suspended, but waking led to boot process instead of resuming from suspend.

3.2.60-030260-generic (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2.60-precise/)
--> using this kernel, I was able to boot successfully and then initiated suspend. PC was suspended. I was able to wake the PC and resume worked properly as well. I tested this 13 times and all tests were successfull. I only saw these error in dmesg (one entry per suspend):
[ 162.537136] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 181.021083] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 210.186947] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 231.687493] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 246.578770] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 294.540121] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 319.081181] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 377.916508] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 389.471168] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 401.818031] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 414.748936] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 454.988862] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[ 547.582342] [drm:pch_irq_handler] *ERROR* PCH poison interrupt

Maybe the erros listed above are not critical. But I can confirm using older kernel 3.2.60-030260-generic in Ubuntu 14.10, what is similar version of kernel used in Debian 7.7, makes suspend work for my PC. Unfortunately the graphic card performance is very poor with this kernel, so I can't use this old kernel on daily purpose.

[penalvch (penalvch)]

Stanislav Kukla, the next step is to fully commit bisect from kernel 3.2.60 to 3.2.66 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[stan383 (stan383)]

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.

[penalvch (penalvch)]

Stanislav Kukla, thanks for bisecting. To confirm, is this reproducible with the latest mainline kernel (4.2-rc8)?

[stan383 (stan383)]

Mr. Christopher,
I tested with the latest upstream kernel 4.2-rc8 and the issue is reproducible even there. I tested 2 times - each time with the same result: suspend/resume attempt worked 3 times and then fourth attempt to suspend froze PC (screen went off, hdd stopped spinning, but PC fan and power led kept on, and the resume from this state was not possible, only hard reset).

[penalvch (penalvch)]

Stanislav Kukla, the issue you are reporting is an upstream one. Could you please report this problem following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel to the appropriate mailing list (linux-pm CC Yinghai Lu and Bjorn Helgaas)?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked via http://vger.kernel.org/vger-lists.html . It can take a day for the new e-mail to show up in the respective archive.

Thank you for your understanding.

[stan383 (stan383)]

The problem was sent to the linux-pm mailing list: http://marc.info/?l=linux-pm&m=144105324003500