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 is used.
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 @@ 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?
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 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.
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] dmidecode output
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.