Carlos, you shouldn't use the VBE restore option anymore.

Can either of you reproduce this problem by just VT switching rather than suspend/resume?

If not, can you build the intel register dumper program (src/reg_dumper in the git tree) and get register snapshots from before and after the resume?

I won't use VBE restore anymore, but I did lots of tests without it before and
I couldn't notice any difference that I can remember anyway.

About your VT question; VT switching is fine for me. The problem appears only
after a s2ram (if no s2disk was made before).

Regarding git: I have the latest (xf86-video-intel-2.2.0-2-g7f9ceff) tree but 
the compilation fails on this:

/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..    -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations      -Wnested-externs -fno-strict-aliasing -I/usr/include/xorg -I/usr/include/pixman-1   -I/usr/include/drm -I/usr/include/X11/dri -DI830_XV -DI830_USE_XAA -DI830_USE_EXA -g -O2 -MT i830_driver.lo -MD -MP -MF .deps/i830_driver.Tpo -c -o i830_driver.lo i830_driver.c
 gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri -DI830_XV -DI830_USE_XAA -DI830_USE_EXA -g -O2 -MT i830_driver.lo -MD -MP -MF .deps/i830_driver.Tpo -c i830_driver.c  -fPIC -DPIC -o .libs/i830_driver.o
i830_driver.c: In function 'I830InitFBManager':
i830_driver.c:2212: warning: the address of 'ScreenBox' will always evaluate as 'true'
i830_driver.c: In function 'I830LeaveVT':
i830_driver.c:3029: error: too many arguments to function 'drmMMLock'
i830_driver.c: In function 'I830EnterVT':
i830_driver.c:3068: error: too many arguments to function 'drmMMUnlock'
i830_driver.c: In function 'I830CloseScreen':
i830_driver.c:3185: error: too many arguments to function 'drmMMUnlock'
make[3]: *** [i830_driver.lo] Error 1
make[3]: Leaving directory `/home/mafra/Download/xf86-video-intel/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mafra/Download/xf86-video-intel/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/mafra/Download/xf86-video-intel'
make: *** [all] Error 2

I have tried with both xorg-server 1.3 and 1.4 sources (by specifying the path with --with-xserver-source=), but the compilation fails the same way.

I was trying to use git-bisect before reporting the bug, because s2ram works 1.7.4 but not afterwards, but so far I haven't been able to compile the driver
using the git tree. I don't know what I am doing wrong.

And if I use the .tar.gz files in http://xorg.freedesktop.org/archive/individual/driver/
the 2.1.0 version compiles, but 2.0.0 does not. The error messages had something
to do i830_bios.h:30 and bios_reader.c. 

In one of my crazy attempts to compile it, I copied the edid.h and vdif.h files from xorg-server-1.2 and put them into src/bios_reader/ of the intel driver, and the compilation succeded (but I don't know exactly why and did not test
the resulting driver because I don't know if what I did was right).

So, do you think it would be fruitful if I spend some time trying to bisect this
regression? I will help though to make it compile first.

And suppose I could compile the git tree, what is the command to get the register snapshots?

Hm, what version of libdrm are you building against?  You'll need something fairly recent...  You'll also want to build against the 1.4 branch of the xserver tree.

I have here:

/usr/lib/libdrm.a
/usr/lib/libdrm.la
/usr/lib/libdrm.so
/usr/lib/libdrm.so.2
/usr/lib/libdrm.so.2.3.0

It looks like you're building with XF86DRI_MM enabled... that means you probably have the 2.3.1 libdrm headers or proto package installed somewhere.   Try building without that.

Once you have it building, cd to src/reg_dumper to build the intel_reg_dumper binary.  Then you can use it to get register dumps.

OK, now the compilation finishes fine without XF86DRI_MM.
But now reg_dumper fails:

[mafra@localhost:reg_dumper]$ make
gcc -DHAVE_CONFIG_H -I. -I../..     -Wall -Wpointer-arith -Wstrict-prototypes   -Wmissing-prototypes -Wmissing-declarations     -Wnested-externs -fno-strict-aliasing -I./.. -DREG_DUMPER -g -O2 -MT intel_reg_dumper-main.o -MD -MP -MF .deps/intel_reg_dumper-main.Tpo -c -o intel_reg_dumper-main.o `test -f 'main.c' || echo './'`main.c
main.c: In function ‘main’:
main.c:72: warning: implicit declaration of function ‘pci_device_map_range’
main.c:72: warning: nested extern declaration of ‘pci_device_map_range’
main.c:75: error: ‘PCI_DEV_MAP_FLAG_WRITABLE’ undeclared (first use in this function)
main.c:75: error: (Each undeclared identifier is reported only once
main.c:75: error: for each function it appears in.)
make: *** [intel_reg_dumper-main.o] Error 1

Where is PCI_DEV_MAP_FLAG_WRITABLE defined? I did a grep and got this:

[mafra@localhost:xf86-video-intel]$ grep -r PCI_DEV_MAP_FLAG_WRITABLE *
src/i810_driver.c:1413:                        PCI_DEV_MAP_FLAG_WRITABLE,
src/i810_driver.c:1450:                        PCI_DEV_MAP_FLAG_WRITABLE | PCI_DEV_MAP_FLAG_WRITE_COMBINE,
src/i830_driver.c:568:                         PCI_DEV_MAP_FLAG_WRITABLE,
src/i830_driver.c:611:                            PCI_DEV_MAP_FLAG_WRITABLE,
src/i830_driver.c:656:                         PCI_DEV_MAP_FLAG_WRITABLE | PCI_DEV_MAP_FLAG_WRITE_COMBINE,
src/reg_dumper/main.c:75:                               PCI_DEV_MAP_FLAG_WRITABLE,

What should I do?

From running configure I have these lines which may be related to my compilation problem:

checking whether XSERVER_LIBPCIACCESS is declared... no
checking for PCIACCESS... yes

How can I have XSERVER_LIBPCIACCESS declared?

Hmm...I am sorry for the stupid questions :-(

I think the X server will also need to be configured for libpciaccess support...

I fixed the compilation! It turned out to be an outdated libpciaccess, although I am using the mandriva version 0.9.1-1mdv2008.0 from Aug 28 2007.

I cloned the git tree git://anongit.freedesktop.org/git/xorg/lib/libpciaccess and
after compiling and instaling it, I had no more problems.

Attached is the result of running intel_reg_dumper.

Created attachment 12760 [details]
The result of running intel_reg_dumper

Excellent.  Now that you have it working, I need intel_reg_dumper output from the following times:
  - fresh boot, before X starts
  - after X starts, but while VT switched to the console
then suspend the machine using your script
  - after resume, but before VT switching back to X

So all of the dumping needs to be done in text mode with X running, except for the first one.  Then I can diff the various dumps and maybe find some clues about what's going wrong.

Just to make clear the dump states in the attached files:

1) Boot into 2.6.24-rc3. In console 1, as root I dumped the state 
in the file fresh_before_X.txt

2) Switched to console 2 (and let root logged in 1), and as my user login
I started X (Window Maker). After a while doing nothing I switched to 
console 1 (root) and dumped the state in the file after_X_console.txt. So
X was running, but I was in the console 1.

3) While still in console 1 as root I did 'echo mem > /sys/power/state'. After
resuming, in console 1, I dumped the state in after_s2ram_console.txt

4) Just for the sake of it I went back to X to check things. It was screwed up,
the window maker menu (which I open with F12) was transparent, the background was dark, and calling the menu again would overlap with the previous one. It was a mess (using intel-2.1.0).

Hmm...do you want me to repeat these steps with intel-2.2.0? Or with 1.7.4 (in which s2ram works)?

Created attachment 12785 [details]
Result of intel_reg_dumper after fresh boot and before loading X

Created attachment 12786 [details]
Result of intel_reg_dumper after loading X and coming back to console to dump state

Created attachment 12787 [details]
After s2ram, while in console (with X running "in the background" VT 7)

Hm, no real help there:
--- pre-suspend.txt     2007-11-28 14:47:06.000000000 -0800
+++ post-suspend.txt    2007-11-28 14:47:17.000000000 -0800
@@ -116,7 +116,7 @@
 (II):         TV_H_LUMA_59: 0x00000000
 (II):        TV_H_CHROMA_0: 0x00000000
 (II):       TV_H_CHROMA_59: 0x00000000
-(II):                 SR00: 0x03
+(II):                 SR00: 0x00
 (II):                 SR01: 0x00
 (II):                 SR02: 0x03
 (II):                 SR03: 0x00
@@ -160,9 +160,9 @@
 (II):                 CR0a: 0x0d
 (II):                 CR0b: 0x0e
 (II):                 CR0c: 0x00
-(II):                 CR0d: 0x00
-(II):                 CR0e: 0x05
-(II):                 CR0f: 0xa0
+(II):                 CR0d: 0x50
+(II):                 CR0e: 0x07
+(II):                 CR0f: 0xd0
 (II):                 CR10: 0x9c
 (II):                 CR11: 0x8e
 (II):                 CR12: 0x8f

Just a few VGA registers changed and I doubt they're causing the problems you're seeing.

Can you attach a screenshot of the corruption you see?

Created attachment 12808 [details]
X after a failed s2ram from console

This is after a fresh boot, starting X, going to console and typing 'echo mem > /sys/power/state', resuming from s2ram in console, and then switching to X again.

Created attachment 12809 [details]
X after "fixing" with s2disk

This is how the Window Maker screen looks like after "fixing" the previous corrupted state by doing a s2disk from console. The state shown in this picture is perfect and everything works fine.

To stress, this picture was taken after seeing the corrupted state of the 
previous attachment. And to fix it all I did was to go (from that corrupted 
wmaker) back to the console, 'echo disk > /sys/power/state', resume, switch 
back to Window Maker (and take this photo).

Can you attach a register dump from after the resume from s2disk but still VT switched away from X?

Would also be helpful to have register dumps from the pre-suspend, working X session, the post-resume, broken X session, and the post-s2disk, working X session, just in case.

Created attachment 12810 [details]
Intel_reg_dumper (in console) after switching from corrupted X

This is the intel_reg_dumper state after I switched back to the console, coming
from the corrupted Window Maker shown in the attachment 12808 [details].

Created attachment 12811 [details]
Intel_reg_dumper (in console) right after fixing with s2disk

This is intel_reg_dumper output after resuming from s2disk, still in console, _before_ switching to VT 7 to check that Window Maker was cured (as shown in
the photo of attachment 12809 [details]).

All the above was using intel-2.1.0.

And it is worth mentioning that if I do a s2ram from within X, when the system 
resumes into X, the laptop freezes (not even the Sysrq keys work, I have to
press the power button!).

I used to to exactly this (s2ram from within X) using i810-1.7.4, and it
worked fine.

Yeah, 2.1.x had some bugs like that, 2.2 may not crash for you.

Created attachment 12813 [details]
After s2ram+s2disk, the fonts in X are bad.

This screenshot show how the fonts are screwed after the s2ram+s2disk cycle
using intel-2.2.0. The fonts used in the terminal mrxvt are fine, though.

I will test later if intel-2.2.0 does not crash upon resume from within X.

Can you attach your X log from the 2.2 driver testing as well?

Btw, thanks for all your help with this, I don't have an 8xx test platform so I need lots of help with these types of bugs. :)

Here, resuming from S3 does not freeze anything with 2.1.0
(as well as with all other versions). I have just the corruption issue
as described, with 2.2.0 giving "inverse" corruption to 2.1.0's.

I'm trying to reproduce Carlos here, but still compiling 
my way towards 1.4 and hunting pciaccess.h, without which 
intel_reg_dumper denies to compile. 

Carlos, can you also capture register dumps from within X (e.g. in an xterm or something) for the broken and working cases?

I will attach two files containing intel_reg_dumper outputs.

1) working_within_X.txt: This is after booting 2.6.24-rc3, starting Window Maker,
doing a s2disk from mrxvt, resuming flawlessly to X, and then getting the dumper output. Just to confirm that this is the dump which works, right after writing
working_within_X.txt I typed in the same mrxvt "echo mem > /sys/power/state".
When I resumed the laptop, I got a perfect-state Window Maker. So that was
indeed the working case.

2) not_working_within_X.txt: This is after booting 2.6.24-rc3, starting Window Maker and using intel_reg_dumper from withing mrxvt. I did not s2ram yet, but
I've done this a million times before and I know that it won't work.

The diffs between 1) and 2) are big this time. I hope this will help you!

Do you think this could be a kernel issue also? I mean, if a fresh boot had
the same state as after a s2disk, then intel-2.1.0 (in this case) would be
perfect for me. 

Created attachment 12831 [details]
Inside X: A later s2ram from within X comes back perfect

Created attachment 12832 [details]
Dump from within X, a later s2ram will not work

I am using intel-2.1.0 on this tests.

I finally have my playground ready after Carlos helped me out
with his intel_reg_dumper binary.

I now have migrated to gentoo packages
x11-base/xorg-server-1.4-r2
media-libs/mesa-7.0.2
and I made myself a package for xf86-video-i810-2.2.0.

The 2.1.0 driver fails to build. Carlos tells me that
I can build it against the xorg-1.3 sources. But I
primarily wanted to check the 2.2.0 driver anyway.

With this, I went through dumping the registers
on console and in X after fresh boot, after S3, after s2disk,
in that order.

The symptoms are basically as described in the initial post,
only I was on xorg-1.3 then, but
with 1.4, I get dri support in X again and
in an aterm, the font colours go allwrong, showing different
shades of blue only. An xterm is fine. Font rendering regresses,
looking like the old days before xorg improved font rendering
spectacularly :-)

I can make out no difference in symptoms when going
to S3 or to disk from X or from console, also, my machine
won't freeze. Terminal switching does not change any matters.
My screen did not come back at all after
one S3, but I cannot reproduce this. And once, I got
corrupted fonts in the WM after a fresh boot, looking like
overlaid with the black and white pattern of the initial X
screen (this flurry something when there's no background at all).
That was repaired by s2disk after ruining it further with S3,
with the exception of the menu, which was back to normal
after a WM (fluxbox) restart. NOT an X restart.
But I cannot reproduce that, either. But something is
mighty unstable with that driver...

====

Now, for the parcours:

After a boot to xdm and logging into X,
all is well (only once failed, see above).
I took a register dump in X
to reg_dump-postBoot-inX
switched to the console and dumped to
reg_dump-postBoot-inConsole.

I switched back to X and suspended to ram.
coming back, I dumped in corrupted X to
reg_dump-postS3-inX.

Then a switch to the console and another dump
to reg_dump-postS3-inConsole,
then an s2disk (from the console, for practical purposes)
and a dump in the console to reg_dump-postS2disk-inConsole,
and a switch to the restored and proper X to finally dump
reg_dump-postS2disk-inX.

And finally, I did another reboot not starting X in the
first place and dumped to reg_dump-postBoot-noX.

I compared the files (I can't "read" them, though).

Finally, I will attach my xorg log.

The differences to Carlos' dumps on 2.1.0 are pretty few,
so I hope this may be instructive.

Created attachment 12843 [details]
reg_dumper after fresh boot in X

Created attachment 12844 [details]
reg_dumper after fresh boot in console

Created attachment 12845 [details]
reg_dumper after s2ram in X

Created attachment 12846 [details]
reg_dumper after s2ram in console

Created attachment 12847 [details]
reg_dumper after s2disk in X

Created attachment 12848 [details]
reg_dumper after s2disk in console

Created attachment 12849 [details]
reg_dumper after fresh boot in console, no X at all

Created attachment 12850 [details]
Xorg.log on andre's machine

Just for the records,
in Comment #31, I wrote:

>And once, I got
>corrupted fonts in the WM after a fresh boot, looking like
>overlaid with the black and white pattern of the initial X
>screen (this flurry something when there's no background at all).
>That was repaired by s2disk after ruining it further with S3,
>with the exception of the menu, which was back to normal
>after a WM (fluxbox) restart. NOT an X restart.
>But I cannot reproduce that

That problem looks exactly like Bug #11402
by description and by screenshot,
which is supposed to be fixed in git.

Regarding the bug which Andre points out in comment #40, there is 
a screenshot there showing a font corruption which looks exactly the same
font corruption that I have after a s2ram+s2disk cycle using intel-2.2.0.  Compare
the attachment named "snapshot" in bug 11402 with the attachment I posted here,
named "After s2ram+s2disk, the fonts in X are bad."

I don't have this particular font problem for versions earlier than intel-2.2.0, 
and it happens (in 2.2.0) only after s2ram+s2disk.

Carlos, can you git bisect the problem?  There were lots of changes between 2.1.0 and 2.2.0; it would be helpful to know which one caused your problem.  The git manpage describes how to do it, basically you have to pick a good commit (probably the 2.1.0 commit) and a bad one, then bisect the commits until you find the bad one.

I bisected the font problem of comment #41 down to 3 commits left. I can't
completely finish the bisection because the last step produced a driver which 
crashes when resuming from s2ram, and that's a different problem from the font 
issue I wanted to hunt down. But hopefully those 3 commits will suffice.

For definiteness, the font problem happens after a full s2ram+s2disk cycle. The first s2ram resumes to a screwed up X, which is fixed by a subsequent s2disk up
to the "font problem" of attachment 12813 [details] in this bug.

Here is git bisect log:

[mafra@localhost:xf86-video-intel_bis]$ git bisect log
git-bisect start
# bad: [75ef3e669dac1259d282dcc8f54b197fc19f22b3] Replace ALLOCATE_LOCAL/DEALLOCATE_LOCAL with xalloc/xfree
git-bisect bad 75ef3e669dac1259d282dcc8f54b197fc19f22b3
# good: [3c552af65d28fafec1d09484a8914b690b961349] Update documentation and bump driver version to 2.1.0.
git-bisect good 3c552af65d28fafec1d09484a8914b690b961349
# good: [b73235f40497cfb10792ba191d4f6eac3a5df009] Fix pixmap offset
git-bisect good b73235f40497cfb10792ba191d4f6eac3a5df009
# good: [74ac5de14ebb77aeb39d698e9e8d188c9d9abd76] Adapt to libdrm buffer object
API changes.
git-bisect good 74ac5de14ebb77aeb39d698e9e8d188c9d9abd76
# bad: [4fe507957bf826d81a71cd63af17c5547d1023a1] Remove unused 'palette_enable' variable
git-bisect bad 4fe507957bf826d81a71cd63af17c5547d1023a1
# good: [7c88b58a93fce9fda59b6344acb87af16336e287] Clear compiler error: "void functions cannot return values"
git-bisect good 7c88b58a93fce9fda59b6344acb87af16336e287
# good: [b8770f710729d616b3ac72544aa522161a78f819] Setup 3D state at EnterVT time
git-bisect good b8770f710729d616b3ac72544aa522161a78f819
# bad: [cb4e5796f0537ea5e0e646d473930c7b826c85d8] Default to EXA
git-bisect bad cb4e5796f0537ea5e0e646d473930c7b826c85d8

There are 3 commits between last good and bad.

I hope this will help you!

In a private email, Andre asked me to test the EXA hypothesis suggested by git
bisect. If I use intel-2.2.0 with Option "AccelMethod" "XAA" then the font
problem after s2ram+s2disk goes away!

So the guilty one is:
[cb4e5796f0537ea5e0e646d473930c7b826c85d8] Default to EXA

I went to bisect the point at which I find the commit that leaves
me with corrupted output after any resume from S3, even after 
an s2disk (as described in the initial post).

I ended up with:

b8770f710729d616b3ac72544aa522161a78f819 is first bad commit
commit b8770f710729d616b3ac72544aa522161a78f819
Author: Jesse Barnes <jbarnes@hobbes.virtuousgeek.org>
Date:   Thu Nov 8 16:19:01 2007 -0800

    Setup 3D state at EnterVT time

    In the absence of full suspend/resume support in the kernel, we have to
    save/restore state in Enter/LeaveVT.  For 8xx chips, 3D state may be
lost
    during suspend/resume, so re-emit the basic setup at EnterVT time.

    Patch from Peter Clifton.

:040000 040000 07824f30e92b78f1a1a91f5d35155dd497b48b84
9bbe962f1dd35feea6caeba793d5760e6f132321 M      src

===

On my way there I noted that the described "inversion" of 
screen corruption, which I initially regarded as a related
telltale symptom does NOT coincide with this commit.

At least commit e784e152a8e84b6e447b55a5c7019e7b47e17621
(18 minutes after the offender) still shows the old corruption
pattern (as described for 2.1 versions) while already failing
constantly on S3. 

If it's worth pinpointing that one as well, let me know.
 

Interesting that this only occurs with EXA and seems related to the 3d invariant state... Any ideas Zhenyu?

Following up on the screen corruption issue from comment 45:

By using XAA acceleration, I get the old pattern of corruption,
with EXA, the modern rampation of it.

To avoid confusion: This does not change S3 functionality.
S3 always fails since commit b8770f710729d616b3ac72544aa522161a78f819,
before, it resumes fine from S3 when having suspended to disk once.

Yes...to avoid confusion I must say that the first S3 always fail. 

The font issue with EXA is another bug, and is avoided using the xorg.conf option I mentioned earlier.

What is intriguing is the fact that s2disk can fix the first S3. 

Back in the days of 1.7.4 I could suspend to ram just fine (no s2disk trick required!). I have already tried to git bisect this issue. But when I try to
compile 1.7.4 using the git repo the compilation fails. I really need more time 
to hunt down this issue, and I don't have it right now :-(

To summarize, EXA issue seems a dup of bug# 11402 and bug# 13456. For his bug, we can focus on why b8770f710729d616b3ac72544aa522161a78f819 cause resume from s3 fail...

Could you try with current driver git?

The EXA issue of comment #41 does not happen anymore with the latest git, I've
just tested it.

Thank you very much!

Ok, I think there's probably more than one bug here, but since Zhenyu fixed one I'm going to close it.  If there are other suspend/resume issues (aside from those reported in 11432, 12393 and elsewhere) please file a new bug and we can try to narrow it down.

Thanks a ton for all your testing.

Jesse