*BSD News Article 5096


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!spool.mu.edu!caen!uakari.primate.wisc.edu!usenet.coe.montana.edu!terra2!osynw
From: osynw@terra2.oscs.montana.edu (Nathan Williams)
Subject: 386BSD Bug Report 1/1
Message-ID: <1992Sep16.054657.485@coe.montana.edu>
Summary: Here it is!
Keywords: n
Sender: usenet@coe.montana.edu (USENET News System)
Organization: Montana State University
References: <1992Sep16.053926.29739@coe.montana.edu>
Date: Wed, 16 Sep 1992 05:46:57 GMT
Lines: 1648

U N O F F I C I A L    3 8 6 B S D     B U G     L I S T
--------------------------------------------------------
Date:		Sept. 15, 1992
Revision:	0.4

[Still welcoming criticism, helpful suggestions, etc...]

Send Bug Reports or Bug fixes to: osynw@terra.oscs.montana.edu
with a subject line of "386BSD BUGS"

Patches can be found on agate.berkeley.edu
	~pub/incoming/nate/patches.tar.Z

[Until Chris moves them, where they will be in the unofficial
directory under "osynw" or "williams"]


Index:
	BOOT and DISKLABEL - 
		If you machine won't boot, or it will boot but doesn't
		do what it is supposed to, check here

	INSTALL and CONFIGURATION -
		These are configuration problems that exist after you
		have successfully installed 386BSD 0.1.  If a program
		won't work, but it seems to run, check here.

	KERNEL - 
		These are REAL (tm) bugs in the operating system, with
		unofficial patches.  If you are getting kernel panics,
		or something in the system doesn't work right, check
		here

	PROGRAM -
		These are bugs in the programs that are distributed
		with 386BSD 0.1.  It's pretty scarce right now, but
		most of these bugs could probably be fixed fairly 
		easily by non-guru's.

	MISC -
		Anything else.  It will probably be split up as I get
		suggestions, and as the list grows.  

	BIG - 
		This is a section directed to large patches that I
		don't want to leave out, but I don't really want
		to put in misc. either.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-
BOOT AND DISKLABEL PROBLEMS

========================================
Bug Number:	BOOT001
Problem:
	386BSD 0.1 ignores the hard disk geometries given 
	in the CMOS ram on IDE disks 				OR
	My machine will not boot off an IDE drive.		OR
	various IDE drive problems
Explanation:
	Instead of getting the geometries from CMOS, it (apparently) gets
	the geometries direct from the disk itself. This causes problems
	when IDE disks are running in translation mode, because the BIOS
	is old and doesn't allow customized disk geometries.
Solution:
	Use the real parameters of the IDE drive in the CMOS table, and don't
	use the translation parameters.

	I don't have a source fix, sorry. Only fix then is to upgrade to
	a new BIOS, backup your hard disk, customize your CMOS and your
	DOS partitions (if needed) to fit in with the correct geometry,
	and restore.

	
Submitted by:
	wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
	(same)
========================================
Bug Number:	BOOT002
Problem:
	disklabel isn't working correctly.

	I can't boot after installing the software	OR
	I can't disklabel my second drive		OR
	System will not recognize second hard drive and/or it crashes
	when you try to access a second drive which is configured but not
	connected. 
Explanation:
	1) Can't boot.  /sys/i386/stand/wd.c is checking an invalid
	register after resetting the controller.  Depending on the
	controller, this may or may not hang forever.

	2) With partition 3 marked as 00 (unused), I can read from
	/dev/rwd1d and do disklabel -r wd1. I get the information from
	the first absolute sector of drive 2 in this case.

	With partition 3 marked as A5 (386BSD), doing anything with
	rwd1d, or disklabel -r wd1, the whole system hangs. The terminal
	driver seems to still be working, as characters such as ^V still
	work. The system must be reset at this stage.

	3) The wd driver has bugs in it.
	It will try to open all configured disks at boot time
	and print the identification strings.
Solution:
	1) Get patched binaries from agate.  OR
*PATCH*
	There is a file called noboot_wd.0_1 which fixes wd.c
	to allow you to boot off the hard-drive.

	2) None yet
*PATCH*
	3) There is a patch file available, called 2_disk.wd.0_1 which
	contains a cdiff which fixes these problems.

Submitted by:
	rd@phoenix.aii.com (Bob Thrush)  
	wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
	chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
	rd@phoenix.aii.com (Bob Thrush)  

	chmr@edvz.tu-graz.ac.at (Christoph Robitschko)

========================================
Bug Number:	BOOT003
Problem:
	shutdown -todos doesn't work as documented.
Explanation:
	The program complains about being unable to make the DOS
	partition bootable
Solution:
	Boot off a floppy that has fdisk on it and use fdisk to change
	the active partition to the DOS one.
	From Terry Lambert's FAQ-
	This will not work if your partition is larger than about 30K
	(the point at which DOS will use a 16 bit FAT).  Apparently, it
	will only work with 8 bit FATs, so if it is possible, use a
	smaller DOS partition, or several smaller partitions instead of
	one large one.
				
Submitted by:
	kevinz@storage.tandem.com (Kevin Zeigler)
Solved by:
	terry@icarus.weber.edu (Terry Lambert)
========================================
Bug Number:	BOOT004
Problem:
	Bringing the machine into single user mode doesn't work 
	correctly.				AND
	After people log out of the machine, who and last show
	them as still logged on.		AND
	Signal handling is screwed up when commands are run from
	/etc/rc.
Explanation:
	/sbin/init didn't set some internal flags correctly (Reboot, drain)
	This caused it to not execute /etc/rc again if the system was
	brought down to single-user and the back up again.
	It also tried to start multi-user mode when you tried
	hat or reboot in single-user (when the single-use shell was terminated
	by halt/reboot).

	/sbin/init wasn't cleaning up the utmp and wtmp files correctly.
	I made a patch that caused normal login/logouts to be updated 
	correctly, but single user shutdown and reboots still need
	some code added.

	In the process of cleaning up Dan L.'s code (init author)
	someone deleted several sigsetmask(0L) calls. So, assuming the
	mask isn't reset by fork or exec these days, /etc/rc is	being
	run with init's signal mask which blocks SIGHUP and SIGTERM.
Solution: 
*PATCH*
	There is a patch file available, called init_single.0_1 which
	contains a cdiff to correct the single user problem.
*PATCH*
	There is a patch file available, called init_utmp.0_1 which
	contains a cdiff to correct the utmp/wtmp problem.
*PATCH*
	There is a patch called init_signal.0_1 which contains a cdiff to
	add a sigsetmask to correct the signal problem
*NOTE*
	Mark Tinguely suggested using the init he posted to the
	comp.unix.bsd group a while back, since it doesn't seem to have
	the problems the current one does.

Submitted by:
	chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	(same)	
	tinguely@plains.nodak.edu (Mark Tinguely)
	pk@cs.few.eur.nl (Paul Kranenburg)
========================================
Bug Number:	BOOT005
Problem:
	386BSD does not use the values in the disklabel.  It will
	use the parameters in the /etc/fstab file.
Explanation:
	Even though the label was written that a partition was unused,
	the fstab file stated that partition was swap, and starting
	writing to that partition.
Solution:
	BE CAREFUL!!

Submitted by:
	wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
	(same)
========================================
Bug Number:	BOOT006
Problem:
	Machine will not boot 386bsd on a warm reboot.
Explanation:
	During a warm reboot, in wd.c the machine is picking up the same
	memory segment as before and so it appears that the drive is
	already open.
Solution:
	Bzero out the memory malloced by wdprobe.  There are a couple
	patches to the wd.c code, and one of them contains the 
	patch which bzeroes out the memory.

Submitted by:
	chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
	(same)
========================================
Bug Number:	BOOT007
Problem:
	WD8013EP ethernet card ('EtherCard Plus Elite 16') only works
	after a warm boot.
Explanation:
	On the first boot after switching on the workstation,
	I only get the well-known Reject xxxxx -Messages.
Solution:
	None-yet.  

Submitted by:
	chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:

========================================
Bug Number:	BOOT008
Problem:
	I get the error "isr 15 and error: isr 17" on an NE2000 card, OR
	I have some card on IRQ2 and it doesn't work; why?
Explanation:
	Some VGA cards use IRQ 2 for a vertical retrace interrupt.  Even
	when the interrupt is not enabled in the VGA, some cards drive
	IRQ 2 inactive instead of leaving the signal tristate.
Solution:
	If this is the problem, you can use Scotch tape to cover the IRQ
	2 signal on the VGA's ISA connector., or cut the IRQ trace on
	your board.

	An alternate solution would be to remove your ethernet card
	until you have rebuilt the kernel so that it expects it at an
	interrupt other than 2, re-jumper it, and re-install it.  This
	gets around both the tape and exacto knife solutions, plus you
	don't have to know which pin is IRQ2 (something you need a
	technical reference for the bus to find out).

Submitted by:
	The net.
Solved by:
	james@bigtex.cactus.org (James Van Artsdalen)

========================================
Bug Number:	BOOT009
Problem:
	Machine will not boot, have tried everything.
Explanation:
	Diskettes used:
		dist.fs (Jolitz .01.24), dist.fs, (cgd) fixit.fs (cgd)

	Copyright notice appears, disk access light stays on, cursor
	blinks, nothing else ever happens. I think I have seen a similar
	problem on this group but not the solution. Tried all three
	disks, disabled or disconnected all optional hardware, disabled
	various CMOS settings. All three disks had exact same problem. 

	486/33mhz OPTI-486WB with 8MB RAM
	OPTI chipset, AMI BIOS (6/6/91)
	"Groundhog Graphics" ET4000 SVGA card
	Quantum 234mb IDE drive
	1.2mb and 1.44mb drives (1.2mb is boot)
	All serial and parallel cards removed after initial failure
	All "shadow" options disabled in CMOS after initial failure
	All caches disabled in CMOS after initial failure
	Speed reduced to "16mhz" after additional failures
Solution:
	Try this!
*PATCH*
	There is a patch called keybd_delay.0_1 which will fix
	some of the booting problems encountered.
	But one needs to get a working system first before the patch can
	be applied, and I found a crazy hack for that.  At the point
	where the boot appears to be hanging, just unplug and replug the
	keyboard and the boot will continue normally. 
 
	Otherwise - None yet :(

Submitted by:
	barnesdo@cs.colostate.edu (douglas barnes)
Solved by:
	terry@uivlsisd.csl.uiuc.edu (Terry Lee)
	fpm@crash.cts.com (Frank Maclachlan)
========================================
Bug Number:	BOOT010
Problem:
	Machine will not reboot.
Explanation:
	reboot(8) syncs the disks, but the machine is then hung.  Also,
	the same things happens with <CTRL><ALT><DEL>.
	Under SysVR4, the keyboard controller is used to reboot the machine,
	but under 386BSD ???.
Solution:
	none

Submitted by:
	andrewh@molly.cs.monash.edu.au (Andrew Herbert)
Solved by:

INSTALLATION or CONFIGURATION

Problems that occur after you have installed 386BSD 0.1, or during
installation.

========================================
Bug Number:	INST001
Problem:
	I can't unpack the etc01 distribution	OR
	I get the error "too many files open" unpacking the etc01
	distribution. 
Explanation:
	The problem is from cat command leaving the file open after
	reading it. Since the default shell only allows 64 files open,
	it will not allow you to read more than 64 files.
Solution:
	Move all the etc01.* files to a different directory (I used
	/usr/tmp) so that they won't get deleted when you reboot.
	Boot up with the bin01 distribution loaded and login as root.
	Next (root uses csh as the default shell), do a
	cd /; cat /usr/tmp/etc01.* | zcat | cpio -iadmlu and wait for
	etc01 to unpack everything where it's supposed to go.

Submitted by:
	comp.unix.bsd
Solved by:
	(same)
========================================
Bug Number:	INST002
Problem:
	/usr/bin/tip doesn't work.
Explanation:
	tip is setuid "uucp".  It wants to create a lock file under
	/var/spool/lock, but lock is owned by root and mode 0755.  Since
	uucp can't create a lock, it dies.  
Solution:
	There are two solutions to the problem.  The first is to make
	tip setuid root (chmod 4755 /usr/bin/tip), but that is not the
	best solution.

	The preferred solution is to change the ownerships on the
	/var/spool/lock directory to allow tip to create a lock file. Another
	little problem is /var/spool/aculog is written by tip, so uucp
	also needs to own that.

	I added the /dev/com devices because I wanted to make sure tip
	could always connect to them.  This may be un-necessary.

Ex:
pc # chown uucp /var/spool/lock /dev/com* /var/spool/aculog

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	The net at large. 
========================================
Bug Number:	INST003
Problem:
	When I run ps, I get an error that it can't find _foo symbols...

	ps -u gives me a floating point exception.
Explanation:
	There are not enough symbols in the kernel. First of all, the
	kernel supplied with the distribution has been stripped, so
	there are no symbols in it.  Also, there are some missing
	symbols in the symbols.raw file which determines which symbols
	will be present in the kernel.  Bill Jolitz mentioned this in a
	net article, and said the fix for this was in patch1.  Patch1
	doesn't appear to be coming, but version 0.2 was mentioned
	recently.

	See the PROG009 entry.
Solution:
	386BSD 0.2 will hopefully have the fix for this.  Also, if you
	re-compile the kernel, most of the needed symbols will be in the
	kernel.

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	386BSD 0.2 (Jolitz, et al)
 	davidg%implode@agora.rain.com (David Greenman)
========================================
Bug Number:	INST004
Problem:
	Mtools doesn't work.
Explanation:
	Mtools is looking for devices that don't exist in the standard
	distribution. You need to create the device special files for
	mtools to use.
Solution:
	Use MAKEDEV to create the /dev/fd* devices required by mtools.

Ex:
pc # cd /dev
pc # sh MAKEDEV fd0 fd1
pc # dev_mkdb

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	(same)
========================================
Bug Number:	INST005
Problem:
	User's can't create files in their home directories.
Explanation:
	As distributed, home directories are owned by root and not by
	the user.
Solution:

Ex:
pc # cd /usr/nate
pc # chown nate.staff . .??*

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	(same)
========================================
Bug Number:	INST006
Problem:
	I can't create any new users.  I've edited the passwd file, but
	the changes don't seem to get added.
Explanation:
	386BSD is using a shadow password utility which hides the
	encrypted passwords in a separate, root-only readable file
	called master.passwd.  Also, there are database files created
	when you change the master.passwd file, so you need to go
	through the supplied "vipw" utility to add users.
Solution:
	Use the "/usr/sbin/vipw" program to add users.  After you have
	added the user(s), you can copy the /usr/share/skel/dot.* files
	into their home directory and change the ownerships of the
	directory and files to the user.

Ex:
pc # vipw
[Added user foo]
pc # mkdir /usr/foo
pc # cd /usr/foo
pc # cp /usr/share/skel/.??* .
pc # chown foo . .??*

[This assumes you have changed the names of /usr/share/skel/dot.cshrc to
/usr/share/skel/.cshrc.  It makes adding users much nicer]

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	The net at large.
========================================
Bug Number:	INST007
Problem:
	Normal users can't use vi (elvis).
Explanation:
	The /tmp and /var/tmp directories have incorrect permissions as
	distributed, and elvis can't write a temporary file to them.
Solution:
	Change the permissions on those directories.  I change them to
	everyone read, write, execute, plus the sticky bit so that the
	users can't delete other user's files.
Ex:
pc # chmod 1777 /tmp /var/tmp

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	(same)
========================================
Bug Number:	INST008
Problem:
	My computer does not have the correct time that is set in my
	BIOS.
Explanation:
	386BSD uses a file /etc/localtime which tells it which timezone
	you are in.  As distributed, it has a symbolic link to 
	/usr/share/zoneinfo/US/Pacific-New, the correct time for Bill
	and Lynne. You need to remove the old /etc/localtime and link it
	to the correct time for you area.

	There is code in the kernel which will use the DST in the BIOS,
	which was commented out.  There is a patch file to fix it.
Solution:
	rm /etc/localtime and make a new symbolic to link to the new
	time zone.
Ex:
pc # rm /etc/localtime
pc # date
Wed Jul 29 21:58 GMT 1992
pc # ln -s /usr/share/zoneinfo/US/Mountain /etc/localtime
pc # date
Wed Jul 29 14:59 MDT 1992
pc #

-NOTE-
	Some BIOS's automatically have Daylight Savings time set up, so
	you have three options.  
	  	1) Change the time in your BIOS so that 386BSD will have
		the correct time.   This is the best option.
		2) Hack up on of the datafiles in
		/usr/othersrc/share/zoneinfo/datafiles to have the
		correct time for your machine. 
		3) Fix the kernel code to read the DST value out of the
		BIOS
*PATCH*
	There is a patch called kernel_time.0_1 which allows the kernel	
	to read the DST from the BIOS.
-ENDNOTE-

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	(same)
	arnej@lise.unit.no (Arne Henrik Juul)
========================================
Bug Number:	INST009
Problem:
	man -k doesn't work.  
Explanation:
	You need to create the whatis.db file. However, there is a ^H in
	all the man pages that messes up apropos, with needs to be
	stripped out. 
Solution:
	in /usr/othersrc/share/man/Makefile, add a col -b to strip out
	the ^H's from the man pages.
Ex:
makedb:
.
.
	done | sort -u > whatis.db
becomes:
	done | col -b | sort -u > whatis.db

*PATCH*
	There is also a patch file called man_make.0_1 which
	contains the fix to the makefile.

Submitted by:
	James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
	(same)
========================================
Bug Number:	INST010
Problem:
	Slip is configured and started in my /etc/rc file,  but doesn't
	seem to work  
Explanation:
	Somehow slattach is being killed when run from /etc/rc.
Solution:
	add a nohup to the slattach command in /etc/rc.

Ex:
nohup slattach /dev/com1 2400

Submitted by:
	wkt@csadfa.cs.adfa.oz.au (Warren Toomey)	
Solved by:
	(same)
========================================
Bug Number:	INST011
Problem:
	I can't get my tape drive to work (SCSI).
Explanation:
	The /dev/ras4* device special files are wrong in the
	distribution.  You need to make new ones using the mknod
	command.
Solution:
	rm /dev/ras4*, and create new ras4* nodes.

Ex:
pc # cd /dev
pc # rm /dev/ras4*
pc # mknod ras4a c 13 32
pc # mknod ras4d c 13 35

Submitted by:
	comp.unix.bsd
Solved by:
	wjolitz@soda.berkeley.edu (W. Jolitz)
========================================
Bug Number:	INST011
Problem:
	There is a serious bug in the bad block handling.
Explanation:
	In 0.1, the driver checks the bad block list for every block,
	but the test is wrong for reads of multiple blocks - it only
	tests if the initial block is on the list.  And when the initial
	block is on the list, it doesn't split up the i/o, so good
	blocks after the bad one are messed up.
Solution:
	I think there is a problem in the 386BSD 0.1
	'usr/src/sys.386bsd/i386/isa/wd.c' when the first sector in a
	multi-sector read or write request is present in the bad144
	table. The bad144 table search code at line 382 finds the sector
	in the bad144 table and replaces the block number, cylinder,
	head, and sector addresses with values corresponding to the
	replacement sector.  At line 434, the sector count register is
	loaded with the number of sectors in the entire transfer.  This
	is wrong; it *MUST* be set to *one* sector.  A read would return
	the wrong data in sectors after the first; a write would
	*overwrite* other replacement sectors or even the bad144 table
	on the last track.
*PATCH*
	There is a file called bad_wd.0_1 which contains a fix
	to the bad block handling code in wd.c

Submitted by:
	bde@runx.oz.au (Bruce Evans)
Solved by:
	fpm@crash.cts.com (Frank Maclachlan)
KERNEL

386BSD 0.1 kernel file bugs.  (Anything that is below /sys)

[but NOT boot stuff or disklabel]

========================================
Bug Number:	KERN001
Problem:
	Machine panics with: kmem_malloc: kmem_map too small
Explanation:
	I have seen two reasons for this.  The first is the most
	common.

	1) There are not enough map entries for computers with >12 MB of
	   memory.
	2) The problem I am having stems from the fact that the
	drive comes back with nonsense when hit with a SCSI read
	capacity command. The block size is way out of line.  If I retry
	the command, all is well. I can not figure out why the drive
	responds normally *every* time when configured as SCSI id 0, or
	1.  It may be possible that the buffer is getting stepped on
	after the command has completed.

Solution:

*PATCH*
1)
	There is also a patch file called kmem_panic.0_1 which
	contains the below fix.
in the file /sys/vm/vm_map.h, there is a:
#define		MAX_KMAPENT	500
which needs to be
#define		MAX_KMAPENT	1000

2) Hack the as driver to retry and get the block size when it is way
   out of line.

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
	jones@cs.Buffalo.EDU (Terry A. Jones)
Solved by:
	wjolitz@soda.berkeley.edu (W. Jolitz)
	scott@pita.cns.ucla.edu (Scott Burris)
========================================
Bug Number:	KERN002
Problem:
	The following simple program would hang the computer:

#include <stdio.h>

main()
{
        char    data[8192];
        FILE    *f;

        f = fopen("Test2.file", "w+");
        while(1)
        {
                fread(data, 1, 8192, f);
                rewind(f);
                fwrite(data, 1, 8192, f);
        }
}

Explanation:
	There is some sort of bug in the scheduler relating to charging
	a process for the CPU while doing heavy disk I/O... If you try
	out a similar program  which does main(){while(1);} you get the
	proper priority of the process as  well as proper load averages.
	If however you run the above not only does the priority
	mechanism fail but I imagine the load average is not correct.

Solution:
	None yet.  But....

	The bug is probably in kern_clock.c or in kern_synch.c ... I
	have not tried to investigate this further as it may be a
	problem with the system as a whole and not a simple bug. (ie.
	relating to the assigned interrupt levels in the kernel...)

Submitted by:
	pao@cd.chalmers.se (Andrew Olausson)
Solved by:

========================================
Bug Number:	KERN003
Problem:
	System hanging under heavy disk activity and high load
Explanation:
	Things are getting put to sleep waiting for pages, and
	are never being awakened.

	This problem was noticed when using DDB.  I found that there 
	were *NO* processes on any of the run queues, and a lot of
	processes waiting for disk pages...)
Solution:
	None yet.

*NOTE*
	Karl Lehenbauer (karl@neosoft.com) made mention of the fact that
	in 0.0, the swap partition must be on cylinder boundaries.
	The check for this is to run disklabel -r wd0 (as0)
	and if there are stars after each partition, the partition
	is NOT on a partition boundary.  After hearing this, I hand
	installed 386BSD, and I have not had any problems with machine
	lockups because of heavy cpu/load. (though I have had lockups
	for other reasons :-)

	dawes@physics.su.oz.au (David Dawes) was having the lockups
	on his machine after installing the patches, and after 
	increasing his swap space and aligning it on cylinder bound-	
	aries, his lockups went away. 
	
	If you can't compile a kernel because of lockups, you may
	be able to mount the filesystem to do synchronous writes.  This
	is very slow, but it *may* help the lockups until you can
	compile the fixed kernel.
*ENDNOTE*

*PATCH*
	There was mention of this bug in a net article, with a patch by
	Bill Jolitz, which may or may not solve this problem.  It was
	kind of	vague, but you may try it.  However, in the same
	article, Bill did mention that main purpose of version 0.2 was
	to fix this bug.
	There is a file called heavy_load.0_1 which is the fix that
	Bill mentioned in his article.

Submitted by:
	cgd@agate.berkeley.edu (Chris G. Demetriou)
Solved by:
	wjolitz@soda.berkeley.edu (W. Jolitz)
========================================
Bug Number:	KERN004
Problem:
	Various machine lockups when doing com stuff.
Explanation:
	kermitting through com1, or downloading via zmodem

	Occasionally, I get a console message: communication disconnect
	and the machine is locked up.  No panel lights, no 3-finger
	salute.  A hard reset was required to bring the machine back to
	life.
	
	Other times, kermit was put into a state where a
	kill -9 would not even do anything, so a reboot was necessary
	to use the modem.  The machine was still usable (via screen)
	so serial communication was only affected.
Solution:
	I suspect the com driver.  Maybe replace it with the beta com
	driver on agate.berkeley.edu by Chris D.
*NOTE*
	[I had more problems with Chris's driver than I did with
	 the stock driver.  This may be a single case, but I thought
	 I would note it.  This by no means says that Chris is a bad
	 programmer or anything, but that I had problems with that 
	 driver]
*ENDNOTE*

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:

========================================
Bug Number:	KERN005
Problem:
	The serial ports don't work at all on my machine.
Explanation:
	There is probably a card in you machine that has IRQ 4.  Check
	out all your cards, and make sure there is nothing that is using
	IRQ 4.
Solution:
	Change the offending card to NOT use IRQ 4. 

Submitted by:
	terry_lambert@gateway.novell.com (Terry Lambert)
Solved by:
	(same)
========================================
Bug Number:	KERN006
Problem:
	Flashing multi-colored characters and a ptdi81061 prompt.
Explanation:
	The problem is that the code checking the return from the read of
	the CMOS RAM value falls through in the case of an invalid value.
	What really is needed is the non-existence "else" case for a bad
	CMOS setup, which goes and probes memory to see it's size.  What
	currently happens is that the code falls through, the Maxmem is set
	to zero, and the maxmem and physmem are set to -1 (this is a bad
	thing).
Solution:
	The quick and dirty workaround:  If you download dist.fs from
	Chris G. Demetriou's upload on agate.berkeley.edu for the hard disk
	boot problem (this MUST be dist.fs, and not one of the other dist.fs
	files modified for Isolan or WD ethernet and named something else!),
	you can use uzap (available for anon ftp from wuarchive.wustl.edu,
	located at mirrors2/unix-c/editors/uzap.tar-z) to binary edit the
	dist.fs at byte offset 946834; it should be changed from 81FE8002
	to 81FE7F02.  This is the compare for 640K in the bogus code.  You
	can look for the pattern 81FE8002 in the other *.fs files, including
	fixit.fs, and change it there, if you MUST use one of them instead.

	The more preffered fix comes from Alan Yang at HP.

	For those of you are using HP VECTRA QS/RS model, you probably
	have observed the "flashing multi-colored characters and
	ptdi81061 prompt" error.  The cause for that had been described
	in the FAQ posting.  The way that you can get around with the
	problem is by doing:

  	 1.  run setup, and type 'yada' at the Enter option number and
	 press <ENTER>:prompt 
	 2.  select 1 from next menu to turn off the EX_BIOS and
	 HIL_BIOS.
	 3.  Exit after that.

	HP Vectra QS/RS system is using 4k memory for EX_BIOS and HP HIL
	bios at the bottom of 640K.  By doing the above, you are turning
	off the bios and the system gives you back the 4k memory which
	allows the 386bsd0.1 to boot and install successfully without
	any patches.

Submitted by:
	terry_lambert@gateway.novell.com (Terry Lambert)
Solved by:
	(same)
	ayang@pollux.svale.hp.com (Alan Yang)
========================================
Bug Number:	KERN007
Problem:
	nroff doesn't work				OR
	I can't get 386BSD to recognize my #! scripts	OR
	Even after I change the permissions of a certain program to
	no execute, users can still execute it.
Explanation:
	/sys/kern/kern_execve.c.c has bugs:

	kern_execve.c needs to have modifications to add the #!
	checking

	This is a big security hole. In 0.0, a VOP_ACCESS was used, but
	root always succeeds (and tries to execute anything). But the
	check for a single execute bit it wrong too. I put the
	VOP_ACCESS back but also checked to make sure at least one
	execute bit is on before root can execute the file. I also
	checked if the filesystem was mount for execution:
Solution:
*PATCH*
	There is a file called kern_shell.0_1 which adds the
	#! checking to kern_execve.c.
*PATCH*
	There is a file called kern_perms.0_1 which contains
	the permission and execute bit fixes.

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
	tinguely@plains.nodak.edu
Solved by:
	pk@cs.few.eur.nl (Paul Kranenburg)
	tinguely@plains.nodak.edu

========================================
Bug Number:	KERN008
Problem:
	As distributed, you can't make a kernel because the makefile
	doesn't include vers.c/vers.o.
Explanation:
	You need to patch the /sys/i386/conf/Makefile.i386 to
	add dependencies and such for vers.o. 
Solution:
	Chris Demetriou has a patch on agate that fixes the
	problem.
*PATCH*
	I have made chris's patch available, which is in the Makefile.cgd
	directory.  There are some more patches in there.  Check the
	README for more info.

Submitted by:
	James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
	(same)
	cgd@agate.berkeley.edu (Chris G. Demetriou)
========================================
Bug Number:	KERN009
Problem:
	Kernel panics from using floating point routines at the same
	time in two programs.			OR

	a panic with a description like -
	trap type 22 .....
Explanation:
	This panic is typical.  22 is T_DNA in <machine/trap.h>.  DNA is
	for device-not-available which is used to help switch FPU
	contexts.  It's not supposed to be generated from inside the
	kernel, but is (or at least appears to be generated in the
	kernel after the kernel screws up trap frame stuff).

	It may also show up quickly with one copy and with another
	program causing a lot of context switches and/or a lot of
	interrupts (run a serial download to get a lot of interrupts).
Solution:
	None yet

Submitted by:
	bde@runx.oz.au (Bruce Evans)
Solved by:

========================================
Bug Number:	KERN010
Problem:
	If you set a breakpoint in a program under gdb, the breakpoint
	will not be cleared and you will get a trace trap if you
	run the program again.
Explanation:
	The 386 does not generate a page protection fault while it is
	executing in supervisor mode :-(, so copy on write handling
	never takes place when the kernel stuffs data into a process's
	text- or any other non-anonymous segment. So these cases must be
	explicitly checked for.

Solution:
*PATCH*
	There is a patch which supposedly fixes this particular 
	instance of the bug, but is not a complete fix.  It is
	called gdb_bp.0_1.

Submitted by:
	bde@runx.oz.au (Bruce Evans)
Solved by:
	pk@cs.few.eur.nl (Paul Kranenburg)
========================================
Bug Number:	KERN011
Problem:
	Double Density 3.5" floppies do not work correctly.
Explanation:
	The code in the fd.c driver does not have an entry for the 3.5"
	720K floppy.
Solution:
*PATCH*
	There is a file called fd_720.0_1 which contains a patch to 
	correct this problem.

Submitted by:
	rahn@sage.cc.purdue.edu (Dale Rahn)
Solved by:
	rahn@sage.cc.purdue.edu (Dale Rahn)
========================================
Bug Number:	KERN012
Problem:
	The buffer cache has very bad performance.		OR
	A process can't grow greater than 6MB data/stack.
Explanation:
	A good explanation for these is included in the patch.
Solution:
*PATCH*
	The is a file called fs_buf.0_1 which contains explanations and
	bugfixes for the FS and virtual memory limitations for
	386BSD.

Submitted by:
	davidg%implode@percy.rain.com (David Greenman)
Solved by:
	davidg%implode@percy.rain.com (David Greenman)
========================================
Bug Number:	KERN013
Problem:
	Kernel panics when reading /dev/drum
Explanation:
	There is an improper initialization buffer in the routine
	physstrat
Solution:
*PATCH*
	There is a file called drum_fix.0_1 which contains a patch
	which fixes the /sys/kern/kern__physio.c

Submitted by:
	pk@cs.few.eur.nl (Paul Kranenburg)
Solved by:
	pk@cs.few.eur.nl (Paul Kranenburg)
========================================
Bug Number:	KERN014
Problem:
	Machine reboots or crashes when rapidly scrolling backwards.	
Explanation:
	The problem is caused by sput() in pccons being reentered while
	processing escape sequences.  Sput(), however, is not reentrant;
	in this particular case, the parameter to the scroll down code
	was being modified when sput() was reentered resulting in the
	kernel being scrolled down (or somewhere).  :-(
Solution:
*PATCH*
	There is a file called scroll_back.0_1 which fixes pccons.

Submitted by:
	fpm@crash.cts.com (Frank MacLachlan)
Solved by:
	fpm@crash.cts.com (Frank MacLachlan)
========================================
Bug Number:	KERN015
Problem:
	DMA handling is incorrect.
Explanation:
	At line 389 in isa_dmarangecheck(), the automatic variable
	priorpage is used without being initially set to 0.  This causes
	the function to flag special handling for virtually all DMA
	transfer requests. Also, no check is made for DMA requests
	crossing DMA page boundaries (64k for DMA chans 0..3, 128k for
	DMA chans 4..7).  This problem is masked by priorpage not being
	initialized - almost all DMA is done to/from safe 'bounce'
	buffers which don't cross DMA page boundaries and the data are
	block moved from/to the user's buffer.
					
Solution:
*PATCH*
	There is a file called dma_page.0_1 which fixes the dma
	code to work correctly.

Submitted by:
	fpm@crash.cts.com (Frank MacLachlan)
Solved by:
	fpm@crash.cts.com (Frank MacLachlan)
PROGRAM

Bugs in programs distributed with 386BSD.

========================================
Bug Number:	PROG001
Problem:
	chmod +t or chmod +s do not work.  You must use the octal
	notation to get those permissions set.
Explanation:

Solution:
	/usr/bin/chmod does not have the code for +t or +s, so it should
	be trivial to fix this bug.
*PATCH*
	A yacc version of chmod was sent to me.  If you wish to use it,
	it is called yacc_chmod.0_1  It appears to be a fully working
	version of chmod, and I have made it my default version.

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	deraadt@newt.cuc.ab.ca (Theo Deraadt)
========================================
Bug Number:	PROG002
Problem:
	diff sometime thinks a text file is a binary file.
Explanation:
	Not sure, probably a bug in diff.  Diff appears to be a Gnu one,
	so getting a newer version may solve the problem.
Solution:
	Get a different version of diff.

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:

========================================
Bug Number:	PROG003
Problem:
	ln -s foo bar doesn't give an error if bar already exists.
Explanation:
	There a bug in ln.
Solution:
	None yet.
Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:

========================================
Bug Number:	PROG004
Problem:
	running rogue will reboot the system.
Explanation:
	when rogue updates it's score file, you get a automatic reboot. 
	No panic, no crash dump, nothing but a reboot.
Solution:
	don't play rogue :-(

Submitted by:
	bs@germany.eu.net (Bernard Steiner)
Solved by:

========================================
Bug Number:	PROG005
Problem:
	The stock stty in the bin01 distribution is unable to set the
	baud rate correctly.
Explanation:

Solution:
	Recompiling stty solves the problem.

Submitted by:
	chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
	(same)
========================================
Bug Number:	PROG006
Problem:
	talk does not work, and dies with a "Can't bind socket: Can't
	assign requested address"
Explanation:
	This can happen when there is no network interface for the IP
	address of the machine.
Solution:
	Add "127.1 `hostname`" to /etc/hosts if running standalone, or ensure
	that the `hostname` entry corresponds with an interface address as
	returned by "netstat -i".

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	andrew@werple.pub.uu.oz.au
========================================
Bug Number:	PROG007
Problem:
	Less will not compile as distributed
Explanation:
	It's using the wrong regular expression package
Solution:
	It has a define in defines.h to choose the correct
	package.  You need to define REGCOMP 1.
*PATCH*
	There is a patch called less.0_1 which fixes the
	define to allow less to compile

Submitted by:
	karl@neosoft.com (Karl Lehenbauer)
Solved by:
	(same)
========================================
Bug Number:	PROG008
Problem:
	vi (elvis) doesn't handle yanking and multiple files.
Explanation:
	This was the result of three lines near the end of the
	tmpabort() function (in tmp.c) that unconditionally closed and
	unlinked the temp file. These three lines were not present in
	the distribution of elvis 1.5 that I had gotten back in April
	(from prep.ai.mit.edu, I believe).

Solution:
*PATCH*
	There is a patch file called elvis.0_1 which contains a 
	snippet of the discussion and a patch which should fix
	elvis.

	Also, version 1.6 has been released, and is on Simtel20, so
	it may be to our advantage to upgrade to the newer release.

Submitted by:
	bob%obiwan.UUCP@cs.utexas.edu (Bob Willcox)
Solved by:
	bob%obiwan.UUCP@cs.utexas.edu (Bob Willcox)
	barnesdo@CS.ColoState.EDU (douglas barnes)
========================================
Bug Number:	PROG009
Problem:
	ps -u gives me a Floating Point exception	OR
	The Resident Memory Size (RSS) and %MEM
	reported are incorrect				OR
	ps is *slow*
Explanation:
	The kvm library routine has some problems, and ps was
	missing a function declaration.
Solution:
*PATCH*
	There is a file called kvm_ps.0_1 which contains an
	explanation and the fixes to kvm and ps.

Submitted by:
	comp.unix.bsd
	davidg%implode@percy.rain.com (David Greenman)
Solved by:
	davidg%implode@percy.rain.com (David Greenman)

MISC

The catch-all list where I am not sure where to put the bugs.

This list will probably be fragmented into other smaller lists.

========================================
Bug Number:	MISC001
Problem:
	/dev/stdout does not work.  I assume /dev/stdin does not either,
	but I don't know how they are set up.
Explanation:
	 Try doing a make tags in one of the source directories, and the
	error: /dev/stdout: Device not configured will occur.

	A recent post made notice of that fact the /dev/std* had
	a major device of 53.  I am not sure what major device these
	should be, but I think 53 is probably a little high.
Solution:
	None yet.
	
Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:

========================================
Bug Number:	MISC002
Problem:
	The man pages for magic and file are incorrect.
Explanation:
	The are too many dots before each command, so the dots must be
	removed.
Solution:
	Remove one of the dots in the magic and file manpages before the
	name.

Submitted by:
	James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
	(same)
========================================
Bug Number:	MISC003
Problem:
	/usr/libexec/locate.updatedb doesn't work.
Explanation:
	In /usr/libexec/locate.updatedb it calls the sort program.  The
	arguments are "-T /var/tmp" for the temp directory.  The sort
	program distributed does not have a "-T" option.
Solution:
	Remove the "-T /var/tmp" from locate.updatedb

Submitted by:
	James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
	(same)
========================================
Bug Number:	MISC004
Problem:
	When linking program FOO, I can't find stty and gtty.
Explanation:
	These routines don't *officially* exist in 386BSD.  They
	are easy to add, though.
Solution:

#define gtty(fd, argp) ioctl(fd, TIOCGETP, argp)
#define stty(fd, argp) ioctl(fd, TIOCSETP, argp)

*PATCH*
	There is a patch called gtty_add.0_1 which also contains this
	information.

Submitted by:
	rivers@ponds.uucp (Thomas David Rivers)
Solved by:
	(same)
========================================
Bug Number:	MISC005
Problem:
	Multiple errors compiling programs with keywords like
	TIOCSETP, TIOCGETP, ECHO, RAW, etc ...

Explanation:
	386BSD is using the new termio library, instead of the older
	ioctl library.
	If the program you are compiling is using the ioctl.h 
	include file, then you need to add another for for 386BSD.
Solution:
	Just before your program include <sys/ioctl.h>, include
	<sys/ioctl_compat.h>.

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	(same)
========================================
Bug Number:	MISC006
Problem:
	mountd hangs when exporting a file system sub-directory
Explanation:
	If /etc/exports contained:

		/usr/src -root=0

	And /usr was not a file system unto itself, mountd went into an
	infinite loop and stayed there.
Solution:

	The fix:  in /usr/src/sbin/mountd/mountd.c, line 592 reads:
		while (*cp == '/' && cp > ep->ex_dirp)
	and should read:
		while (*(cp-1) == '/' && cp > ep->ex_dirp)
Submitted by:
	roe@unibase.sk.ca (Roe Peterson)
Solved by:
	(same)
========================================
Bug Number:	MISC007
Problem:
	One needs to type 2 ^V's in screen to get one to show up.
Explanation:
	When screen is compiled with POSIX termios, you should disable
	ICANON and IEXTEN to get raw mode correctly.
Solution:
	In the code that sets the screen to raw mode, add IEXTEN to the
	flags to disable.
Submitted by:
	sim@cory.berkeley.edu
Solved by:
	(same)
========================================
Bug Number:	MISC008
Problem:
	/usr/include/sys/termios.h doesn't setup it's environment
	correctly.
Explanation:
	In /usr/include/sys/termios.h, NCCS is only set if _POSIX_SOURCE
	is not defined. 
Solution:
	If you exchange lines 80 and 81,  (ie put the line '#define NCCS
	20' after the #endif) it works. 

Submitted by:
	chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
	(same)
========================================
Bug Number:	MISC009
Problem:
	select(2) doesn't work with the com driver.	OR
	The kernel reports 'com1: silo overflow' 	
	although I am only using com2.			OR
	X doesn't work correctly with my mouse		OR
	X is using a lot of resources.
Explanation:
	The com driver uses (minor(dev) -1) as the unit number, so
	/dev/com1 is COM0 and /dev/com2 is COM1;
	However, ttselect() also accesses some structures of the com driver,
	but with an index of (minor(dev)). So, select() on /dev/com1
	really uses /dev/com2, and select() on /dev/com2 uses an undefined
	entry and (usually) returns true.

Solution:

*PATCH*
	There is a patch called select.0_1 which is a patch to the 
	stock 0.1 driver.  I believe that Chris Demitrou has also
	included this fix into his driver also.

Submitted by:
	chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
	comp.unix.bsd
Solved by:
	chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
========================================
Bug Number:	MISC010
Problem:
	fread(a,0,1,b) returns zero in old 4.3 and one in 386BSD.
Explanation:
	I don't think this is a bug - however, it is inexplicably
	different from the usage on the evil old VAX 11/750 running
	4.3BSD+SUNNFS (take it from me, very very very old).
Solution:
	Use of code:  only used in obscure cases (as should be obvious)
	to check for EOF condition without having to write a binding for
	feof.  So, check for the special cases.

Submitted by:
	comrade@uniwa.uwa.edu.au (Peter Cooper)
Solved by:

========================================
Bug Number:	MISC011
Problem:
	Sockets have a real problem with raw mode sockets. 
Explanation:
	This is actually a 0.0 bug - but it may be worth checking in 0.1.
	If you Telnet into 386bsd (using NCSA Telnet from a DOS PC),
	login and 'stty sane'. Your session will appear to lockup. It
	appears that  characters are going from Telnet to 386bsd OK, but
	nothing comes back.
Solution:
	None yet.

Submitted by:
	raz@socs.uts.EDU.AU
Solved by:

========================================
Bug Number:	MISC012
Problem:
	The library routines toupper and tolower are broken as far as
	ANSI is concerned.
Explanation:
	The library functions as supplied don't check to see if the
	character is lower/upper, and changes it anyway.
Solution:
*PATCH*
	There is a patch file available, called lib_toupper.0_1 which
	contains a cdiff to correct the problem.

Submitted by:
	wiljo@freeside.ki.open.de (Wiljo Heinen)
Solved by:
	(same)
========================================
Bug Number:	MISC013
Problem:
	I can't set up a secondary swap partition on a 
	different drive.  The message is:
	/dev/wd1b: device not configured
Explanation:
	If the config is setup properly (so that the counts of NWD in
	wd.h are appropriate), then config should generate the above itself.
	However, config had some bugs in it.
Solution:
*PATCH*
	There is a file called config_2drive.0_1 which fixes some errors
	that 386BSD has with two drives (and possibly two controllers).

Submitted by:
	wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
	tih@barsoom.nhh.no (Tom Ivar Helbekkmo)
========================================
Bug Number:	MISC014
Problem:
	386BSD did not recognize my ethernet card (WD8003- EtherCard
	PLUS Elite) 
Explanation:
	/sbin/init was not executable.  This caused many reboots with
	the message ("init died", "saving RAM..." or such)
	After fixing and re-booting, 386BSD no longer knew my EtherCard.
 Solution:
	boot up DOS , start diagnose program and ... well it said, "LAN
	Address ROM" faulty.
	run ezsetup, store the configuration (no changes) anew, run
	diagnose -> board tests fine, boot 386BSD -> ethernet ok.

Submitted by:
	wiljo@freeside.ki.open.de (Wiljo Heinen)
Solved by:
	(same)
========================================
Bug Number:	MISC015
Problem:
	These are less than bugs, but will call them major
	annoyances.

	1) kernel panics don't allow you to read what happened
	2) timezone in the config file is not used
	3) date/time bugs
		a) GMT must be in CMOS
		b) running date doesn't set the CMOS time
		c) if daylight savings time is used, must redo CMOS time
	4) console message are doubled/tripled
	  [One duplicate is from syslog telling both /dev/console and
	   all users logged in as root]
Explanation:
	Things are (hopefully) trivial things that need to be fixed.
Solution:
	None yet.

Submitted by:
	terry@spcvxa.spc.edu (Terry Kennedy)
Solved by:

========================================
Bug Number:	MISC016
Problem:
	NCSA tn3270 (IBM PC program) can't talk with 386BSD-0.1 via
	ethernet
Explanation:
	The solution.
Solution:
	Recompile telnetd w/o KLUDGELINEMODE

Submitted by:
	merlin%neuro.usc.edu@usc.edu (merlin)
Solved by:
	(same)
========================================
Bug Number:	MISC017
Problem:
	when ec0 is ifconfig'd, a bogus 'ecinit' prints on console.
	There is a "extra" ecinit in the 
Explanation:
	A printf statement with "ecinit" was left in the ec driver.
Solution:
	Hack 'ecinit' text out of ec.c.
	
Submitted by:
	terry@spcvxa.spc.edu (Terry Kennedy)
Solved by:
	terry@spcvxa.spc.edu (Terry Kennedy)
========================================
Bug Number:	MISC018
Problem:
	The /etc/crontab file doesn't get run.		OR
	cron doesn't work.
Explanation:
	The cron that is supplied with 4.X BSD is Paul Vixie's
	cron, which has separate crontab files contained in
	/var/cron/tabs/username.

Solution:
	Move the /etc/crontab file to /usr/cron/tabs/root, and edit
	it to be in the new crontab format.

Submitted by:
	jimj@miller.cs.uwm.edu (James Jegers)
Solved by:
	jimj@miller.cs.uwm.edu (James Jegers)
========================================
Bug Number:	MISC019
Problem:
	NFS bugs.
		Appending to already existing files.
		IBM AIX 3.2 client fixes.
		reserved ports for NFS.
		Subdirectories can be exported.
Explanation:
	In the patch.
Solution:
*PATCH*
	There is a file called nfs_misc.0_1 which contains information
	and a patch which fixes the above mentioned problems.

Submitted by:
	comp.unix.bsd
	root@snowhite.cis.uoguelph.ca (gopher I)
Solved by:
	comp.unix.bsd
	root@snowhite.cis.uoguelph.ca (gopher I)

========================================
Bug Number:	MISC020
Problem:
	Sometimes a program running in raw mode would 'hang' on a 
	keypress until a second key was typed.
Explanation:
	The RB_LEN() macro in /usr/include/sys/tty.h is sometimes out by
	1.  In particular, in the case of a buffer containing a single
	character at the very end, RB_LEN() would return 0.  This caused
	ttread() to block until a 2nd character was read before
	delivering them both.  The user would find RAW mode programs
	such as vi would occasionally (1 in 1024 keypresses) get "stuck"
	requiring a second keypress to bring it to life.
Solution:
*PATCH*
	There is a file called two_keypress.0_1 which fixes the 
	RB_LEN macro.

Submitted by:
	Stephen McKay
Solved by:
	Stephen McKay
BIG PATCH

This addition is for patches I didn't know what to do with.  I
didn't want to ignore them, but neither did I know where to
file them, so here they are.

========================================
PATCH Number: BIG001
Description:
	
	This set of patches is an attempt to make adding a SCSI disk
	safer and easier.  There are patches to the scsi code,
	disklabel, and the ufs disk code.  It's pretty self explanatory,
	so have at it.

*PATCH*
	In the big directory under the patches, called lotsa_scsi.0_1.

Submitted by:
	fty@bizarre.rtpnc.epa.gov (Frank Terhaar-Yonkers)
	
========================================
PATCH Number: BIG002
Description:
	This is a replacement pccons driver that supports all sorts
	of good things.  Vt100, VGA (only), cheap virtual screen etc.

*PATCH*
	big/vga, and everything in it.

Submitted by:
	hm@hcshh.hcs.de (hellmuth michaelis)


========================================
PATCH Number: BIG003
Description:
	These are the patches to the lpt driver that explain
	how to setup up the lpt device, along with the
	two patches required to make it work correctly.

*PATCH*
	There is a directory in the big directory called
	lpt which has instructions and patches
	to the lpt.c that is already in 386BSD 0.1.
*NOTE*
	It is 'a good thing' to re-compile the lpd daemon,
	since it appears that it may not work correctly until
	after you recompile it.  This is especially important
	if you have made any of the 'kvm' patches.

Submitted by:
	ejh@slustl.slu.edu (Eric J. Haug)
	cflatter@nrao.edu (Chris Flatters)
	alm@netcom.com (Andrew Moore)
-- 
osynw@terra.oscs.montana.edu |  A hacker w/out a home. 
work: (406) 994-5991         |  Keeper of the Unofficial 386BSD Bug Report
home: (406) 586-0579         |  Please send bugs and/or fixes you find.