SUMMARY: kernel make error

From: Ron Madurski (
Date: Sun May 26 1991 - 10:48:55 CDT

Here is the problem and the responses received.

From: (Brent Alan Wiese)

} Subject: kernel make error
> loading vmunix
> Undefined
> _mem_ops
> *** Error code 2
> make: Fatal error: Command failed for target `vmunix'
> This is the error that I get when I run make in the
> /usr/kvm/sys/sun4c/hostname
> directory after doing a config hostname.
> I'd like to know where the _mem_ops should be so that I can fix that and
> get on to the next problem.
> Actually as long as I'm writing I'll throw this out also. I have an IPC
> that was an upgrade from a 3/50. I have 2 drives installed (HP 97548S
> and a CDC Wren IV), 8 MB memory (new along with the CPU so I don't think
> it is a hardware problem), an EXABYTE Tape Drive, 2 modems Telebit and a
> USR, and a CD-ROM Drive attached.
> The problems I am experiencing are somewhat varied. Generally, the
> beast manifests itself as a core dump from some program, most commonly
> vi, or sh, or quotaon, or ps. However, if you wait a few minutes and
> run the program again it may work just fine. (Like I just tried to su
> to the computer and it wouldn't let me, I tried to find a problem and
> couldn't so I tried it again and it worked just fine.) Sometimes I will
> get a bus error, sometimes I get a Segmentation Fault. When news is
> received I get a message indicating that incoming news is being
> discarded due to a lack of space, when I have over 150 MB free with
> only 10% of the inodes used.
> When the computer crashes I usually end up with a lot of duplicate
> inodes.
> Has anyone seen this problem before?? If not maybe someone has an idea
> that I haven't thought of yet. Oh yeah OS version 4.1.1.
> Thanks for your time,
> --
> ron@DRD.Com
> uunet!apctrc!drd!ron
---- End of excerpt from Ron Madurski

     My quess is that you included kernel support for "bwtwo", "cg3" or "cg6",
but not "win"/"win128". Either include "win128" or modify
/usr/sys/sun4c/conf/files to include "pixrect/../mem/mem_kern.c" for your
framebuffer. Here is a diff for the file "files" that I made.

***His guess was right on the money. That is exactly what I had done. ****

(ssctrtest,20)* dirs
/usr/sys/sun4c/conf ~
(ssctrtest,21)* diff -c files.orig files
*** files.orig Thu Oct 11 15:10:57 1990
--- files Sat May 11 21:22:24 1991
*** 12,17 ****
--- 12,18 ----
  pixrect/../cg12/cg12_ioctl.c optional win cgtwelve device-driver
  pixrect/../mem/mem_colormap.c optional win device-driver
  pixrect/../mem/mem_kern.c optional win device-driver
+ pixrect/../mem/mem_kern.c optional bwtwo device-driver
  pixrect/../mem/mem_rop.c optional win device-driver
  pixrect/../pr/pr_clip.c optional win device-driver
  pixrect/../pr/pr_dblbuf.c optional win device-driver

     As for your other problems, make sure you are mount "sun4c" kvm on
/usr/kvm and not "sun4" kvm on /usr/kvm. Sometimes you can quickly check
if this is the case by running the ps command. If everything appears in
parentheses then your are not mounting the right /usr/kvm.

*** I am rebuilding the kernel from


so I don't think that is the problem. ***

From: (Fabrice Le Metayer)

There is a way to find all the defined and referenced symbols in the object
files linked into the kernel and I use it fairly often when I encounter an
error similar to yours. It turns out generally that the Makefile generated
by /etc/config has the object files in the wrong order, or that I forgot to
include a line in the /usr/sys/sun4c/conf/files file.

Run this :

        # cd /usr/sys/sun4c/OBJ
        # foreach f ( *.o )
        ? nm $f | egrep mem_ops
        ? if ( ! $status ) echo $f
        ? end

and you will get an output that looks like :

                 U _mem_ops
        00000024 D _mem_ops
                 U _mem_ops
                 U _mem_ops
                 U _mem_ops

Where "U" means that the symbol is referenced, and "D" that it is defined.
So, verify that the object "mem_kern.o" is included in your Makefile, and
that it appears before cgsix.o, win.o, windt.o or winioctl.o

From: era@niwot.scd.ucar.EDU (Ed Arnold)

_mem_ops is defined in OBJ/mem_kern.o. If ../OBJ/mem_kern.o isn't
in the kernel makefile then something is wrong with the config
process. You could probably add it to the OBJS list if you can't
find the real source of the problem ...

From: etnibsd!vsh@uunet.UU.NET (Steve Harris)

I was told sometimes marginal memory will fail in an apparent random
fashion. Unfortunately, such marginal memory will usually pass the
standard bootstrap memory tests. If nothing else works, try swapping
with faster memory.

*** The memory and CPU are brand spanking new. It seemed to be a
hardware type problem so Sun sent me a new board. ***

From: (Jean-Yves Picard)

as for your IPC, did you check out your shared library ?
we experience a similar problem not so long:
% su
illegal instruction (core dump)

twm crash whem poping an xterm and the like ....

making a checksun on shared library show a difference,
from a ``sane'' machine (altough the size where equal).

so if you have two IPC, you better chek this.

Hope this will help.

        Jean Yves Picard

SunOS Release 4.1.1 (GENERIC_SMALL) #1: Thu Oct 11 10:48:40 PDT 1990

check sum:
44181 3 /usr/lib/lib.b
05613 643 /usr/lib/libc.a

... some lines deleted

04113 224 /usr/local/lib/
48261 333 /usr/local/lib/libsunwindow_p.a

*** they checked out OK ***

From: stern@sunne.East.Sun.COM (Hal Stern - Consultant)

do you have a cgsix defined withtout any window devices?

the mem_ops come from the pixrect package, which is included
in the kernel via the "win" pseudo device driver (see
/sys/sun4c/conf/files for the magic line, the file is
mem_kern.c). if you have a cgsix defined, it will look
for mem_ops

*** This was the first response I received and pointed me in the right
direction ***
Thanks for all of your help. I am still having trouble with the system,
but I theink I've narrowed it down to the disk drive. I moved the IPC's
disk to another machine and still experienced similar problems. That is
the tack I am on now.

Thanks again.


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:14 CDT