Trouble shooting with the ``cirrus'' driver

Information for Cirrus Chipset Users : Trouble shooting with the ``cirrus'' driver
Previous: The ``cl64xx'' Driver
Next: Tested Configurations

## 7. Trouble shooting with the ``cirrus'' driver

First of all, make sure that the default modes selected from your `XF86Config` 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.

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).

There is a video signal, but the screen doesn't sync.

  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.

Horizontal jitter at high dot clocks.

  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 `"fifo_conservative"` option. Failing that, you can try the `"fast_dram"` option, or use a lower dot clock. If that is not sufficient, the `"noaccel"` option or `"no_bitblt"` will probably help.

`Wavy' screen.

  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:

       "1024x768"     65      1024 1116 1228 1328     768  783  789  818

  If you are using programmable clocks with Clockchip `"cirrus"`, try disabling it and using the default set of clocks.
Crash or hang after start-up (probably with a black screen).

  Try the `"noaccel"` option. If that works, try Option `"no_bitblt"` 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.

Crash, hang, or trash on the screen after a graphics operation.

  This may be related to a bug in one of the accelerated functions, or a problem with the BitBLT engine. Try the `"noaccel"` option, or the `"no_bitblt"` option. Also check the BIOS settings.

`Blitter timeout' messages from the server.

  Same as for the above entry.

Screen is `wrapped' vertically. (542x/3x/46)

  This indicates a DRAM configuration problem. If your card has two megabytes of memory, try the `"no_2mb_banksel"` option, or use `videoram "1024"` if you only use 1 Mbyte for the virtual screen.

Corrupted text in terminal window.

  This has been reported on non-standard video implementations. Use the `"no_bitblt"` option.

Streaks or hangs with laptop chipset

  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.

Occasional erroneous pixels in text, pixel dust when moving window-frame

  Probably related to MCLK setting that is too high (can happen with linear addressing even though banked mode runs OK).

Chipset is not detected.

  Try forcing the chipset to a type that is most similar to what you have.

Incorrect little lines (mostly white) appear occasionally

  This may be related to a problem with system-to-video-memory BitBLT operations. Try the `"no_imageblt"` option if it annoys you.

Textmode is not properly restored

  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 (`setfont`, `runx`, `restorefont` on Linux).

Erratic system behaviour at very high dot clocks

  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).

For other screen drawing related problems, try the `"noaccel"` option (if `"no_bitblt"` doesn't help).

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 can be reached at H.Hanemaayer@inter.nl.net), or post in the Usenet newsgroup "comp.windows.x.i386unix".

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 www.xfree86.org.

Information for Cirrus Chipset Users : Trouble shooting with the ``cirrus'' driver
Previous: The ``cl64xx'' Driver
Next: Tested Configurations