xref: /minix3/external/bsd/top/dist/FAQ (revision b89261ba018da33f0bd8cd05f5a1fe9e7a9c837b)
1*b89261baSDavid van Moolenbroek                                        TOP
2*b89261baSDavid van Moolenbroek                                  Version 3.8beta1
3*b89261baSDavid van Moolenbroek
4*b89261baSDavid van Moolenbroek                                  William LeFebvre
5*b89261baSDavid van Moolenbroek                             with much help from others
6*b89261baSDavid van Moolenbroek
7*b89261baSDavid van Moolenbroek                    Frequently Asked Questions and their Answers
8*b89261baSDavid van Moolenbroek
9*b89261baSDavid van Moolenbroek
10*b89261baSDavid van Moolenbroek
11*b89261baSDavid van Moolenbroek     GENERAL
12*b89261baSDavid van Moolenbroek
13*b89261baSDavid van Moolenbroek 1.  What is top?
14*b89261baSDavid van Moolenbroek
15*b89261baSDavid van Moolenbroek     Top provies the user with a regularly updated display showing
16*b89261baSDavid van Moolenbroek     information about the system and its top cpu-using processes. Think
17*b89261baSDavid van Moolenbroek     of it as a full-screen "ps" output that gets updated at regular
18*b89261baSDavid van Moolenbroek     intervals.
19*b89261baSDavid van Moolenbroek
20*b89261baSDavid van Moolenbroek 2.  Where do I get the latest version of top?
21*b89261baSDavid van Moolenbroek
22*b89261baSDavid van Moolenbroek     The official site for top is "ftp.unixtop.org" in the directory
23*b89261baSDavid van Moolenbroek     "/pub/top". Top is also a SourceForge project, and the most recent
24*b89261baSDavid van Moolenbroek     releases are available on any of the SourceForge mirrors. The
25*b89261baSDavid van Moolenbroek     SourceForge project page is at
26*b89261baSDavid van Moolenbroek     http://sourceforge.net/projects/unixtop.
27*b89261baSDavid van Moolenbroek
28*b89261baSDavid van Moolenbroek 3.  Is there a web page for top?
29*b89261baSDavid van Moolenbroek
30*b89261baSDavid van Moolenbroek     Yes. Point your browser at http://www.unixtop.org. It includes all
31*b89261baSDavid van Moolenbroek     documentation, a nice interactive display which describes the various
32*b89261baSDavid van Moolenbroek     components of the output of top, web-based retrieval of the package,
33*b89261baSDavid van Moolenbroek     year 2000 information, and other neat stuff.
34*b89261baSDavid van Moolenbroek
35*b89261baSDavid van Moolenbroek 4.  Is there a mailing list or on-line bulletin board for top?
36*b89261baSDavid van Moolenbroek
37*b89261baSDavid van Moolenbroek     There is a mailing list used for general announcements regarding top,
38*b89261baSDavid van Moolenbroek     including new releases. This mailing list is available to sourceforge
39*b89261baSDavid van Moolenbroek     members and can be accessed from the unixtop sourceforge project
40*b89261baSDavid van Moolenbroek     page. Visit SourceForge and search for the project "unixtop", then
41*b89261baSDavid van Moolenbroek     click on "mailing lists". There are also on-line forums available
42*b89261baSDavid van Moolenbroek     through SourceForge where members can post questions and comments.
43*b89261baSDavid van Moolenbroek
44*b89261baSDavid van Moolenbroek 5.  What about Year 2000 compliance?
45*b89261baSDavid van Moolenbroek
46*b89261baSDavid van Moolenbroek     Top did not experience any problems with the transition to the year
47*b89261baSDavid van Moolenbroek     2000. A full statement concerning top and the year 2000 can be found
48*b89261baSDavid van Moolenbroek     in the file "Y2K" included with the distribution.
49*b89261baSDavid van Moolenbroek
50*b89261baSDavid van Moolenbroek 6.  Will there be another major release of top? Will there be a top
51*b89261baSDavid van Moolenbroek     version 4?
52*b89261baSDavid van Moolenbroek
53*b89261baSDavid van Moolenbroek     I have some great ideas for the next major release of top, and I very
54*b89261baSDavid van Moolenbroek     much want to make those ideas a reality. What I don't have much of
55*b89261baSDavid van Moolenbroek     these days is free time. But I will keep poking at it and I hope to
56*b89261baSDavid van Moolenbroek     have top version 4.0 ready by the fall of 2006.
57*b89261baSDavid van Moolenbroek
58*b89261baSDavid van Moolenbroek 7.  Does top really support multi-processor systems?
59*b89261baSDavid van Moolenbroek
60*b89261baSDavid van Moolenbroek     On platforms that support multiple processors, top is able to detect
61*b89261baSDavid van Moolenbroek     and correctly summarize the information about those processors. What
62*b89261baSDavid van Moolenbroek     top does not do is break down the cpu states summary (the third line
63*b89261baSDavid van Moolenbroek     of the display) by cpu. Instead it collects the cpu state information
64*b89261baSDavid van Moolenbroek     from all processors and combines them in to a single line. Some
65*b89261baSDavid van Moolenbroek     vendors  include a modified version of top that presents this
66*b89261baSDavid van Moolenbroek     information for each cpu. Top 3.7 may have this functionality but it
67*b89261baSDavid van Moolenbroek     is not present in the standard top 3.6 release.
68*b89261baSDavid van Moolenbroek
69*b89261baSDavid van Moolenbroek 8.  Is top under CVS control? Can I access the sources via SourceForge
70*b89261baSDavid van Moolenbroek     CVS or Subversion?
71*b89261baSDavid van Moolenbroek
72*b89261baSDavid van Moolenbroek     I maintain top using subversion, not CVS. Although I utilize my own
73*b89261baSDavid van Moolenbroek     private subversion repository, it is regularly mirrored in to the
74*b89261baSDavid van Moolenbroek     SourceForge Subversion repository. You can access the SourceForge
75*b89261baSDavid van Moolenbroek     repository here: https://svn.unixtop.org/unixtop/top-3.
76*b89261baSDavid van Moolenbroek
77*b89261baSDavid van Moolenbroek
78*b89261baSDavid van Moolenbroek     COMPILING
79*b89261baSDavid van Moolenbroek
80*b89261baSDavid van Moolenbroek 9.  We just upgraded our operating system to a new version and top broke.
81*b89261baSDavid van Moolenbroek     What should we do?
82*b89261baSDavid van Moolenbroek
83*b89261baSDavid van Moolenbroek     Recompile it. Top is very sensitive to changes in internal kernel
84*b89261baSDavid van Moolenbroek     data structures. It is not uncommon for a new version of the
85*b89261baSDavid van Moolenbroek     operating system to include changes to kernel data structures.
86*b89261baSDavid van Moolenbroek
87*b89261baSDavid van Moolenbroek
88*b89261baSDavid van Moolenbroek     RUNNING
89*b89261baSDavid van Moolenbroek
90*b89261baSDavid van Moolenbroek10.  I just finished compiling top and it works fine for root, but when I
91*b89261baSDavid van Moolenbroek     try to run it as a regular user it either complains about files it
92*b89261baSDavid van Moolenbroek     can't open or it doesn't display all the information it should. Did I
93*b89261baSDavid van Moolenbroek     do something wrong?
94*b89261baSDavid van Moolenbroek
95*b89261baSDavid van Moolenbroek     Well, you're just not done. On many operating systems today, access
96*b89261baSDavid van Moolenbroek     to many of the kernel memory devices and other system files is
97*b89261baSDavid van Moolenbroek     restricted to either root or a particular group. The configure script
98*b89261baSDavid van Moolenbroek     figures this out (usually) and makes sure that the "install" rule in
99*b89261baSDavid van Moolenbroek     the Makefile will install top so that anyone can run it successfully.
100*b89261baSDavid van Moolenbroek     However, you have to *install* it first. Do this with the command
101*b89261baSDavid van Moolenbroek     "make install".
102*b89261baSDavid van Moolenbroek
103*b89261baSDavid van Moolenbroek11.  Top is (not) displaying idle processes and I don't (do) want it to.
104*b89261baSDavid van Moolenbroek
105*b89261baSDavid van Moolenbroek     This default has only changed about a dozen times, and I finally got
106*b89261baSDavid van Moolenbroek     tired of people whining about it. Go read the manual page for the
107*b89261baSDavid van Moolenbroek     current version and pay special attention to the description of the
108*b89261baSDavid van Moolenbroek     "TOP" environment variable.
109*b89261baSDavid van Moolenbroek
110*b89261baSDavid van Moolenbroek12.  We have so much memory in our machine that the memory status display
111*b89261baSDavid van Moolenbroek     (the fourth line) ends up being longer than 80 characters. This
112*b89261baSDavid van Moolenbroek     completely messes up top's output. Is there a patch?
113*b89261baSDavid van Moolenbroek
114*b89261baSDavid van Moolenbroek     Most modules have been changed to use new memory formatting functions
115*b89261baSDavid van Moolenbroek     which will display large values in terms of megabytes instead of
116*b89261baSDavid van Moolenbroek     kilobytes. This should fix all occurences of this problem. Also note
117*b89261baSDavid van Moolenbroek     that newer versions of top can use columns beyond 79, and understand
118*b89261baSDavid van Moolenbroek     window resizes. So you can always make your window wider.
119*b89261baSDavid van Moolenbroek
120*b89261baSDavid van Moolenbroek13.  I tried to compile top with gcc and it doesn't work. I get
121*b89261baSDavid van Moolenbroek     compilation errors in the include files, or I get an executable that
122*b89261baSDavid van Moolenbroek     dumps core, or top displays incorrect numbers in some of the
123*b89261baSDavid van Moolenbroek     displays. What's wrong?
124*b89261baSDavid van Moolenbroek
125*b89261baSDavid van Moolenbroek     Gnu CC likes very much to use its own include files. Not being a gcc
126*b89261baSDavid van Moolenbroek     expert, I can't explain why it does this. But I can tell you that if
127*b89261baSDavid van Moolenbroek     you upgrade your operating system (say from Solaris 2.6 to Solaris
128*b89261baSDavid van Moolenbroek     2.7) after installing gcc, then the include files that gcc uses will
129*b89261baSDavid van Moolenbroek     be incorrect, especially those found in the "sys" directory. Your
130*b89261baSDavid van Moolenbroek     choices are: (1) rebuild and reinstall the "standard" include files
131*b89261baSDavid van Moolenbroek     for gcc (look for scripts in the distribution called "fixincludes"
132*b89261baSDavid van Moolenbroek     and "fixinc.svr4"), (2) compile machine.c with
133*b89261baSDavid van Moolenbroek     "CFLAGS=-I/usr/include" then make the rest of the object files
134*b89261baSDavid van Moolenbroek     normally, or (3) use a different compiler.
135*b89261baSDavid van Moolenbroek
136*b89261baSDavid van Moolenbroek14.  The cpu state percentages are all wrong, indicating that my machine
137*b89261baSDavid van Moolenbroek     is using 95% system time when it is clearly idle. What's wrong?
138*b89261baSDavid van Moolenbroek
139*b89261baSDavid van Moolenbroek     This can happen if you compiled with gcc using the wrong include
140*b89261baSDavid van Moolenbroek     files. See the previous question.
141*b89261baSDavid van Moolenbroek
142*b89261baSDavid van Moolenbroek
143*b89261baSDavid van Moolenbroek     FREEBSD PROBLEMS
144*b89261baSDavid van Moolenbroek
145*b89261baSDavid van Moolenbroek15.  This version of top does not show individual threads with the "t" or
146*b89261baSDavid van Moolenbroek     "H" commands. Instead it says "command not available." Why?
147*b89261baSDavid van Moolenbroek
148*b89261baSDavid van Moolenbroek     Previous versions of top attempted to support the display of
149*b89261baSDavid van Moolenbroek     individual threads under FreeBSD through the use of the "t" command.
150*b89261baSDavid van Moolenbroek     However,  the FreeBSD kernel does not supply sufficient or correct
151*b89261baSDavid van Moolenbroek     information on the individual threads within a process. So the data
152*b89261baSDavid van Moolenbroek     that was being displayed was incorrect and misleading. Therefore, top
153*b89261baSDavid van Moolenbroek     version 3.8 disables the use of this command to prevent the display
154*b89261baSDavid van Moolenbroek     of incorrect information. FreeBSD 8.0 will correctly report
155*b89261baSDavid van Moolenbroek     per-thread information and top version 3.8 supports the use of the
156*b89261baSDavid van Moolenbroek     "t" command for version 8.0.
157*b89261baSDavid van Moolenbroek
158*b89261baSDavid van Moolenbroek16.  The "f" command (to display full command lines for the processes)
159*b89261baSDavid van Moolenbroek     does not work and instead says "command not available". Why?
160*b89261baSDavid van Moolenbroek
161*b89261baSDavid van Moolenbroek     The current version of top is able to use sysctl to retrieve almost
162*b89261baSDavid van Moolenbroek     all of the information it needs without having to open /dev/kmem. The
163*b89261baSDavid van Moolenbroek     one piece of information not available via sysctl is the full command
164*b89261baSDavid van Moolenbroek     line of each argument. If you run top as a regular user and it cannot
165*b89261baSDavid van Moolenbroek     open /dev/kmem (in other words, it is not installed set-gid to the
166*b89261baSDavid van Moolenbroek     kmem group) then it will disable the "f" command. Make sure the top
167*b89261baSDavid van Moolenbroek     binary is installed with a group ownership of "kmem" and with the
168*b89261baSDavid van Moolenbroek     set-gid bit on if you want the "f" command to work properly.
169*b89261baSDavid van Moolenbroek
170*b89261baSDavid van Moolenbroek
171*b89261baSDavid van Moolenbroek     MACOSX PROBLEMS
172*b89261baSDavid van Moolenbroek
173*b89261baSDavid van Moolenbroek17.  I tried to configure top on my Mac OSX system and I got an error
174*b89261baSDavid van Moolenbroek     claiming "macosx not supported". What up?
175*b89261baSDavid van Moolenbroek
176*b89261baSDavid van Moolenbroek     Since I don't have full time root access to a Mac OSX system I cannot
177*b89261baSDavid van Moolenbroek     provide effective support for the platform. MacOSX uses Mach, and it
178*b89261baSDavid van Moolenbroek     is very difficult to extract accurate system and process information
179*b89261baSDavid van Moolenbroek     from the system. It takes a lot of trial and error, along with root
180*b89261baSDavid van Moolenbroek     access. I have included the most up-to-date version of the macosx
181*b89261baSDavid van Moolenbroek     module in the distribution, but I do not claim that it works. If you
182*b89261baSDavid van Moolenbroek     want to try to use it, you can configure with "./configure
183*b89261baSDavid van Moolenbroek     --with-module=macosx".
184*b89261baSDavid van Moolenbroek
185*b89261baSDavid van Moolenbroek
186*b89261baSDavid van Moolenbroek     SUNOS PROBLEMS
187*b89261baSDavid van Moolenbroek
188*b89261baSDavid van Moolenbroek18.  I tried compiling top under SunOS version 4.1.x and it got compile
189*b89261baSDavid van Moolenbroek     time errors or run time errors. Is there a patch?
190*b89261baSDavid van Moolenbroek
191*b89261baSDavid van Moolenbroek     If you try compiling top in a "System V environment" under SunOS
192*b89261baSDavid van Moolenbroek     (that is, /usr/5bin is before /usr/bin on your path) then the
193*b89261baSDavid van Moolenbroek     compilation may fail. This is mostly due to the fact that top thinks
194*b89261baSDavid van Moolenbroek     its being compiled on a System V machine when it really isn't. The
195*b89261baSDavid van Moolenbroek     only solution is to put /usr/bin and /usr/ucb before /usr/5bin on
196*b89261baSDavid van Moolenbroek     your path and try again.
197*b89261baSDavid van Moolenbroek
198*b89261baSDavid van Moolenbroek
199*b89261baSDavid van Moolenbroek     SOLARIS PROBLEMS
200*b89261baSDavid van Moolenbroek
201*b89261baSDavid van Moolenbroek
202*b89261baSDavid van Moolenbroek     NOTE: the most common source of problems with top under Solaris is
203*b89261baSDavid van Moolenbroek     the result of compiling it with the wrong front end. Make sure that
204*b89261baSDavid van Moolenbroek     /usr/ucb is not on your path before attempting to compile top under
205*b89261baSDavid van Moolenbroek     Solaris.
206*b89261baSDavid van Moolenbroek
207*b89261baSDavid van Moolenbroek19.  Is there somewhere I can get a pre-compiled package?
208*b89261baSDavid van Moolenbroek
209*b89261baSDavid van Moolenbroek     Yes. Although I don't provide pre-compiled binaries, you can get a
210*b89261baSDavid van Moolenbroek     Sun-style package from www.sunfreeware.com.
211*b89261baSDavid van Moolenbroek
212*b89261baSDavid van Moolenbroek20.  Under Solaris 2, when I type "make", the system says "language
213*b89261baSDavid van Moolenbroek     optional software package not installed." What's going on?
214*b89261baSDavid van Moolenbroek
215*b89261baSDavid van Moolenbroek     You tried to compile with /usr/ucb/cc. Make sure /usr/ucb is not on
216*b89261baSDavid van Moolenbroek     your path. Furthermore, you do not have a Sun compiler installed on
217*b89261baSDavid van Moolenbroek     your system. You need a compiler to make top. Either Sun's C compiler
218*b89261baSDavid van Moolenbroek     or the Gnu C compiler will work fine.
219*b89261baSDavid van Moolenbroek
220*b89261baSDavid van Moolenbroek21.  Under Solaris 2, when I run top as root it only shows root processes,
221*b89261baSDavid van Moolenbroek     or it only shows processes with a PID less than 1000. It refuses to
222*b89261baSDavid van Moolenbroek     show anything else. What do I do?
223*b89261baSDavid van Moolenbroek
224*b89261baSDavid van Moolenbroek     You probably compiled it with /usr/ucb/cc instead of the real C
225*b89261baSDavid van Moolenbroek     compiler. /usr/ucb/cc is a cc front end that compiles programs in BSD
226*b89261baSDavid van Moolenbroek     source-level compatability mode. You do not want that. Make sure that
227*b89261baSDavid van Moolenbroek     /usr/ucb is not on your path and try compiling top again.
228*b89261baSDavid van Moolenbroek
229*b89261baSDavid van Moolenbroek22.  Under Solaris 2, I compiled top using what I am sure is the correct
230*b89261baSDavid van Moolenbroek     compiler but when I try to run it it complains about missing dynamic
231*b89261baSDavid van Moolenbroek     libraries. What is wrong?
232*b89261baSDavid van Moolenbroek
233*b89261baSDavid van Moolenbroek     Check to see if you have LD_LIBRARY_PATH defined in your shell. If
234*b89261baSDavid van Moolenbroek     you do, make sure that /usr/ucblib is not on the path anywhere. Then
235*b89261baSDavid van Moolenbroek     try compiling top again.
236*b89261baSDavid van Moolenbroek
237*b89261baSDavid van Moolenbroek23.  Under Solaris 2, when I try to run top it complains that it can't
238*b89261baSDavid van Moolenbroek     open the library "libucb.so.1". So I changed the LIBS line in
239*b89261baSDavid van Moolenbroek     m_sunos5.c to include -R/usr/ucblib to make sure that the dynamic
240*b89261baSDavid van Moolenbroek     linker will look there when top runs. I figured this was just an
241*b89261baSDavid van Moolenbroek     oversight. Was I right?
242*b89261baSDavid van Moolenbroek
243*b89261baSDavid van Moolenbroek     No, you were not right. As distributed, top requires no alterations
244*b89261baSDavid van Moolenbroek     for successful compilation and operations under any release of
245*b89261baSDavid van Moolenbroek     Solaris 2. You probably compiled top with /usr/ucb/cc instead of the
246*b89261baSDavid van Moolenbroek     real C compiler. See FAQ 22 for more details.
247*b89261baSDavid van Moolenbroek
248*b89261baSDavid van Moolenbroek24.  On my 64-bit system some processes show up with incorrect information
249*b89261baSDavid van Moolenbroek     (such as zero memory).
250*b89261baSDavid van Moolenbroek
251*b89261baSDavid van Moolenbroek     If you are running a 64-bit system, then you need to make sure that
252*b89261baSDavid van Moolenbroek     you are running the 64-bit top binary. Top's configure script
253*b89261baSDavid van Moolenbroek     attempts to detect 64-bit systems, and will automatically generate
254*b89261baSDavid van Moolenbroek     both 32-bit and 64-bit binaries on such systems. If you use or
255*b89261baSDavid van Moolenbroek     install the 32-bit binary on a 64-bit system top will still run but
256*b89261baSDavid van Moolenbroek     will not produce the correct results. This will also happen if you
257*b89261baSDavid van Moolenbroek     configure your distribution on a 32-bit system then compile with that
258*b89261baSDavid van Moolenbroek     configuration on a 64-bit system. You must configure and compile on
259*b89261baSDavid van Moolenbroek     the same system. For Sparc systems the 32-bit binary will be created
260*b89261baSDavid van Moolenbroek     in the subdirectory "sparcv7" and the 64-bit binary will be created
261*b89261baSDavid van Moolenbroek     in the subdirectory "sparcv9". For Intel systems the directories will
262*b89261baSDavid van Moolenbroek     be "i386" (32-bit) and "amd64" (64-bit). In all cases a copy of
263*b89261baSDavid van Moolenbroek     /usr/lib/isaexec is made in the main directory and called "top". This
264*b89261baSDavid van Moolenbroek     program will choose the correct binary to run from one of these
265*b89261baSDavid van Moolenbroek     subdirectories. See isaexec(3c) for more details.
266*b89261baSDavid van Moolenbroek
267*b89261baSDavid van Moolenbroek25.  Can I install both 32-bit and 64-bit binaries on a central file
268*b89261baSDavid van Moolenbroek     server and have machines which mount it automatically use the correct
269*b89261baSDavid van Moolenbroek     one?
270*b89261baSDavid van Moolenbroek
271*b89261baSDavid van Moolenbroek     Yes. If you configure and compile on a 64-bit system, top's configure
272*b89261baSDavid van Moolenbroek     script and makefile will automatically create both 32-bit and 64-bit
273*b89261baSDavid van Moolenbroek     binaries. The "install" rule in the makefile will install these
274*b89261baSDavid van Moolenbroek     binaries in subdirectories of /usr/local/bin appropriate to the
275*b89261baSDavid van Moolenbroek     architecture (sparcv7/sparcv9 or i386/amd64) then create a copy of
276*b89261baSDavid van Moolenbroek     /usr/lib/isaexec named "top" in /usr/local/bin to ensure that the
277*b89261baSDavid van Moolenbroek     appropriate is run when a user types "top". If you make sure that you
278*b89261baSDavid van Moolenbroek     configure and compile on a 64-bit system, then "make install" will do
279*b89261baSDavid van Moolenbroek     the right thing.
280*b89261baSDavid van Moolenbroek
281*b89261baSDavid van Moolenbroek26.  This version of top show less available swap space than previous
282*b89261baSDavid van Moolenbroek     versions. Why does it no longer match the output of the swap summary
283*b89261baSDavid van Moolenbroek     produced with "swap -s"?
284*b89261baSDavid van Moolenbroek
285*b89261baSDavid van Moolenbroek     Starting with version 3.6 of top, the amount of swap space reported
286*b89261baSDavid van Moolenbroek     by top has been changed to reflect only disk-based swap space. The
287*b89261baSDavid van Moolenbroek     swap summary produced with "swap -s" also includes memory-based swap
288*b89261baSDavid van Moolenbroek     space. This changed was made for several reasons. It makes the
289*b89261baSDavid van Moolenbroek     display under Solaris more like those of other operating systems. The
290*b89261baSDavid van Moolenbroek     display is more what users expect (except those used to previous
291*b89261baSDavid van Moolenbroek     versions of top). Most importantly, "swap -s" gets its data via an
292*b89261baSDavid van Moolenbroek     undocumented system interface. Now that top no longer displays that
293*b89261baSDavid van Moolenbroek     data it can use publically documented and maintained system
294*b89261baSDavid van Moolenbroek     interfaces to retrieve its data.
295*b89261baSDavid van Moolenbroek
296*b89261baSDavid van Moolenbroek
297*b89261baSDavid van Moolenbroek     SVR4-DERIVED PROBLEMS
298*b89261baSDavid van Moolenbroek
299*b89261baSDavid van Moolenbroek27.  When I run top on my SVR4-derived operating system, it displays all
300*b89261baSDavid van Moolenbroek     the system information at the top but does not display any process
301*b89261baSDavid van Moolenbroek     information (or only displays process information for my own
302*b89261baSDavid van Moolenbroek     processes). Yet when I run it as root, everything works fine. What's
303*b89261baSDavid van Moolenbroek     wrong?
304*b89261baSDavid van Moolenbroek
305*b89261baSDavid van Moolenbroek     Your system probably uses the pseudo file system "/proc", which is by
306*b89261baSDavid van Moolenbroek     default only accessible by root. Top needs to be installed setuid
307*b89261baSDavid van Moolenbroek     root on such systems if it is going to function correctly for normal
308*b89261baSDavid van Moolenbroek     users.
309*b89261baSDavid van Moolenbroek
310*b89261baSDavid van Moolenbroek
311*b89261baSDavid van Moolenbroek     SVR42 PROBLEMS
312*b89261baSDavid van Moolenbroek
313*b89261baSDavid van Moolenbroek28.  The memory display doesn't work right. Why?
314*b89261baSDavid van Moolenbroek
315*b89261baSDavid van Moolenbroek     This is a known bug with the svr42 module. The problem has been
316*b89261baSDavid van Moolenbroek     traced down to a potential bug in the "mem" driver. The author of the
317*b89261baSDavid van Moolenbroek     svr42 module is working on a fix.
318*b89261baSDavid van Moolenbroek
319*b89261baSDavid van Moolenbroek
320*b89261baSDavid van Moolenbroek     STILL STUCK
321*b89261baSDavid van Moolenbroek
322*b89261baSDavid van Moolenbroek29.  I'm still stuck. To whom do I report problems with top?
323*b89261baSDavid van Moolenbroek
324*b89261baSDavid van Moolenbroek     The most common problems are caused by top's sensitivity to internal
325*b89261baSDavid van Moolenbroek     kernel data structures. So make sure that you are using the right
326*b89261baSDavid van Moolenbroek     include files, and make sure that you test out top on the same
327*b89261baSDavid van Moolenbroek     machine where you compiled it. Sun's BSD Source Compatability Mode is
328*b89261baSDavid van Moolenbroek     also a common culprit. Make sure you aren't using either /usr/ucb/cc
329*b89261baSDavid van Moolenbroek     or any of the libraries in /usr/ucblib. Finally, make sure you are
330*b89261baSDavid van Moolenbroek     using the correct module. If there does not appear to be one
331*b89261baSDavid van Moolenbroek     appropriate for your computer, then top probably will not work on
332*b89261baSDavid van Moolenbroek     your system.
333*b89261baSDavid van Moolenbroek
334*b89261baSDavid van Moolenbroek     If after reading all of this file and checking everything you can you
335*b89261baSDavid van Moolenbroek     are still stuck, then please use SourceForge to submit a support
336*b89261baSDavid van Moolenbroek     request or a bug. Top is supported by the SourceForge project  named
337*b89261baSDavid van Moolenbroek     "unixtop". On SourceForge you will find defect tracking, a mailing
338*b89261baSDavid van Moolenbroek     list, and on-line forums. You can also contact the author through
339*b89261baSDavid van Moolenbroek     SourceForge.
340*b89261baSDavid van Moolenbroek
341