Bug 455214 - Nonfunctional 3D support, Intel G33, 4GB RAM
Nonfunctional 3D support, Intel G33, 4GB RAM
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
9
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-14 00:06 EDT by Jerry James
Modified: 2009-10-22 08:56 EDT (History)
1 user (show)

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


Attachments (Terms of Use)
Log file from latest attempt to run glxgears (54.18 KB, text/plain)
2008-07-14 00:06 EDT, Jerry James
no flags Details
xorg.conf after setting some options (705 bytes, text/plain)
2008-07-14 00:07 EDT, Jerry James
no flags Details

  None (edit)
Description Jerry James 2008-07-14 00:06:23 EDT
Description of problem:
I purchased a computer with an Intel G33 chipset and 4GB of RAM, but the 3D
support isn't working.  I can launch extremetuxracer, which reports about 0.3
FPS.  Other 3D programs freeze up the entire computer, to the point where I have
to force a power off to recover.  Here is what I have done so far to try to fix
the problem.

I built the computer on a Shuttle SG31G2 barebone.  I found that a later BIOS
was available at
http://global.shuttle.com/download03.jsp?PI=646 and flashed the BIOS.

I found bug #446620, and read about the MTRR problems associated with 4GB of
RAM.  Sure enough, /proc/mtrr reported:

reg00: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg01: base=0x120000000 (4608MB), size= 256MB: write-back, count=1
reg02: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg03: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg04: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg05: base=0xcf600000 (3318MB), size=   1MB: uncachable, count=1
reg06: base=0xcf800000 (3320MB), size=   8MB: uncachable, count=1
reg07: base=0xcf700000 (3319MB), size=   1MB: uncachable, count=1

so I combined the reg05 and reg07 blocks in /etc/rc.d/rc.local to free one up
for X.  Now /proc/mtrr reports:

reg00: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg01: base=0x120000000 (4608MB), size= 256MB: write-back, count=1
reg02: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg03: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg04: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg05: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
reg06: base=0xcf800000 (3320MB), size=   8MB: uncachable, count=1
reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1

I tried adding some explicit option settings to /etc/X11/xorg.conf.

I'll attach my Xorg.0.log and xorg.conf.  Even with the new BIOS, the MTRR
problem apparently fixed, and some explicit option settings in
/etc/X11/xorg.conf, the problem persists.  If I run glxgears, the gears are
drawn on a black screen, but never move (that I can tell).  The mouse pointer is
still quite responsive, but I can't get the program to quit.  If I Ctrl-Alt-F1
to go to a VT, then go back to the X screen, it gets redrawn normally and my
terminal window reports that glxgears segfaulted.  Then /var/log/messages shows
something like this:

Jul 12 15:48:48 speedy kernel: glxgears[3086]: segfault at 30 ip 1292bd sp 7fff5
2dddc40 error 4 in i915_dri.so[110000+5f000]

Any ideas on what to try next are greatly appreciated.  Removing 2GB of RAM is
not an appealing option.

Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.4.99.905-1.20080701.fc9.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Run a 3D graphics using program
  
Actual results:
The initial screen is often drawn, but then freezes or (in the case of
extremetuxracer) moves at a glacial pace.

Expected results:
Normal 3D movement.

Additional info:
Comment 1 Jerry James 2008-07-14 00:06:24 EDT
Created attachment 311677 [details]
Log file from latest attempt to run glxgears
Comment 2 Jerry James 2008-07-14 00:07:39 EDT
Created attachment 311678 [details]
xorg.conf after setting some options
Comment 3 Andreas Øye 2008-07-27 10:28:07 EDT
I also have this after upgrading to F9. Worked ok-ish with F8 This is a gigabyte
G33M-S2H motherboard 

/proc/mtrr contains:
reg00: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg01: base=0x130000000 (4864MB), size= 256MB: uncachable, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf800000 (3320MB), size=   8MB: uncachable, count=1
reg04: base=0xcf700000 (3319MB), size=   1MB: uncachable, count=1
reg05: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg06: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg07: base=0xcf600000 (3318MB), size=   1MB: write-through, count=1
Though I'm not sure how to parse this.
When I run a 3d program like glxgears it shows up very broken, overwriting other
parts of the screen. and only the tips of the blue cog is actually visible, the
rest is all black. bzflag segfaults.

Comment 4 Jerry James 2008-07-31 18:55:44 EDT
Andreas, read this: http://en.wikipedia.org/wiki/Mtrr.

Your mtrr settings have two interesting differences from mine (besides order,
and the size of the AGP aperture): your 0x130000000 block is uncachable (mine is
write-back), and your 0xcf600000 block is write-through (mine is uncachable). 
That means you can't combine the 0xcf600000 and 0xcf700000 blocks like I did to
free up a register.  On the other hand, doing so didn't solve the problem for me.

So, do we have to wait for PAT support in the kernel, or is there some hope of
figuring out what the MTRR registers should contain?
Comment 5 Jerry James 2008-07-31 23:26:34 EDT
Other people have reported problems with Intel chipsets and MTRRs only with 4GB
of RAM or more.  I just pulled out one of my memory sticks and rebooted with 2GB
installed.  The MTRR registers are different, but the problems reported above
all remain.
Comment 6 Jerry James 2008-08-13 10:13:46 EDT
The segfault address has changed slightly in kernel-2.6.25.14-108.fc9.x86_64.  The message now reads:

Aug 13 08:10:06 speedy kernel: glxgears[3811]: segfault at 30 ip 1292bd sp 7fffe00a6e10 error 4 in i915_dri.so[110000+5f000]

Also, I tried XAA instead of EXA on a lark.  With XAA, I get random screen artifacts all over the place and glxgears still doesn't move.
Comment 7 Jerry James 2008-09-13 00:34:04 EDT
The address has changed again in kernel-2.6.26.3-29.fc9.x86_64.  The message now reads:

Sep 12 22:29:30 speedy kernel: glxgears[3591]: segfault at 30 ip 1292bd sp 7fffb8cdba50 error 4 in i915_dri.so[110000+5f000]

When I run glxgears now, the red gear is barely visible.  It looks like it is in deep shadow.  That's different from the 2.6.25 kernels.
Comment 8 Jerry James 2008-10-03 15:25:50 EDT
For kernel-2.6.26.5-45.fc9.x86_64, the message is now:

Oct  3 13:20:20 speedy kernel: glxgears[3691]: segfault at 30 ip 1292bd sp 7fffefceba60 error 4 in i915_dri.so[110000+5f000]

Also, I tried passing enable_mtrr_cleanup on the kernel boot line, but it made no difference.  The contents of /proc/mtrr are the same as they always were.  Still no 3D whatsoever with the latest F9 kernel + Xserver combo.
Comment 9 Jerry James 2008-11-30 18:58:52 EST
I flashed my BIOS to the latest version and installed F-10 ... and now 3D works!  I don't know if it was the BIOS change or the F-10 change or both that solved the problem, but everything is functioning normally now.  I'll go ahead and close the bug.

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