#428711 black screen and no keyboard on Silicon Motion with Xserver 1.3

Package:
xserver-xorg-core
Source:
xorg-server
Description:
Xorg X server - core server
Submitter:
clayton
Date:
2019-09-30 18:27:03 UTC
Severity:
important
#428711#5
Date:
2007-06-13 16:57:52 UTC
From:
To:
I track testing with this machine. It was working just fine with xorg/siliconmotion module until I upgraded to the
current testing version. Now starting X results in a blank screen, and a locked up keyboard (Ctl-Alt-F1,
Ctl-Alt-Backspace seem to have no effect). I can still log in through the network.

The appended log file contains:

(EE) AIGLX: Screen 0 is not DRI capable

Note that I did make this go away at one point by turning off AIGLX, and behavior was unchanged.

I also tried the vesa module, and had exactly the same result: blank screen, unresponsive keyboard.

Post upgrade, this machine is now dead in the water.
#428711#10
Date:
2007-06-13 18:37:07 UTC
From:
To:
reassign 428711 xserver-xorg-core
found 428711 2:1.3.0.0.dfsg-6
retitle 428711 black screen and no keyboard on Silicon Motion with
Xserver 1.3
thank you




clayton wrote:

Probably related to the upgrade of xserver-xorg-core to 1.3.

This is harmless and I think it has been changed to a warning for the
next releases.

I wonder whether it could be related to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424684 (vesa driver
broken) which has a candidate patch pending.

Try downgrading with

http://snapshot.debian.net/archive/2007/03/08/debian/pool/main/x/xorg-server/xserver-xorg-core_1.1.1-20_i386.deb

Brice
#428711#23
Date:
2007-06-15 08:38:45 UTC
From:
To:
(EE) VESA(0): No matching modes
For vesa, in my log I am seeing:
(EE) Screen(s) found, but none have a usable configuration.
But I can't say that I remember actually ever *seeing* vesa run on this machine. It is just notable that in the current messed-up state behavior is exactly the same as when using the Silicon Motion driver.

I actually had to downgrade all of the xorg packages to http://snapshot.debian.net/archive/2007/03/08/debian/ to get the xserver to run, it was complaining about package versions not matching. But after some pulling of the hair, I succeeded (thank you apt-get) and X is working again. So we can't say for sure it is xserver-xorg-core, from this experiment.

If I can help debugging in any other way, don't hesitate to ask.
#428711#28
Date:
2007-07-05 09:24:14 UTC
From:
To:
Clayton wrote:

xserver-xorg-core 2:1.3.0.0.dfsg-7 has been uploaded to unstable today.
It contains a VBE/VESA fix which might help with your siliconmotion
driver too.

Thanks,
Brice
#428711#33
Date:
2007-07-05 15:36:53 UTC
From:
To:
On Thu, 05 Jul 2007 11:24:14 +0200 Brice Goglin <Brice.Goglin@ens-lyon.org> wrote:

My girlfriend is on a biz trip with the thing, I will try when she
returns and report back.

clayton
#428711#38
Date:
2007-07-14 16:20:35 UTC
From:
To:
On Thu, 05 Jul 2007 11:24:14 +0200 Brice Goglin <Brice.Goglin@ens-lyon.org> wrote:

No progress I am afraid, the same blank screen and locked keyboard for
both the vesa and silicon motion drivers using latest unstable xorg.

Clayton
#428711#45
Date:
2007-08-06 14:25:24 UTC
From:
To:
Clayton, do you know exactly which combination of xserver-xorg-core
and xserver-xorg-video-siliconmotion you tried so far? I forwarded your
bug upstream at https://bugs.freedesktop.org/show_bug.cgi?id=11845
and the developer wants to know whether you were using the same driver
when you said xserver-xorg-core 1.1 worked while 1.3 gave a black screen.

I guess you initially had xserver-xorg-core 1.1 with siliconmotion 1.4.1
(all from etch). Then you upgraded to 1.3 + 1.5.1 (current testing) from
what I see at the end of your first report. Then you probably downgraded
back to 1.3 + 1.4.1 to get something working again.

IIRC xserver-xorg-core 1.3 (testing/unstable) should work with siliconmotion
1.4.1 (etch/stable). Did/could you check this combination? It would help us
be sure whether the problem is in the server or the driver.

Feel free to either reply direct in the upstream bug above or reply here
and will be forward your reply there.

Thanks,
Brice
#428711#50
Date:
2007-08-06 15:35:48 UTC
From:
To:
On Mon, 6 Aug 2007 16:25:24 +0200 Brice Goglin <Brice.Goglin@ens-lyon.org> wrote:

Hi Brice,

I am pretty sure that each time I moved from one version of xorg to
another (snapshot.debian.net/archive/2007/03/08/debian/ <--> testing
<--> unstable) *all* the xorg modules changed, including the modules. As
I recall, apt-get was unwilling to easily let me do otherwise. So I do
not think the combination of unstable xserver-xorg-core 1.3 and stable
siliconmotion 1.4.1 was ever tested.

Clayton
#428711#55
Date:
2007-08-09 07:59:06 UTC
From:
To:
Brice, I just added the "testing" version of only xserver-xorg-core to
the snapshot.debian.net/archive/2007/03/08/debian/ version of xorg. And
then booted into a blank screen. After downgrading xserver-xorg-core
back down to snapshot.debian.net/archive/2007/03/08/debian/ everything
worked again. It would appear the problem is indeed probably in
xserver-xorg-core and not the siliconmotion module.

Clayton
#428711#60
Date:
2007-08-10 08:26:18 UTC
From:
To:
Clayton wrote:

Thanks a lot for the clarification, I'll notify the upstream developer.
He's supposed to look at the problem soon.

Brice
#428711#65
Date:
2007-08-10 08:17:42 UTC
From:
To:
Everything works under snapshot.debian.net/archive/2007/03/08/debian/
--> xserver-xorg-core=2:1.1.1-19
--> xserver-xorg-video-siliconmotion=1:1.4.1-4

Replace above xserver-xorg-core (and nothing else changes) with
xserver-xorg-core=2:1.3.0.0.dfsg-11 from testing and it breaks.

Clayton
#428711#70
Date:
2007-09-17 18:00:14 UTC
From:
To:
Hi,

Is 1.2.99.901-1 or 1.2.99.902-1 generated?
It is remembered that it was between 1.2.99.901-1 and 1.2.99.902-1 that the condition
from which VT is set to blank screen by my machine began to occur.
#428711#75
Date:
2008-09-05 18:16:06 UTC
From:
To:
I have improved by applying this patch.
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-siliconmotion.git;a=commitdiff;h=8feca790a6e92799019237ac69a4ef618cacfaae

However, dash shell sends a message called "turning off NDELAY mode".
#428711#80
Date:
2008-10-05 05:35:17 UTC
From:
To:
I just tested with the latest and greatest xorg in testing. Behavior is
slightly different now:

$ lspci
Controller 00:02.0 VGA compatible controller: Silicon Motion, Inc.
SM712 LynxEM+ (rev a0)

xorg is trying to drive this graphics card with a neomagic driver now,
which of course fails.

I forced loading of the siliconmotion driver by manually adding
appropriate device and screen entries to xorg.conf, and I am back to a
blank screen and locked up keyboard, just like before.

Clayton
#428711#85
Date:
2009-09-21 15:31:49 UTC
From:
To:
And now the Xorg.0.log seems to have some very interesting new details
about the failed start. See at the end of the attached log:

(II) SMI(0): Printing probed modes for output LVDS
(II) SMI(0): Modeline "800x600"x59.9   38.25  800 832 912 1024  600 603
607 624 -hsync +vsync (37.4 kHz) (II) SMI(0): Output LVDS connected
(II) SMI(0): Using fuzzy aspect match for initial modes
(II) SMI(0): Output LVDS using initial mode 800x600
(EE) SMI(0): Not enough video memory for the configured screen size
(800x800) and color depth. (II) UnloadModule: "siliconmotion"
(II) UnloadModule: "vbe"
(II) Unloading /usr/lib/xorg/modules//libvbe.so
(II) UnloadModule: "int10"
(II) Unloading /usr/lib/xorg/modules//libint10.so
(II) UnloadModule: "vgahw"
(II) Unloading /usr/lib/xorg/modules//libvgahw.so
(EE) Screen(s) found, but none have a usable configuration.
#428711#90
Date:
2011-01-28 10:04:48 UTC
From:
To:
Hi,

Clayton <ckoeni@gmail.com> (21/09/2009):

maybe you'd have a chance to report what's happening with an X stack
from squeeze/sid, or from experimental?

KiBi.
#428711#97
Date:
2011-01-30 15:33:50 UTC
From:
To:
Hi Cyril,

Running an up-to-date testing, I get exactly the same behavior with the
same error messages in Xorg.0.log.

Clayton
#428711#102
Date:
2011-12-01 19:52:09 UTC
From:
To:
I was getting the same issue of a black display when nursing an old
laptop  off Etch -> lenny -> squeeze with the same siliconmotion
LynxEM chipset.
reading this bug report 428711 gave me enough clues to do a work around.

First the bug reporter's last E-mail may not be relevant to the
original report and could be because the amount of graphic memory is
low, so that the X server errors out before doing the black screen...
which it will do after fixing only this.
(EE) SMI(0): Not enough video memory for the configured screen size

mine has 4MB video memory... seems that is not enough to run at
1024x786 in 32bit color depth
Changing to a color depth of 16 solved that...
I dropped the col
Section "Screen"
     Identifier "Screen"
     Device     "Video Card"
     Monitor    "Monitor"
     DefaultDepth       16
     SubSection "Display"
         Depth   16
          Virtual 1024 768
     EndSubSection
EndSection

Next I went through and turned off anything the driver could do....all
optimizations etc, until it no longer black screened, but was not
usable (slow).
The winning option is
  Option "UseBIOS" "off"

Depending on state of affairs (like if X has already run),  you may
seem to have a working X-server with UseBIOS on, but when exiting the
X-server  it black screens and you cannot see any of the consoles
either.
So as long as "UseBIOS" is "off", it behaves before, during and after X.

      Section "Device"
         Identifier "Video Card"
         Driver "siliconmotion"
         BusID  "PCI:0:2:0"
#       Option "HWCursor" "off"
##Essential Option, unless you like a black screen ##
        Option "UseBIOS" "off"
#       Option "CSCVideo" "off"
#       Option "NoAccel"
#       Option "PciBurset" "off"
       EndSection

This is on a Shuttle 1000 (500 Mhz, 96MB memory) , not an IBM so while
I am sure they sourced the same broken pieces for the video BIOS, BIOS
versions would be pretty useless here.
I use it as PC-oscilloscope running off a CompactFlash 2 GB drive.

Hope this is useful to someone.

      Sincerely
                 J.Currey