jsanchez@uunet.uu.net (Julio Sanchez / GMV) (04/22/89)
I have been trying to reconfigure a kernel (to install SunLink/DNI) and
most things go OK except for 'ps' or 'w' that produce a 'segmentation
fault' and complain about problems in accessing /dev/drum and /dev/kmem.
After giving up with this, we tried to configure a GENERIC kernel (w/o
SunLink/DNI) and now no errors are found but ps produces NO output but the
header. 'w' does not seem to be producing correct answers either (7000+
days up time, etc).
We have restored libraries and reconfigured to no avail. We have used a
different WS to configure the kernel as well.
Now we have come to the point that we cannot produce a completely
functional kernel for 3.5. We had already done this for 3.2 without
problems, but it is our first try with 3.5.
Has anyone run into this problem and would like to help us?
Julio Sanchez Ph. +34 1 234 30 04
Grupo de Mecanica del Vuelo, S.A. (GMV) Fax +34 1 233 32 50
Cristobal Bordiu, 35 Telex 48487 GMEV E
E-28003 MADRID jsanchez@gmv.es
SPAIN mcvax!gmv.es!jsanchez@uunet.uu.net
uunet!mcvax!gmv.es!jsanchezcasper@uva.UUCP (Casper H.S. Dik) (05/06/89)
mcvax!gmv.es!jsanchez@uunet.uu.net (Julio Sanchez / GMV) writes: >X-Sun-Spots-Digest: Volume 7, Issue 238, message 14 of 14 > >I have been trying to reconfigure a kernel (to install SunLink/DNI) and >most things go OK except for 'ps' or 'w' that produce a 'segmentation >fault' and complain about problems in accessing /dev/drum and /dev/kmem. Ps(1), w(1) and many many other programs that tell something about the status of the system look in /dev/kmem and /dev/drum. They look for the values of certain items in the kernel's address space. To find out what's where they use the kernel's name list. (see nlist(3)). To get that namelist, those programs open /vmunix, expecting it to be the current kernel. If that kernel isn't the current one, ps will show random data and will derefence random pointers, sometimes causing segmentation faults. So, I suspect you have named your kernel something like newvmunix or vmunix.generic (anything but /vmunix). All you have to do is mv /<current-vmunix> /vmunix. Alternatively, you can specify the new kernel on the command line of some of the utilities that use it (but not all, this works with ps(1) and netstat(8), but not with w(1), iostat(8) and vmstat(8)) Similar effect happen when you strip(1) the kernel, but in that case ps would say something like: `/vmunix: no namelist.' --cd Casper H.S. Dik University of Amsterdam | casper@uva.uucp The Netherlands | ...!uunet!mcvax!uva!casper [[ Alternatively, you could link "/vmunix" to the kernel that you just booted with: "mv /vmunix /vmunix.old; ln /<current-unix> /vmunix" --wnl ]]
joerg%berthold.UUCP%TUB.BITNET@mitvma.mit.edu (Joerg Schilling - H. Berthold AG Berlin) (05/07/89)
This seemes to be interesting for all those people who are going to
rekonfigure their kernel for the first time:
'ps' and 'w' are looking for the namelist in /vmunix to figure out the
adresses of various objects (i.e. the proc structure) in the kernel memory.
'ps' cannot verify that the file /vmunix is the kernel you are running
now. It simply assumes that everything is ok and gets bogus values.
Depending on *how wrong* these values are, 'ps' either gets a segmentation
violation or simply displays nothing than the header.
The fact that you cannot get 'ps' to do it's work even if the kernel is a
generic one let me assume that you have a different /vmunix in your root
directory than that you are running. If you know the name of the vmunix
that you are running you can get 'ps' get to work if you type:
ps -ax /vmunix.test
if /vmunix.test is that one you are currently running.
The 'w' command has *no* way to specify a different kernel than /vmunix,
it will never work, if you are using a kernel different from /vmunix.
Hope this helps.
J. Schilling
H. Berthold AG
Teltowkanalstr. 1-4
D 1000 Berlin 46
+49 30 7795 - 400
joerg@berthold.de
.. tub!berthold!joerg
.. unido!berthold!joerg