This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 91595 - XF86Config Option "NoMTRR" failed to disable i815 MTRR write-combining when "dri" and "glx" modules loaded
XF86Config Option "NoMTRR" failed to disable i815 MTRR write-combining when "...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
i686 Linux
high Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-25 06:41 EDT by C L Hong
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-20 21:51:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
XFree86 logfile from Redhat 8.0 wth Option "NoMTRR" and "dri" and "glx" modules disabled (26.40 KB, text/plain)
2003-05-25 06:45 EDT, C L Hong
no flags Details
XFree86 from Redhat 8.0 logfile showing both "glx" and "dri" loaded successfully, no Option "NoMTRR" issued. (28.88 KB, text/plain)
2003-05-25 06:46 EDT, C L Hong
no flags Details
XF86Config config file which disable write combining in MTRR for Redhat 8.0 XFree86-4.2 (3.47 KB, text/plain)
2003-05-25 06:51 EDT, C L Hong
no flags Details
XF86Config file for redhat 9.0 with dri and glx enabled, Option "NoMTRR" in device section (3.27 KB, text/plain)
2003-05-26 12:44 EDT, C L Hong
no flags Details
XFree86.0.log file for Redhat 9.0 crash dump (31.29 KB, text/plain)
2003-05-26 13:15 EDT, C L Hong
no flags Details
lsmod prior to X startup, init 3. (1.74 KB, text/plain)
2003-05-27 18:57 EDT, C L Hong
no flags Details
dmesg log file prior to X startup, init 3. (8.12 KB, text/plain)
2003-05-27 18:58 EDT, C L Hong
no flags Details
lsmod after X startup, run level 5 (2.03 KB, text/plain)
2003-05-27 18:59 EDT, C L Hong
no flags Details
dmesg log file after X startup, run level 5 (10.58 KB, text/plain)
2003-05-27 19:06 EDT, C L Hong
no flags Details

  None (edit)
Description C L Hong 2003-05-25 06:41:27 EDT
Description of problem:
Symptom: After upgrading from Redhat 8.0 to 9.0, the X server crash the whole
system from time to time (not even  Ctrl-Alt-F1 can switch to virtual terminal).
The symptom shows up  most often when load tested using x11perf -all.

Work-around solution: Upon checking the XF86Config file and the manpage and
mtrr.txt from linux kernel doc, the solution is to disable  MTRR write-combining
by issuing
Option "NoMTRR" in  Section "Screen" in  XF86Config. 

However, it was uncovered that when the Module "dri" and "glx" are loaded to
enable opengl 3D acceleration, the "NoMTRR" option has no effect
 cat /proc/mtrr still shows 
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x1ff00000 ( 511MB), size=   1MB: uncachable, count=1
reg02: base=0xe0000000 (  64MB), size=  64MB: write-combininng, count=3

Issues: However, even when both module "dri" and "glx" are *NOT* loaded, and
Option "NoMTRR" issued in XF86Config in XFree86-4.3 in Redhat 9.0, /proc/mtrr
still shows that 64MB write-combining enabled for video memory as before. 
 cat /proc/mtrr still shows 
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x1ff00000 ( 511MB), size=   1MB: uncachable, count=1
reg02: base=0xe0000000 (  64MB), size=  64MB: write-combininng, count=2
But compared to XFree86 4.2 in Redhat 8.0, these settings do disable the mtrr
properly, showing 
 cat /proc/mtrr 
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x1ff00000 ( 511MB), size=   1MB: uncachable, count=1
as it should have been happening in Redhat 9.0. 

What would be nice is to have "glx" and "dri" 3D opengl enabled and Option
"NoMTRR" issued, therefore not using any write-combining memory transfer method,
perhaps using write-back mode? I've tried writing to /proc/mtrr directly using
"echo "..." >| /proc/mtrr" but without any success. Instead, my system is
currently without any 3D acceleration loaded because of the MTRR issue. 


Version-Release number of selected component (if applicable):
XFree86-4.3.0-2.i386

How reproducible:
Everytime

Steps to Reproduce:
1.edit /etc/X11/XF86Config, by commenting out "dri" and "glx" lines, issue
Option "NoMTRR" in screen section
2.check mtrr settings by cat /proc/mtrr
3.run x11perf -all to load test the X server 
    
Actual results:
cat /proc/mtrr  
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x1ff00000 ( 511MB), size=   1MB: uncachable, count=1
reg02: base=0xe0000000 (  64MB), size=  64MB: write-combininng, count=2

X server crash from time to time

Expected results:
cat /proc/mtrr 
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x1ff00000 ( 511MB), size=   1MB: uncachable, count=1

X server should be more stable as as result of disabling write-combining
transfer method in MTRR

Additional info:
System config:
Intel Celeron 900MHz, 512MB memory, i815 grahics without cache memory
kernel 2.4.20-13.8, XFree86-4.2.0-72 for Redhat 8.0
kernel 2.4.20-13.9 for Redhat 9.0
Comment 1 C L Hong 2003-05-25 06:45:16 EDT
Created attachment 91953 [details]
XFree86 logfile from Redhat 8.0 wth Option "NoMTRR" and "dri" and "glx" modules disabled
Comment 2 C L Hong 2003-05-25 06:46:56 EDT
Created attachment 91954 [details]
XFree86 from Redhat 8.0 logfile showing both "glx" and "dri" loaded successfully, no Option "NoMTRR" issued.
Comment 3 C L Hong 2003-05-25 06:51:00 EDT
Created attachment 91955 [details]
XF86Config config file which disable write combining in MTRR for Redhat 8.0 XFree86-4.2
Comment 4 Mike A. Harris 2003-05-25 19:55:34 EDT
Put the NoMTRR option in the "Device" section, not the "Screen" section.
It seems this option is misdocumented on the manpage.

Option "noaccel"
Option "swcursor"
Option "XaaNo....."
Option "NoMTRR"

... should all be used in the "Device" section where the video driver is
declared.  Why they're listed in the "Screen" section of the manpage is a
good question.  I've never noticed that before.  I just tested a few of them
in the Screen section to see what happens, and most of them do actually work
there too, just to add to the confusion.

I'm not sure why XFree86 allows driver specific options to be stated in
Screen sections, instead of the Display section, but it does seem to.

Please test this option in the Device section and let me know if it works
or not.
Comment 5 Mike A. Harris 2003-05-25 19:58:39 EDT
Oddly, I just tried option nomtrr in the Screen section also, and it did disable
MTRR.  Thes options all appear to work both in the Screen or Device sections of
the config file.  Funny that almost all Linux distributions, and almost all
config tools put these options in the Device section (and they work), when the
manpage shows them for the Screen section.  Learn something new every day.
Comment 6 Mike A. Harris 2003-05-25 20:04:51 EDT
You've attached only RHL 8.0 config/log files.  Please attach your RHL 9 config
and log.
Comment 7 C L Hong 2003-05-26 12:44:20 EDT
Created attachment 91976 [details]
XF86Config file for redhat 9.0 with dri and glx enabled, Option "NoMTRR" in device section
Comment 8 C L Hong 2003-05-26 13:15:59 EDT
Created attachment 91977 [details]
XFree86.0.log file for Redhat 9.0 crash dump

1) Output from /proc/mtrr when Option "NoMTRR" issued, with dri loaded
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x1ff00000 ( 511MB), size=	 1MB: uncachable, count=1
reg02: base=0xe0000000 (3584MB), size=	64MB: write-combining, count=2

2) What I have found out is, if dri loaded and without "NoMTRR", then the third
line in mtrr will show count=3: 
 reg02: base=0xe0000000 (3584MB), size=  64MB: write-combining, count=3
3) no dri, without Option "NoMTRR" in config, the third line of mtrr shows
count = 1:
reg02: base=0xe0000000 (3584MB), size=	64MB: write-combining, count=1
4) no dri, with Option "NoMTRR" issued either in "Device" or "Screen" section
of config file, the third line disappeared. 
This leads to the conclusion that, loading "dri" will set the mtrr register,
regardless of the Option "NoMTRR". I suppose the default behaviour of "dri"
module is to setup write-combining in mtrr register. I've made a mistake in my
earlier post about the different behaviour between RH8 and RH9 system, in fact,
both system shows the same conditions. And thanks for the clarification on
putting "NoMTRR" in the device section. It works on RH8 and RH9 as you
described earlier. Thanks.
Comment 9 Mike A. Harris 2003-05-27 03:00:39 EDT
The X server log does not show MTRR being set.  It does show DRI croaking though.
Can you provide the output of "lsmod" from just prior to starting X up?  Also,
please attach your /var/log/messages.
Comment 10 Mike A. Harris 2003-05-27 03:07:27 EDT
The log shows option nomtrr being set.  Please set your computer into
runlevel 3, and reboot, then try starting X.  I don't think MTRR has anything
to do with this.  It looks like a DRI lockup to me.

MTRR is merely a performance tuning option which is used if both your
processor and kernel support it.  It tunes the way memory gets cached
by the processor.
Comment 11 C L Hong 2003-05-27 18:57:42 EDT
Created attachment 92012 [details]
lsmod prior to X startup, init 3.
Comment 12 C L Hong 2003-05-27 18:58:35 EDT
Created attachment 92013 [details]
dmesg log file prior to X startup, init 3.
Comment 13 C L Hong 2003-05-27 18:59:15 EDT
Created attachment 92014 [details]
lsmod after X startup, run level 5
Comment 14 C L Hong 2003-05-27 19:06:56 EDT
Created attachment 92015 [details]
dmesg log file after X startup, run level 5

I've been able to compile and run Opengl applications, such as glxinfo,
glxgears, Specviewperf, Tuxracer,  and Xvideo application such as xvinfo, xawtv
without any hang or lockup. The only X lockup I experience is when x11perf is
running. Yes, I suppose it could have been a DRI bug, but I would also suspect
X server has a role to play here.
Comment 15 Mike A. Harris 2004-08-20 21:51:37 EDT
Red Hat Linux 9 has reached end of life a number of months back,
please upgrade to our current OS release of Fedora Core 2 or later,
and if this problem persists, please file a bug report in X.Org
bugzilla, located at http://bugs.freedesktop.org in the "xorg"
component, and if you'd like us to track the issue in upstream
bugzilla, you can add a URL here to the upstream bug report and
we'll keep track of the issue in the centralized location.

Thanks in advance for testing Fedora Core 2.

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