Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/answers/386bsd-faq/part4

Internet Message Format | 1993-12-26 | 31KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!usc.edu!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail
From: [e-mail] (Dave Burgess)
Newsgroups: comp.os.386bsd.announce,comp.answers,news.answers
Subject: [comp.os.386bsd] BNR/2 derived BSD for PCs FAQ (Part 4 of 10)
Followup-To: comp.os.386bsd.misc
Date: 27 Dec 1993 06:00:30 -0000
Organization: Armstrong Laboratory, Brooks AFB, TX
Lines: 747
Approved: [e-mail]
Distribution: world
Expires: 01/14/94
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (386bsd FAQ Maintainer)
NNTP-Posting-Host: hrd769.brooks.af.mil
Xref: senator-bedfellow.mit.edu comp.os.386bsd.announce:211 comp.answers:3169 news.answers:16208

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part4

Section 3.    (Kernel Building and Maintenance)

3.0    System Internals

    One of the interesting aspects of *BSD is the fact that it comes
    with the complete source.  This allows you to make changes to the
    system, recompile, and test out your new ideas.  This section of
    the FAQ describes many of the different aspects of this endeavor
    and common problems and pitfalls that are encountered.  Kevin Lahey
    provided the substantial portion of this section.  You can contact
    him via E-Mail at ([e-mail]) or contact Dave Burgess
    ([e-mail]).



3.1    Kernel

3.1.1    How do I build a kernel?

    The kernel can be compiled in a variety of ways to support different
    devices and configurations.  Compilation is controlled by a config
    file that specifies the characteristics of the kernel.  A set of
    different config files is located in /sys/i386/conf or
    /sys/arch/i386/conf.  The configuration file names are in upper case.

    To build a particular kernel (in this example, we use the GENERICISA
    configuration file in NetBSD or FreeBSD):

    % cd /sys/i386/conf
    % config GENERICISA
    % cd /sys/compile/GENERICISA
    % make depend
    % make

    You'll need patch 1 from the patchkit to get the compilation to work,
    'cause the version file isn't correctly included in the Makefile.


3.1.2    I want to do one of the following things:
    * add a device not in the distributed kernel (third com
      port, additional disk or tape, line printer driver, etc).
    * use a patch from the net or the patchkit to fix a kernel bug.
    * add another swap device.
    * recompile the kernel to remove extraneous devices so that
      it takes up less space.
    * configure more pseudo-terminals to allow for more xterms
      or network logins.

    You're going to have to recompile the kernel after you modify the
    config file.  See section 3.2 below for more information about the
    config file in general.


3.1.3    I don't have the source distribution -- how can I rebuild the
    kernel?

    There are reference sites available, as well as the 'good
    net-neighbor' policy, whereby you could make arrangements with a
    net neighbor to use a large local machine as a Network File System,
    or allow you to compile a new kernel on their machine and transfer it
    to yours.  If you *still* can't fit it in, you'll have to ftp a
    compiled kernel from agate in the unofficial/patchkit-old directory
    or one of the archive sites.  You can also ask for help from
    comp.os.386bsd.questions if you get stuck and cannot make any headway.


3.1.4    Now that I have a kernel, how do I install it?

    Your kernel is called /386bsd or /netbsd.  Copy the new kernel from
    /sys/compile/GENERICISA/386bsd to /, assuming that it is in that
    directory.  This is relatively straightforward; there are a couple
    of things to remember, though.  First, if you really screw up the new
    kernel, you want to have something to fall back on, so be sure to
    save /386bsd to /386bsd.old before copying in a new kernel.  Second,
    if you just copy the new kernel over the currently running kernel,
    funny things can happen.  Be sure to move aside the currently running
    kernel before copying over the new one.

    There are folks that have reported that overwriting their current
    kernel has never caused them any real problems.  On the other hand,
    if the old kernel was working and the new one doesn't, and you have
    made changes that require that old kernel, it should be available to
    the system, and saving it to /386bsd.alt or /386bsd.old are reasonable
    things to do.

    If you are really paranoid, you can mount a new fixit floppy and
    replace its kernel with the one you just built, and then boot from
    the fixit floppy to make sure everything will work.  This is a
    pretty good idea if you are making radical changes or if you are
    unsure about your changes.


3.1.5    After installing the patchkit and recompiling the kernel with the
    option "WD8013", I am no longer able to reboot the machine.  A cold
    boot (power on) runs fine, but after a reboot no boot drive is found
    by the BIOS.  Besides having a 16-bit WD/SMC Ethernet card installed
    the machines try to boot using either a Adaptec 1742 or 1542 SCSI
    board to boot from.

    This answer was provided by Hellmuth Michaelis ([e-mail]) and
    written by Rodney Grimes (rgrimes@acacia).

    Remove "option WD8013" from the config files and recompile and
    reinstall the kernel.

    The reason that option WD8013 often causes this reboot problem is
    this:

    There is a requirement that all memory within a 128k bank in the
    0xA0000 to 0xFFFFF region be either 16-bit or 8-bit.  On a cold
    boot, the WD8013 boards are reset to 8-bit mode, the POST
    (Power On Self Test) passes without error.  386bsd comes up, the
    if_we.c driver places the WD8013 in 16-bit mode.  Now on a soft boot
    when the BIOS runs some quick POST tests it finds a problem in the
    0xA000 to 0xF000 region.  You probably get a "beep-beep" when this
    happens.  It means you have a memory size conflict.
    The machine has been mis-configured.

      This is a little known fact about 16-bit vs 8-bit option cards.  It
    has caused more than one person to go crazy tracking down what they
    swear is a bug in the program.  It is not, it is a flaw in the design
    of the ISA bus.  The signal MEMCS16- must be returned the same for
    every 128k block of memory:

        B0000-CFFFF    Must all be either 8-bit or 16-bit.
        D0000-FFFFF    Must all be either 8-bit or 16-bit.

      In your particular configuration (WD8013 @ cc000) I suspect that
    you have another board in the B0000-CFFFFF region that is 8-bit, i.e.
    your Adaptec has an 8-bit BIOS on it!

      Try moving the board to the 0xD0000 region and see if it works there,
    you may still have a problem as many modern system BIOSes are now
    8-bit.
    If your system BIOS is 8-bit, try shadowing the system BIOS region
    at 0xF0000 to 0xFFFFF, this effectively turns it into a 16-bit BIOS.

      Do not attempt to shadow the WD8013, it well cause you many
      headaches.

      As always, works for me, you mileage may vary..


3.1.6    I found a bug in the kernel.  How do I report it?

    Both NetBSD and FreeBSD include a facility called 'bugfiler'.
    While the instructions are included in both system, there is
    still some apparent confusion about when to use (and when to
    NOT use) bugfiler.

    Jordan K. Hubbard ([e-mail])  provides us with this
    short article.

    To send bug reports, you want to use the sendbug(1) command.
    The entire package for sending and filing these bugs is known
    as "the bugfiler", which is where the confusion stepped in,
    but sendbug is definately the command you want to use.

    Second, it doesn't take a "net connection" to use sendbug,
    since all it does is package up your "bug report form" and mail
    it to us; no direct internet connectivity is required, just mail.

    So if you can send internet mail you can use sendbug, or you can
    also send mail to the `[e-mail]' address
    (do NOT send it to FreeBSD.cdrom.com since it will BOUNCE, this
    is not the place to send bugs to, just to ftp stuff from!).

    NetBSD has a similar facility, but has a different host for bug
    reports.


3.1.7    Can someone please give a reasonably clear set of instructions
    as to how to get a "current" version of NetBSD running?

    Marc Wandschneider <[e-mail]> provided this description
    of what he did to upgrade to the current version of NetBSD:

    1. Delete the old source tree, saving what I wanted to (a bunch
    of files moved around, and just unpacking the new one over the old
    will cause some problems)

    2. Unpacked the new source tree.

    3. ran the following sequence of commands:


        cd /usr/src/share/mk; make install
        cd /usr/src/include; make && make install
           setenv LDSTATIC -static
           setenv NOPIC
        cd /usr/src/lib/libc; make && make install
        cd /usr/src/gnu/lib/libmalloc; make && make install
           cd /usr/src/gnu/usr.bin/gas; make && make install
           cd /usr/src/gnu/usr.bin/ld; make && make install
        # You'll probably get some barfage from the above because
        # ld.so won't build yet.  Ignore it and install ld anyway.
           cd /usr/src/gnu/usr.bin/gcc; make && make install
           unsetenv NOPIC LDSTATIC
           cd /usr/src/lib ; make && make install
           cd /usr/src/gnu/lib ; make && make install
        cd /usr/src/gnu/usr.bin/ld; make && make install
           cd /usr/src; make && make install


    NOTE: At some point, you might very well come across an unresolved
    external __DYNAMIC in crt0.o.  If this happens, edit the makefile
    for crt0.o (lib/csu/i386) and remove the -DDYNAMIC flag)
    make && make install.  Then put the flag back in the makefile
    (but don't rebuild it until the natural order of things dicates
    that it happen)

    And Theo Deraadt provides this guidance when you get an error like
    "init_main.o: Undefined symbol _pdevinit referenced from text segment."

    You need to
        (1) install new config
        (2) make clean
        (3) re-config your kernel
    then this goes away


3.2    What exactly is this config file, anyway?  What are all of these
    cryptic notations?

    I've annotated the distributed GENERICISA file;  my comments are
    delineated by the '--' symbols.

    #
    # GENERICISA -- Generic ISA machine -- distribution floppy
    #
--  BSD can be compiled for different hardware platforms, so it is important to
--  define the hardware types.  386bsd can only be built for 386 or
--  compatible machines, so this is sort of superfluous, but maintains
--  compatibility with standard BSD config files.
    machine        "i386"
    cpu        "i386"
--  The ident describes the machine for which this kernel is to be built.
--  It is usually the system name -- "ROKKAKU", "REF", or whatever.
--  This can be used for conditional compilation, so that kernel changes
--  can be compiled in only for one machine.
    ident        GENERICISA
--  This should indicate the timezone of the system relative the
--  Greenwich.   8 is PST;  4 is EST.  Somebody else might want to discuss
--  this more fully.
    timezone    8 dst
--  maxusers isn't strictly checked;  it is just used to size several
--  system data parameters.
    maxusers    10
--  The options control the conditional compilation of features into the
--  kernel.  The options can be listed all on a line separated by commas.
--  They are #define'ed when the kernel is compiled, so that #ifdef's
--  will work.  An option can be given a value by appending an equals sign
--  and a value (enclosed in double quotes) to the option name.

--  Hopefully the names are at least somewhat self-explanatory.  To
--  discover what everything does, you'd have to go through the kernel
--  looking for all of the appropriate #ifdef's.

--  [Perhaps somebody else could list the *exact* meanings of these
--  options and some of the other possible options?]
    options        INET,ISOFS,NFS
    options        "COMPAT_43"
    options        "TCP_COMPAT_42"

--  The config line controls the location of the root, swap, and dump
--  devices.  Anything not specified is defaulted.  This is where you add
--  support for multiple swap devices.  Just list 'em, separated by 'and'.
--  The config line below identifies the root drive as wd0 and the
--  swap drives as wd0 and as0.  See the section on swap devices in FAQ_02
--  for additional information.
    config        "386bsd"    root on wd0 swap on wd0 and as0
--  A 'controller' is a device or bus controller.  'isa' is obviously for
--  the ISA bus.  'wd0' is for regular disk controllers,  'fd0' is for the
--  floppies, and 'as0' is for SCSI disk controllers.
    controller    isa0
--  The fields work as follows:

--  a.  What do you call this device?
--  b.  What controller is this on?  As you can see, the disk controller
--  talks to the ISA bus, and the disks talk to the disk controller.
--  c.  Where are the registers for the controller mapped into memory?
--  This is #defined in /sys/i386/isa/isa.h.
--  d.  What IRQ is this device set up for?
--  e.  What routine should be called on an interrupt from the device?

--             a          b           c             d           e
--            vvv        vvv       vvvvvvv          vv        vvvvvv
    controller    wd0    at isa? port "IO_WD1" bio irq 14 vector wdintr
--  You need a 'disk' entry for every disk on the controller.  In the
--  config file originally shipped with 386bsd, both hard disks were
--  incorrectly identified as wd0.  Be sure to change the second occurrence
--  to wd1, as I have done in below.
    disk        wd0    at wd0 drive 0
    disk        wd1    at wd0 drive 1

    controller    fd0    at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
    disk        fd0    at fd0 drive 0
    disk        fd1    at fd0 drive 1

--  The 'drq' specifies the channel used for bus-mastering DMA.
    controller    as0    at isa? port 0x330 bio irq 11 drq 5 vector asintr
    disk        as0    at as0 drive 0
    disk        as1    at as0 drive 1

--  Define other physical devices.  pc0 is the keyboard, npx0 drives the
--  math coprocessor, and com* controls the com ports.
    device        pc0    at isa? port "IO_KBD" tty irq 1 vector pcrint
    device        npx0    at isa? port "IO_NPX" irq 13 vector npxintr
    device        com1    at isa? port "IO_COM1" tty irq 4 vector comintr
    device        com2    at isa? port "IO_COM2" tty irq 3 vector comintr

--  Ethernet drivers of various sorts and the particular configuration
--  information they require.  For most installations, only one of these
--  devices would normally be defined.
    device we0 at isa? port 0x280 net irq 2 iomem 0xd0000 iosiz 8192 vector weintr
    device ne0 at isa? port 0x300 net irq 2 vector neintr
    device ec0 at isa? port 0x250 net irq 2 iomem 0xd8000 iosiz 8192 vector ecintr
    device is0 at isa? port 0x280 net irq 10 drq 7 vector isintr

--  Tape driver
    device        wt0    at isa? port 0x300 bio irq 5 drq 1 vector wtintr

--  The TCP/IP loop-back device, ethernet interface, slip interface, log
--  device, and pseudo-terminals.
    pseudo-device    loop
    pseudo-device    ether
    pseudo-device    sl    2
    pseudo-device    log
    pseudo-device    pty    4

--  Devices required by VM.
    pseudo-device    swappager
    pseudo-device    vnodepager
    pseudo-device    devpager

    Normally, there is an annotated configuration file called ALL which
    gives a list of all of the options for the configuration file.


3.2.1    Okay, fine.  Why shouldn't I just add every device I can find to
    the kernel, so I'll never have to recompile this again?

    Because it takes up space.  The kernel is wired into memory, so every
    byte it uses comes out of the pool of memory for everything else.  It
    can't page out sections that aren't in use.  If your kernel is larger
    than 640K, then it can't be loaded.  You'll need to use Julian Elischer's
    bootblocks to put it in high memory, which seem to be fairly complex.
    Installing them (once they are compiled) is as easy as using disklabel.


3.2.2    What should I remove from the kernel?

    What do you need?  If you only have an SCSI controller, you don't
    need the wd0 device;  if you have another kind of disk controller,
    you don't need as0.  Unless you actually HAVE more than one Ethernet
    controller, you should comment out all but one of them.  If you don't
    have an ethernet controller, you don't need any of the controllers or
    NFS compiled in.   Without a CD-ROM, ISOFS is kind of pointless.  Just
    look at what you have and think about what you really need.


3.2.3    I can't get enough remote login sessions or xterm sessions.  What
    can I do?

    Increase the count of pseudo-terminals --

    pseudo-device    pty    12  # or whatever

    Every pseudo terminal should have a /dev/pty* entry.  If you have 12
    pseudo terminals, you should also have at least 12 pty devices in the
    /dev directory.  The MAKEDEV script in /dev will create as many pseudo-
    terminals as you tell it to.


3.2.4    How do I get ddb, the kernel debugger, compiled into the kernel
    and running?

    Add the following line to the configuration file:

    pseudo-device    ddb

    Build the kernel, then run dbsym on it:

    % dbsym ./386bsd

    Install it and go for it.  Ctl-Alt-Esc drops you into the debugger.

    Note: DDB as shipped originally is a memory hog, and it is very
    difficult to get a kernel small enough with enough fun things in it
    to debug in 640K


3.2.5    Can I have more than one config file?  Should I rename it to something
    else?  Any other hints?

    You can create as many (or as few) config files as you desire.  The
    system, once the patchkit is applied, will have between 10 and 15,
    each of which implements certain functions or features.  In addition,
    the normal place for the patchkit to make changes to the config files
    is in the GENERICISA file.  Since this file should remain unchanged
    and available, it is always a good idea to copy this file to a
    meaningful name and modify that file.  In other words, change every
    reference in 3.1.1 from GENERICISA to HAL (or whatever you call your
    system).

    One final note.  Every /sys/compile directory takes up 800K or so;
    you might want to watch to see how big these all get.



3.2.6    What is the meaning of the trap codes I get in panic messages?
    Sometimes this message appears in the form "trap type nn".

    That message means that the system received an unexpected (and
    unwanted) trap that probably indicates some form of kernel bug.
    These traps, are usually received from the kernel, in which case
    the trap.h definitions should be used.

    The number (which appears in place of "nn" above) is *NOT* the
    i386 or i386 trap type, it is a BSD-defined trap type number.

    The definitions of the various trap types can be found in
    /usr/include/machine/trap.h.

    two of the more common ones are:
          9    T_PROTFLT    protection fault
                (The kernel tried executing code
                which was not noted as "executable".
                This happens if the kernel jumps to
                a bogus location.)
         12    T_PAGEFLT    page fault
                (The kernel tried to access a bogus
                area of memory.  This can happen if
                an invalid pointer is dereferenced.)


    This is a list of i386 trap codes (just to confuse the issue).

Trap    0    Divide Error
        The DIV or IDIV instruction is executed with a zero denominator
        or the quotient is too large for the destination operand.


Trap    1    Debug Exceptions
        Used in conjunction with DR6 and DR7, The following flags
        need to be tested to determine what caused the trap:
        BS=1                Single-step trap
        B0=1 AND (GE0=1 or LE0=1)    Breakpoint, DR0, LEN0, R/W0
        B1=1 AND (GE1=1 or LE1=1)    Breakpoint, DR1, LEN1, R/W1
        B2=1 AND (GE2=1 or LE2=1)    Breakpoint, DR2, LEN2, R/W2
        B3=1 AND (GE3=1 or LE3=1)    Breakpoint, DR3, LEN3, R/W3
        BD=1                Debug registers not available,
                        in use by ICE-386
        BT=1                Task Switch


Trap    2    NMI Interrupt
        On PC/AT systems, the NMI input to the CPU is usually
        connected to the main memory parity circuit.  By the time the
        error signal is generated, the data may have already been
        used in an instruction, so it isn't possible to reliably
        recover.

        And some not-so-common causes (from various sources):

          PS50+ : I/O channel check, system watch-dog timer
          time-out interrupt, DMA timer time-out interrupt

          parity errors on any 8-bit or 16-bit board pulling the
          IOCHCK* line low

          first generation of auto-switching EGA cards used NMI to trap port
          access for CGA emulation (e.g., ATI's EGA Wonder)

          Zeos Notebook low battery (perhaps other battery-based
          computers)


Trap    3    Breakpoint
        The result of executing an INT 3 instruction.  MS-DOS and
        Windows and some other non-386 systems use this for debugging.
        Code specific to the 386 and later processors should use
        the debugging features tied to Trap 1.


Trap    4    INT0 Detected Overflow
        Occurs if an INT0 instruction is executed and the overflow
        flag (OF) is currently set.


Trap    5    BOUND Range Exceeded
        Occurs if the BOUND instruction is executed and the array
        index points beyond the area of memory containing the array
        being tested.


Trap    6    Invalid Opcode
        The value read at CS:IP is not a valid opcode.


Trap    7    Coprocessor Not Available
        This occurs if the processor fetches an instruction that is
        for the coprocessor and no coprocessor is present.


Trap    8    Double Exception (Fault)
        An exception occurred while trying to execute the handler
        for a prior exception.  Example, an application causes a
        General Protection Fault (13) and the area of memory where
        the GPF handler should be is flagged not-present (paged-out?).
        The double-fault handler is invoked in these conditions.
        If a fault occurs while trying to run the double-fault handler,
        a triple-fault occurs and the CPU resets.

        The rules for deciding if a double-fault should occur or
        if the two faults can be handled serially are discussed in
        more detail in the Intel song book.


Trap    9    Coprocessor Segment Overrun
        A page or segment violation occurred while transferring
        the middle part of a coprocessor operand to the NPX.


Trap    10    Invalid Task State Segment
        During a task switch, the new TSS was invalid.  Here is
        a table of conditions that Invalidate the TSS:
        TSS id + EXT    The limit in the TSS descriptor is < 103
        LTD id + EXT    Invalid LDT selector or LDT not present
        SS id + EXT    Stack segment selector is outside table limit
        SS id + EXT    Stack segment is not a writable segment
        SS id + EXT    Stack segment DPL does not match new CPL
        SS id + EXT    Stack segment selector RPL <> CPL
        CS id + EXT     Code segment is outside table limit
        CS id + EXT    Code segment selector does not refer to
                    code segment
        CS id + EXT    DPL of non-conforming code segment <> new CPL
        CS id + EXT    CPL of conforming code segment > new CPL
        DS/ES/FS/GS id + EXT    DS, ES, FS or GS segment selector is
                    outside table limits
        DS/ES/FS/FS id + EXT    DS, ES, FS, or GS is not readable
                    segment


Trap    11    Segment Not Present
        Occurs when the "present" bit of a descriptor is zero.
        This can occur while loading any of these segment registers
        CS, DS, ES, FS, or GS.  Loading SS causes a Stack fault.
        Also occurs when attempting to use a gate descriptor that is
        marked "not present", and if attempting to load the LDT with
        an LLDT instruction.  Note that loading the LDT during a
        task switch causes an "invalid TSS" trap.


Trap    12    Stack Fault
        A limit violation relating to an address referenced off
        the SS register.  Includes POP, PUSH, ENTER and LEAVE
        opcodes, as well as references such as MOV AX,[BP+8]
        (which has an implied SS:).
        Also causes by loading SS with a descriptor that is marked
        "not present".


Trap    13    General Protection Fault (GPF)
        Americas Favorite, in the Windows 3.0 world, it is known as
        the UAE error.  The instruction tried to access data out of
        the bounds designated by the descriptors.  The access that
        failed can be a read, write or instruction fetch.  There are
        15 classifications of GPFs:
        1.  Exceeding segment limit when using CS, DE, ES, FS or GS.
        2.  Exceeding segment limit when referencing a descriptor
            table.
        3.  Transferring control to a segment that is not executable.
        4.  Writing into a read-only data segment or into a code
            segment.
        5.  Reading from an execute-only segment.
        6.  Loading the SS register with a read-only descriptor
            (unless the selector comes from the TSS during a task
            switch, in which case a TSS exception occurs.)
        7.  Loading SS, DS, ES, FS or GS with the descriptor of a
            system segment.
        8.  Loading, DS, ES, FS or GS with the descriptor of an
            executable segment that is not also readable.
        9.  Loading SS with the descriptor of an executable segment.
        10. Accessing memory via, DS, ES, FS or GS when the segment
            register contains a null selector.
        11. Switching to a busy task.
        12. Violating privilege rules.
        13. Loading CR0 with a PG=1 and PE=0.
        14. Interrupt or exception via trap or interrupt gate from
            V86 mode to privilege level other than zero.
        15. Exceeding the instruction limit of 15 bytes (this can
            only occur if redundant prefixes are placed before an
            instruction).
        To determine which condition caused the trap, you need
        the instruction, the contents of all associated registers,
        particularly the segment registers involved, then the various
        LDT, GDT and page control tables.  Lots of common coding
        errors cause the GPFs.  Even a stack imbalance will usually
        show up as a GPF.   Even MOV AX,7 MOV ES,AX or
        MOV AX,5 PUSH AX POP DS will get a GPF error.  You can't
        use a segment register for "temporary storage" of any
        old value the way you could on the 8086.  The values loaded
        into the segment registers are checked in protected mode.


Trap    14    Page Fault
        The page directory or page table entry needed for the address
        translation has a zero in the present bit, or the current
        procedure does not have sufficient privilege to access the
        indicated page.

Trap    15    (reserved)


Trap    16    Coprocessor Error
        The coprocessor asserted the ERROR# input pin on the 386
        (internal on the 486)


Trap    17    Alignment Check (486 and later)
        If enabled, this trap will occur if a data fetch does not
        occur on a word boundary.  I don't know of any software that
        activates this feature yet.  I have seen SCO UNIX get this
        error on early Cyrix processors, even though SCO had not
        enabled the feature.


Trap    18-32    (reserved)

[answered by     Frank Durda IV <[e-mail]>    and
        jim mullens [e-mail]  -or- [e-mail]]

-------------------------------------------------------------------------------

3.2.7    I have been getting a lot of "virtual memory exhausted" errors when
    I am compiling a program with a really big static array.  I have
    128Meg of memory and 8Gig of swap.  How can this be happening?

    If you are using Csh, you can simply unlimit your processes in
    your csh.cshrc file.  You can also modify your kernel so that the
    amount of memory available is less limiting.  J"org Wunsch
    ([e-mail]) provides us with this brief description:

    From a recent posting i just made, regarding the problem how much
    virtual memory one could get.

    | On the other hand, i've also changed the definitions you
    | mentioned. But i didn't like to modify the header files, and
    | actually, modifying the values is as easy as:
    |
    | options        "DFLDSIZ='(16 * 1024 * 1024)'"
    | options        "MAXDSIZ='(64 * 1024 * 1024)'"
    |
    | Include the above lines into your kernel's config file, reconfig
    | and rebuild it.
    |

    This is just a hint for those people poking around with compiling
    large source files. Especially, due to some gcc problems with large
    static arrays, compiling X applications with huge bitmaps would
    cause virtual memory trouble. Increasing the limits (o'course, as
    long as the h/w resources suffice) could help there.

    The default definitions for the above parameters are found in
    /usr/include/machine/vmparam.h.


3.2.8    Where can I learn more about all this?

    We've skipped over a lot of details here;  the straight dope comes from
    "Building Berkeley UNIX Kernels with Config", by Samuel J. Leffler and
    Michael J. Karels.

3.3    X11/XFree86/XS3
3.3.1    What options should I define to get the X extensions included?

    Once you have applied the patch kit, the only thing left to do is to
    modify the config file to include the following line:

    options    XSERVER, UCONSOLE

    recompile the kernel and the kernel should support X.

3.3.2    Where can I get the FAQ for 'X'?

    Answers to frequently asked questions about XFree86 on 386BSD are
    available by anonymous ftp from agate.berkeley.edu (128.32.136.1) in
    /pub/386BSD/0.1-ports/XFree86-1.2/XFree86-1.2-386BSD-FAQ.  It
    supplements the more introductory material distributed with XFree86
    1.2 in README.386BSD.  It also supplements Steve Kotsopoulos' more
    general 'X on Intel-based Unix' FAQ available by anonymous ftp from
    export.lcs.mit.edu in /contrib/Intel-Unix-X-faq.


3.3.3    Why does X drop characters when using xdm?   When I run xdm
    from the console, it keeps losing keystrokes and the shift keys
    don't always work.  Why?

        You need to run xdm with the -nodaemon flag.  The reason is
        xdm normally detaches from the keyboard.  This allows other
        processes (like getty) to return to reading from the keyboard.
        A race condition results, where some keystrokes are sent to
        xdm and others are sent to other processes.  Using the
        -nodaemon flag causes xdm to stay attached to the keyboard
        so no other process can use it.  This answer comes from Michael
        C. Newell ([e-mail])

    This bit of trivia is also covered in detail in the X FAQ and
    the README that accompanies XFree86.


3.4    Compiler and Library routines

    There are several questions that could probably be included
    here.  See also Section 4 for some of the more common 'missing
    modules' that also happen to be library routines.


3.4.1    Which C compiler is shipped with my Net/2 derived BSD?

    The standard compiler released with 386bsd 0.1 is GCC 1.38.  This
    version is considered by many people to be the most stable of
    the GCC versions.  All other Net/2 derived BSD systems have both
    1.38 and 2.4+ available.  NetBSD 0.9, for example, is completely
    compilable using GCC 2.5.5, which is included as the default
    compiler.  FreeBSD will also ship with the same compiler.

3.4.2    Where is libcompat.a?

    The library libcompat.a is (working from memory here) completely
    deprecated in 386bsd.  The only exceptions might be the re_comp
    and re_exec routines, which are discussed in detail in section 4.

    The easiest way around not having a libcompat.a is to simply link
    it to a small library, since virtually every other function that
    is expected in libcompat.a is already include libc.a.


--
TSgt Dave Burgess
NCOIC Applications Programming Branch
US Strategic Command, Offutt AFB, NE
[e-mail]