I have a laptop with a SMI910 (Silicon motion Lynx) card. However
the X server will crash immediately. This card does not work with
the siliconmotion driver, please use vesa instead.
Just found out that the card will work with the siliconmotion driver if
Option MTRR no
Unfortunately, that's an X server option (as opposed to a driver option),
AFAICT; this means that this can't be fixed in the hwdata table.
If I just do (under 7.3)
--- /usr/share/hwdata/Cards.orig Wed Apr 17 18:50:59 2002
+++ /usr/share/hwdata/Cards Tue Jul 16 16:01:36 2002
@@ -3203,6 +3203,7 @@
+LINE Option "nomtrr"
NAME Silicon Motion LynxEM
Xconfigurator will set up the card just fine and everything will work.
So what difference does it make if the option is picked up by
the driver or by the server?
Hmm, I am unable so far to find the "nomtrr" option documented anywhere
in XFree86 documentation. Once I find it (assuming its there) and figure
out how it works, I can consider adding it to the Cards database if it
is indeed an option that resides in the Device section.
(And update the slack documentation too)
Looks like it is not documented. However, it is used in vidmem.c and turns
off write-combine. One of the side effect of my trial and error changes to
the siliconmotion driver were that it failed to set up wc...
Egbert Eich is looking into this, but for now this seems the best work around.
I have documented this option on the XF86Config manpage now, and will
submit it upstream.
I wont put the NoMTRR option on by default however for this driver because
MTRR's not working is not a video driver/card specific thing. If MTRR's
do not work on your machine, it is a bad combination of hardware on your
specific machine, and is not specific to all machines containing the
same video driver. It does not make sense to penalize users who have
machines with working MTRR support with up to a 250% slowdown in video
performance due to one buggy machine.
Likewise, I wont use the "vesa" driver by default, because the driver
does work for many users. The problem you're having is specific to your
specific machine, and there is no way to reasonably detect bad hardware
combinations and change these things from the default for specific
The proper solution for this, is for the driver to be fixed, or someone
detect this combination internally and disable MTRR on this machine.
I've discussed this problem with upstream maintainers, who are
investigating a fix/workaround. At this point, there's nothing we
can do until an upstream fix is available to test.
I'll leave this open for now, pending upstream fix, and defer it if nothing
comes from upstream in a reasonable amount of time.
I know that the siliconmotion driver wors for other lynx chipsets,
but I don't know of any person with an SMI910 chip which works under linux
(I know many who have the same problem I have). There is no need to use
it for any chipset other than SMI910.
There is no noticable difference in speed between the linux(+nomtrr) and the
windows driver. In particular, I cannot confirm the "250% slowdown".
I tought the policy of rh is to have conservative settings which work
for as many users as possible? I run a web page on how to get this card
working under linux and many people have contacted me for help, so its
not just one buggy machine. But the decision is up to you, I can always
add the option by hand.
While you may not know another person with the same chip that does
work, that does not exclude such people from existing. There is not
exactly an influx of 1000 bug reports from users of this hardware,
which implies to me that it is isolated. MTRR's are not a video
card specific thing as I said, and disabling MTRR's for a video
card regardless of the machine it is used in, is not sensible.
I'm curious how you performed your benchmark between Windows and Linux.
The point I am making, is that MTRR's provide up to 250% video
performance gain when they are enabled. Wether or not you or
anyone else actually sees that in your particular circumstance
is totally irrelevant.
Don't try to "the policy of Red Hat" me on this one. The policy
of Red Hat is to let the developers explore various solutions to
a given problem, research a problem and devise a fix/workaround or
solution which seems to be the best technical decision given the
available data/research. I have investigated this, including
discussing it on mailing lists and with Egbert.
You may have 10 or even 100 users with the same problem, but disabling
a performance feature for 100 users and killing the performance for
existing numbers of users that are much larger is not a solution at all.
The problem aparently is a hardware problem which is machine specific,
and in that case it is something that needs a workaround in the driver.
Penalizing hardware which does not have the problem is not a proper
technical solution, and is not responsible.
There is no need to debate this in bugzilla, the decision is final
barring a real bugfix/workaround from XFree86.org.
Deferring for future.
Arjan, is this something you could use dmi-decode info to detect this
box in the kernel and have MTRR's disabled at the kernel level?
If so, could we do this in future kernels after obtaining the dmi-decode?
If not, there's nothing I can do, and I'd like to close this issue out.
Created attachment 84704 [details]
I have attached the output from dmidecode for this box.
This hardware is extremely rare, the problem is a hardware bug, not a driver
bug, nobody upstream seems to care about it, and no easy way of blacklisting
just this one single machine with the problem. It simply is not worth wasting
time on compared to much more important issues, when a workaround for the
hardware flaw exists by using NoMTRR. I've documented the NoMTRR option
on the manpage.
Closing NOTABUG as it is not an XFree86 bug, but a hardware one.