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 |
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.
Carlos and me worked pinpointing a regression in suspend to ram on our near-identical TP R50e 1634 systems. We also observe that calling "cat /proc/acpi/ibm/video" freezes the kernel if we are using i810/intel drivers after version 2.0.0. But now we will focus in the s2ram behaviour. We use the following notation: s2ram = "# echo ram > /sys/power/state" s2disk = "# echo disk > /sys/power/state". == On i810 versions 1.6.5 and 1.7.4, both s2ram and s2disk work fine. (I remember it crashing on resume, though, from times long gone.) == From versions 2.0.0 to 2.1.1 of the intel driver we find the following behaviour on the 855GM chipset (rev02): - After booting (NOT resuming from disk), resume from s2ram leaves us corrupted output. Restarting X won't help. I can suspend to disk though, and the screen comes back fine after resuming. In other words, we can "repair" the screen output by s2disk. - After the first s2disk, we notice that s2ram starts working flawlessly. No matter how many times we use it, it always resumes to a perfect-state X. A corrupted screen here means: the consoles are invisible, the background is invisible, the WM (fluxbox and Window Maker) elements (menu, taskbar) are visible, there is no blanking, though. == From 2.1.99 to 2.2.0, resuming from s2ram always fails. s2disk is fine by itself (Still "repairs" the screen), but does not make s2ram work afterwards. Also, openGL will not work, but that probably is an existing, but definitely other bug. On 2.2.0, the screen corruption has inverted, in a sense... The WM borders and the consoles (aterms) are there, but the toolbar entries and the menu are invisible -- the other half. =========================== We both ran these tests on vanilla 2.6.24-rc2 and -rc3, with dri support, no framebuffer at all. Carlos has also made these tests on various older kernels, and the s2ram problem is the same: i810-1.7.4 and later versions don't work (and require the s2disk trick). My system is a Gentoo using xorg-server-1.3.0.0-r2 media-libs/mesa-6.5.2-r1 Carlos uses Mandriva 2008 xorg-server-1.4-7mdv2008.1 mesa-7.0.1-12mdv2008.1 We will provide logs on request, instead of flooding this with all logs in all circumstances -- we don't really know what provides the right pointers here. We found no difference in behaviour with suspending to disk or to ram from console or from X on drivers >=2.1.0 ========================================== My Module and Device sections in xorg.conf: Section "Module" Load "extmod" Load "dri" Load "glx" Load "dbe" Load "record" Load "xtrap" Load "type1" Load "freetype" EndSection Section "Device" Identifier "Card0" Driver "i810" # Driver "vesa" VendorName "Intel Corp." BoardName "82852/855GM Integrated Graphics Device" BusID "PCI:0:2:0" # Option "NoDRI" Option "NoAccel" "false" Option "DRI" "true" # andrem 2007-05-22: sleep mode requires -- not # Option "VBERestore" "true" EndSection ==== And Carlos's: Section "Module" Load "dbe" # Double-Buffering Extension Load "v4l" # Video for Linux Load "extmod" Load "type1" Load "freetype" Load "glx" # 3D layer Load "dri" # direct rendering EndSection Section "Device" Identifier "device1" VendorName "Intel Corporation" BoardName "Intel 810 and later" Driver "i810" Screen 0 BusID "PCI:0:2:0" Option "DPMS" Option "XaaNoOffscreenPixmaps" "1" Option "VBERestore" "yes" EndSection Section "Device" Identifier "device2" VendorName "Intel Corporation" BoardName "Intel 810 and later" Driver "i810" Screen 0 BusID "PCI:0:2:1" Option "DPMS" Option "XaaNoOffscreenPixmaps" "1" Option "VBERestore" "yes" EndSection =========================== My lspci -vvv video section: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA]) Subsystem: IBM Thinkpad R50e model 1634 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M] Region 1: Memory at d0000000 (32-bit, non-prefetchable) [size=512K] Region 2: I/O ports at 1800 [size=8] Capabilities: [d0] Power Management version 1 Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) Subsystem: IBM Thinkpad R50e model 1634 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Region 0: Memory at e8000000 (32-bit, prefetchable) [disabled] [size=128M] Region 1: Memory at d0080000 (32-bit, non-prefetchable) [disabled] [size=512K] Capabilities: [d0] Power Management version 1 Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- === Carlos's differs slightly: Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M] Region 1: Memory at d0080000 (32-bit, non-prefetchable) [size=512K] He lacks the DisINTx- and INTx- entries, and his Memory lines lack "[disabled]". We can't interpret neither...