Bug 10319 - MacBookPro1,1: on resume (from console) s2ram -f -p does not anymore give me my display back - 2.6.25 regression
Summary: MacBookPro1,1: on resume (from console) s2ram -f -p does not anymore give me ...
Status: RESOLVED WILL_NOT_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks: 7216 9832 56331
  Show dependency tree
 
Reported: 2008-03-25 04:44 UTC by Soeren Sonnenburg
Modified: 2013-04-09 06:23 UTC (History)
8 users (show)

See Also:
Kernel Version: 2.6.27-rc7
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
kernel config (13.52 KB, application/x-gzip)
2008-04-07 05:57 UTC, Soeren Sonnenburg
Details
Debug patch to test (1.15 KB, patch)
2008-04-11 13:41 UTC, Rafael J. Wysocki
Details | Diff
dmesg output (29.61 KB, text/plain)
2008-04-21 08:48 UTC, HJH
Details

Description Soeren Sonnenburg 2008-03-25 04:44:16 UTC
this is a follow up to #10065

Latest working kernel version: 2.6.24
Earliest failing kernel version: ???
Distribution: Debian-SID
Hardware Environment: MacBookPro1,1
Software Environment:
Problem Description: hangs / reboot / no display on resume from s2ram

I am still having problems on *resume* with git current
a4083c9271e0a697278e089f2c0b9a95363ada0a, however it always suspends fine now.

- on resume (from within X) I don't get the display back, the ide led is still
on then it reboots (about 10 seconds later).

- on resume (from console) s2ram -f -p does not anymore give me my display
back, however blindly typing reboot or s2ram again works (system is alive).

Steps to reproduce:

happens on any s2ram resume attempt
Comment 1 Shaohua 2008-03-26 18:36:30 UTC
- on resume (from console) s2ram -f -p does not anymore give me my display
back, however blindly typing reboot or s2ram again works

So it actually resumed, but just haven't display. Can you try the enable CONFIG_FB_INTEL (with this maybe you don't need s2ram, just directly do 'echo mem > /sys/power/state). In my test, the new intel driver works perfectly.
Comment 2 Soeren Sonnenburg 2008-03-26 22:53:26 UTC
I don't have an intel but an ati card (radeonhd X driver) and it does not work even under the console... however under the console it still works at least in 2.6.24 ...
Comment 3 HJH 2008-03-30 10:22:25 UTC
same on 2.6.25-rc7.
Works fine on 2.6.24
Comment 4 Len Brown 2008-04-01 18:16:47 UTC
please try 2.6.25-rc8, for it includes the resume-order patch
7731ce63d9a863c987dd87b0425451fff0e6cdc8
Comment 5 Rafael J. Wysocki 2008-04-02 15:27:16 UTC
Soeren did that.  Also, he tested the patch from http://bugzilla.kernel.org/show_bug.cgi?id=10345#c32
and it helped, but the console still didn't come up after the resume.
Comment 6 Rafael J. Wysocki 2008-04-02 15:30:27 UTC
References : http://lkml.org/lkml/2008/4/2/496
Comment 7 HJH 2008-04-05 02:28:46 UTC
Confirmed.
Still no resume after suspend in 2.6.25-rc8
Comment 8 Romano Giannetti 2008-04-06 13:00:55 UTC
Have you tried echo mem > /sys/power/state? On my laptop I used to suspend with s2ram -f -p -m in .24, and now that one sometime fails with the exactly same symptoms you said. The echo method works ok.
Comment 9 HJH 2008-04-06 14:02:53 UTC
Romano,

that does indeed work in 2.6.25-rc8, but only WITHOUT an X server running!
s2ram fails horribly in all cases.
s2disk / echo disk >/sys/power/state always seems to fail.
Comment 10 Anonymous Emailer 2008-04-07 00:17:27 UTC
Reply-To: romanol@upcomillas.es



On Fri, 2008-04-04 at 08:31 +0200, Soeren Sonnenburg wrote:
> On Fri, 2008-04-04 at 01:22 +0200, Rafael J. Wysocki wrote:

> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=10319
> > Subject             : 2.6.25-rc6 regression - hang on resume
> > Submitter   : Soeren Sonnenburg <kernel@nn7.de>
> > Date                : 2008-03-25 04:44 (10 days old)
> 
> Yes. The machine resumes and display stays black using s2ram -f -p
> (blindly typing reboot etc on keyboard does what is expected). However
> display comes back on 2.6.24.

I can add that on my laptop (toshiba U305, Intel 945GM chipset), s2ram
-f -p -m which used to work ok, in X and console, in 2.6.24 stopped to
work (I tested -rc8, but I think it's like that since a long time).
Machine resumes but the screen stays off after that, although machine is
working (exactly as Soeren said). 

On the other hand, now the plain "echo mem > /sys/power/state" works
perfectly, from X and console. So some of the magic vbe save/restore of
s2ram mess something up for this card. 

Is it a regression for my laptop (is evidently one for Soeren)? On one
side, a "used to work" setup is broken, but it worked with userspace
hacks; now it works with the plain way, and that's clearly better.

I added on Cc: Jesse, to whom I confirmed that Intel suspend/resume was
ok on Feb, 21, [1] and suspend-devel list, because now I do not know
what to do with the whitelist I sent for s2ram for this machine...

Romano 

[1] http://marc.info/?l=linux-kernel&m=120362475121590&w=2
Comment 11 Rafael J. Wysocki 2008-04-07 02:11:04 UTC
On Monday, 7 of April 2008, Romano Giannetti wrote:
> 
> On Fri, 2008-04-04 at 08:31 +0200, Soeren Sonnenburg wrote:
> > On Fri, 2008-04-04 at 01:22 +0200, Rafael J. Wysocki wrote:
>>
> > Yes. The machine resumes and display stays black using s2ram -f -p
> > (blindly typing reboot etc on keyboard does what is expected). However
> > display comes back on 2.6.24.
> 
> I can add that on my laptop (toshiba U305, Intel 945GM chipset), s2ram
> -f -p -m which used to work ok, in X and console, in 2.6.24 stopped to
> work (I tested -rc8, but I think it's like that since a long time).
> Machine resumes but the screen stays off after that, although machine is
> working (exactly as Soeren said).

Your graphics adapter is different from the Soeren's one and the fact that
"echo mem > /sys/power/state" works for you now is probably a result of the
recent changes in the i915 driver that is now supposed to handle suspend
and resume.

That said, there had to be a change that affected both of your systems
between 2.6.24 and .25-rc8.  Moreover, I'm suspecting ACPI or something
generic in the DRM core.

As far as ACPI is concerned, one commit related to backlight has just been
reverted, so Soeren, can you please test the current Linus' tree?
Comment 12 Rafael J. Wysocki 2008-04-07 03:33:15 UTC
References : http://lkml.org/lkml/2008/4/6/1
Comment 13 Soeren Sonnenburg 2008-04-07 03:59:04 UTC
I have not yet tried current git, but would just like to comment that the display does not come back (radeon graphics adapter) using a sole echo mem > >/sys/power/state for console only.
Comment 14 Soeren Sonnenburg 2008-04-07 04:20:55 UTC
argh, current git does not compile

  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CHK     include/linux/compile.h
  CC [M]  drivers/media/video/pvrusb2/pvrusb2-devattr.o
  LD      drivers/media/video/saa7134/built-in.o
  CC [M]  drivers/media/video/saa7134/saa7134-cards.o
drivers/media/video/pvrusb2/pvrusb2-devattr.c:178: error: unknown field ‘flag_has_analogtuner’ specified in initializer
drivers/media/video/pvrusb2/pvrusb2-devattr.c:179: error: unknown field ‘flag_has_composite’ specified in initializer
drivers/media/video/pvrusb2/pvrusb2-devattr.c:180: error: unknown field ‘flag_has_svideo’ specified in initializer
drivers/media/video/pvrusb2/pvrusb2-devattr.c:182: error: unknown field ‘digital_control_scheme’ specified in initializer
drivers/media/video/pvrusb2/pvrusb2-devattr.c:182: error: ‘PVR2_DIGITAL_SCHEME_HAUPPAUGE’ undeclared here (not in a function)
drivers/media/video/pvrusb2/pvrusb2-devattr.c:183: error: unknown field ‘led_scheme’ specified in initializer
drivers/media/video/pvrusb2/pvrusb2-devattr.c:183: error: ‘PVR2_LED_SCHEME_HAUPPAUGE’ undeclared here (not in a function)
make[4]: *** [drivers/media/video/pvrusb2/pvrusb2-devattr.o] Error 1
make[3]: *** [drivers/media/video/pvrusb2] Error 2
make[3]: *** Waiting for unfinished jobs....
Comment 16 Soeren Sonnenburg 2008-04-07 05:13:44 UTC
OK, compiles now. However the black display after resume remains :(
Comment 17 Rafael J. Wysocki 2008-04-07 05:51:05 UTC
Can you attach your current .config, please?
Comment 18 Soeren Sonnenburg 2008-04-07 05:57:20 UTC
Created attachment 15654 [details]
kernel config

the config with which I am seeing the hang.
Comment 19 Rafael J. Wysocki 2008-04-07 06:03:09 UTC
Can you test with CONFIG_DRM unset, please?
Comment 20 Soeren Sonnenburg 2008-04-07 07:47:47 UTC
I did, still a black display...
Comment 21 Rafael J. Wysocki 2008-04-07 10:23:45 UTC
It seems to be an ACPI problem, then.

Can you check out commit c697eecebc6cfc0b393afea3c4ff1a5041526ad1 and see if that works?
Comment 22 Tino Keitel 2008-04-08 01:59:22 UTC
On Mon, Apr 07, 2008 at 11:10:39 +0200, Rafael J. Wysocki wrote:
> On Monday, 7 of April 2008, Romano Giannetti wrote:
> > 
> > On Fri, 2008-04-04 at 08:31 +0200, Soeren Sonnenburg wrote:
> > > On Fri, 2008-04-04 at 01:22 +0200, Rafael J. Wysocki wrote:
> >>
> > > Yes. The machine resumes and display stays black using s2ram -f -p
> > > (blindly typing reboot etc on keyboard does what is expected). However
> > > display comes back on 2.6.24.
> > 
> > I can add that on my laptop (toshiba U305, Intel 945GM chipset), s2ram
> > -f -p -m which used to work ok, in X and console, in 2.6.24 stopped to
> > work (I tested -rc8, but I think it's like that since a long time).
> > Machine resumes but the screen stays off after that, although machine is
> > working (exactly as Soeren said).
> 
> Your graphics adapter is different from the Soeren's one and the fact that
> "echo mem > /sys/power/state" works for you now is probably a result of the
> recent changes in the i915 driver that is now supposed to handle suspend
> and resume.

I tried to use vbetool to get my text console back with 2.6.24 after a
suspend to RAM. As a result, I got a text working console, but a
crashing X server sometimes after resume, and the only way to get X
back was to reboot.

With 2.6.25-rc, the text console is fine after resume, due to the
recent changes to the Intel i915 DRM driver. Maybe those people who
used to use vbetool prior to 2.6.25 should check if this is still
needed.

Regards,
Tino
Comment 23 Anonymous Emailer 2008-04-08 05:35:20 UTC
Reply-To: romanol@upcomillas.es



On Tue, 2008-04-08 at 10:58 +0200, Tino Keitel wrote:
> With 2.6.25-rc, the text console is fine after resume, due to the
> recent changes to the Intel i915 DRM driver. Maybe those people who
> used to use vbetool prior to 2.6.25 should check if this is still
> needed.

Yep, the problem is just that: in 2.6.24 vbetool hacks (in my case,
using s2ram -p -m options) was needed to resume graphics. Now they are
not needed anymore, and using them _break_ resume.

So, people with a working suspend-to-ram setup (even using the whitelist
in s2ram, I mean, simply calling s2ram) will discover that 2.6.25 break
their machine. Removing the s2ram package and suspending with
kernel-only machinery will work, but... well, it's not user-friendly.
 
Romano 
Comment 24 Soeren Sonnenburg 2008-04-08 05:40:21 UTC
On Tue, 2008-04-08 at 14:35 +0200, Romano Giannetti wrote:
> 
> On Tue, 2008-04-08 at 10:58 +0200, Tino Keitel wrote:
> > With 2.6.25-rc, the text console is fine after resume, due to the
> > recent changes to the Intel i915 DRM driver. Maybe those people who
> > used to use vbetool prior to 2.6.25 should check if this is still
> > needed.
> 
> Yep, the problem is just that: in 2.6.24 vbetool hacks (in my case,
> using s2ram -p -m options) was needed to resume graphics. Now they are
> not needed anymore, and using them _break_ resume.
> 
> So, people with a working suspend-to-ram setup (even using the whitelist
> in s2ram, I mean, simply calling s2ram) will discover that 2.6.25 break
> their machine. Removing the s2ram package and suspending with
> kernel-only machinery will work, but... well, it's not user-friendly.

The above holds only if you have an intel graphics adapter. For me
(radeon) it really breaks (as in echo mem >/sys/power/state leaves me a
black screen on resume and manually typing vbetool post or vbetool
vgamode simply hangs the machine).

Soeren
Comment 25 Soeren Sonnenburg 2008-04-08 05:40:31 UTC
The above holds only if you have an intel graphics adapter. For me
(radeon) it really breaks (as in echo mem >/sys/power/state leaves me a
black screen on resume and manually typing vbetool post or vbetool
vgamode simply hangs the machine).

Soeren
Comment 26 Fabio Comolli 2008-04-08 05:52:44 UTC
On Tue, Apr 8, 2008 at 2:39 PM, Soeren Sonnenburg <kernel@nn7.de> wrote:
> On Tue, 2008-04-08 at 14:35 +0200, Romano Giannetti wrote:
>  >
>  > On Tue, 2008-04-08 at 10:58 +0200, Tino Keitel wrote:
>  > > With 2.6.25-rc, the text console is fine after resume, due to the
>  > > recent changes to the Intel i915 DRM driver. Maybe those people who
>  > > used to use vbetool prior to 2.6.25 should check if this is still
>  > > needed.
>  >
>  > Yep, the problem is just that: in 2.6.24 vbetool hacks (in my case,
>  > using s2ram -p -m options) was needed to resume graphics. Now they are
>  > not needed anymore, and using them _break_ resume.
>  >
>  > So, people with a working suspend-to-ram setup (even using the whitelist
>  > in s2ram, I mean, simply calling s2ram) will discover that 2.6.25 break
>  > their machine. Removing the s2ram package and suspending with
>  > kernel-only machinery will work, but... well, it's not user-friendly.
>
>  The above holds only if you have an intel graphics adapter. For me
>  (radeon) it really breaks (as in echo mem >/sys/power/state leaves me a
>  black screen on resume and manually typing vbetool post or vbetool
>  vgamode simply hangs the machine).
>

For me (radeon X700) using binary fglrx xorg driver without the binary
kernel module (which does not compile under .25rc for me)
resume-from-ram works using s2ram.

Lightly tested with -rc8.

My laptop is in whitelist as VBE_POST|VBE_SAVE|NOFB .

>  Soeren

Fabio
Comment 27 Soeren Sonnenburg 2008-04-08 06:32:56 UTC
On Tue, 2008-04-08 at 14:52 +0200, Fabio Comolli wrote:
> On Tue, Apr 8, 2008 at 2:39 PM, Soeren Sonnenburg <kernel@nn7.de> wrote:
> > On Tue, 2008-04-08 at 14:35 +0200, Romano Giannetti wrote:
> >  >
> >  > On Tue, 2008-04-08 at 10:58 +0200, Tino Keitel wrote:
> >  > > With 2.6.25-rc, the text console is fine after resume, due to the
> >  > > recent changes to the Intel i915 DRM driver. Maybe those people who
> >  > > used to use vbetool prior to 2.6.25 should check if this is still
> >  > > needed.
> >  >
> >  > Yep, the problem is just that: in 2.6.24 vbetool hacks (in my case,
> >  > using s2ram -p -m options) was needed to resume graphics. Now they are
> >  > not needed anymore, and using them _break_ resume.
> >  >
> >  > So, people with a working suspend-to-ram setup (even using the whitelist
> >  > in s2ram, I mean, simply calling s2ram) will discover that 2.6.25 break
> >  > their machine. Removing the s2ram package and suspending with
> >  > kernel-only machinery will work, but... well, it's not user-friendly.
> >
> >  The above holds only if you have an intel graphics adapter. For me
> >  (radeon) it really breaks (as in echo mem >/sys/power/state leaves me a
> >  black screen on resume and manually typing vbetool post or vbetool
> >  vgamode simply hangs the machine).
> >
> 
> For me (radeon X700) using binary fglrx xorg driver without the binary
> kernel module (which does not compile under .25rc for me)
> resume-from-ram works using s2ram.
> 
> Lightly tested with -rc8.
> 
> My laptop is in whitelist as VBE_POST|VBE_SAVE|NOFB .

I am talking about console only. X is a completely different issue
especially with fglrx (which will very likely do the re-init).

Soeren
Comment 28 Mark Lord 2008-04-08 07:15:22 UTC
Mmmm.. My Dell Inspiron 9400 has an ATI X1400 card (ugh) in it, and I'm forced (for now) to use fglrx for X, but without the kernel binary module.

Works perfectly, until 2.6.25-rc*.  Now, much of the time on resume from RAM,
the screen goes "snowy", or sometimes "jittery", and sometimes just stops
providing backing store for windows and the like.

Something new in 2.6.25 is misconfiguring the card registers on resume, I guess.

Is there a way to dump the card config, to compare with 2.6.24 ?

My suspend-to-RAM sequence does not bother with vbetool (not needed), but it does first switch to a text console, before doing the suspend.

Cheers
Comment 29 Soeren Sonnenburg 2008-04-08 07:30:24 UTC
does/did suspend to ram work for you on console only (without fglrx) in 2.6.24 and 25-rc?
Comment 30 Anonymous Emailer 2008-04-08 07:41:57 UTC
Reply-To: mjg59@srcf.ucam.org

On Tue, Apr 08, 2008 at 02:35:07PM +0200, Romano Giannetti wrote:

> So, people with a working suspend-to-ram setup (even using the whitelist
> in s2ram, I mean, simply calling s2ram) will discover that 2.6.25 break
> their machine. Removing the s2ram package and suspending with
> kernel-only machinery will work, but... well, it's not user-friendly.

The assumption that a static table of VBE-based quirks can be used 
without paying attention to the capabilities of the video driver has 
always been broken, though I'll freely admit that it's all my fault in 
the first place...
Comment 31 Anonymous Emailer 2008-04-08 08:13:46 UTC
Reply-To: jesse.barnes@intel.com

On Tuesday, April 08, 2008 7:41 am Matthew Garrett wrote:
> On Tue, Apr 08, 2008 at 02:35:07PM +0200, Romano Giannetti wrote:
> > So, people with a working suspend-to-ram setup (even using the whitelist
> > in s2ram, I mean, simply calling s2ram) will discover that 2.6.25 break
> > their machine. Removing the s2ram package and suspending with
> > kernel-only machinery will work, but... well, it's not user-friendly.
>
> The assumption that a static table of VBE-based quirks can be used
> without paying attention to the capabilities of the video driver has
> always been broken, though I'll freely admit that it's all my fault in
> the first place...

That said, running vbetool from the console after resuming into it with a new 
i915 driver shouldn't kill your machine...

Romano, you say this was working for you before with the suspend/resume 
enabled i915 driver, right?  So something else must have broken?

You can run the upstream DRM modules against 2.6.24 to insulate yourself from 
anything in 2.6.25 that might have broken things...  That would be a good 
data point.

Jesse
Comment 32 Mark Lord 2008-04-08 08:32:39 UTC
>does/did suspend to ram work for you on console only (without fglrx) in 2.6.24
and 25-rc?

Mmm... It turns out I *did* have a small vbetool hack in the s/r script, specifically to get console-only working in 2.6.24 and earlier.

Removing that small hack, *seems* to have cured 2.6.25 on the machine now, so I'll just run with that, and leave y'all back to your intel chipset issues.

Cheers
Comment 33 Adrian Bunk 2008-04-08 08:42:43 UTC
There seem to be several different issues discussed in this bug.

Let's use this bug *only* for the following regression Soeren reported:
- on resume (from console) s2ram -f -p does not anymore give me my display
back, however blindly typing reboot or s2ram again works (system is alive).

Please open one bugs for each other issues you run into copying the information you already stated here into this bug and the information whether it works with 2.6.24.

It doesn't matter if one person opens 3 bug reports (unfortunately that's nothing unusual for suspend/resume problems) or if we end up with 5 reports for the same issue, but it's simply impossible to keep track of what happened here in this bug.
Comment 34 Romano Giannetti 2008-04-08 09:50:43 UTC
On Tue, 2008-04-08 at 08:13 -0700, bugme-daemon@bugzilla.kernel.org
wrote:
> Romano, you say this was working for you before with the suspend/resume 
> enabled i915 driver, right?  So something else must have broken?

No, I didn't make myself clear enough. What I said is that 2.6.24
suspend/resume worked with s2ram -f -p -m, and display did nor resume
with a plain echo mem > /sys/power/state. With 2.6.25-rc8, the things is
nicely reverted :-) 

> You can run the upstream DRM modules against 2.6.24 to insulate yourself from 
> anything in 2.6.25 that might have broken things...  That would be a good 
> data point.

Hmm, I could try this. Could please give me more detailed instructions?
I mean, I start with 2.6.24.4 and...

Thanks,
	Romano 
Comment 35 Rafael J. Wysocki 2008-04-09 14:01:32 UTC
The problem is present in 2.6.25-rc8-git7.

References : http://lkml.org/lkml/2008/4/9/40
References : http://lkml.org/lkml/2008/4/9/51
Comment 36 Rafael J. Wysocki 2008-04-11 13:41:11 UTC
Created attachment 15736 [details]
Debug patch to test

Soeren, can you see if the attached patch has any effect on the suspend problem on your system?
Comment 37 Soeren Sonnenburg 2008-04-11 14:29:47 UTC
the patch from #36 did not help (display remained blank) :(
Comment 38 Rafael J. Wysocki 2008-04-13 10:41:07 UTC
References : http://lkml.org/lkml/2008/4/13/73
Comment 39 HJH 2008-04-20 12:00:34 UTC
On 2.6.25 final nothing changed:
- s2ram -f -a3 -m works from the console, but not from X in the sense that the machine always does suspend, but only resumes when working from the console.

I also noticed the suspend led (the moon on the X61) only works when working from using the console and not when using X.
Comment 40 Rafael J. Wysocki 2008-04-20 12:07:35 UTC
Well, what happens if you do:

# echo 8 > /proc/sys/kernel/printk
# echo core > /sys/power/pm_test
# echo mem > /sys/power/state

from under X (assuming you have compiled the kernel with CONFIG_PM_DEBUG set)?
Comment 41 HJH 2008-04-21 08:48:44 UTC
Created attachment 15829 [details]
dmesg output

I did the following:

# echo 8 > /proc/sys/kernel/printk
# echo core > /sys/power/pm_test
# echo mem > /sys/power/state

the output can be found in the attached dmesg.txt file
Comment 42 Rafael J. Wysocki 2008-04-21 08:53:44 UTC
Did the system work correctly after that?
Comment 43 HJH 2008-04-21 09:31:58 UTC
Good point; yes it did.
Comment 44 Rafael J. Wysocki 2008-04-23 14:24:27 UTC
This means the kernel handles correctly everything it really controls.  What breaks is the interaction between the kernel and the BIOS.  It will be difficult to figure out what the problem really is.
Comment 45 Len Brown 2008-06-13 19:29:14 UTC
Soeren,
Please see if this command changes anything:
echo 1 > /proc/acpi/video/*/DOS

(should have a value of 0 before this).
And if rmmod video makes any difference.

Everybody else,
If you don't have a macbook pro or a machine that with ATI
graphics failing just like it, please do not type in to this bug report.
Comment 46 Soeren Sonnenburg 2008-06-14 03:19:21 UTC
Good catch Len,

while doing echo 1 > /proc/acpi/video/*/DOS doesn't help or change anything (yes it was 0 before).

After boot s2ram fails with the video module loaded but when it is once removed it works, i.e.

s2ram -> after resume black screen
rmmod video
s2ram -> screen comes back
modprobe video
s2ram -> screen comes back

(all on 2.6.26rc5+git)
Comment 47 Soeren Sonnenburg 2008-06-20 09:09:14 UTC
Forget what I said. This problem also happens even when the video module is unloaded (or not even compiled in the kernel). It just does not happen all the time, so I guess it is another wrong timing - bad luck thing :(
Comment 48 Soeren Sonnenburg 2008-06-21 00:43:46 UTC
OK, some statistics: Booting 2.6.26-rc7 and doing s2ram 4 times results in 3 times the display coming back correctly and once it remained black.

That is with the video module and everything loaded.
Comment 49 Soeren Sonnenburg 2008-09-23 05:32:46 UTC
This still happens on 2.6.27-rc7. My only hope how this will be resolved is kernel based modesetting.
Comment 50 Zhang Rui 2008-11-20 20:02:09 UTC
(In reply to comment #49)
> This still happens on 2.6.27-rc7. My only hope how this will be resolved is
> kernel based modesetting.
> 
For intel graphics, the black screen issue has already been fixed in the current drm driver, which is part of kernel modesetting work.

And in order to fix this issue, the ATI drm driver needs to save/restore the screen during suspend/resume.
we should probably move this bug to the video/drm category, what do you think, rafael?
Comment 51 Zhang Rui 2009-03-18 19:22:26 UTC
(In reply to comment #49)
> This still happens on 2.6.27-rc7. My only hope how this will be resolved is
> kernel based modesetting.
> 
yes, I talked with a graphics guy.
Intel is not the only one that's going to support KMS. so you're right, KMS should help here.
Comment 52 Florian Mickler 2010-08-17 18:14:48 UTC
With the advent of kernel based mode-setting suspend/resume is hopefully fixed now. Please reopen, if this problem still persists.

Note You need to log in before you can comment on or make changes to this bug.