68kMLA Classic Interface
This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.
| Click here to select a new forum. | | top command output | Posted by: billynomates on 2009-10-30 10:29:49
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.,
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% ????? | Posted by: johnklos on 2009-10-31 01:19:40
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.
| Posted by: billynomates on 2009-11-02 08:36:33
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!
| Posted by: tlc630 on 2011-01-05 20:33:56
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.
| Posted by: billynomates on 2011-01-06 02:40:33
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.
This is an example of codified text | Posted by: tlc630 on 2011-01-06 08:16:55
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 | Posted by: ChristTrekker on 2011-01-06 08:33:23
When I run top, I only get "top: getkval for proc array: Bad address" after a 3- or 4-second delay.
| Posted by: tlc630 on 2011-01-06 08:56:37
Thanks for the tips.
Sorry for the previous reply. I accidently hit 'Submit' instead of 'Preview'.
SO, you don't like this output:
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:
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
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.
| Posted by: billynomates on 2011-01-06 10:29:54
Cool. Thanks. My SIZE output is still garbled though - although not uniformly...
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...
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!
| Posted by: tlc630 on 2011-01-06 17:02:40
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.
| Posted by: billynomates on 2011-01-07 09:00:08
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...
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.
| Posted by: billynomates on 2011-01-07 09:31:17
One other thing - if I start a shell command via commando, then the same SIZE issue appears against the cmdo process.
| Posted by: billynomates on 2011-12-28 09:31:16
To close this off - just had my SE/30 re-capped by phreakout, and the 'top' output's now fine.
| Posted by: billynomates on 2012-03-29 11:45:23
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.
| | 1 |
|