top command output

[billynomates]

Hi

I'm running 'top' on an A/UX 3.1 Macintosh SE/30. This has been downloaded from aux-penelope and compiled.

The COMMAND and SIZE output is garbled . Any ideas why?

e.g.,

Code: Select all

load averages:   1.03,  1.02,  0.81                                    17:21:57
22 processes:  20 sleeping, 1 running, 1 on cpu
Cpu states:  0.0% idle, 58.0% user, 42.0% kernel,  0.0% wait,  0.0% nice
Memory: 9512K mem avail, 51M free, 8148K locked, 128M swap free

  PID  PGRP USERNAME PRI NICE  SIZE STATE   TIME    WCPU     CPU COMMAND
  170   145 simon     45  -20 /-0,'*K run      ???   0.00%   0.00% ??
  190     0 oracle     1    0   14M sleep    ???   0.00%   0.00% ??????z???????
  211   211 simon     31   -4  192K cpu      ???   0.00%   0.00% ??????????????
  186     0 oracle     1    0   14M sleep    ???   0.00%   0.00% ??????????????
  189     0 oracle     1    0   14M sleep 2488.3   0.00%   0.00% ??????????????
  187     0 oracle     1    0   14M sleep    ???   0.00%   0.00% ??????????????
  169   145 simon    -25  -20 /-0(.,K sleep 310.7H   0.00%   0.00% ???
  193   193 root       1    0  176K sleep    ???   0.00%   0.00% ??????????????
    1     0 root      14    0  128K sleep   0:00   0.00%   0.00%
  188     0 oracle     1    0   14M sleep 2488.3   0.00%   0.00% ??????????????
  140   139 root       1    0  176K sleep 4630.0   0.00%   0.00% ??????????????
  171   171 simon      5    0  228K sleep 2488.3   0.00%   0.00% ??????????????
  194   194 simon      5   -4  228K sleep    ???   0.00%   0.00% ??????????????
  145   145 simon      5    0  228K sleep 2488.3   0.00%   0.00% ??????????????
  167   145 simon      5    0   76K sleep 2718.5   0.00%   0.00% ?????

[johnklos]

I'm running 'top' on an A/UX 3.1 Macintosh SE/30. This has been downloaded from aux-penelope and compiled.

The COMMAND and SIZE output is garbled . Any ideas why?

top and other programs which get lots of data from the kernel are usually very picky about changes in the format of that data. Are you sure that the source to top which you got from aux-penelope was definitely intended for 3.1? Read the notes - most tarballs have a readme somewhere which might talk about differences between the A/UX versions and might even say what to do differently to make top happy with 3.1.

[billynomates]

According to the AUX-README, the source has been (manually) patched to make it compatible with A/UX 3.x

Doesn't seem to work for me... maybe there's something "funny" about my O/S.

Thanks anyway!

[tlc630]

Hi,
Sorry for the very late reply.
This bothered me too a long time ago when I had a clock chipped Quadra 650 running A/UX.
I fixed the bug then but the Q650 went away so I had no way to verify my fix.
Recently, a SE/30 came home and I am now running A/UX again with a properly formatted top
on it. I'd show you the output and the code fix but for the life of me I can't figure out how to
post a screen dump (cmd-shift-3), a copy of a telnet output, or any other picture to this site.


Here's the deal: You show me how to include an image in a reply and I'll supply the fix to top.

BTW, the error I get when I try to include a image of the top output is 'The extension is not allowed', whatever
that means.

[billynomates]

AFAIK the only way to do this is to use the 'img' tags in the reply, with a URL hosting the actual picture between the tags. IIRC some people here have used flickr (or a similar website) to host the pictures.

The above output was 'codified' rather than posted as an image - that is, I telnet'ed into my SE/30, copied the output to my PC's clipboard, and then pasted it into the post. The 'code' tags are then put around the text to be formatted. ~jl actually did the codifying, as I wasn't aware that this was the way to do it at the time.

Code: Select all

This is an example of codified text

[tlc630]

Code: Select all

load averages:   1.31,  0.53,  0.21                                    08:14:56
14 processes:  12 sleeping, 1 zombie, 1 on cpu
Cpu states: 87.3% idle,  6.2% user,  6.5% kernel,  0.0% wait,  0.0% nice
Memory: 5188K mem avail, 32M free, 43M locked, 375M swap free

  PID  PGRP USERNAME PRI NICE  SIZE STATE   TIME    WCPU     CPU COMMAND
  166   144 tlong    -25  -20   12M sleep   0:32   1.01%   5.84% startmac
  167   144 tlong    -25  -20   13M sleep   0:05   0.32%   1.95% CommandShell
  186   186 tlong     31   -4  192K cpu     0:01   0.32%   1.62% top
  168   168 root       1    0  176K sleep   0:00   0.13%   0.65% in.telnetd
  169   169 tlong     14   -4  532K sleep   0:02   0.00%   0.00% bash
  137   136 root       1    0  184K sleep   0:00   0.00%   0.00% in.routed
   11    10 root     -25    4  136K sleep   0:00   0.00%   0.00% fidd
    1     0 root      14    0  128K sleep   0:01   0.00%   0.00% init
  139   139 root       1    0  192K sleep   0:00   0.00%   0.00% inetd
  131   131 root       1    0  164K sleep   0:00   0.00%   0.00% portmap
  144   144 tlong      5    0   76K sleep   0:06   0.00%   0.00% sh
  134   134 root       1    0  208K sleep   0:00   0.00%   0.00% cron
  126   125 root       1    0   68K sleep   0:00   0.00%   0.00% errdemon



[ChristTrekker]

When I run top, I only get "top: getkval for proc array: Bad address" after a 3- or 4-second delay.

[tlc630]

Thanks for the tips.
Sorry for the previous reply. I accidently hit 'Submit' instead of 'Preview'.

SO, you don't like this output:

Code: Select all

load averages:   1.73,  1.62,  1.16                                    08:35:05
14 processes:  11 sleeping, 1 running, 1 zombie, 1 on cpu
Cpu states: 92.1% idle,  4.6% user,  3.3% kernel,  0.0% wait,  0.0% nice
Memory: 5192K mem avail, 32M free, 43M locked, 375M swap free

  PID  PGRP USERNAME PRI NICE  SIZE STATE   TIME    WCPU     CPU COMMAND
  166   144 tlong     16  -20   12M run   3646.5   0.50%   0.00%
  271   271 tlong     31   -4  232K cpu   6258.1   0.86%   0.00% ?p
  167   144 tlong    -25  -20   13M sleep 3649.5   0.50%   0.00%
  137   136 root       1    0  184K sleep 6270.9   0.86%   0.00%  n
  168   168 root       1    0  176K sleep 2653.3   0.36%   0.00% /?N?
  169   169 tlong     14   -4  536K sleep 5469.5   0.75%   0.00% n?? S/?N?
    1     0 root      14    0  128K sleep 1340.6   0.18%   0.00% S=l????=l????/
  144   144 tlong      5    0   76K sleep 2519.1   0.35%   0.00% ?2м?
  134   134 root       1    0  208K sleep    ???  -0.73%   0.00% n
  139   139 root       1    0  192K sleep 3663.5   0.50%   0.00% !@
  131   131 root       1    0  164K sleep 6403.1   0.88%   0.00%
  126   125 root       1    0   68K sleep 2439.8   0.34%   0.00% ?O?
   11    10 root     -25    4  136K sleep    ???  -0.63%   0.00% ??=@??-l?<??-l



and would prefer this:

Code: Select all

load averages:   1.31,  1.51,  1.16                                    08:36:09
14 processes:  12 sleeping, 1 zombie, 1 on cpu
Cpu states: 88.4% idle,  7.7% user,  3.9% kernel,  0.0% wait,  0.0% nice
Memory: 5192K mem avail, 32M free, 43M locked, 375M swap free

  PID  PGRP USERNAME PRI NICE  SIZE STATE   TIME    WCPU     CPU COMMAND
  166   144 tlong    -25  -20   12M sleep   2:01   0.61%   7.07% startmac
  272   272 tlong     31   -4  192K cpu     0:01   0.22%   2.57% top
  167   144 tlong    -25  -20   13M sleep   0:21   0.11%   1.29% CommandShell
  168   168 root       1    0  176K sleep   0:36   0.06%   0.64% in.telnetd
  137   136 root       1    0  184K sleep   0:00   0.00%   0.00% in.routed
  169   169 tlong     14   -4  536K sleep   0:06   0.00%   0.00% bash
    1     0 root      14    0  128K sleep   0:01   0.00%   0.00% init
  144   144 tlong      5    0   76K sleep   0:06   0.00%   0.00% sh
  134   134 root       1    0  208K sleep   0:00   0.00%   0.00% cron
  139   139 root       1    0  192K sleep   0:00   0.00%   0.00% inetd
  131   131 root       1    0  164K sleep   0:00   0.00%   0.00% portmap
  126   125 root       1    0   68K sleep   0:00   0.00%   0.00% errdemon
   11    10 root     -25    4  136K sleep   0:00   0.00%   0.00% fidd



?

Here's what I did. I found the code that did all the formating. It is in machine.c which is a symlink to machine/m_aux31.c in
our case. I notices that all the things properly formatted are based off of /dev/kmem and the improperly formatted ones are
based on /dev/mem so I figured that A/UX didn't maintain /dev/mem the same way other unixes do. So as a trial, I inserted, at 144, the line

Code: Select all

mem = kmem;

recompiled and tested. Output looked great. I never went back to do more checking or code clean up. I suppose someone should
incorporate the fix so that it doesn't get lost.

[billynomates]

Cool. Thanks. My SIZE output is still garbled though - although not uniformly...

Code: Select all

load averages:  1.66,  1.59,  1.17                                     18:16:44
15 processes:  13 sleeping, 1 running, 1 on cpu
Cpu states:     % idle,     % user,     % kernel,     % wait,     % nice
Memory: 6036K mem avail, 54M free, 8184K locked, 128M swap free

  PID  PGRP USERNAME PRI NICE  SIZE STATE   TIME    WCPU     CPU COMMAND
  158   145 simon    -25  -20 /-0,.(K sleep   2:52   0.00%   0.00% CommandShell
  157   145 simon     15  -20 /-0(.,K run     1:33   0.00%   0.00% startmac
  145   145 simon      5    0   76K sleep   0:08   0.00%   0.00% sh
  624   624 simon      1    0  192K sleep   0:02   0.00%   0.00% top
  626   626 simon     14   -4  492K sleep   0:01   0.00%   0.00% bash
    1     0 root      14    0  128K sleep   0:01   0.00%   0.00% init
  633   633 simon     35   -4  188K cpu     0:01   0.00%   0.00% top
  159   159 simon     14    0  492K sleep   0:00   0.00%   0.00% bash
  137   137 root       1    0  192K sleep   0:00   0.00%   0.00% inetd
  625   625 root       1    0  176K sleep   0:00   0.00%   0.00% in.telnetd
  132   132 root       1    0  164K sleep   0:00   0.00%   0.00% portmap
  135   135 root       1    0  208K sleep   0:00   0.00%   0.00% cron
  140   139 root       1    0  176K sleep   0:00   0.00%   0.00% syslogd
   11    10 root     -25    4  100K sleep   0:00   0.00%   0.00% fidd
  127   126 root       1    0   68K sleep   0:00   0.00%   0.00% errdemon


It doesn't look as if it's to do with the size of the process, as the Oracle database is reported as 14M correctly.

Any ideas? There were some warnings(?) during compilation...

Code: Select all

aegis.root # make
   cc -Dclear=clear_scr -DPRIO_PROCESS=0 -DIMPLEMENT_SETPRIORITY -O -c top.c
   awk -f sigconv.awk /usr/include/sys/signal.h >sigdesc.h
   cc -Dclear=clear_scr -DPRIO_PROCESS=0 -DIMPLEMENT_SETPRIORITY -O -c commands.c
   cc -Dclear=clear_scr -DPRIO_PROCESS=0 -DIMPLEMENT_SETPRIORITY -O -c display.c
   cc -Dclear=clear_scr -DPRIO_PROCESS=0 -DIMPLEMENT_SETPRIORITY -O -c screen.c
   cc -Dclear=clear_scr -DPRIO_PROCESS=0 -DIMPLEMENT_SETPRIORITY -O -c username.c
   cc -Dclear=clear_scr -DPRIO_PROCESS=0 -DIMPLEMENT_SETPRIORITY -O -c utils.c
   cc -Dclear=clear_scr -DPRIO_PROCESS=0 -DIMPLEMENT_SETPRIORITY -O -c version.c
   cc -Dclear=clear_scr -DPRIO_PROCESS=0 -DIMPLEMENT_SETPRIORITY -O -c getopt.c
   cc -Dclear=clear_scr -DPRIO_PROCESS=0 -DIMPLEMENT_SETPRIORITY -O -c machine.c
/usr/include/sys/file.h: 126: O_RDONLY redefined
/usr/include/sys/file.h: 127: O_WRONLY redefined
/usr/include/sys/file.h: 128: O_RDWR redefined
/usr/include/sys/file.h: 129: O_NDELAY redefined
/usr/include/sys/file.h: 131: O_APPEND redefined
/usr/include/sys/file.h: 132: O_CREAT redefined
/usr/include/sys/file.h: 133: O_TRUNC redefined
/usr/include/sys/file.h: 134: O_EXCL redefined
/usr/include/sys/file.h: 136: O_GETCTTY redefined
/usr/include/sys/file.h: 137: O_GLOBAL redefined
/usr/include/sys/file.h: 140: O_SYNC redefined
   rm -f top
   cc -o top top.o commands.o display.o screen.o username.o  utils.o version.o getopt.o machine.o -ltermcap -lm


Thanks anyway - it's a million times better than it was!

[tlc630]

You can get rid of those warnings by installing file.h from jagubox. It is in the Sys_stuff directory.

I see your Cpu states and the CPU percentages are not proper either. Never saw that before. So what exactly are you running?
What A/UX, what cc, what ld, what make, etc? What top package? What was the output of Configure? Maybe we can get to
the bottom of this.

[billynomates]

Thanks - got the file.h and re-compiled - all fine there.

The 0.00% readings (I think) are because I'd taken the screen before top had a chance to refresh - it was it's first iteration of display, if I leave it to refresh a couple of times, and then take the screen again...

Code: Select all

load averages:   1.07,  1.02,  1.01                                    16:55:29
15 processes:  14 sleeping, 1 on cpu
Cpu states: 92.9% idle,  3.5% user,  3.5% kernel,  0.0% wait,  0.0% nice
Memory: 6028K mem avail, 54M free, 8232K locked, 128M swap free

  PID  PGRP USERNAME PRI NICE  SIZE STATE   TIME    WCPU     CPU COMMAND
  435   435 simon     31   -4  192K cpu     0:01   0.45%   2.26% top
  158   145 simon    -25  -20 /-0,.(K sleep 310:35   0.37%   1.94% CommandShell
  157   145 simon    -25  -20 /-0(.,K sleep   6:15   0.95%   1.61% startmac
  428   428 root       1    0  176K sleep   0:00   0.18%   0.97% in.telnetd
  429   429 simon     14   -4  492K sleep   0:01   0.00%   0.00% bash
  213   213 root       3    0  112K sleep   0:01   0.00%   0.00% sh
  137   137 root       1    0  192K sleep   0:00   0.00%   0.00% inetd
  132   132 root       1    0  164K sleep   0:00   0.00%   0.00% portmap
    1     0 root      14    0  128K sleep   0:01   0.00%   0.00% init
  140   139 root       1    0  176K sleep   0:00   0.00%   0.00% syslogd
  159   159 simon     14    0  492K sleep   0:02   0.00%   0.00% bash
  145   145 simon      5    0   76K sleep   0:07   0.00%   0.00% sh
  135   135 root       1    0  208K sleep   0:00   0.00%   0.00% cron
  127   126 root       1    0   68K sleep   0:00   0.00%   0.00% errdemon
   11    10 root     -25    4  100K sleep   0:00   0.00%   0.00% fidd


Still got the weird stuff for the SIZE though. Notice that both the processes with this SIZE problem are 'mac' processes - their executables are both in /mac/bin. Their NICE values are the same too - both are -20.

The version of A/UX I'm using is 3.1(.0). The cc, ld, etc are just the ones that came with A/UX - not sure how to tell if I'm honest!

Thanks again for your help.

[billynomates]

One other thing - if I start a shell command via commando, then the same SIZE issue appears against the cmdo process.

[billynomates]

To close this off - just had my SE/30 re-capped by phreakout, and the 'top' output's now fine.

[billynomates]

Actually, no it's not sorted at all, but it was before I put 64MB back in. Looks like it's something to do with that. Have had various chimes of doom problems, so I'm thinking dodgy memory.