- 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.

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 ...

same on 2.6.25-rc7.
Works fine on 2.6.24

please try 2.6.25-rc8, for it includes the resume-order patch
7731ce63d9a863c987dd87b0425451fff0e6cdc8

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.

References : http://lkml.org/lkml/2008/4/2/496

Confirmed.
Still no resume after suspend in 2.6.25-rc8

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.

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.

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

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?

References : http://lkml.org/lkml/2008/4/6/1

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.

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....

Sigh.  Please try reverting http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=92c9d07507f0a90b64172bfede7e6fa845e8e66b

OK, compiles now. However the black display after resume remains :(

Can you attach your current .config, please?

Created attachment 15654 [details]
kernel config

the config with which I am seeing the hang.

Can you test with CONFIG_DRM unset, please?

I did, still a black display...

It seems to be an ACPI problem, then.

Can you check out commit c697eecebc6cfc0b393afea3c4ff1a5041526ad1 and see if that works?

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

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 

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

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

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

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

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

does/did suspend to ram work for you on console only (without fglrx) in 2.6.24 and 25-rc?

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...

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

>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

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.

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 

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

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?

the patch from #36 did not help (display remained blank) :(

References : http://lkml.org/lkml/2008/4/13/73

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.

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)?

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

Did the system work correctly after that?

Good point; yes it did.

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.

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.

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)

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 :(

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.

This still happens on 2.6.27-rc7. My only hope how this will be resolved is kernel based modesetting.

(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?

(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.

With the advent of kernel based mode-setting suspend/resume is hopefully fixed now. Please reopen, if this problem still persists.