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:
Created attachment 311677 [details] Log file from latest attempt to run glxgears
Created attachment 311678 [details] xorg.conf after setting some options
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.
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?
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.
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.
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.
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.
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.