Bug 496516

Mace, could you please be sure upstream is aware of this bug?

Think this may be the same bug upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=21181

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?

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.

By the way, the artifacts appear to already be reported upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=20977

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

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

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.

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.

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.

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

Isn't this duplicate of bug 505430?

-- 
testing signature

There is no oops when this bug occurs.

(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

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

This appears to be resolved in F12.  Closing.