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#16974 - [xf86-video-intel] 845GM/855GM kernel panic with DRI enabled, KMS disabled

Attached to Project: Arch Linux
Opened by Daniele C. (legolas558) - Monday, 02 November 2009, 09:05 GMT
Last edited by Allan McRae (Allan) - Saturday, 02 June 2012, 11:58 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Jan de Groot (JGC)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 13
Private No


Xorg instantly crashes with the new xf86-video-intel and (presumably) only Intel 855GM hardware.

Xorg.0.log (attached) talks about DRM issues:

(II) intel(0): [drm] removed 1 reserved context for kernel
(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0xe0956000 at 0xb71ce000
(II) intel(0): [drm] Closed DRM master.

then there is a kernel panic, not recoverable by any means (neither SysRq)


I am using vanilla kernel

Steps to reproduce:

Start X server (startx)
This task depends upon

Closed by  Allan McRae (Allan)
Saturday, 02 June 2012, 11:58 GMT
Reason for closing:  No response
Comment by Daniele C. (legolas558) - Monday, 02 November 2009, 09:06 GMT
Please remove the attachment, it seems the wrong one - I am going to provide the correct one (v1.7.1)
Comment by Daniele C. (legolas558) - Monday, 02 November 2009, 09:24 GMT
no Xorg.0.log is generated! crash must happen even before Xorg can flush writes to the log...

can this crash be related to KMS? my kernel has KMS support but I have disabled it with 'nomodeset' kernel command line option because I had other issues with it enabled

relevant lspci lines:

00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
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)
Comment by Pierre Schmitz (Pierre) - Monday, 02 November 2009, 10:22 GMT
I have the same GPU and I can confirm the X freezes the whole system if you don't use KMS.
Comment by Jan de Groot (JGC) - Monday, 02 November 2009, 10:32 GMT
What are the issues when KMS is used?
Comment by Pierre Schmitz (Pierre) - Monday, 02 November 2009, 10:43 GMT
xv is disabled (and there is no arch logo on boot ;-))
Comment by Daniele C. (legolas558) - Monday, 02 November 2009, 10:44 GMT
I'll summarize:

- xorg 1.7.1 + xf86-video-intel-2.9.1 with KMS enabled: crash within 2-3 seconds from Xorg start
- xorg 1.7.1 + xf86-video-intel-2.9.1 with KMS disabled (nomodeset in kernel command line): instant crash, no Xorg.0.log produced
- xorg-server- + xf86-video-intel-legacy-2.3.2: only possible working combination, using old packages (this configuration also requires outdated packages xf86-input-synaptics-1.1.3 and xf86-input-evdev-2.2.5 to work)

Please note that this is different from #14594 since crash happens instantly
Comment by Daniele C. (legolas558) - Monday, 02 November 2009, 10:46 GMT
@JGC: can you please edit the title accordingly (kernel panic when KMS is disabled) and remove the useless Xorg.0.log attachment? Also it would be nice if my permissions could be raised so that I can do that myself in future

Comment by Grzegorz Owczaruk ( - Monday, 02 November 2009, 10:46 GMT
I have the same problem(855GM). Freezing with new drivers was issue for a long time, but now X crashes on start.
Comment by Daniele C. (legolas558) - Monday, 02 November 2009, 10:47 GMT
@Pierre: does the xf86-video-intel-2.9.1 work for you with KMS? What magic did you use??
Comment by Daniele C. (legolas558) - Monday, 02 November 2009, 10:50 GMT - I can use my laptop only with old (now unsupported) packages.

You should get a working system with this:

pacman -R xorg-server xf86-video-intel xf86-input-evdev xf86-input-synaptics && \
cd /var/cache/pacman/pkg/ && \
pacman -U xf86-input-evdev-2.2.5-1-i686.pkg.tar.gz xf86-input-synaptics-1.1.3-1-i686.pkg.tar.gz xf86-video-intel-legacy-2.3.2-3-i686.pkg.tar.gz xorg-server-

If you miss one of these packages then download it from internet
Comment by Jan de Groot (JGC) - Monday, 02 November 2009, 10:54 GMT
Looks like the KMS issue with XV will be fixed in a kernel update:

I think kernel 2.6.32 will fix the remaining KMS fixes. Also note that the next major driver version will no longer work without KMS.
Comment by Daniele C. (legolas558) - Monday, 02 November 2009, 10:59 GMT
I am going to try with mainline 2.6.32-rc5 and report back. I suppose that Eric's patch is already merged
Comment by Pierre Schmitz (Pierre) - Monday, 02 November 2009, 12:40 GMT
I did not notice any crash using kms so far (but I don't use opengl). I could attach dmesg and xorg.log if that was helpful.
Comment by Henry C. (solenoglyph) - Tuesday, 03 November 2009, 16:57 GMT
I can confirm this behavior. Presario v2000 laptop with Intel 855GM. lspci is identical to Daniele's.
With KMS enabled, X crashes after a few seconds (but looks OK before the crash).
Without KMS (nomodeset or i915.modeset=0), X hangs the system (no SysRQ) and does not write log.
There are a few interesting lines in dmesg from i915/drm:

[drm] DAC-6: set mode 640x480 0
render error detected, EIR: 0x00000010
[drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
render error detected, EIR: 0x00000010
[drm] LVDS-8: set mode 1280x768 e
Console: switching to colour frame buffer device 160x48
[drm] fb0: inteldrmfb frame buffer device

But fb console works fine, so i doubt it's relevant.
I tested using kernel 2.6.32-rc5-git6 and the problem is still present. Also, i915 in that kernel seems to be broken for me (doesn't set up fb console properly).
Comment by S H (sh__) - Tuesday, 03 November 2009, 18:36 GMT
Another Intel 855GM user here with the same symptoms when using xorg-server 1.7.1-1 and xf86-video-intel 2.9.1-1.

It seems newer kernel versions in the 2.6.31.x series cause trouble. With any 2.6.31.x kernel, X does not start if KMS is disabled. When KMS is enabled, X will hang after a few seconds with kernels to However, with kernel, X is much more stable (I've had uptimes of several hours) but still occasionally freezes. There is no XVideo, though.

Since the status of the intel driver is what it is, I think an ideal solution would be to maintain xf86-video-intel-legacy package that is compatible with xorg-server 1.7.x.
Comment by Daniele C. (legolas558) - Tuesday, 03 November 2009, 20:29 GMT
Just tried 2.6.32-rc5, Xorg does not start with:

Fatal server error:
no screens found

See also attachment.

I realize that my hardware has just been locked out of the supported series and the tip is "buy new hardware" :(
Comment by Jan de Groot (JGC) - Wednesday, 04 November 2009, 07:44 GMT
The legacy driver is not an option with xorg-server 1.7. I tried to fix the driver to work, it actually compiled after some patching, but it would lock up the machine instantly when loaded.
Comment by Daniele C. (legolas558) - Wednesday, 04 November 2009, 08:55 GMT
Is anybody aware if this issue is known upstream?
@intel? @LKML? other distros?

this reminds me of when the i810 driver (v2.3.2) was discontinued and we lost the TV-OUT feature..
Comment by S H (sh__) - Wednesday, 04 November 2009, 21:20 GMT
This issue has been reported upstream:

The more frequent freezing of X seems to be a result of the "Fix the pre-9xx chipset flush" patch:

I tested this by patching a vanilla kernel with the above patch. The resulting kernel hangs almost instantly after starting X. From the Ubuntu bugzilla, it looks like this patch has fixed problems with the i865 chipset but made them worse for i855.
Comment by Philipp (Kapaneus) - Thursday, 05 November 2009, 00:40 GMT
Same problem over here. I can confirm this happens with and without KMS and renders the system totally unusable (no ssh, no sysreq). Downgrading xserver to 1.6.1 gave back a working system. Upgrading to kernel 2.6.32-rc6 *didn't remove this issue*. KMS does a good job in setting console resolution so I guess the problem isn't related to it.
Comment by Daniele C. (legolas558) - Thursday, 05 November 2009, 23:08 GMT
I added URL for our issue in the upstream tracker

P.S. title should be corrected "i855GM/i915" and not "i855G" (which does not exist)
Comment by kols (kols) - Friday, 06 November 2009, 09:27 GMT
Hangs instantly when start X wiht out KMS. But I have a working X with KMS enabled, and it just freezes occasionally and randomly during the normal usage(usally under the situation that the graphic objects change quickly on the screen).
Comment by Scott (firecat53) - Sunday, 08 November 2009, 17:42 GMT
Same results for me as kols -- random freezing during normal usage with KMS enabled. I have the 82845 chipset.
Comment by Daniele C. (legolas558) - Monday, 09 November 2009, 09:35 GMT
I have installed a Xorg(+intel driver) development stack by using the script at (I have actually improved that script on the wiki) and I am currently stuck because if I boot without KMS ("nomodeset" in kernel command line) I get:

(EE) intel(0): No kernel modesetting driver detected.

but booting with KMS enabled leads to a black screen of death (display turned off). I have asked for help on intel-gfx freedesktop mailing list, but if somebody is also following this path please give me any pointer...

@JGC: as soon as this development stack is working I'd start trying some patches, so please consider my hardware as available for tests

Comment by Daniele C. (legolas558) - Monday, 09 November 2009, 09:36 GMT
I forgot: module i915 needs to be started *without* 'modeset=1' otherwise it leads to crazy flickering every each refresh when KMS is disabled in kernel (which is acceptable, since both the kernel and the driver should be have KMS active for it to work)
Comment by Jan de Groot (JGC) - Monday, 09 November 2009, 09:39 GMT
Note that development code requires KMS, as non-KMS support has been removed from xf86-video-intel master.
Comment by Daniele C. (legolas558) - Monday, 09 November 2009, 09:47 GMT
yes, my intention is to have a working KMS development stack, and to use the non-KMS old intel driver for normal everyday usage (the only working driver right now)

I'd like to see the KMS-enabled kernel boot correctly...should by initramfs have something special inside? for what I've read around I think the framebuffer console is totally broken
Comment by wandrian (wandrian) - Saturday, 14 November 2009, 19:05 GMT
Hi, I have the same problem.

I managed to enable KMS with an Intel i915 mobile board but when I log into any DE my system freezes after 2 seconds without any possibility of recovery.
I tried with drivers from AUR:


But nothing changed.

Comment by Petr Jezek (pjezek) - Sunday, 06 December 2009, 14:43 GMT
I am another one trapped by this. Many laptops not only like my Thinkpad X40 use this 855GM chip. I tried all possible combinations of settings based on the latest packages: KMS y/n, xorg.conf y/n, fbdev driver y/n. All issued to a total freeze of HW (display, kbd, pointer) but I/O button only. There were some (3-4x) short activities of HD visible via diode after lockup. My log (for no KMS, with xorg.conf, intel, dri, dri2 and fbdev modules) is EE free (but without fbdev EE for missing fbdev) and WW free (but WW "VGA arbiter: cannot open kernel arbiter, no multi-card support"), all the modules and submodules were loaded properly including openacpi... In a second after startx some unreadable console report run before a black lockup. Thank you for your interest, JGC!
Comment by Jan de Groot (JGC) - Sunday, 06 December 2009, 14:58 GMT
Try kernel 2.6.32 from testing, it should contain fixes for the Intel 855. Using it with KMS is recommended, but you'll lose the ability to use XV then. Intel will release new drivers later this month that should also fix that.
Comment by Jan de Groot (JGC) - Saturday, 19 December 2009, 20:54 GMT
Please try kernel 2.6.32 with xf86-video-intel from testing.
Comment by Grzegorz Owczaruk ( - Sunday, 20 December 2009, 12:55 GMT
after installing kernel from testing (2.6.32) and xf86-video-intel-newest from aur xserver starts , but after couple of minutes gpu hangs (error.log says that i need to reboot) everything freezes on screen(cursor is still working). system still works properly(i can launch apps and do stuff), after restarting xserver i can see only black screen with cursor.
Comment by Scott (firecat53) - Tuesday, 22 December 2009, 19:03 GMT
Left my comment here:[0]=&sev[0]=&due[0]=&cat[0]=&status[0]=open&percent[0]=&reported[0]=

Not sure if it's related, because the hardware is slightly different (845 vs 855), but I figured I'd add it here too just in case.

Comment by Daniele C. (legolas558) - Tuesday, 22 December 2009, 21:18 GMT
@firecat53: I think it's the same bug
Comment by Andrea Vico (Vicus) - Monday, 28 December 2009, 17:24 GMT
I have the same problem: Asus M2400N with 82852/855GM, X freeze after some seconds by the login.

I use 2.6.31-ARCH
xf86-video-intel 2.9.1-1
Comment by Severin (gripir) - Monday, 18 January 2010, 10:51 GMT
still no solution or even an acceptable workaround (beside buying new hardware)?
Comment by Daniele C. (legolas558) - Monday, 18 January 2010, 16:13 GMT
@gripir: you can currently use the old packages or buy new hardware :(, and old packages won't work forever!
Comment by Grzegorz Owczaruk ( - Monday, 18 January 2010, 17:32 GMT
there are new drivers on aur. but nothing changes, ans gpu hungs after couple of minutes. i think that nobody cares about people who still have old graphic cards, but i don't understand why it is still supported. i know that it looks better if someone will write that system supports large variety of hardware, but its only empty words. so i please you, remove support or get it f^&ing done!
Comment by Severin (gripir) - Tuesday, 19 January 2010, 11:11 GMT
thats bad news :/ ... I thought it was possible to use vesa instead of intel-drivers, so I removed intel-driver and started system without a xorg.conf. Now I dont even get a working X :D ... I hope I can fix this with a live cd this evening.
Is this an arch specific problem or does it occur on other distributions like debian, ubuntu etc. too?
Comment by Andrea Vico (Vicus) - Tuesday, 19 January 2010, 14:03 GMT
To use the vesa driver you must use "noapic" (i don't remember if noapic or nolapic, try with both) and "nomodeset" on kernel start up option.
Comment by Daniele C. (legolas558) - Tuesday, 19 January 2010, 18:49 GMT
@gripir: all distros affected, it's documented upstream:

I am still waiting for somebody to update the title of the issue: it should be 845GM/855GM
Comment by Severin (gripir) - Tuesday, 19 January 2010, 20:02 GMT
@vicus thank you very much! vesa satisfies me and there are no freezes till now :D
Comment by Petr Jezek (pjezek) - Friday, 29 January 2010, 21:08 GMT
VESA is a temporary cure for the intel driver failure, I have used VESA as well to get X working. Anyway, we need 2D acceleration (UXA for intel) at least to revitalize our older-but-satisfying HW and enjoy it. I hope many orphan packages will find new maintainers as soon as possible...
Comment by Daniele C. (legolas558) - Saturday, 13 February 2010, 03:43 GMT
still no solution, same Xorg.0.log message and weird memory dumps in /var/log/messages.log, something seriously bad must be happening in the kernel part of the intel driver
Comment by kang (kang) - Tuesday, 16 February 2010, 03:25 GMT
According to bugtrack, you can download 2.6.33-rc8 and apply their patch (see ), or get the latest git version or wait for rc9

I am currently using the intel driver on arch linux with KMS enabled, on a 855GM. Even XV works (never worked before).

Note that with KMS enabled, if i use the vesa driver it still freezes o.O but the intel one works fine now!
Comment by Daniele C. (legolas558) - Tuesday, 16 February 2010, 09:15 GMT
@kang: you are using vanilla 2.6.33-rc8 + nolid.patch and it works?

Can you provide more details? What kernel .config are you using?

I have just reported on the kernel bug entry that it only works with FC12+FC13_kernel+nolid.patch, so for me it must be either:
1) a weird situation triggered only by my kernel .config
2) some FC12/FC13 kernel patch fixes DRM issues very well

However even with the software used in the kernel bugzilla entry I get a crash
Comment by kang (kang) - Tuesday, 16 February 2010, 11:28 GMT
@Daniele C.:
I am using 2.6.33-rc8 from + nolid patch (i typed it by hand in the source but i assume its the same patch: i return status connected and skip the check)

i am not on my laptop right now however: its a CF-R3 with a 855GM chipset, kernel was stripped down to minimum config with kms/dri/agpart, i915 dri, vesa and i915 fb drivers.
i can now play 720p with xv and -hardframedrop on mplayer.. it looks nice, don't notice the frame dropping.

However, i used the laptop for 30min to make sure yesterday and more problems arised:
- opengl display is broken
- after using opengl, fonts get garbled on screen
- after a while, it freezes much like before (sysreq doesnt work) the bug that made it "not work at all"
haven't tried without using opengl.. will try tonight i guess

of course, i use arch, not fc12, no other patches, and xf86-intel (not legacy)
Comment by Daniele C. (legolas558) - Tuesday, 16 February 2010, 12:25 GMT
@kang: thank you kang, I am now using an FC13 .config (slightly stripped) and I can confirm that this issue can arise from some kernel configuration quirk.

1) with kernel .config in (my original one) I get all the above mentioned troubles
2) with kernel .config in (FC13) I get a working Xorg 1.7 + KMS

I have asked on kernel bugzilla why this is happening.
Also, I have noticed that glxgears reports 200 FPS (it should be much higher) and that fonts memory is sometimes garbled

I will also keep testing and possibly find out what's happening
Comment by Daniele C. (legolas558) - Wednesday, 17 February 2010, 10:55 GMT
Some updates from upstream:

1) using modular AGP (in your kernel .config) will cause the OFF display issue and subsequent Xorg crash, I am gonna file an Arch bug for this since AGP module should have some priority over DRM and video card module
2) the KMS/Xorg crashes seem to be totally fixed on i8xx hardware by using 855nolid.patch + drm-intel-big-hammer.patch

Only the garbled fonts issue remains for me now
Comment by Jan de Groot (JGC) - Wednesday, 17 February 2010, 11:10 GMT
If the AGP module isn't loaded before the DRM module, you should put them in MODULES in the correct order, or add them to your initcpio image in the correct order. We're not going to compile drivers static inside our kernel if we don't have to.
Comment by Daniele C. (legolas558) - Wednesday, 17 February 2010, 11:20 GMT
@JGC: there is to say that I was using a custom kernel with custom .config, so when switching to the stock Arch Linux kernel I did not think that the bug could be due to modules loading order because Arch Linux also uses them compiled as modules; J.Barnes pointed out this.

Perhaps they could add a notice to the kernel configuration help text...and we could also add this to Arch Linux documentation, since it seems to be an issue of latest kernels (since when DRM entered the stage)

Also, the "OFF display" issue happened exactly during udev rules processing, so perhaps we can add a special udev rule which loads agp modules first?

P.S. I have verified that building AGP as built-in fixes the issue, but I have not verified that DRM necessarily needs to be built-in (although I am using it as built-in to prevent further issues), so perhaps only agp module needs priority
Comment by Jan de Groot (JGC) - Wednesday, 17 February 2010, 11:46 GMT
If AGP is buit-in, it's always loaded before DRM. It would be nice if we could detect the correct loading order. This Acer system here also has this issue with Q35. At first KMS didn't work at all, but after finding out modules were loading in the incorrect order, it was fixed quite easy.
Comment by Daniele C. (legolas558) - Wednesday, 17 February 2010, 11:55 GMT
@JGC: yes - I know that. I meant to say that we could implement some udev rule which loads AGP first since agp is not built-in but modular in Arch Linux stock kernel, this is what we can do on our side. I think only agp needs to be loaded first since drm is auto-loaded by i915

P.S. I have added a kernel documentation bug also
Comment by Daniele C. (legolas558) - Monday, 15 March 2010, 12:55 GMT
@JGC: the separate DRM-modular bug has been added here:

It *is* a separate bug because the Arch Linux stock kernel won't work on these boxes with i855GM.
Comment by Daniele C. (legolas558) - Friday, 19 March 2010, 11:51 GMT
With latest kernel and intel drivers I get:

(EE) intel(0): No kernel modesetting driver detected.

Is KMS disabled in latest kernel?
Comment by Daniele C. (legolas558) - Thursday, 08 April 2010, 22:02 GMT
Looks like nobody is supporting this bug from Arch.

Anyway the i855GM issues have just been radically fixed by Daniel Vetter, you can find the patch and the complete kernel sources archive here:

Patch has not yet been pushed upstream so it will take a lot of time before seeing it in regularly released kernel; all people interested can get the patch and/or the patched kernel which I have put above.

The bug should be closed as soon as the patch is accepted in linus' tree (it still has to get to drm-intel-next).
Comment by Thomas Dziedzic (tomd123) - Monday, 28 June 2010, 20:55 GMT
Comment by Karol Błażewicz (karol) - Thursday, 08 July 2010, 08:49 GMT
82845G/GL[Brookdale-G]/GE + fully updated system = + maybe some other bugs.
Let's see if 'i915.powersave=0' helps.

Edit: Nah, it doesn't help.
Comment by Jan de Groot (JGC) - Wednesday, 13 October 2010, 21:44 GMT
Is this still an issue with latest X, driver and kernel?
Comment by S H (sh__) - Friday, 03 December 2010, 21:33 GMT
The latest kernel and driver seem stable when shadowfb is enabled. Xvideo overlay works but there is no 3D acceleration.

Without shadowfb, 3D acceleration is sort of working at the cost of some serious flickering. After a few minutes, artefacts start appearing on the screen and the fonts look corrupted, so the system is not really usable.

xorg-server 1.9.2-2
xf86-video-intel 2.13.0-4
Comment by Jan de Groot (JGC) - Friday, 03 December 2010, 21:36 GMT
ShadowFB is enabled by default on 845 for a reason ;).
On my test machines that run Arch as thinclient solution, shadowFB was required to get X to start the 2nd time. Without it, X would just hang or corrupt the whole screen. AFAIK DRI should work with ShadowFB enabled though.
Comment by Allan McRae (Allan) - Saturday, 28 April 2012, 16:11 GMT
Current status?