| Summary: | black screen after resume from hibernation since linux kernel 3.18 | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Martin Steigerwald <Martin> |
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | major | ||
| Priority: | medium | CC: | intel-gfx-bugs, noga.dany |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
|
Description
Martin Steigerwald
2014-11-22 09:58:22 UTC
I wonder whether Bug 80773 - [hsw backlight bisected] backlight is off after resume with this fixing commit sna/transform: Correctly check for imprecise fractional translations http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=7ecc778691c452285f754743a93a46fa1d3da52f may be related to it. But its a driver fix in X.org, yet for me working is kernel 3.17 and not working is kernel 3.18. So might be something different. I can also try changing sleep modules to userspace software suspend… maybe I can tell it to switch to VT1 before hibernation this way so I may see some kernel debug messages. Oh it definately loads in the hibernation image. I see the kernel messages where it tells progress in 10 percent steps. Then it switches to black screen and sits there while the machine seems to be not completely locked. I think I saw some disk activity. Next time I may leave it running like that for some minutes. Maybe it will eventually write something into logs. (In reply to Martin Steigerwald from comment #2) > Oh it definately loads in the hibernation image. I see the kernel messages > where it tells progress in 10 percent steps. Then it switches to black > screen and sits there while the machine seems to be not completely locked. I > think I saw some disk activity. Next time I may leave it running like that > for some minutes. Maybe it will eventually write something into logs. Could you boot with the kernel parameters "drm.debug=0xe no_console_suspend initcall_debug" and provide the dmesg log after the hang? If you can't access the device otherwise, you could try using serial console or netconsole. Can you reproduce the problem if you boot with nomodeset? Could you try the git://anongit.freedesktop.org/drm-intel drm-intel-nightly branch? It contains some S3/S4 fixes that may help here. Created attachment 109928 [details]
debug log of a working hibernation cycle
I am now running
merkaba:~> cat /proc/version
Linux version 3.18.0-rc6-tp520 (martin@merkaba) (gcc version 4.9.2 (Debian 4.9.2-1) ) #12 SMP PREEMPT Mon Nov 24 08:46:56 CET 2014
with
merkaba:~> cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.18.0-rc6-tp520 root=/dev/mapper/sata-debian ro rootflags=subvol=debian resume=/dev/mapper/sata-swap init=/bin/systemd drm.debug=0xe no_console_suspend initcall_debug
I attach a log of a hibernation cycle that worked okay.
As soon as I find something during the next days I will try to capture logs.
Thanks,
Martin
Created attachment 111837 [details]
debug log of a hibernation cycle with longer delay with black screen on resume
Happy new year!
This still happens with 3.19-rc2. As I enabled debug I didn´t see the issue for a long time and I disabled debugging after a while again – and then it happened again. But with debugging I had it once that it took a longer time from black screen to usable system and I thought I may be hitting that issue again.
Log attached. Maybe it yields something useful.
I will now add "no_console_suspend initcall_debug" to the boot options again and hope that it will happen again with debug enabled. Maybe it doesn´t as the timing, but then I can use debug output as a work-around to make this annoying issue disappear at least.
Created attachment 112050 [details]
debug log of a hibernation cycles with longer delay with black screen on resume
This still happens with 3.19-rc3. Now with debug enabled as in:
martin@merkaba:~> cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.19.0-rc3-tp520-trim-all-bgroups+ root=/dev/mapper/sata-debian ro rootflags=subvol=debian resume=/dev/mapper/sata-swap init=/bin/systemd no_console_suspend no_console_suspend initcall_debug
Hmmm, I see, there is still something missing. The drm debug drm.debug=0xe, and I accidentally added no_console_suspend twice, I will adapt this for the next cycles.
Anyway, I attach a syslog with above kernel command line and the black screen delay happening. I don´t see any noticable delays in the initcall debug statements. I have another one from a few days before available as well.
To more observations:
1. It seems that if I wait long enough after resume, the box, I can actually get the Plasma/KDE 4.14 screen locker, instead of the black screen.
2. it seems that the other issue of the delay on hibernating, with the blinking power LED of the laptop instead of the laptop shutting down after saving the image, seems related. Everytime I have this issue, on the next resume, I have the black screen delay as well.
Okay, next round with drm.debug=0xe reenabled as well. This is really annoying and I don´t like something breaks my user experience that way.
I also thought to try without systemd and using sysvinit again, but let me first catch a DRM debug log as well.
Created attachment 112375 [details]
debug log of a hibernation cycle with longer delay with black screen on resume
Okay, now I catched a log with:
merkaba:~> cat /proc/version /proc/cmdline
Linux version 3.19.0-rc4-tp520-trim-all-bgroups+ (martin@merkaba) (gcc version 4.9.2 (Debian 4.9.2-10) ) #17 SMP PREEMPT Mon Jan 12 10:43:23 CET 2015
BOOT_IMAGE=/vmlinuz-3.19.0-rc4-tp520-trim-all-bgroups+ root=/dev/mapper/sata-debian ro rootflags=subvol=debian resume=/dev/mapper/sata-swap init=/bin/systemd no_console_suspend drm.debug=0xe initcall_debug
So this is with all debugging and it is huge.
Again for the case where I get a longer delay on resuming from hibernation. Also on hibernation itself the power LED continued to blink and the laptop didn´t switch off after saving the image. It may be that it would eventually do so, but I didn´t want to have it running all night as I was about to go to bed.
On resuming I saw something interesting: I had the black screen for at least a minute, I think more two minutes, and then I saw the tty shortly displaying about half a screen of messages before the KDE/Plasma screen locker appeared. I don´t know what it displayed there as I was too far away from the laptop.
Jani, I will look at your suggestion next. May take a while.
I think I didn´t see this with 3.19-rc7 anymore, maybe even an earlier version. Thus closing. Thank you, Martin This still happens. Currently on 3.19-rc7. Jani, does 3.20 contain the patch from your comment #7? If so, I think I simply wait for 3.20-rc2 or so. Otherwise I try the patch. I think I also ask on linux-pm about it, at it may be more related to PM in general than to Intel graphics as I noticed now that the laptop makes a beep after this delay. So it may be stuck in general resuming procedure. Odd, dmesg is filled with Jan 16 11:35:14 merkaba kernel: [166660.246491] [drm:add_framebuffer_internal] [FB:914] (In reply to Martin Steigerwald from comment #10) > Jani, does 3.20 contain the patch from your comment #7? If so, I think I > simply wait for 3.20-rc2 or so. Otherwise I try the patch. The patch has been merged in v3.19-rc7. Thanks, Jani. I now tested with 4.0-rc2, but it doesn´t hibernate at all: [Bug 94241] New: Blanks screen on hibernation but does not switch off the machine https://bugzilla.kernel.org/show_bug.cgi?id=94241 (In reply to Martin Steigerwald from comment #13) > [Bug 94241] New: Blanks screen on hibernation but does not switch off the > machine > https://bugzilla.kernel.org/show_bug.cgi?id=94241 I suspect we have this covered already, please check my comment on the bug and report back. Okay, with https://bugzilla.kernel.org/show_bug.cgi?id=94241#c3 on top of https://bugzilla.kernel.org/show_bug.cgi?id=94241#c1 the machine hibernates again. I still get the symptom described in this bug on resume. The screen is black for a minute or more and then suddenly is blanked on. And I know something else now: I am able to log into the machine from a second ThinkPad at that time. Yet, I do not see *anything* regarding the initial wait in kern.log. I am still back at 3.19-rc7 due to the issue I described in https://bugzilla.kernel.org/show_bug.cgi?id=94241#c4 as the backtrace described there has Mar 5 08:57:41 merkaba kernel: [ 858.107406] [<ffffffff812b4315>] do_unblank_screen+0xd3/0x141 in it, there may be some relation although that issue happens on opening a second Plasma/KDE session as I described in the comment in the other bug. So either this is a third bug, or this is somehow related to the other or this bug. I am now using vanilla 4.0 without any hibernation or intel gfx related patch and I still have this issue. I am not using the patch from https://bugzilla.kernel.org/show_bug.cgi?id=94241#c4 anymore, since Ilya doesn´t think that the patch would help on my machine. I am reopening since this is still unsolved. Martin, related to https://bugzilla.kernel.org/show_bug.cgi?id=94241#c14: Did the issue in this report also get resolved meanwhile? You mentioned in comment 15 that the patch from https://bugzilla.kernel.org/show_bug.cgi?id=94241#c3 made a difference for you. Could you confirm if that's still needed or not? I'd assume it's not needed based on the comments in the kernel bugzilla ticket. Thanks. Hello Imre, I am not seeing this issue either anymore with no patches related to this issue applied. Thank you, Martin |
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.