KNOWNBUGS

This file lists known problems with this release of FreeBSD

'hanging keyboard'
------------------
There are still problems with certain machines appearing to 'hang' on
bootup even though a prompt is there.  The most common machines that
exhibit these problems are Gateway 2000 machines with PHOENIX bios's but
other machines with PHOENIX bios also exhibit this behavior.
        The temporary solution until you can get the distribution
installed on your hard-drive is to 'bounce' on a key like shift or
num-lock (which works well since you can see when the keyboard comes
back to life) until the boot sequence is finished.  The keyboard will
work fine for installing FreeBSD onto the hard-drive.

/usr/bin/gdb:
        The gdb in the release will not work on shared objects nor will it
        work with C++ executables.  Please use the gdb in the ports area for
        debugging shared and/or C++ code.  This is just a work-around until
        we can transition to the new version of gdb completely.  See below.

/usr/gnu/bin/gdb:
        This is the gdb from the ports area (if installed), also known as
        gdb-4.11.  There is a problem using gdb-4.11 to debug a core-file
        generated by a binary which uses shared libraries. The problem is
        basically due to the fact that the shared libraries are mmap'ed at
        addresses in the memory space of the binary which are not accessible
        to gdb-4.11 at the time that it tries to examine the core-file. This
        usually manifests itself in "Cannot access memory at address <foo>"
        messages at startup and "#0  <bar> in end ()" when you try to do
        a backtrace ("bt").

        Workaround: start gdb-4.11 without reference to the core-file,
        e.g. "gdb fubar". Set a breakpoint in main and run the inferior
        so that gdb-4.11 can resolve references to the shared libraries.
        After this, use the "core-file" command to force gdb-4.11 to
        load the core-file, e.g. "core-file fubar.core". Since all
        shared library references were previously resolved gdb-4.11 can
        now access the shared libraries and things like "bt" now work.
        You will also be able to reference items previously on the stack
        (from the core file), but all globals will show up as zero'd.
        All these problems may be avoided if you compile the application
        with -static.

/sys/i386/isa/if_ep.c
        The 3c509 driver will hang under heavy network loads and take your
        machine off the network.  (Though the machine will continue to run with
        no network facilities)

        Workaround: Try a "ifconfig ep0 down" and a "ifconfig ep0 up"
        to get it running again.

/sys/i386/isa/bt742a.c
        The Bt445S and Bt747 controllers can cause problems when ISA DMA
        is selected as an option.  With the EISA controller the remedy is
        easy - simply turn it off using your EISA configuration utility.
        With the Bt445S, which is a VLB card, you must switch the undocumented
        "SW10" on "SB2" to the off position.  Also note that certain revisions
        of the Buslogic board (Revision C or earlier, firmware revision <3.37)
        will cause DATA CORRUPTION with systems containing more than 16MB of
        memory.  If you find this to be the case, temporarily remove your
        extra memory and contact Buslogic for an upgrade!

fsck:
        fsck can go into an endless loop in the repair/fsck cycle on
        a corrupted filesystem. The message "VALUES IN SUPER BLOCK
        DISAGREE WITH THOSE IN FIRST ALTERNATE" is very misleading.
        fsck compares the superblock with the alternate in the last
        cylinder group? So if this block is corrupt, you have no chance
        to get the filesystem repaired. You can answer on the question
        "UPDATE STANDARD SUPERBLOCK" with yes and get always the same
        error message on the next fsck.

$Id: KNOWNBUGS,v 1.15 1994/06/03 22:22:41 ats Exp $