<!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 ``cirrus'' driver</TITLE>
</HEAD>
<BODY BGCOLOR="#efefef" TEXT="black" LINK="blue" VLINK="#551A8B" ALINK="red">

<A HREF="cirrus.html"><EM> Information for Cirrus Chipset Users</EM></A>
 <b>:</b> <EM>Trouble shooting with the ``cirrus'' driver</EM><BR>
<b>Previous:</b> <A HREF="cirrus6.html"><EM>The ``cl64xx'' Driver</EM></A><BR>
<b>Next:</b> <A HREF="cirrus8.html"><EM>Tested Configurations </EM></A>


<HR NOSHADE>
  <H2><A NAME="7"></A>7. Trouble shooting with the ``cirrus'' driver</H2>
<p>First of all, make sure that the default modes selected from your
<code>XF86Config</code>
is 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>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 especially when drawing operations such as
scrolling are in progress.
If you're using a 542x/3x/46/6x/754x, try the 
<code>"fifo_conservative"</code> 
option. Failing that, 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 or <code>"no_bitblt"</code> will
probably help.  When using a 546x, option
<code>"fifo_aggressive"</code> can also be tried.</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. 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>

If you are using programmable clocks with Clockchip <code>"cirrus"</code>,
try disabling it and using the default set of clocks.</p>
<dt><b>Crash or hang after start-up (probably with a black screen).</b><dd><p>Try the <code>"noaccel"</code> option. If that works,
try Option <code>"no_bitblt"</code> for
somewhat better performance. Check that the BIOS settings are OK;
in particular, disable caching of 0xa0000-0xaffff. Disabling hidden
DRAM refresh may also help.</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,
or the <code>"no_bitblt"</code> option. Also check the BIOS settings.</p>
<dt><b>`Blitter timeout' messages from the server.</b><dd><p>Same as for the above entry.</p>
<dt><b>Screen is `wrapped' vertically. (542x/3x/46)</b><dd><p>This indicates a DRAM configuration problem. If your card has two
megabytes of memory, try the <code>"no_2mb_banksel"</code> option, or use
<code>videoram "1024"</code> if you only use 1 Mbyte for the virtual
screen.</p>
<dt><b>Corrupted text in terminal window.</b><dd><p>This has been reported on non-standard video implementations.
Use the <code>"no_bitblt"</code> option.</p>
<dt><b>Streaks or hangs with laptop chipset</b><dd><p>This can happen if the dot clock is high enough to leave very
little bandwidth for drawing (e.g. 40 MHz on a 512K card), and
(5422-style) acceleration is used.</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).</p>
<dt><b>Chipset is not detected.</b><dd><p>Try forcing the chipset to a type that is most similar to what
you have.</p>
<dt><b>Incorrect little lines (mostly white) appear occasionally</b><dd><p>This may be related to a problem with system-to-video-memory BitBLT
operations. Try the <code>"no_imageblt"</code> option if it annoys you.</p>
<dt><b>Textmode is not properly restored</b><dd><p>This has been reported on some configurations. In XFree86 3.1
the SVGA server probe would corrupt a register on the 543x,
requiring a Chipset line. 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>Erratic system behaviour at very high dot clocks</b><dd><p>It is possible that high dot clocks on the video card interfere with
other components in the system (e.g. disk I/O), because of a bad
card and/or motherboard design. It has been observed on some PCI
5428-based cards (which are very rare, since the 5428 chip doesn't
support PCI).</p>
<dt><b>No mouse cursor, or cursor appears twice on screen</b><dd><p>With high dot clocks, the graphics card's hardware cursor
doesn't operate correctly.  Try option <code>"sw_cursor"</code> or
use a lower screen refresh.</p>

<dt><b>Random/garbage pixels on far right or bottom of screen (546x)</b><dd><p>This problem is usually associated with using a virtual
screen size larger than the screen display size.  The
garbage pixels are unused portions of the frame buffer
that result from padding each scanline to an integral
number of memory tiles.  To eliminate the extra pixels,
use a screen display mode whose pixel width is evenly
divisible by 128 / bits per pixel.</p>

<dt><b>Screen is wrapped horizontally on right side (546x)</b><dd><p>Same as above entry.</p>

<dt><b>The screen is initially displayed correctly, but then turns all
white. (546x)</b><dd><p>This problem usually happens at high bit depths and while
the screen is changing rapidly (catting a long file or
dragging a large window around).  The RamBus memory is
being overdriven.  Use Option <code>"med_dram"</code>, or, if
the problem persists, Option <code>"slow_dram"</code>.</p>

</dl>

For other screen drawing related problems, try the <code>"noaccel"</code>
option (if <code>"no_bitblt"</code> doesn't help).</p>
<p>If 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 (the current driver maintainer, Corin Anderson,
can be reached at <i>corina@the4cs.com</i>), or post in the
Usenet newsgroup "<i>comp.windows.x.i386unix</i>".</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 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="cirrus.html"><EM> Information for Cirrus Chipset Users</EM></A>
 <b>:</b> <EM>Trouble shooting with the ``cirrus'' driver</EM><BR>
<b>Previous:</b> <A HREF="cirrus6.html"><EM>The ``cl64xx'' Driver</EM></A><BR>
<b>Next:</b> <A HREF="cirrus8.html"><EM>Tested Configurations </EM></A>



</BODY>
</HTML>
