Created attachment 124405 [details] 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.)
Correction: kernels from 3.9 -> Kernel 3.19 I found this, somebody reporting the same issue having a Toshiba laptop too. https://bugs.freedesktop.org/show_bug.cgi?id=94203 Maybe it helps. On 01.org it is advised to open a separate report anyway.
(In reply to Volker Gronau from comment #1) > I found this, somebody reporting the same issue having a Toshiba laptop too. > https://bugs.freedesktop.org/show_bug.cgi?id=94203 > > Maybe it helps. On 01.org it is advised to open a separate report anyway. That one is Ironlake, this one is Haswell.
(In reply to Volker Gronau from comment #0) > Created attachment 124405 [details] > ZIP files containing screenshots and dmesg of system startup For future reference, please attach each file directly, unpacked. > 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. Unfortunately, the screenshots do not contain the full backtrace. :( > 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. Please attach such a dmesg running drm-intel-nightly over a hibernate-resume sequence even if it doesn't result in a crash; it may provide valueable information anyway. > (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.) I can't recommend anyone using intel_reg for anything except testing and debugging.
Created attachment 124425 [details] dmesg of hibernate and resume cycles I did add the proposed kernel parameters "drm.debug=0x1e log_buf_len=1M", took a dmesg of the system startup and let it continually log into the file. Each time i cycled i echoed it into the file too. Does this help? Can I provide sth else?
I forgot to mention it: As you can see in the truncated file, after the third cycle the system did not come back. The screen stayed black and it did not answer when pinged. I was asking if I can provide more specific information because I prefer contributing that over randomly crashing the machine and hoping for another chance to screenshot it.
fixed with today's nightly
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.