Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#14594 - [xf86-video-intel] 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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Architecture i686
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 23
Private No


Description: 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.
Comment by Alois Nespor (anespor) - Tuesday, 05 May 2009, 20:28 GMT
confirm, same problem, driver xf86-video-intel 2.7.0-2, no KMS
Comment by Arael (ArchArael) - Wednesday, 06 May 2009, 15:26 GMT
I have the same problem:

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.
Comment by Andrej Podzimek (andrej) - Wednesday, 06 May 2009, 16:09 GMT
I don't have anything like that in Xorg.0.log when the screens freeze.
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.
Comment by Arael (ArchArael) - Thursday, 07 May 2009, 15:32 GMT
By the way...I noticed that the freezing is more frequent while using Macromedia Flash 8 / Wine.

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.
Comment by Alberto Gonzalez (Luis) - Saturday, 09 May 2009, 19:47 GMT
I also have these random freezes, but only if I enable KMS. If I stay with EXA it never happens.

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.
Comment by Adrian C. (anrxc) - Saturday, 09 May 2009, 21:40 GMT
I use same packages as the OP - using UXA with no KMS on GM965/X3100.
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.
Comment by Not Important (pholie) - Monday, 11 May 2009, 18:47 GMT
I have the same symptomps as the original reporter. I get random freezes with xf86-video-intel 2.6.3-4. Only mouse can be moved, GUI is frozen. I have 965 graphics and use UXA. I also use 2nd monitor (notebook with LCD connected, set to clone display).

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...
Comment by David Orman (ormandj) - Tuesday, 12 May 2009, 14:50 GMT
I experience the same as pholie, with the new drivers, switching to full screen video in vlc/mplayer/etc causes a complete freeze of X. I can ssh in and reboot the machine cleanly, but this is quite irritating as it's my HTPC. Intel 2.7.0-3, KMS is enabled, GM45/X4500HD. 2.6 didn't freeze on me, I just had poor performance/lots of tearing. The freeze occurs every time video is made full screen, not randomly.

[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) Intel i810/i830/i915/945G/G965+ video drivers
[root@media1 ~]#

No xorg.conf, KMS is enabled.
Comment by Alberto Gonzalez (Luis) - Tuesday, 12 May 2009, 16:14 GMT
The bug is reported several times upstream, for example:

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.
Comment by Alois Nespor (anespor) - Tuesday, 12 May 2009, 16:34 GMT

Currently i has no problem. I reinstall my notebook (Archlinux 64-bit) and try my own (custom) kernel without KMS and PAT, rebuild xf86-video-intel-2 and no problem now. I tested also xf86-video-intel-3.
Comment by Dominik (cpcgm) - Tuesday, 12 May 2009, 19:13 GMT
Problem started today. All together six crashes. It's impossible to work productively.

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.
Comment by Adrian C. (anrxc) - Wednesday, 13 May 2009, 13:17 GMT
They claim it's fixed in 2.7.1 So far, with UXA and NO KMS I can't reproduce a freeze.
Comment by Alberto Gonzalez (Luis) - Thursday, 14 May 2009, 22:28 GMT
I've tried driver 2.7.1 but could still reproduce the bug by trying to open in Firefox the following image:

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.
Comment by Alberto Gonzalez (Luis) - Friday, 15 May 2009, 21:44 GMT
Today Eric Anholt pushed a fix into the kernel for this issue (or at least a very similar one). If anyone here compiles his own kernel and wants to try it, here's the patch (might not apply cleanly to 2.6.29, but it's a very simple patch so it should be hard to apply manually in any case):

Otherwise, we have to wait and see if it's backported to (it didn't make it into .4 review process) or else wait for 2.6.30.
Comment by Thomas Orgis (sobukus) - Tuesday, 19 May 2009, 11:17 GMT
I'm not using Arch Linux, but I have the same issue with quite vanilla upstream stuff (Source Mage).
Since you got a nice collection of links and comments here already, I'd like to add one:

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:-(
Comment by Frank Phillips (fphillips) - Wednesday, 20 May 2009, 04:45 GMT
New patches for the jpeg issue, at least:
Comment by Matteo Drera (seven.issimo) - Thursday, 21 May 2009, 09:26 GMT
I've got similar problem, before and now (xf86-video-intel 2.7.1-1):
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!!
Comment by Steven Q. (eskiou) - Saturday, 23 May 2009, 07:15 GMT
First time this bug occurs for me was when I installed xf86-video-intel 2.7.1-1.
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
Comment by Steven Q. (eskiou) - Saturday, 23 May 2009, 17:22 GMT
Bug doesn't occur with kernel26 and xf86-video-intel 2.6.3-4
intel-dri and everything else up-to-date...
Comment by Vikas Kumar (kvikas) - Thursday, 04 June 2009, 07:15 GMT
It is happening very randomly with me with all latest packages;
xf86-video-intel 2.7.1-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?
Comment by Lagaro (Lagaro) - Thursday, 04 June 2009, 21:35 GMT
Same situation as Steven Q. When using the awesome window manager, crashes once every four days or so. Using KDE, every two or three hours.

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
intel-dri 7.4.2-1
Comment by kkl2401 (kkl2401) - Wednesday, 10 June 2009, 20:17 GMT
I can confirm these random freezes as well. Nothing in Xorg.0.log, nothing in everything.log. Mouse can be moved but that's all, keyboard doesn't work, luckily power button can be pressed and the computer at least cleanly shuts down.
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
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.
Comment by Alois Nespor (anespor) - Thursday, 11 June 2009, 06:24 GMT
with kernel 2.6.30 (without PAT) works intel-driver fine, without freeze.
Comment by Jan de Groot (JGC) - Thursday, 11 June 2009, 22:48 GMT
Is this confirmed fixed with 2.6.30 from testing?
Comment by Alberto Gonzalez (Luis) - Thursday, 11 June 2009, 23:10 GMT
No, it's not fixed with just kernel 2.6.30. It also needs a newer libdrm and xf86-video-intel.

With kernel26-2.6.30 from testing I can still reproduce the freeze by using UXA acceleration and opening this JPG in Firefox:
Comment by Alois Nespor (anespor) - Friday, 12 June 2009, 06:30 GMT
kernel26 2.6.30 from [testing] has enabled PAT, i tested without PAT, because PAT broken suspend (pm-utils) on my laptop and make X server unstable.
Alberto, can you test kernel 2.6.30 without PAT ??
Comment by Jan de Groot (JGC) - Friday, 12 June 2009, 06:49 GMT
The latest libdrm in extra has been patched to fix that bug.
Comment by Alois Nespor (anespor) - Friday, 12 June 2009, 09:16 GMT
new driver 2.8.0rc1

* 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 :-)
Comment by Alberto Gonzalez (Luis) - Friday, 12 June 2009, 12:49 GMT
With xf86-video-intel- and kernel26-2.6.30 (and libdrm from extra), I can't reproduce the problem anymore. So it seems (as expected) that once xf86-video-intel-2.8 is released (or if they backport the fix to 2.7.2) the bug will be solved.

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.
Comment by Daniele C. (legolas558) - Monday, 29 June 2009, 22:40 GMT
I am experiencing the same bug, sytem frozen but mouse moving.

I am working it around by using xf86-video-intel-legacy.
Comment by Alberto Gonzalez (Luis) - Tuesday, 30 June 2009, 03:04 GMT
Daniele, do you have [testing] enabled? With packages from core/extra this bug is confirmed. What's interesting to know now is if anyone encounters it with packages from testing. Using xf86-video-intel from testing does solve it for me, so it would be helpful if anyone can confirm/deny this.
Comment by Daniele C. (legolas558) - Tuesday, 30 June 2009, 05:43 GMT
Hi Alberto,

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?
Comment by Daniele C. (legolas558) - Tuesday, 30 June 2009, 05:52 GMT
Sorry, I talked too early.

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.
Comment by Alberto Gonzalez (Luis) - Tuesday, 30 June 2009, 06:25 GMT
That's bad news, so the bug is still around with latest Intel driver (it's still beta, that's why is not in [core], I guess).

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.
Comment by Daniele C. (legolas558) - Tuesday, 30 June 2009, 09:11 GMT
For me always happens with EXA as UXA is never starting, I suppose UXA does not support my chipset (855GM)
Comment by Vikas Kumar (kvikas) - Tuesday, 14 July 2009, 19:06 GMT
kernel26 2.6.30.*
intel-dri 7.4.4-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.

Comment by Thajan Wals (thajan) - Friday, 17 July 2009, 14:02 GMT
I confirm this bug.

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: 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..

intel-dri 7.4.4-1
Comment by Vikas Kumar (kvikas) - Wednesday, 05 August 2009, 09:52 GMT
I's all happy for last 20 days till it came again today (not once but twice). The recent upgrade upgraded xorg-server, xf86-video-intel, intel-dri. This is my current list of packets:

intel-dri 7.5-2
xorg-server 1.6.3-2

kernel26-firmware 2.6.30-1

Did anyone else find the problem back after upgrade?
Comment by kang (kang) - Thursday, 06 August 2009, 01:01 GMT
Unfortunately I still experience the freeze. As everyone pointed out, its during resizes, etc. If i dont use the computer its not freezing. Might be also with video or something I don't know.
intel-dri 7.5-2
xorg-server 1.6.3-2
Comment by Lagaro (Lagaro) - Thursday, 06 August 2009, 15:11 GMT
I cannot confirm that the bug is fixed for me with the following packages:
intel-dri 7.5-2
xorg-server 1.6.3-2

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.
Comment by Daniele C. (legolas558) - Thursday, 10 September 2009, 11:56 GMT
I have the latest packages for everything:

intel-dri 7.5.1-2
mesa 7.5.1-2

and I am using the 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?
Comment by Lagaro (Lagaro) - Monday, 21 September 2009, 16:09 GMT
The freezing problem seems to have been fixed for me, now. Haven't had a crash in over a week.

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.
Comment by Daniele C. (legolas558) - Tuesday, 22 September 2009, 18:17 GMT
It's not fixed for me. Nothing changed, I can get the bug in less than 1 hour. Bug triggers more often if I use the computer instead of leaving it with screensaver or glxgears. It always happen by resizing or re-activating some window.
Comment by Andrej Podzimek (andrej) - Thursday, 24 September 2009, 14:05 GMT
Freezes are still there, much more frequent than before. Mean time before freeze is about 30 minutes now. (It used to be something like 5 hours when I tested the new Intel drivers for the first time.) I am almost sure it has something to do with Firefox, big images, Flash animations and the like.

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 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 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...
Comment by David (alleluia20) - Thursday, 24 September 2009, 18:59 GMT
I also have recently much more frequent freezes. But my experience is a bit different. When I have the freeze, even the cursor stops moving, and Ctrl+Alt+Del does not work. Or do you mean after unlocking the keyboard?

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?
Comment by (UNIVAC) - Friday, 25 September 2009, 03:57 GMT
I dont have this issue.

xf86-video-intel 2.8.1-1

KMS on

More than 12 hours uptime, usually daily, MSI wind u100 (intel gma 950).
Comment by Roman Kyrylych (Romashka) - Friday, 25 September 2009, 07:34 GMT

BTW I don't have any freezes, Intel GMA X3100M with KMS on, laptop can work full day without a glitch.
Comment by Daniele C. (legolas558) - Friday, 25 September 2009, 11:39 GMT
Seems like affecting only older hardware. Is this the well-known hardware-upgrade push ported to Linux?

I am also following the upstream bug

and I hope a fix will appear there.
Comment by Andrej Podzimek (andrej) - Friday, 25 September 2009, 13:53 GMT
> I also have recently much more frequent freezes. But my experience is a bit different. When I have the freeze, even the cursor stops moving, and Ctrl+Alt+Del does not work. Or do you mean after unlocking the keyboard?
Comment by Andrej Podzimek (andrej) - Tuesday, 06 October 2009, 01:00 GMT
Switching KMS off helps a lot! Instead of freezing the whole machine, the X server "just" crashes. So here's the log.

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.
Comment by Daniele C. (legolas558) - Tuesday, 06 October 2009, 12:17 GMT
@andrej: actually with 'nofb' kernel parameter it seems more stable...I have not yet been able to see a crash (xf86-video-intel 2.8.1-1)

I will use this configuration this week, let's see if the testcase can be reduced to the new Intel driver with framebuffer active
Comment by Daniele C. (legolas558) - Tuesday, 06 October 2009, 13:03 GMT
Nope, it happens anyway. It seems a race condition to me.
Comment by Andrej Podzimek (andrej) - Tuesday, 06 October 2009, 14:02 GMT
I have just seen a freeze (with KMS and framebuffer on) after which the same signal 11 stuff appeared in Xorg.0.log. So it seems the root cause remains, no matter if KMS is on or off. Not all the freezes get logged, but the log backtrace is always the same (if present).

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
Comment by Daniele C. (legolas558) - Tuesday, 06 October 2009, 14:11 GMT
Hi andrej,

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 ( 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.
Comment by Daniele C. (legolas558) - Tuesday, 06 October 2009, 14:12 GMT
Note: the new driver does not work with or without KMS, so this is not specifically a KMS/FB issue but a driver/Xorg?/kernel? issue
Comment by David (alleluia20) - Wednesday, 07 October 2009, 21:30 GMT
Only just in case this helps: I have been using OpenSuse Factory (that is currently kind of an alpha version for OpenSuse 11.2) for a week and a half, and I have just had 3 freezes, while using my laptop for a lot of hours. But I have no idea of the reason... (and I am very busy and stressed, so I cannot play around, I am afraid).
Comment by Daniele C. (legolas558) - Monday, 02 November 2009, 08:35 GMT
Disaster! With latest upgrade xf86-video-intel-legacy is no more usable! I had to use the following command:

pacman -U /var/cache/pacman/pkg/xorg-server- /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... :(
Comment by Daniele C. (legolas558) - Monday, 02 November 2009, 09:25 GMT
I reported this issue in
please add task relationship
Comment by Gladstone (gladstone) - Monday, 09 November 2009, 14:43 GMT
This issue still persists for me in xf86-video-intel-newest 2.9.1-1 (identical to the OP). Relevant thread:
Comment by Jan de Groot (JGC) - Saturday, 19 December 2009, 20:53 GMT
Please try kernel 2.6.32 with xf86-video-intel from testing.
Comment by Denis Sychjov (zic422) - Monday, 21 December 2009, 10:18 GMT
I have this bug with kernel 2.6.32 and intel from testing. Then I rolled back to 2.9.1 and everything is fine.
Comment by mikes (mechmg93) - Wednesday, 23 December 2009, 08:23 GMT
i had the exact same problem after upgrading to intel-dri 7.6.1 , mesa 7.6.1 kai libdrm 2.4.17 . Rolling back to previous version of these packages, the bug disappeared.
Comment by Jan de Groot (JGC) - Wednesday, 23 December 2009, 08:56 GMT
If you're running kernel 2.6.32, try booting with "i915.powersave=0". This disables all powersaving in the i915 driver. 2.6.32 contains a feature to do clock scaling, but this is buggy and has been removed from 2.6.33rc1 already.
Comment by mikes (mechmg93) - Wednesday, 23 December 2009, 10:08 GMT
i am stuck to due to ath5k problems of 2.6.32.
Comment by Daniele C. (legolas558) - Wednesday, 23 December 2009, 14:53 GMT
I am using the wireless-testing kernel and the most recent xorg-server and xf86-video-intel, now it's even worse: I can't get a console, it goes black screen after loading the modules, and if I login to Xorg "blindly" I get no Xorg, only black screen.

I have tried combinations of nomodeset, nofb, i915.powersave=0 without any success
Comment by mark (mmm) - Saturday, 26 December 2009, 16:31 GMT
may these be related? bug# 17545 ?
Merry Xmas :)
Comment by mikes (mechmg93) - Saturday, 26 December 2009, 19:42 GMT
has anyone tried the latest packages?
Comment by mark (mmm) - Saturday, 26 December 2009, 20:21 GMT
im running the latest testing, so far so good. uptime 5 hours:P but better than before, no trouble after the upgrade, so far :) i'll wait and hope it's ok :) report in a few days to see if it's hopefully gone
Comment by mark (mmm) - Saturday, 26 December 2009, 20:53 GMT
hm, bad luck for me:( the same issue again. i run most up to date testing as of today.
Comment by Alex (rednaxela) - Sunday, 27 December 2009, 17:51 GMT
After upgrading to a 2.6.32 kernel, I started having this problem where X randomly freezes but the mouse can still move. I'm going to try "i915.powersave=0" and "nomodeset" and such. Three out of four times it's happened so far, it's happened while xscreensaver was running, but that could be a coincidence. I've never had it happen when actively using the computer, so I suspect it may indeed be to do with this powersaving thing that has been mentioned, in my case.
Comment by Denis Sychjov (zic422) - Monday, 28 December 2009, 09:19 GMT
After upgrading dependencies of xf86-video-intel I can run version of it without issues. Now I'm using all latest versions and the testing repository and bug disappeared. KMS enabled. 945GME chipset.
Comment by Daniele C. (legolas558) - Monday, 28 December 2009, 13:28 GMT
@zic422: can you explain how to reproduce your environment please? I am running a normal Arch without [testing], thanks
Comment by Alex (rednaxela) - Monday, 28 December 2009, 20:18 GMT
To update on what I'm finding: "i915.powersave" had no effect. I've found that 2.6.32 (testing) kernel is causing Xorg crashes regardless of if xf86-video-intel is (testing) or 2.9.1 (extra), and that xf86-video-intel (testing) is crashing regardless of if the kernel is 2.6.32 (testing) or 2.6.31 (core)
Comment by Denis Sychjov (zic422) - Monday, 28 December 2009, 21:19 GMT
@legolas558: enable [testing] and do # pacman -Syu.
Comment by Andrej Podzimek (andrej) - Saturday, 02 January 2010, 21:42 GMT
Has anyone tried this device...

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. ;-)
Comment by Daniele C. (legolas558) - Friday, 08 January 2010, 02:55 GMT
@andrej: I have that exact hardware and will try on 2.6.32/2.6.33 ASAP, however last time it didn't work at all
Comment by Daniele C. (legolas558) - Friday, 08 January 2010, 05:02 GMT
No hope, it crashes with 2.6.32 (stock Arch Linux kernel) and 2.6.33 (Linus tree) during initialization (I get a black screen, but not turned OFF)

I have also tried 2.6.33 without this patch;a=commit;h=7abf3aa8294d95e3f0be375f30e8d933f874ada0 (as reported in but it is even worse since it crashes after loading the module for the framebuffer console
Comment by Daniele C. (legolas558) - Friday, 08 January 2010, 05:08 GMT
log of a failed session with latest packages (not [testing]) and kernel 2.6.33. Note the last thousand bytes, not ASCII!!

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
Comment by Daniele C. (legolas558) - Friday, 08 January 2010, 05:28 GMT
log of a failed session (this time using [testing]), this time it ends with:

(WW) xf86CloseConsole: VT_WAITACTIVE failed: Interrupted system call
Comment by Andrej Podzimek (andrej) - Thursday, 14 January 2010, 14:41 GMT
@Daniele: Many thanks for trying that.
This sounds like a hopeless situation. The bug makes virtually unusable on lots of machines. :-(
Comment by Daniele C. (legolas558) - Friday, 15 January 2010, 11:22 GMT
maybe it is a bug of the intel driver only
Comment by Gladstone (gladstone) - Sunday, 17 January 2010, 19:07 GMT
Just a thought... do people experiencing this bug have more than one monitor hooked up? I hadn't had my external screen attached for a month and now I do, the bug is occurring again.
Comment by Andrej Podzimek (andrej) - Sunday, 17 January 2010, 22:54 GMT
@Gladstone In my case, monitor configuration did not matter. I tried all possible configurations (LVDS only, vertical and horizontal external display (1680x1060), dual core layouts). MTBF was approwimately the same. Playing video and viewing large images made some versions even more error-prone, but again, display configuration did not matter.
Comment by teteve (titivi) - Monday, 18 January 2010, 08:06 GMT
Here, Arch crashes with Firefox, pidgin and Thunderbird on our poor little Panasonic T2 :-(
(no external screen)
I'm not a specialist .... sorry, it's not very detailed ...
Comment by Andrej Podzimek (andrej) - Thursday, 21 January 2010, 02:15 GMT
With 2.6.32, even intel-legacy crashes. (KMS off, FB off.)
OK, sounds like all hope is gone. It's time for OpenSolaris.