[Bug 91585] New: [BDW] System hard lock-up on resume from suspend

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Aug 8 04:58:53 PDT 2015


https://bugs.freedesktop.org/show_bug.cgi?id=91585

            Bug ID: 91585
           Summary: [BDW] System hard lock-up on resume from suspend
           Product: DRI
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: an.inbox at free.fr
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

Created attachment 117588
  --> https://bugs.freedesktop.org/attachment.cgi?id=117588&action=edit
dmesg of Intel DRM nightly kernel, DRM logs enabled (0x1e)

The starting point is similar to bug 90342. On a Thinkpad X1 3rd gen with a i5
5200U with the stock Debian stable (Jessie) the hardware acceleration is
disabled, llvmpipe is used instead. After upgrading the Intel X driver to
2.99.917 (from Debian stable backport) the hardware acceleration is properly
enabled, but issues happen when resuming from suspend.

With the stock Debian kernel (3.16 + backports), the GPU hang but console
switching works, it's as described in bug #90342.

With newer Debian kernels (tried 4.0.8 from testing and 4.1.3 from unstable)
resumes work most of the time, but sometimes the system locks up hard. This
happen when switching to X, with a black screen. Then the system is fully
unresponsive and a hard power-off is required. On reboot, there is no log
available. The hard lock-up happens for me after 3 to 5 suspend/cycle
typically.
There were no additional DRM logs when doing those tests.

With Intel DRM nightly kernel (fb4572c00fadc1ac94816061e76c65b65607f66a,
2015y-08m-05d-15h-33m-02s UTC integration manifest) based on 4.2.0 RC5 the
issue also happens with no additional DRM logs. When enabling logs as asked in
the howto (drm.debug=0x1e log_buf_len=50M --- 1M was not enough) the issue did
not happen for 20 suspend/resume cycles. 

So it looks like a racy problem that vanishes when adding a lot of logs and is
present since 4.0.8.

I attached the output of dmesg with logs enabled.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20150808/127bf0e2/attachment.html>


More information about the intel-gfx-bugs mailing list