Previous Next Contents

12. FAQ: Troubleshooting?

12.1 Has this hardware been tested?

See hardware requirements above, there is a list of hardware that has been found to work.

12.2 Failed to change I/O privilege?

You need to be root, or setuid your application to run a Glide based application. For DMA, the driver accesses /dev/mem, which is not writeable for anybody but root, with good reasons. See the README in the Glide distribution for Linux.

12.3 Does it work without root privilege?

There are compelling case where the setuid requirement is a problem, obviously. There are currently solutions in preparation, which require changes to the library internals itself.

12.4 Displayed images looks awful (single screen)?

If you are using the analog pass through configuration, the common SVGA or X11 display might look pretty bad. You could try to get a better connector cable than the one provided with the accelerator board (the ones delivered with the Diamond Monster 3D are reportedly worse then the one accompanying the Orchid Righteous 3D), but up to a degree there will inevitably be signal loss with an additional transmission added.

If the 640x480 full screen image created by the accelerator board does look awful, this might indicate a real hardware problem. You will have to contact the board manufacturer, not 3Dfx for details, as the quality of the video signal has nothing to do with the accelerator - the board manufacturer chooses the RAMDAC, output drivers, and other components responsible.

12.5 The last frame is still there (single or dual screen)?

You terminated your application with Ctrl-C, or it did not exit normally. The accelerator board will dutifully provide the current content of the framebuffer as a video signal unless told otherwise.

12.6 Powersave kicks in (dual screen)?

When you application terminates in dual screen setups, the accelerator board does not provide video output any longer. Thus powersave kicks each time. To avoid this, use


12.7 My machine seem to lock (X11, single screen)?

If you are running X when calling a Glide application, you probably moved the mouse out of the window, and the keyboard inputs do not reach the application anymore.

If you application is supposed to run concurrently with X11, it is recommend to expose a full screen window, or use the XGrabPointer and XGrabServer functions to redirect all inputs to the application while the X server cannot access the display. Note that grabbing all input with XGrabPointer and XGrabServer does not qualify as well-behaved application, and that your program might block the entire system.

If you experience this problem without running X, be sure that there is no hardware conflict (see below).

12.8 My machine locks (single or dual screen)?

If the system definitely does not respond to any inputs (you are running two displays and know about the loss of focus), you might experience a more or less subtle hardware conflict. See installation troubleshooting section for details.

If there is no obvious address conflict, there might still be other problems (below). If you are writing your own code the most common reason for locking is that you didn't snap your vertices. See the section on snapping in the Glide documentation.

12.9 My machine locks (used with S3 VGA board)?

It is possible you have a problem with memory region overlap specific to S3. There is some info and a patch to the so-called S3 problem in the 3Dfx web site, but these apply to Windows only. To my understanding, the cause of the problem is that some S3 boards (older revisions of Diamond Stealth S3 968) reserve more memory space than actually used, thus the Voodoo Graphics (tm) has to be mapped to a different location. However, this has not been reported as a problem with Linux, and might be Windows-specific.

12.10 No address conflict, but locks anyway?

If you happen to use a motherboard with non-standard or incomplete PCI support, you could try to shuffle the boards a bit. I am running an ASUS TP4XE that has that non-standard modified "Media Slot", i.e. PCI slot4 with additional connector for ASUS-manufactured SCSI/Sound combo boards, and I experienced severe problems while running a Diamond Monster 3D in that slot. The system operates flawlessly since I put the board in one of the regular slots.

12.11 Compile/link error: grSstWinOpen()?

As Linux Glide will be version 2.4, this error should not occur. This function was not available in Glide and thus Linux Glide 2.2;; the latter has never been released to the public.

12.12 Compile/link error: grSstOpen()?

Your application's source is based on Glide 2.2, and this function was removed in Glide 2.3;. It is not available anymore and so may not be used with Linux Glide 2.4. Modify your application to use the function grSstWinOpen instead.

As the Linux Glide integration with Mesa was based on Glide 2.2 originally, earlier versions of Mesa might produce compile time errors. The Mesa-2.3b3 release has been patched to be used with Linux Glide 2.3.1; make sure to get both the distribution and the patches, or, preferably, a later revision of Mesa.

12.13 Cannot open shared object file?

test25: error in loading shared libraries cannot open shared object file: No such file or directory

If, for whatever reasons, you have a binary lying around compiled for a different revision of Linux Glide, or if there is an inconsistency in your ldconfig setup, the program will not find the shared library. Check the name (e.g. and make sure that the proper flags are used when compiling and linking - e.g. -lglide might not work with the default installation.

Note that the naming of Linux Glide revisions follows the conventions used in the 3Dfx Windows distribution, not the conventions common for Linux.

12.14 Mesa compilation problems

Be sure to set USE_GLIDE_FULLSCREEN in fxmesa.h. Check whether the linkage options (e.g. -lglide) match the name of the Linux Glide library installed (e.g. -lglide2x instead). Be sure to use the patches to Mesa-2.3b3 or a later release, as all Mesa releases up to 2.3b3 were based on Linux Glide 2.2. See above.

12.15 Mesa runs, but does not access the board?

Be sure that you recompiled all the libraries (including the toolkits the demo programs use - remember that GLUT does not yet support Voodoo Graphics (tm)), and that you removed the older libraries, run ldconfig, and/or set your LD_LIBRARY_PATH properly. Mesa supports several drivers in parallel (you could use X11 SHM, off screen rendering, and Mesa Voodoo at the same time), and you might have to create and switch contexts explicitely (see MakeCurrent function) if the Voodoo Graphics (tm) isn't chosen by default.

Previous Next Contents