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. When using a 546x, option "fifo_aggressive" can also be tried.

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

No mouse cursor, or cursor appears twice on screen

With high dot clocks, the graphics card's hardware cursor doesn't operate correctly. Try option "sw_cursor" or use a lower screen refresh.

Random/garbage pixels on far right or bottom of screen (546x)

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.

Screen is wrapped horizontally on right side (546x)

Same as above entry.

The screen is initially displayed correctly, but then turns all white. (546x)

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 "med_dram", or, if the problem persists, Option "slow_dram".

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 corina@the4cs.com), 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.