FS#14594 - [xf86-video-intel] X.org freezes after a few hours of uptime
Attached to Project:
Arch Linux
Opened by Andrej Podzimek (andrej) - Tuesday, 05 May 2009, 15:41 GMT
Last edited by Jan de Groot (JGC) - Thursday, 21 January 2010, 07:39 GMT
Opened by Andrej Podzimek (andrej) - Tuesday, 05 May 2009, 15:41 GMT
Last edited by Jan de Groot (JGC) - Thursday, 21 January 2010, 07:39 GMT
|
Details
Description:
X.org freezes completely after about 1 to 5 hour(s) of uptime. Magic SysRq can be used to switch the keyboard mode and reboot the machine gracefully. The X-server does not die on SIGTERM, SIGKILL is needed to terminate it. Amazingly, the hardware mouse cursor still works, even when the whole GUI is frozen. Additional info: I use a dual head configuration with one vertical and one horizontal display. xf86-video-intel-legacy works fine, but can't handle KMS. (xf86-video-intel also can't handle KMS in most cases anyway...) * package version(s) xf86-video-intel 2.6.3-4 * config and/or log files etc. Nothing interesting there, no errors, no SIGSEGV... Steps to reproduce: Now that's complicated. ;-) Just wait... |
This task depends upon
Closed by Jan de Groot (JGC)
Thursday, 21 January 2010, 07:39 GMT
Reason for closing: Upstream
Additional comments about closing: Upstream is working on this. Adding extra comments here doesn't make any sense.
Thursday, 21 January 2010, 07:39 GMT
Reason for closing: Upstream
Additional comments about closing: Upstream is working on this. Adding extra comments here doesn't make any sense.
intel-dri 7.4.1-1
xf86-video-intel 2.6.3-4
In my Xorg.0.log I have this error:
(EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
The screen freezes and the only thing is working is the mouse pointer. This happens randomly.
This problem is really annoying. I hope Intel will fix soon this bug. I have several freezes a day, and I have a lot of work to do.
Had to switch to xf86-video-intel-legacy today. :-(
KMS sort of works with a single-head layout, but everything freezes after I switch from X to a console about ten times.
On my dual-head layout, KMS leads to an immediate crash. So the new driver doesn't seem to be stable.
I cannot avoid using this program as I need it at work. This is becoming a serious problem for me.
My machine freezes several times in a couple of hours.
Freezes have same symptoms: mouse cursor works, music keeps playing, I can ssh into the machine and reboot it gracefully. I've found no logs that are meaningful.
Complete freeze; no mouse, no keyboard, no acpid (power button) and even no Magic SysRq.
Freeze most easily reproducible by scrolling a document in Okular full screen mode.
What is worse (or better??), with the new xf86-video-intel 2.7.0-3 I can reproduce the freeze in 100%, when I watch something in VLC and change to Fullscreen. Downgraded to 2.6.3 version.. f*ck those intel drivers, they will never get fixed...
[root@media1 ~]# pacman -Qs intel
local/intel-dri 7.4.1-1
Mesa DRI drivers for Intel chipsets
local/xf86-video-intel 2.7.0-3 (xorg-video-drivers)
X.org Intel i810/i830/i915/945G/G965+ video drivers
[root@media1 ~]#
No xorg.conf, KMS is enabled.
https://bugs.freedesktop.org/show_bug.cgi?id=20893
https://bugs.freedesktop.org/show_bug.cgi?id=21240
https://bugs.freedesktop.org/show_bug.cgi?id=21512
It happens with UXA mostly (thought some people have triggered it also with EXA, but it's rare), you can move the mouse, ssh into the machine, music keeps playing, etc..., but screen is frozen.
For now the best workaround is to use EXA until this is fixed. There are already gpu dumps in those reports, so unless anyone can provide further debugging information I guess we just have to wait until the developers find the problem.
Currently i has no problem. I reinstall my notebook (Archlinux 64-bit) and try my own (custom) kernel 2.6.29.3 without KMS and PAT, rebuild xf86-video-intel-2 and no problem now. I tested also xf86-video-intel-3.
I'm updating the system (64 bit, xf86-video-intel, gnome) every day so the question is why it didn't happen before. Because of the kernel update yesterday? I hadn't restarted the computer in two days.
http://upload.wikimedia.org/wikipedia/commons/b/b7/Singapore_port_panorama.jpg
With EXA no problem, but with UXA it hangs.
Anyway, as I said, the bug is reported upstream and it's being investigated, so we can only wait until they find the problem and fix it.
http://lists.freedesktop.org/archives/intel-gfx/2009-May/002374.html
Otherwise, we have to wait and see if it's backported to 2.6.29.5 (it didn't make it into .4 review process) or else wait for 2.6.30.
Since you got a nice collection of links and comments here already, I'd like to add one:
https://bugs.freedesktop.org/show_bug.cgi?id=20560
I also tried the latest driver and that patch from Eric Anholt (but I suspect it's not doing anything because I don't use KMS).
The freeze after some time is still there:-(
https://bugs.freedesktop.org/show_bug.cgi?id=20152#c32
X freezes occur randomly, both with or without KMS.
Cursor still works but switch to VT does not, neither Magic SysRq.
The very strange thing, I noticed today, is that GUI still update:
freeze happened during Inkscape use, only cursor continued to work,
GUI freezed, but pointer coordinates on statusbar still update!!
I do not know if I'm using KMS... I have a "standard" archlinux conf without any mods...
It seems it happens a lot more frequently with KDE (like 5-10mn after the boot) than with some minimalist WM (awesome)
MPD is still working continue to work after GUI freezed
intel-dri and everything else up-to-date...
xf86-video-intel 2.7.1-1
kernel-headers 2.6.29.3-1
kernel26 2.6.29.4-1
kernel26-firmware 2.6.29-1
Doesn't matter if i'm on exteended desktop mode or single at any uptime. Just now it happened with just 1hr of uptime. Any update on the fix?
I've got a 965GM/X3100 graphics card on an Acer Aspire laptop.
If it helps, my software versions:
xf86-video-intel 2.7.1-1
mesa 7.4.2-1
xorg-server 1.6.1.901-1
kernel26 2.6.29.4-1
intel-dri 7.4.2-1
Happens every now and then, sometimes after a day or two, sometimes two minutes after restart... Usually when an application tries to (re)draw a piece of screen (mplayer tries to show a window with a video, browser redraws a page because I clicked on the "back" button, etc.). I think it is slightly less common since I switched off desktop effects in KDE but it still happens way too often.
My system is up to date, specifically:
xf86-video-intel 2.7.1-1
mesa 7.4.2-1
xorg-server 1.6.1.901-1
kernel26 2.6.29.4-1
intel-dri 7.4.2-1
I have no idea how to enable KMS which makes me believe I don't use it. I also found nothing about UXA in Xorg.0.log, whereas there is a line '(II) LoadModule: "exa"' which I suppose means I use EXA (again, I know nothing about this stuff so I'm not sure). Which also means that for me using EXA isn't a sollution, the problem isn't rare, happens all the time. I'll try to downgrade xf86-video-intel to 2.6.3-4 and see if it'll help.
With kernel26-2.6.30 from testing I can still reproduce the freeze by using UXA acceleration and opening this JPG in Firefox:
http://upload.wikimedia.org/wikipedia/commons/b/b7/Singapore_port_panorama.jpg
Alberto, can you test kernel 2.6.30 without PAT ??
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/snapshot/xf86-video-intel-2.7.99.901.tar.bz2
Changes:
* Several fixes for intermittent GPU hangs/crashes, (some of
which already appeared in the 2.7.1 release)
* Fix to avoid X crash when viewing large images in browser
* Fix X server failure when running old (non-GEM) kernel
* Fixes for SDVO LVDS mode detection
* Fix major performance regression of trapezoid rendering
compared to XAA/EXA
* New support for tear-free video when using KMS
* New support for tear-free DRI2 CopyRegion
we can test :-)
I haven't tested without PAT. Can I do it without recompiling the kernel? But besides, what's the point? Even if the problem goes away without PAT, it's not a solution.
I am working it around by using xf86-video-intel-legacy.
I am now using [testing] and the bug is gone, I was just proposing a workaround which does not need to enable [testing]. By the way, why isn't the [testing] intel driver moved to core? Side-bugs?
With the [testing] xf86-video-intel I can still reproduce the problem, nothing changed for me. I get a frozen Xorg, keyboard absolutely dead, power button not sending any interrupt, only mouse walking around the screen.
I can reproduce the bug by running CPU-intensive programs (like amsn), but the bug is indeed at the Xorg/kernel level by considering the crash impact.
The problem with this bug is that there seems to be various different bugs with similar symptoms. Personally I'm only affected with UXA acceleration, and it's fixed with latest driver. But others have it with EXA too and still not fixed.
kernel26 2.6.30.*
intel-dri 7.4.4-1
xf86-video-intel 2.7.99.901-1
For more than 2 weeks now with no freeze. I used to have freezes every 3rd day on fluxbox and everyday on kde4. From my Xorg log, i can say that i'm using UXA and dri2. Let me know if anyone needs more info about the packages/settings, as i do not know what all is relevant.
Thanks.
The bug seems to be triggered by some random actions like resizing or just by moving a window. Currently running the legacy drivers because of this bug, which of course isn't much of a solution...
I experience the same things as the others here: Screen "freezes" but mouse still works, but the screen doesn't get updated anymore. Sound does still work (music keeps playing through) but any keyboard actions seem to be ignored. I can't switch to other session for example.
I found the following related error message in /var/log/error.log:
[drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1
When searching for the error on google, I found the following thread on the Arch forum: http://bbs.archlinux.org/viewtopic.php?id=68709 it dates from this year's march.
In short they give advise to give the "nopat" and "enable_mtrr_cleanup" as init parameters or to disable the DRI option in xorg.conf. Both solutions didn't help me..
Using:
kernel26 2.6.30.1-1
intel-dri 7.4.4-1
xf86-video-intel 2.7.99.901-1
intel-dri 7.5-2
xf86-video-intel 2.7.99.902-1
xorg-server 1.6.3-2
kernel-headers 2.6.30.1-1
kernel26 2.6.30.4-1
kernel26-firmware 2.6.30-1
Did anyone else find the problem back after upgrade?
Using
xf86-video-intel 2.7.99.902-1
kernel26 2.6.30.4-1
intel-dri 7.5-2
xorg-server 1.6.3-2
kernel26 2.6.30.4-1
intel-dri 7.5-2
xorg-server 1.6.3-2
xf86-video-intel 2.7.99.902-1
Whatever has been changed, it has certainly reduced the frequency of the freezes. Two days now without a freeze (upgraded from legacy drivers two days ago). Then again, I haven't been putting the computer through its paces recently; the freeze appears to be triggered by high activity.
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
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:
(II) UXA(0): Driver registered support for the following operations:
(II) solid
(II) copy
(II) composite (RENDER acceleration)
Can somebody please point out how to get some useful debug info from the crash?
I'm using xf86-video-intel 2.8.1-1, intel-dri 7.5.1-2, xorg-server 1.6.3-2, and mesa 7.5-2.
Audio applications (such as VoIP software) keep on working after a freeze. The freezes occur no matter if I switch to a text terminal or stay on the X.org screen. However, freezes that occur when a text terminal is used result in a 100% CPU usage by the X process. These freezes can be easily „handled“ by killing X. When a freeze occurs on the X.org screen, the keyboard can be unlocked using Magic+R, but the only thing that (re-)starts working is CapsLock. ;-) There is 0% CPU usage from the X server in this case, the mouse cursor moves normally, but everything else is dead. The graphic chipset gets confused somehow, so you can't switch back to a text console. What you can do is either CtrlAltDel to reboot gracefully, or Magic+BUSIER if the former fails...
By the way, what is the Magic key? (the one with the Windows logo, the Fn one?). With BUSIER, do you mean the sequence of these five keys?
xf86-video-intel 2.8.1-1
kernel26 2.6.30.6-1
xorg-server 1.6.3.901-1
KMS on
More than 12 hours uptime, usually daily, MSI wind u100 (intel gma 950).
BTW I don't have any freezes, Intel GMA X3100M with KMS on, laptop can work full day without a glitch.
I am also following the upstream bug
http://bugs.freedesktop.org/show_bug.cgi?id=21826
and I hope a fix will appear there.
http://en.wikipedia.org/wiki/Magic_SysRq_key
The backtrace looks weird. What does the AddScreen function do? I didn't change the screen layout in any way by the time the server crashed. I just opened Firefox and a few tabs of animated GIFs and Flash banners, which is a reliable recipe for disaster with these new Intel drivers. I didn't connect/disconnect anything any screen(s) physically. Not even during the whole uptime before the crash.
Anyway, these events occur no matter if a dual head layout is used or not. If you experience freezes, try to switch *both* KMS and framebuffer off. This doesn't solve the problem, but at least some reasonable information can be obtained from the server logs.
I will use this configuration this week, let's see if the testcase can be reduced to the new Intel driver with framebuffer active
In my case, 'nofb' doesn't change anything. KMS switches the FB on automatically, despite 'nofb'. I have to disable KMS in the kernel config to get rid of the framebuffer.
On my machine, the current situation is as follows:
KMS+FB, new driver: Frequent freezes, some of them get logged, some don't.
KMS+FB, old driver: Terrible flickering of the whole screen, which makes normal work virtually impossible. (Surprisingly, this only applies to the default single-head configuration, dual head layouts work fine.) (And yes, this is a completely different bug that may not have anything in common with this one...)
FB off, new driver: Frequent crashes, rare freezes. Most of them get logged.
FB off, old driver: This is currently the only feasible way to use my laptop. :-D
to disable KMS without recompiling the kernel, use 'nomodeset' parameter. Actually I am always using that, and varying my tests only by the 'nofb' parameter. I have done KMS tests in the past and it seems unusuable on both old driver and old driver, so I confirm your findings.
I don't think anybody will fix the KMS issues with the old driver, but at least I'd like to see KMS+FB working on the new driver.
I am always using a custom .config with the vanilla last stable kernel (2.6.31-2 at the time of writing), but I have found that there is no difference when using the stock kernel (as it should be, since the bug is in the driver).
Also, if you want to get an *instant* crash you can apply the Con Kolivas' BFS scheduler patch (http://ck.kolivas.org/patches/bfs/) to your kernel: the new driver crashes in less than 2 seconds. That's why I say that it must be a race condition of some sort, because the bfs scheduler is known to help finding these bugs.
pacman -U /var/cache/pacman/pkg/xorg-server-1.6.3.901-1-i686.pkg.tar.gz /var/cache/pacman/pkg/xf86-input-evdev-2.2.5-1-i686.pkg.tar.gz
to install the previous versions of xorg-server and xf86-input-evdev, and then also xf86-video-intel-legacy
Since xf86-video-intel-legacy is no more supported what is the future of my hardware? I cannot use xf86-video-intel and the new Xorg because it instantly crashes... :(
please add task relationship
I have tried combinations of nomodeset, nofb, i915.powersave=0 without any success
Merry Xmas :)
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
...and kernel 2.6.32? Some people on the Ubuntu forums said 2.6.32 should eliminate these problems. This ancient laptop is still my main machine used for coding, so I can't just take the risk and give it a try right now. ;-)
I have also tried 2.6.33 without this patch http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=commit;h=7abf3aa8294d95e3f0be375f30e8d933f874ada0 (as reported in http://bugs.freedesktop.org/show_bug.cgi?id=24789) but it is even worse since it crashes after loading the module for the framebuffer console
000cf62 0000 0000 0000 0000 0000 0000 0000 0000
*
000cff2 0000 0000 0000 0000 0000 0000 0000 6c67
000d002 6269 2d63 646c 732e 2e6f 7561 6378 6361
000d012 6568 312d 302e 031e 0000 36cd 0000 1276
000d022 0006 0000 0000 b5c6 4b38 0000 0000 8f98
000d032 0004 0000 0000 0306 0000 0000 0000 0003
000d042 0000 0001 0000 0000 0000 0000 0000 7712
000d052 0005 0000 0000 0e72 4b29 0000 0000 6261
000d062 0000 0000 0000 0306 0000 0000 0000 0003
000d072 0000 0012 0000 0612 0002 0000 0000 2858
000d082 0006 0000 0000 b30a 4a48 0000 0000 bca6
000d092 0001 0000 0000 0306 0000
(WW) xf86CloseConsole: VT_WAITACTIVE failed: Interrupted system call
This sounds like a hopeless situation. The bug makes X.org virtually unusable on lots of machines. :-(
(no external screen)
I'm not a specialist .... sorry, it's not very detailed ...
OK, sounds like all hope is gone. It's time for OpenSolaris.