Most recent kernel where this bug did not occur: 2.6.13.2 Distribution: Slackware 10.1 Hardware Environment: Toshiba Satellite Pro 6000 laptop Software Environment: Xorg 6.8.2, XFCE 4.2, acpid 1.0.4 Problem Description: After resuming from S3 (suspended while in X), the LCD panel stays black . However, the laptop is up again, and I can SSH into it from another machine. I can get the panel working again, when I first direct video output to the CRT output of the laptop, and then back to LCD (done by repeatedly hitting Fn+F5 buttons on the Toshiba, which directs output to either LCD, CRT or TV) None of this ever happened with older kernels. Steps to reproduce: - boot with 2.6.14-rc2 or rc3 - suspend to S3 (done by closing lid) - resume from S3 (done by opening lid) - notice how laptop resumes but screen stays black
So if you boot with 2.6.13.2 this failure goes away and the LCD is restored properly after S3 resume?
Yes, indeed. Fact is, I never experienced this video resume problem with any kernel < 2.6.14. So far, my Toshiba worked perfectly well using ACPI. I was actually a little surpised to see a new kernel (albeit an rc) come up with a problem.
Can you please post comlete dmesg with both working and non-working kernels?
Created attachment 6449 [details] dmesg kernel 2.6.13.2 - video OK after resume
Created attachment 6450 [details] dmesg kernel 2.6.14 - video not OK after resume laptop was suspended for a few hours
Created attachment 6451 [details] output of lspci -v
I added the dmesg ouput you asked for. Honestly, I don't see any difference. I also would like to note that de video resume problem occurs only when suspended in X11. When suspended in console mode (actually vesa fb), video is fine when resuming. In fact, when the laptop resumes (suspended in X11), I see the console messages (back to C! etc) briefly before the lcd panel goes black again. If you need more info, don't hesitate to ask.
Bug is kind of "fixed" by resorting to vga=normal instead of 1024x768 vesa fb mode. When the laptop resumes now, everything is OK. Did something change in the vesa fb code of 2.6.14 ?
vesafb is not really hooked up to the power management system of the kernel. In 2.6.14, there are minor changes in the blanking code of vesafb. Can you try copying drivers/video/vesafb.c from the working kernel to the non-working kernel?
> Can you try copying drivers/video/vesafb.c from the working kernel to the > non-working kernel? Did so, and yes, it solves the problem ;) Apparently, the changes made to the vesafb driver of 2.6.14 don't mix well with resuming from memory. Maybe we should assign the bug now to the veasfb maintainer ?
Created attachment 6532 [details] Drop vesafb_blank() Okay. The recently added vesafb_blank() method is giving problems with laptop users. It works with CRT displays, but they don't need this as much as laptop users. Try this patch. It drops the vesafb_blank() hook from vesafb.
> Try this patch. It drops the vesafb_blank() hook from vesafb. Patch seems 100% OK. I have tested this for 2 days now, and my laptop suspends/resumes without any problem each time. I think you can close this bug ;) Thx alot for a job well done.
I am not sure who is driving this fix into the base. Antonino: Are you driving this? Can I assume that this will be fixed in upstreamkernel and close this bug? Thanks.
The fix is in akpm's tree. It will eventually go to mainline but I don't know when. So you can mark this as resolved at least.
In mm tree 2.6.15-rc*-mm* Marking the bug resolved.
The fix didn't make into 2.6.15 (final). I still had to apply the patch myself. Will it make it into 2.6.16 ?
Yes, it did not get in to 2.6.15, it was a bit too late. But it will in 2.6.16
OK, thx again.
the patch in comment #11 went upstream on Jan 10, 2006. closed.