[Bug 96442] New: Hibernating while utilising i915 with modeset=1 results in crash.

[bugzilla-daemon at freedesktop.org]

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

            Bug ID: 96442
           Summary: Hibernating while utilising i915 with modeset=1
                    results in crash.
           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: vjay at gmx.net
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

Created attachment 124405
  --> https://bugs.freedesktop.org/attachment.cgi?id=124405&action=edit
ZIP files containing screenshots and dmesg of system startup

Suspending and resuming a Toshiba Satellite C50-B-1CJ laptop (latest BIOS, EFI
start or BIOS start) randomly causes system freezes.

Hours of testing revealed that these freezes were caused by the i915 driver.
When using nomodeset they do not happen. Using windows hibernate work perfectly
fine. Sometimes it happens after just one hibernate cycle, sometimes it takes
like (felt) 20 times. 

I tested all stock kernels from 3.9 to the today's nightly code. I enabled and
disabled all drivers options to no effect. This behaviour persists. Using
kernel DRI results in the fact that hibernate will freeze the machine sooner or
later. Staying on console and not starting X does not resolve the problem.

Very seldom the display comes up after this and a kernel message could be seen.
I took a screenshot (literally) because you cannot write to the hard disk
anymore. Whatever you do causes the system to fully die. 

I bought this laptop as a present and will have access to it till the end of
august. If you want me to try anything i can happily do. I can provide ssh
access if you like.

Sadly I saw the instruction for posting bug reports utilising drm.debug=0x1e
too late. As I already mentioned it is a rarity to capture a kernel panic at
all but I try to catch one with this mode set.

In my personal opinion the driver somehow corrupts the memory as the errors
before system death looked very different in the past. I have the impression if
you let glxgears run it make the problem appear sooner.

(If somebody in the future experiences the same problem and it was never fixed
with this https://github.com/vjay82/Linux-i915-Backlight-Control you can at
least control the backlight but anyway you will loose acceleration.)

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