• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

top command output

billynomates

Well-known member
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 :scrambled: . Any ideas why?

e.g.,

Code:
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% ?????
 
Last edited by a moderator:

johnklos

Well-known member
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 :scrambled: . 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

Well-known member
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

Well-known member
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

Well-known member
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:
This is an example of codified text
 

tlc630

Well-known member
Code:
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
 

tlc630

Well-known member
Thanks for the tips.

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

SO, you don't like this output:

Code:
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:
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:
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

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

Code:
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:
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

Well-known member
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

Well-known member
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:
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

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

 

billynomates

Well-known member
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.

 
Top