<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Trouble shooting with the SVGA Tseng driver</TITLE>
</HEAD>
<BODY BGCOLOR="#efefef" TEXT="black" LINK="blue" VLINK="#551A8B" ALINK="red">

<A HREF="tseng.html"><EM> Information for Tseng Chipset Users</EM></A>
 <b>:</b> <EM>Trouble shooting with the SVGA Tseng driver</EM><BR>
<b>Previous:</b> <A HREF="tseng14.html"><EM>Linear addressing and 16bpp/24bpp/32bpp modes </EM></A><BR>
<b>Next:</b> <A HREF="tseng16.html"><EM>Acknowledgments </EM></A>


<HR NOSHADE>
  <H2><A NAME="22"></A>15. Trouble shooting with the SVGA Tseng driver</H2>
<p>First of all, make sure that the default modes selected from your
<code>XF86Config</code>
are supported by your monitor, i.e. make sure the horizontal sync limit is
correct. It is best to start with standard 640x480x256 with a 25.175 MHz
clock (by specifying a single horizontal sync of 31.5) to make sure the
driver works on your configuration. The default mode used will always be
the first mode listed in the modes line, with the highest dot clock listed
for that resolution in the timing section.</p>
<p>Some general hints:
<ul>
<li>Put Option "slow_dram" in the Device Section.</li>
<li>Put Option "pci_burst_off" in the Device Section.</li>
<li>Put Option "w32_interleave_off" in the Device Section.</li>
<li>Take out the Hercules monochrome adapter, if you have one.  Many
configurations of the ET4000/W32 series do not allow one in the
system.</li>
<li>Get a motherboard with its local bus running at 33 MHz.  Many, if not
all, ET4000/W32 boards will surely behave in a funny way on a 50-MHz
bus.  You may have to use a wait state or two, but first try without
any.</li>
<li>Cold-boot your machine.  Do not run anything that messes with the
video hardware, including other X servers, before running
<code>XF86_SVGA</code>.</li>
<li>In case of an ET6000 card, try specifying chipset "et6000"
in the Device Section. The card normally auto-probes from the PCI bus,
but on some systems, another on-board VGA card, although disabled, may
cause the ET6000 server to want to use the other card.</li>
</ul>
</p>

<p>Note that some VESA standard mode timings may give problems on some monitors
(try increasing the horizontal sync pulse, i.e. the difference between
the middle two horizontal timing values, or try multiples of 16 or 32 for
all of the horizontal timing parameters).
<dl>
<dt><b>There is a video signal, but the screen doesn't sync.</b><dd><p>You are using a mode that your monitor cannot handle. If it is
a non-standard mode, maybe you need to tweak the timings a bit. If
it is a standard mode and frequency that your monitor should be able
to handle, try to find different timings for a similar mode and
frequency combination.</p>

<dt><b>Horizontal jitter at high dot clocks.</b><dd><p>This problem shows up especially when drawing operations such as
scrolling or blitting are in progress. There is currently no easy
fix for this, You can try the <code>"fast_dram"</code> option, or use a
lower dot clock. If that is not sufficient, the <code>"noaccel"</code>
option will almost always help (it leaves more bandwidth for the
RAMDAC). In most cases, this is caused by the video memory not being
able to provide pixel data to the RAMDAC fast enough, so it gets fed
with garbage.</p>

<dt><b>`Wavy' screen.</b><dd><p>Horizontal waving or jittering of the whole screen, continuously
(independent from drawing operations). You are probably using a dot
clock that is too high; it is also possible that there is
interference with a close MCLK. Try a lower dot clock (sometimes
even dropping it by 0.5 MHz may work). You can also try to tweak the
mode timings; try increasing the second horizontal value somewhat.
Here's a 65 MHz dot clock 1024x768 mode (about 60 Hz) that might
help:
<pre>
 "1024x768"     65      1024 1116 1228 1328     768  783  789  818
</pre>
</p>
<dt><b>Crash or hang after start-up (probably with a black screen).</b><dd><p>Try the <code>"noaccel"</code> option. Check that the BIOS settings are
OK; in particular, disable caching of 0xa0000-0xaffff. Disabling
hidden DRAM refresh may also help.</p>
<p>On Linux systems, if "APM" (power management) support is enabled in
the kernel, the server may start up in power-save mode or with a
black screen. Rebuild your kernel with APM support disabled.</p>
<dt><b>Crash, hang, or trash on the screen after a graphics operation.</b><dd><p>This may be related to a bug in one of the accelerated functions, or
a problem with the BitBLT engine. Try the <code>"noaccel"</code> option.
Also check the BIOS settings.</p>
<dt><b>`ACL: TIMEOUT' messages from the server.</b><dd><p>Same as for the above entry. However, on some systems, the problem
will not go away no matter what you do. It may be related to the
operating system you use (it has only been seen on Linux systems,
and even then it depends on the kernel versions). Sometimes,
choosing another MemBase may help.</p>
<dt><b>Occasional erroneous pixels in text, pixel dust when moving window-frame</b><dd><p>Probably related to MCLK setting that is too high (can happen with
linear addressing even though banked mode runs OK). Most (if not
all) ET6000 cards are sold with the MCLK slightly over clocked for
performance (the current norm is 90 or 92 MHz), which may cause
these problems. There is currently no fix for this. If the pixel
dust is only temporary (it disappears as soon as nothing moves on
the screen anymore), then memory bandwidth is probably the cause.
The only solution is to disable acceleration, or, if that doesn't
help, using a lower pixel clock.</p>
<dt><b>Textmode is not properly restored</b><dd><p>This has been reported on some configurations. Sometimes a Chipset
line will fix this. Normally you should be able to restore the
textmode font using a utility that sets it (<code>setfont</code>,
<code>runx</code>, <code>restorefont</code> on Linux).</p>
<dt><b>Mostly black or blue screen when using accelerated driver features</b><dd><p>If you are seeing a mostly black or blue screen, with only a few
icons (pixmaps) displayed, this section applies to you.</p>
<p>There can be several causes for this.</p>
<p>One is if the amount of memory is not detected (or specified) correctly. If the
server's autodetection mechanism detects too much memory,
accelerated features will not work. Define the amount of memory in
the <code>XF86Config</code> file. This seems to happen sometimes on some
2.25 MB ET6000 cards, where the server detects 2.5 MB instead (add
<code>videoram "2304"</code> in this particular case).</p>
<p>If that doesn't help, disabling acceleration (option
<code>"noaccel"</code>) is the only solution.</p>
<dt><b>Problems with DMA hardware (floppy, tape)</b><dd><p>On some systems, the accelerated server will interfere with other
hardware that uses ISA DMA. Most notably is the PC floppy controller
and sound cards. The floppy interface cannot cope with inordinately
long bus-holds, which may occur during large accelerated operations.
The Linux-ftape module for example (a floppy-tape driver) will
generate lots of "write error" messages when running a backup or
restore operation while the X-server is in use. These errors should
not be fatal, but that all depends on how well the operating system
handles these conditions. Linux seems to cope.</p>
<p>There are two possible solutions: disable acceleration using the
<code>"noaccel"</code> option, or disable PCI-retry (which is causing
the large bus delays) by removing the <code>"pci_retry"</code> option.
This will cause a very small slowdown of accelerated operations.</p>
<p>The <code>"pci_retry"</code> option applies not only to the PCI bus
systems, but has a similar effect on other busses.</p>
<dt><b>"Cannot read colourmap from VGA.  Will restore with default"</b><dd><p>If this error occurs, the server was unable to properly initialize
the RAMDAC, and tries to restore a default color map. On some
unsupported RAMDACs, this will have the adverse effect of removing
all color altogether, leaving you with a bunch of weird colors, or
with a completely black screen. If that happens, add the <code>ramdac
"normal"</code> statement to the Device section in your
<code>XF86Config</code> file. In most cases, this will solve the color
problem.</p>
<dt><b>Why does the server report my ModeLine with only half the pixel clock?</b><dd><p>For ET4000W32p cards at 8bpp, some modes using a clock over 75 MHz
(e.g. a 1152x910 mode with 95 MHz pixel clock) will produce the
following message in the Xserver output:</p>
<p>(--) SVGA: Mode "1152x910" will use pixel multiplexing</p>
<p>And later, when the accepted modelines are reported:</p>
<p>(**) SVGA: Mode "1152x910": mode clock =  47.500</p>
<p>This is normal, because with pixel multiplexing, only half the clock
is needed as two pixels are sent to the RAMDAC per clock pulse. </p>

</dl>

For other screen drawing related problems, try the <code>"noaccel"</code>
option.</p>

<p>If you are having driver-related problems that are not addressed by this
document, or if you have found bugs in accelerated functions, you can try
contacting the XFree86 team.</p>
<p>In fact, reports (success or failure) are very welcome, especially
on configurations that have not been tested. You can do this
via the BetaReport form (mail it to report@XFree86.org). You may want to
keep an eye on forthcoming beta releases at <i>www.xfree86.org</i>.</p>


 <HR NOSHADE>
<A HREF="tseng.html"><EM> Information for Tseng Chipset Users</EM></A>
 <b>:</b> <EM>Trouble shooting with the SVGA Tseng driver</EM><BR>
<b>Previous:</b> <A HREF="tseng14.html"><EM>Linear addressing and 16bpp/24bpp/32bpp modes </EM></A><BR>
<b>Next:</b> <A HREF="tseng16.html"><EM>Acknowledgments </EM></A>



</BODY>
</HTML>
