In most cases, when there are problems, error messages are shown in the console window, application windows, or log files.
This chapter describes how to look at log files to track down the errors and what the known problems are and how to resolve them. The following topics are covered:
OpenGL Vizserver uses the following log files:
If you have problems running OpenGL Vizserver, first look at the server and session log files and then the system log file. If by looking at the server log file you find out that the X server failed to start on your Silicon Graphics Prism or Onyx4 system, looking at its XFree86 log file can give you a hint as to why the X server failed.
The accounting files can also be useful in establishing a chronology of user events. The following subsections describe each type of log file.
The OpenGL Vizserver server manager writes its status messages in its server log file:
/var/vizserver/logs/vsserver.log
The server log contains the following entries:
Server mananger start/stop notice
Licenses that checked out/in
Clients logged in/out
Number of pipes found
Number of pipes used by XDM
Number of pipes marked for OpenGL Vizserver use
X server start notification
Session start success/failure
Error message from the server
Note: After each run, the server log is overwritten.
The OpenGL Vizserver session manager writes its status messages in its session log file:
/var/vizserver/logs/vssession.<username>.log
The <username> variable specifies the master user's login name for the session.
The session log contains the following entries:
Session manager start/stop notice
Session name, server display, and master username
Client join/leave
Compressor change
Spoiling change
Control passing change
Error messages from the session
Note: After each run, the session log is overwritten.
The OpenGL Vizserver server processes also write critical error messages in the system log file:
/var/adm/SYSLOG
The processes use the following tags for the system log entries:
| vsserver | Entry posted by the OpenGL Vizserver server manager | |
| vssession | Entry posted by the OpenGL Vizserver session manager |
If you are having problems while using the PAM authentication module with OpenGL Vizserver, the /var/adm/SYSLOG file might include relevant information about it. You should look for entries having module_name[pid] in them—for example, pam_rhosts_auth[2112]:, where the module used is pam_rhosts_auth.so and the PID of vsserver is 2112.
Since there are so many other processes on your system that write their messages to the /var/adm/SYSLOG file, look carefully at lines between user connects to the OpenGL Vizserver server and user disconnects from the OpenGL Vizserver server. Check that the session was started and exited normally and look at the messsages related to graphics processes between the user connect and user disconnect messages.
When the OpenGL Vizserver server host is a Silicon Graphics Prism or Onyx4 system, the X server that is used on the system is XFree86. When XFree86 is run, it generates a very detailed log file, /var/log/XFree86.x.log, where x is the X server's number (for example, if the X server is :32, the log file is /var/log/XFree86.32.log).
Based on the file set in the server configuration parameter Vizserver*BaseXF86Config (see “The /var/vizserver/config File” in Chapter 2), OpenGL Vizserver generates temporary XFree86 configuration files to be used by the X servers it starts. In the XFree86 log file, you can also look for the line starting with the following string:
Using config file: |
This line will identify which XFree86 configuration file was used when starting this X server.
Something might be incorrect or inadequate for OpenGL Vizserver's needs in this file especially if you have customized this file. If you have customized the file, you might resolve the issue by creating a new default XFree86 configuration file using /etc/X11/gen-XF86Config and using it as the base XFree86 configuration file for OpenGL Vizserver. Do not forget to back up your customized XFree86 configuration file.
Looking at accounting log files can be useful to determine actual time, user, and session type when an error happened.
OpenGL Vizserver records a client login and logout and a session start and stop into an accounting log file (usually /var/vizserver/acct). This file can be viewed using vsacct. See the vsacct(1m) man page for more details.
$ vsacct /var/vizserver/acct |
Each OpenGL Vizserver session is also logged to the wtmpx database of the system (typically /var/adm/wtmpx), for use with utmpx-based utilities, such as last.
OpenGL Vizserver sessions appear in the file as the device vsspipe#, where pipe# is the graphics pipe number used by a session. If the session uses more than one graphics pipe, a line per each graphics pipe is used.
Since the last command also shows other records in /var/adm/wtmpx, use it with the grep command to extract the information related only to OpenGL Vizserver sessions. (Actual results on your system will be different.)
$ last | grep vss yolee vss1 130.62.55.27 Tue Aug 13 16:39 - 16:49 (00:09) guest vss0 130.62.53.103 Tue Aug 13 16:33 - 16:43 (00:10) guest vss0 130.62.53.103 Tue Aug 13 15:27 - 15:56 (00:28) root vss1 130.62.55.66 Mon Aug 12 12:46 - 13:07 (00:20) yolee vss0 130.62.55.27 Mon Aug 12 13:42 - 13:53 (00:10) yolee vss2 130.62.55.27 Mon Aug 12 13:42 - 13:53 (00:10) root vss0 130.62.52.83 Mon Aug 12 12:46 - 13:07 (00:20) |
See the last(1) and utmpx(4) man pages for more details.
If OpenGL Vizserver cannot use all of the available graphics pipes in your system and your system's SYSLOG shows something similar to the following, it is a SHMIQ problem.
Dec 4 15:46:36 5B:ontario vizserver: Failed to open shmiq control device.: No such file or directory Dec 4 15:46:36 3D:ontario Xsgi35[17597]: Dec 4 15:46:36 5B:ontario vizserver: Xsgi35[17597]: Dec 4 15:46:36 2D:ontario Xsgi35[17597]: Fatal server error: Dec 4 15:46:36 5B:ontario vizserver: Xsgi35[17597]: Fatal server error: Dec 4 15:46:36 2D:ontario Xsgi35[17597]: Error Starting SHMIQ I/O! Dec 4 15:46:36 5B:ontario vizserver: Xsgi35[17597]: Error Starting SHMIQ I/O! Dec 4 15:46:36 2D:ontario Xsgi35[17597]: Dec 4 15:46:36 5B:ontario vizserver: Xsgi35[17597]: |
A SHMIQ (pronounced shmick) is a fast way of receiving input device events by eliminating the operating system overhead to receive data from input devices. Instead of reading the input devices through UNIX file descriptors, the kernel deposits input events directly into a region of the X server's address space, organized as a ring buffer.
Associated with the shmiq driver, a character device called qcntl is needed for the X server (Xsgi). The qcntl device allows Xsgi to process character input from the SHMIQ driver. To use multiple X servers in a system, you need at least the same number of /dev/qcntl nodes as that of Xsgi to be used. For example, if your system has only qcntl0 and qcntl1 nodes, you can have at most two Xsgi servers running on your system.
As of IRIX 6.5, the systems with graphics capabilities are preconfigured with 9 SHMIQ drivers, 2 input directories (/dev/input0, /dev/input1), and 8 qcntl nodes (/dev/qcntl0, /dev/qcntl1, ..., /dev/qcntl7). Therefore, usually, you do not have to worry about these values. However, the preconfigured values are sometimes wiped out when the system is rebooted.
Check how many qcntl nodes are in the /dev directory and create an additional number of qcntl character devices by using mknod as follows. Create one qcntl node for each pipe in your configuration.
# mknod qcntl2 c 55 2 # mknod qcntl3 c 55 3 ... # mknod qcntl7 c 55 7 |
The default /var/sysgen/master.d/shmiq file defines NSHMIQS as 9, so you can have a maximum of 8 qcntl nodes.
| Note: If your system has 16 pipes, you can change NSHMIQS to 17 and make 16 qcntl nodes. In that case, you need to create a new kernel (autoconfig -fv) because you modified the /var/sysgen/master.d/shmiq file. |
As a normal procedure, after starting a session, the OpenGL Vizserver Session Control window is shown first and then the OpenGL Vizserver Console window later. However, if the OpenGL Vizserver Console window is not shown after the session control window has appeared, make sure that your Windows 2000 system has service pack 2 or later installed.
After running an OpenGL Vizserver sessions many times continuously, if the performance of OpenGL Vizserver shows the slowdown considerably, check the shared memory in an OpenGL Vizserver server system. This can be done by using an ipcs command.
Usually, an OpenGL Vizserver session removes the shared memory for its use when the session is exited. However, there might be cases where the shared memory is not deleted when the session or applications do not exit normally. Then it is stacked up and occupied as a long list of active shared memory. This might cause the problem in OpenGL Vizserver performance. The shared memory can be removed by using an ipcrm command. See the ipcs(1) and ipcrm(1) man pages for more details.
An OpenGL Vizserver session uses a message queue and a shared memory segment with keys 0x12340000 to 0x1234FFFF. These resources are necessary for the session and applications to communicate. Ensure that they are not deleted while the session is running.
In an OpenGL Vizserver client using a window manager other than 4Dwm, the application windows running under the OpenGL Vizserver session accept user inputs, such as key press/release and mouse button press/release, which are only conformant to 4Dwm.
Sometimes an application window is updated on an expose event. When spoiling is on, some of the updates are missed. So it appears as if the window on the client side never got updated. Try to turn spoiling off and you will see the updates. The updated rates are also dependent on your system configuration and network bandwidth.
When an application is started by a user who does not have the privilege to run and the user did not start the OpenGL Vizserver session, the application is masked as a cross-hatch pattern image.
For example, an OpenGL Vizserver session is started by a guest user and the user is switched to root later in the OpenGL Vizserver console window. Then if vsconfig is issued, the application is masked as a cross-hatch pattern image in the console window.
In addition, in a local collaborative session, when the master's other application windows overlap the application windows running from OpenGL Vizserver, nonmaster clients in the session see the cross-hatch pattern in their OpenGL Vizserver application windows.
For example, if the OpenGL Vizserver console window or application windows are covered by other windows on the local master's monitor, the OpenGL Vizserver application window of nonmaster clients displays the overlapped region as a cross-hatch pattern image. This is an expected behavior and it was implemented as a security feature to prevent the local master's private contents from being transmitted to the other clients.
OpenGL is not inheritently frame-based. Therefore, OpenGL Vizserver uses glFlush(), glFinish(), or glXSwapBuffers() calls to trigger a framebuffer readback.
Applications that do the back-to-front rendering and do not make these calls often might get less than optimal frame updates.
As mentioned in the section “Dynamic Pipe Allocation” in Chapter 2, OpenGL Vizserver uses *.vizserver scripts and the xdm-config configuration file in the /var/X11/xdm directory by default.
When using a customized XDM with a dynamic pipe allocation scheme, you must inform OpenGL Vizserver server of its location and the configuration files related to the XDM. This involves modifying some of the scripts and the XDM configuration path (XDM Config File) in vsconfig. Otherwise, OpenGL Vizserver might have problems allocating pipes even though there are available pipes on the server.