Created attachment 26022 [details] from instructions at the given url kernel: both 2.6.28-11 and 2.6.30-020630rc5 distribution: Ubuntu 9.04 xserver-xorg version: 1:7.4~5ubuntu1 xserver-xorg-video-intel version: 2:2.6.3-0ubuntu9 graphics device: Intel 82852/855GM integrated My screen randomly freezes a few times a day with only the mouse moving. The keyboard reacts to nothing. ssh-ing in is still possible. This has been happening since I upgraded to jaunty (Ubuntu 9.04) from intrepid (8.10) a few weeks ago. I cannot think of any similarities between the situations in which it happens, except I think it always happened during mouse movement. I followed those instructions: https://launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test
The dowstream bug report is at https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/378147 [lspci] 00:00.0 Host bridge [0600]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3580] (rev 02) Subsystem: Wistron Corp. Device [17c0:4011] 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) Subsystem: Wistron Corp. Device [17c0:205b]
Created attachment 26033 [details] xorg.conf from dowstream bug report Minimal. Note that Ubuntu is currently using EXA by default.
When booting with the vga=normal option, I have had no freeze yet.
I think I was misleaded, vga=normal does not eliminate the freezes, at least not when using the 2.6.30 kernel.
How about if you use UXA? Note the upstream driver has removed EXA.
I'm still getting freezes with UXA, will try without DRI now. By the way, the intel driver overall seems to be buggy. With UXA enabled, googleearth moved from near-unusable to unusable, and glxgears also became all messed up.
Could you provide gpu dump according to http://intellinuxgraphics.org/intel-gpu-dump.html?
The gpu dump is included in the initial attachment (id=26022). Do you want a new dump after a freeze with UXA?
Yes, to see what’s included in the archive, follow the link given in comment #0. I can produce new dumps in other environments, of course, if you wish.
This commit may help with intermittent freeze issues with UXA: 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. Can you reproduce the problem with master of the 2D driver and post a new dump?
Sorry, I have not been able to compile the package yet. I have gotten past some undefined references, but now I am missing references to xf86I2CReadByte, xf86I2CWriteByte, xf86I2CDevInit, xf86DrvMsg and Xcalloc, which I cannot find anywhere. Can anyone help?
> --- Comment #11 from Hendrik Lönngren <wikibugs@gmail.com> 2009-07-31 10:18:24 PST --- > Sorry, I have not been able to compile the package yet. I have gotten past some > undefined references, but now I am missing references to xf86I2CReadByte, > xf86I2CWriteByte, xf86I2CDevInit, xf86DrvMsg and Xcalloc, which I cannot find > anywhere. Can anyone help? did you run 'sudo apt-get build-dep xserver-xorg-video-intel' before building? if you still can't build the driver please attach the build log to this bug so we know more precisely what the issue is.
Created attachment 28243 [details] config.log
Created attachment 28244 [details] dpkg-buildpackage output Yes, I did install the build-deps. dpkg-buildpackage does not seem to create a build log, so I am attaching the output as seen on the console.
Ah, now I was able to build the package. Something has changed since a week ago when I first tried. With the most recent version I got much further, this time there were only two compiler problems that google could solve easily (http://www.phoronix.com/forums/showpost.php?p=69325&postcount=139). Will be back when I have tested the package.
I still have a question ... How can I make sure that the new driver is actually used? Because, the newly created package for xf86-video-intel is installed to /usr/local, while the original xserver-xorg-video-intel still resides in /usr, so nothing is overridden.
> --- Comment #16 from Hendrik Lönngren <wikibugs@gmail.com> 2009-08-02 12:00:35 PST --- > I still have a question ... How can I make sure that the new driver is actually > used? Because, the newly created package for xf86-video-intel is installed to > /usr/local, while the original xserver-xorg-video-intel still resides in /usr, > so nothing is overridden. a few ways to do that: - add /usr/local/... to ModulePath in xorg.conf - configure the driver with --prefix=/usr - instead of 'make install', run 'cp --remove-destination src/.libs/intel_drv.so /usr/lib/xorg/modules/drivers/' Cheers, Julien
Created attachment 28314 [details] dri_debug.tgz Thanks, now the driver is running. It seemed stable for an unusually long period, but just now, I’ve had another freeze. This is the new dump.
Just reporting that Eric’s commit definitely has fixed something, freezes have become much less frequent, so I am able to use DRI again. Big thanks! They still occur about once a week, though.
I have the same problem, as reported downstream: http://bugs.archlinux.org/task/14594 These are relevant packages: xf86-video-intel-2.8.1-1 intel-dri 7.5.1-2 xorg-server 1.6.3.901-1 mesa 7.5.1-2 libdrm 2.4.13-1 and I am using the kernel.org vanilla kernel 2.6.31-rc9 (I have verified that the behaviour is exactly the same with the stock archlinux kernel). I can always get a freeze, it can take minutes up to 1 hour, crash happens also if I am not at the computer (I have often found it hanged up). When using xf86-video-intel-legacy EXA is always selected, instead when I use the new driver I get UXA (which is my choice in xorg.conf): (II) UXA(0): Driver registered support for the following operations: (II) solid (II) copy (II) composite (RENDER acceleration) I think I am affected by this bug (which is duplicated many times in this bugtracker, in my opinion), if I can be of some help at fixing this problem I offer my help. @Hendrik: situation didn't change for me with most recent driver updates
I have just enabled KMS, I will see if something changes. So far it seems not crashing.
Created attachment 29382 [details] full dmesg of crash I retrieved this dmesg by connecting through ssh, since the whole Xorg sub-system is unresponsive (only mouse moves around). I confirm that with or without KMS the bug always happens.
Hendrik, can you retest with the drm-intel-next kernel, containing the following patch? commit e517a5e97080bbe52857bd0d7df9b66602d53c4d Author: Eric Anholt <eric@anholt.net> Date: Thu Sep 10 17:48:48 2009 -0700 agp/intel: Fix the pre-9xx chipset flush.
Hi Eric, sorry for joining the party without invitation, but I really fear being left behind with an unusable i855GM (or with an old unmantained driver). I am a good wrench at programming, but not yet so good with git, I have applied your patch (supposedly http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commitdiff_plain;h=e517a5e97080bbe52857bd0d7df9b66602d53c4d) to my git tree pulld from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Patch applied successfully but there were minor offsets, nothing to worry about I guess. Right now I am compiling the kernel, are you interested in my tests as well? I remember you that I have an i855GM, that should be even older than i865
Hi Eric, just in case you want to know about my findings: I am using stock xf86-video-intel driver 2.8.1-1 (provided by Arch Linux) and the kernel patched as in my previous post things have really changed: I get a crash from within 5-10 seconds from starting X. I don't know if this is better or worse, maybe now we can better find the bug?
I confirm that, using the kernel from drm-intel-next, with or without DRI enabled, the said problem occurs reproduceably very quickly after login, that is before the desktop has even fully built up. With my previous setup, I have noticed that the freezes have started to happen increasingly often again, most notably even with DRI disabled, which I had not experienced before. I am unable to tell what caused this, possibly just different occupations, or some software update.
I'd like to add that undoing the commit mentioned above (e517a5e97080bbe52857bd0d7df9b66602d53c4d, agp/intel: Fix the pre-9xx chipset flush) on recent kernels seems to ``fix'' X freezing after a few seconds as mentioned here and in a few other bugs (#24789, #22771). After that, I'm back again to X freezing randomly every few hours. I reckon the commit above was tested on a i865 chipset, so maybe something else is still missing for i855.
Hi, I've a laptop Asus A3n with an Intel 855GM. The problem of freeze affects me too with the last Linux distributions (Ubuntu 9.10, Fedora RC, OpenSuse RC2). I can enter my user and password, and xorg freeze during the first second of use, only mouse move. Sometimes, it freezes even before the desktop finish to start. If I can help to solve this problem; I can't help to program, but I'm ok to make test, send log files, etc.. Best regards, Stéphane
http://bugs.archlinux.org/task/14594?project=1&opened=3107 Hello, this thread contains details about a similar (or identical) problem. The problem persists up to now. Versions and other links are also mentioned there.
Created attachment 31946 [details] tarball from instructions in Comment#0 I have been experiencing the freezes for the last couple of months on the Mandriva 2009.1 (Spring) backport described in the downstream bug https://qa.mandriva.com/show_bug.cgi?id=52601 Colin Guthrie asked me to create a upstream bug, but since I found the exact existing one I won't duplicate. I followed the instructions at the link in Comment #0 while the machine was in the freeze state and am uploading an attachement. The particulars on my Thinkpad G40 are: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 01) kernel-desktop586-2.6.31.6-1mnb-1-1mnb2 (module i915 is loaded) libdrm2-2.4.14-2mdv2010.0 mesa-7.5.2-2mdv2010.0 x11-driver-video-intel-2.9.1-1mdv2010.0 x11-server-xorg-1.6.5-1mdv2010.0 I rarely get the freeze other than when running Google Earth. With GE, I can always get it to freeze quickly by causing a few text dialogs to popup (Panoramio and Wikipedia links).
Same thing happens to me. I have already submitted a bug with Fedora crew but it happens even with a Live version of Ubuntu... so it's definitely the driver i915 driver. I had no problems with Fedora 11 (except for Compiz stuff, but i never used flashy graphics anyways). 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) I can remotely login and gracefully reboot the machine, but I lose all unsaved work on the desktop. Hopefully I can fill this out before it breaks randomly again. Sometimes right after a reboot, sometimes hours, or days later. MOst times when I am scrolling or clicking on another window. The following message gets repeated several times: Dec 7 16:50:04 pcsg788 kernel: INFO: task i915/0:98 blocked for more than 120 seconds. Dec 7 16:50:04 pcsg788 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Dec 7 16:50:04 pcsg788 kernel: i915/0 D f654b598 0 98 2 0x00000000 Dec 7 16:50:04 pcsg788 kernel: f6587f14 00000046 fecef945 f654b598 c09ef6ec c09f4120 f654b598 f6587edc Dec 7 16:50:04 pcsg788 kernel: c09f4120 c09f4120 c257e160 f6587ef4 f6587eec 00000000 f75c9d7e 0000fad4 Dec 7 16:50:04 pcsg788 kernel: c257e120 f654b300 00000000 f6587f18 c0430c73 00000000 f64f9c14 f654b300 Dec 7 16:50:04 pcsg788 kernel: Call Trace: Dec 7 16:50:04 pcsg788 kernel: [<c0430c73>] ? finish_task_switch+0x53/0xbf Dec 7 16:50:04 pcsg788 kernel: [<c07655f8>] __mutex_lock_common+0xde/0x12d Dec 7 16:50:04 pcsg788 kernel: [<c076565e>] __mutex_lock_slowpath+0x17/0x1a Dec 7 16:50:04 pcsg788 kernel: [<c0765747>] ? mutex_lock+0x2e/0x3c Dec 7 16:50:04 pcsg788 kernel: [<c0765747>] mutex_lock+0x2e/0x3c Dec 7 16:50:04 pcsg788 kernel: [<f7dccc35>] i915_gem_retire_work_handler+0x29/0x66 [i915] Dec 7 16:50:04 pcsg788 kernel: [<c0446238>] worker_thread+0x13c/0x1bc Dec 7 16:50:04 pcsg788 kernel: [<f7dccc0c>] ? i915_gem_retire_work_handler+0x0/0x66 [i915] Dec 7 16:50:04 pcsg788 kernel: [<c0449be1>] ? autoremove_wake_function+0x0/0x34 Dec 7 16:50:04 pcsg788 kernel: [<c04460fc>] ? worker_thread+0x0/0x1bc Dec 7 16:50:04 pcsg788 kernel: [<c0449937>] kthread+0x70/0x75 Dec 7 16:50:04 pcsg788 kernel: [<c04498c7>] ? kthread+0x0/0x75 Dec 7 16:50:04 pcsg788 kernel: [<c04041a7>] kernel_thread_helper+0x7/0x10 Dec 7 16:52:04 pcsg788 kernel: INFO: task i915/0:98 blocked for more than 120 seconds. Dec 7 16:52:04 pcsg788 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Dec 7 16:52:04 pcsg788 kernel: i915/0 D f654b598 0 98 2 0x00000000 Dec 7 16:52:04 pcsg788 kernel: f6587f14 00000046 fecef945 f654b598 c09ef6ec c09f4120 f654b598 f6587edc Dec 7 16:52:04 pcsg788 kernel: c09f4120 c09f4120 c257e160 f6587ef4 f6587eec 00000000 f75c9d7e 0000fad4 Dec 7 16:52:04 pcsg788 kernel: c257e120 f654b300 00000000 f6587f18 c0430c73 00000000 f64f9c14 f654b300 Dec 7 16:52:04 pcsg788 kernel: Call Trace: Dec 7 16:52:04 pcsg788 kernel: [<c0430c73>] ? finish_task_switch+0x53/0xbf Dec 7 16:52:04 pcsg788 kernel: [<c07655f8>] __mutex_lock_common+0xde/0x12d Dec 7 16:52:04 pcsg788 kernel: [<c076565e>] __mutex_lock_slowpath+0x17/0x1a Dec 7 16:52:04 pcsg788 kernel: [<c0765747>] ? mutex_lock+0x2e/0x3c Dec 7 16:52:04 pcsg788 kernel: [<c0765747>] mutex_lock+0x2e/0x3c Dec 7 16:52:04 pcsg788 kernel: [<f7dccc35>] i915_gem_retire_work_handler+0x29/0x66 [i915] Dec 7 16:52:04 pcsg788 kernel: [<c0446238>] worker_thread+0x13c/0x1bc Dec 7 16:52:04 pcsg788 kernel: [<f7dccc0c>] ? i915_gem_retire_work_handler+0x0/0x66 [i915] Dec 7 16:52:04 pcsg788 kernel: [<c0449be1>] ? autoremove_wake_function+0x0/0x34 Dec 7 16:52:04 pcsg788 kernel: [<c04460fc>] ? worker_thread+0x0/0x1bc Dec 7 16:52:04 pcsg788 kernel: [<c0449937>] kthread+0x70/0x75 Dec 7 16:52:04 pcsg788 kernel: [<c04498c7>] ? kthread+0x0/0x75 Dec 7 16:52:04 pcsg788 kernel: [<c04041a7>] kernel_thread_helper+0x7/0x10
I awakened to a locked-up machine this morning at 8AM. Logging into it I saw it had the "120 second" message in /var/log/messages beginning from 06:02. The call trace on my machine is slightly different from Elmo's: INFO: task i915/0:34 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. i915/0 D feceded3 0 34 2 0x00000000 f6401f18 00000046 fff1255b feceded3 ffffffff c040dde0 f6f631c0 c17fd420 f6f631c0 ca0831c0 f21c0000 f6f63440 3c8d03c5 00003690 c0644864 c0649420 f6f63440 00000000 00003690 d6691600 f6f631c0 f6401f6c c03fe818 00000282 Call Trace: [<c03fe818>] ? schedule+0x418/0xa00 [<c03ff956>] __mutex_lock_slowpath+0xc6/0x130 [<c03ff875>] mutex_lock+0x25/0x40 [<f7f8593f>] i915_gem_retire_work_handler+0x2f/0x80 [i915] [<c0153c1d>] worker_thread+0x10d/0x210 [<f7f85910>] ? i915_gem_retire_work_handler+0x0/0x80 [i915] [<c0158580>] ? autoremove_wake_function+0x0/0x50 [<c0153b10>] ? worker_thread+0x0/0x210 [<c015825c>] kthread+0x7c/0x90 [<c01581e0>] ? kthread+0x0/0x90 [<c0104ae7>] kernel_thread_helper+0x7/0x10 Is there anything I can do to gather more data for the experts? Although I'm an IT professional, I'm not into compiling, etc.; I just install the latest bits from Mandriva. But I'm tired of these X lockups. (If some "expert" is in the Boston, MA area, maybe my machine could pay a visit...)
Created attachment 32156 [details] Intel GPU Dumpfile This is the intel-gpu-dump output from when my 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) keeps hanging.
Created attachment 32351 [details] intel gpu dumpfile 2 Wow, this bug is getting to be too much. I haven't spent much time on my desktop because I cannot reliably tell when it's going to hang up on me. Even in adding the latest dump file to this bug, it crashed on me.
Created attachment 32352 [details] intel_gpu_dumpfile #3
Created attachment 32353 [details] intel_gpu_dump #4
It is still hitting my system as well, though I haven't captured additional dumps. I'd hate to have to copy my Thunderbird email files to the NTFS partition and run (blech!) Windoze to have continuity. :-( Again, if an "expert" is in the Boston area, perhaps my laptop could pay a visit. I even have a spare hard drive, so said "expert" could install whatever needed to debug.
It seems that I forgot to mention this earlier, but it might be relevant to people suffering from this bug: Driver version 2.6.3 together with X.Org 7.4 is safe for me when DRI is disabled. Also, when DRI is enabled and a freeze occurs, SysRq remains functional so you can gracefully reboot.
Created attachment 33250 [details] Debug output (dmesg/debugfs/gpu_dump etc) Adding myself to the list of people affected by the GPU hanging randomly after a while. Chipset: 855GM Kernel: 2.6.33-rc7/x86 (from drm-intel repository, last commit is 0f318cd689ef0758e... drm/i915: provide self-refresh status in debugfs) intel-driver: 2.10.0 libdrm: 2.4.17 Mesa: 7.7 Xorg-server: 1.7.4.901 I reverted commit e517a5e97080bbe... agp/intel: Fix the pre-9xx chipset flush, as this in itself did not seem to trigger a GPU error (no error recorded in /sys/kernel/debug/dri/0/i915_error_state, i915_add_request still going on merrily in dmesg), only a disply freeze. Possibly related to the flush as executed in the above commit not working as intented on a 855 chipset. Hopefully one of the captured files actually contains something useful for the devs to work with.
Forward duping because the later bug has a simple test case. *** This bug has been marked as a duplicate of bug 26345 ***
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.