From: osynw@warp.mhd.montana.edu (Nate Williams)
Subject: Unofficial Bug Report, #2 1/1
Summary: The report!
Keywords: 386BSD bugs
Organization: I as unorganized as they come
Date: Thu, 13 Aug 1992 05:09:45 GMT


U N O F F I C I A L    3 8 6 B S D     B U G     L I S T
--------------------------------------------------------
Date:		Aug.  12, 1992
Revision:	0.2

[As this is still in the early stage, suggestions and helpful
criticism is welcome, flames -> /dev/null]

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

	INSTALL and CONFIGURATION -
		These are configuration problems that exist after you
		have succesfully 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.  

***READ THIS***
The patches mentioned in this list are currently archived on 
plains.nodak.edu ~ftp/pub/386BSD.  If Glen has not moved them there yet,
they are in the (unreadable directory) ~ftp/pub/386BSD/.n/patches.tar.Z

I have also uploaded them to agate, ~ftp/pub/incoming/patches.tar.Z.
The file is around 41K compressed.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-
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 (aparently) 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 customised 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, customise 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 wll not recognize second hard drive and/or it crashes
	when you try to acces 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.

	No real solution.
Submitted by:
	kevinz@storage.tandem.com (Kevin Zeigler)
Solved by:

========================================
Bug Number:	BOOT004
Problem:
	Bringing the machine into single user mode doesn't work 
	correctly.				OR
	After people log out of the machine, who and last show
	them as still logged on.
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 singleuser and the back up again.
	It also tried to start multiuser mode when you tried
	hat or reboot in singleuser (when the singleuser 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.
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.

*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)
========================================
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 bzoeros 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-knownn 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 dosn'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 soloution would be to remove your ethernet card
	until you have rebuilt the kernel so that it expects it at an
	interrupt other than 2, rejumper it, and reinstall it.  This
	gets around both the tape and exacto knife soloutions, plus you
	don't have to know which pin is IRQ2 (something you need a
	techincal 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 (Jollitz .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:
	None yet

Submitted by:
	barnesdo@cs.colostate.edu (douglas barnes)
Solved by:

========================================
Bug Number:	BOOT010
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:
	Boot up with the bin01 distribution loaded and login as root.
	Next (root uses csh as the default shell), do a
	cd /; cat /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 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.

	This problem was because there wasn't a prototype given for
	getcpu, so it was returning an int (default) and was causing
	a floating point exception.

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.
*PATCH*
	There is a file called ps_fp.0_1 which fixes the floating point
	exception problem.

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 1755 /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.
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 automaticaly have Daylight Saving's time set up, so
	you have two 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/datfiles to have the
		correct time for your machine. 
*ENDNOTE*

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	(same)
========================================
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:
	None yet.

Submitted by:
	bde@runx.oz.au (Bruce Evans)
Solved by:
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:
	There are not enough map entries for computers with >12 MB of
	memory.
Solution:

in the file /sys/vm/vm_map.h, there is a:
#define		MAX_KMAPENT	500
which needs to be
#define		MAX_KMAPENT	1000

*PATCH*
	There is also a patch file called kmem_panic.0_1 which
	contains the above fix.

Submitted by:
	osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
	wjolitz@soda.berkeley.edu (W. Jolitz)

========================================
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.berkely.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-existance "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 multicolored 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/kernexecve.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:
	??@*.eur.nl 		[If you wrote this, let me know]
	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 dependcies 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:
	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:	KERN010
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:
	bed@runx.oz.au (Bruce Evans)
Solved by:

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.

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

========================================
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:
	I think talk is doing something it shouldn't because screen
	seems to work fine with sockets.
Solution:
	None yet.

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

========================================
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)
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
	arguements 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)

	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:
	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:	MISC007
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:	MISC008
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:	MISC009
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:	MISC010
Problem:
      select(2) doesn't work with the com driver.
Explanation:
	It always says there is something to read when there isn't.
	I tried it with the stock com driver and with Chris Demetriou's .
Solution:
	None yet.

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

========================================
Bug Number:	MISC011
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:	MISC012
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:	MISC013
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:	MISC014
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 gen the above itsself.
	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:	MISC015
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
	Adress 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:	MISC016
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 sylog 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:	MISC017
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:	MISC018
Problem:
	There are several bugs in the kernel namelist db creation/use
	and bugs in kvm.c which causes ps and several other utils to
	fail to work correctly.
Explanation:
	It's a bug!
Solution:
	There is a patch file called kvm_util.0_1 which contains
	fixes for the kvm.c library routine and the kvm_mkdb 
	system program.

Submitted by:
	
Solved by:
	(same)
-- 
osynw@terra.oscs.montana.edu |  A hacker w/out a home.  Anyone  interested
work: (406) 994-5991         |  in a used Sys. Admin., with alot of 
home: (406) 586-0579         |  good hacks left?
Newsgroups: comp.unix.bsd