Bug 59738 - siliconmotion driver crashes
siliconmotion driver crashes
Product: Red Hat Linux
Classification: Retired
Component: XFree86-Servers (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-02-12 09:55 EST by Gerald Teschl
Modified: 2007-04-18 12:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-16 06:16:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XF86Config-4 (3.80 KB, text/plain)
2002-02-13 07:54 EST, Gerald Teschl
no flags Details

  None (edit)
Description Gerald Teschl 2002-02-12 09:55:24 EST
The siliconmotion driver will crash my system after approx 5sec
every time it is started. This is an ASUS L7300 laptop (see beta hw #12)

00:02.0 VGA compatible controller: Silicon Motion, Inc. SM910 (rev b5)
Comment 1 Gerald Teschl 2002-02-12 09:55:59 EST
Forgot to mention: the fb driver works.
Comment 2 Mike A. Harris 2002-02-12 13:53:31 EST
XFree86 3.3.6, on Red Hat Linux Beta Version 6.1.90?

Please attach logs + configs, and update the report to the correct
version please.  Indicate the exact package version-release you're using
too please.
Comment 3 Gerald Teschl 2002-02-13 07:53:07 EST
This is a vanilla beta1 text install (Hampton): XFree86-4.2.0-6.24
(gui install won't work since the system crashes right after the
gui comes up)
Comment 4 Gerald Teschl 2002-02-13 07:54:10 EST
Created attachment 45519 [details]
Comment 5 Gerald Teschl 2002-02-13 08:23:04 EST
I just did a startx as root. The X server will come up and I can
see the KDE startup screen. Then it draws a window telling me
that arts failed and the system freezes. Unfortunately, the
log file was empty (due to the crash) - so I can't attach it;-(
Comment 6 Gerald Teschl 2002-03-09 12:29:36 EST
Just tried again under beta2. Same result.
Comment 7 Mike A. Harris 2002-03-12 04:03:57 EST
I do not have access to any siliconmotion hardware or docs, so I can't really
do much to fix the problems whatever they are.  What I can do is possibly
provide a workaround.  To do that, I'll need you to test the various
drivers out, and tell me what one works for you, possibly testing different
driver options, disabling acceleration, etc.

Once I know what settings work, I can make them the default so that it at least
works after install, albeit perhaps not optimally.
Comment 8 Gerald Teschl 2002-03-12 16:06:45 EST
Currently only the XF86_SVGA server works. I tried to disable all hw accel and
use 8bpp. It will take a bit longer to crash but the v4 server is not
usable. See also #60949
Comment 9 Gerald Teschl 2002-05-08 15:02:02 EDT
Still no go in 7.3
Comment 10 Mike A. Harris 2002-05-30 02:37:45 EDT
I don't have access to any siliconmotion hardware, and as such cant
reproduce.  Short of someone who does have the hardware, doing a full
debug of the driver and fixing it, and submitting patches, this hardware
will remain nonfunctional.  If it doesn't work with any drivers, try
out the XFree86 4.x "vesa" driver, if that fails, try the "vga" driver.

Let me know what one works.  I'll set the database to default to that
for the future.  If nothing works at all, then the hardware is just
no longer supported by XFree86.

Closing as WONTFIX, and recommending to report the problem upstream
where someone who _might_ be able to fix it, can become aware of the
issue, and possibly fix it for future releases.

We'll be dropping 3.3.6 support in the future, and hardware that does
not work at all in 4.x will be totally unsupported.  Best to try to
prod someone to fix it in 4.x now.
Comment 11 Gerald Teschl 2002-06-03 07:28:03 EDT
"vesa" works (it will however crash the box if I switch from vt 7 to vt1).
Comment 12 Gerald Teschl 2002-06-10 13:16:42 EDT
I did some further investigations, and I feel I somehow traced the problem.
It looks like it is related to the mapping of the framebuffer. In fact, if
I map just a little bit less than the actual videoram (4M in my case)
the driver no longer crashes
--- smi_driver.c.orig   Mon Jun 10 10:25:22 2002
+++ smi_driver.c        Mon Jun 10 18:59:36 2002
@@ -1827,7 +1827,7 @@
        if (pSmi->videoRAMBytes)
                pSmi->FBBase = xf86MapPciMem(pScrn->scrnIndex, VIDMEM_FRAMEBUFFER,
-                               pSmi->PciTag, pScrn->memPhysBase,
+                               pSmi->PciTag, pScrn->memPhysBase,
pSmi->videoRAMBytes - 1024);
                if (pSmi->FBBase == NULL)
I can even run kde/mozilla/etc with only some minor cosmetic problems when
I drag windows around (sometimes part of the border gets filled by some
random parts of background). However, I get numerous warnings from the
driver of the type:

(II) Silicon Motion(0): Physical MMIO at 0xFD400000
(II) Silicon Motion(0): Logical MMIO at 0x40014000 - 0x40023FFF
(II) Silicon Motion(0): DPR=0x4001C000, VPR=0x40020000, IOBase=0x00000000
(II) Silicon Motion(0): DataPort=0x40014000 - 0x4001BFFF
(II) Silicon Motion(0): Splitting WC range: base: 0xfd000000, size: 0x3ffc00
(II) Silicon Motion(0): Splitting WC range: base: 0xfd000400, size: 0x3ff800
(II) Silicon Motion(0): Splitting WC range: base: 0xfd000800, size: 0x3ff400
(II) Silicon Motion(0): Splitting WC range: base: 0xfd3ff400, size: 0x800
(WW) Silicon Motion(0): Failed to set up write-combining range (0xfd3ff800,0x400)
(WW) Silicon Motion(0): Failed to set up write-combining range (0xfd000000,0x3ffc00)
(II) Silicon Motion(0): Physical frame buffer at 0xFD000000
(II) Silicon Motion(0): Logical frame buffer at 0x40067000 - 0x40466FFF

Does this make any sense to you? Do you understand what is going on?

Thanks for your help!
Comment 13 Gerald Teschl 2002-07-16 06:16:50 EDT
The card will work with the siliconmotion driver if

Option MTRR no

is used. Could you add this to your data base as a workaround.
Comment 14 Gerald Teschl 2002-07-24 05:31:13 EDT
Egbert Eich from XFree86 said he'll look into the porblem. So hopefully
this will be fixed in a future release of XFree86. Hence I close this bug.
See also #67359.
Comment 15 Mike A. Harris 2002-07-26 04:49:34 EDT
I wont add NoMTRR to the default configuration database for the reasons
cited in bug #67359.  This is a machine specific issue, and not a video
card specific issue.  The database deals with video card specific
configuration, and not card-motherboard combos.

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