Created attachment 25244 [details] Xorg.0.log up until X froze, running git driver with ModeDebug enabled I'm running Kubuntu 9.04 with intel drivers alternating from the ones found at the xorg-edgers ppa (https://launchpad.net/~xorg-edgers/+archive/ppa) and pulled manually from git. The system is an old Dell I managed to pick up cheap, with an 865G integrated controller according to lspci. I'm running a 2.6.30-rc3 kernel, but without kernel mode-setting enabled by default. (Not sure it'd work with an old controller like this.) Problem: When I start X - specifically, KDE - it *seldom* gets past the splash screen before locking up. Even if it does get past and draws the desktop, that's the very farthest it will go. I can still move the mouse, but the keyboard doesn't respond when I try to switch to a terminal or when I hit numlock, but I can still REISUB. Unsure of what to set the severity to, though it *does* concern a 100% surefire X lockup upon start of it. * Distribution: Kubuntu 9.04 x86 * Computer make and model: Dell OptiPlex GX270 * Monitor display connection: CRT * "uname -r": 2.6.30-020630rc3-generic (i686, package from http://kernel.ubuntu.com/~kernel-ppa/mainline) * "lspci -v | grep VGA": 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) * xf86-video-intel: git upto commit e55d943126cdd3eac7dfec5f40e794f89dbf038b (xorg-edgers, 2.7.99.1+git20090427.e55d9431-0ubuntu0sarvatt) * libdrm2/libdrm-intel1/... (drm-snapshot): git upto commit 11b60973bca1bc9bbda44be4c695e22d28d8ca4a (xorg-edgers, 2.4.9+git20090427.11b60973-0ubuntu0sarvatt) * xserver-xorg: Ubuntu repository package, 7.4~5ubuntu18 This happens with both UXA and EXA acceleration methods. Nothing particular is output to Xorg.0.log; the last entries are a second (?) batch of modeline poll results. See attachment. As for versioning, see above for git commit spam. With the 2.6.3 repository driver, UXA doesn't work at all (screen just keeps blanking and monitor generally goes bananas) which seems to have since been fixed as the git driver draws the screen properly (before locking). With that repo driver EXA works, though with halting performance. The 2.4 driver from https://launchpad.net/~siretart/+archive/ppa exhibits vastly better rates in Sierpinski3D by a factor of ~4x (peaks of 70 vs 15), but obviously I'm looking to get the driver from git working. Anything else can I do to debug this?
Not yet fixed as of git commit a8a771a853478e5f45f71d0eff3c4d55bf24d0ad.
Adjusting severity: crashes & hangs should be marked critical.
Could you try with kernel commit: commit cfa16a0de5392c54db553ec2233a7110e4b4da7a Author: Eric Anholt <eric@anholt.net> Date: Tue May 26 18:46:16 2009 -0700 drm/i915: Apply a big hammer to 865 GEM object CPU cache flushing. in the for-review branch of my kernel tree, or posted to intel-gfx@lists.freedesktop.org
I compiled a new kernel from git which included that commit, and the behavior persists. I'd like to say that it's "better" though, since now it seems to last a bit longer before locking up. At the time of writing this, I'm happily right-clicking my desktop and getting the context menu pop up. ...Now I opened up konsole and entered a single command, and it locked up. With this kernel I'm running with KMS enabled (which seems to work great), but when it locks up the keyboard doesn't respond, so I cannot switch to a virtual terminal. The tail of Xorg.0.log doesn't contain anything interesting; the last thing it did was list modelines.
To clarify, at the risk of coming through as spamming, this happens both with KMS enabled and with it disabled via the nomodeset bootline option. Also, the "seems better" behavior described is still a rare occurence, though an occurence that *never* happened earlier. Even with this new kernel, most of the time it never gets around to drawing the desktop, instead hanging during the splash animation.
Created attachment 27593 [details] dmesg after trying to restart X
Updating description. With a daily live image of Kubuntu Karmic (11/7) the issue remains. I also tried booting up in single mode (still on the live image), and updated xserver-xorg-core, xserver-xorg-video-intel and mesa packages from xorg-edgers, to no improvement. In preparation, while still in the cli I installed openssh-server and managed to stay connected with my other machine when it locked. From this ssh session I have *full* control of the system, but I still can't recover. dmesg didn't say anything interesting, but I saved a copy of Xorg.0.log and a gpu dump at this point, which I'll attach. I tried stopping kdm, but it wouldn't respond to SIG_TERM (only SIG_KILL), the X process likewise. Trying to restart kdm - and by extension X - spawns both processes but just makes the screen modechange and stop again. At this point I started getting dmesg output I hadn't before; this is when X is trying to restart. It didn't output this when it had just hung, if that is of relevance. (Might've already attached it before this comment, browser malfunction) dmesg: http://pastebin.ubuntu.com/215581 It's easy to reproduce the steps to get here, if you want me to produce output of other commands.
Created attachment 27594 [details] gpu dump
Created attachment 27595 [details] lspci -vn output
Created attachment 27596 [details] Xorg.0.log up until it froze
Created attachment 27597 [details] Xorg.0.log when trying to restart it
Could you test with this change in the 2D driver? commit a1e6abb5ca89d699144d10fdc4309b3b78f2f7a9 Author: Eric Anholt <eric@anholt.net> Date: Wed Jul 15 14:15:10 2009 -0700 Use batch_start_atomic to fix batchbuffer wrapping problems with 8xx render. Bug #22483.
(In reply to comment #12) > Could you test with this change in the 2D driver? Did not seem to help, using the 2.8.0 + commit 6f3fc6b2 package from xorg-edgers, tried on both a live usb of Jaunty and one of a Karmic daily. The desktop tries to load but everything inevitably locks.
Thanks for checking. There appear to still be some serious 865 issues as I've found since that last commit, and unfortunately the solution at the moment would be to just disable Render acceleration.
Render acceleration is disabled on i8xx in Debian unstable but I still get hangs soon after X startup on my i865. Debian's patch disabling render accel is: http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-intel.git;a=blob;f=debian/patches/disable-uxa-render-accel-on-i8xx.patch;h=6cb74f2fe3ce7c102e4bbb7118f3dd8fd16e2c1d;hb=7044a130ba4225295c890f3d65763dc21cff5846 It makes the last line below disappear: (II) UXA(0): Driver registered support for the following operations: (II) solid (II) copy (II) composite (RENDER acceleration)
I am seeing this same issue under Gentoo. The kernel version is 2.6.30-r4, xorg is 7.4, xorg server is 1.6.3 and the intel video driver is 2.8.0. I am using WindowMaker and the session stays active for quite some time before a hang. If I just open an xterm or if I let the system stay idle, I haven't seen a hang. But if I open firefox and start browsing or if I move windows around rapidly, the hang comes very soon after that. Again, mouse cursor can be moved around the screen, but clicking on visual elements doesn't take effect. I will attach the relevant system information and logs...
Created attachment 28466 [details] kernel boot log
Created attachment 28467 [details] xorg log file
Created attachment 28468 [details] xorg configuration file
Created attachment 28469 [details] lspci output
Created attachment 28470 [details] cat /proc/cpuinfo output
I have done a few more tests on this: Currently, my system has kernel 2.6.30-gentoo-r4 and intel video 2.8.0 and the problem can be duplicated easily. I have tried downgrading the video driver to 2.7.1 and the problem persisted. The I have tried downgrading the kernel to 2.6.30-gentoo-r1 (I kept the video driver at 2.7.1) and the problem didn't happen anymore. The I have tried upgrading the video driver back to 2.8.0 (while keeping the kernel at 2.6.30-gentoo-r1) and the problem came back. So, in order for the problem to go away, both the linux kernel and the video driver must be downgraded. According to my observations, linux kernel 2.6.30-gentoo-r1 and intel video 2.7.1 seem to be working. I had initially reported this bug on the gentoo bugzilla: http://bugs.gentoo.org/show_bug.cgi?id=280661 I have inquired there about the differences between the two kernel versions
If it will help, I can provide the source code for both intel video 2.7.1 and 2.8.0. I also have the sources for both kernel versions, so I can provide the necessary files from that source tree if needed. I can also provide the diffs...
After using the system for almost 3 hours, using kernel 2.6.30-r1 and intel video driver 2.7.1, the hang happened again. This time I have tried to connect to the system using secure shell and I succeeded. Then I have tried killing the X server using killall. That didn't take effect. Then I killed the server using kill -9 and that worked. But even though I remain connected to the system through ssh, on the system I am not seeing the command prompt. switching terminals doesn't work either. The screen is mostly black with an array of tiny periodic red dots.
tried downgrading xorg-server from 1.6.3 to 1.5.3. This also required a recompilation of the keyboard and mouse driver and the intel video driver (ABI change). Hang is still happening :( Any idea what else I can try? I thought about downgrading the MESA library, but is that used when I do regular browsing using firefox. My understanding is that mesa is only used with games and such (3D) and not for 2D...
Prevented windowmaker from running so that twm will be used as the window manager. Hang still happens, using firefox. I am out of idias to try at the moment. The problem started happening after a large system update which covered some 96 packages. Hope anybody can provide some ideas for debugging, otherwise I will just do a complete reinstall...
Another test: I have disabled DRI in xorg.conf and now firefox is working for almost a half hour with no problems. Of course, it is very sluggish, but no hang so far...
I would like to mention that the only working configuration for me on debian is: linux-image-2.6.26 xserver-xorg-video-intel 2:2.7.1-1 No matter what version of xserver, xorg or mesa is installed. I've tried 2.6.29 and some 2.6.30 rcs and intel drivers 2:2.7.99.901. More info in my comment here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527349#27 Michal Pokrywka
I have restored my original configuration, which was: xorg-server 1.6.3 intel video 2.8.0 kernel 2.6.30-r4 xf86-input-keyboard 1.3.2 xf86-input-mouse 1.4.0 With this configuration, if I do startx and run firefox, the hang happens quickly. I have tried using the "NoAccel" option, but the driver apparently doesn't support this option (based on a messages in the Xorg.log). Then I have tried setting "DRI" to "no", and the hang still happened. Note that in a previous test, disabling "DRI" prevented the problem. In that test, the xorg-server was 1.5.3 and the intel driver was 2.7.1. But with the latest versions, even setting "DRI" to "no" doesn't prevent the problem. Finally, I have compiled the vesa driver (version 2.2.1). I am using this driver now and after a half hour, there are no hangs...
(In reply to comment #28) > No matter what version of xserver, xorg or mesa is installed. > I've tried 2.6.29 and some 2.6.30 rcs and intel drivers 2:2.7.99.901. I am currently using mesa 7.5. I wonder if I start windowmaker and run firefox, will the mesa libraries be used?
I have been using the system for 5 hours now with no crash. The only difference between the crashing configuration and the not crashing configuration is using the vesa video driver vs the intel video driver, which is evidence that the problem is related to the video driver. My home computer is also running gentoo with the following versions: * Searching for xorg-server ... IP-] [ ~] x11-base/xorg-server-1.6.2-r1 (0) * Searching for xf86-input-keyboard ... IP-] [ ] x11-drivers/xf86-input-keyboard-1.3.2 (0) * Searching for xf86-input-mouse ... IP-] [ ] x11-drivers/xf86-input-mouse-1.4.0 (0) * Searching for gentoo-sources ... IP-] [ ~] sys-kernel/gentoo-sources-2.6.30-r1 (2.6.30-r1) * Searching for mesa ... IP-] [ ~] media-libs/mesa-7.4.4 (0) * Searching for xf86-video-radeonhd ... IP-] [ ~] x11-drivers/xf86-video-radeonhd-1.2.5 (0) This system is running stable for a long time. The only difference between my home system and the work system is the xorg-server version (1.6.3 vs 1.6.2), the mesa version (7.5 ve 7.4.4) and the video driver (radeonhd vs intel). I haven't tried xorg-server 1.6.2 and mesa 7.4.4 at work, but my gut feeling is that it won't make a difference and that the significant change here is the video driver. But if anybody thinks the changes between the mesa and xorg-server versions are significant, I can try that, too.
(In reply to comment #30) > (...). I wonder if I start windowmaker and run firefox, > will the mesa libraries be used? I'm not sure, I think You should run some glxgears or similar program to be certain. Anyway, some MORE INFO now :) I was suggested to run memtest86+ on my box where problem occurs, with option Configuration -> Memory Sizeing -> Bios-ALL, and it locks up when 61% complete. I was also informed that inserting external graphic adapter doesn't help, so it seems there is a problem with whole motherboard. If anyone can do such tests with memtest86+ and external graphic card it could be helpful - I think.
Eric Anholt posted a kernel patch that fixes several hangs for pre-9xx chipsets: http://lists.freedesktop.org/archives/intel-gfx/2009-September/004122.html Could you try if it works?
(In reply to comment #33) > Eric Anholt posted a kernel patch that fixes several hangs for > pre-9xx chipsets: > > http://lists.freedesktop.org/archives/intel-gfx/2009-September/004122.html > > Could you try if it works? > Unfortunately, I've got rid of my mainboard, but I will try as soon as I can.
I am not the original reporter, but Eric's patch works great for me on an 865.
Feedback timout -- JR, if you find the problem still exists, please re-open the bug report and clear NEEDINFO.
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.