Bug 496516 - G45/X4500HD Xorg locks after a few minutes use with KMS and UXA
G45/X4500HD Xorg locks after a few minutes use with KMS and UXA
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F11Target
  Show dependency treegraph
 
Reported: 2009-04-19 16:53 EDT by Mace Moneta
Modified: 2013-01-10 00:10 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-30 01:06:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Xorg.0.log (64.63 KB, text/plain)
2009-04-19 16:53 EDT, Mace Moneta
no flags Details
intel_gpu_dump when 'mplayer -vo xv' hangs Xorg (1.49 MB, text/plain)
2009-05-14 01:56 EDT, Mace Moneta
no flags Details
intel_gpu_dump after 'killall -9 Xorg' and hang in restart (1.64 MB, text/plain)
2009-05-14 01:59 EDT, Mace Moneta
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 21181 None None None Never

  None (edit)
Description Mace Moneta 2009-04-19 16:53:21 EDT
Created attachment 340256 [details]
Xorg.0.log

Description of problem:

After updating, including:

xorg-x11-drv-intel-2.7.0-1.fc11.x86_64
kernel-2.6.29.1-100.fc11.x86_64

the system appeared to be operating normally.  A few minutes later, while waiting for a web page to load, Xorg locked (no cursor movement, no screen updates).  The system was still functional, but I had to shutdown to get Xorg back.

The system log indicated:

Apr 19 16:24:25 slayer kernel:[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
Apr 19 16:24:25 slayer kernel:[drm:i915_gem_object_pin] *ERROR* Failure to bind: -12
Apr 19 16:24:25 slayer kernel:[drm:i915_gem_evict_something] *ERROR* inactive empty 1 request empty 1 flushing empty 1
Apr 19 16:24:25 slayer kernel:[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
Apr 19 16:24:25 slayer kernel:[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
Apr 19 16:24:25 slayer kernel:[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty

The Xorg.o.log indicated:

(WW) intel(0): i830_uxa_prepare_access: bo map failed
(WW) intel(0): i830_uxa_prepare_access: bo map failed
(WW) intel(0): i830_uxa_prepare_access: bo map failed

Version-Release number of selected component (if applicable):

xorg-x11-drv-intel-2.7.0-1.fc11.x86_64

How reproducible:

Always

Steps to Reproduce:
1.Install updates
2.
3.
  
Actual results:

Xorg locks

Expected results:

Usable system

Additional info:
Comment 1 Warren Togami 2009-04-19 17:15:23 EDT
Mace, could you please be sure upstream is aware of this bug?
Comment 2 Mace Moneta 2009-04-19 17:32:12 EDT
Think this may be the same bug upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=21181
Comment 3 Allen Kistler 2009-04-30 02:41:24 EDT
I filed a different bug against the intel driver which has some similar symptoms that occur in anaconda.  However, when I looked at my Xorg.0.log (for a different chip, but still Intel) I noticed that the intel driver seemed to think I had 4G of video ram.  So I looked in the Xorg.0.log in this bug for a similar disconnect from reality.  In this bug, intel seems to think there's -1K (yes, less than zero) video ram.

I'm not the guy to go about tearing through the source code myself, but:
1. Is the amount of memory reported what the driver really thinks is there?
2. Presumably the driver does memory-mapped IO.
   Wouldn't not knowing where not to write be a problem?
Comment 4 Mace Moneta 2009-05-06 18:07:00 EDT
I updated today to:

kernel-2.6.29.2-129.fc11.x86_64
mesa-dri-drivers-7.5-0.9.fc11.x86_64
mesa-libGL-7.5-0.9.fc11.x86_64
mesa-libGL-devel-7.5-0.9.fc11.x86_64
mesa-libGLU-7.5-0.9.fc11.x86_64
mesa-libGLU-devel-7.5-0.9.fc11.x86_64
xorg-x11-drv-intel-2.7.0-4.fc11.x86_64

I've been up for about 2.5 hours now in KMS+UXA, playing opengl games (fullscreen and windowed), videos (fullscreen, including 1080p), and running about a dozen applications concurrently (browsing and scrolling).

The only glitch I see is on the left/right edges when scrolling in firefox on a koji build (e.g. http://koji.fedoraproject.org/koji/buildinfo?buildID=101070).

It looks much more stable on the G45/X4500HD.
Comment 5 Mace Moneta 2009-05-06 18:11:51 EDT
By the way, the artifacts appear to already be reported upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=20977
Comment 6 Mace Moneta 2009-05-08 01:39:58 EDT
KMS+UXA lasted a couple of days, then every time I started mplayer (xv, fullscreen), X hung.  No error messages anywhere.  That also appears to have an upstream bug:

https://bugs.freedesktop.org/show_bug.cgi?id=21271
Comment 7 Adam Williamson 2009-05-12 14:37:19 EDT
allen: ajax believes your issue is probably a different one and the reported memory size is likely not the problem here, so please follow up your problem within your separate report. thanks!

<adamw> ajax: do you think the two reporters are actually both encountering the same bug? or is this two separate issues?
 is allen's conjecture about reported memory size actually an issue?
<ajax> probably separate
 i don't think it's an issue, no
Comment 8 Allen Kistler 2009-05-12 15:31:33 EDT
adamw/ajax (re: #7):

I reported Bug 495032, which seems very similar to this bug to me, but with the 865.  I questioned the memory size detection, because it seemed odd in both 495032 and this bug.  I pointed it out (in both reports) because I thought it might be a common cause of underlying difficulty.  If it's not a problem, it's not a problem.  In the meantime, I'll keep watching both reports.
Comment 9 Mace Moneta 2009-05-14 01:56:06 EDT
Created attachment 343910 [details]
intel_gpu_dump when 'mplayer -vo xv' hangs Xorg

I recreated the mplayer (with xv) hang of Xorg and captured this intel_gpu_dump.
Comment 10 Mace Moneta 2009-05-14 01:59:19 EDT
Created attachment 343911 [details]
intel_gpu_dump after 'killall -9 Xorg' and hang in restart

After the above capture, I attempted to kill Xorg.  The screen went black, but Xorg hung trying to restart.  I captured another intel_gpu_dump at this point.  I had to shutdown/restart to get Xorg back.
Comment 11 Bug Zapper 2009-06-09 10:08:34 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Matěj Cepl 2009-06-30 08:56:35 EDT
Isn't this duplicate of bug 505430?

-- 
testing signature
Comment 13 Mace Moneta 2009-06-30 14:10:45 EDT
There is no oops when this bug occurs.
Comment 14 Gabriel Ramirez 2009-08-20 14:20:03 EDT
(In reply to comment #8)
> 
> I reported Bug 495032, which seems very similar to this bug to me, but with the
> 865.  I questioned the memory size detection, because it seemed odd in both
> 495032 and this bug.  I pointed it out (in both reports) because I thought it
> might be a common cause of underlying difficulty.  If it's not a problem, it's
> not a problem.  In the meantime, I'll keep watching both reports. 

seems which in certain intel chipsets* kernel mode setting garbles the memory reporting to -1 (because X works regardless of the memory reporting) I found a fix:

- disable KMS adding nomodeset to the kernel boot line
- check the Device section for intel driver in /var/log/Xorg.0.log and change the Identifier line if necesary in the following xorg.conf
- create a /etc/X11/xorg.conf with:

Section "Device"
        Identifier      "Builtin Default intel Device 0"
        Driver  "intel"
        Option "AccelMethod" "UXA"
EndSection

to force UXA mode, with tha the xorg log line shows after a restart
(==) intel(0): VideoRam: 262144 KB 


* mine is (--) PCI:*(0:0:2:0) 8086:29c2:8086:5044 Intel Corporation 82G33/G31 Express Integrated Graphics Controller rev 2
Comment 16 Matěj Cepl 2009-11-05 13:26:53 EST
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 17 Mace Moneta 2009-11-30 01:06:59 EST
This appears to be resolved in F12.  Closing.

Note You need to log in before you can comment on or make changes to this bug.