Bug description: The screen remains blank (even the back-light does not turn on) after the laptop resumes from suspend to ram. I can say that the system resumed because the system responds to SSH and I can (blindly) enter commands on the console, like reboot. Moreover, if I turn off kernel mode setting and start using the vesa xorg driver resume works. The problem is reproducible from the console (no X) or in X. The logs attached were obtained in the console. System environment: -- chipset: intel HD Graphics (Arrandale) -- system architecture: 64-bit -- xf86-video-intel: 2.11.0 (from X-updates ppa https://launchpad.net/~ubuntu-x-swat/+archive/x-updates) -- xserver: 1.7.6 -- mesa: 7.7.1 -- libdrm: 2.4.18-1ubuntu3 -- kernel: 2.6.35-5-generic -- Linux distribution: Ubuntu Lucid (with update kernel and xorg driver) -- Machine or mobo model: Dell Latitude E6410 -- Display connector: laptop LCD (LVDS) Reproducing steps: Just enter suspend and try to resume Additional info: I tried the steps in the suspend guide (http://intellinuxgraphics.org/suspend-resume.html). In the S3(a) in the console the laptop suspends and resumes but the screen remaind blank. I can ssh to the machine or type any command. The logs attached were obtained issuing the command intel_reg_dumper > reg_dump_before; intel_gpu_dump > gpu_dump_before; dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after; intel_gpu_dump > gpu_dump_after; intel_reg_dumper > reg_dump_after After that I rebooted the machine typing reboot in the blank console. As for the step b in the guide (suspend/resume by skipping BIOS), the laptop could wake up in all cases, from setting /sys/power/pm_test to devices to core. It only fails if I set pm_test to none. Finally, I was not sure if this bug should be reported here or in the kernel bugzilla.
Created attachment 36456 [details] dmesg output before suspending
Created attachment 36457 [details] dmesg output after suspending
Created attachment 36458 [details] reg dump before suspending
Created attachment 36459 [details] reg dump after suspending
I also have the gpu dumps before and after suspending. If they are needed, please let me know. I did not attach them here because they are too big (2.0M and 1.2M respectively)
I have updated my system with more current versions of the kernel, xorg, and Intel drivers from the x-edgers ppa: https://launchpad.net/~xorg-edgers/+archive/ppa I still have the same problem. My current configuration is System environment: -- chipset: intel HD Graphics (Arrandale) -- system architecture: 64-bit -- xf86-video-intel: 2.12.0 (from X-edgers ppa) -- xserver: 1.8.1.902 (1.8.2 RC 2) -- mesa: 2.1 Mesa 7.9-devel -- libdrm: 2.4.21+git20100624.726210f8-0ubuntu0sarvatt~lucid -- kernel: 2.6.35-6-generic -- Linux distribution: Ubuntu Lucid (with updated kernel and xorg) -- Machine or mobo model: Dell Latitude E6410 -- Display connector: laptop LCD (LVDS)
Today I discovered interesting behaviors in this bug. I don't know if they mean something but I believe it is worth registering. 1) If I turn off Kernel Mode Setting (KMS), boot into text mode and try to suspend using echo mem > /sys/power/state then the back-light remains off and screen remains blank (nothing is painted on the screen) after resume 2) If I turn off KMS, boot into text mode and try to suspend using pm-suspend then resume works! 3) If I turn off KMS, boot into graphics mode and try to supend using echo mem > /sys/power/state then the backlight is turned on but screen remains blank (nothing is painted on the screen) after resume. 4) If I turn off KMS, boot into graphics mode and try to supend using pm-suspend then resume works! Hence there is something fundamental on what pm-suspend does that ensures that resume can work without KMS (and using or not the vesa xorg driver). Maybe it is something related to the video "quirks" that pm-suspend uses (I don't actually know what are those "quirks" but they appear in the logs). All this happens using the 2.6.35-6-generic kernel.
hm ok let's look at the diff: - PIPEACONF: 0xc0000050 (enabled, active, 6bpc) + PIPEACONF: 0xc0000040 (enabled, active, 6bpc) somehow we lost the dithering bit, but that shouldn't cause a blank screen, probably just some color ugliness. Then there are some pipe b mode changes, but those look harmless. - PFA_CTL_1: 0x00800000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel (null),chroma pre-filter disable, vert3tap auto, v_inter_invert field 1) + PFA_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1) Here we changed the type of filtering we use for panel fitting, but since panel fitting is disabled it shouldn't matter... - PCH_FPA1: 0x00030d07 (n = 3, m1 = 13, m2 = 7) + PCH_FPA1: 0x016b0000 (n = 43, m1 = 0, m2 = 0) We don't use FPA1 at all so this one shouldn't matter... Looks like you were originally running a 1280x800 mode on your panel? The reg dumps look ok, so I guess we must be failing to train a link or wait for something to warm up somewhere...
(In reply to comment #8) > hm ok let's look at the diff: ... > Looks like you were originally running a 1280x800 mode on your panel? > Yes, that is my panel resolution. > The reg dumps look ok, so I guess we must be failing to train a link or wait > for something to warm up somewhere... Is there some way for me to look for this information? Like turning on some debugging flag or increasing the verbosity somewhere? Just ask, and I'll do it.
You can load the drm module with 'debug=1' to get a ton of output. Some of it may be helpful (we'd just need the boot log with that option set).
Created attachment 36677 [details] Dmesg output with drm.debug=1 before suspend
Created attachment 36678 [details] Dmesg output with drm.debug=1 after resume
(In reply to comment #10) > You can load the drm module with 'debug=1' to get a ton of output. Some of it > may be helpful (we'd just need the boot log with that option set). OK, I am attaching new dmesg output from before and after suspending in the console. See dmesg_drmdebug_1_before and dmesg_drmdebug_1_after. It did generate tons of output as you said and the dmesg buffer was not enough to hold all the output. Since I believe you only want to see the difference in the end (the new messages while resuming) I am attaching them anyway. If you need the full output then, please, let me know. In this case I'll need to recompile my kernel.
From this bug https://bugzilla.kernel.org/show_bug.cgi?id=13811 we have a patch which is already on kernel 2.6.33.6-142.rc1.fc13.x86_64 , which I could do an hibernation complete , not fix the suspend but be helpful.
(In reply to comment #13) > It did generate tons of output as you said and the dmesg buffer was not enough > to hold all the output. Since I believe you only want to see the difference in > the end (the new messages while resuming) I am attaching them anyway. If you > need the full output then, please, let me know. In this case I'll need to > recompile my kernel. You may set a bigger dmesg ring buffer, with the boot option log_buf_len. for example: log_buf_len=100M I got a full_demsg after suspend but the full_dmesg have 118M . You can download it on http://sergiomb.no-ip.org/full_dmesg.txt HTH
*** Bug 28912 has been marked as a duplicate of this bug. ***
Hi I believe I am having the same problem, what I have noticed is if I attach a second monitor and do a gdm restart the second monitor comes on line and then I can use xrandr to bring up the laptop monitor and then remove the external monitor.
Created attachment 36785 [details] xorg.log log this show a log of me suspending, resuming being unable to restart the X screen, then attaching the second screen - restarting gdm and using xrandr to move the screen from the external monitor back to the main monitor.
Created attachment 36786 [details] failed xorg this shows a gdm restart after a resume from suspend, and it failing. tty fails and X fails Alex
Hi Just to add this for a HP 2540p running debian sid 2.6.34-1 amd64 Ale
(In reply to comment #14) > From this bug > https://bugzilla.kernel.org/show_bug.cgi?id=13811 > > we have a patch which is already on kernel 2.6.33.6-142.rc1.fc13.x86_64 , > which I could do an hibernation complete , not fix the suspend but be helpful. The patch it self is (sorry I forget to mention in first time): http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-13/drm-i915-fix-hibernate-memory-corruption.patch?revision=1.1&content-type=text%2Fplain&view=co
I can confirm the behavior described in comment #17 in my Dell E6410. That is, I can awake the internal LCD if I plug an external monitor and restart gdm after resume (in may case I don't even need to use xrandr, when gdm restart the internal LCD is already on on an extended desktop setup, it is configured to the right of the external monitor). As Jesse said in comment #8, it looks like the driver is waiting for something to happen and does not awake the internal display. The gdm restart looks to force the display setup.
Hi, I also can confirm the behaviour described in comment #17 in my Dell E6410, yes I also have a E6410. I try explorer this new condition, which is a partial resume when attach one monitor. I found out this, after do : pm-suspend ; xrandr > xxx cat xxx Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) DP1 disconnected 1280x800+0+0 (normal left inverted right x axis y axis) 304mm x 190mm HDMI1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) 1280x800 (0x47) 74.8MHz h: width 1280 start 1334 end 1378 total 1472 skew 0 clock 50.8KHz v: height 800 start 809 end 817 total 846 clock 60.1Hz when xrandr on normal boot gives: Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) DP1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 304mm x 190mm 1280x800 60.1*+ 40.0 HDMI1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) After resume, xrandr says that DP1 is disconnect and more enigmatic DP3 have a resolution. HTH
Sergio, that helps since it looks like we're detecting the display port outputs in a different order between boot and resume. I don't think that should happen but I don't know the DP code that well. Will check it out.
(In reply to comment #24) > Sergio, that helps since it looks like we're detecting the display port outputs > in a different order between boot and resume. I don't think that should happen > but I don't know the DP code that well. Will check it out. Thanks , btw , it is possible reprobe monitors and DPn with a command like xrandr. or it is possible ,blacklist DP2 and DP3 , to not detect by the intel-drv , xrandr say that I have 3 DPs, DP1 ,DP2 and DP3 and also 3 HDMIs HDMI1, 2 and 3 , but I really have 1 of each.
What would be nice, is if there was some way to control i915 module the same way that X / xrandr does. If X/xrandr can get the monitor working again - in my case by attaching a second monitor. if I can a command line tool I could script something up. I have looked at vbetool but it can lock it up hard.........
> What would be nice, is if there was some way to control i915 module the same > way that X / xrandr does. > > If X/xrandr can get the monitor working again - in my case by attaching a > second monitor. if I can a command line tool I could script something up. > > I have looked at vbetool but it can lock it up hard......... There's a program called modetest in the drm repository. It can set modes and list output information, but it won't change the fbcon configuration. For that you'd need to use fbset or reboot with specific command line options.
*** Bug 28744 has been marked as a duplicate of this bug. ***
I'm trying to get ahold of one of these machines so I can reproduce and fix this myself.
I'm experiencing this bug with suspend/resume or plugging external monitor on HP EliteBook 8440p in Lucid. When system wakes up, everything works, only the screen remains black. Xrandr detects laptop display as connected DP1 both before the suspend and after the wakup. Further playing with xrandr reports no displays at all. Both suspend/resume and plugging external monitor works from Maverick Alpha 2 live CD, but surprisingly not from the same installed system. Xrandr in that case detects laptop display as connected DP1 before the suspend; and disconnected DP1 and connected DP4 after the wakeup. It's possible to turn on the display with "xrandr --output DP1 --auto" later (which doesn't works in Lucid).
This could be a dupe of 28998, can someone try the patch in the last comment of that bug and see if it helps?
Hi I have this problem, even when X is not loaded, but i915 module is. Alex
The same here. The problems happens from the console. Actually my initial report and logs are from suspending at the console without X involved. I believe that the suggested patch is now useful in this case, right?
(In reply to comment #31) > This could be a dupe of 28998, can someone try the patch in the last comment of > that bug and see if it helps? I can test it , where is the patch ? Could you give me the direct link to the patch because , I can't find it . Thanks,
On Tue, 13 Jul 2010 08:18:43 -0700 (PDT) bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=28739 > > --- Comment #34 from Sérgio M. B. <sergio@sergiomb.no-ip.org> 2010-07-13 08:18:42 PDT --- > (In reply to comment #31) > > This could be a dupe of 28998, can someone try the patch in the last comment of > > that bug and see if it helps? > > I can test it , where is the patch ? Could you give me the direct link to the > patch because , I can't find it . No if it happens w/o X then the patch isn't relevant, sorry for the noise.
A new workaround appeared in Ubuntu's companion bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/578673?comments=all It is in comment #54 and says: Workaround: -Use kernel 2.6.35 from ppa:kernel-ppa/ppa -add acpi_sleep=s3_bios to the Grub commandline -delete /usr/lib/pm-utils/sleep.d/99video and /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler The workaround works for me (with a E6410). Of course the deletion of the pm-utils files is only needed if you want to use pm-suspend to suspend. If you use only the kernel with echo mem > /sys/power/state (as root), you don't need to delete those files. Maybe the work around gives a hint on where is the problem?
(In reply to comment #36) > A new workaround appeared in Ubuntu's companion bug report: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/578673?comments=all > > It is in comment #54 and says: > > Workaround: > -Use kernel 2.6.35 from ppa:kernel-ppa/ppa > -add acpi_sleep=s3_bios to the Grub commandline > -delete /usr/lib/pm-utils/sleep.d/99video and > /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler with kernel 2.6.33.6-147.fc13.x86_64 ( fedora kernel have drm updated) , add acpi_sleep=s3_bios to the Grub commandline and remove /usr/lib64/pm-utils/sleep.d/99video works form me too thanks,
That doesn't help much; all it tells us is that the BIOS can initialize the GPU but the i915 driver can't. But we already knew that since graphics comes up at boot time. :) I found some problems with our eDP initialization and detection, working to fix them now. I have an e4310 and can reproduce the issue, so I hope to have a fix today.
Created attachment 37049 [details] [review] make sure panel power is enabled on eDP Can you guys give this kernel patch a try? It enables the panel even for eDP configurations, and works on my e4310.
I have tried your patch against the 2.6.35-8-generic kernel from ubuntu kernel ppa. It works! Great Job. I have an E6410.
*** Bug 29081 has been marked as a duplicate of this bug. ***
No joy for me on a Dell Latitude E6510. I tried applying the patch to the upstream 2.6.34 kernel (with some contortions) and to ubuntu-maverick tag Ubuntu-2.6.35-5.6. (I tried to use Linus' tree but failed at getting the debian tools to build it.) In both cases, the screen goes dead at system boot time when the KMS driver comes alive. This is the same behavior I had before applying Dave Airlie's patch http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html for bug 28070. I also tried backing out Dave's patch and applying just this one, but still boot to a blank screen.
Andrew, Maybe you have a different problem? This bug is about blank screen after resume and not at boot. I never had a blank screen at boot. By the way this patch also seems to affect another problem I had. Before the patch if I hooked an external monitor before turning on the machine at the end of the boot both screens (the external and the internal LCD) would end up blank. Now the gdm screen appears (in a mirroed setup). However if I try to login the external screen gets blank and the internal monitor only shows the mouse pointer over a blank background. Anyhow there was progress there. I'll probably look for a bug report that is more closely related to this problem or even file a new bug report for this case.
Created attachment 37323 [details] [review] patch 1/2 of upstream submission First patch in 2 part series to fix this, submitted upstream.
Created attachment 37324 [details] [review] patch 2/2 of upstream submission Second part of 2 part series submitted upstream.
(In reply to comment #45) > Created an attachment (id=37324) [details] > patch 2/2 of upstream submission > > Second part of 2 part series submitted upstream. hum , I can't apply this patch even on kernel-2.6.35-rc6.git1.fc14 , I guess, I have to wait ...
author Jesse Barnes <jbarnes@virtuousgeek.org> Thu, 22 Jul 2010 20:18:19 +0000 (13:18 -0700) committer Eric Anholt <eric@anholt.net> Mon, 26 Jul 2010 18:27:04 +0000 (11:27 -0700) commit 9934c132989d5c488d2e15188220ce240960ce96 tree d8ffde80fb3ac3ef19cdd671df1ec6741a95f7c4 tree | snapshot parent 4a655f043160eeae447efd3be297b6b4c397a640 commit | diff drm/i915: make sure eDP panel is turned on When enabling the eDP port, we need to make sure the panel is turned on after training the link. If we don't, it likely won't come back after suspend or may not come up at all. For unknown reasons, unlocking the panel regs before initiating a power on sequence is necessary. There are known bugs in the PCH panel sequencing logic, apparently this is one possible workaround. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28739. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: "Paulo J. S. Silva" <pjssilva@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net>
JFYI, These patches do not seem to work for the e6510 (intel core i5, intel integrated graphics), which should have the same hardware. I tested various patched kernels, compiled by myself and by others (including the latest drm-intel-next where these patches are already included). I'll file a separate bug about this. (In reply to comment #47) > author Jesse Barnes <jbarnes@virtuousgeek.org> > Thu, 22 Jul 2010 20:18:19 +0000 (13:18 -0700) > committer Eric Anholt <eric@anholt.net> > Mon, 26 Jul 2010 18:27:04 +0000 (11:27 -0700) > commit 9934c132989d5c488d2e15188220ce240960ce96 > tree d8ffde80fb3ac3ef19cdd671df1ec6741a95f7c4 tree | snapshot > parent 4a655f043160eeae447efd3be297b6b4c397a640 commit | diff > drm/i915: make sure eDP panel is turned on > > When enabling the eDP port, we need to make sure the panel is turned on > after training the link. If we don't, it likely won't come back after > suspend or may not come up at all. > > For unknown reasons, unlocking the panel regs before initiating a power > on sequence is necessary. There are known bugs in the PCH panel > sequencing logic, apparently this is one possible workaround. > > Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28739. > > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> > Tested-by: "Paulo J. S. Silva" <pjssilva@gmail.com> > Signed-off-by: Eric Anholt <eric@anholt.net>
hello suspend and resume seems is been working "out of the box" on F13 with kernel 2.6.34.6-54.fc13.x86_64 on my E6410. Thanks,
Unfortunately as of 2.6.38-rc4, this problem appears to be back. With 2.6.38-rc3, the back light stays off when resuming from suspend-to-disk, and using the laptop controls to increase the brightness no longer work at that point, the only option is to restart the laptop. With 2.6.38-rc4 it's even worse, the screen appears to be completely turned off with nothing that I can see in the screen no matter how hard I look. Unfortunately, this problem is back for me.
Can you bisect it?
Sorry, I don't understand the question.
Please try to use "git bisect" to figure out what caused the regression.
I can try that when I get home but I think that git stuff may be above my skill level. All I know is that resuming from suspend to RAM worked in 2.6.37, and it doesn't work in 2.6.38.
I can confirm that the bug is back, but at least in my system (E6410, intel graphics, 1280x800 screen) I get the following results (using kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/): 2.6.36-3 Screen works after boot and after resume (everything works) 2.6.37-rc1 Blank screen with backlight on after boot (so I couldn't test resume) This bad boot behavior is the same until 2.6.37 2.6.38-rc1 Screen works after boot (so the regression introduced in 2.6.27-rc1 is fixed), but backlight is off after resume. I can not turn on backlight with the usual key (Fn-Up), but I can do it with Fn-Left arrow (which is supposed to turn on and off the auto control of screen brightness in the laptop) The behavior of 2.6.38-rc1 stays the same up to 2.6.38-rc3 2.6.36-rc4 Screen works after boot but remains completely black after resume, laptop seems not to respond anymore. I can not even use Ctrl-Alt-F1 to move to console blindly and reboot (using Ctrl-Alt-Del) as I used to do in the very first iterations of this bug. Maybe this new problem is not really a screen problem anymore. Note that my behavior is a little bit different then the one described in comment #50 and #54 as the author says that resumes works for him in 2.6.37 (and I get blank screen at boot in this kernel). jlacroix, Maybe your system is a little different, for example a different screen? This would help to explain this different behavior. Jesse, I may try to bisect (but I may be a little slow at it). But how should I behave since from my description above it looks like there is more then one regression?
It seems like the exact same thing to me, my laptop doesn't respond at all after I resume. It appears that rc4 is worse than rc3.
Bisecting multiple problems can be tough, but just stick to one symptom when bisecting each and you should be able to narrow things down (i.e. don't "git bisect bad" if the screen doesn't come on in a different way than the one you're looking for).
(In reply to comment #55) > 2.6.36-3 Screen works after boot and after resume (everything works) > 2.6.37-rc1 Blank screen with backlight on after boot (so I couldn't test > resume) > > This bad boot behavior is the same until 2.6.37 > > 2.6.38-rc1 Screen works after boot (so the regression introduced in 2.6.27-rc1 > is fixed), but backlight is off after resume. I can not turn on backlight with > the usual key (Fn-Up), but I can do it with Fn-Left arrow (which is supposed to > turn on and off the auto control of screen brightness in the laptop) > > The behavior of 2.6.38-rc1 stays the same up to 2.6.38-rc3 > > 2.6.36-rc4 Screen works after boot but remains completely black after resume, > laptop seems not to respond anymore. I can not even use Ctrl-Alt-F1 to move to > console blindly and reboot (using Ctrl-Alt-Del) as I used to do in the very > first iterations of this bug. Maybe this new problem is not really a screen > problem anymore. > > Note that my behavior is a little bit different then the one described in > comment #50 and #54 as the author says that resumes works for him in 2.6.37 > (and I get blank screen at boot in this kernel). jlacroix, Maybe your system is > a little different, for example a different screen? This would help to explain > this different behavior. > > Jesse, I may try to bisect (but I may be a little slow at it). But how should I > behave since from my description above it looks like there is more then one > regression? For me thing is , you can not , just jump on boot kernel major versions ,36 37 and 38 , and always use same libdrm , you should have libdrm compile against the major kernel version or let me say drm version. With such new hardware , the behavior is unpredictable ... you may try recompile libdrm against the kernel and see if anything change ? and even recompile intel-drv (after lidrm of course ) may generate different behaviors, thought.
Sérgio, Let me see if I get this straight. You are saying that after each kernel compile I should rebuild the package libdrm2 libdrm-intel1 (I use Ubuntu) against the new kernel? I believe I can do it. Note, however that the major regression. The one that makes the laptop completely unresponsive was between minor revisions (2.6.38-rc3 and 2.6.38-rc4). I will try to do as you say and recompile libdrm against the new kernels. Note, however that I will try to recompile the packages from Ubuntu 10.10 and not updated versions. If I needed to update this packages then the bisect must be much more difficult as I would need to deal with differences in different trees. Finally, note that the bad behavior does not change if I use the stock Ubuntu graphics system or if I update it to xorg-edgers repository: https://launchpad.net/~xorg-edgers/+archive/ppa/+index?start=75&batch=75
My E6510 has a resume issue too: the backlight doesn't come back. https://patchwork.kernel.org/patch/499221/ fixed things though (looks like it was an ACPI problem).
I finished the bisect trying to find the first bad commit that resulted in the laptop being completely frozen on resume (I am not trying to look for the backlight issue now). The starting interval was 2.6.38-rc3 to 2.6.38-rc4. The result was (full log at the bottom): ----- Bisect result ---- 5d1d0cc87fc0887921993ea0742932e0c8adeda0 is the first bad commit commit 5d1d0cc87fc0887921993ea0742932e0c8adeda0 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jan 24 15:02:15 2011 +0000 drm/i915: Reset crtc after resume Based on a patch by Takashi Iwai. Reported-by: Matthias Hopf <mat@mshopf.de> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27272 Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> :040000 040000 9d649a524e16408e210551dcd9e9a71df3e19ac2 79815ecec87bb4306986c717e33ba4265a2b7bfd M drivers ---- End bisect result ---- It is interesting to see that the above commit is related to resume and in the i915 drm driver. I have some more comments that may be helpful: 1) If I boot the laptop docked (in the E-port dock from Dell with a monitor attached), suspend and resume the problem does not happen. Even funnier, if after resume I un-dock the laptop and suspend I can still resume. It seems like the first resume (or the boot itself) with a docked laptop "fix the problem". 2) I have tried with both the stock driver stack in Ubuntu 10.10 and the xorg-edgers stack. I have also tried to compile the new (xorg-edgers) libdrm in my laptop using the last bad kernel (so that the compilation uses the headers of the last bad kernel) and it did not improve. The libdrm from xorg-edgers is marked libdrm2_2.4.23+git20110119. Anything more I should try? ---- Bisection log ---- Log: git bisect start # good: [ebf53826e105f488f4f628703a108e98940d1dc5] Linux 2.6.38-rc3 git bisect good ebf53826e105f488f4f628703a108e98940d1dc5 # bad: [100b33c8bd8a3235fd0b7948338d6cbb3db3c63d] Linux 2.6.38-rc4 git bisect bad 100b33c8bd8a3235fd0b7948338d6cbb3db3c63d # bad: [78d2978874e4e10e97dfd4fd79db45bdc0748550] CRED: Fix kernel panic upon security_file_alloc() failure. git bisect bad 78d2978874e4e10e97dfd4fd79db45bdc0748550 # good: [eb487ab4d5af0caee81bfaaa5d87b55844f60145] Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip git bisect good eb487ab4d5af0caee81bfaaa5d87b55844f60145 # good: [811aaa55ba21ab37407018cfc01770d6b037d3fb] drm: Only set DPMS ON when actually configuring a mode git bisect good 811aaa55ba21ab37407018cfc01770d6b037d3fb # bad: [e98ce0d7cfa6ee0650a63d45558a5121383995d9] Merge remote branch 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next into drm-fixes git bisect bad e98ce0d7cfa6ee0650a63d45558a5121383995d9 # bad: [ede3ff5204b0117d00609f4980df3b864cefe96f] drm: Simplify and defend later checks when disabling a crtc git bisect bad ede3ff5204b0117d00609f4980df3b864cefe96f # good: [500f7147cf5bafd139056d521536b10c2bc2e154] drm/i915: Reset state after a GPU reset or resume git bisect good 500f7147cf5bafd139056d521536b10c2bc2e154 # bad: [5d1d0cc87fc0887921993ea0742932e0c8adeda0] drm/i915: Reset crtc after resume git bisect bad 5d1d0cc87fc0887921993ea0742932e0c8adeda0 # good: [f3269058e7a80083dcdf89698bfcd1a6c6f8fd12] drm/i915/crt: Force the initial probe after reset git bisect good f3269058e7a80083dcdf89698bfcd1a6c6f8fd12 ---- End bisection log ----
commit 04dbff52600719017598f7439bf42e5a72e7de3b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Feb 10 17:38:35 2011 +0000 drm/i915: Fix resume regression from 5d1d0cc
I can confirm that the bug is fixed in my laptop (E6410, intel graphics, 1280x800 panel). Note that the patch not only fixes the hard lockup of the laptop at resume but also brings the back-light back on. So this is a complete fix for the suspend/resume problems in the 2.6.38 kernel described in comment #55. I have tested a self compiled kernel 2.6.38-rc5 and the version from Ubuntu mainline kernel PPA (http://kernel.ubuntu.com/~kernel-ppa/mainline/).
Closing. Verified by Paolo 5+half year ago.
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.