From: ghod@drycas.club.cc.cmu.edu
Newsgroups: comp.unix.bsd
Subject: [386BSD] fixing ps: major/minor numbers for /dev/console wrong?
Date: 27 Sep 92 20:51:25 GMT
Organization: Carnegie Mellon Computer Club

Greetings...

I finally got really ticked off at ps not working correctly and I finally
decided to poke around with it this weekend. I never encountered the
floating point execption bug that some people complained of, although I
have noticed other problems, to wit:

1) it seems unable to find certain symbols in the kernel via nlist

2) it returns '??' instead of 'co' as the controlling terminal for
   processes started from the console.

3) it returns incorrect values for process memory usage (%MEM)

4) it never prints the arguments used to invoke processes (i.e. it'll
   show you (ps), which is the command name, but not 'ps -aux' which
   is the command line invokation).

Problem #1 is not, ps's fault: it's the kernel. The stock kernel in the 0.1
distribution has only a hanfull of symbols that can be accessed through 
nlist. A good way to demonstrate this is to type 'nm /386bsd' and look at
the output. There should be many, many screenfulls of symbols, but my
original kernel only had about one or two pages worth. Regrettably, I don't
have the space to build a new kernel, but I was able to ftp a patched one
from rachel.ibmpcug.co.uk. 

Problem #2 is what I really want to discuss. After obtaining the source code
to ps and twiddling with devname.c so that it would print out device numbers,
I discovered that it thinks the console device is at major number 12, minor
number 0. However, the console entry in the /dev directory says it's at
major number 0, minor number 0 (and a character special device). This is
WRONG WRONG WRONG!!! /dev/wd0a is *ALSO* at major 0, minor 0 (a block special
device). Now I don't care that one is a character special file and the
other is a block special file, YOU CAN'T HAVE TWO DIFFERENT DEVICES WITH THE
SAME MAJOR/MINOR NUMBERS!!! If it happens that someone has already posted
an article about this, I apologize for wasting bandwitdh, but there's nothing
about this in the FAQ file (that I could see). I have since created a new
/dev/console at major 12, minor 0: everything still works and ps can now
identify the console device correctly. If someone knows of some
other driver that might also wind up using this major/minor combination,
please let me know by posting or e-mail.

Problem #3 is related to an article which appreared previously in this topic,
but which has expired at my site. The %MEM value is a floating point number
and, in my newly compiled version of ps, it always comes out as -1. Someone
brought this up before, when they noticed that printf-ing the same value using 
both integer and floating point versions produced different numbers altogether.
If anyone remembers the article and the fix, or has a copy of it, please send
me a copy or direct me to an archive site where I can grab it.

Problem #4 is still evading me, but I'm still working on it. There *MUST* be
a way to track down the command line arguments for a given process, but 
without *detailed* man pages, I'm forced to search through the /usr/include/sys
files for information. It could be worse though: I wrote a ps command for 
Coherent 3.2, which required lseeking back and forth through physical memory
at least half a dozen times before finally arriving at the bottom of the
user-area segment where the arguments were kept. 

It should also be noted that the w command doesn't know how to find command
line arguments either. And, while I'm on about w, I'm sure that many people
have noticed that both w and uptime produce a "can't read namelist" error.
This is directly related to problem #1 and will only go away once you get
a new kernel. Since I installed mine, both commands work fine. 

--Bill Paul
Assistant System Administrator
New Windsor Associates L.P.

	ghod@drycas.club.cc.cmu.edu  -or-  ghod@drycas.bitnet

	"A black hole is what happens when god divides by zero."
Newsgroups: comp.unix.bsd