Bug 67359 - gui install on SMI910 does not work
gui install on SMI910 does not work
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
Brock Organ
:
Depends On:
Blocks: 67217 79578
  Show dependency treegraph
 
Reported: 2002-06-23 10:32 EDT by Gerald Teschl
Modified: 2007-04-18 12:43 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-19 06:49:51 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)
dmidecode output (4.44 KB, text/plain)
2002-11-12 12:56 EST, Gerald Teschl
no flags Details

  None (edit)
Description Gerald Teschl 2002-06-23 10:32:55 EDT
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.
Comment 1 Gerald Teschl 2002-07-16 06:15:14 EDT
Just found out that the card will work with the siliconmotion driver if

Option MTRR no

is used.
Comment 2 Bill Nottingham 2002-07-23 14:35:31 EDT
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.
Comment 3 Gerald Teschl 2002-07-24 05:21:53 EDT
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 @@
 DRIVER siliconmotion
 UNSUPPORTED
 NOCLOCKPROBE
+LINE         Option "nomtrr"

 NAME Silicon Motion LynxEM
 CHIPSET Lynx


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?
Comment 4 Mike A. Harris 2002-07-24 07:16:55 EDT
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)
Comment 5 Gerald Teschl 2002-07-24 13:29:07 EDT
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.
Comment 6 Mike A. Harris 2002-07-26 03:45:33 EDT
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
bad cases.

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.
Comment 7 Gerald Teschl 2002-07-26 04:57:08 EDT
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.
Comment 8 Mike A. Harris 2002-07-26 05:23:31 EDT
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.
Comment 9 Mike A. Harris 2002-11-03 07:47:25 EST
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.
Comment 10 Gerald Teschl 2002-11-12 12:56:48 EST
Created attachment 84704 [details]
dmidecode output
Comment 11 Gerald Teschl 2002-11-12 12:58:35 EST
I have attached the output from dmidecode for this box.
Comment 12 Mike A. Harris 2002-12-19 06:49:51 EST
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.

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