Bug 59738

Forgot to mention: the fb driver works.

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.

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)

Created attachment 45519 [details]
XF86Config-4

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;-(

Just tried again under beta2. Same result.

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.

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

Still no go in 7.3

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.

"vesa" works (it will however crash the box if I switch from vt 7 to vt1).

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->videoRAMBytes);
+                               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
<snip>
(II) Silicon Motion(0): Splitting WC range: base: 0xfd3ff400, size: 0x800
(WW) Silicon Motion(0): Failed to set up write-combining range (0xfd3ff800,0x400)
<snip>
(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!

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.

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.

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.