Bug 20856 - X hangs after idle time on GM45
Summary: X hangs after idle time on GM45
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: 7.2
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-25 02:19 UTC by David John
Modified: 2009-04-14 12:01 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
X server log (250.45 KB, text/plain)
2009-03-25 02:19 UTC, David John
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David John 2009-03-25 02:19:51 UTC
Created attachment 24229 [details]
X server log

[Problem]

The X server hangs if the system has been left idle for a period of time (20 - 30 mins) with the following messages in the log: 

[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping.

The screen saver is disabled and system has to be rebooted (all keys stuck).

[Hardware]

I have a Dell Inspiron 1525 laptop with an mobile Intel GM45 Express chipset, Core 2 Duo and 2GB RAM.

[Software]

I am running Fedora 10 x86_64 (updated to latest packages). The problem happens with all kernels I have used so far, but I am currently using 2.6.28.8. The versions of various packages are given below:

Xserver: 1.5.3-15.fc10
X Intel Driver: 2.5.0
Mesa 3D: 7.2-0.15.fc10

[Stack Trace]
0: /usr/bin/X(xorg_backtrace+0x26) [0x4e7c96]
1: /usr/bin/X(mieqEnqueue+0x291) [0x4c87d1]
2: /usr/bin/X(xf86PostMotionEventP+0xc4) [0x4914c4]
3: /usr/bin/X(xf86PostMotionEvent+0xa9) [0x491699]
4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7fd5c3690472]
5: /usr/bin/X [0x47a795]
6: /usr/bin/X [0x46b337]
7: /lib64/libc.so.6 [0x3399a32f90]
8: /lib64/libc.so.6(ioctl+0x7) [0x3399ade037]
9: /usr/lib64/libdrm.so.2 [0x33b2a03023]
10: /usr/lib64/libdrm.so.2(drmWaitVBlank+0x20) [0x33b2a036c0]
11: /usr/lib64/dri/i965_dri.so [0x7fd5c43db09e]
12: /usr/lib64/dri/i965_dri.so(driWaitForVBlank+0xcb) [0x7fd5c43db29f]
13: /usr/lib64/dri/i965_dri.so(intelSwapBuffers+0x23f) [0x7fd5c43e0d86]
14: /usr/lib64/dri/i965_dri.so [0x7fd5c43db3e2]
15: /usr/lib64/xorg/modules/extensions//libglx.so [0xc067ff]
16: /usr/lib64/xorg/modules/extensions//libglx.so [0xbfa656]
17: /usr/lib64/xorg/modules/extensions//libglx.so [0xbfd8f2]
18: /usr/bin/X(Dispatch+0x364) [0x446904]
19: /usr/bin/X(main+0x45d) [0x42cd4d]
20: /lib64/libc.so.6(__libc_start_main+0xe6) [0x3399a1e576]
21: /usr/bin/X [0x42c129]

I also disabled the OpenGL 'Use Vsync' option in KDE, but that doesn't seem
to have any effect. I have seen this same issue solved for Ubuntu (apparently in Mesa), but I don't know which version it has been fixed in since I seem to be using the latest version.
Comment 1 Jesse Barnes 2009-03-31 18:16:54 UTC
Bugs like this have been fixed recently in libdrm, Mesa and the kernel.  But you can also work around the problem by creating a driconf file and setting the vblank_mode (googling around should show you how).
Comment 2 David John 2009-03-31 23:37:34 UTC
(In reply to comment #1)
> Bugs like this have been fixed recently in libdrm, Mesa and the kernel.  But
> you can also work around the problem by creating a driconf file and setting the
> vblank_mode (googling around should show you how).
> 

I'll try that. Thanks, Jesse.
Comment 3 David John 2009-04-02 00:47:47 UTC
> Bugs like this have been fixed recently in libdrm, Mesa and the kernel.  But
> you can also work around the problem by creating a driconf file and setting the
> vblank_mode (googling around should show you how).
> 

Nope doesn't work. The bug is still there. (I set vblank_mode to 0 and 3). Can someone at least tell me which library this occurs in? Is the bug in Mesa or libdrm?
Comment 4 David John 2009-04-14 12:01:09 UTC
Fixed on updating to Fedora 11 Beta.


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.