Known bugs/complaints with the system:

- 2.5 Beta 2 release known issues: 2003-05-30
	The ramdisk size may be larger than needed. This will be revisited
	in a later release.

- 2.5 Beta 1 release known issues: 2003-05-21
	The module tools in newbusybox are disabled as they do not work.

	One must not access the Random Number Generator while doing DES/HASH.
	The /dev/random updating checks for this and does not access the RNG.

- 2.5 Alpha 1 release known issues: 2003-05-15

	This and all previous releases have a login deficiency in that
	the ID and password are wired into the login source code.

	Releases after this allow userland configuration option
	CONFIG_USE_TEXT_PASSWORDS selected to get the old behavior
	(not suggested).  If "not" selected, then the /etc/passwd is
	used for validation.

	If jffs2 file system is compiled into the kernel, then that
	will be used by the default /etc/rc script for having a
	/flash/etc directory that is initially populated from /etc/rc.
	These files can be changed via normal linux utilities.


- BETA TWO release known issues: 2003-03-06

	Insmod from busybox/newbusybox has been found to be at least
	partially broken.  Please use the regular ("modultils")
	version of insmod and other module utilities.

- BETA ONE release known issues: 2003-02-24

	Telnet client (from MSP to host) is broken

    The MTD partition map, uClinux/linux/drivers/mtd/map/brecis_flashmap.c,
    defined for use with bbload is misconfigured for all standard builds. 
    The MTD partition map defined for use with pmon works. Don't use 
	bbload with a jffs2 partition without reconfiguring this file.


- Last verified: 2002-12-18
    close(-1) causes system crash.
    Example code:
	    fd = open("/doesnotexist", O_RDONLY, 0);
	    close(fd);
	    fd = open("/doesnotexist", O_RDONLY, 0);
	    close(fd);
    The second close usually is enough to see the system having  problems.

- c++ programs take a lot of memory.  NOT verified, nor looked at, yet.
  November 2002.

- System seems really slow.  Where is the bottleneck? -- November 2002.

In uClinux/linux/mmnommu directory, file mmap.c:
- mmap does not accept all options passed to it.
- munmap does not work if exactly the address (and range) gotten from
  mmap is not passed.  A message is printed and nothing done, or it
  uses the original size passed by mmap when freeing.  You can not
  shorten the range -- like cut it in half and keep the latter half.

- malloc and free are implemented by doing mmap() and munmap() system
  calls.  This is a lot of overhead.  The uclibc from 2003-02-01 snapshot
  still does not have the nice memory allocator working correctly.
