- Repocopy from www/<lang> to head/<lang>/htdocs to eliminate duplicate information in the www and the doc directory. - Add various administration files to svnadmin. Approved by: doceng (implicit)
		
			
				
	
	
		
			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$
 |