| 1 | This file lists known problems with this release of FreeBSD |
| 2 | |
| 3 | 'hanging keyboard' |
| 4 | ------------------ |
| 5 | There are still problems with certain machines appearing to 'hang' on |
| 6 | bootup even though a prompt is there. The most common machines that |
| 7 | exhibit these problems are Gateway 2000 machines with PHOENIX bios's but |
| 8 | other machines with PHOENIX bios also exhibit this behavior. |
| 9 | The temporary solution until you can get the distribution |
| 10 | installed on your hard-drive is to 'bounce' on a key like shift or |
| 11 | num-lock (which works well since you can see when the keyboard comes |
| 12 | back to life) until the boot sequence is finished. The keyboard will |
| 13 | work fine for installing FreeBSD onto the hard-drive. |
| 14 | Generally the problems go away at this point, but if it doesn't |
| 15 | you should install a SYSCONS kernel which doesn't experience these |
| 16 | keyboard problems. |
| 17 | |
| 18 | /usr/bin/gdb: |
| 19 | The gdb in the release will not work on shared objects nor will it |
| 20 | work with C++ executables. Please use the gdb in the ports area for |
| 21 | debugging shared and/or C++ code. This is just a work-around until |
| 22 | we can transition to the new version of gdb completely. See below. |
| 23 | |
| 24 | /usr/gnu/bin/gdb: |
| 25 | This is the gdb from the ports area (if installed), also known as |
| 26 | gdb-4.11. There is a problem using gdb-4.11 to debug a core-file |
| 27 | generated by a binary which uses shared libraries. The problem is |
| 28 | basically due to the fact that the shared libraries are mmap'ed at |
| 29 | addresses in the memory space of the binary which are not accessible |
| 30 | to gdb-4.11 at the time that it tries to examine the core-file. This |
| 31 | usually manifests itself in "Cannot access memory at address <foo>" |
| 32 | messages at startup and "#0 <bar> in end ()" when you try to do |
| 33 | a backtrace ("bt"). |
| 34 | |
| 35 | Workaround: start gdb-4.11 without reference to the core-file, |
| 36 | e.g. "gdb fubar". Set a breakpoint in main and run the inferior |
| 37 | so that gdb-4.11 can resolve references to the shared libraries. |
| 38 | After this, use the "core-file" command to force gdb-4.11 to |
| 39 | load the core-file, e.g. "core-file fubar.core". Since all |
| 40 | shared library references were previously resolved gdb-4.11 can |
| 41 | now access the shared libraries and things like "bt" now work. |
| 42 | You will also be able to reference items previously on the stack |
| 43 | (from the core file), but all globals will show up as zero'd. |
| 44 | All these problems may be avoided if you compile the application |
| 45 | with -static. |
| 46 | |
| 47 | /sys/i386/isa/if_ep.c |
| 48 | The 3c509 driver will hang under heavy network loads and take your |
| 49 | machine off the network. (Though the machine will continue to run with |
| 50 | no network facilities) |
| 51 | |
| 52 | Workaround: Try a "ifconfig ep0 down" and a "ifconfig ep0 up" |
| 53 | to get it running again. |
| 54 | |
| 55 | /sys/i386/isa/bt742a.c |
| 56 | The Bt445S and Bt747 controllers can cause problems when ISA DMA |
| 57 | is selected as an option. With the EISA controller the remedy is |
| 58 | easy - simply turn it off using your EISA configuration utility. |
| 59 | With the Bt445S, which is a VLB card, you must switch the undocumented |
| 60 | "SW10" on "SB2" to the off position. Also note that certain revisions |
| 61 | of the Buslogic board (Revision C or earlier, firmware revision <3.37) |
| 62 | will cause DATA CORRUPTION with systems containing more than 16MB of |
| 63 | memory. If you find this to be the case, temporarily remove your |
| 64 | extra memory and contact Buslogic for an upgrade! |
| 65 | |
| 66 | /usr/bin/find |
| 67 | find doesn't work on CDROM's. You need to call find with the |
| 68 | "fstype isofs" argument to get it working. The bug seems to be |
| 69 | in the "fts(3)" routines that find uses. |
| 70 | |
| 71 | $Id: KNOWNBUGS,v 1.13 1994/05/01 20:59:41 rgrimes Exp $ |