Created attachment 16852 [details] Xorg log of the session Linux 2.6.25, Debian testing (with xorg sid packages). Intel driver 2.3.1. I use vanilla kernel hibernate(to disk) using hibernate package, AFAIK I don't use video POST or vbetool for this procedure. This is a Dell inspiron 510m laptop with Intel 855GM video card. When I trigger hibernation all runs fine, and when I restore all looks normally, till I get back to Xorg. In this point, screen stays at text console and stops working. System's not totally dead, since I can ctrl-alt-del to reboot. I'm attaching the full backtrace from Xorg core dump and xorg log. This is the video driver section for Xorg: Section "Device" Identifier "Intel Corporation 82852/855GM Integrated Graphics Device" Driver "intel" BusID "PCI:0:2:0" Option "ModeDebug" "1" Option "ForceBIOS" "1024x768=1400x1050" EndSection This is the xorg backtrace I have: #0 0xb7ef1424 in __kernel_vsyscall () #1 0xb7c8cef5 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7c8e871 in abort () from /lib/i686/cmov/libc.so.6 #3 0x081bbbab in FatalError (f=0xb7a93c7c "lockup\n") at ../../os/log.c:554 #4 0xb7a5f6bc in I830WaitLpRing (pScrn=0x9532bb8, n=131064, timeout_millis=0) at ../../src/i830_accel.c:150 #5 0xb7a5fabc in I830Sync (pScrn=0x9532bb8) at ../../src/i830_accel.c:204 #6 0xb7a6c300 in i830_stop_ring (pScrn=0x9532bb8, flush=<value optimized out>) at ../../src/i830_driver.c:1822 #7 0xb7a6c467 in I830LeaveVT (scrnIndex=0, flags=0) at ../../src/i830_driver.c:3213 #8 0x080d86bd in xf86XVLeaveVT (index=0, flags=0) at ../../../../hw/xfree86/common/xf86xv.c:1278 #9 0xb7b0aaef in glxDRILeaveVT (index=0, flags=0) at ../../../GL/glx/glxdri.c:1004 #10 0x080a8b7d in AbortDDX () at ../../../../hw/xfree86/common/xf86Init.c:1112 #11 0x081bb618 in AbortServer () at ../../os/log.c:406 #12 0x081bbb96 in FatalError (f=0xb7a93c7c "lockup\n") at ../../os/log.c:552 #13 0xb7a5f6bc in I830WaitLpRing (pScrn=0x9532bb8, n=131064, timeout_millis=0) at ../../src/i830_accel.c:150 #14 0xb7a5fabc in I830Sync (pScrn=0x9532bb8) at ../../src/i830_accel.c:204 #15 0xb7a828ca in I830EXASync (pScreen=0x953f808, marker=0) at ../../src/i830_exa.c:156 #16 0xb7994762 in exaWaitSync (pScreen=0xcc2) at ../../exa/exa.c:806 #17 0xb79950f2 in exaPrepareAccess (pDrawable=0xabd02008, index=0) at ../../exa/exa.c:352 #18 0xb7998b11 in exaMoveInPixmap (pPixmap=0xabd02008) at ../../exa/exa_migration.c:223 #19 0xb7999187 in exaDoMigration (pixmaps=0xbfd0b3d4, npixmaps=3, can_accel=1) at ../../exa/exa_migration.c:626 #20 0xb799a0fe in exaTryDriverComposite (op=3 '\003', pSrc=0x9a8ba00, pMask=0x9a8bad8, pDst=0x9a6ee80, xSrc=0, ySrc=0, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>, height=<value optimized out>) at ../../exa/exa_render.c:391 #21 0xb799ab68 in exaComposite (op=3 '\003', pSrc=0x9a8ba00, pMask=0x9a8bad8, pDst=0x9a6ee80, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=723, yDst=447, width=250, height=290) at ../../exa/exa_render.c:709 #22 0x08170283 in damageComposite (op=0 '\0', pSrc=0x9a8ba00, pMask=0x9a8bad8, pDst=0x9a6ee80, xSrc=<value optimized out>, ySrc=<value optimized out>, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>, height=<value optimized out>) at ../../../miext/damage/damage.c:580 #23 0x081575d0 in CompositePicture (op=3 '\003', pSrc=0x9a8ba00, pMask=0x9a8bad8, pDst=0x9a6ee80, xSrc=<value optimized out>, ySrc=<value optimized out>, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>, height=<value optimized out>) at ../../render/picture.c:1756 #24 0x0815d5af in ProcRenderComposite (client=0x9a2aa28) at ../../render/render.c:758 #25 0x0815a465 in ProcRenderDispatch (client=0xcc2) at ../../render/render.c:2002 #26 0x0814dbee in XaceCatchExtProc (client=0x9a2aa28) at ../../Xext/xace.c:299 #27 0x0808d19f in Dispatch () at ../../dix/dispatch.c:502 #28 0x080746bb in main (argc=8, argv=0xbfd0bc44, envp=Cannot access memory at address 0xcca ) at ../../dix/main.c:452
Created attachment 16853 [details] Full backtrace of the Xorg core.
I can't reproduce this problem on my 855GM, with 2.6.25 kernel and 2.3.1, though I'm not using Debian.
Do you think this could be a Dell laptop specific issue? Is there any further test I can do? I forgot to mention that I'm using vesafb text console, which may be relevant. Also I'll try tweaking POST and vbetool stuff to investigate different possibilities. Regards,
Trying without any framebuffer drivers loaded could help narrow it down. Also I've never seen the "ForceBIOS" option you're using; are you running a patched 2.3.1 driver? In the meantime I'll try to reproduce on my 855GM laptop...
Also, you may need some fixes in your kernel, it would be good if you had a59e122a67b88925944d3bbf33d15229cf0fc3de and e948e99400b28af152414f15f8c8023ff2430b79 from Linus' kernel tree patched in.
Created attachment 16902 [details] [review] Fixes from upstream ported back to 2.6.25 Here are a couple of important fixes that didn't make it into 2.6.25. They might help with your problem.
Thanks for the comments Jesse. Indeed I thought about doing some tests without fb drivers, only I hand't have the time yet. Expect news soon. The ForceBios option looks like a legacy option while I was trying to get 1400x1050 on this laptop (which I was unable BTW). I'll also try removing it. I run bare Debian 2.3.1 xorg driver version package, so I don't think there's any special patch to driver. Regarding the linux patch, looks quite relevant. I will also try it. Regards,
So far I've tried removing the vesa framebuffer text mode, styaing with old regular text mode. This avoids the problem, so I have a workaround. The ForceBios option seems irrelevant, since tests result the same with or without it. I'll try with the kernel patch soon. Regards,
Ok so at least you can avoid the problem by removing vesafb, that's good. So there must be some register difference between the vesafb & regular text mode configurations that causes X to fail. Can you capture a register dump (using intel_reg_dumper) after resuming from hibernate with and without the vesafb driver loaded but before switching back to X? For comparison it would also be good to have both vesafb & non-vesafb register dumps from a fresh boot. Thanks.
No time to patch kernel yet, sorry for that. But I nearly have ended to perform the intel_reg_dumper tests. My test procedure is this: · Boot in text/vesa mode · Wait till kdm (Xorg) login. · Login as root · Invoke intel_reg_dumper and save result · Go to a text/vesa console. · Invoke intel_reg_dumper and save result. · Hibernate. · Invoke intel_reg_dumper and save result · Go back to Xorg. · Invoke intel_reg_dumper and save result. The results file are named upon this pattern: ·bootmode-: vesa or text ·X-: if regdump is for Xorg, none for console ·hibernate: if regdump is get after hibernate. ·.regdump Unfortunately, the most important dump, the one for X after the hibernate is missing for the moment. I'll need to get it from a remote computer. Maybe tomorrow... Regards,
Created attachment 16985 [details] Regdump for text console after a fresh reboot.
Created attachment 16986 [details] Regdump for Xorg console after a fresh reboot on text mode.
Created attachment 16987 [details] Regdump for text console after hibernate.
Created attachment 16988 [details] Regdump for Xorg after a hibernate cycle with text console.
Created attachment 16989 [details] Regdump for vesa console after a fresh reboot.
Created attachment 16990 [details] Regdump for Xorg after a fresh reboot with vesa console.
Created attachment 16991 [details] Regdump for vesa console after a hibernate cycle.
Created attachment 17062 [details] Regdump when on Xorg after waking up from hibernate using vesa console. This is the last part of the sequence, the register dump after having woken up from hibernate. There are plenty of differences from the previous logical status, vesa-X.regdump(https://bugs.freedesktop.org/attachment.cgi?id=16990) with this one. Funny enough, I've been unable to reproduce the problem today. Now it's working perfectly. And I can't see any upgrades related to this. Not closing bug yet, but awaiting instructions. Regards,
Hm, nothing changed? I'll take a look at the register dumps when I get a chance.
Is this problem still gone? If so, I guess it's been fixed. :) The main difference between your "fresh boot + vesafb" and "post resume w/vesafb" is that in the post resume case, pipe A seems to have a mode programmed.
I guess this can be closed.
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.