Bug 455214

Summary:

Nonfunctional 3D support, Intel G33, 4GB RAM

Product:

[Fedora] Fedora

Reporter:

Jerry James <loganjerry>

Component:

xorg-x11-drv-i810

Assignee:

Adam Jackson <ajax>

Status:

CLOSED CURRENTRELEASE

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

low

Docs Contact:

Priority:

low

Version:

CC:

xgl-maint

Target Milestone:

---

Target Release:

---

Hardware:

x86_64

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2008-11-30 23:58:52 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Log file from latest attempt to run glxgears	none
xorg.conf after setting some options	none

Description Jerry James 2008-07-14 04:06:23 UTC

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 04:06:24 UTC

Created attachment 311677 [details]
Log file from latest attempt to run glxgears

Comment 2 Jerry James 2008-07-14 04:07:39 UTC

Created attachment 311678 [details]
xorg.conf after setting some options

Comment 3 Andreas Øye 2008-07-27 14:28:07 UTC

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 22:55:44 UTC

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-08-01 03:26:34 UTC

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 14:13:46 UTC

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 04:34:04 UTC

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 19:25:50 UTC

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 23:58:52 UTC

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.