73 lines
3.5 KiB
Text
73 lines
3.5 KiB
Text
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.
|
|
|
|
$FreeBSD$
|