The system here is a Sony Vaio Z VPCZ1 - the same as was at issue in https://bugs.freedesktop.org/show_bug.cgi?id=29141 . I built a kernel from the current drm-intel-next tree to test the fixes for that bug. With that kernel I can now boot with the Intel graphics chipset, whereas I couldn't before. However, on resume from suspend, the display does not wake up properly. The backlight comes on but the screen remains blank. I cannot switch to a VT either. The system is running and I can connect to it via ssh. Running xrandr via ssh shows this: [adamw@vaioz ~]$ DISPLAY=:0 xrandr Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192 (null)1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 291mm x 164mm 1600x900 59.9*+ 40.0 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) HDMI3 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) That (null)1 looks odd, I haven't checked if that's also what it says when it's working okay before suspend. I will attach /var/log/messages with drm.debug=14 and /var/log/Xorg.0.log . I suspended the system around 12:32:25 and resumed around 12:33.
Created attachment 39312 [details] /var/log/messages after resume
Created attachment 39313 [details] Xorg.0.log after attempt to resume
I tested, and yeah, it does refer to the output as (null)1 even when it's working before I suspend. Seems like a bug in itself.
I was about to file a similar bug report, but a day later this issue was already fixed. Presumably those fixes aren't merged into intel-drm-next yet. My current kernel with working suspend: git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel branch: edp-fixes commit: 0c942e6cb80e3219da3e4ae168664e0f44aa91fe
Created attachment 39315 [details] [review] Take down DP link This is the patch Jesse applied to make suspend work on his Vaio. Can you give it a test?
Nope, that's not enough, still fails. Attaching new logs. I guess I'll try just building a kernel from the edp-fixes branch, it looks like it has a lot of stuff that isn't in drm-intel-next yet.
Created attachment 39325 [details] messages after resume (with "drm/i915/dp: down the DP link even if the reg indicates it's already down" patch) suspend is at 11:26:15, resume at 11:27:44.
Created attachment 39326 [details] Xorg.0.log after attempt to resume (with drm/i915/dp: down the DP link even if the reg indicates it's already down patch)
OK, so I built direct from jesse's edp-fixes tree and suspend/resume works. Looks like it needs some of the other commits too. Should I close this or wait till it's moved into the drm-intel-next queue?
Does this fix the suspend/resume problem? diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 8e019c8..a3e8a21 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -919,6 +919,7 @@ static void intel_dp_prepare(struct drm_encoder *encoder) if (is_edp(intel_dp)) { ironlake_edp_backlight_off(dev); + ironlake_edp_panel_off(dev); ironlake_edp_panel_on(intel_dp); if (!is_pch_edp(intel_dp)) ironlake_edp_pll_on(encoder);
hey, jesse. As I said in my last comment, with your edp-fixes branch it works fine. are you trying to isolate the patch needed to fix it against drm-intel-next? do you want me to try a drm-intel-next build with just that patch added? not sure what you need to check, let me know :) thanks!
Yeah, my edp-fixes branch had a patch that worked for me but not for others. I'm hoping the patch in the last comment (against drm-intel-next) will actually fix it for everyone.
ah I see - okay, will test and let you know how it works.
It works, but not quite as smoothly as the edp-fixes branch. It resumes from suspend to a black screen with the cursor visible; I have to switch to a VT and back for the rest of the desktop to show up. (I have the same symptoms using the NVIDIA adapter and the nouveau driver on the same system, oddly enough). The edp-fixes branch resumes flawlessly with the desktop fully visible.
Suspend/resume works fine for me (on a VPCZ11C5E) with the patch from #10 and the drm-intel-next branch. There's no need to switch to VT and back for me. Userspace is a current Ubuntu 10.10. It also works with the current edp-fixes branch (head is the patch against the flickering) from Jesses repository.
I may not have been testing entirely rigorously, there may be other factors involved - at the time I had multiple results to the same effect with both kernels, but since then I've seen at least one resume-to-black-with-cursor with the edp-fixes kernel. So it may just be random and I got a string of oddly consistent results at first, or it may depend on something else (may be to do with metacity vs compiz vs gnome-shell, actually). So I guess discount my finding unless I can confirm it more carefully.
suspend/resume works for me with: repo: ickle/drm-intel.git branch: drm-intel-next and the patch from comment #10 applied Sony Vaio VPCZ11Z9E it's the first time resume worked, thx!
(In reply to comment #15) > Suspend/resume works fine for me (on a VPCZ11C5E) with the patch from #10 and > the drm-intel-next branch. There's no need to switch to VT and back for me. > Userspace is a current Ubuntu 10.10. > > It also works with the current edp-fixes branch (head is the patch against the > flickering) from Jesses repository. This is again broken for me on next (a17577c942e774520ca61479e1e48a232b1e27d7) and fixes (1bb95834bbcdc969e477a9284cf96c17a4c2616f), but adding the line from #c10 still fixes the problem.
So why is Jesse's patch (comment 10) not in linux 2.6.37 nor in linux-next? Did I miss something?
(In reply to comment #18) > (In reply to comment #15) > > Suspend/resume works fine for me (on a VPCZ11C5E) with the patch from #10 and > > the drm-intel-next branch. There's no need to switch to VT and back for me. > > Userspace is a current Ubuntu 10.10. > > > > It also works with the current edp-fixes branch (head is the patch against the > > flickering) from Jesses repository. > > This is again broken for me on next (a17577c942e774520ca61479e1e48a232b1e27d7) > and fixes (1bb95834bbcdc969e477a9284cf96c17a4c2616f), but adding the line from > #c10 still fixes the problem. Suspend / resume is also broken for me in drm-intel-next (fe4402931e43e81a4129eba41d05cf8907603af5) even after adding #c10. Jesse's edp-2 branch works fine in this respect. I have a dell e6510 with an HD panel but *not* with switchable graphics. What happens to my laptop is that the backlight is not switched on after resuming. It can be activated with the keyboard backlight controls, but it stays in the console and alt-f7 does not take me to the X server display. I was wondering whether it could be due to some suspend / resume script not making some critical call?
(In reply to comment #20)\ > Suspend / resume is also broken for me in drm-intel-next > (fe4402931e43e81a4129eba41d05cf8907603af5) even after adding #c10. Jesse's > edp-2 branch works fine in this respect. I have a dell e6510 with an HD panel > but *not* with switchable graphics. What happens to my laptop is that the > backlight is not switched on after resuming. It can be activated with the > keyboard backlight controls, but it stays in the console and alt-f7 does not > take me to the X server display. I was wondering whether it could be due to > some suspend / resume script not making some critical call? Further information at https://bugs.freedesktop.org/show_bug.cgi?id=33439#c17
I think we're in upstream bug territory now... Something is going awry with the ACPI/backlight handling code. Fortunately everything else seems to be coming back ok.
Does https://patchwork.kernel.org/patch/499221/ help?
(In reply to comment #23) > Does https://patchwork.kernel.org/patch/499221/ help? Seems to work (in a E6510 with intel graphics only). I patched it against drm-intel-next, but could not try it a lot, since that branch is right now in a very unstable state; the X server crashes very frequently.
hm drm-intel-next has been ok for me, aside from wireless crashes (using the brcm80211 staging driver), but either way that's a separate bug, can you file it along with whatever info you can collect?
Ok, I guess this is one of the non-gfx suspend/resume bugs. Any runtime hangs should be reported as separate bugs.
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.