7 Trouble shooting with the ``cirrus'' driver

Contents of this section

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

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.

Sparklies/streaks at high dot clocks.

You can try the "fast_dram" option, or use a lower dot clock. If it happens when moving something on the screen, try the "fifo_conservative" option. If that is not sufficient, the "noaccel" option or "no_bitblt" will probably help.

`Wavy' screen, horizontal jitter.

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.

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 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 doesn't support PCI).

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 hhanemaa@cs.ruu.nl), or post in the Usenet newsgroup "comp.windows.x.i386unix".

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter