I am using the i810 driver on a Lenovo X60 tablet running kubuntu/feisty. lspci calls my video device an "Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)". When I resume from suspend on my machine, about half of the time the X server will start, freeze, and restart in an infinite loop. The X log from this crash contains the following: Error in I830WaitLpRing(), now is 353619, start is 351618 pgetbl_ctl: 0x3ffc0001 pgetbl_err: 0x0 ipeir: 0 iphdr: c000720 LP ring tail: 8 head: 18 len: 1f001 start 0 eir: 0 esr: 0 emr: ffff instdone: ffc1 instpm: 0 memmode: 306 instps: f84cc hwstam: ffff ier: a2 imr: ffff iir: 0 space: 8 wanted 80 DRIUnlock called when not locked (II) I810(0): [drm] removed 1 reserved context for kernel (II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xf8fdf000 at 0xb7c25000 Fatal server error: lockup This bug appears to be related to several others: 5774 (which has been closed), 10258, 10472.. There are also a number of people reporting this bug on launchpad (https://launchpad.net/bugs/28326). I have also tried the modesetting version if the i810 driver, which did not help.
I have the same problem on HP nx6110 with the same graphics card. Debian testting. I spent lot of time to get it worgking and now I am using old version 2:1.7.2-4 with vbetool, without 3d rendering. With 3d rendering it makes this problem and with newer version, it doesn't do anything, only black screen, even if 3d rendering is off :-(
Created attachment 12642 [details] Xorg-log after crash Same problem here, tested with - Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller - Gentoo system - xorg-server-1.4-r2 - xf86-video-i810 2.1.0, 2.1.1, 2.1.99 and current git version - kernel 2.6.22 and 2.6.23 - with framebuffer (vesa, uvesa) and without Steps to reproduce: 1. Boot system (drm and i915 unloaded) 2. Start X (everything's ok) 3. Use xterm or switch back to VT 4. s2ram 5. Resume X will crash as soon it is activated. It does not matter if you exit X and unload drm and i915 before suspending! X will crash when you try to restart it after resume. Other way to reproduce: 1. Start system (without X) 2. s2ram 3. resume 4. Start X -> everything is OK 5. Quit X 6. s2ram 7. resume 8. Start X -> Crash So I don't think this might be a kernel problem. Interesting line from the logfile: > space: 130800 wanted 131064 This value varies from time to time, so it seems to be a memory allocation problem?
Created attachment 12643 [details] my current xorg.conf
Created attachment 12644 [details] current kernel config
X doesn't crash when setting option "NoAccel" to true. But... no dri, no compiz and very slow window redraw (e.g. when moving windows). Just a temporary solution for me. This bug might be related to bug #11720.
Sounds like an intel driver bug.
Upping severity as this causes a crash/hang.
Have you tested with the latest git driver? We fixed several suspend/resume bugs (really Enter/LeaveVT bugs) for that release, hopefully yours was fixed as well. Could also be related to 11432 or 13196. It would be helpful if you could build the intel_reg_dumper tool and capture some register state from after the resume before the X crash along with a dump from before starting a working X session.
*** Bug 11720 has been marked as a duplicate of this bug. ***
Created attachment 13040 [details] Log the crashed server with current git tree I've just compiled and tested the current git version. The server still crashes (same procedure as described earlier or in bug #11720), but now it looks somewhat different. I'll doing additional tests tomorrow.
Created attachment 13068 [details] Backtrace when X crashed after resume and vt-switch New backtrace with current git version of xf86-video-intel 1. Start system w/o X 2. Start X with gdb (ssh) 3. Switch to vt1 and suspend 4. Resume and switch back to vt7 -> crash
Created attachment 13069 [details] intel_reg_dump after startup but before X
Created attachment 13070 [details] intel_reg_dump after startup while X is running
Created attachment 13071 [details] intel_reg_dump after resume but before switching to vt7
Created attachment 13072 [details] intel_reg_dump after resume and switch to vt7 (this means, after crash)
If you require additional info, let me suggest to give you temporary root-access to my system so you can trace this bug by yourself. Please contact me by mail.
Created attachment 13115 [details] Xorg.log of crash after resuming from disk (tuxonice) I just did some tests with tuxonice instead of default suspend. When resuming from disk, the server keeps crashing when entering vt7. But it seems to be slightly different because I was not able to backtrace this crash with gdb. The screen shows garbage but the server still runs and receives SIGUSR1-events (however it does not handle them). Maybe an interesting detail: When suspending to mem via sysfs (using hibernate-tools) after killing a running X-session, the screen is blank after resuming. If I'm not totally wrong even the backlight keeps disabled. But when starting X (using an ssh-connection) the backlight is enabled again and the server crashes the same way it did when suspending to disk. None of this problems occurs when option NoAccel is true in xorg.conf. Is someone working on this? I will help as best as I can, but this bug is really annoying.
I wonder if this might be related to 13196... my latest theory there is that we're not letting the PLLs settle for a long enough period before writing the pipe registers... There's a patch there to test that theory, can you give it a try?
Thanks to Jesse, I was able to find out more information about the problem. To make it short, resuming works fine with classic vesafb, although I'm not sure wether it had worked all the time. Actually, it seems that I experienced different problems, all related to the kernel: The first one (which encouraged me to start experimenting with various versions and kernel settings), resuming from disk with vesafb-tng (kernel 2.6.22), was apparently fixed some times ago and works at least with current git drivers. The second one, resuming from ram with vesafb-tng, still exists but is a kernel problem (the screen stays black and the system completely hangs on resume, independently of starting an X-session). The third and current one (used for the backtraces) occurs with the new uvesafb and kernel 2.6.23, but I think it may be an uvesafb-bug so I'll report it there, too. I stupidly never tested with classic vesafb or without fb-support because I thought the driver is disabled when omitting the video=-line from kernel options, but obviously I was wrong. @Jesse: Thank you for your patience, and sorry for the missleading and imperfect description of the bug. At least I learned how to use git and how to get backtraces with gdb ;-). Please change status if you think that this bug doesn't belong to xorg any longer.
Added the bug to gentoo database: http://bugs.gentoo.org/show_bug.cgi?id=202756
(In reply to comment #19) > > @Jesse: Thank you for your patience, and sorry for the missleading and > imperfect description of the bug. At least I learned how to use git and how to > get backtraces with gdb ;-). Please change status if you think that this bug > doesn't belong to xorg any longer. > Roland, did you have a chance to try the patch in bug# 13196 that Jesse mentioned?
I tried already, it had no effect. At the moment I'm pretty sure that this is an uvesafb-issue because my system resumes perfectly since I'm using classic vesafb. Futhermore there is another user with the same problem at gentoo's bugzilla.
Bugzilla Upgrade Mass Bug Change NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO. - benjsc fd.o Wrangler
(In reply to comment #19) > > I stupidly never tested with classic vesafb or without fb-support because I > thought the driver is disabled when omitting the video=-line from kernel > options, but obviously I was wrong. > Roland, it sounds to me if you remove vesafb kernel driver, just using drm driver, the suspend/resume works fine then?
(In reply to comment #24) > (In reply to comment #19) > > > > I stupidly never tested with classic vesafb or without fb-support because I > > thought the driver is disabled when omitting the video=-line from kernel > > options, but obviously I was wrong. > > > > Roland, it sounds to me if you remove vesafb kernel driver, just using drm > driver, the suspend/resume works fine then? > Withouth uvesafb compiled in kernel, suspend-resume works fine for me.
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #19) > > > > > > I stupidly never tested with classic vesafb or without fb-support because I > > > thought the driver is disabled when omitting the video=-line from kernel > > > options, but obviously I was wrong. > > > > > > > Roland, it sounds to me if you remove vesafb kernel driver, just using drm > > driver, the suspend/resume works fine then? > > > > Withouth uvesafb compiled in kernel, suspend-resume works fine for me. > great. I'm closing this bug then..
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.