1. Remove a rather strangely gratuitous bit of profanity

[unix-history] / 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 $