🚀 go-pugleaf

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part2

Section 1. (General Network Information)
General information

	This section of the FAQ is about the electronic support network 
	that exists for 386bsd.  

1.0	What is 386BSD? (Taken from the INSTALL.NOTES by the Jolitz's)

	Welcome to 386BSD Release 0.1, the second edition of the 386BSD 
	operating system created by William and Lynne Jolitz.  Like its 
	predecessor, 386BSD Release 0.0, Release 0.1 comprises an entire 
	and complete UNIX-like operating system for the 80386/80486-based 
	AT Personal Computer.

	386BSD Release 0.1 is an enhanced version of the original release 
	done by William F. Jolitz, the developer of 386BSD.  386BSD 
	Release 0.0 was based on the Networking Software, Release 2 from 
	the University of California at Berkeley EECS Department, and 
	included much of the 386BSD work done earlier by Bill and 
	contributed by us to the University. The latest release, 386BSD 
	Release 0.1, contains new work by the developer and many new items 
	which have been freely contributed by other software developers 
	for incorporation into 386BSD (see the file CONTRIB.LIST).  These 
	contributions have increased the functionality and made it more 
	robust.  As a courtesy to the developer and the many people who 
	have generously contributed these software enhancements, we request 
	that users abide by and properly maintain all attributions, 
	copyrights, and copylefts contained within this release.

 	386BSD is intended to foster new research and development in 
 	operating systems and networking technology by providing this base 
 	technology in a broadly accessible manner.  As such, like its 
 	predecessor, 386BSD Release 0.1 is freely redistributable and 
 	modifiable.
 
1.0.1	What are these other Free BSD systems?

	For reasons best left to private E-Mail, there have been two 
	different 'product lines' that have been established for 
	development of BSD systems.  They are NetBSD and FreeBSD.  Both,
	individually, have virtually deprecated the original 386bsd.
	The "raison d'etre" for each is different and each has a different
	set of goals.  The purpose for FreeBSD is to develop a stable 
	working environment for [3-9]86 systems.  The emphasis has been 
	on upgrading utility programs and incorporating changes that make
	the system more stable.

	NetBSD, on the other hand, is a development effort whose main 
	thrust is on mulitple platform support and staying more current
	with BSD 4.4. 

	Both systems are excellent choices for the casual user or people
	who are interested in studying the internals of an operating 
	system.  While the products are nearly commercial quality, they 
	are both maintained by volunteers.


1.0.2	I just downloaded all of 386bsd version 0.1 and I get can't get
	[some feature] to work?  Do you have any suggestions?

	Yes.  Get either FreeBSD or NetBSD.

	The original 386BSD software was kind of buggy when it was put 
	up for anonymous FTP last year.  It has been modified significantly
	since then, and now exists in a different form.  There are people
	who will argue that the original 386BSD was completely unusable,
	but that is generally an overstatement.  

	Over 100 patches were applied to the original system, with hundreds
	more waiting in the wings.  To get this 'patched' version of 
	386bsd, get FreeBSD instead.  To get a version that split from 
	386bsd to try and stay more in line with the BSD 4.4 system, and
	also provide a multiplatform development system, get NetBSD.

	Getting one of these two systems will provide you with a more 
	complete system, with newer utilities, and many bugs already 
	fixed.


1.1	Feature summary

	Among the many features of these BNR/2 systems:

	*    Floppy disk based Installation

	*    Hard drive partitioning for use with MS-DOS partitions

	*    Compressed, multivolume CPIO dump format binary/source/other 
	     distribution sets on MS-DOS floppies.
	
	*    387 support or emulation.

	*    SCSI support.

	*    CD-ROM support.

	*    NFS, TCP/IP and full networking.

	*    MS-DOS file system access (in newer *BSD systems).

	*    PPP and SLIP protocol support.

	*    System upgrades through Carnegie Mellon University's 'sup'
	     utility.

	*    Shared Library Support (in alpha or beta testing, depending
	     on the environment).


1.2	The future of 386BSD.

	{ This section is included for historical purposes only.  Most 
	of the information in here is either wildly out of date or just
	plain wrong.  I decided to include it mostly to show how far
	we have come... dbb }

	Forecasting the future is always a tricky business.  There is work 
	underway to implement version 0.2 of 386bsd.  In addition, many 
	people are involved in a project to put together a 386bsd version 
	(FreeBSD) which will be a complete distribution set including all 
	relevant patches and updates to new versions of many of the 
	software packages that are currently available.  It is available 
	by anonymous FTP from FreeBSD.cdrom.com

	In addition, NetBSD (a direct descendent of 386bsd) is available 
	for anonymous FTP from sun-lamp.cs.berkeley.edu.  The purposes of 
	these two apparent competitors appear to be at odds, but in 
	fact are very similar.  NetBSD has taken a 'stable, production
	quality, free OS' as one of its primary goals, where 386bsd 
	pursues the high ideal of the ultimate OS research platform.
	There is considerable cross pollination of the two.  The frequent
	debates on style and concept that appear in comp.os.386bsd.*
	are testimony to that point.  NetBSD and FreeBSD are still both
	very viable operating system alternatives, with differing goals.

	To see the Future of 386bsd as seen by Bill and Lynne Jolitz, I 
	suggest you read the INSTALL.NOTES that come with 386bsd.


1.3	386BSD software projects in progress

	The list of software projects in progress is just too volatile 
	to go into a static document like the FAQ.  Suffice it to say, if 
	there is something you want to do using 386bsd; ask first to see 
	what has been done.

	Nate Williams (nate@bsd.coe.montana.edu) has volunteered to be 
	the focal point for software projects for 386BSD.  His job will
	be to get people with similar interests together to minimize 
	wasted effort and people working at cross purposes.

	Folks that are interested in software projects for NetBSD 
	should contact netbsd-comments@sun-lamp.cs.berkeley.edu and
	let that mailing list know the same information.
 

1.3.1	Contacting software authors

	Whenever you are working on a port of a software package, it is 
	always a good idea to contact the original author and offer 
	whatever changes you needed to make in order to port the software.  
	That way, subsequent releases of the package may include changes 
	that allow all users of 386bsd the advantage of reusing your work 
	over and over.

	Also, once you have ported a package to *BSD, you might want to 
	send a note to either Nate Williams (nate@bsd.coe.montana.edu) 
	letting him know that you have completed a package and where it 
	is available.  For NetBSD, contact
	netbsd-comments@sun-lamp.cs.berkeley.edu.

	If the port was a simple recompile of the source and install, a 
	note to one of the newsgroups telling the story could be considered 
	appropriate as well.  

	In keeping with that, if you find a 'bug' in 386bsd, or find a 
	problem that causes you some headaches and find a solution, you 
	should contact the author of the particular driver/module/program 
	and let them know.  In addition, you could also post the problem 
	and/or fix to "comp.os.386bsd.bugs".

	Both NetBSD and FreeBSD have implemented 'bugfiler', so if you
	are connected to the net, you can use that to send out your
	bug.  See the documentation that comes with your system to find
	out more.


1.4	Minimum hardware configuration recommended

	There has been considerable debate about what the REAL minimum 
	configuration for 386bsd is.  Some would claim that it is the 
	smallest computer that an installation will succeed on.  Others 
	claim that it is the smallest usable computer (based on RAM and 
	speed constraints) and others would claim that it should be 
	based on using 'X'-windows.
 
	For specific hardware, see Section 8 (still in development).

	The smallest installable platform is an 80386, using an MGA card, 
	with at least 2Meg of RAM and a 20 Megabyte hard disk.  While not 
	all SCSI cards (especially EISA) are supported, a great many are 
	either in the base distribution or through patches.  This 
	configuration is tricky to prepare, and will certainly be hard to 
	use, but it is possible.

	A comfortable installation which includes source and binary 
	distributions, as well as other utilities will work in about 
	100Meg of hard drive.  

	'X' requires at least a Hercules MGA; for masochists only, from 
	what I understand.

	See section 8 for more details.


1.5	Where to get the source and binaries
1.5.1	Forms available (floppy, FTP, CD-ROM)

	386bsd is available in just about every format known to man, with 
	the possible exception of stone tablets and papyrus.


1.5.1.1 Where can I get the distribution on floppy or tape?

	Many people will copy files onto diskettes or tapes if you 
	coordinate it with them ahead of time.  In addition, many 
	companies offer 386bsd on various types of media for money.  
	Austin Code Works and others (usually advertisers in PC 
	magazines) offer the base 0.1 "official" distribution for a fee.
	  
	Note that there are virtually no restrictions on distributing 
	the 386bsd distributions.  Basically, wherever you can find it, 
	you can get it.  This goes for FreeBSD and NetBSD as well.


1.5.1.2 Where can I get the distribution via FTP?

	The files you should look for specifically when using FTP are 
	directories called srcdist, bindist, and etcdist.  These 
	directories will hold the files for each of the distributions.  
	Once you have received the files via FTP, you can either load 
	them directly onto your system and then un archive them using 
	'extract' or one of the other methods suggested in Section 2 of 
	the FAQ, in the section about installing with 'real partitioning'.
	
	The list of sites that have 386BSD is covered in section 1.8 below.  
	This list is produced automatically by using a utility called 
	'archie' and is updated for every new version of the FAQ.  If you 
	try to access a site from this list and find that they either 
	don't have FTP enabled, or don't have 386bsd loaded any more, 
	a polite letter to the admin of the system asking them to 
	update their 'archie' entries is good manners.
	
	
1.5.1.3 Where can I get the distribution on CD ROM?
	
	Infomagic sells a UNIX CD-ROM that has 386BSD.  Their FAX number 
	is 609-683-5502.

	Profit Press has 386BSD dated 7/21/92 on their "Mega Win OS/2" 
	CD-ROM.  This is in the format of BINDIST, ETCDIST, SRCDIST and 
	BOOTABLE.

		Profit Press
		2956 N. Campbell Ave
		Tucson, Arizona 85719
		(602) 577-9696
		Their order line is 1-800-843-7990

	Look for their advertisements in the back pages of Computer 
	Shopper.  The Mega series is $29.00 each or $69.00 for all three 
	plus a fourth "Demo Disk".  

	In all likelihood, the version 386bsd that is available on CD-ROM 
	will be the 0.1 version, without any patches.  Keep this in mind 
	when ordering, since the first thing most people want to do is 
	bring the system up to the current patch level.  If you do not want
	the original 0.1 version, be sure to ask where the distribution
	came from and which version of *BSD it is. 	
 
	For our European users, I have included these notes from Julian 
	Stacey (stacey@guug.de) and Christian Seyb (cs@gold.muc.de) 
	concerning locations and methods for getting 386bsd in Europe on 
	both CD-ROM and floppies.
	
	----------------------------------------------------------------------
	The following CDROM is available for DM 98,-- (app. $60) and contains 
	the following software:

	- Linux SLS V1.03, Kernel 0.99.11 and utilities for Linux
	- 386BSD version 0.1 including patch-kit 0.2.4
	- NetBSD version 0.8
	- Utilities for 386BSD and NetBSD
	- The Berkely Second Networking Distribution
	- GNU software (gcc 2.4.5, emacs 19.17, gmake 3.68, etc)
	- X11R5 up to patch 25 and lots of Contributed Software
	- TeX version 3.14
	- The Internet RFCs up to RFC1493
	- News, mail and mailbox software and many utilities for Unix


	To: CDROM Versand
	    Helga Seyb
	    Fuchsweg 86
	                                          Tel: +49-8106-302210
	    85598 Baldham                         Fax: +49-8106-302310
	    Germany                           Bbs/Fax: +49-8106-34593

	(Ed. Note:  This appears to be an advertisement, but the price is right
	and appears to be reasonable.  Christian and Helga may have the same
	last name by coincidence :-)  If you want more ordering information, 
	please feel free to give Helga a call.)
	--------------------------------------------------------------------------

	In Munich Germany:
	Buy the monthly "c't magazin fuer computer technik" (Price 8.5 DM) 
	(~1.7 = $1) & look in back pages, I saw:

	Mail Order:
		JF Lehmanns Buchhandlung, fuer EDV, 
		Zuelpicher Str 182, D-50937 Koeln, Germany
		Free catalogue for X, Linux, 386bsd, 1.
		Confusing advert seems to offer X11R5 + GNU + 386BSD 
		on CD Rom "InfoMagic Vol2 No2" for Price: 149 DM.
		Tel. 0130 4372 (always busy, claims to be free, 
			so don't know if +49 130 4372 viable)
		Fax: +49 221 415995
		Shops in Berlin, Koeln, Regensburg, Ulm.
		
	(Editorial Notes:  DM149 is about $75-$90 US (or a little more) 
	and 0130 numbers are Toll Free in Germany only.)

	Mail Order:
		Computer Solutions Software GmbH
		Postfach 1180, D-85561 Grafing (Muenchen), Germany
		Tel +49 8092 5018
		Fax +49 8092 31727
		23 * 3.5" 1.4M flops @ Price: DM199
		Order No:/Best Nr: 5099
		Shop: 
			Columbus Datentechnik,
			Theresienstr 63, D-80333 Muenchen, Germany
			Tel +49 89 5232021

	Lynne wrote a short follow-up, letting us know that these 
	companies do not send them any money.

	(Linux was advertised in the mag. @ 89DM, both Linux & 386BSD 
	distributions were offered as something over 20 1M floppies )

	Many people would happily under cut high price commercial 
	distributors, pocket some for media & copying hassle and 
	forward the remainder to subsidize Bill & Lynne's development 
	efforts.

	This information is offered with no warranties, guarantees, 
	franchise offers, or recommendations.
	        
1.6	Electronic Information Groups for 386BSD

1.6.1	Usenet newsgroups

	List below are the Usenet newsgroups that were developed to support
	386bsd and its descendents.  In addition, general BSD questions can
	be posted to comp.1.bsd.  Bear in mind, however; that your 
	questions to this group should really be about BSD in general, not
	a specific implementation detail of *BSD.

	comp.os.386bsd.announce 
	    Announcements relating to the 386bsd operating system. (Moderated)
	    Posts should be mailed to "386bsd-announce@agate.berkeley.edu".
	    
	comp.os.386bsd.apps
	    Applications which run under 386bsd.
	    
	comp.os.386bsd.bugs
	    Bugs and fixes for the 386bsd OS and its clients.
	    
	comp.os.386bsd.development
	    Working on 386bsd internals.
	    
	comp.os.386bsd.misc 
	    General aspects of 386bsd not covered by other groups.
	    
	comp.os.386bsd.questions
	    General questions about 386bsd.


1.6.2	Newsgroup archives.
	
	These sites maintain a historical record of the traffic in the Usenet
	Newsgroups indicated.  There are others, but I haven't gotten their
	names yet.

Host Name            IP address     Location        Newsgroups archived
-------------------- -------------- --------------  ---------------- 
minnie.cs.adfa.oz.au 131.236.20.70  Australia       comp.1.bsd
src.doc.ic.ac.uk     146.169.2.1    London, UK      comp.os.386bsd.*


1.6.3	BNR/2 Derived bsd mailing lists.

	There are at least two mailing lists for 386bsd.  Both are for 
	discussions of the patchkit and patches.  They are:

	386bsd_patchkit@cs.montana.edu: 
		This list is primarily for discussion of the patchkit and other
		patch procedure discussions.
	patches@cs.montana.edu: 
		This list is for patch submissions.

	NOTE: The patchkit is discussed in detail in Section 2 of the FAQ.
	Also, the patchkit has been effectively deprecated.  Sending to 
	these lists may or may not get you the kind of info you are looking
	for.

	In addition to the pure 386bsd lists mentioned above, there are 
	mailing lists available for FreeBSD and NetBSD.  Information about 
	the NetBSD lists and how to use majordomo (the list handler) is 
	available by mailing to majordomo@sun-lamp.cs.berkeley.edu.

	There are three mailing lists for FreeBSD and they are:

	FreeBSD-hackers: for hackers
	FreeBSD-questions: misc questions
	FreeBSD-bugs: bug reports

	Send to FreeBSD-hackers-request@freefall.cdrom.com to be added 
	to the hackers list, and *-questions-request@freefall... to be 
	added to the questions list.


1.6.4	Other electronic resources.

	There are many bulletin boards throughout the world that have 
	386bsd software and information available.   Also, there are 
	CompuServe and other on-line services that have 386bsd discussions.
	
	    
1.6.5	System Updates.

	There are at least two different ways of getting the updates for the
	current source tree for both FreeBSD and NetBSD.  The first is the
	traditional FTP method, and the other is using a utility called 'sup'.
	This program keeps a log of the source modules that have been updated 
	and sends out only those files that have been changed.  Included below
	are some instructions from John Brezak <brezak@apollo.hp.com> on how 
	to run sup for NetBSD.  The sup procedures for FreeBSD are similar:


	Instructions for installing NetBSD sources and releases using SUP
	-----------------------------------------------------------------
					1.3 1993/11/3

	SUP is a network installation package written by CMU used to distribute
	software. For more details on SUP refer to the man pages.

	Sup works by reading a configuration file (supfile) and using this 
	information to determine what "collections" of files will be loaded 
	from the collection repository. Here is an example of a supfile to 
	load the NetBSD current release.

	[ Note: lines have been broken for readability; do NOT use '\' in 
	supfiles ]

	src release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp 	    base=/usr prefix=/usr backup

	ksrc release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp 	    base=/usr prefix=/usr backup

	security release=current host=sun-lamp.cs.berkeley.edu 	    hostbase=/b/anon_ftp base=/usr prefix=/usr backup

	gamessrc release=current host=sun-lamp.cs.berkeley.edu 	    hostbase=/b/anon_ftp base=/usr prefix=/usr backup

	regress release=current host=sun-lamp.cs.berkeley.edu 	    hostbase=/b/anon_ftp base=/usr prefix=/usr backup

	#othersrc release=current host=sun-lamp.cs.berkeley.edu 	    hostbase=/b/anon_ftp base=/usr prefix=/usr backup


	This supfile will load the "current" collections for "src", "ksrc",
	"security", "gamessrc", and "regress" in the /usr directory on the
	local machine.  The "othersrc" collection will not be loaded because
	it is commented out.

	The supfile line is made up of keywords that describe the collection's
	location on the sup server and where and how it will be loaded on the
	local host.

		release - the release of the collection to load.
        	host	- the 'host' where the SUP repository resides. NetBSD 
        		uses sun-lamp.cs.berkeley.edu .
        	hostbase- the pathname on the host to the base of the 
        		collection.  The hostbase for NetBSD is "/b/anon_ftp".
		base	- where you want to install it locally.
		prefix	- used to locate the "sup" directory to write sup's
			info about updates. Usually the same as base.

	This supfile can also set some options. The "old" option tells sup
	to check all files for changes, not just those that are newer than 
	the last sup update. Normally sup will overwrite local files with the
	changed file from the repository. If the sup collection specifies 
	that an existing file should be renamed to a backup, the "backup" 
	option in the supfile activates this. The "delete" option tells 
	sup to delete any files locally that are no longer in the 
	collection - be careful with this one.  The "keep" option will 
	cause sup to NOT update files that have been changes locally. 
	The "compress" option will use gzip to compress the files before 
	transfer and gunzip them on the receiving end. This option can be 
	used to cut down on the number of transmitted bytes.

	You may want to set 'base' and 'prefix' to something other than /usr
	if you want to preserve your existing src tree.

	The sup repository on sun-lamp.cs.berkeley.edu currently offers these
	collections.
       	 
		src, ksrc, security
			The sources for NetBSD

		othersrc
			The current sources for contributed parts of NetBSD. This
			contains the sources for sup.

		regress
			The current sources for the NetBSD regression test suite.

	If you only want the kernel sources for a specific port there are some
	sub packages that you can use instead of the "ksrc" one. If you are 
	using the sub packages, be sure to also sup the "ksrc-common" package.

        	ksrc-common
                	Kernel sources common to all ports.

        	ksrc-1, ksrc-sparc, ksrc-hp300, ksrc-amiga, ksrc-mac,
        	ksrc-pc532, ksrc-pmax, ksrc-sun3
                	Kernel sources for a particular port.


	The security package is not to be sup'ed by sites outside of the U. S.,
	read the "README.export-control" file for details.

	Each collection can have multiple releases (as specified by the "release"
	keyword).

	IMPORTANT!!
	Be aware that the current release is simply a snapshot of the daily
	state of NetBSD development and is not guaranteed to build (or even
	work) - use at your own risk !

	Stable releases of NetBSD are available via SUP. Instructions are
	included with the release announcement.

	Before running sup, be sure that your /etc/services contains these
	entries.

	supfilesrv      871/tcp         # for SUP
	supfiledbg      1127/tcp

	To try sup without really updating anything use the '-f' flag. The '-v'
	flag means verbose and can be used to see what sup is doing.
	
		sup -fv supfile

	The sup binary, sup man page and sample supfiles can be ftp'ed from
	sun-lamp.cs.berkeley.edu:~ftp/pub/sup .  Comments should be directed
	to "sup@sun-lamp.cs.berkeley.edu".

	A mailing list exists for users of the NetBSD "current" release. To
	join, mail to 'majordemo@sun-lamp.cs.berkeley.edu' with a mail body
	of "info". The reply will describe the mailing lists for NetBSD. The
	you will want to subscribe to te "current-users" mailing list.
	We will use this list to announce any special changes made to the
	"current" tree.


1.7	Documentation available

	There are two types of documentation for 386bsd.  First is the 
	set that covers the operation and theory used in BSD-Unix.  
	These sources are often excellent for background and understanding 
	of the current implementation of 386bsd.  Second is the set of 
	manuals written specifically for 386bsd.  Most of these are books 
	and magazine articles written by Bill and Lynne Jolitz.


1.7.1	BSD manuals

	The full set of BSD documentation is available via anonymous FTP 
	from ocf.berkeley.edu in /pub/Library/Computer/doc4.3.  To print 
	this documentation on 386bsd systems, replace the ditroff 
	references in the Makefile with 'groff -e -t -msU {SRC} >out.ps' 
	to generate PostScript format files.  Use different options to 
	make the output conform to other print styles.

	The etc distribution also comes with a documentation directory
	~/share/doc which has nearly 3Meg of documentation about 386bsd.
	  
	In addition, on-line manuals are available in the binary 
	distribution set.  It contains specific information on the use 
	of UNIX utilities and commands.  Type "man man" for information 
	on the online manual.


1.7.2	BSD books

	There is an excellent set of works recommended by Bill and Lynne 
	in the INSTALL.NOTES.  In addition, several other books have been 
	recommended by Andrew Moore and others.

	For learning how to work in the Unix environment, the standard text
	is "The Unix Programming Environment,"  by Kernighan and Pike.
	
	For Unix Administration, the best is "Unix System Administration
	Handbook," by Nemeth, Snyder and Seebass.

	For systems level programming (i.e., systems calls), I recommend
	"Advanced Unix Programming," by Marc Rochkind.  Unfortunately it is
	out-dated and oriented towards System V.  

	A new book "Advanced Programming in the Unix Environment," by W.
	Richard Stevens is very	up-to-date, and an excellent reference,
	especially for dealing with POSIX standards issues.

	For network programming, "Unix Network Programming," by W. Richard
	Stevens is highly regarded.
	
	The 4.3BSD Unix Manuals contain loads of invaluable tutorials and
	historical papers in addition to hard copies of on-line documentation.
	The six volume set is available from Usenix for $60.00 (email:
	office@usenix.org)

	I could go on, but let me mention just two more - if you have a full
	386BSD installation, you may want to learn the bash shell (in
	/usr/othersrc/public).  This is an extension of the Bourne shell (sh)
	with features from both the C shell (Csh) and the Korn shell (Ksh).
	The Korn shell is described in "The Kornshell," by Korn (of course).
	
	Second, I recommend you look at "The AWK Programming Language," by 
	Aho, Weinberger and Kernighan.  This is a very nice prototyping 
	language - powerful and easy to use.

	Another excellent reference book for 386bsd is "The Design and 
	Implementation of the 4.3BSD UNIX Operating system" by  Samuel J. 
	Leffler, Marshall Kirk McKusick, Michael J. Karels, John S. 
	Quarterman, 1989, Addison-Wesley, ISBN 0-201-06196-1.  While this 
	book is out of date in many sections, it is purported to be an 
	excellent source of historical information, if nothing else.  
	Chris Demetriou recommends the sections on the treatment of 
	file systems, caching and the networking layer.  The sections in 
	this books which do not apply to 386bsd include the VM section, 
	bootstrapping, and autoconfig.

	In addition, there are many other books which, for one reason or 
	another, have not made it into this brief list.  Rest assured that 
	this is not intended to be an exhaustive list by any means.  In 
	fact, Lynne Jolitz has offered to supply the FAQ with her preferred 
	reading list describing the current and future versions of 386bsd.  


1.7.3	The Jolitz Book

	Bill and Lynne Jolitz are writing a book about 386bsd.  It will 
	be announced once it is ready.  A tentative date of late 1992 
	was once offered, but since it is nearly 1994 and no book has 
	been announced, we can assume that it will be later than the 
	original estimate.
 

1.7.4	Dr. Dobbs' journal

	For users who wish to understand the internals of the BNR/2 BSD 
	family of Operating Systems originally developed and/or ported by 
	William F. Jolitz from 1989 to the present, the most immediate 
	and available reference is the feature series entitled 
	"Porting UNIX to the 386: A Practical Approach", appearing in Dr. 
	Dobbs' Journal, USA (January 1991 to July 1992) and UNIX and iX 
	Magazines, Germany (June 1991 to present). For inquiries on the 
	article series (including reprints),  contact the magazines for 
	information.

	"Porting UNIX to the 386: A Practical Approach" (feature series) by
	Jolitz and Jolitz
	
	 1/91: DDJ		"Designing a Software Specification"
	 2/91: DDJ		"Three Initial PC Utilities"
	 3/91: DDJ		"The Standalone System"
	 4/91: DDJ		"Copyright, Copyleft, and Competitive Advantage"
	 4/91: DDJ		"Language Tools Cross-Support"
	 5/91: DDJ		"The Initial Root Filesystem"
	 6/91: DDJ		"Research and the Commercial Sector: Where Does 
				BSD Fit In?"
	 7/91: DDJ		"A Stripped-Down Kernel"
	 8/91: DDJ		"The Basic Kernel"
	 9/91: DDJ		"Multiprogramming and Multiprocessing, Part I"
	10/91: DDJ		"Multiprogramming and Multiprocessing, Part II"
	11/91: DDJ		"Device Autoconfiguration"
	 2/92: DDJ		"UNIX Device Drivers, Part I"
	 3/92: DDJ		"UNIX Device Drivers, Part II"
	 4/92: DDJ		"UNIX Device Drivers, Part III"
	 5/92: DDJ		"Missing Pieces, Part I"
	 6/92: DDJ		"Missing Pieces, Part II"
	 7/92: DDJ		"The Final Step: Running Light with 386BSD"
	
	You can contact M&T Books (DDJ) for reprints if you can't get them from 
	your technical library:
	
	1-800-356-2002 (inside CA)
	1-800-533-4372 (North America)
	1-800-444-4881 (better In NA Backorder number)
	1-415-358-9500 (international)
 
	 6/91: UNIX Magazin	"Portierung von BSD-UNIX auf den 80386. Heimlich 
				Liebe."
	 7/91: UNIX Magazin	"Steighilfe."
	 8/91: UNIX Magazin	"Systemverwaltung durch Tabellen"
	 9/91: UNIX Magazin	"Sicher bewegen auf fremdem Terrain"
	10/91: UNIX Magazin	"Damit die Fehlersuche nicht zum Hurdenspringen 
				wird"
	11/91: UNIX Magazin	"Alles in eine Schublade"
	12/91: UNIX Magazin	"Feuer und Wasser"
	 1/92: UNIX Magazin	"Rekursives Speicher-Mapping"
	 2/92: UNIX Magazin	"Tanz auf dem Eis"
	 3/92: UNIX Magazin	"Aus Hanschen wird Hans"
	 4/92: UNIX Magazin	"Das Geheimnis des Multiprogramming"
	 5/92: UNIX Magazin	"Zeitmanagement scheibenweise"
	 6/92: UNIX Magazin	"Magie des Kernels"
	 7/92: UNIX Magazin	"Erkenne Dich Selbst"
	 9/92: UNIX Magazin	"Niemand is eine Insel"
	10/92: UNIX Magazin	"Treiberlatein"
	12/92: UNIX Magazin	"Einlandung erforderlich" 
	 1/93: iX Magazin	"Wir unterbrechen das Programm"
	 2/93: iX Magazin	"Liste gut, alles gut"
	 3/93: iX Magazin	"Blick ins Allerheiligste"
	 4/93: iX Magazin	"Von Bl"ocken, Ringen und Zeichen"
	
	NOTE: The series in UNIX Magazin was moved to IX Magazin in 1/93.
	The article in the April issue was the last one in the series.
	
	In addition, other major articles which discuss 386BSD in detail:
	
	 8/92: UNIX Magazin "Interview mit Bill Jolitz. Das passiert mit 
	 	386BSD" by Jurgen Fey
	 8/92: DDJ "Very High-Speed Networking" by W.F. Jolitz
	12/92: DDJ "Inside the ISO-9660 Filesystem Format" by Jolitz and 
		Jolitz
	
	Reprints of the first 19 parts on the UNIX Magazin series are available 
	from:
	
	iX Redaktion
	Stichwort: 386BSD-Serie
	Verlag Heinz Heise GmbH & Co KG
	Helstorfer Str. 7
	D-30625 Hannover, Germany 
	
	Some of the parts are without code listings due to the unclear
	status of the BSD releases stemming from the Net/2 release.
	

>However, "1-800-533-4372 (North America)" has since been disconnected. 
>ordering back issues and they only have some '91 issues. No luck here ...

>==> Can somebody out there "sell" me a complete set of the above DDJ articles?

>Any help will be very much appreciated. Thanks in advance.

I may be overlooking the obvious, but have you tried your local
library?

-- 
------------------------------------------------------------------------------
  Michael L. VanLoon                           Project Vincent Systems Staff
  michaelv@iastate.edu              Iowa State University Computation Center
------------------------------------------------------------------------------


	
1.7.5	Other FAQ's on the net that are relevant
	
	There are many FAQs that can be used in conjunction with 386bsd.  
	These include the FAQs for all of the GNU software, the different 
	shells that are available, the programming languages that are 
	available, and many more.  In addition, many programs have their 
	own FAQ which should be referenced whenever that package is being 
	added.  Good examples of the latter are the FAQs for elm, C-News, 
	and innd.
	 
	The observant reader will notice that there are very few 'X' 
	questions in this FAQ.  The XFree86 FAQ is posted regularly to 
	comp.os.386bsd.*.  There is no good reason to include any 'X' 
	questions in this FAQ, with the exception of the most basic 
	'Where can I get the 'X' FAQ'.
	
	Most FAQs are available by anonymous FTP from rtfm.mit.edu and 
	via Usenet News in news.answers and/or comp.answers.  This FAQ
	is no exception (I hope). 
	
	
1.8	FTP sites for 386BSD
	
	A standard tool on Internet connected hosts for finding files is
	'archie'.  Searching the archie archive for either "386BSD"  or 
	"386bsd" yields the following list.   For UUCP sites, FTP-Mail 
	is available from gatekeeper.dec.com.  The list below was created 
	with an 'archie -l' on 26 Dec 1993 searching for 386bsd.

	For those folks that have access to telnet, but not FTP, you can use
	archie by using telnet and connecting to 132.206.2.3.  Log in as
	'archie' and use the 'prog' command to find programs of interest.
	The list below is included primarily for those folks that have only
	uucp, and will need to get their software though UUCP and other
	channels.
	

1.8.1	FTP Site List

	This list is automatically generated every time the FAQ is 
	produced.  Please do not request that your host be added to 
	this list.  If your host is represented in an 'archie' list,
	it will be reflected here.  Several other sites are included 
	in Section 1.8.4 below.

	Host					Directory
	ascwide.ascii.co.jp           /pub2/language/clisp/386bsd/
	binkley.cs.mcgill.ca          /pub/386bsd/
	bloom-picayune.mit.edu        /pub/usenet-by-hierarchy/comp/os/386bsd/
	brolga.cc.uq.oz.au            /pub/386bsd/
	etlport.etl.go.jp             /pub/386bsd/
	etlport.etl.go.jp             /pub/ccipr/386bsd/
	ftp.cfi.waseda.ac.jp          /pub3/fj/fj.sources/386bsd/
	gatekeeper.dec.com            /.0/BSD/386bsd/
	gatekeeper.dec.com            /.9/plan/lisp/clisp/binaries/386bsd/
	grasp1.univ-lyon1.fr          /pub/msdos/386bsd/
	hpb.mcc.ac.uk                 /pub/386bsd/
	isfs.kuis.kyoto-u.ac.jp       /ftpmail/ftp.ae.keio.ac.jp/pub/386bsd/
	isfs.kuis.kyoto-u.ac.jp       /ftpmail/ftp.iij.ad.jp/pub/386bsd/
	isfs.kuis.kyoto-u.ac.jp       /ftpmail/ftp.meiji.ac.jp/pub/386bsd/
	isfs.kuis.kyoto-u.ac.jp       /ftpmail/ftp.phys.keio.ac.jp/pub/386bsd/
	isfs.kuis.kyoto-u.ac.jp       /ftpmail/ftp.phys.keio.ac.jp/pub/tex/dviout/386bsd/
	knot.queensu.ca               /pub/tcrunchers/Unix/386bsd
	krynn.efd.lth.se              /pub/386bsd/
	lth.se                        /pub/netnews/386bsd/
	net-1.iastate.edu             /pub/386bsd/
	oes.orst.edu                  /pub/386bsd/
	orion.oac.uci.edu             /pub/386bsd/
	rs3.hrz.th-darmstadt.de       /pub/programming/languages/lisp/clisp/binaries/386bsd/
	scslwide.sony.co.jp           /pub/386bsd/
	sifon.cc.mcgill.ca            /pub/ftp_inc/386bsd/
	tesla.ee.cornell.edu          /pub/386bsd/
	uceng.uc.edu                  /pub/wuarchive/systems/1/386bsd/
	ugle.unit.no                  /pub/386bsd/
	1.secs.oakland.edu         /pub/386bsd/
	world.std.com                 /src/mail/mh-6.8.3/conf/examples/386bsd
	world.std.com                 /src/telcom/FlexFAX-news/port/386bsd/
	world.std.com                 /src/telcom/FlexFAX/port/386bsd/


	The code may soon also to be available, or perhaps is already 
	available, from both CompuServe and BIX.

1.8.2	Official distribution sites

	According to Lynne Jolitz, there is no such thing as an 'official' 
	386bsd site.  The closest we have is 'agate.berkeley.edu' which is 
	mirrored at several of the sites listed above.

1.8.3	Reference sites

	For a brief period, ref.tfs.com was available for use as a reference 
	system.  This system was used as the test-bed for many programs that 
	were ported to 386bsd by many authors.  Unfortunately, ref.tfs.com 
	has been disabled as a reference system.  Once a replacement is 
	established, it will be noted here.

	There is now a site in Germany that is acting as a reference site 
	for 386bsd.  The name is "g386bsd.first.gmd.de", also known as
	"bsd386.first.gmd.de". Sorry, no anonymous ftp yet. But there is
	a "guest" login with the password "guest".

	But the most important reason why I had installed the machine on 
	the network was for all these people who don't have enough space 
	to compile their own kernel or their own packages.   They can do 
	it on this machine.  ATS ( ats@first.gmd.de or ats@cs.tu-berlin.de )

	Also, Montana State University has offered accounts on a 386BSD
	machine to anyone who has a project they would like to do.
	Send email to nate@bsd.coe.montana.edu with the name of your project
	and have your account setup.  As of this writing, the machine has
	access to both NetBSD and 386BSD 0.1 + patchkit sources online.  Here
	is Nate's announcement.

	This is to announce the availability of a machine on the network
	available for anyone to do specific 386BSD/NetBSD projects.

	Unfortunately, due to a not having a T1 network link, our connection
	does not have the bandwidth to do the same job as 'ref' did.  
	However, this machine can be used by anyone who does not have the 
	resources to do projects on their own machine, or who does not have 
	a machine to do a project on it.  In addition, I have local copies 
	of the interim release work and the NetBSD stuff (which are always 
	a little behind due to them both being done by hand).

	Prerequisites for getting an account are simple:

	1) telnet access so you can login - No modems are available, and you
	   wouldn't want to pay for long distance to Montana anyway :-)
	2) a specific project to accomplish/attempt
	3) a mail message sent to me stating your project and an account name.

	The projects don't have to be overly specific, but since I can't
	provide access to everyone, I need projects to give to the folks 
	who provided the resources to me a listing of the projects that 
	are being worked on.

	The machine is a 486/33 with 16MB of memory and 3Gig of disk, some 
	local and some NFS mounted.  The engineering Dept.. of Montana State 
	University has provided a large part of the resources this machine 
	has, and backups are being done on a regular basis.

	Please send all requests for account to: nate@bsd.coe.montana.edu, 
	which is the machine that is being provided for the network access.


1.8.4	Unofficial archive sites that have neat stuff!

	There are many sites that have things which have either been ported 
	to 386bsd or are available to the world.  Use archie to find these 
	sites, or read comp.os.386bsd.* for more information.
	
	agate.berkeley.edu:~/0.1-ports 
	agate.berkeley.edu:~/unofficial/from-ref
	
	Listed here because they don't have access to 'archie' yet...
	g386bsd.first.gmd.de -or- bsd386.first.gmd.de:
	    Sources for 386bsd0.1 and the later patchkits.
	    Source for NetBSD0.8 and the newer snapshots.

	    Xfree is installed binary as version 1.3.

	Ported software are:
	    tcsh6.03.00
	    emacs19-15
	    gcc-2.4.5
	    top3-1
	    perl4.0.36
	    elvis1.7
	    bison-1.21
	    rn and nn.

	 In addition, ftp.cs.tu-berlin.de has a lot of neat 
	 software and Wolfram Schneider (wosch@cs.tu-berlin.de) has 
	 'ported' the FAQ into LaTeX.  It is available in 
	 pub/386BSD/FAQ/tex in both PostScript and DVI formats.


1.8.5	 X for 386BSD 0.1 Ported Software List

	This is a list of non-core X window system application that 
	have been ported to 386BSD 0.1.  The ftp server and directory 
	name are listed above and each file or directory name is 
	followed by a short description.  Feel free to send corrections, 
	additions or suggestions to rich@rice.edu.

agate.berkeley.edu:/pub/386BSD/0.1-ports/x-apps

	InterViews	C++ GUI class library + WYSIWYG document & graphics editors.
	img_1.3		raster image manipulator/viewer

agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial/from-ref/public

	Xw		widget library
	ghostscript-2.5.2	interactive postscript interpreter/viewer
	ghostview-1.4.1	front end processor for viewing postscript
	gnuplot-3.2	interactive graphics/plotting
	gwm		generic window manager with lisp interpreter
	tk		GUI tool kit with Tool command languate (tcl) 
			interpreter
	ups		C source level debugger with slick GUI
	xbench		X server performance measurement tool
	xcdplayer	GUI for cd player
	xfig		interactive graphical editor
	xlock 		screen locker
	xntpd		network time protocol???
	xphoon		real-time view of lunar phase
	xpool		game of pool?
	xroach		yep, a roach crawling on your monitor.
	xscreensaver	screen blanker/saver
	xv		raster image viewer
	xvgr		?

nova.cc.purdue.edu:/pub/386bsd/submissions

	Xdtm-2.5.386bsd		X desk top manager
	idraw-bin.tar.Z		C++ GUI class library + WYSIWYG document & 
				graphics editors.
	img1.3.386bsd.tar.Z	see above
	mpeg_play.Z		animated raster image viewer
	small_X11r5.tZ		a minimal subset of the core distribution
	vogl.tar.Z		a library that emulatates Silicon Graphics 
				GL calls
	xview3			sun's GUI development tool kit

sunvis.rtpnc.epa.gov:/pub/386bsd/incoming:

	Dirt.tar.Z		GUI development tool kit
	XBSD8514-0.1.Z		8514 X server port
	XS3-0.3-exp.Z		S3 X server port
	acm.tar.Z		aerial combat mission/flight simulator
	chess-vort-movie.tar.Z	?
	epoch.Z			enhanced emacs for X
	jpeg.tar.Z		jpeg viewer
	libXaw3d.a.Z		3D widget library
	mpeg-1.2.tar.Z		animated raster image viewer
	ups-2.45.bin.tar.Z	C source level debugger with slick GUI
	vort-movie.tar.Z	?
	xantfarm.tar.Z		screen saver with ants?
	xbench.tar.Z		X server performance measurement tool
	xpipeman.tar.Z		game: connect pipes to keep a liquid within
	xxgdb.tar.Z		GUI for GNU source level debugger

-- 
TSgt Dave Burgess
NCOIC Applications Programming Branch
US Strategic Command, Offutt AFB, NE
burgessd@j64.stratcom.af.mil

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part3

Section 2.	(Common installation questions)


2.0	Install process
	
	The 386 BSD system is distributed in many ways.  One of the most 
	common is via DOS diskettes, (either 3 1/2 or 5 1/4, both high 
	density) with the actual distribution being a 'CPIO archive' broken 
	into 240K pieces.  This allows the distribution to fit onto a 
	minimum number of floppies. 
	
	Once the files are on floppies, thoughts usually turn to questions 
	about how to install the boot image on a floppy.  The rawrite 
	program (for DOS) is used to write the bootable images (dist.fs and 
	fixit.fs) onto floppies.  The same image can used for 3 1/2 and 
	5 1/4 high density diskettes.  Low density diskettes are not 
	supported in this version of 386bsd.
	
	Once the bootable images are written onto the floppies, insert 
	the dist.fs disk into the A: drive and reboot.  If the system does 
	not boot, see section 2.5 below for more information.
	
	If the disk boots, type install and proceed to use the 
	INSTALL.NOTES to get more information.
	
	Problems with the install are either related to hardware (i.e. Do 
	you want to install on your T.V.?) or software.  Of the hardware 
	issues, the most common FAQs are usually straight out of the 
	installation notes.  Of the software issues, there are only two 
	that really concern us.  The first is bad files.
	
	On some systems, files that are loaded from floppy appear to 
	'go bad' when they arrive on the hard disk.  Try some of these 
	solutions:

	- You forgot binary.  Don't get insulted.  Those of us that FTP 
	for a living forget sometimes.  If so, the distribution will come 
	out with all different sizes and install will complain about every 
	disk.
	
	- One or two of the files are no good.  Try getting them again.  
	As a  precaution, rename the bad files on your hard drive to names 
	like foo.1 and bob.23.  Copy the files again from floppy.  If they 
	are still bad, rename the file, and the one immediately before the 
	first bad file (bin01.23 if bin02.24 is bad) and copy them again.  
	If they are still bad, download those files again from the 
	distribution site (including the one before and after the bad one) 
	and try again.  
	    The reason for renaming the files is that sometimes, especially 
	with drive that do not auto-magically record bad sectors, you could 
	copy a distribution file onto a bad spot on the disk.  If this 
	happens, you want to isolate the bad spot.  The easiest way to do 
	that is just leave the bad file on it.
	
	- Keep trying, these same files have been used by literally 
	thousands of people to install 386bsd.
	

2.0.1	Tiny boot disk  (versions and media formats)
	
	There is currently one official boot disk, referred to as the 
	"Tiny" boot disk.  In addition, there is at least one patched 
	unofficial boot disk available from agate and its mirror sites.

	There are a few FAQs from the boot/install disk.


2.0.1.1	Where does extract go when I reboot?
	
	It was in /tmp, which is cleaned the first time you reboot the 
	system from the hard drive.  If you have just booted from the 
	hard drive for the second time, chances are you just wiped out 
	extract.  It is not really needed, since the instructions for 
	building your own install are included in section 2.5.2 of 
	the FAQ, under custom installation.

	When installing NetBSD, the set_tmp_dir and extract programs are 
	part of the .profile that is booted when you are installing.  
	This .profile is overwritten as part of the install process, and
	extract then disappears.  If you need extract again, you can mount 
	the install disk and source .profile.  This will recreate these 
	two routines.

	There is also an install procedure that NetBSD uses that does
	the same job.  It is defined as part of the .profile on one of the
	installation floppies.  You can either copy it from there, or use
	the procedure for 'real disk partitioning'.

	
2.0.1.2	I put the floppy in and try to boot, and nothing happens.  What now?

	This is usually referred to as the Compaq boot problem.  The easiest 
	solution is to get a patched boot disk.  The normal source for this 
	disk is agate (also known by its real name agate.berkeley.edu) in 
	the directory /pub/386BSD/386bsd-0.1/unofficial/patchkit.

	Another source of possible hope for you is to grab the NetBSD bootable
	disks.  They are compatible with 386BSD and allow you to install on
	some of the more recalcitrant hardware.


2.0.1.3a	The floppy booted, but now the hard disk won't boot?
2.0.1.3b	I am trying to reinstall.  I run install and it loops asking
	          me if I want to use the whole disk?
	
	The most likely culprit is your hard disk controller.  It is 
	probably doing some type of disk translation for you.  If this is 
	the case (assume it is) then you will need to find out the real 
	disk controller geometry, and rewrite your disk label.  See section 
	2.6.2, but before doing that get the program pfdisk.exe from agate 
	(It is out there, somewhere in the ~unofficial/ref-tfs stuff).  
	This program will tell you what the controller geometry is (right 
	before it reboots your computer).  Make the disklabel agree with 
	this program and your system should boot.  You may have to 
	reinstall, but at least your disklabel will be right.

	NOTE:  If the hard disk controller does NOT have an option for
	turning off the geometry, you may well be completely out of
	luck.  There are very few controllers that fall into this
	category.  The ones that do full time translation will often
	boot up in translated mode.  pfdisk will help you determine the
	correct geometry for your drive by telling you what the geometry
	looks like when 386bsd boots up.  

	But on the other hand, maybe not...

	See section 2.5.5 below for a detailed set of instructions about
	getting NetBSD (and by implication 386BSD and FreeBSD) to work with 
	a system that uses full time translation.


2.0.1.4	There are a bunch of flashing colored things on the screen.  Now what?
	
	See section 2.7 below.  It gives a rather detailed description of 
	the cause and solution.

	
2.0.2	Fix-it boot disk 
	
	The fix-it disk contains a series of programs that are 
	particularly handy for 'fixing' your disk in case you can't get 
	logged in.  It includes the disklabel program and other utilities 
	for system maintenance.


2.1	Binary distribution

	The binary distribution consists of virtually all of the programs 
	that a typical Unix system would be expected to have.  The list 
	includes mail, UUCP, GCC version 1.39, and others.
	
	Known problems with the binary distribution include the following:
	
	1.  Mtools as shipped in the bindist does not always work.  The 
	ones on the install disk seem to work fine.
	
	2.  The install script built into the binary distribution does 
	not correctly install all of the files and symbolic links that it 
	should.  For example,  some of the symbolic links to the 
	/usr/include directory are botched up.
	
	3.  'tip', the modem control program, does not always work right 
	out of the box.
	
	4.  Any program that relies on a valid symbol table in the kernel 
	(e.g. ps) will not work because the kernel is stripped so that it 
	will fit onto the bootable disk.

	These problems are all cured either by patches available in the
	patchkit, or through re-compilation.


2.2	Source distribution

	The source distribution contains all of the source code for every 
	program in the bindist.  Known problems (which are fixed in the 
	patchkit) include the following:
	
	1.  There is an error message during install about install.src01 
	not being found.  It is not an error, there isn't an install.src01.  
	Think of it as Bill and Lynne's idea of a practical joke.
	
	2.  There are several symbolic links that are not made correctly.  
	In addition, there are several files that should have been deleted 
	(to ensure clean 'make's) before the files were packed.  This is 
	fixed by the patchkit, as of 0.2.3.
	  
	3.  The /usr/src tree does not compile cleanly.  This is fixed by 
	the patchkit, as of 0.2.3, or by NetBSD or FreeBSD. 
	

2.3	Additional software distribution

	The etc distribution contains source trees for many programs that 
	are of interest to 386bsd users.  The complete ISO software 
	development environment, as well as many additional software 
	packages (and all of the games) are included in this distribution.

	The most common problem with the etc distribution is the error 
	"too many files open".  Followed closely by "install.etc01 not 
	found".  The latter is a annoyance (see above) but the former can 
	be easily overcome in a couple of ways.
	
	The "too many files open" is a result of the "cat" command leaving 
	files open after it has read a file.   Dwight E. Cass (his Email 
	address is dec@lazarus.nrtc.northrop.com) has provided us with this 
	anecdotal work around for his own experiences:
	
	--------------------------------------------------------------------
	So - back to installation.  This time, when I get to the etc01 
	partition, I am a bit more awake, so I run it from Csh (with the 
	open file limit at 256).  Works pretty well - but complains at the 
	end that it could not do the final configuration because it could 
	not find the configuration file - I checked the MANIFEST and the 
	file is not there, so I finally decided to ignore the message (but 
	it was bothersome!)  Once etc01 was done - source was easy ... and 
	I am now up and running, and quite impressed!!!
	--------------------------------------------------------------------
	
	Another method is to use a loop construct in the Bourne shell.  For 
	example:
	
	for i in (etc01.*)
	do
	  cat $i
	done | compress -d | cpio -idalmu

	-or-
	
	for i in (etc01.*)
	do
	  zcat $i
	done | cpio -idalmu
	
	will also solve the problem handily.  This solution solves the problem
	by running cat multiple times, with one file each.  Since cat now only
	has one file, there are no limits on the number of files that can be
	used for the distribution set.
	
2.4	Patch-kit
	
	The patchkit has been completely deprecated.  FreeBSD and NetBSD
	are both mature programs that will serve the average user extremely
	well.  The patchkit may still be available, but it os only required
	if you are installing the original 386BSD 0.1 version.

	There are two mailing lists dedicated to the patchkit.  They are as 
	follows:

	386bsd-patchkit@cs.montana.edu, which is primarily for discussion of
	up-coming patches and patchkit philosophy.
	
	patches@cs.montana.edu, which is dedicated to submitting new,
	untested patches.
	
	The current (and final) version of the patchkit is 0.2.4, which 
	has absolutely no relationship with the new version of 386bsd.  
	It is available by anonymous FTP from several sites throughout 
	the net.


2.5	Configuration

	By far, the most common configuration questions are partitioning, 
	followed closely by all of the other software in the system.  
	Sendmail and named are also problems occasionally, but the 
	documentation that comes with them usually gets you through.  If 
	you run into a problem, post a question to comp.os.386bsd.questions.  

	
	A less frequently asked question is "Where can I get info on how 
	to configure a kernel?"  The answer to this question has been 
	provided by Richard Murphey (Email address rich@Rice.edu).  
	
	--------------------------------------------------------------------
	Ready-to-print PostScript files for each section of the net2 system 
	maintainer's manual are on nova.cc.purdue.edu in 
	pub/386bsd/submissions/bsd.manuals.
	
	smm.02.config.ps.Z describes kernel configuration for the VAX, 
	however some of it is relevant to 386BSD.  There is no freely 
	available rewrite for 386BSD that I know of.  
	--------------------------------------------------------------------



2.5.1	Partitions

	This section describes many of the questions that people ask about 
	hard disk partitioning.
	
	The first is a brief explanation of the BSD system disk partitions.

2.5.1.1	What is a 'disklabel' and why do I need one?

	The BSD partition table supplements the DOS partition table.  The 
	entries in this table are meaningful to BSD.  There are eight 
	partitions in the BSD partition table, and they are normally 
	lettered from a: to h:.  This supplemental partition table is
	often refereed to as the 'disklabel'.
	

	This tutorial is provided by by "<haley@husc.harvard.edu>" and 
	provides an  excellent overview of the hard disk partitioning 
	procedure from start to finish.

		"Disk Partitioning for the Compleat Idiot"

	There are times, in our trials with our computers, that it becomes
	necessary to mess about with the disklabel. For those not
	knowledgeable of BSD or Unix Systems administration, this somewhat
	simple task can be somewhat daunting. This document is the result of
	my own short experience.

	This does not cover physical installation of the disk. For those who
	are having trouble with that, I direct you to any of the fine manuals
	dealing with hard drives and your hardware.

	It also does not deal with the vagaries of the DOS partition manager.
	It assumes you have done that as well, if need be...

	After the drive is physically installed and is recognized in the BSD
	startup, and it mentions both your drives, in the order you expect
	them... Or perhaps just the one, if you had special problems with
	installation. Now all you have to do is "disklabel" the drive... Well,
	what is *THAT*??? 

	The disklabel is used by the kernel and other utilities to tell how
	you want or have the drive set up *logically*. 

	In a beautiful world, we might have a very free hand at this set-up
	and expect it to work. Unfortunately, the authors of the software
	dealing with the hard drives either decided or were forced by
	circumstance to make certain things about the disklabel inviolate. 
	
	When you let the installation disk set the disklabel for you first
	drive it comes out like this:

	    The a: partition is the primary partition.
	    The b: partition is the swap partition.
	    The c: partition is the amount of the disk used by 386bsd 
	    	(swap and data)
	    The d: partition is the entire disk.

	Of these, the only one that could be different is a:... 

	(Note for those of us who have spent far too much time using DOS: the
	labels a: b: c: d: e: f: g: h: DO NOT refer to DOS drives, but to
	partitions in your 386bsd partition... confusing, eh?  For the sake 
	of consistency I will never make a reference to DOS drives except by
	saying something like "DOS drive C:". )

	It's possible to divide up the disk a bit differently, but three
	things MUST be:

	c: must refer to every cylinder you wish 386bsd to use, either
	for your data or the swap space. 

	d: Must refer to the whole disk, from cylinder 0 to the last
	one...
	
	b: Should always refer to a swap partition. Note that on any
	other than the first disk it does not have to, but if you
	enable swapping on that drive, and you are using b: for
	something else, that something else will be killed.

	The reason for this is simple: It's hard coded in.

	"WHY?" you ask? (I did...) Probably time constraints, maybe tradition.
	But if you look at the code in "isofs" and "ufs" in your sys.386bsd
	directory, you will see numerous comments asking some of the same
	questions, which leads me to believe this may change in the future,
	making our lives both more complicated and easier at the same time...

	Getting past the esoteric explanations, here is a method for figuring
	out and "labeling" your disk.

	We'll start with the disklabel from my second disk, in the form most
	understandable by humans... #'s signify the start of a comment.

	# /dev/rwd1d:
	type: ESDI
	disk: maxtor7245
	label: 
	flags:
	bytes/sector: 512
	sectors/track: 31
	tracks/cylinder: 16
	sectors/cylinder: 496
	cylinders: 967
	rpm: 3600
	interleave: 1
	trackskew: 0
	cylinderskew: 0
	headswitch: 0		# milliseconds
	track-to-track seek: 0	# milliseconds
	drivedata: 0 
	
	5 partitions:
	#      size  offset  fstype [fsize bsize   cpg]
  	a:   198400       0  4.2BSD    512  4096    16 	# (Cyl.    0 - 399)
  	b:    31744  447392    swap                  	# (Cyl.  902 - 965)
  	c:   479136       0  unused      0     0       	# (Cyl.    0 - 965)
  	d:   479136       0  unused      0     0       	# (Cyl.    0 - 965)
  	e:   248992  198400  4.2BSD    512  4096    16	# (Cyl.  400 - 901)
	
	Some math:
	Looking at the comments at the end and the size and offset columns,
	size is a function of (last - first + 1) * sectors per cylinder:
	a: 399 - 0 + 1 = 400 * 496 = 198400
	b: 965 - 902 + 1 = 64 * 496 = 31744
	c: & d: (Since I have no DOS partition, whatsoever)
   	   965 - 0 = 1 = 966 * 496 = 479136
	e: 901 - 400 = 502 * 496 = 248992
	
	248992 + 198400 + 31744 = 479136 (all the parts should equal the whole)
	
	Some things I discovered  (for all you in novice land like me...)
	
	1. As you can see this disk has 967 cylinders, but I only refer to 966
	of them, 0 - 965... This is because it's good practice to leave the
	"Landing Zone" cylinder out of it... This is usually the last
	cylinder, and it's where the read/write heads hang out when your disk
	is off...

	Note from TSgt Dave:

	Most modern drive heads come to rest on a polished surface inside the 
	highest cylinder.  I could be mistaken, of course, and the Hard Drive 
	Bible (or other appropriate reference manual) will tell the tale for 
	each drive.

	2. a: can be a regular partition, b: should be swap, c: everything
	386bsd will get to use, including swap. d: is the entire disk from 
	0 - (cylinder_per_disk - 2)   [leaving out the Landing Zone]

	On the boot drive (The drive that actually contains the kernel), a: 
	is the boot partition.  On all other drives, it is a regular partition.

	You can then use e - h for your other partitions. I am not sure
	whether you could specify b: as other than a swap partition and not
	run into trouble, but you could surely make it a zero sized one
	starting and stopping on the Landing Zone...

	Note from TSgt Dave:

	This is a good idea.  Another way to accomplish this is to
	simply not specify it in the map.

	3. Stupid human trick: When doing the math don't forget that 400 - 900
	refers to 50*1* cylinders. I did, for a while. No great problem I
	suspect, but why waste a cylinder...

	4. newfs'ing really is that simple if you have the label right:
	"newfs /dev/rwd?x config_template" where the question mark is the 
	physical disk, the x is a partition letter, and the config_template 
	is the configuration from /etc/disktab for your disk drive. 

	* NOTE:  This is a thumbnail sketch; read the man page to verify all 
	of the options and be sure about how to proceed...
	
	5. then fsck the partition: 
	fsck /dev/rwd?x 
	
	Don't forget that fsck should be run on the RAW device.

	6. As long as it checks out, you can then mount it and do disk things
	with it...

	7. Add it to the fstab... (follow the man page).  Don't forget 
	that your new swap partition won't work if your kernel isn't 
	configured for it, but it won't cause you any problem to have 
	it there. 

	One last note from TSgt Dave:

	And I have yet to figure out a way to determine if it is or
	isn't using the swap partition anyway.  There is a program called
	'swapinfo' and it is part of the NetBSD source tree.  On my system, 
	it tells me that I never use the swap area. :)

	Comnonly used definitions:

	bsize:
	Block Size:  This is the smallest allocatable area on a disk file 
	system, sort of.  A file uses the maximum amount of blocks until it
	can not completely fill up a block. 

	fsize:
	Fragment Size:  This is the size of the 'leftover' data that didn't
	fit into a full block.  For example, assuming a using an 8K Block
	Size/1K Fragment Size, a 34.5K file, would use up 4-8K Blocks (4 *
	8K = 32K) and 3 1K fragments (3 * 1K = 3K).  There is 512 bytes of
	wasted space, since 32K + 3K = 35K, which is 512 bytes larger than
	34.5K.  If you want to reduce the amount of wasted space, you can
	reduce your fragment size, but you also reduce the amount of data
	you read at one time, so your disk performance decreases also.
	A good setup is 8K/1K for performance, but if you are really
	concerned about wasted space you can consider using a 4K/512byte
	filesystem.

	For further information, find an article that explains the Berkeley
	FFS in more detail.

	cpg:
	Cylinders Per Group, it determines the cylinder group size, which 
	in turn determines the number and location of the alternate 
	superblocks.


	Cgd posted a description of how to manually install 386bsd and 
	create 'real' BSD partitions.  It is excerpted below:
	
	--------------------------------------------------------------------
	HOW TO GET 386bsd 0.1 INSTALLED WITH "REAL" PARTITIONING:
	
	(remember, if things don't work, they might be in places that aren't 
	normally looked in... things should work as below, but you might 
	have to use explicit paths occasionally... the 'better' stuff -- 
	mount, umount, cp, etc... is in /usr/distbin on the fixit floppy...  
	even mknod is there, if the devices you need aren't on the fixit 
	floppy...) 

	(1) boot the fixit floppy
	(2) disklabel the disk as appropriate
	(3) newfs the partitions
	(4) mount the new root partition under /mnt
	(5) mkdir /mnt/usr
	(6) mount the new /usr partition under /mnt/usr

	(7) cpio the entire contents of the fixit floppy to the hard drive
		cd /
		ls .profile * [0-ln-z]*/* */*/* | cpio -pdalmu /mnt
		(NOTE: [0-ln-z]*/* is to avoid matching mnt/mnt)
	(8) copy /usr/distbin/mount and /usr/distbin/umount to /mnt (so that
		they'll be in the new root partition, so you can mount the
		new /usr partition...)
	(9) shutdown
		and the eject the floppy.
	(10) reboot off the hard drive, then fsck -p <root raw device>
		If there are any errors, after the fsck is done, hit
		ctl-alt-delete, and repeat this step.
	(11) fsck -p <usr raw device>
	(12) mount -u <root device> /
	(13) mount <usr device> /usr
	(14) insert 0.1 boot/install floppy (dist.fs) into floppy drive
		and "mount /dev/fd0a /mnt"
	(15) cd /mnt
		and then
		usr/bin/zcat etc/baselist.Z | usr/bin/cpio -pdalmu /
	(16) cd /
		and then
	/mnt/usr/bin/zcat /mnt/etc/baseutils.cpio.Z | /mnt/usr/bin/cpio -idalmu
	(17) umount /mnt	then eject the floppy
	(18) umount /usr
	(19) shutdown
	(20) reboot off the hard drive, and get all of the various files (the
		bindist files, srcdist files, etc...).
		I put them into /usr/tmp, because there wasn't enough space
		in /tmp (because it was on a small root partition...).
	(21) cd / ; cat <all the binary files> | uncompress | cpio -idalmu
	(22) rm <all the binary files>
	(23) put your hostname into "/etc/myname" and put your ip addr/hostname
		into /etc/hosts.
	(24) make an fstab for yourself.  specifically, you want something like:
		<root device name>	/	ufs rw 1 1
		<usr device name>	/usr	ufs rw 1 2
	
	congratulations!  you now have a working system!
	
	you can repeat step 21 for the srcdist and etcdist files, as well, 
	if you wish...


2.5.2	Common Disk Label Problems.
2.5.2.1	Swap space.

	Nate Williams provides a short tutorial on swap space in 386bsd, 
	excerpted below:
	
	To be able to use additional swap partitions, you need to specify 
	them in the config (/sys/i386/conf/WHATEVER) file.
	
	Ex:
	
	config          "386bsd"        root on sd0 swap on sd0 and sd1
	
	Allows swap on sd0 and sd1
	
	config          "386bsd"        root on wd0 swap on wd0 and sd0
	
	This would allow swap on both wd0 and sd0 OR whichever (both/either) 
	of the two had a valid disklabel.  Note, you can really screw 
	yourself up with this, if you should happen to not want to swap to 
	this partition, and it happens to be the first one found...
	
	The problem of not being able to swap was from the config file not 
	having wd1 in it.
	
	controller      wd0     at isa? port "IO_WD1" bio irq 14 vector wdintr
	disk            wd0     at wd0 drive 0
	disk            wd0     at wd0 drive 1
	                ^^^                  
	This should have been wd1, and that's why it didn't get added by 
	default.  I may be wrong, but I have swapped to two different 
	partitions w/out any problems since patchkit 0.1, and there aren't 
	any patches to swap386bsd.c
	   
	Once the install is complete, swapping will not be enabled on the 
	second drive.  The following steps can be used to make sure that it 
	is enabled correctly.
	
	If there is a 'b' partition in your root disk 386bsd partition, it 
	will be used automatically (MAKE SURE B is not the start of the 
	disk, and MAKE SURE b doesn't contain any data you wish to keep).  
	If b starts at disk offset 0, it will promptly wipe out your boot 
	sectors and other important disk stuff.  (This appears to be fixed
	in the current NetBSD sources)
	
	If you want an additional partition, put an entry similar to this 
	in /etc/fstab:
	
	/dev/sd1b	none			swap		sw
	
	I'm swapping on sd0b and sd1b, and 'swapon' is run on this partition 
	on boot up.
	
	Swapping to a file is still not implemented.  Rumor has it 0.2 will 
	have such things.  If someone wanted to add it, the vnops_* files 
	would have to be radically modified to get it to work correctly.


2.5.2.2	Increasing the 386bsd partition size.

	Once the install is finished, the system has it's 386bsd partition.
	This includes a 5Meg swap partition, which is altogether too small.  
	There is no easy way to increase this swap partition without 
	relabeling the drive.   Unfortunately, relabeling usually involves 
	reinstalling.  That involves re-doing just about everything you have 
	just finished doing.  The good news is that if all you have done is 
	the base installation, you don't have a lot of time and energy 
	invested in the system.  Take the time, and make sure that your swap 
	space is at least as big as your memory; many people recommend even
	larger.  There is no real limit to the size that this space can
	take.  If you have two disk drives, you can have space space on both.
	Simply follow the instructions above, and you will be all set.
	If your swap space is smaller than your real memory, system core 
	dumps will be disabled.


2.5.2.3	I can access the DOS partition on my second disk from Unix but not 
	DOS?  Any suggestions?

	One kinky problem that almost got me was when I tried to disklabel 
	my second drive in order to use the DOS partition on it, and use 
	the rest as swap for BSD (FreeBSD-1.0 Eps, SCSI drive on an AHA1542B, 
	to be exact). The DOS partition was visible from UNIX, but *not* from 
	DOS.

	What I tried to do:
	    Using PFDISK (from DOS), make one big DOS partition at the start 
	    and use the rest for a BSD partition (type 165).  Something that 
	    came out like
		  1    6    0	69 DOSbi # ..
		  2    165  70	98 unkno
	    for a 99 cyl drive.

	
	    Using BSD disklabel generate disk description/label as documented 
	    in the FAQ. Make only 'c' (total BSD DOS part), 'd' (complete disk) 
	    and 'b' (intended swap) BSD partitions.

	Problem:
	    When writing the label, disklabel would ask about overwriting DOS
	    partition table.  Whether I said y or n, the DOS partition table
	    was screwed up, as seen from DOS (BSD saw the DOS file system
	    very nicely indeed).

	Cause, solution:
	    BSD disklabel wants to write the label to the start of the 'a' 
	    partition; I had *not* defined an 'a' partition (since I was 
	    only using the disk for swap).  This tells disklabel that the 'a'
	    partition is the start of the disk, which means there is no DOS
	    partition.  Disklabel then writes the label at the start of the 
	    drive, which is why it talks about overwriting (aha!); this is 
	    *bad* for the DOS partition table.  One solution is to have a 
	    non-empty (e.g. one cylinder) 'a' partition at the start of the 
	    BSD part of the disk, and resize the 'b' swap partition 
	    accordingly.  Now everything works just fine.


2.5.3	How do I set up the system so that I can boot from more than one
	operating system/file-loader without using floppies?
	
	There are many people that wish to be able to boot DOS or 386bsd 
	at will.  There are several programs that allow this.  The 
	program "os-bs" is one such program, "BOOTEASY" is another, and 
	there are three or four others.  There are problems in some 
	configurations using the os/2 boot manager for this, so beware.  
	
	In addition to being able to boot from either of two partitions, 
	some people want to operate more than one disk drive (and perhaps 
	boot from either as well).  Christoph Robitschko provided one 
	description of this.  Since there are virtually limitless 
	possibilities for configurations for BSD systems, it will be 
	impossible to answer all of the possible questions about these 
	features.  Many people operate with multiple disk drives on one 
	or more controllers.  

	Yu-Han Ting provides this tutorial on partitioning and booting
	multiple systems with a single hard disk.

	After spending one day fighting with the nasty partition table, 
	finally I had NetBSD, DOS 5 (Sorry, I don't use DOS 6), and 
	OS/2 2.1 March beta co-existing on my hard drive.  Here is the 
	answer:

	Since that my original hard disk setup was corrupted by NetBSD's
	installation program, I decided to rebuild it.  I would like my 
	partition table looks like this:

	Partition 0: OS/2 2.1 beta (Primary, HPFS, C:)
	Partition 1: MS-DOS 5.0 (Primary, C:)
	Partition 2: MS-DOS 5.0 (Extended, D: & E:)
	Partition 3: NetBSD

	You will need the following tools before you can setup a similar 
	environment:

	1) Mr. Wolfram's OS-BS.  (It's an excellent boot selector, much
	   better than OS/2's boot manager, IMHO)
	2) PFDISK.EXE.  (It's available from wuarchive.wustl.edu:mirrors/
	   linux/dos_utils/pfdisktc.zip.)
	3) A binary editor.  I use Norton Utilities' DiskEdit.
	4) 386BSD's 'tinyBSD' distribution disk.

	After you have the necessary tools handy: 

	1) Use OS/2 'fdisk' to create partition 0.  Make it install-able 
	   and install the system as usual.
	2) Use OS/2 'fdisk' to create partition 1.  Assign drive C: to 
	   the partition.  Then reboot from DOS.
	3) Use DOS 'fdisk' to create the extended partition.  Assign logical
	   drive D and E to the partition.
	4) Reboot from DOS again.  Format drive C: (for DOS), D:, and E:.
	5) Use 'tinyBSD', NOT 'NetBSD', to boot the machine.  Create a genuine
	   386BSD partition.  Once the 386BSD partition has been made,
	   boot DOS from floppy and execute PFDISK.EXE.  For example, issue
	   the following commands once you get into DOS:

		C>pfdisk 0 <enter>
		pfdisk> L <enter>  ("pfdisk>" is the command prompt and "L"
				    is the actual command.)

	   The second line, i.e., command 'L', will tell you the starting
	   address and the length of each partition you have.  Record the
	   information for step 6.
	6) Reboot NetBSD from floppy.  Install NetBSD over the original
	   386BSD partition.  Fill out the information you get from step
	   5 to the installation program.  'halt' the system after you
	   have installed 'install2.fs'.
	   (Ed.Note:  This step is the same for 386bsd or NetBSD)
	7) Boot OS/2 from floppy.  Use fdisk to assign drive C: to the OS/2
	   partition.  In my case, partition 0.  Note that fdisk will
	   change the ID of partition 1 from '0x06' to '0x16'.  '0x06'
	   stands for 16-bit DOS FAT; while '0x16' stands for non-DOS
	   partition.  In the next step, we have to change '0x16' back to
	   '0x06' manually.  You can get the ID information by issuing "I"
	   under PFDISK.  It will tell you what the IDs represent.
	8) Boot DOS from floppy.  Use the binary editor to change the
	   partition type as stated in step 7.
	9) Install OS-BS under DOS.  Remember to enable "Modify startup ID
	   before booting".
	10) Now you can boot any partition w/o floppy diskettes during
	    startup. :)

	The above procedures may not be optimized.  But it works for me.  
	I won't spend anytime to deal with tedious work again :)

	You might feel strange why we need 'tinyBSD'.  Simply trust me.  
	By using 'tinyBSD' to create a partition for NetBSD, it will 
	make your life a lot easier.  Hope this helps.  

	Ed. Note:  The reason is because several versions of NetBSD and 
	FreeBSD will not label a disk that doesn't have a disklabel.  
	Catch-22.


	PS:  %%%%% REMEMBER TO BACKUP YOUR SYSTEM BEFORE YOU CONDUCT THE 
			EXPERIMENT !!! %%%%%

	Here is Christoph's explanation of how to set up a dual hard drive
	system so that the 386BSD/NetBSD system is stored entirely on the
	second hard drive.

	I have done this with two IDE drives. IDE+SCSI should be a bit 
	simpler.  There's a boot selector called BOOTEASY that can load 
	from the second drive (you can get it from 
	ftp.tu-graz.ac.at:pub/386BSD/0.1/unofficial/booteasy).

	What I have done to boot 386bsd from the second (IDE) drive:

	- installed booteasy on the first drive
	- (you can install booteasy on the second drive, too, if you
	  have multiple partitions there)
	- modified Julian's boot blocks to use the second drive per default
	  (Ed. Note:  See below for the illumination of this step)
	- rebuilt the kernel to have root and swap on wd1 (probably not
	  necessary for you, since your second disk is sd0, which is
	  already in the config file).

	It worked perfectly for me.

	This should also work with equal facility for 386bsd users.

	Julian Elischer (julian@jules.dialix.oz.au) adds:

	To make the bootcode default to drive 1 look in 
	/sys/{arch/}i386/boot/boot.c for the following (or similar.. It has 
	changed a little) code:

loadstart:
 
	/***************************************************************\
        * As a default set it to the first partition of the first	*
        * floppy or hard drive						*
  	\***************************************************************/
        part = unit = 0;
        maj = (drive&0x80 ? 0 : 2);             /* a good first bet */
        name = names[currname++];


	and change it to:


loadstart:

	/***************************************************************\
	* As a default set it to the first partition of the SECOND	*
	* floppy or hard drive						*
	\***************************************************************/
!	part = 0;
!	unit = 1;
	maj = (drive&0x80 ? 0 : 2);             /* a good first bet */
	name = names[currname++];

	And in yet another interation, Luke Mewburn (lm@yallara.cs.rmit.oz.au)
	decided to hack that a bit further in his NetBSD 0.9 (as_shipped i.e., 
	non-current) to set the drive to the unit which the boot blocks 
	loaded off.

	So, instead of:
		part = unit = 0;
	do:
		part = 0;
		unit = (drive & 0x7F);

	(the FAQ suggests `part = 0; unit = 1;' )

    	This way, whatever drive the bb's loaded from, it has that as
	default.  In my case, I get wd(0,a) when I have my netbsd drive as
	C:, and wd(1,a) when I have it as D:.  (I've been swapping drives
	left right and centre the last day getting dos to boot on one drive
	and netbsd on another).


2.5.4	How do I disklabel my second hard drive?

	The obvious answer is to use 'disklabel -w -r /dev/rwd1d'.  
	Unfortunately, this does not always put a real disklabel on the
	drive.  The symptom is that the drive labels and can be used
	until the system is reset, at which point the system tries to
	read the label from the disk.  It was never actually written to 
	the disk, so the operation fails.

	There are also reports that the /usr/mdec files are corrupted in 
	some of the distributions.  If you have tried everything else, you
	can either load the files from one of the many archive sites that
	keep the /usr/mdec files around, or you can recompile them 
	yourself.

	Mark Weaver (mhw@cs.brown.edu) provides us with an illuminating
	answer to this perplexing problem.

	I had the same problem and there is a simple solution.  I'm not 
	sure why this works, but it does.

	Instead of specifying the entire device path name (i.e. /dev/rsd0c), 
	only specify the two letters of the device type and the unit number 
	(i.e. "sd0").  Disklabel figures out the rest, and it works.

	For instance, the following line works for me:

	  disklabel -w -r sd0 <drive-type>

	assuming of course that the boot block files are in /usr/mdec/ and
	the <drive-type> is in the /etc/disktab.

	This is also a symptom of some of the versions of FreeBSD and 
	NetBSD where the disklabel code was 'fixed' to only write a 
	disklabel on a drive with a disklabel.  Oops.


2.5.5	386bsd/NetBSD/FreeBSD cannot handle disk geometry translations, 
	but it turns out that my disk geometry is translated.  It has 
	five zones, each with a different sec/track!  What kind of 
	things can I do about the disk translation my hard disk 
	controller uses?

	It turns out that what *BSD cannot handle is not translation, but
	translation that changes during the boot-up process.  For example,
	the configuration above will work just fine IF the translation
	that the controller uses when it powers up is the same one that it
	uses when it boots.  On many PC clones, the BIOS loads a different
	geometry after it boots to make the geometry agree with one that is
	loaded in CMOS.  This is the fatal flaw for *BSD.  Fortunately, 
	once the problem has been identified, it is relatively easy to
	handle.  Simply make sure that the BIOS is configured to set the
	controller to the translated geometry that the card powers up 
	with.
	
	There are several ways to get around these problems with disk 
	geometry translation.  If you are using a SCSI controller, you can
	specify the geometry such that each 'cylinder' is 1 Meg (64 sectors
	by 32 tracks for example).  Most SCSI controllers will blithely
	ignore what YOU tell it the geometry is and press on using this
	type of 1 Meg cylinder had to get the job done.  NOTE:  If you are
	going to try this, try to ensure that each 'pseudo cylinder' is a
	reasonable size (like 1Meg or 512K).

	An interesting method for dealing with disk geometry comes from 
	Alan Barrett (barrett@lucy.ee.und.ac.za):

	This sort of problem happens when you try to install NetBSD in a
	partition of a disk whose controller does geometry translation.  I
	have not had time to find the bug that causes the problem.  One 
	option is to disable the geometry translation:  Use ide_conf to 
	find the true geometry, use the CMOS setup program to tell your 
	BIOS about the true geometry, and reformat everything.  I 
	successfully did that on one of my systems.
	
	If you are not able to, or do not wish to, disable the geometry
	translation then the following work-around might work for you.  
	This requires that the disk have unused space on {cylinder 0, 
	head 0}, from sector 2 to sector 16.  Almost all DOS disks that 
	I have ever seen satisfy this condition, because they usually 
	start the DOS partition in {cylinder 0, head 0, sector 1}, 
	leaving most of {cylinder 0, head 0} unused apart from the 
	partition sector in {cylinder 0, head 0, sector 1}.  However, 
	many partitioning programs like to hide this fact from you, 
	and pretend that the DOS partition starts at the front of the 
	disk; don't believe them until you have checked with a raw 
	disk editor.

	    0.  Make sure you have adequate backups.

	    1.  Use a partition sector editor (fdisk, pfdisk, os-bs, 
	    	booteasy, Norton utilities, whatever) to mark the partition 
	    	that you want for NetBSD as bootable with type 0xA5 
	    	(decimal 165).

	    2.  Halt the system.  Boot the NetBSD kernel copy floppy.  
		When it asks you to insert the floppy for the root file 
		system, switch to the Install-1 floppy and press enter.

	    3.  Answer all the installation prompts, using numbers based 
		on the translated geometry.  When it asks if you really 
		want to label the disk, be brave and say yes.

	    4.  Halt the system.  Boot to DOS.  Run a disk editor program, 
		such as Norton utilities.

	    5.1.  Verify that the partition sector in {cyl 0, head 0, 
		sec 1} is undamaged.  Verify that the disklabel program 
		run as part of the NetBSD install has written the NetBSD 
		primary boot block to {cylinder xx, head 0, sector 1}, 
		written the disk label to {cyl xx, head 0, sec 2}, and 
		written the secondary boot program to {cyl xx, head 0, 
		sectors 3 to 16}.  ("xx" represents the translated 
		cylinder number you chose for the start of the NetBSD 
		partition.  You did choose to start on a cylinder boundary, 
		I hope.)

	    5.2.  Verify that the space in {cyl 0, head 0, sectors 2 to 
		16} is still available.  Copy the fifteen sectors containing 
		the NetBSD disk label and secondary boot block from {cyl 
		xx, head 0, sectors 2 to 16} to {cyl 0, head 0, sectors 2 
		to 16}.

	    5.3.  Edit the partition table in {cyl 0, head 0, sec 1}.  
		Change the system ID of the NetBSD partition from 0xA5 
		(decimal 165) to something else (I use 0xA4, decimal 164), 
		but keep it flagged as bootable.  This will let you boot 
		to the NetBSD primary boot block.

	    5.4.  Edit one of the previously unused partition table entries 
		(I hope you have one), to contain the following information: 
		{sys id = 0xA5, boot flag = 0, start cylinder/head/sector = 
		0/0/1, end cylinder/head/sector = anything, initial 
		offset = 0, total size = anything}.  This will tell the 
		NetBSD primary boot block, or a NetBSD system booted from 
		a floppy, that it should look for the NetBSD disk label 
		in {cyl 0, head 0, sec 2}.

	    6.  Halt the system.  Boot the NetBSD kernel copy floppy.  When it
	    	asks you to insert the floppy for the root file system, just 
	    	press enter without changing disks.

	    7.  Copy the kernel, and proceed with the rest of the installation 
	    	as per the instructions provided with NetBSD.  It should now 
	    	work because of the trickery with the partition table etc.


2.6	Common installation problems.

	There are many common installation problems.  This section covers
	the most basic and common of these problems.  In addition to this
	section, you should also read through the other sections of the
	FAQ, since many of the less common questions are answered in other
	places in the doc.

2.6.1	Swap space not identified correctly.
	
	There are several levels of problems associated with swap space.  
	The first is that the swap space on a second disk will not get 
	used if it is not in your /etc/fstab file.  Your /etc/fstab should 
	have the swap space identified.  The following is a representative 
	fstab:
	
	/dev/wd0a		/		ufs  rw 1 1
	/dev/wd1b		swap		swap sw 0 0
	 
	Another common question is that the install program installs the
	swap partition in the 'b' partition, but does not mark it correctly
	as a swap partition.  The swapping software will use the swap 
	partition regardless of what it is called, but it should still be
	identified in the disklabel as the swap partition.  Use 'disklabel'
	to change the partition type from 'unused' to 'swap'.

	NOTE:  I mean it when I say that 386bsd will use the b: partition
	for swap without regard to what you called it.  If it was your 
	root partition, it will be toast the first time you try to swap
	a process out to disk.  I'm not kidding!


2.6.2	Endless reboot cycles.
	
	Endless reboot cycles are the single most vexing aspect of 386bsd.  
	Part of the problem is that the 0.1 distribution boot routines 
	were never checked against many types of computers and have bugs.  
	Most of the bugs are fixed in the patchkit, but that doesn't do 
	the average novice user any good.
	
	In general, this will show up as a "bad disk label" error, and 
	can result in in not booting from the hard drive "most of the time".  
	You may be able to partially (or even completely) work around this 
	problem by making your machine run at a lower clock rate.

	This problem is the result of the kernel reading the wrong register 
	waiting for the drive controller to come ready.  On some 
	controllers, this isn't a problem; on others, it's fatal.
	This problem is solved for almost all controllers in the patchkit
	and both FreeBSD and NetBSD.

	The correct solution is to use a patched "dist.fs" or "fixit.fs" 
	boot disk.  These have been provided by the patchkit maintainers 
	and are located on the machine agate.berkeley.edu in the directory 
	pub/386BSD/386bsd-0.1/unofficial/patchkit.  In addition, new
	patches kernels or a NetBSD kernel may be able to solve your 
	immediate problems.

	Another incarnation of this symptom is that the disk geometry on 
	your disk label (as installed by install) is different than the 
	geometry that your hard drive controller thinks it is using.  This 
	will most often manifest itself on controllers that insist on 
	operating in some type of translation mode.  Normally the fix is to 
	find out what the controller geometry is and make the disk label 
	agree.  There are programs available to help with this problem.  

	Julian's new boot blocks may also solve this problem.  They are 
	available where fine precompiled kernels may be found.  Also, they
	are included in the patchkit as of version 0.2.2.


2.7	The computer just sits there, or 'that isn't right'.
	
	This class of problems is sometimes caused by an incorrect FTP of 
	the boot disk.  Make sure that the files were grabbed in 'binary' 
	mode and that the size reported back is 1244000 bytes.  Use the 
	Unix program 'dd' or the DOS program RAWRITE to put these files 
	onto the diskette.  In addition, this is the 'miscellaneous' 
	section of the FAQ.  These problems are included here because they
	are usually preceded by 'I just finished installing...'


2.7.1	The boot disk works all right on one computer but not another. 

	This could be a problem with many different pieces, some of which are: 

	- Misconfigured hardware.  The iomem, IRQ, and other board settings 
	must match the ones listed in the INSTALL.NOTES.  Unfortunately, the 
	INSTALL.NOTES are on the disk that will not boot.  You can grab them 
	via FTP from /pub/386BSD/386bsd-0.1/filesystem.

	- Unsupported hardware.  There are several SCSI controllers on the 
	market that are not fully supported by 386bsd.  The Ultrastore 24F 
	(when not running in ISA emulation mode) is a good example of this.  
	There are also some network cards that are not directly supported 
	in 386bsd.  If you get into a real bind, you can post a question 
	to comp.os.386bsd.questions, and one of the many experienced 386bsd 
	gurus that reads that group will probably try to help you.

	
2.7.2	The screen has "flashing multicolored characters and ptdi81061 
	prompt" error?
	
	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).
	
	To solve this, Terry Lambert wrote a program in (forgive him!) 
	Turbo C to read and write CMOS values, so that he could force the 
	memory count to the correct value.  For a machine with a base 
	memory of 640K, the expected value in CMOS is 0280 (in bytes 
	0x16 and 0x15, respectively).  What the AT&T boxes and the HP 
	Vectra have is 027f, so it falls through to the default case and 
	blows up.
	
	The quick and dirty work-around:  If you download the new patchkit 
	bootables from agate.berkeley.edu they have fixed these problems.  
	If not, 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.
	
	It should be noted that, if you download uzap, you should "touch" 
	uzap.c, as otherwise, make will try to use lex to create it, and
	will probably fail.  This is due to the tar extraction order from
	the uzap tar archive.


2.7.3a	I get the error "isr 15 and error: isr 17" on an NE2000 card.
2.7.3b	I have some card on IRQ2 and it doesn't work; why?
2.7.3c	I am getting lousy performance out of my network card.  What are 
	    some of the other possibilities?
	
	The description of this problem is that one of the cards in your 
	system; most likely the VGA card, is either generating interrupts 
	or is causing the IRQ 2 to be actively disabled.  The VGA card uses
	IRQ 2 during vertical retrace to prevent sparklies.

	One solution would be to plan on not using your Ethernet card until 
	you have rebuilt the kernel so that it expects it at an interrupt 
	other than IRQ 2 or 9, re-jumper or reconfigure the card to match the 
	IRQ you have selected, and enable it.  
	
	From time to time, this problem will manifest itself as a general
	tendency of the network card to transfer either very sporadically
	or very slowly. It is precisely the same problem.

	James Van Artsdalen (email at james@bigtex.cactus.org) has given us 
	a solution:
	
	--------------------------------------------------------------------
	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.

	If this is the problem, you can use Scotch tape to cover the IRQ 2 
	signal on the VGA's ISA connector.
	--------------------------------------------------------------------
	
	There has been some discussion as to whether scotch tape is really 
	appropriate inside a card slot.  My answer would be "yes".  This is 
	because the alternate solution of cutting the trace on the video 
	board seems, to my mind, to reduce the value of the board.  It is 
	possible that, in the future, with a bi-bipartite driver, you would 
	want to catch the retrace interrupt to get rid of "sparklies" or to 
	implement a driver for a very high resolution monitor for X.  In 
	this happens, given a choice between alcohol and solder, I vote for 
	alcohol.
	
	Either way, you will probably find that your VGA card uses IRQ 2
	strictly for compatibility with older cards.  With the advent of
	dual-ported memory for video cards, virtually all of these types
	of problems have disappeared.


2.7.4	What is the difference between IRQ2 and IRQ9?  Are they really
	the same, or are they really different?  

	Holger Veit (veit@mururoa.gmd.de) says:
	IRQ 2 is unused on XT systems (except for retrace on some VGA 
	cards), so the board might offer this as a valid interrupt.  
	On an AT system (including the 386/486-ISA boards) there are two 
	interrupt controllers.  The second one is chained to the first via 
	interrupt line 2, so this one is actually used to forward 
	interrupts from the second controller.  So IRQ 2 is not a good 
	choice.  IRQ 8, which is the first interrupt line on the second 
	controller, serves as the "no interrupt" signal for the second 
	controller.  So the first available interrupt on the second 
	controller is IRQ 9.  

	It is reported that on AT bus systems, the IRQ9 trace is in the 
	same place as the IRQ2 trace on XT bus systems.  



2.7.5	Some of my SCSI devices (like a tape drive) don't work; why?
	
	That is because the original SCSI drivers didn't recognize any 
	devices past the first two (ID 0 and ID 1).  Also, there was a bug 
	in the distribution floppy regarding the devices at ID 6.  The 
	'dev' files for that id need to be remade.  Use MAKEDEV to do that.

	The disks and tapes will be recognized and configured when they 
	are first accessed. 
	
	A new and improved SCSI driver has been written by Julian Elischer 
	and is available from many sources.  It includes support for many 
	new types of SCSI controllers and many devices that are thereby 
	attached.  This driver is included in the patchkit.

	In addition, many of these types of devices are supported in 
	FreeBSD and NetBSD.  If one of the devices you are interested
	in using is not supported in 386BSD, you might try one of these
	newer systems.


2.7.6	I try to run 'ps' or 'w' and get ': cannot get namelist'
	from the TinyBSD kernel.  What did I do wrong?

	Nothing.  There is a class of programs that interact directly with 
	the current kernel.  These programs include 'ps', 'w', 'uptime', and 
	others.  The shell on the TinyBSD disk is not capable of supporting 
	these programs because the symbol table that these programs use has 
	been stripped out of the kernel to save space.  The easiest way to 
	fix this is to get a  different kernel (build it yourself, or from 
	agate.berkeley.edu or one of the other FTP sites).  Of course, you 
	can have a fully functional system with these programs, but they are 
	nice to have.  


2.7.7	I get a 'Floating point constant out of range' when I try to compile
	package 'n'.  What is broke?

	This problem was encountered during many package compilations, 
	including compiling gcc-2.3.3 under NetBSD-0.8.  

	NetBSD-0.9, and presumably FreeBSD, contain a repaired printf()
	function, which corrects this problem.  The easiest solution for
	this (and MANY other) problems is to upgrade.  In addition, these
	systems also include gcc-2.3.3 (or newer) as the default compiler.

	There is also a circular dependency for protoize.o/unprotoize.o 
	in the Makefile. Add the lines
 
	      touch protoize.o
	      touch unprotoize.o
 
	after the line:

	      touch stamp-proto
 
	After this "make bootstrap" will run to completion.

	gas apparently has bugs too.  It should produce +Infinity.  I 
	think it is OK internally but it may be trusting the library 
	too much.  gcc can easily be changed to avoid printf for output, 
	but input is harder.
 
 	One of the problems is that various pieces of code rely on the
 	value of DBL_MAX.  A kludge to fix it is to change the line
 	below:

	#define DBL_MAX         1.7976931348623157E+308

	One value that works is
 
 	#define DBL_MAX         1.7976931348623147E+308
	                                        ^ was 5

	This is a kludge, but it does mostly work.


	The problem is entirely in printf() (really in cvt()), NOT in
	atof().  I have inspected the output of atof() bit by bit, and 
	it is well within IEEE specification.

	The digits `157' are the `best' approximation.

	The code for printf() generates a representation which is not even 
	in the range of doubles.  Below are the details:

	atof("1.7976931348623157e+308") returns 
	
	 	0x7fefffffffffffff

	which is the maximum double value and is correct.  However, 
	printf() of the previous yields `1.7976931348623168e+308', which 
	isn't even within the floating point range.  It is clearly printf() 
	that is broken, and a quick inspection of the code is enough to 
	determine that it uses a pessimal algorithm.

	atof() has been tested with many other values, and it has never 
	been off by more than is allowed by IEEE 754 (though it is not 
	optimal).


2.7.8	I want to use the Adaptec 1542C SCSI controller.  What are the 
	problems/tricks you need to know to get it working?

	The first thing to check when trying to use the 1542C is the setting 
	of 'Enable Disconnection' under the 'SCSI Device Configuration' 
	menu.  It should be set to YES for all devices, as the manual warns 
	you. 

	Matthias Urlichs (urlichs@smurf.ira.uka.de) has provided this 
	description of the types of things that can cause problems for the
	controller and devices attached to it.
	
	The problem is that the Adaptec 1542C has (a) rather powerful line 
	drivers, and (b) is sensitive to transient signals which can be 
	induced by them via either a bad cable or a bad external terminator.

	A bad cable is almost any cable which doesn't meet SCSI-2 specs.

	A bad external terminator is one which doesn't adequately buffer 
	its resistor network.

	So...

	- Remove the internal terminator from the last drive in your chain. 
	  Replace with an active SCSI-2 external terminator.  Side 
	  improvement: active terminators consume a bit less power.

	- Check cables.  Specifically, some cables carry less than the 
	  nominal 50 signal wires. Manufacturers sometimes think they can 
	  get away with this because almost all odd-numbered pins are GROUND 
	  anyway. So, if pins 1 and 3 or 3 and 5 are connected, you're 
	  likely to have a marginal cable.

	- Make sure that the terminator power is supplied by all devices 
	  and that the power pin is actually connected on your cable. The 
	  problem here is that some idiot device manufacturers save on 
	  2-cent diodes, which means that the thing will pull terminator 
	  power to ground if it's not plugged in.  (Two of these on one 
	  bus are even worse.)

	- Consider creating your own cabling. Take a 50-wire flat ribbon 
	  and press the appropriate connectors onto it in precisely the 
	  right places. (Move your devices as to minimize cable length.) 
	  Be aware that if a device has two external connectors, you must 
	  take the SCSI bus in at one connector and out at the other 
	  -- don't leave the other connector dangling; this isn't within 
	  the SCSI specs because the cable usually is too long.

	- Better but more expensive: use 2-twisted cable. (I.e., wires 1&2 
	  are twisted around each other, wire 3&4, ...) This will improve 
	  reliability because the wires are twisted at different rates. 
	  These cables have short non-twisted segments every 50 cm (1.5') 
	  so that you can press on your connectors instead of heating up 
	  that soldering iron.

	- While you're rebuilding your system anyway...: If you have more 
	  than one drive per power supply, check if these drives have 
	  adequate condensors to buffer their power.  I have two 80-MB 
	  Seagates which refused to work more than a few hours without 
	  glitches -- then I soldered two 10-uF Tantals onto their power 
	  connector and they've been flawless ever since.

	The terminator power is pin 26. Be aware that SCSI counts pins as 
	they appear on a ribbon cable, not as they're sometimes numbered 
	on the connectors.  Pin 25 is supposed to be disconnected.

2.7.9	Did anyone ever find out on how to use the 3c509 etherlink III 
	card yet for bsd?

	Herb Peyerl (hpeyerl@fsa.ca) responds:

	I have a mostly working 3c509 driver that I've been working on 
	for far too long.  There are a couple of problems with it that 
	I've addressed (in my mind mostly).  I have several things I have 
	to do before I can go back to working on it (mostly Windsurfing, 
	waterskiing, suntanning, climbing, and drinking)...

	I have yet to look at the recently announced Linux 3c509 driver 
	but plan to do that to see if it can address any of the problems 
	that I'm having.

	I always offer to give out my existing code on the off chance i
	that someone has more energy and time than I do to get it working.
	But invariably I end up getting requests to photocopy and mail my 
	documentation which is something I'm tiring of doing.

	So, to everyone who's waiting for a 3c509 driver, I say "keep 
	waiting, it'll happen someday"...


2.8	Other common problems that are attributed to the installation
	process but are caused other places.
	
2.8.1	Why don't the man pages for "magic" and "file" work?

	The manual page for magic and file all have two dots before the 
	commands,  e.g.. "..SH" it should be ".SH" just delete one of the 
	double dots in the whole file and then it will work.  These man 
	pages are fixed by both the patch-kit, NetBSD, and FreeBSD.  The
	only time this problem every occurs is when you are using the
	distribution from one of the old CD-ROM distributions are get the
	original 386bsd 0.1 release.


2.8.2	Why is apropos broke?

	The Makefile in /usr/othersrc/share/man/Makefile creates the 
	whatis.db.  The problem is that it doesn't strip the backspaces in 
	the title and apropos can't handle that.  So add a "col -b" to strip 
	those.

	excerpt from the Makefile.

	makedb:
	   for file in `find /usr/share/man -type f -name '*.0' -print`; do \
		sed -n -f /usr/share/man/makewhatis.sed $$file; \
	   done | col -b | sort -u > whatis.db
	   install -o ${BINOWN} -g ${BINGRP} -m 444 whatis.db \
	              ${DESTDIR}/usr/share/man

	This problem is also solved in the patchkit, and other *BSD releases.

	Also, if the Makefile is moved to the /usr/share/man directory, the 
	whatis.db will reside where it needs to eventually reside, and the 
	install will wipe it out.  An easy fix for that problem is to change 
	the two references of whatis.db in the excerpt above to 
	/tmp/whatis.db.  This will ensure the file is correctly built and 
	installed.


2.8.3	I want to use more than 16 Megabytes of memory.  Will any of the 
	Net/2 derived BSD systems support it?

	Early on, 386bsd 0.1 would choke radically on any system that had
	more than 8M of memory.  With the advent of the patchkit, this 
	problem was, for the most part, solved; memory could then expand to
	the 16M limit inherent in the ISA bus.

	As people started using VESA and EISA busses, however, attempts 
	were made to push the envelope even further.  Memory limits have 
	expanded seemingly without limit.  Since the EISA bus (for example) 
	has more than the 24 address lines (the 16Meg limit), it is capable 
	of supporting more memory.

	When using NetBSD and FreeBSD, there is no SOFTWARE limitation on 
	more than 16Meg of memory.  There are still hardware limitations.
	The limit is caused by DMA controllers which copy memory images
	around the system.  Many cards which people use in VESA and EISA
	machines either emulate ISA cards (in order to work with *BSD) or
	are really ISA cards.  

	Jordan K Hubbard (jkh@thrush.lotus.com) has provided this 
	explanation of the distinction:


	Just so long as you're using a DMA-using disk controller in EISA 
	mode, rather than ISA mode, you can use more than 16 Meg of memory.

	For those who may find such a distinction confusing, let me explain:

	You can use an ISA controller (such as an Adaptec 1542) in an EISA
	machine, but as it will still think it's in an ISA box and refuse to
	use the extra address lines, this is no different than having an
	ISA machine as far as >16MB is concerned.

	You can use an EISA controller in "ISA mode", meaning it uses the
	older protocols for compatability reasons (examples being Adaptec 
	1742 in "standard" mode, DTC 3290 in "Adaptec" mode, etc) and 
	again, does not use the extra address lines.

	The only way to get full EISA, 32MB-of-memory-and-everything, mode 
	is to use an EISA controller in full EISA mode (for Adaptec 1742, 
	this is "enhanced" mode, for DTC 3290 it's "DTC" mode).

	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

	In addition, several other types of EISA controllers which do NOT
	use DMA will not cause problems.  IDE, ESDI, and RLL controllers
	are examples of this type of card.  The discussion above also applies
	to VESA and VLB cards. 

	So, the bottom line is that you are limited to the amount of memory
	that your DMA equipped devices can access.  Once again, the weakest
	link is the strength of your machine.

2.8.4	I tried to use a device in my computer that should be there.  When 
	I did, I got a "Device not configured error."  What do I do now?

	Garrett A. Wollman (wollman@emba.uvm.edu) provides us with this
	brief discussion in answer to a specific question.  It wears well
	as a generic answer as well.

	When any program tells you ``Device not configured'', it's trying 
	to tell you something very important about what you tried to do:
	namely, that the device you tried to access is not configured 
	into the running operating system.  This is the error message 
	corresponding to ENXIO.

	There are three major causes for this error:

	1) The kind of device you requested was not configured into the
	   system.  This is Robert Wheeler's problem; the generic kernels 
	   are not distributed with the Berkeley Packet Filter enabled by 
	   default.  To correct this, you must add the appropriate device or
	   pseudo-device to your kernel configuration file and recompile.  
	   (In this particular case, `pseudo-device bpfilter
	   number-of-network-interfaces'.)

	2) The kind of device you requested was configured into the system,
	   but either the device you requested is would use more than the
	   maximum you configured into the system, or if a physical device,
	   was not found during autoconfiguration.  To solve this, either
	   change your configuration file, or change the I/O settings on the
	   device to match what the file says.

	3) The major or minor device number specified by the device's
	   entry(ies) in /dev is incorrect.  To solve this, re-MAKEDEV the
	   device (read the MAKEDEV script for more details).  Hopefully
	   whatever change caused the kernel's internal device tables to get
	   changed also updated your MAKEDEV script; otherwise, you will have
	   to grovel through the kernel to see what is going on.

-- 
TSgt Dave Burgess
NCOIC Applications Programming Branch
US Strategic Command, Offutt AFB, NE
burgessd@j64.stratcom.af.mil

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part4

Section 3.	(Kernel Building and Maintenance)

3.0	System Internals
	
	One of the interesting aspects of *BSD is the fact that it comes 
	with the complete source.  This allows you to make changes to the 
	system, recompile, and test out your new ideas.  This section of 
	the FAQ describes many of the different aspects of this endeavor 
	and common problems and pitfalls that are encountered.  Kevin Lahey 
	provided the substantial portion of this section.  You can contact 
	him via E-Mail at (kml@rokkaku.atl.ga.us) or contact Dave Burgess 
	(burgess@hrd769.brooks.af.mil).



3.1	Kernel

3.1.1	How do I build a kernel?

	The kernel can be compiled in a variety of ways to support different 
	devices and configurations.  Compilation is controlled by a config 
	file that specifies the characteristics of the kernel.  A set of 
	different config files is located in /sys/i386/conf or 
	/sys/arch/i386/conf.  The configuration file names are in upper case.

	To build a particular kernel (in this example, we use the GENERICISA
	configuration file in NetBSD or FreeBSD):

	% cd /sys/i386/conf
	% config GENERICISA
	% cd /sys/compile/GENERICISA
	% make depend
	% make

	You'll need patch 1 from the patchkit to get the compilation to work,
	'cause the version file isn't correctly included in the Makefile.


3.1.2	I want to do one of the following things:
	* add a device not in the distributed kernel (third com
	  port, additional disk or tape, line printer driver, etc).
	* use a patch from the net or the patchkit to fix a kernel bug.
	* add another swap device.
	* recompile the kernel to remove extraneous devices so that
	  it takes up less space.
	* configure more pseudo-terminals to allow for more xterms
	  or network logins.
	
	You're going to have to recompile the kernel after you modify the 
	config file.  See section 3.2 below for more information about the 
	config file in general.
	

3.1.3	I don't have the source distribution -- how can I rebuild the
	kernel?

	There are reference sites available, as well as the 'good 
	net-neighbor' policy, whereby you could make arrangements with a 
	net neighbor to use a large local machine as a Network File System, 
	or allow you to compile a new kernel on their machine and transfer it 
	to yours.  If you *still* can't fit it in, you'll have to ftp a 
	compiled kernel from agate in the unofficial/patchkit-old directory 
	or one of the archive sites.  You can also ask for help from 
	comp.os.386bsd.questions if you get stuck and cannot make any headway.


3.1.4	Now that I have a kernel, how do I install it?

	Your kernel is called /386bsd or /netbsd.  Copy the new kernel from 
	/sys/compile/GENERICISA/386bsd to /, assuming that it is in that 
	directory.  This is relatively straightforward; there are a couple 
	of things to remember, though.  First, if you really screw up the new 
	kernel, you want to have something to fall back on, so be sure to 
	save /386bsd to /386bsd.old before copying in a new kernel.  Second, 
	if you just copy the new kernel over the currently running kernel, 
	funny things can happen.  Be sure to move aside the currently running 
	kernel before copying over the new one.  

	There are folks that have reported that overwriting their current 
	kernel has never caused them any real problems.  On the other hand, 
	if the old kernel was working and the new one doesn't, and you have 
	made changes that require that old kernel, it should be available to 
	the system, and saving it to /386bsd.alt or /386bsd.old are reasonable 
	things to do.

	If you are really paranoid, you can mount a new fixit floppy and 
	replace its kernel with the one you just built, and then boot from 
	the fixit floppy to make sure everything will work.  This is a 
	pretty good idea if you are making radical changes or if you are 
	unsure about your changes.
  

3.1.5	After installing the patchkit and recompiling the kernel with the
	option "WD8013", I am no longer able to reboot the machine.  A cold
	boot (power on) runs fine, but after a reboot no boot drive is found
	by the BIOS.  Besides having a 16-bit WD/SMC Ethernet card installed
	the machines try to boot using either a Adaptec 1742 or 1542 SCSI
	board to boot from.

	This answer was provided by Hellmuth Michaelis (hm@hcshh.hcs.de) and 
	written by Rodney Grimes (rgrimes@acacia).

	Remove "option WD8013" from the config files and recompile and
	reinstall the kernel. 

	The reason that option WD8013 often causes this reboot problem is 
	this:
	
	There is a requirement that all memory within a 128k bank in the
	0xA0000 to 0xFFFFF region be either 16-bit or 8-bit.  On a cold 
	boot, the WD8013 boards are reset to 8-bit mode, the POST
	(Power On Self Test) passes without error.  386bsd comes up, the 
	if_we.c driver places the WD8013 in 16-bit mode.  Now on a soft boot
	when the BIOS runs some quick POST tests it finds a problem in the 
	0xA000 to 0xF000 region.  You probably get a "beep-beep" when this
	happens.  It means you have a memory size conflict.
	The machine has been mis-configured.
	
	  This is a little known fact about 16-bit vs 8-bit option cards.  It
	has caused more than one person to go crazy tracking down what they
	swear is a bug in the program.  It is not, it is a flaw in the design
	of the ISA bus.  The signal MEMCS16- must be returned the same for
	every 128k block of memory:
	
		B0000-CFFFF	Must all be either 8-bit or 16-bit.
		D0000-FFFFF	Must all be either 8-bit or 16-bit.
	
	  In your particular configuration (WD8013 @ cc000) I suspect that
	you have another board in the B0000-CFFFFF region that is 8-bit, i.e.
	your Adaptec has an 8-bit BIOS on it!
	
	  Try moving the board to the 0xD0000 region and see if it works there,
	you may still have a problem as many modern system BIOSes are now
	8-bit.
	If your system BIOS is 8-bit, try shadowing the system BIOS region
	at 0xF0000 to 0xFFFFF, this effectively turns it into a 16-bit BIOS.
	
	  Do not attempt to shadow the WD8013, it well cause you many
	  headaches.
	
	  As always, works for me, you mileage may vary..
	

3.1.6	I found a bug in the kernel.  How do I report it?

	Both NetBSD and FreeBSD include a facility called 'bugfiler'.  
	While the instructions are included in both system, there is 
	still some apparent confusion about when to use (and when to
	NOT use) bugfiler.

	Jordan K. Hubbard (jkh@whisker.lotus.ie)  provides us with this
	short article.

	To send bug reports, you want to use the sendbug(1) command.
	The entire package for sending and filing these bugs is known 
	as "the bugfiler", which is where the confusion stepped in, 
	but sendbug is definately the command you want to use.

	Second, it doesn't take a "net connection" to use sendbug, 
	since all it does is package up your "bug report form" and mail 
	it to us; no direct internet connectivity is required, just mail.

	So if you can send internet mail you can use sendbug, or you can 
	also send mail to the `FreeBSD-bugs@freefall.cdrom.com' address 
	(do NOT send it to FreeBSD.cdrom.com since it will BOUNCE, this 
	is not the place to send bugs to, just to ftp stuff from!).

	NetBSD has a similar facility, but has a different host for bug 
	reports.


3.1.7	Can someone please give a reasonably clear set of instructions 
	as to how to get a "current" version of NetBSD running?

	Marc Wandschneider <marcwan@microsoft.com> provided this description
	of what he did to upgrade to the current version of NetBSD:

	1. Delete the old source tree, saving what I wanted to (a bunch
	of files moved around, and just unpacking the new one over the old
	will cause some problems)

	2. Unpacked the new source tree.

	3. ran the following sequence of commands:


		cd /usr/src/share/mk; make install
		cd /usr/src/include; make && make install
   		setenv LDSTATIC -static
   		setenv NOPIC
		cd /usr/src/lib/libc; make && make install
		cd /usr/src/gnu/lib/libmalloc; make && make install
   		cd /usr/src/gnu/usr.bin/gas; make && make install
   		cd /usr/src/gnu/usr.bin/ld; make && make install
		# You'll probably get some barfage from the above because 
		# ld.so won't build yet.  Ignore it and install ld anyway.
   		cd /usr/src/gnu/usr.bin/gcc; make && make install
   		unsetenv NOPIC LDSTATIC
   		cd /usr/src/lib ; make && make install
   		cd /usr/src/gnu/lib ; make && make install
		cd /usr/src/gnu/usr.bin/ld; make && make install
   		cd /usr/src; make && make install


	NOTE: At some point, you might very well come across an unresolved
	external __DYNAMIC in crt0.o.  If this happens, edit the makefile
	for crt0.o (lib/csu/i386) and remove the -DDYNAMIC flag)
	make && make install.  Then put the flag back in the makefile
	(but don't rebuild it until the natural order of things dicates
	that it happen)

	And Theo Deraadt provides this guidance when you get an error like 
	"init_main.o: Undefined symbol _pdevinit referenced from text segment."

	You need to
		(1) install new config
		(2) make clean
		(3) re-config your kernel
	then this goes away


3.2	What exactly is this config file, anyway?  What are all of these 
	cryptic notations?

	I've annotated the distributed GENERICISA file;  my comments are 
	delineated by the '--' symbols.

	#
	# GENERICISA -- Generic ISA machine -- distribution floppy
	#
--  BSD can be compiled for different hardware platforms, so it is important to
--  define the hardware types.  386bsd can only be built for 386 or
--  compatible machines, so this is sort of superfluous, but maintains
--  compatibility with standard BSD config files.
	machine		"i386"
	cpu		"i386"
--  The ident describes the machine for which this kernel is to be built.
--  It is usually the system name -- "ROKKAKU", "REF", or whatever.
--  This can be used for conditional compilation, so that kernel changes
--  can be compiled in only for one machine.
	ident		GENERICISA
--  This should indicate the timezone of the system relative the
--  Greenwich.   8 is PST;  4 is EST.  Somebody else might want to discuss
--  this more fully.
	timezone	8 dst
--  maxusers isn't strictly checked;  it is just used to size several
--  system data parameters.
	maxusers	10
--  The options control the conditional compilation of features into the
--  kernel.  The options can be listed all on a line separated by commas.
--  They are #define'ed when the kernel is compiled, so that #ifdef's
--  will work.  An option can be given a value by appending an equals sign
--  and a value (enclosed in double quotes) to the option name.
	
--  Hopefully the names are at least somewhat self-explanatory.  To
--  discover what everything does, you'd have to go through the kernel
--  looking for all of the appropriate #ifdef's.
	
--  [Perhaps somebody else could list the *exact* meanings of these
--  options and some of the other possible options?]
	options		INET,ISOFS,NFS
	options		"COMPAT_43"
	options		"TCP_COMPAT_42"
	
--  The config line controls the location of the root, swap, and dump
--  devices.  Anything not specified is defaulted.  This is where you add
--  support for multiple swap devices.  Just list 'em, separated by 'and'.
--  The config line below identifies the root drive as wd0 and the
--  swap drives as wd0 and as0.  See the section on swap devices in FAQ_02
--  for additional information.
	config		"386bsd"	root on wd0 swap on wd0 and as0
--  A 'controller' is a device or bus controller.  'isa' is obviously for
--  the ISA bus.  'wd0' is for regular disk controllers,  'fd0' is for the
--  floppies, and 'as0' is for SCSI disk controllers.
	controller	isa0
--  The fields work as follows:
	
--  a.  What do you call this device?  
--  b.  What controller is this on?  As you can see, the disk controller
--  talks to the ISA bus, and the disks talk to the disk controller.
--  c.  Where are the registers for the controller mapped into memory?
--  This is #defined in /sys/i386/isa/isa.h.
--  d.  What IRQ is this device set up for?
--  e.  What routine should be called on an interrupt from the device?
	
--			 a          b           c             d           e
--			vvv        vvv       vvvvvvv          vv        vvvvvv
	controller	wd0	at isa? port "IO_WD1" bio irq 14 vector wdintr
--  You need a 'disk' entry for every disk on the controller.  In the
--  config file originally shipped with 386bsd, both hard disks were 
--  incorrectly identified as wd0.  Be sure to change the second occurrence 
--  to wd1, as I have done in below.
	disk		wd0	at wd0 drive 0
	disk		wd1	at wd0 drive 1
	
	controller	fd0	at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
	disk		fd0	at fd0 drive 0
	disk		fd1	at fd0 drive 1

--  The 'drq' specifies the channel used for bus-mastering DMA.
	controller	as0	at isa? port 0x330 bio irq 11 drq 5 vector asintr
	disk		as0	at as0 drive 0
	disk		as1	at as0 drive 1

--  Define other physical devices.  pc0 is the keyboard, npx0 drives the
--  math coprocessor, and com* controls the com ports.
	device		pc0	at isa? port "IO_KBD" tty irq 1 vector pcrint
	device		npx0	at isa? port "IO_NPX" irq 13 vector npxintr
	device		com1	at isa? port "IO_COM1" tty irq 4 vector comintr
	device		com2	at isa? port "IO_COM2" tty irq 3 vector comintr
	
--  Ethernet drivers of various sorts and the particular configuration
--  information they require.  For most installations, only one of these 
--  devices would normally be defined.
	device we0 at isa? port 0x280 net irq 2 iomem 0xd0000 iosiz 8192 vector weintr
	device ne0 at isa? port 0x300 net irq 2 vector neintr
	device ec0 at isa? port 0x250 net irq 2 iomem 0xd8000 iosiz 8192 vector ecintr
	device is0 at isa? port 0x280 net irq 10 drq 7 vector isintr

--  Tape driver
	device		wt0	at isa? port 0x300 bio irq 5 drq 1 vector wtintr
	
--  The TCP/IP loop-back device, ethernet interface, slip interface, log
--  device, and pseudo-terminals.
	pseudo-device	loop
	pseudo-device	ether
	pseudo-device	sl	2
	pseudo-device	log
	pseudo-device	pty	4
	
--  Devices required by VM. 
	pseudo-device	swappager
	pseudo-device	vnodepager
	pseudo-device	devpager

	Normally, there is an annotated configuration file called ALL which
	gives a list of all of the options for the configuration file.
	

3.2.1	Okay, fine.  Why shouldn't I just add every device I can find to
	the kernel, so I'll never have to recompile this again?

	Because it takes up space.  The kernel is wired into memory, so every 
	byte it uses comes out of the pool of memory for everything else.  It 
	can't page out sections that aren't in use.  If your kernel is larger 
	than 640K, then it can't be loaded.  You'll need to use Julian Elischer's
	bootblocks to put it in high memory, which seem to be fairly complex.
	Installing them (once they are compiled) is as easy as using disklabel.


3.2.2	What should I remove from the kernel?

	What do you need?  If you only have an SCSI controller, you don't 
	need the wd0 device;  if you have another kind of disk controller, 
	you don't need as0.  Unless you actually HAVE more than one Ethernet 
	controller, you should comment out all but one of them.  If you don't 
	have an ethernet controller, you don't need any of the controllers or 
	NFS compiled in.   Without a CD-ROM, ISOFS is kind of pointless.  Just 
	look at what you have and think about what you really need.


3.2.3	I can't get enough remote login sessions or xterm sessions.  What
	can I do?

	Increase the count of pseudo-terminals --

	pseudo-device	pty	12  # or whatever

	Every pseudo terminal should have a /dev/pty* entry.  If you have 12
	pseudo terminals, you should also have at least 12 pty devices in the
	/dev directory.  The MAKEDEV script in /dev will create as many pseudo-
	terminals as you tell it to.


3.2.4	How do I get ddb, the kernel debugger, compiled into the kernel
	and running?

	Add the following line to the configuration file:

	pseudo-device	ddb

	Build the kernel, then run dbsym on it:

	% dbsym ./386bsd

	Install it and go for it.  Ctl-Alt-Esc drops you into the debugger.

	Note: DDB as shipped originally is a memory hog, and it is very
	difficult to get a kernel small enough with enough fun things in it
	to debug in 640K


3.2.5	Can I have more than one config file?  Should I rename it to something
	else?  Any other hints?  

	You can create as many (or as few) config files as you desire.  The 
	system, once the patchkit is applied, will have between 10 and 15, 
	each of which implements certain functions or features.  In addition, 
	the normal place for the patchkit to make changes to the config files 
	is in the GENERICISA file.  Since this file should remain unchanged 
	and available, it is always a good idea to copy this file to a 
	meaningful name and modify that file.  In other words, change every 
	reference in 3.1.1 from GENERICISA to HAL (or whatever you call your 
	system).

	One final note.  Every /sys/compile directory takes up 800K or so;
	you might want to watch to see how big these all get.



3.2.6	What is the meaning of the trap codes I get in panic messages?
	Sometimes this message appears in the form "trap type nn".

	That message means that the system received an unexpected (and
	unwanted) trap that probably indicates some form of kernel bug.
	These traps, are usually received from the kernel, in which case
	the trap.h definitions should be used.

	The number (which appears in place of "nn" above) is *NOT* the 
	i386 or i386 trap type, it is a BSD-defined trap type number.

	The definitions of the various trap types can be found in
	/usr/include/machine/trap.h.

	two of the more common ones are:
          9	T_PROTFLT	protection fault
				(The kernel tried executing code
				which was not noted as "executable".
				This happens if the kernel jumps to
				a bogus location.)
         12	T_PAGEFLT	page fault
				(The kernel tried to access a bogus
				area of memory.  This can happen if
				an invalid pointer is dereferenced.)


	This is a list of i386 trap codes (just to confuse the issue).

Trap	0	Divide Error
		The DIV or IDIV instruction is executed with a zero denominator
		or the quotient is too large for the destination operand.
	
	
Trap	1	Debug Exceptions
		Used in conjunction with DR6 and DR7, The following flags
		need to be tested to determine what caused the trap:
		BS=1				Single-step trap
		B0=1 AND (GE0=1 or LE0=1)	Breakpoint, DR0, LEN0, R/W0
		B1=1 AND (GE1=1 or LE1=1)	Breakpoint, DR1, LEN1, R/W1
		B2=1 AND (GE2=1 or LE2=1)	Breakpoint, DR2, LEN2, R/W2
		B3=1 AND (GE3=1 or LE3=1)	Breakpoint, DR3, LEN3, R/W3
		BD=1				Debug registers not available,
						in use by ICE-386
		BT=1				Task Switch
			
	
Trap	2	NMI Interrupt
		On PC/AT systems, the NMI input to the CPU is usually
		connected to the main memory parity circuit.  By the time the
		error signal is generated, the data may have already been
		used in an instruction, so it isn't possible to reliably
		recover.
	
		And some not-so-common causes (from various sources):

		  PS50+ : I/O channel check, system watch-dog timer 
		  time-out interrupt, DMA timer time-out interrupt

		  parity errors on any 8-bit or 16-bit board pulling the 
		  IOCHCK* line low 

		  first generation of auto-switching EGA cards used NMI to trap port
		  access for CGA emulation (e.g., ATI's EGA Wonder)
	
		  Zeos Notebook low battery (perhaps other battery-based 
		  computers)


Trap	3	Breakpoint
		The result of executing an INT 3 instruction.  MS-DOS and
		Windows and some other non-386 systems use this for debugging.
		Code specific to the 386 and later processors should use
		the debugging features tied to Trap 1.
	
	
Trap	4	INT0 Detected Overflow
		Occurs if an INT0 instruction is executed and the overflow
		flag (OF) is currently set.
	
	
Trap	5	BOUND Range Exceeded
		Occurs if the BOUND instruction is executed and the array
		index points beyond the area of memory containing the array
		being tested.
	
	
Trap	6	Invalid Opcode
		The value read at CS:IP is not a valid opcode.
	
	
Trap	7	Coprocessor Not Available
		This occurs if the processor fetches an instruction that is
		for the coprocessor and no coprocessor is present.
	
	
Trap	8	Double Exception (Fault)
		An exception occurred while trying to execute the handler
		for a prior exception.  Example, an application causes a
		General Protection Fault (13) and the area of memory where
		the GPF handler should be is flagged not-present (paged-out?).
		The double-fault handler is invoked in these conditions.
		If a fault occurs while trying to run the double-fault handler,
		a triple-fault occurs and the CPU resets.
	
		The rules for deciding if a double-fault should occur or
		if the two faults can be handled serially are discussed in
		more detail in the Intel song book.
	
	
Trap	9	Coprocessor Segment Overrun
		A page or segment violation occurred while transferring
		the middle part of a coprocessor operand to the NPX.
	
	
Trap	10	Invalid Task State Segment
		During a task switch, the new TSS was invalid.  Here is
		a table of conditions that Invalidate the TSS:
		TSS id + EXT	The limit in the TSS descriptor is < 103
		LTD id + EXT	Invalid LDT selector or LDT not present
		SS id + EXT	Stack segment selector is outside table limit
		SS id + EXT	Stack segment is not a writable segment
		SS id + EXT	Stack segment DPL does not match new CPL
		SS id + EXT	Stack segment selector RPL <> CPL
		CS id + EXT 	Code segment is outside table limit
		CS id + EXT	Code segment selector does not refer to
					code segment
		CS id + EXT	DPL of non-conforming code segment <> new CPL
		CS id + EXT	CPL of conforming code segment > new CPL
		DS/ES/FS/GS id + EXT	DS, ES, FS or GS segment selector is
					outside table limits
		DS/ES/FS/FS id + EXT	DS, ES, FS, or GS is not readable
					segment


Trap	11	Segment Not Present
		Occurs when the "present" bit of a descriptor is zero.
		This can occur while loading any of these segment registers
		CS, DS, ES, FS, or GS.  Loading SS causes a Stack fault.
		Also occurs when attempting to use a gate descriptor that is
		marked "not present", and if attempting to load the LDT with
		an LLDT instruction.  Note that loading the LDT during a
		task switch causes an "invalid TSS" trap.


Trap	12	Stack Fault
		A limit violation relating to an address referenced off
		the SS register.  Includes POP, PUSH, ENTER and LEAVE
		opcodes, as well as references such as MOV AX,[BP+8]
		(which has an implied SS:).
		Also causes by loading SS with a descriptor that is marked
		"not present".


Trap	13	General Protection Fault (GPF)
		Americas Favorite, in the Windows 3.0 world, it is known as
		the UAE error.  The instruction tried to access data out of
		the bounds designated by the descriptors.  The access that
		failed can be a read, write or instruction fetch.  There are
		15 classifications of GPFs:
		1.  Exceeding segment limit when using CS, DE, ES, FS or GS.
		2.  Exceeding segment limit when referencing a descriptor
		    table.
		3.  Transferring control to a segment that is not executable.
		4.  Writing into a read-only data segment or into a code
		    segment.
		5.  Reading from an execute-only segment.
		6.  Loading the SS register with a read-only descriptor
		    (unless the selector comes from the TSS during a task
		    switch, in which case a TSS exception occurs.)
		7.  Loading SS, DS, ES, FS or GS with the descriptor of a
		    system segment.
		8.  Loading, DS, ES, FS or GS with the descriptor of an
		    executable segment that is not also readable.
		9.  Loading SS with the descriptor of an executable segment.
		10. Accessing memory via, DS, ES, FS or GS when the segment
		    register contains a null selector.
		11. Switching to a busy task.
		12. Violating privilege rules.
		13. Loading CR0 with a PG=1 and PE=0.
		14. Interrupt or exception via trap or interrupt gate from
		    V86 mode to privilege level other than zero.
		15. Exceeding the instruction limit of 15 bytes (this can
		    only occur if redundant prefixes are placed before an
		    instruction).
		To determine which condition caused the trap, you need
		the instruction, the contents of all associated registers,
		particularly the segment registers involved, then the various
		LDT, GDT and page control tables.  Lots of common coding
		errors cause the GPFs.  Even a stack imbalance will usually
		show up as a GPF.   Even MOV AX,7 MOV ES,AX or 
		MOV AX,5 PUSH AX POP DS will get a GPF error.  You can't
		use a segment register for "temporary storage" of any
		old value the way you could on the 8086.  The values loaded
		into the segment registers are checked in protected mode.


Trap	14	Page Fault
		The page directory or page table entry needed for the address
		translation has a zero in the present bit, or the current
		procedure does not have sufficient privilege to access the
		indicated page.

Trap	15	(reserved)


Trap	16	Coprocessor Error
		The coprocessor asserted the ERROR# input pin on the 386
		(internal on the 486)


Trap	17	Alignment Check (486 and later)
		If enabled, this trap will occur if a data fetch does not
		occur on a word boundary.  I don't know of any software that
		activates this feature yet.  I have seen SCO UNIX get this
		error on early Cyrix processors, even though SCO had not
		enabled the feature.


Trap	18-32	(reserved)

[answered by 	Frank Durda IV <uhclem@nemesis.lonestar.org>	and
		jim mullens jcm@ornl.gov  -or- mullens@jamsun.ic.ornl.gov]
	
-------------------------------------------------------------------------------

3.2.7	I have been getting a lot of "virtual memory exhausted" errors when 
	I am compiling a program with a really big static array.  I have 
	128Meg of memory and 8Gig of swap.  How can this be happening?

	If you are using Csh, you can simply unlimit your processes in 
	your csh.cshrc file.  You can also modify your kernel so that the
	amount of memory available is less limiting.  J"org Wunsch 
	(j@tcd-dresden.de) provides us with this brief description:

	From a recent posting i just made, regarding the problem how much
	virtual memory one could get.

	| On the other hand, i've also changed the definitions you
	| mentioned. But i didn't like to modify the header files, and
	| actually, modifying the values is as easy as:
	| 
	| options		"DFLDSIZ='(16 * 1024 * 1024)'"
	| options		"MAXDSIZ='(64 * 1024 * 1024)'"
	| 
	| Include the above lines into your kernel's config file, reconfig
	| and rebuild it.
	| 

	This is just a hint for those people poking around with compiling
	large source files. Especially, due to some gcc problems with large
	static arrays, compiling X applications with huge bitmaps would
	cause virtual memory trouble. Increasing the limits (o'course, as
	long as the h/w resources suffice) could help there.

	The default definitions for the above parameters are found in
	/usr/include/machine/vmparam.h.


3.2.8	Where can I learn more about all this?

	We've skipped over a lot of details here;  the straight dope comes from
	"Building Berkeley UNIX Kernels with Config", by Samuel J. Leffler and
	Michael J. Karels. 

3.3	X11/XFree86/XS3
3.3.1	What options should I define to get the X extensions included?

	Once you have applied the patch kit, the only thing left to do is to
	modify the config file to include the following line:

	options	XSERVER, UCONSOLE
 
	recompile the kernel and the kernel should support X.

3.3.2	Where can I get the FAQ for 'X'?

	Answers to frequently asked questions about XFree86 on 386BSD are
	available by anonymous ftp from agate.berkeley.edu (128.32.136.1) in
	/pub/386BSD/0.1-ports/XFree86-1.2/XFree86-1.2-386BSD-FAQ.  It
	supplements the more introductory material distributed with XFree86 
	1.2 in README.386BSD.  It also supplements Steve Kotsopoulos' more 
	general 'X on Intel-based Unix' FAQ available by anonymous ftp from
	export.lcs.mit.edu in /contrib/Intel-Unix-X-faq.


3.3.3	Why does X drop characters when using xdm?   When I run xdm 
	from the console, it keeps losing keystrokes and the shift keys 
	don't always work.  Why?

        You need to run xdm with the -nodaemon flag.  The reason is
        xdm normally detaches from the keyboard.  This allows other
        processes (like getty) to return to reading from the keyboard.
        A race condition results, where some keystrokes are sent to
        xdm and others are sent to other processes.  Using the
        -nodaemon flag causes xdm to stay attached to the keyboard
        so no other process can use it.  This answer comes from Michael 
        C. Newell (root@wanderer.nsi.nasa.gov)

	This bit of trivia is also covered in detail in the X FAQ and 
	the README that accompanies XFree86.


3.4	Compiler and Library routines

	There are several questions that could probably be included
	here.  See also Section 4 for some of the more common 'missing
	modules' that also happen to be library routines.


3.4.1	Which C compiler is shipped with my Net/2 derived BSD? 

	The standard compiler released with 386bsd 0.1 is GCC 1.38.  This
	version is considered by many people to be the most stable of
	the GCC versions.  All other Net/2 derived BSD systems have both 
	1.38 and 2.4+ available.  NetBSD 0.9, for example, is completely 
	compilable using GCC 2.5.5, which is included as the default
	compiler.  FreeBSD will also ship with the same compiler.

3.4.2	Where is libcompat.a?

	The library libcompat.a is (working from memory here) completely
	deprecated in 386bsd.  The only exceptions might be the re_comp
	and re_exec routines, which are discussed in detail in section 4.

	The easiest way around not having a libcompat.a is to simply link 
	it to a small library, since virtually every other function that
	is expected in libcompat.a is already include libc.a.


-- 
TSgt Dave Burgess
NCOIC Applications Programming Branch
US Strategic Command, Offutt AFB, NE
burgessd@j64.stratcom.af.mil

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part5

Section 4.	(Kernel Additions)

  Thanks go to  Marc Wandschneider (storm@cs.mcgill.ca) for putting this
  section of the FAQ together..

4.0	Introduction

	If you have written some addition to the kernel, or know of
	one that feel should be mentioned, send mail to Dave Burgess 
	(burgess@hrd769.brooks.af.mil) with all the relevant information, 
	and it will be added for the next release.



4.1	Common Kernel-related problems

4.1.1	Where are the commands "rpcinfo" and "rpcgen"?

	Chris Flatters (cflatter@nrao.edu) informs us in the following
	posting excerpt where we can find them:

	--------------------------------------------------------------------
	The sources for the Sun OS 4.0 RPC are on titan.rice.edu (I don't 
	have the inet number handy) in directory sun-sources.  You will have 
	to pick up all the shell archives and unpack them to get at rpcgen.
	--------------------------------------------------------------------

	These sources are also included in NetBSD and FreeBSD as part of the
	normal installation.
 
4.1.2	Where can I get a working "netstat"?

	netstat was released as a binary patch and source patch 
	in the patchkit.  Netstat will be a part of the FreeBSD 
	distribution currently under construction, and is already
	part of NetBSD.


4.1.3	How can I fix NFS to work with my NE2000 board?

	Ken Raeburn (raeburn@cambridge.cygnus.com) has both identified the
	problem and provided us with a work around:

	--------------------------------------------------------------------
	I reported previously that I was seeing problems reading files over
	NFS using the ne2000 driver; timeouts would eventually be reported, no
	data would be read.  Listing files and directories (small ones
	anyways) were not a problem.

	After playing with etherfind and kernel printfs, I've come to this
	conclusion: Fragmented 8K UDP packets from the NFS server are not
	reaching the UDP layer in 386bsd.  The Sun is sending them (according
	to another Sun spying on the network), but the UDP input routine is
	never called.  I don't know if the bug here is on the 386bsd or Sun
	side, and won't have time to look into it in the next couple of days.

	In the meantime, mounting NFS file systems with "rsize=1024" does get
	rid of this problem.

	(It does nothing about TCP being slow, though.)
	Ken
	--------------------------------------------------------------------

	Hopefully, the real solution (a UDP fix) will be forthcoming so
	that the slow TCP problem is fixed as well.

	See also:  Section 2.6.3.3c "I am getting lousy performance 
		   out of my network card.  What are some of the other 
		   possibilities?"

	Recent work in FreeBSD and NetBSD may have deprecated this problem.
	There is a new network card driver called the ed0 driver.  This
	replaces the original NE1000/NE2000 drivers, as well as replacing
	the we0 driver.  By combining the two, a more flexible driver has
	been developed and most of these types of problems have been fixed.
	Once again, upgrading to FreeBSD or NetBSD seems to be the answer.


4.1.4	How can I get "ps" and "w" to work?

	The patch-kit contains a fix for /src/lib/libutil/kvm.c, which,
	last we heard, was due to the work of Jim Paradis 
	(paradis@sousa.ltn.dec.com).  New versions of the kernel should
	have this problem fixed.

	In order for users to be able to use certain flags with ps and
	the w/uptime commands, the kernel must have permissions 755.

	Also, in order to save space on the distribution, the kernel is 
	'stripped' of all its labels.  Programs that rely on those labels
	will not work.  There are several in this category, including ps, 
	w, and uptime.  Either ftp an un-stripped kernel, or recompile.


4.1.5	Where are re_comp and re_exec?

	These two functions are currently not in libc.a.  However, there
	are two related functions that seem to work exactly the same in
	all cases we've heard of---These are regcomp() and regexec().

	Thus, a pretty ugly fix for the problem would be to always compile
	as follows:

	$(CC) -Dre_comp=regcomp -Dre_exec=regexec ....

	There is a slightly nicer fix available for this, listed in 4.2


4.1.6	Where are stty() and gtty()?

	These functions are missing from libc.a.  To fix, add the following
	#defines to your program:

	#define stty(f, m)	ioctl((f), TIOCSETP, (m))
	#define gtty(f, m)	ioctl((f), TIOCGETP, (m))

	A more elegant solution is to apply the patchkit.  These routines
	are included in there.

4.1.7	The system hangs with the HD light on after intense disk usage.

	Brett Lymn (blymn@mulga.awadi.com.AU)  Provides us with a
	description of the problem and the steps that he had to take
	to fix it:

        It seems that, on some disk subsystems, the controller and the
	hard disk get out of synchronization when they are being used 
	intensively.  The result of this is that the disk completes a 
	command but the controller still believes the disk not to have 
	completed the command, so the controller status register 
	indicates the disk is busy when it is not really.  The standard 
	wd drivers are too trusting of the hardware and expect it to do 
	the right thing all the time.  There are a few while loops in 
	the wd drivers that loop on a status change from the disk 
	controller, however; if the problem I have described takes place 
	then the wd driver will be stuck looping waiting for the disk to 
	not be busy - which never happens, so you lock the machine because 
	this is a kernel level wait.  To fix this problem I put a timeout 
	into the while loops so that after a specified time the wd driver 
	will give up waiting for the drive to become ready, reset the 
	controller and retry the command.  In my experience the retry 
	always succeeds.

	Ed.Note:  The retry doesn't ALWAYS work, but it IS better than 
	just waiting for the drive to wake back up (which it never does).

	Dan Yergeau (yergeau@gloworm.Stanford.EDU) provides us with more 
	insight into this problem.  The README accompanying the original 
	sources used as a base for the NetBSD driver indicates that

	> There's also another problem still bothering me: There's some 
	sort of timing/reentrancy error still lurking in here, that was 
	there in the original 0.1 wd driver as well.  The symptom is that, 
	on *some* controllers, doing the initial wdopen() (which will 
	then call the readdisklabel() function) for two or more disks at 
	the same time (so that wdopen() gets called again while it's 
	already being executed), the controller gets hung.  I'm still 
	looking for this, meanwhile I specify in my config file that I 
	have swap on all disks.  This causes the kernel to wdopen() the 
	drives nicely in order -- and once it's been done for each disk, 
	the problem will, of course, not occur.  Without the "swap on ... 
	and ... and ..." stuff, my wd1, wd2 and wd3 would be opened 
	simultaneously by "fsck -p" forks, which would nicely hang up 
	everything...  I note a "sleep(10)" in fsck, but it obviously 
	doesn't do that.

	So, changing the appropriate config line to

	config		"386bsd"	root on wd0 swap on wd0 and wd1
	                                                        ^^^^^^^
	may get around the problem.  I don't run NetBSD, but I do use a
	variation of the barsoom/NetBSD driver.  This works for me.  
	Please let the NetBSD people know if it works for you.

	(Note: the sleep(10) in fsck is misplaced.  It does not keep fsck 
	from opening multiple disks simultaneously.  A properly placed 
	sleep() should also work around the wdopen problem.)

#include <std.disclaimer>



4.1.8	How do you implement quotas on Net/2 derived BSD systems?

	From: tinguely@plains.NoDak.edu (Mark Tinguely)

 	maybe you did not complete the setup, here is a step-by-step 
 	instructions to get them to work:

	1)  make a kernel with "options quota" installed

	2)  edit /etc/fstab and include the kinds of quotas you want, 
	    below I used "userquota", you could also add "groupquota".

	/dev/wd0h		/usr		ufs	rw,userquota 1 2

	3)  for each filesystem that is in /etc/fstab that uses quota,
	    create the file "quota.user" (and "quota.group if appropriate).
	    Above I have user quotas in the /usr filesystem, so I would:

	    # touch /usr/quota.user

	4)  scan filesystem for files ownership (and/or group ownership).

	    # quotacheck -a

	5)  now you can add individual quota limits, if you want to add 
	    the same quotas to the many people, then make a template and 
	    replicate the template.  If they change for each user, then 
	    edit seperately.

	    # edquota tinguely

	 (an editor is kicked up and says something like:

	Quotas for user tinguely:
	  /usr: blocks in use: 11876, limits (soft = 0, hard = 0)
	        inodes in use: 891, limits (soft = 0, hard = 0)

	 a limit of 0 means "unlimited".  Change these to the appropriate 
	 number of blocks.  A soft limit generates a warning, and can be 
	 exceed for period of time (7 days?), after which time a soft limit 
	 is treated like a hard limit.  A hard limit denies new writes.

 	to replicate a template (for this example let us assume "tinguely" 
 	is the template):

	    # edquota -p tinguely user1 user2 user3 ... userN

	6)  turn quotas on (usually done in the /etc/rc file, but turn it 
	    on manually so you do not have to reboot right now:

	    # quotaon

	that should take care of setting up quotas.  You can look at the 
	status of use of files with repquota, the -a option lists all 
	filesystems with quotas.


4.2	Available kernel add-ons


4.2.1	The Patch-Kit

	Perhaps the most famous of all additions to the kernel, the Patch-Kit,
	currently coordinated by Rodney Grimes (rgrimes@agora.rain.com)
	contains numerous bug fixes, Julian's SCSI drivers, as well as fixes
	for other parts of the system.

	The patch-kit, as well as all relevant information, is available on
	agate.berkeley.edu (and mirrors) in unofficial/patch-kit, as well
	as bsd.co.montana.edu in /pub/patch-kit. (archie will likely list
	other sites as well)

	It is highly recommended that all users with space for the source code
	apply the patch-kits as many things that seem broken in 0.1 suddenly
	start working with the patch-kits.

4.2.2	Shared Libraries

	A basic and experimental implementation of shared libraries exists
	for 386bsd.  According to the author (Dr. Joerg Lohse, 
	lohse@tech7.informatik.uni-hamburg.de), features are as follows:

	-No kernel extension is necessary
	-Shared libraries use the approach used in SysV.

	Others are also working on different implementations of shared
	libraries.

	This code can be obtained from agate.berkeley.edu in 
	~/unofficial/from-ref/sys.extras.  The file is called ??????????.

	Bill and Lynne have adopted a shared-library implementation based
	on Dr. Lohse's original work.  It will be included in Version 0.2
	of 386bsd and should be included in NetBSD about the same time 
	(Yes, I am guessing here).

4.2.3	Sound Blaster Drivers

	A driver for the Sound Blaster card has been written by Steve
	Haehnichen (steveh@ucsd.edu) for BSD.  Steve Gerakines has
	provided us with the information necessary to get this driver 
	working under 386bsd.

	Most features of the SB family of cards are supported save some
	stereo portions of the SBPro cards.

	The driver is available on agate.berkeley.edu in 
	unofficial/drivers/misc/soundblaster-1.4


4.2.4	Bus Mouse Drivers

	Fred Cawthorne (fcawth@delphi.umd.edu) wrote a busmouse
	driver for 386bsd.  He recently wrote a short letter with this
	update:

	My busmouse driver is mentioned in the FAQ, but it is quite out of 
	date.  I use Gene Stark's driver available from Freebsd.cdrom.com 
	in /pub/XFree86/mice.  (It is well done and I did not have time to 
	finish mine to make it more stable)  It is small, though, so it 
	might be good for people who want to rewrite parts, etc...  
	Several people have written about getting this to work with new
	versions, etc... and I have pointed them to the other driver.  It 
	would seem that people found out about my busmouse driver through 
	the FAQ, so could you please add something like the following to 
	the FAQ??

	This is taken from the INDEX in the Freebsd.cdrom.com mice 
	directory:

	"We currently have four bus mouse drivers for 386bsd available by
	anonymous ftp on XFree-86.cdrom.com in pub/XFree86/mice:

	ms-busmouse.tar.z

		Sandi Donno's <sandi@uctcs.cs.uct.ac.za.> port of 
		Erik Forsberg's Microsoft bus mouse driver to 386bsd.

	logitech-busmouse-0.2.shar.z

		Fred Cawthorne's <fcawth@delphi.umd.edu> second version 
		of a logitech Bus Mouse driver.  

	busmouse.tar.z:

		Eugene Stark's port of Rick Macklem's driver to the 
		Microsoft bus mouse.  Rick's driver supports the 
		Logitech and ATI Inport Bus mice with 386bsd.  It's also 
		available by e-mail to stark@cs.sunysb.edu and by anon. 
		ftp on cs.sunysb.edu in pub/386BSD/busmouse.tar.Z.

	psm.tar.z:

		Johan Solhed <Johan.Solhed@lu.erisoft.se> ported the 
		Linux PS/2 mouse driver to 386BSD.  It includes a PS/2 
		to Microsoft protocol converter in the driver so XFree86 
		understands the mouse events.

	In addition we have busmouse.v3.z which is Erik Forsberg's original
	post of his device driver for BSDI/386 and Microsoft (and
	compatible) bus mice using the Microsoft InPort chip as well as a
	device driver for Logitech bus mice. "

	I prefer busmouse.tar.z, and that seems to be the one that 
	supports the most mice.  It also drops into FreeBSD very easily.
	(all you have to do is copy com.c into /sys/i386/isa and add the
 	device mse0 ... line to the system config file.)


4.2.5	PPP Support

	A package to add PPP support to 386bsd can be found on agate
	in unofficial/drivers/net.  It is included in NetBSD and FreeBSD.


4.2.6	re_comp and re_exec library functions

	As mentioned in section 4.1, re_comp and related functions, such
	as re_exec, are currently not in the library libc.a  Apart from
	using the rather crude fix listed above, there is another option.

	Kim Anderson (kim@dde.dk) has provided a patch that will add these
	to libc.a.  You can probably obtain this patch from the author, or
	you can ftp it from binkley.cs.mcgill.ca in pub/386bsd.

4.2.7	Intel i82586 Ethernet Controller driver

	Garrett A. Wollman has written a driver for the Intel i83586 
	Ethernet Controller.  The driver is available from agate
	in unofficial/from-ref/sys.extras.

	The authors e-mail address is listed as Garrett.Wollman@uvm.edu,
	attempts to send him mail there have failed.

4.2.8	PC Speaker driver for Nethack

	Andrew A. Chernov has ported the Nethack PC Speaker driver to
	386bsd.  It allows the speaker to be controlled by applications.

	Unfortunately, we are not aware of a site that distributes this,
	but this patch has been posted a couple of times to the various
	comp.os.386bsd groups, and the author can be contacted at
	ache@astral.msk.su

	This patch is included in the NetBSD source tree, although it is
	not included in the distribution kernels.

-- 
TSgt Dave Burgess
NCOIC Applications Programming Branch
US Strategic Command, Offutt AFB, NE
burgessd@j64.stratcom.af.mil

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part6

Section 5.	(Kernel Replacements)

5.0	Introduction

	This section is supposed to document the unusual or optional
	kernel add-ons that are available from various places.  As 
	they are included in the mainstream of the various Berkeley
	Net Release systems, they will slowly come out of here.

	If you know of any replacement parts for the kernel, please 
	send Dave Burgess (burgess@hrd769.brooks.af.mil) a message 
	detailing the package (possibly include a README), where it 
	can be found, and what version of the OS (ie. NetBSD, 
	386bsd 0.1 + pk 0.2) it was designed to run under.

	When the exact directory is not listed for a package, the
	places to look on agate.berkeley.edu are in unofficial/drivers
	and unofficial/from-ref/sys.extras.

	Many a goodie can be found in these directories.


5.1	Available Kernel Replacements


5.1.1	keycap/codrv

	These server as replacements for the generic pccons driver
	that comes (by default) with 386bsd 0.1.

	Holger Veit (author of these) writes:

	"The same type of driver, but keycap has the version number 0.1.1
	and codrv has the version number 0.1.2.  The latter is much 
	improved and downward compatible.  Codrv was developed to provide
	a universal way of mapping national keyboard layouts during
	runtime (ie, not by patching the kernel tables) and providing
	better X11 support.  Codrv uses a superset of the pc3 terminal 
	emulation, and a termcap-like database for keymaps (therefore
	"keycap").  X11 is supported by two dedicated console raw devices
	/dev/kbd and /dev/vga, which avoids all the existing problems
	pccons has with X11.  The latest version has virtual consoles.
	Codrv will become part of patchkit 0.2.4"

	This package is available on agate.berkeley.edu.

	

5.1.2	pcvt

	A superset of pccons, this driver supports virtual consoles, 
	and some form of database oriented keyboard mappings.  It was
	also designed to emulate a vt220 terminal as best as possible.

	Joerg Wunsch, the author of pcvt <joerg_wunsch@tcd-dresden.de>
	has sent us this update.

	I've arranged irz301.inf.tu-dresden.de [141.76.4.1] as the 
	`official' ftp server for the pcvt console driver, as long as 
	there are several different drivers.  The stuff is under 
	~ftp/pub/unix/386bsd/pcvt, along with some recent (still 
	unofficial) patches to be compatible with XFree86.  Everything 
	is scheduled with the author, Hellmuth Michaelis.

	I'm not the official maintainer of that ftp site, so I must ask 
	the folks there to help me.  This might delay recent changes; 
	before they're merged into the official server tree, they can 
	be found in ~ftp/pub/incoming/unix/386bsd.

	The Dresden University has only a thin wire to outside.  Any 
	mirroring site, especially in US, would be appreciated.  The 
	space requirements are less, only 2 or 3 Meg.  Maybe I'll upload 
	a `generic' kernel configured with pcvt there some day.

	all the best, J"org <joerg_wunsch@uriah.sax.de>

5.1.3	syscons

	Another superset of pccons that was designed to emulate SCO as
	well as possible.  Many of the ioctls from SysV have been 
	implemented.  XFree86 requires special patches to be run with
	kernels using this console driver. Available on agate.


5.1.4	Fast Symbolic Links

	The following is taken from the README for the fast sym-links
	patch:

	"This cruddy but complete hack answers one of the objections to
	 symlinks: that they are slow, and cost an entire frag.  Symlinks
	 of less than length 60 are stored in the inode itself.  Symlinks
	 longer than this are still in the inode.  To make the illusion
	 of normality complete, dump and fsck also need changing.  
	 Additionally, I made dumpfs verbose to excess."

	Available on agate.


5.1.5	npx fixes

	There are problems with the floating point error handling 
	routines, and there are fixes available for this problem provided
	by Bruce Evans (of Minix-386 fame)

	The code for these fixes is available on agate.berkeley.edu
	in unofficial/from-ref/sys.extras/bde-npx.

	Note that most of the code is applicable to floating point hardware
	as opposed to emulation.

	The newest version (and now official) fixes to this are in
	patchkit-0.2.4.


5.1.6	CGD's COM drivers

	Chris G. Demetriou (cgd@blah blah blah) has written some COM drivers
	for 386bsd.  These, among other things, support multi-port serial
	packages.

	The latest (and last) version is 0.2, and is available on agate
	in unofficial/from-ref/sys.extras/cgd-com-ports.  Please note that
	this is not going be developed any further by the author, and no 
	new versions will appear.  Users who do not absolutely need the
	features this provides are encouraged to use the newest drivers
	that come with the patch-kits.


5.1.7	Tom Ivar Helbekkmo's wd.c replacement

	Tom Ivar Helbekkmo (tih@barsoom.nhh.no) has rewritten much of the
	wd.c file that handles common hard disks, and added many new
	features to the code.

	The patches to use these can be obtained from barsoom.nhh.no
	in pub/386bsd.  Users should consult the README file for more
	information.

	Also, it should be noted that NetBSD uses these drivers as their
	stock drivers.


5.1.8	Interruptless LPT Driver Kit

	An Interruptless lpr driver kit is available from agate.berkeley.edu
	in unofficial/drivers/lpt.

	This driver was designed with faster performance and lower system
	load in mind.  See the INSTALL-NOTES that come with the package
	for more details and installation information.

	This is also included in NetBSD and FreeBSD.  Note that with some
	printers, it may be prefereable to ignore the status port and rely
	on the data port.  If you have tried everything else and the
	interruptless printer driver still does not work for you, you may
	need to play with this.


5.2	Floppy Disk problems.

	One of the most common problems in 386BSD involves working with 
	new boot sector and/or reformatting a floppy.  Dave Silvia 
	provided this section on using floppy disks.

5.2.1	How do I get a bootable floppy?

	Several ways, ranging from brain-dead-but-works to simplest.  
	Classification into categories is left to the reader (is there 
	really a difference between 'brain-dead' and 'simple'?:')

	1) rawrite (or dd) dist.fs (or fixit.fs) to a disk,
	   mount it, cd to the mount point, and execute:

		rm -rf .

	   you now have a bootable floppy!;^}

	2) Take your existing dist.fs or fixit.fs boot disk and
	   diskcopy it on a DOS machine.  Mount and rm as in 1)
	   above.  Again, you have a bootable floppy!;^}

	3) Run disklabel on the floppy, e.g.:

		disklabel -w -r fd0a floppy5

	   where 'floppy5' is a 'name' for an entry in the disktab
	   file in /etc.  You'll get a couple of ioctl errors because
	   writing a label to a floppy isn't supported (yet?), but
	   the boot blocks have indeed been written.

	4) Write the boot blocks to the floppy:

		cat /usr/mdec/fdboot /usr/mdec/bootfd | dd of=/dev/rfd0a

	   or, more simply:

		cat /usr/mdec/fdboot /usr/mdec/bootfd > /dev/rfd0a

	Methods 3) and 4) require you to run newfs on the floppy, e.g.:

	newfs /dev/rfd0a floppy5

	If you have a floppy that was originally bootable, but the boot
	blocks were somehow damaged, you can use method 3) or 4) to
	restore boot-ability (do _NOT_ run newfs).  You _could_, through
	the convolutions of copying a floppy whose boot blocks are damaged
	to a temporary location and then re-copying to a bootable floppy,
	use method 1) or 2) (if you really want to!;^})

	5)  If the disk is already newfs'ed and is otherwise ready to use,
	disklabel will write the boot blocks on the disk.  Read the man page
	for disklabel.

5.3	Unit Record

	These devices are also often referred to as character devices.
	
5.3.1	Printers

	Configuring a parallel printer for 386bsd requires a working 
	printer driver to be installed in the kernel.  386bsd 0.1 does 
	not include a printer driver in the stock distribution kernel.
	NetBSD and FreeBSD both include this driver in their stock 
	manifestations.

	It is possible to connect a serial printer to either.  This brief
	tutorial is provided by Daryl Berryhill 
	(djberry2@b25info.b25.ingr.com)

	The way I got my printer to work.

	1) connect a 25 pin to 9 pin null modem cable to printer and 
	   computer.
	2) set printer to 9600 baud, 7 data bits, even parity.
	3) configure /dev/com1 (DOS COM2) port the same way as the printer
	4) add a line to /etc/printcap that says:
	       lp|local line printer:\
	          :lp=/dev/com2:wq:sd=/var/spool/lpd:lf=/var/log/lpd-errs:\
	          :br#9600
	5) type "lpr <add filename here>"
	6) type "lpd"
	   and it should start printing.

	An obvious point, but make sure that you do NOT start a getty on 
	on the com port.  Check the /etc/ttys file and make sure that 
	the com port you select is not active.

5.3.2	Terminals/Keyboards

	Terminals are relatively simple to add.  It involves making sure the 
	/etc/ttys file identifies the com port (com0, com00, or tty00 
	depending on your configuration) as an active port and a getty is
	running.  The man page for ttys and getty help explain this.

	Many people report that there are sometimes problems running some
	programs on a remote terminal.  There are some known bugs in the
	terminal handler where the parity and bits per character.


5.3.3	Modems

	How to add a modem to 386BSD:

	The first part that confused me was assuming that /dev/com1 is 
	the same as DOS com1, they're not.  /dev/com0 is connected to 
	COM1 and (I think) /dev/com1 is connected to COM2.

	The switch settings for my modem were the same as what I had 
	under DOS, CTS CD RTS et al were set to follow the actual line 
	(i.e. my modem can force them high, which I turn off)

	Ok that's not too bad.

	Now you need to edit the /etc/remote file to include a reference 
	to the com port. I have only used NetBSD-0.8, so I'm not sure 
	what the default files are like that come with the other rev's 
	of 386BSD.

	I added the last line (with com0).
	--------------------------------------------------------
	#	@(#)remote	5.2 (Berkeley) 6/30/90
	#

	...stuff deleted...

	# UNIX system definitions
	unix1200|1200 Baud dial-out to another UNIX system:\
		:el=^U^C^R^O^D^S^Q:ie=%$:oe=^D:tc=dial1200:
	unix300|300 Baud dial-out to another UNIX system:\
		:el=^U^C^R^O^D^S^Q:ie=%$:oe=^D:tc=dial300:

	...stuff deleted...

	dial2400|2400 Baud Hayes attributes:\
	        :dv=/dev/tty19:br#2400:cu=/dev/tty19:at=hayes:du:
	dial1200|1200 Baud Hayes attributes:\
	        :dv=/dev/tty19:br#1200:cu=/dev/tty19:at=hayes:du:
	
	# Hardwired line
	com1c|com1:dv=/dev/com1:br#9600:
	com1b:dv=/dev/com1:br#2400:

	com0:com0:dv=/dev/com0:br#9600:at=hayes:
	------------------------------------------------

	Ok, now if you are running as root you can use type 'tip com0' 
	and you should then be talking to your modem.  I use kermit to 
	transfer files, and it wants to create a lock file in (not sure 
	about the exact path) /var/spool/uucp/lock or something along 
	those lines.  I made the directory world writeable so I could 
	run kermit with my own uid, rather than root.

	Also, you may need to add an entry in /etc/remote for com0.

	Thanks also to thombsr@liciren.li.co.uk for information on how 
	to do this.

5.4	Tape Drives

	This section should help out for those of you that have either
	never used tape drives before, or only have experience with them
	as non-Unix devices.

5.4.1	Does the tape need to be formatted?

	It depends,   but I think usually not.  And when it is necessary,
	I don't know how it would be done.  One thing is for certain, 
	though, first....  NEVER use the block devices..  erase them and 
	forget you ever saw them.  All operations on tape should be to 
	the character device (rst0).


5.4.2	If I execute the command 'st -f /dev/st0 status', I get:
		Archive/Tandberg? tape drive, residual=0, blocksize=512
		Density: high = 16 (0x10), medium = 15 (0xf), low = 5 (0x5)
		ds=0
		er=0

	so to write to tape at high-density (QIC-150), presumably I want 
	to use a device with minor number +4 (in st.c, density is computed as
	minor >> 2 & 0x03, where low density == 3 and high == 1):

	You have the idea.. density is controlled by bits 2 and 3

		00 = default
		01 = hi density
		10 = medium density
		11 = low density, 

	Unless the driver knows about you kind of drive the density values
	may need to be set by hand before they make any sense.


5.4.3	When is erst0 used?

	e stands for 'eject' and is bit 1 of the minor.. 
	e.g. eject on close.. many devices can't actually do this.

	There is actually a method to this whole thing:

		r = raw		(rst0)
		e = eject	(erst0)
		n = No rewind	(nrst0 or maybe nerst0)

5.4.4	How is density (bpi) computed?  I am using 3M DC 6250 cassettes 
	which have a 250MB capacity on the Viper 150.  But computing the 
	bits/inch based on 250MB/tape-length (1020 ft.), I get a density 
	of 171335 bpi, which is nowhere near the 10000 bpi associated 
	with QIC-150 in the st(1) man page.  Why the discrepancy?

	These cartridge tapes are right onto the tape in narrow tracks, 
	which begin at opposite ends of the tape.  Track 0 starts at the
	beginning of the tape, and Track 1 starts at the other end, etc.

	So, how many times does the tape go backwards and forwards?  If 
	there are 17 tracks, your density is 170000 bpi if it is 10000
	bpi per track.

5.4.5	How is an appropriate block size determined (and in what units 
	are they specified in the st(1) command)?

	QIC 150 and below should stick to 512 byte blocks a write of 
	1024 bytes from the program will be written as 2 512 byte blocks 
	with no speed penalty.  dd will think it's writing a 1024 byte 
	block but on tape it's 2 x 512.

	Stick to 512 on QIC 150 or less if you ever hope to swap data 
	with anyone else.


5.4.6	From the 4.3BSD mtio(4) man page, it sounds like data is typically
	(traditionally?) stored on tape in eof-terminated sequences of 
	1K records.  

5.4.6.1	Is st's notion of "file" the record sequence between two eof marks?  

5.4.6.2	What about a "record"?  

5.4.6.3	Is a "record" one "block", as determined by st's "blocksize" command?   
	If not, what is the connection between them?  

5.4.6.4	Can I change the "record" size?  
5.4.6.5	When would I want a block size that is different from the default?  
	1KB is the size of writes used by dd or whatever.  QIC specifies 
	512 byte records (well at least its what people use..)  Whatever 
	you write in will be broken into 512 byte sections.  They must be 
	multiples of 512 though.

	If you have written to a tape, a close will automatically append a 
	filemark (eof mark).  You may read the 512 byte blocks back as 
	512 byte records or as 1024 byte records (in which case you'll 
	get 2 at once).  The bigger the unit, the more efficient.

5.4.7a	How do I write several archives to a single tape?  I tried without 
	success:
		$ st -f /dev/rst4 rewind
		$ tar cf /dev/nst4 archive1
		$ st -f /dev/nrst4 weof
		$ tar cf /dev/nst4 archive2
		$ st -f /dev/nrst4 weof

	First:  throw away the block devices.

	'n' stands for 'No-Rewind-on-close' and will leave the tape 
	positioned ready for another file e.g.

		tar -cf /dev/nrst0 archive1
		tar -cf /dev/nrst0 archive2


5.4.8b	Later, I would expect to be able to access, say, archive3 via the fsf
	directive to skip over the first two archives.  What is the correct
	sequence?

		st -f /dev/nrst0 rewind
		st -f /dev/nrst0 fsf 2
		tar -xf /dev/rst0 {files}


5.4.9	Since the Viper 150 writes on QIC-150/120, I guess I don't need 
	to worry about writing variable-length records?  How about reading 
	a tape written with variable-length records.  Is this possible 
	with the Viper?  If so, what's involved?


	Who would have written it? :-)

	Presently you can't.  You`re right.  Don't worry about it.

	The new 'st' changes will change this somewhat, though.


5.4.10	The very scant documentation that came with my drive mentions
	a "selectable buffer disconnect size," whose default is 16K.
	This is evidently the "maximum number of bytes that can be 
	sent over the SCSI bus during a single data transfer phase."  
	What's that?  How is it connected st's "blocksize" command?  
	Do I want to use 16K blocks, or might I even want to set the 
	disconnect size to a higher value?

	This suggests that 32 512 blocks will be written at a time.
	This jives with the tape format for some of the lower density 
	cartridges (QIC-40 and 80, for example).  The tape is written 
	in blocks of 32 512-byte blocks, with the last three being used
	for Error Correction Codes.  

	Use dd or tar with 16 k blocks and 32 x 512 byte blocks will be 
	written.

5.4.11	What is "streaming"?  When I tar a directory of files to tape,
	I notice that the tape often stops.  Streaming means it doesn't 
	stop?  How would I get the viper 150 to stream using tar or cpio 
	or dump?

	Use a bigger write size... (more efficient)  Try 16k blocks.


5.4.12	Where are all the answers to the above and related questions 
	written down?  Neither on the net nor in the 4.3BSD manuals 
	nor Administration text which I have could I find this stuff 
	covered!

	They are in the FAQ :-)...


5.4.13	What else should I know?  For example, it seems that a new tape 
	must stretched.  How is this done?

	Use a blowtorce and a pair of pliers;  or you can use the 
	non-destructive method and run the tape through a complete fast 
	forward/rewind cycle to get it tight on the spindles.


5.5	Network
5.6	Marc Mengel's <mengel@fnal.gov> driver list

	Well, since replies to my request for information on
	drivers dried up a few weeks ago; here is the list.
	I got more replies from folks wanting drivers than
	from folks who'd done them.

	Hopefully this posting will inspire folks whose drivers
	aren't on the list to send me information on their stuff,
	and I'll add it in.

	If there is continued interest I'd be willing to turn this
	over to the FAQ folks, or maintain it as a separate FAQ 
	posting for comp.os.386bsd.announce or some such.

	Here is the form to submit new entries to the list:

      Driver Name:
    Author's Name:
   Author's Email:
Devices Supported:
 Number Supported:
 Interrupt driven:
 External Symbols:
        Size info:
     Availability:
            Sites:
        Stability:
     Restrictions:
         Comments:

	Here is the list received to date:
-----
       Driver Name: fdc
     Author's Name: Jesus Monroy Jr.
    Author's Email: jmonroy@netcom.com, et al. (to follow)
 Devices Supported: NEC765, Intel8272
  Number Supported: 8 projected (1 works now)
  Interrupt driven: Y
  External Symbols: (fdopen, fdclose, TBA)
	 Size info: (N/A (projected to add 1k to kernel))
      Availability: (TBA)
	     Sites: (TBA)
	 Stability: (in BETAS)
      Restrictions: (UCB Copyright)
     Delivery Date: June '93
 
-----
       Driver Name: rtc (CMOS clock)
     Author's Name: Jesus Monroy Jr.
    Author's Email: jmonroy@netcom.com, et al. (to follow)
 Devices Supported: Motorola CMOS 16458? (must double check)
  Number Supported: 1
  Interrupt driven: (Y)
  External Symbols: (TBA)
	 Size info: (N/A)
      Availability: (TBA)
	     Sites: (TBA)
	 Stability: (starts 5-17-93)
      Restrictions: (UCB Copyright)
     Delivery Date: July '93
 
-----
       Driver Name: QIC-40/80
     Author's Name: Steve Gerakines
    Author's Email: 
 Devices Supported: QIC-117 (standard) through FDC
  Number Supported: 1
  Interrupt driven: 
  External Symbols: 
	 Size info: 
      Availability: Beta Testing.
	     Sites: hrd769.brooks.af.mil
	 Stability: 
      Restrictions: 
     Delivery Date: 1 Sep 93 for latest version.

-----
       Driver Name: co ("codrv") console driver
     Author's Name: Holger Veit
    Author's Email: Holger.Veit@gmd.de
 Devices Supported: Keyboard, CGA/MDA/EGA/VGA/SVGA
  Number Supported: 1
  Interrupt driven: Keyboard INT 1
  External Symbols: coopen,coclose,coread,coselect,coioctl,comap,
			pcopen,pcclose,pcread,pcwrite,pcioctl,pcmmap,
			crtat, sput, getchar,putchar, and many more
			
	 Size info: large, several modules
      Availability: ftp
	     Sites: latest version is codrv-0.1.2-030593.tar.z (gzip)
		    ftp.uni-duisburg.de:/pub/unix/386bsd-0.1/unofficial/codrv
		    bsd386.first.gmd.de:~veit/codrv
		    (login with 'guest', passwd 'guest')
		    bsd.coe.montana.edu:/pub/codrv
		    agate.berkeley.edu:/pub/incoming/codrv-0.1.2-030593.tar.z
	 Stability: quite stable
      Restrictions: BSD Copyright
-----
     Package Name: patchkit
    Editor's Name: Rodney Grimes
   Editor's Email: rgrimes@agora.rain.com 
     Availability: ftp
	    Sites: agate.berkeley.edu, bsd.coe.montana.edu, etc.(ask archie)
	Stability: Excellent
     Restrictions: 
	 Comments: 
-----
       Driver Name: shlib
     Author's Name: Joerg Lohse  
    Author's Email: lohse@tech7.informatik.uni-hamburg.de 
 Devices Supported: -
  Number Supported: -
  Interrupt driven: -
  External Symbols: -
	 Size info: 
      Availability: 
	     Sites: agate.berkeley.edu:unofficial/fromref/sys.extras
	 Stability: ?
      Restrictions: ?
-----
      Driver Name: "mse"
    Author's Name: Rick Macklem (patches by Eugene W. Stark)
   Author's Email: rick@snowhite.cis.uoguelph.ca, stark@cs.sunysb.edu
Devices Supported: Bus mouse
 Number Supported: "n", where n >= 0 (but I have only 1)
 Interrupt driven: Y
 External Symbols: mseopen, mseclose, mseread, mseselect
	Size info: text	data	bss	dec	hex
		   1484	72	0	1556	614
     Availability: E-mail to stark@cs.sunysb.edu, FTP to cs.sunysb.edu
	    Sites: cs.sunysb.edu, in pub/386BSD
	Stability: Sometimes generates phantom events when system is under load.
     Restrictions: "Do anything, but preserve this notice" copyright.
-----
      Driver Name: "tw"
    Author's Name: Eugene W. Stark
   Author's Email: stark@cs.sunysb.edu
Devices Supported: TW-523 X-10 carrier current modem for home control
 Number Supported: "n", where n >= 0 (but I have only 1)
 Interrupt driven: Y
 External Symbols: twopen, twclose, twread, twwrite, twselect
	Size info: text	data	bss	dec	hex
		   2944	560	0	3504	db0
     Availability: E-mail to author for most recent version + s/w,
			FTP not updated too frequently
	    Sites: cs.sunysb.edu, in pub/386BSD
			(older version on agate.berkeley.edu in "from-ref")
	Stability: Solid
     Restrictions: BSD-style copyright.
-----
       Driver Name: js, Joystick
     Author's Name: Juha Nurmela
    Author's Email: junki@lut.fi
 Devices Supported: Standard PC joysticks, LDResistors,...
  Number Supported: 2, more with "tweaked" cards
  Interrupt driven: No, polled with configurable timeouts, dflt 1/5 sec.
  External Symbols: jsopen, jsclose, ...
	 Size info: ??? (very small)
      Availability: mail
	     Sites: None
	 Stability: Solid (no guarantees though)
      Restrictions: None whatsoever
	     Blah: select()able, nonblocking/blocking io.
-----
      Driver Name: pcvt - VT220 virtual console driver
    Author's Name: Hellmuth Michaelis (and many others!)
   Author's Email: hm@hcshh.hcs.de
Devices Supported: MDA / CGA / EGA / VGA
 Number Supported: 1
 Interrupt driven: Keyboard=YES/Video=NO
 External Symbols: 
	Size info: ca. 64k (4 .o modules)
     Availability: alt.sources, ftp from agate and others
	    Sites: i.e. agate.berkeley.edu
	Stability: stable
     Restrictions: BSD Copyright

-- 
TSgt Dave Burgess
NCOIC Applications Programming Branch
US Strategic Command, Offutt AFB, NE
burgessd@j64.stratcom.af.mil

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part7

Section 6.	(Interaction with MS-DOS)

6.0	Working with DOS and BNR/2 related software.

	This section is designed to cover some of the more common 
	problems that DOS will have when interacting with BNR/2.
	There are other sections of the FAQ that deal with 
	indirectly with this .  Try looking in sections 0, 1, and 2
	to see if something in there (particularly when talking 
	about DOS and *BSD coexisting on a single drive).

	
6.1	Formatting a floppy

	There is a rumor that floppy formatting either is possible or was
	possible at one time.  If you see any software or FTP sites with 
	anything about this, please contact burgess@hrd769.brooks.af.mil
	and I will make sure it gets updated in here.

	There was a set of patches that were developed to allow floppy
	formatting.  They are not currently included in any of the *BSD
	systems.

	I have actually applied the patches for floppy formatting here on 
	NetBSD, and they seem to work just fine.  The fdformat program 
	could use some work, but seems to work OK.  According to the author,
	similar patches are available for NetBSD and the original 386BSD.
	Presumably, FreeBSD patches can't be too far behind.
	

6.2	Sharing the Disk with MS-DOS

	There are a myriad of questions about how to share a disk between
	386bsd and MS-DOS.  They all boils down to one of the <n> following
	questions:

	1)  How can I partition my drive for both MS-DOS and 386bsd?
	2)  I can install using the whole disk, but I can't install when 
	I try to share the drive between 386bsd and MS-DOS.  Why?
	3)  I can use either MS-DOS or 386BSD on my hard drive,
	but shutdown -todos doesn't seem to work.


6.2.1	How can I partition my drive to support both MS-DOS and 386bsd?

	NOTE:  Before attempting to install 386bsd on a computer with an
	active DOS partition, ALWAYS back up your hard drive.  No one on 
	the net, no matter how talented, can help you recover a hosed 
	MS-DOS file system.  If you lose all of your data, it is YOUR
	fault.

	During the install phase, you need to have un-allocated space left
	on your disk drive.  This allows the install program to correctly
	install the 386bsd partition in the partition table and DOS to
	peacefully co-exist with 386bsd.

	If you do not have any space available on your hard drive, you will
	not be able to install both.  Re-fdisk your hard drive and make
	sure you have left un-allocated space in the partition table.  
	This WILL wipe out your DOS partition - Permanently.

	Even though the partition table procedure above may have worked, 
	there are still no guarantees that your system will boot after
	the install.  This problem most often manifests itself as one of
	the endless reboot problems.  You would normally be able to boot
	DOS from the hard disk, but not 386bsd (once that partition is
	marked as active).

	Once the partition table has been correctly defined with both
	DOS and 386bsd, there can still be problem.  One of the most
	common is that the disk drive works in some sort of translation
	mode.  This is particularly common with drives that physically have
	more than 1024 cylinders.  DOS cannot access a drive with more than
	1024 cylinders.  Translation mode will have to be turned off, usually
	by redefining your hard drive in SETUP as one of the user definable
	types.  This change will normally trash your hard drive, or at least
	render your DOS partition unreadable.

	The solution to this problem is to install 386bsd at the end of the
	hard drive.  While DOS cannot use cylinders above 1024, 386bsd has
	no such limitations, once it has booted.  During the boot-up phase,
	some of the newer boot blocks will refer to the BIOS for some
	services.  Specifically, the disk is checked for a bad sector map
	on the last track.  Since the BIOS cannot deal with cylinders
	higher than 1024, your bad sector map will be incorrectly
	identified as 1023 if the number of cylinders is larger than that.
	This problem is being worked on, and I hope to change this section
	with better news later.

	NOTE:  The only people that this problem will effect are those 
	MFM and ESDI users that have drives with more than 1023 tracks.  
	While drives of this type are not the overwhelming majority, 
	neither are they an anomoly.  People are working on it.

	As an example, if your hard disk physically has 8 heads, 16 sectors 
	per track, and 2000 cylinders (128M); you MUST use some sort of disk
	translation in order to use the entire drive.  An obvious geometry
	for this drive (for DOS) would be 16 heads, 16 sectors, and 1000
	cylinders.  Unfortunately, 386bsd operates using the disk drives
	native geometry as reported during the probe phase of boot up.  This
	will probably be 8/16/2000, and will NOT agree with your translated
	disk geometry.  This causes an endless reboot cycle.  If you change
	the geometry so that the drive agrees with the disklabel, your DOS
	partition is toast.

	The best way to operate in this case would be to (for example)
	split the disk in half.  That leaves 64M for DOS, using a 
	geometry of 8 heads, 16 sectors per track, and the first 1000 
	cylinders for DOS.  The second 1000 cylinders could then safely
	be used for 386bsd.  The DOS partition table may even be capable of
	showing this partition as it actually exists.

	Luke Mewburn <zak@rmit.edu.au> has provided the following tutorial on 
	using the pfdisk program and making your 386bsd/NetBSD partitions
	peacefully coexist with DOS:


			Getting NetBSD 0.8 to coexist with DOS.

		    Written 930510 by Luke Mewburn <zak@rmit.edu.au>


	NetBSD can be made to happily co-exist with DOS if its install
	program knows how to modify the partition table. This assumes
	that you have access to a program which enables you to edit the
	partition table of your hard drive (such as Norton Utilities, or
	pfdisk).

	When you partition your hard drive, you will probably have a large
	partition in which you wish to place NetBSD. This has to have the
	partition ID of 165d (or 0xA5). To change this, you can use the
	'Partition Edit' section of Norton's, or you can use pfdisk.
	This document will go into more detail on how to use pfdisk, as it's
	freely available.

	I'll use my personal drive specifications in the following example.
	It is a 1001 cylinder, 15 trk/cyl, 17 sec/trk, 125MB drive. I
	low-level formatted it, and used fdisk on a MS-DOS 5.0 boot disk to
	create a primary partition '1' of 32MB, and an extended partition '2'
	of 93MB.  I formatted the drive with format c: /s to give myself a
	bootstrap for DOS (much faster than floppies :), but this isn't that
	necessary. Now, the next stage...

	Running pfdisk 0 (to access my first (and only :) HD) came up with
	something like:
	
	For help, enter: '?'
	pfdisk>

	At the prompt, enter 'l' to list partitions, giving (in my case),
	something like:

	# Partition table on device: 0
	geometry 1000 15 17 (cyls heads sectors)
	#  ID  First(cyl)  Last(cyl)  Name  # start, length (sectors)
	1   4      0        256       DOS16 # 17, 65518
	2   0    257        999       unkno # 65535, 189465
	3   0      0          0       empty # 0, 0
	4   0      0          0       empty # 0, 0
	active: 0 (none)

	(Note that there is 1 cylinder less - the last one is, I think,
	for the IDE controller to use when auto-mapping dud sectors out.)

	Now, we want to change the type of #2 (the prospective NetBSD
	partition) to 165. You can obtain a list of known IDs by selecting
	'I'. Depending on the version of pfdisk you have, 165 may or may not
	be known. This doesn't matter too much either way. To get the NetBSD
	install program to use the 2nd partition, I would enter:

	pfdisk> 2 165 257 999

	Another 'l' to list partitions would show that the entry for
	partition 2 will either look like one of the following (depending
	on whether pfdisk knows about the 386bsd partition type or not):

	2 165    257        999       unkno # 65535, 189465
	or
	2 165    257        999       386BS # 65535, 189465


	You could set the active partition with 'a 2' if you want NetBSD
	to always boot, but I personally recommend that you obtain a copy
	of OS-BS 1.35 or BOOTEASY to save you the hassle of running fdisk
	or pfdisk every time you wish to swap system types.

	To complete everything off, do 'w' to write out the info (once
	you're sure it's correct! :), and 'q' to quit the program.


	Well, I hope that is useful to someone. Comments can be directed
	to the author (Email: <zak@rmit.edu.au>).


6.2.2	I can install using the whole disk, but I can't install when 
	I try to share the drive between 386bsd and MS-DOS.  Why?

	This is an extension of the question above.  The most common reason
	for this is, once again, disk translation problems.  If the 
	disklabel does not agree with the disk geometry, the install will
	fail.  Other incarnations of this problem are that you can install
	DOS, then 386bsd, and DOS will be hosed, or vice versa.

	There are more than a couple of people who will blithely suggest that
	this is a good thing, and you should install 386bsd exclusively,
	job not withstanding.

6.2.3	I can use either MS-DOS or 386BSD on my hard drive,
	but shutdown -todos doesn't seem to work.

	There is a known bug in shutdown that prevents the -todos option 
	from working as advertised on all but the smallest DOS partitions.
	Many people have reported some success while using a very small
	(less than 32M) DOS partition as the first partition.

	There is a utility available for 386bsd which operates very much
	like the MS-DOS fdisk partitioning program.  You can use this program
	to mark the DOS partition active from 386bsd.  A similar procedure
	is used (fdisk in DOS) to mark the 386bsd partition as the active
	boot partition.  Boot managers are also an excellent investment for
	those individuals that need to boot both DOS and 386BSD.


6.2.4	Is there any hope of ever running MS-DOS applications under any of
	the free BSD systems?

	There is currently a project in development to port the Windows 
	program exvironment to Linux and the *BSD systems.  Here is an
	excerpt from the original message announcing the project:

	As many of you already know, we are in the process of creating a
	Windows emulator.  This emulator is similar to Sun's Wabi product, 
	but is being developed completely independent of them.  Many of 
	you are anxious to hear the latest status of the project.  I have 
	created a mailing list for those of you.  To join the list, simply 
	send mail to:

	wine-project-info@amscons.com

	If your mailing address is not easy to deduce from the mail 
	headers, then place the following line in the body of the message 
	that you send.

	Reply-To: youraddress@yourmachine

	where youraddress@yourmachine should be replaced by your actual 
	mailing address.


6.3	Accessing the MS-DOS filesystem 

	One of the most common MS-DOS related questions (with the possible
	exception of 6.2 above) is how to access the DOS disk partitions
	from 386bsd.  One way is to modify mtools so that it recognizes your
	DOS partition.  This solution is provided by Jim Paradis 
	(paradis@sousa.ltn.dec.com):

	--------------------------------------------------------------------
	To build a /usr/othersrc/public/mtools.2.0.5/devices.c file that 
	lets you access the DOS partition, you need to know the byte offset 
	of the DOS partition from the start of the hard disk.  You would then 
	add an entry to the devices[] array as follows:

	{'C', "/dev/wd0d", <byte-offset>L, 16, 0, (int (*) ()) 0, 0, 0, 0},

	So, f'rinstance, if your DOS partition starts at the beginning of
	the disk, you'd have:

	{'C', "/dev/wd0d", 0L, 16, 0, (int (*) ()) 0, 0, 0, 0},

	On the other hand, if your DOS partition starts 32MB into the disk,
	you'd say something like:

	{'C', "/dev/wd0d", (32768L * 1024L), 16, 0, (int (*) ()) 0, 0, 0, 0},

	--------------------------------------------------------------------
	Of course, this is both the hard and VERY non-portable way of
	solving this problem.  An easier way would be to add PCFS to your 
	386bsd/NetBSD system.  Both the PC File system and PC Network File 
	System (PC-NFS) code has been ported to 386bsd/NetBSD.  These are 
	available from several sources, including the patchkit. 

	The instructions for using PCFS with 386BSD are provided by Scott 
	Miles <gt1679c@prism.gatech.EDU>. 

	    What would probably be easier would be to add a partition to 
	    the disklabel for your DOS drive and then just mount it with 
	    PCFS.  I don't know if it's in the FAQ now, I haven't read it 
	    for a while, but this is what I did:

		1) run 'fdisk' and write down the DOS partition info for 
		the start and size that it gives you.

		2) disklabel -e -r /dev/<raw device>
   		   - Add 1 to the '# partitions:', and then add another line 
   		   for the DOS partition .  Mine went in after e: as 

	   f:   130977     63   unused      0     0     # (Cyl.    0*- 129*)

	(Ed.Note:  The unused should be something else, although I really
	    couldn't tell you what. MSDOS is a recognized partition 
	    type name, maybe that should be used.  Also, make sure that
	    your c: and d: partitions do not overlap this area.  h: might 
	    be a better partition letter to use; that way the MSDOS 
	    partition is graphically separate from the rest of the BSD
	    partitions.  DO NOT USE a:, b:, c:, or d: for your DOS 
	    partition.  These are RESERVED for your BSD system and any 
	    attempt to use these for anything but what BSD uses them for 
	    will result in a completely hosed, totally dead, absolutely 
	    screwed up file system.  You have been warned! )

		3) Add a line to /etc/fstab if you want it mounted 
		automatically.
   		  Mine is:
   		  /dev/wd0f       /dos            pcfs    rw              1       2

   	    Otherwise, just mount -t pcfs /dev/<part> /<dir>

	Mount has other options that may improve performance or increase
	security for your system.  See 'man mount' for more information 
	about mounting your system read-only and other advanced features.

	In addition to this, Jordan Hubbard has provided us with the
	following description for mounting the DOS partition specifically
	from FreeBSD:

		How to mount your DOS partition from FreeBSD

	1. First, be root.  The following won't work as an ordinary user.

	2. Second, use 'fdisk' to see where your DOS partition starts.  
	It will be labeled as type DOS.  On my system, 'fdisk /dev/sd0d' 
	produces the following:

		... (extraneous output, not of interest) ...
	The data for partition 0 is:
	sysid 6,(Primary 'big' DOS (> 32MB))
	    start 32, size 306400 (149 Meg), flag 0
	        beg: cyl 0/ sector 1/ head 1;
	        end: cyl 149/ sector 32/ head 39

	    This shows me that my DOS partition starts at sector 32, and 
	is 306400 (512 byte) sectors long.

	3. Next, using this information, you craft a new disk entry in your
	   /etc/disktab file that assigns one of your unused "UNIX" 
	   partitions to this DOS region.  Again, using my system as a 
	   default, you see I've created:

	disk0|DEC 5501:\
		:ty=winchester:dt=SCSI:se#512:nt#8:ns#256:nc#1001:rm#3600:\
		:pa#956416:oa#307200:ba#8192:fa#1024:ta=4.2BSD:\
		:pb#131072:ob#1263616:tb=swap:\
		:pc#1087488:oc#307200:tc=UNUSED:\
		:pe#306400:oe#32:te=MSDOS:

	   As you can see, partition 'e' now points to the DOS partition as
	   pointed out by fdisk.

	4. Now we have to actually stick the label on the disk, which is done
	   with disklabel.  Using my example, this would be:

	    disklabel -r -w sd0 disk0 SCSI /usr/mdec/sdboot /usr/mdec/bootsd

	5. Reboot your system to see the new disk label.

	6. Mount the DOS partition.  I do:

		mount -t pcfs /dev/sd0e /dos_c

	   Where /dos_c is just a convenient directory to mount it.

	7. You're set!

     
6.4	NFS/PC-NFS support

	The problems normally associated with PC-NFS are also associated 
	with NFS in general.  

6.4.1	Can I use 8K packets for NFS?  When I try, I have all kinds of 
	problems.

	In addition to the NE2000 card, this problem can also manifest 
	itself on other ISA networks cards that have a limited amount of
	memory.  Ken Raeburn (raeburn@cambridge.cygnus.com) has identified 
	a common problem with the NE2000 card and provided us with a work
	around:

	--------------------------------------------------------------------
	I reported previously that I was seeing problems reading files over
	NFS using the ne2000 driver; timeouts would eventually be reported, no
	data would be read.  Listing files and directories (small ones
	anyway) were not a problem.

	After playing with etherfind and kernel printfs, I've come to this
	conclusion: Fragmented 8K UDP packets from the NFS server are not
	reaching the UDP layer in 386bsd.  The Sun is sending them (according
	to another Sun spying on the network), but the UDP input routine is
	never called.  I don't know if the bug here is on the 386bsd or Sun
	side, and won't have time to look into it in the next couple of days.

	In the meantime, mounting NFS file systems with "rsize=1024" does get
	rid of this problem.

	Ken
	--------------------------------------------------------------------

	As a matter of policy, specifying "rsize=1024,wsize=1024" works very
	well also, and makes the transfers seem to run faster.  This is
	probably because there are fewer collisions.  The disadvantage of 
	this method comes from the kernel 'sync'ing after all NFS writes.  
	This can slow NFS accesses considerably.  As with most 
	generalizations, this one too can do nearly as much harm as good.  
	Charles Hannum reports that he has no trouble using the default 8K 
	packet size.  If you have trouble, reduce your default packet size
	until the problem goes away.
	

6.4.2	How do I get around the NFS "Permission denied" error?

	The problem is not the configuration of the server (unless there is
	no real requirement to run it in "secure" mode, and you happen to
	be running it that way anyway).  The problem is the fact that,
	even though mount request are sent on a privileged port, NFS
	connections are not.  This is part of secure NFS, and is not
	supported in 386BSD.
	

6.4.3	What does the message "BAD MNT RPC: RPC Authentication error; 
	why = Invalid client credential" mean when I try to mount something
	from another machine?

	Hellmuth Michaelis (hm@hcshh.hcs.de) offers the solution to this
	relatively common problem:

	You have to make sure that the user "root" is not present in more
	than 8 entries in the "/etc/group" - file on the 386BSD machine.
	Simply remove some entries and the NFS mounts will succeed.

	The problem is also explained in the Clarkson Driver documentation.
	On 386bsd, the maximum number of groups that can be associated with
	a particular user is specified in the source (in a #DEFINE).  In 
	386bsd, this number is set to 8.  So, you actually have two routes
	you can take to correct this problem.  The first is outlined by
	Hellmuth, above, and the second is to edit and recompile the NSF
	software to allow more groups.


6.4.4	What does the message "Bad MNT RPC: RPC: Authentication error; 
	why = Client credential too weak" mean when I try to mount something
	from another machine?

	This problem is a standard NFS problem; it simply means that your 
	user number is not one of the ones that can mount this NFS.  
	Normally, you will get this message when you are trying to mount 
	a filesystem from a machine that allows 'root' to mount an NFS,
	but limits other users.


6.4.5	I get a lot of 'ring buffer overflow' messages using NFS and the
	ed0 driver.  Is there a problem?

	David Greenman (davidg@implode.rain.com), the original author of 
	the ed0 driver, provides us with some insight into the inner 
	workings of the ed0 driver.

	   It always surpises me that people don't just ask the original 
	author these questions. :-) Anyway, the reason these are happening 
	is that the access to the 8bit boards shared memory simply isn't 
	fast enough to deal with full wire speeds...but the driver tries 
	hard...so even though packets get dropped, your performance only 
	drops to about what the ethernet board is capable of (should be 
	in the 400-600k range with an 8bit card). NFS is especially bad 
	because the UDP window is quite large (40k last time I looked), 
	so the overflow condition can happen easily. I've explained this
	for the most part in the release notes for the driver, but these 
	didn't make it into either the FreeBSD or NetBSD releases (we 
	couldn't find an appropriate place to put them).

	>From the release notes:

	receive
	-------
	   The 8390 implements a shared memory ring-buffer to store 
	incoming packets.  The 8bit boards (3c503, and 8003) usually have 
	only 8k bytes of shared memory.  This is only enough room for about 
	4 full size (1500 byte) packets. This can sometimes be a problem, 
	especially on the original WD8003E and 3c503.  This is because these 
	boards' shared memory access speed is also quite slow compared to 
	newer boards - typically only about 1MB/second. The additional 
	overhead of this slow memory access, and the fact that there is 
	only room for 4 full-sized packets means that the ring-buffer 
	will occassionally overflow.  When this happens, the board must 
	be reset to avoid a lockup problem in early revision 8390's.  
	Resetting the board will cause all of the data in the ring-buffer 
	to be lost - requiring it to be re-transmitted/received...slowing 
	things even further.  Because of these problems, maximum throughput 
	on boards of this type is only about 400-600k per second. The 16bit 
	boards (8013 series), however, have 16k of memory as well as much 
	faster memory access speed. Typical memory access speed on these 
	boards is about 4MB/second. These boards generally have no problems 
	keeping up with full ethernet speed. The only problem I've seen 
	with these boards is related to the (slow) performance of 386BSD's 
	malloc code when additional mbufs must be added to the pool. This 
	can sometimes increase the total time to remove a packet enough 
	for a ring-buffer overflow to occur.  


6.4.6	Is there any PC software that will allow me to use my enormous PC
	with all of the unsupported hardware as a PC-NFS server?

	Yes.  It is called SOSS, and is available from MANY FTP sources.
	You will need the aforementioned Clarkson Packet Drivers for it
	to work, but that should cause too many problems for most people.

-- 
TSgt Dave Burgess
NCOIC Applications Programming Branch
US Strategic Command, Offutt AFB, NE
burgessd@j64.stratcom.af.mil

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part8

Section 7.	(System Communication and Network Information)

7.0	Communications

	386bsd and its kith support a wide range of communications methods.
	
7.1	SLIP

	Serial Line I/P is supported in all versions of Net/2 derived BSD.

	Brian <brian@awfulhak.demon.co.uk> provides us with a rather
	good explanation of some of the hurdles that must be overcome
	for a working slip interface.

	The idea is (overview) that you make a serial line connection to 
	the host, set the line discipline, and tell your router to use 
	this interface as your gateway.  You also should set the gateway 
	up as a nameserver.

	Sounds easy ? - well it is if you've done it before.

	The _usual_ way of doing this is as follows:

	Both server and client must know eachothers inet addresses.  Set 
	these up in /etc/hosts with lines saying
	    11.22.33.44 host.my.domain.name host
	    11.22.33.55 client.my.domain.name client

	where 11.22.33.?? is your inet number, and the following name is 
	the full machine name (and is followed by any number of aliases).

	SERVER:
 	  Create a login - usually Sclientname - and run `sliplogin` as 
 	  its shell.  I've looked at the docs for sliplogin, and it seems
 	  fairly straightforward.  I haven't actually set up a server.

	CLIENT:
	  Set up /etc/resolv.conf to say the following (for the nameserver)
		domain client.my.domain.name
		nameserver 11.22.33.55

	  ** traditional method **
	  - Log on to the server.  This is usually done via kermit or some
	  such program.
	  - Exit the program (or backround it if your line wants to drop 
	  once the device is closed).
	  - Run `slattach /dev/comport` for whatever "comport" is.  On most
	    Net/2 derived systems, this may be either com0, or cua01, or
	    whatever the correct name is for your site.
	  - Run `ifconfig inet sl0 clientname servername netmask 0xffffff00`
	  - Run `route add default servername`.
	  
	    "servername" is your server and "clientname" is your client.
	    
	  It should now be possible to `ping host`

	** my method **
	  Configure /etc/remote
	  Configure /etc/host.dial
	  Run `slip host`.

	/etc/remote contains an extended `tip` entry.  /etc/host.dial 
	contains a login script (and is named in /etc/remote).

	Oh yes, don't forget to have a line in your kernel config saying

	pseudo-device sl 2

	Without this line, you may get a 'device not configured' or 
	'TIO...' error because the slip driver is not built into the 
	kernel.

	I uploaded the slip package a while ago (to several archives), but 
	was unaware of needing to notify the postmaster.  They've probably 
	all been removed now.  Slip packages are available from many FTP 
	sites; use archie to find the site nearest you.


7.2	CSLIP

	SLIP is included in the NetBSD-0.9 stock kernel and in the source
	tree.  It is also available in FreeBSD.


7.3	PPP

	Implementations of Point to Point Protocol are also available.  PPP
	should be available in the next major release (0.9+) of NetBSDi and 
	in the current release of FreeBSD.


7.4	TCP/IP

	TCP/IP is an integral part of Net/2 BSD.  There are at least five
	different network card drivers.  TCP/IP is fully supported and is
	available to all users of Net/2 derived BSD systems.  In fact,
	many people believe that this area is one of the primary advantages
	that Net/2 has over Linux.


7.5	UUCP

	There is an excellent document included in the UUCP directory
	that describes in detail, what needs to be done to get a working
	UUCP for Net/2 BSD systems.

	
7.5.1	TIP/CU

	First thing you need to do is...

		vi /etc/remote

	Then remove the two lines at the bottom of the file that mention 
	com1, and com2.  Now add the following lines:

		com0:dv=/dev/com0:br#9600:
		com1:dv=/dev/com1:br#9600:

	That tells tip/cu where to find your com ports.  Next you need 
	to be logged in as root and do a:

		chown uucp.dialer /dev/com0
		chown uucp.dialer /dev/com1
		touch /var/log/aculog
		chown uucp.dialer /var/log/aculog

	Make sure that, if you are running newsyslog, you change the 
	owner.group entry in the newsyslog.conf file so that the file
	ownership is maintained correctly.

	Then you should be all set, remember "DOS Com1" = com0, and 
	"DOS Com2" = com1.  So, if your modem is at 0x2F8/IRQ=3 and you
	access it as the COM2: port from DOS, you would do..

		tip com1

	To exit, type <RETURN>~.<RETURN>

	Many people have a problem with the lock open: procedure.   
	If you receive the error:

	lock open: no such file or directory
	all ports busy

	You need to create a directory: /var/spool/lock, owned by uucp.  If
	this file already exists and is owned correctly, make sure that the
	lock file in the directory is deleted.

	This answer thanks to (crt@tiamat.umd.umich.edu).


7.6	Terminals

	Since the target machine for most Net/2 machines is a 386 with 
	no more than a couple of serial ports, most people do not bother 
	with serial terminals.  For most problems, a quick perusal of the 
	man pages for the ttys file and getty are enough to get them 
	started.  Other than that, most terminal problems are limited to
	peculiarities of particular terminals.

	One common problem that appears to crop up from time to time is
	which wires need to be connected at each end of the cable.  Most
	cables do not, in fact, pass through all lines.  If your terminal 
	uses XON/XOFF (DC1/DC3) protocol, a cable of the appropriate 
	twist, either straight through or null modem, can have as few as
	three lines connecting the two devices.  Assuming DB-25 connections
	at each end, the lines need to go from 2 to 3, 3 to 2, and 7 to 7.
	These lines are Rx, Tx, and gnd.  Other lines that may or may not
	be required include 4 and 5; and 6, 8, and 20.  Normally, these 
	lines would be connected within the 'hood' of the cable to simulate
	the functionality of the full blown cable.  While full support for
	CTS/RTS is not available (yet), other support for the remainder
	of these lines is available or is being worked on in all Net/2
	derived systems.
	

7.7	Can network attached assets be used by/from NetBSD?

	Yes, they can, assuming the machine at the other end of the 
	connections is reasonably cooperative.  The specifics are up to the
	remote machine, but a couple of things that you can start looking
	for that will help are provided below:

		-  Ask the system administrator of the machine in question
		   if it is OK for you to use whatever it is you need.  This
		   is more a matter of manners than a technical issue.

		-  For NFS mounted disk drives, make sure that you are not
		   prevented from using the assets by the /etc/exports
		   (or equivalent) file.  This goes for CD-ROMs as well as
		   regular mounted disks.

		-  There are a completely different set of concerns for
		   tapes and printers.  Each system implements these in
		   slightly different ways.  Check with your system manager
		   or documentation for more information.
-- 
TSgt Dave Burgess
NCOIC Applications Programming Branch
US Strategic Command, Offutt AFB, NE
burgessd@j64.stratcom.af.mil

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part9

Section 8.	("Supported" Hardware List)

Disclaimer: This list is NOT a commercial oriented effort.  It is not an 
	    attempt to promote brands of computer machinery; it merely 
	    reports "happy" customers.  The validity of information supplied 
	    is based solely on the validity of the statements made by the 
	    contributors.  If more information is needed on a particular 
	    product please contact the contributor directly via e-mail.


8.0	What hardware is 386BSD known to run on and support!

	The problem with this section of the FAQ is that software is 
	the only reason that every PC card on the planet does not work.

	EISA cards are not directly supported; when and if EISA
	is directly supported, they will give a significant performance
	advantage to EISA bus machines.  As it happens, user who desire 
	more than 16Meg of memory must use either VESA or EISA systems.
	Even with an EISA system, many users will not be able to use the
	address space above 16Meg unless their system uses only EISA 
	cards for those devices that need access to DMA.  The limitations
	are covered in another section of the FAQ.

	Many EISA cards operate in an ISA emulation mode.  Notably, the
	Ultrastore 24F SCSI controller operates in an IDE emulation mode 
	that allows the card to be used in the current system without 
	modification.  Most EISA cards that operate in ISA mode will 
	work with 386BSD, NetBSD, or FreeBSD.

	Like EISA, MCA is unsupported currently; unlike EISA, it can't
	work until it is supported, as it doesn't fall back to ISA
	operation.  If you want to work on this problem, I'm sure that
	many people will appreciate it; you will probably need an ISA or
	EISA machine to do the work, however.


8.1	System brand names
8.2	Motherboards

	Here is the list of compatible motherboards for 386bsd that I 
	managed to collect off the network. Thanks to all of you who 
	contributed to this effort. If some of you have knowledge of a 
	different motherboard and want to add it to the list please send 
	E-mail either Kostis Dryllerakis (kd@doc.ic.ac.uk) or Dave Burgess 
	(burgess@hrd769.brooks.af.mil).

--------------------------------------------------------------------------------
Manufacturer		: Zeos
Country of origin	: USA
Architecture		: ISA (serial/parallel ports and controller on board)
Bus Slots		: 7 16-bit and 1 8-bit
Chipset			: 
Processor/Speed		: 486SLC/25
Processor Cache		: 8K(?)
BIOS			: Award w/ built-in setup (no password, though)
Max Memory		: 16 megs
Country of availability	:
Price estimate		: This machine was $1995. (out of production)
Points of attention	:
Other Information	: I would most likely not recommend this system, 
			  or any other system using a 486SLC...the 16 Meg limit
			  is a real pain. Also, the system has No processor 
			  upgrade options (unlike a real 486SX)...the 
			  motherboard itself would have to be replaced. :(
Contributor		: Matt Beal (publius@wam.umd.edu)
--------------------------------------------------------------------------------
Manufacturer		: Micronics
Country of origin	: USA
Architecture		: ISA
Bus Slots		: 8 (all 16 bit :-)
Chipset			: Not Known
Processor/Speed		: 486/25MHz
Processor Cache		: 256K
BIOS			: Phoenix
Max Memory		: 16Meg
Country of availability	: Australia (at least)
Price estimate		: Not Known
Points of attention	: 
Other Information	: Needed "fixed" boot floppies otherwise system 
			  would not boot from hard disk.
Contributor		: Brett Lymn (blymn@awadi.com.au)
--------------------------------------------------------------------------------
Manufacturer		: VOBIS / HIGHSCREEN
Country of origin	: Germany
Architecture		: ISA
Bus Slots		: 8
Chipset			: OPTI / uP INTEL
Processor/Speed		: INTEL 80486 DX 50 Mhz
Processor Cache		: 256 Kb
BIOS			: AMI 1992
Max Memory		: 32MB
Country of availability	: Europe
Price estimate		: 3000 US $ with the following configuration:
			  486/50 - 8 Mb RAM - HDD 210 Mb - 2 floppies - 
			  VGA card - 14" VGA Monitor - 
			  DOS/Windows/& other software.
Points of attention	: I paid 6000 US $ for the following configuration:
			  486/50 - 16 Mb RAM - SCSI card (Adaptec) 425 Mb 
			  SCSI disk - 2 floppies - 1 Mb VGA card (ET4000) - 
			  17" professional monitor etc. The hard drive alone 
			  costs 1250 US $, but it is from a third party. The 
			  monitor alone (PHILIPS, remarked as VOBIS) 
			  costs 1000 US $.
			  All prices are valid in Italy.
Other Information	: 
Contributor		: Piero Serini (piero@strider.st.dsi.unimi.it)
--------------------------------------------------------------------------------
Manufacturer		: OPTI
Country of origin	:
Architecture		: ISA
Bus Slots		: 8
Chipset			: OPTI
Processor/Speed		: 486DX/33
Processor Cache		: 256K (can use from 64K - 512K)
BIOS			: AMI
Max Memory		: 32M
Country of availability	: USA, at least
Price estimate		: $850 (w/ 8M) ??
Points of attention	: Make sure cache-able region setting matches actual
			  size of RAM.  Probably don't want BIOS shadowing.
Other Information	:  Uses 1- or 4-Meg 80ns SIMMS, in sets of 4.  
			  (8 sockets).
Contributor		: Bill Warner (wtw@wpi.wpi.edu)
--------------------------------------------------------------------------------
Manufacturer		: unknown (board is called PAT48SA)
Country of origin	: unknown
Architecture		: ISA
Bus Slots		: 6x 16bit, 1x 8bit
Chipset			: SIS
Processor/Speed		: 486 33MHz
Processor Cache		: 256 KByte
BIOS			: AMI BIOS
Max Memory		: 32 MByte
Country of availability : Germany (at least)
Price estimate		:
Points of attention	: none
Other Information	:
Contributor		: Jan Klier, Berlin - Germany (klier.cs.tu-berlin.de)
--------------------------------------------------------------------------------
Manufacturer		: NICE USA
Country of origin	: U.S.A
Architecture		: ISA
Bus Slots		: 8
Chipset			:
Processor/Speed		: 486DX/50MHz
Processor Cache		: 256K
BIOS			: AMI
Max Memory		: 32MB
Country of availability	:
Price estimate		:
Points of attention	: 
Other Information	:
Contributor		: Tom Wye TJW00@charon.amdahl.com
--------------------------------------------------------------------------------

		==== EISA MOTHERBOARDS ===

--------------------------------------------------------------------------------
Manufacturer		: A.I.R. (Advanced Integration Research, Inc.)	
Country of origin	: San Jose, CA USA
Architecture		: EISA/Local Bus
Bus Slots		: 8 Total - 5 EISA, 3 EISA/Local Bus
Chipset			: SIS
Processor/Speed		: 486DX33 (20-50mhz)
Processor Cache		: 256Kb (64-512KB)
BIOS			: AMI
Max Memory		: 256MB max using 16M X 36 SIMMS
Country of availability : U.S.A
Price estimate		: $475 US with 256KB cache, No processor or Memory
Points of attention	: 
Other Information	: Only tested with Tiny Kernel with Adaptec 1542B and
                   	  ET4000 video card.  EISA and Local Bus not tested 
                   	  yet.  Will post again with further results.
Contributor		: Joe Gervais joeg@Novell.com
--------------------------------------------------------------------------------
Manufacturer		: NICE
Country of origin	: USA
Architecture		: EISA/Local Bus
Bus Slots		: 8 total - 5 ISA + 2 EISA/VLB + 1 EISA
Chipset			: HiNT
Processor/Speed		: 486DX/50MHZ
Processor Cache		: 256K
BIOS			: AMI
Max Memory		: 128MB
Country of availability	: USA
Price estimate		: $950 + memory
Points of attention	: none
Other Information	: easy boot, mini AT footprint
			  easy boot, sudden death. first motherboard failed 
			  after one week due to temperature sensitive component.
Contributor		: duncan@zycad.com (Donald Duncan)
--------------------------------------------------------------------------------
Manufacturer		: Partner (according to supplier - board is unlabeled)
Country of origin	: Taiwan
Architecture		: EISA
Bus Slots		: 8
Chipset			: Opti
Processor/Speed		: 486 DX2 66
Processor Cache		: 8k internal 256k on board
BIOS			: AMI
Max Memory		: 32Mb
Country of availability	: UK
Price estimate		: 599 ex VAT including (necessary) heat sink for 486.
Points of attention	: Board works with 386BSD straight out of the box
    			  with defaults.. When adding memory you must use 
			  the BIOS setup to make all of the new RAM cache-able.
Other Information	: This board is cheap and it works. I got mine from
    			  Jupiter Systems (081 570 1011). They do a fairly wide
			  range of boards and accessories. See Micro Mart for 
			  an advert.
Contributor		: David James (dwj@btcase.bt.co.uk dwj@doc.ic.ac.uk)
--------------------------------------------------------------------------------
Manufacturer		: Synerco, Inc. Richardson Texas (214) 669-0023
Country of origin	: U.S.A.
Architecture		: EISA
Bus Slots		: 8
Chipset			: SOYO Motherboard
Processor/Speed		: Intel/486/66MHz
Processor Cache		: 256K
BIOS			: 1990 American Megatrends
Max Memory		: 32 MB
Country of availability	: Dallas, Texas, U.S.A.
Price estimate		: US 3,000
Points of attention	:
Other Information	: 1 IO card with /dev/com1=DB9 and /dev/com2=DB25
			  EtherCard PLUS "Elite16 Series" 
			  (io base=0x280, irq=2,iomem=0xd000)
					(jumper change to SOFT)
					(Do NOT use default setting, must use)
					(SMC SuperDisk a:ezsetup to adjust)
			  Logitech MouseMan Serial Mouse (M/N: M-CJ13 -9F) 
			  plug in /dev/com1
Contributor		: Jongjay Liou (jongjay@mistxt.oc.com)
--------------------------------------------------------------------------------
Manufacturer		: Gateway2000
Country of origin	: U.S.A.
Architecture		: EISA
Bus Slots		: 8 (6 master and 2 slave?)
Chipset			: 
Processor/Speed		: 486DX2-66E
Processor Cache		: 8 k internal 128 k external
BIOS			: Award (?)
Max Memory		: 16MB
Country of availability : U.S.A. 
Price estimate		: $4750
Points of attention	: (Set Adaptec 1740 SCSI to "standard" mode)
Other Information	:
Contributor		: Daniel Ortmann <ortmann@plains.NoDak.edu>
--------------------------------------------------------------------------------
Manufacturer		: Micronics Model: 5050-00-ICP/E2/256 Revision: A-1, 
			  plus rework ECN E2A07 to fix CMOS/clock problem
Country of origin	: USA/Taiwan
Architecture		: EISA & Local Bus
Bus Slots		: 8 EISA. 6 are bus master capable, two are not. One of
			  the slots that can not be used for a bus master has 
			  a connector at the other end for a local bus card. 
			  So, for this slot you decide whether to plug in an
			  EISA card or a local bus card.
Chipset			: Intel 357, Intel 358, and a Micronics ASIC.
Processor/Speed		: 486DX50
Processor Cache		: 256 KB external secondary cache, 8 KB internal
BIOS			: Phoenix 80486/EISA, ROM BIOS PLUS version 1.01.23-2	
Max Memory		: 64MB
Country of availability	:
Price estimate		: $1700.00 US
Points of attention	:
Other Information	: built in floppy controller, 1 parallel port, and two
			  serial ports.
Contributor		: Chris Shaker (shaker@cisco.com)
--------------------------------------------------------------------------------

8.3	Video cards
8.4	Mice
8.5	Serial Cards

8.5.1	How do I configure multiport cards?

	Patchkit 0.2.4 has introduced the possibility to use multiport 
	serial boards.  How do you configure an AST/4 in the kernel?

	The AST/4 and its clone multiport cards can run on 386BSD using 
	patchkit 0.2.4 and later.  The only problems seem to be that the
	code in sioprobe() and sioattach() in sio.c needs to be hacked to 
	get it to properly detect the ports and then recognize the type 
	of UARTs installed (16550As).  The code segment that is causing 
	the problem is included below:

	The test in the sio.c driver (in the sioattach() routine) that 
	is causing it to *think* it is a 8250 is:


	
	scr = inb(iobase + com_scr);
	outb(iobase + com_scr, 0xa5);
	scr1 = inb(iobase + com_scr);
	outb(iobase + com_scr, 0x5a);
	scr2 = inb(iobase + com_scr);
	outb(iobase + com_scr, scr);
	if (scr1 != 0xa5 || scr2 != 0x5a)   <--- this is it!
		printf(" <8250>");


	This test seems to be depending upon the absence of the com_scr 
	register in the 8250 (iobase+7).  Unfortunately, the AST 4-port
	card uses this last register of the last UART for interrupt status
	(for the 4 UARTs), hence the last port of the 4 fails the test.  
	The easiest fix is to simply delete this test in your copy of 
	sio.c (If you *know* that you have no 8250s).

	The Bocaboard (BB1008) fails the same way on *all* 8 of its
	ports (the +7 address register is replicated for each port 
	according to the documentation).

	There are also some problems with another test in the if 
	statement:

	if (   inb(iobase + com_cfcr) != CFCR_8BITS
	    || inb(iobase + com_ier) != IER_ETXRDY
	    || inb(iobase + com_mcr) != MCR_IENABLE
	    || !isa_irq_pending(dev)              <--- this one fails!
	    || (inb(iobase + com_iir) & IIR_IMASK) != IIR_TXRDY
	    || isa_irq_pending(dev)
	    || (inb(iobase + com_iir) & IIR_IMASK) != IIR_NOPEND)
		result = 0;

	in the sioprobe() routine for a couple of the ports on the 
	4-port card.  Again, the fix is simply to remove that particular 
	test and everything seems to be okay.  These are admittedly
	pretty ugly hacks, but when you're in a pinch to the system back
	up...

	What you need in the config file is:

	sio0	-> COM1 
	sio1	-> COM2

	(both should be recognized and work just fine)

	sio2	@ 0x1a0	irq 9 flags 0x0501
	sio3	@ 0x1a8	irq 9 flags 0x0501
	sio4	@ 0x1b0 irq 9 flags 0x0501
	sio5	@ 0x1b8 irq 9 flags 0x0501

	Other folks have reported that their configuration looks very 
	similar to this, though they are using irq 5 for the 4-port card.

	(above paraphrased from Bob Willcox, et al)

8.5.2	Now that I have FreeBSD 1.0 installed, how do I set up the 
	serial ports for bi-directional use?

	Thanks to Lyn Kennedy (lrk@k5qwb.lonestar.org) for the advice about 
	the cua devices and their minor numbers.  He worked out much of this 
	without docs.

	In order to get the comm ports working, I decided to run the sio 
	driver (heard it is faster and more capable than com).  In order to 
	get it set up, this is what I did.

	1. I have four com ports assigned to the addresses and interrupt lines
	that are standard for DOS COM1, COM2, COM3, and COM4.  I have the
	following lines in the file used to specify the config for the kernel
	build:

	device		sio0	at isa? port "IO_COM1" tty irq 4 vector siointr
	device		sio1	at isa? port "IO_COM2" tty irq 3 vector siointr
	device		sio2	at isa? port "IO_COM3" tty irq 5 vector siointr
	device		sio3	at isa? port "IO_COM4" tty irq 9 vector siointr

	I also enabled the use of com ports for either call in or call out by
	selecting the bi-directional option.  The following line in the config file
	causes the proper code to be compiled in the driver.

	options	   "COM_BIDIR"	#Bidirectional support in sys/isa/sio.c

	2. After building the kernel, I made sure the devices were represented 
	in /dev.  MAKEDEV should be used to create the tty0[0-3] special 
	devices.  It will result in entries such as the following:

	   0 crw-------    1 root     wheel     28,   0 Nov  8 06:28 tty00
	   0 crw-------    1 root     wheel     28,   1 Nov  8 10:09 tty01
	   0 crw-------    1 root     wheel     28,   2 Nov  7 01:13 tty02
	   0 crw-------    1 root     wheel     28,   3 Nov  8 03:02 tty03

	Then mknod and chown should be used to create the following four entries:

	   0 crw-rw-r--    1 uucp     dialer    28, 128 Nov  8 03:45 cua00
	   0 crw-rw-r--    1 uucp     dialer    28, 129 Nov  7 18:34 cua01
	   0 crw-rw-r--    1 uucp     dialer    28, 130 Nov  7 17:29 cua02
	   0 crw-rw-r--    1 uucp     dialer    28, 131 Nov  8 03:15 cua03

	The tty0[0-3] entries are used to receive calls on (with the 
	bidirectional code, this is signalled because the most significant 
	bit in the minor number is 0).  The cua0[0-3] entries represent the 
	same ports as the corresponding tty ports, but with the most 
	significant bit of the minor number turned on.  This indicates to 
	the driver that this port is a call out port.

	The reason for the ownership being set to uucp:dialer is because 
	I have all programs that use dialers (uucico, kermit, tip, etc.) 
	set to operate as set-uid with uucp as owner.  Also all of these 
	programs are set up as being in group dialer with group dialer 
	membership being required to execute them.

	3.  One further step needs to be done to allow proper use of the 
	ports.  In rc.local, the last few lines include the following:

	    comcontrol /dev/tty00 bidir
	    comcontrol /dev/tty01 bidir
	    comcontrol /dev/tty02 bidir
	    comcontrol /dev/tty03 bidir

	4. Now I set up getty to use the incoming ports with the following
	entries in /etc/ttys:

	    tty00	"/usr/libexec/getty std.19200"	unknown	on secure
	    tty01	"/usr/libexec/getty std.4800"	unknown	on secure
	    tty02	"/usr/libexec/getty std.4800"	unknown	on secure
	    tty03	"/usr/libexec/getty std.19200"	unknown	on secure

	5. I set up the port file for uucp, the remote file for tip, and 
	the .kermrc file for kermit to refer to the cua0[0-3] devices for 
	call out targets.

	6. Note that I have modems on cua/tty 00 and 03.  My modems are set 
	up to adjust the baud rate of the call (in or out) by negotiating 
	with the other modem in the call.  However the modems always retain 
	the same speed (19,200 Kb) for the rs-232 port.  In order to make 
	the modems use the proper speed, I have to send them an AT sequence 
	at the desired speed.  They will then retain that setting for 
	incoming calls.  So, to do this, I include the following at the 
	end of my rc.local script:

	    /usr/local/bin/initcua00 
	    /usr/local/bin/initcua03

	and in /usr/local/bin, I have the two scripts like (this is the one 
	for initcua00):

	#!/usr/local/bin/kermit
	set modem hayes
	set line /dev/cua00
	set speed 19200
	dial XXXXXXX                  <----------- it's own number to get busy
	quit


8.6	Disk Controllers
8.7	SCSI Controllers
8.8	Network Cards
8.9	Printers

8.10	TAPE Drives

	Editor's note:  

	This tapedrive list is maintained by the original authors.  If you
	have additions, corrections, changes, or deletions, please be sure
	to contact the folks listed in the next paragraph.

------------------------------------------------------------------------
Attn: QIC-40/80 users:

The QIC-40/80 Driver is reading and writing QIC-40/80 tapes on
FreeBSD. Formatting and verifying has yet to be written.

The latest version of the QIC-40/80 floppy tape driver is now available
at ftp.gte.com:/pub/ft/dist0.3/dist0.3.tgz. This release includes
support for the newer floppy driver with FreeBSD.

(thanks to cgd for the info)

If anyone has information about QIC-40/80 tape drives working (or not)
with the ft driver, please forward it and we'll include it in the FAQ.

------------------------------------------------------------------------

These tape drives have been reported as working (or not working)
on 386BSD, NetBSD or FreeBSD, either in articles on USENET or in
response to previous postings.  If you know any more details, want
to point out errors, know another tape drive works (or doesn't),
have any suggestions for additions/changes to the FAQ, or anything
else useful, please send your reports to:

          andrew@noware.ocunix.on.ca (Andrew Cornwall) or
          rsk@ecs.soton.ac.uk (Bob Kemp)

PLEASE HELP TO 26 Dec 1993 THIS LIST BY PROVIDING COMMENTS AND NEW
INFO.  IN RETURN, WE WILL POST UPDATES AND TRY TO MAKE THE LIST
AVAILABLE TO ANYONE INTERESTED.

IMPORTANT DISCLAIMER:
        This list is not guaranteed to be 100% correct.
        We don't know much about tape drives as yet, so
        we are only collating information provided by others.
        By getting feedback on this list, we hope to improve
        it into an FAQ.

EVEN MORE IMPORTANT THANK-YOU:
        Thanks to everyone who's contributed to this list. Without
        your help, it wouldn't exist!

-------------------------------------------------------------------
Changes to:
        Archive 2525-S
Additions: 
	Conner C250MQT
	Tandberg TDC-3800
        Wangtek 5099EK
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Important stuff: 

>From: juliane@au.gov.wa.dcd
>It should be noted that I am rewritung the scsi system`(new version
>out in beta) and that what works with what may change.
>
>julian

Some people have had problems using SCSI tapes. The newest SCSI code
fixes several problems; if you have trouble, try upgrading your SCSI
driver.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

The latest versions of FreeBSD/NetBSD will use compatible SCSI code.
Hence, what works with one should work with the other.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

MANUFACTURER CONTACTS:
        Archive is a Maynard company bought by Conner
                Sales:     +1 714 641 0279
                Technical: +1 800 227 6296
        [informant: mq8qc@qcunix.acc.qc.edu (KARAGEORGIOU ANGELOS)]

-------------------------------------------------------------------

COMPATIBLE TAPE DRIVES:

Format of each entry is as follows:
Name:           {name of the device; if you're reporting, please be as
                 specific as possible}
Capacity:       {Maximum size of the device}
Approx Cost:    {Roughly what you paid}
Interface:      {How it talks to the machine - SCSI, PC bus, etc}
Controllers:    {What controller you're using - Adaptec 1542B, etc}
Informant:      {Who says it works}
Comments:       {Anything good or bad you feel like saying}


Name:           Archive 2060
Capacity:       60MB
Approx Cost:    US$200
Interface:      SCSI
Controllers:    Adaptec 1542b, Adaptec 1742a
Informant:      duncan@zycad.com
Comments:       no observed problems when used with julian's drivers.
                works fine with 1542b/1742a


Name:           Archive 2150
Capacity:       250Mb
Approx cost:    US$350-500
Interface:      SCSI
Controllers:    Adaptec 1542b, Adaptec 1742a
Informant:      ejh@slustl.slu.edu (Eric J. Haug)
                admerlev@cip.e-technik.uni-erlangen.de (me 8-))
                duncan@zycad.com
                jfieber@sophia.smith.edu
Comments:       works well with both the driver in the distribution
                kernel and julians' SCSI drivers.   [ejh]

                nice device!!!, works like a charm, tar w/ original
                scsi-driver plus variable block length patch, under DOS:
                GTAR, ASPIBIN (ASPI-TAR), PCTOOLS 8.0, COREL-SCSI
                works fine with julian's drivers and 1542b/1742a
                    [admerlev/duncan]
                and with Adaptec 1542C + Julian's SCSI drivers [jfieber]

                S version (SCSI?) runs under FreeBSD:CombsSF@Salem.GE.COM
                2150S also known as Viper 150


Name:           Archive 2150L
Capacity:       150 Mb, 120 Mb
Interface:      QIC-02
Controllers:    Archive Viper SC402
Informant:      vak@kiae.su (Serge Vakulenko)
Comments:       Works well, with new wt driver (by me and Sergey Ryzhkov).
                Supports 150Mb and 120 Mb formats on write and 150Mb, 120Mb
                and 60Mb formats on read.  It's possible to use mt command
                to rewind the tape, seek file forward etc.

                It's not a problem in the SCSI code. It's a firmware
                bug in (at least) the Archive Viper 150. Data can be
                appended only if the drive is ``totally sure'' that
                the tape is at end of recorded medium. This could be
                achieved by issuing a `space to end of recorded
                medium' command.  Unfortunately, the recent version of
                Julian's SCSI driver doesn't support this.  (Future
                versions might do.)

                As a workaround, it's possible to ``mt fsf'' after the
                last tape file, then issue another ``mt fsf'', which
                will result in an IO error (SCSI blank check, `no data
                found' appears on console), that should be ignored.
                At this point, the tape could be written to!
                 - joerg_wunsch@tcd-dresden.de


Name:           Archive 2525-S (Firmware Rev. 25462-007 - seems to be important [nbladt])
Capacity:       QIC-24, QIC-120, QIC-150, QIC-525
Approx Cost:    ca. 1000,- DM (about US$ 600 ?)
Interface:      SCSI-1
Controllers:    Adaptec 1542B, Adaptec 1542C, Adaptec 1742A, Adaptec 1742B
Informant:      nbladt@autelca.ascom.ch (Norbert Bladt)
                hm@hcshh.hcs.de (Hellmuth Michaelis)
                loodvrij%cyb@fredbox.cts.com (Bruce J. Keeler)
		musashi@com.netcom (Irving Moy)
Comments:       In contrary to what my dealer told me, it can read and WRITE
                QIC-150 tapes. Didn't have a chance to try QIC-120, or QIC-60,
                etc. yet.
                I am using 386bsd-0.1 (still with the first patchkit and
                all updates from Julian for his fabulous SCSI-driver kit)
                Sorry, no experience with the original driver because
                that driver doesn't work with the 1742A. [nbladt]

                Worked with Julian's driver out of the box. [hm]

                Since putting in Julian's drivers, with Dave Tweten's mods,
                it seems to work just fine.  [loodvrij]


Name:           Cipher Model 540
Capacity:       45M/60M (probably/hopefully)
Approx Cost:    Loaned to me in `vintage appearance' (Much dust) - No idea !
Interface:      SCSI 1
Controllers:    Adaptec 1542B
Informant:      Julian Stacey   <stacey@guug.de>
Comments:       Shows promise, Cant yet call it truly usefull though:
                The Good Bit:
                        I have seen it stream constantly on 386bsd.
                The Bad Bit:
                        I can't use it as a usefull drive because it keeps
                        dropping out with errors.
                        The fault does not lie in the media, & most probably
                        not with external power supply or scsi cable -
                        I'm working on it.


Name:           CIPHER MicroStreamer F880 (1600bpi, 9 track PERTEC interface)
Capacity:       ???
Approx Cost:    $5000 for the drive in 1985
                $1000 for protocol Converter 1992
Interface:      SCSI
Controllers:    Adaptec AHA-1542A to NCR ADP-53 to tape drive 
Informant:      mike@scrooge.uoregon.edu (Mike Hoffman)
Comments:       It is FAST, reads tape about the same speed as rewind.
                The SCSI controller runs the 9 track drive thru the
                converter and an Archive 2060S 60mb Cartridge tape
                drive directly.  After putting in the current
                patches and reading the PERTEC Specs it was almost
                "plug and play".  The ADP-53 is a protocol converter
                from/to SCSI/PERTEC, purchased from Laguna Data
                Systems (see Byte Magazine).

                Problems:
                mt does not seem to be of much use.  Forward spacing
                the 9 track tape is an iffy job (skipping the label
                on a labeled tape).  dd now does this (skip=1).

                I always get the error 'cannot prevent/allow'.  This
                is not a big deal (prevent or allow removal of
                tape).

                dd does not handle cr/lf at all well.  Could be all
                the protocol conversions or gnu dd just doesn't do
                it.  All files are read in as one line(no CR Lf
                etc).  The blocking and conversion options have no
                effect on line length.  Conversion from EBCDIC to
                ASCII works fine.  A small program to break up the
                file solves the long line problem.


Name:           Cipher ST-150F
Capacity:       150Mb
Approx cost:    US$300 (incl. interface)
Interface:      QIC-02
Controllers:    Cipher
Informant:      hideki@isl.rdc.toshiba.co.jp (YOSHIDA Hideki)
Comments:       works well with blocksize <= 4b


Name:           Cipher ST150-S
Capacity:       QIC-24(read only), QIC-120, QIC-150
Approx Cost:    1300,- DM (long ago ..)
Interface:      SCSI (better SCSI-I or CCS)
Controllers:    Adaptec 1542B, 1742
Informant:      Hellmuth Michaelis (hm@hcshh.hcs.de)
Comments:       This drive responds with empty strings if asked for
                for it's vendors name and model.
                It has a strange format of the mode sense/set command
                blocks.
                By default, it reports a soft error back to the host
                which makes it a bit hard to work with.
                Problems solved with next release of Julian Elischer's
                enhanced SCSI driver (currently beta, July '93).
                oyang@bruce.cs.monash.edu.au reports an upgrade
                which involves a new ROM and cutting some traces.
                The drive responds: CIPHER : Model ST150S2 Rev: 2.0
                ANSI SCSI rev: 01 when asked for it's vendors names
                and model.

Name:           COMTEK Gigatape 1200 4mm external DAT
Capacity:       1.2 Gb
Approx Cost:    US$800
Interface:      SCSI 1
Controllers:    Adaptec 1542B
Informant:      Rich@rice.edu
Comments:       Uses formatted, fixed blocksize tapes.  Only
                partial success writing  about 400Mb so far.

Name: 		Conner C250MQT
Capacity:	250 MB compressed, 125 not
Approx Cost: 	approx $200
Interface:	Uses floppy disk controller on PC.
Controller:	?
Informant:	tpw@ruth.ece.psu.edu (Tom Weldon)
Comments:	Maybe it works, but i couldnt get it to talk to 386BSD
		with GENERICISA kernel.


Name:           DEC TZ30
Capacity:       96 MB (uses 3M CompacTape cartridges)
Approx cost:
Interface:      SCSI
Controllers:    Adaptec 154xB
Informant:      davidb@otto.bf.rmit.oz.au (David Burren) May 1993
Comments:       Works with Julian's SCSI drivers.  Console reports "cannot
                prevent/allow" but this is not a problem.
                This is the native-SCSI half-height version of DEC's
                TK50Z drive.


Name:           DEC TZ857
Capacity:       18.2 GB (stacker unit with seven 2.6 GB CompacTape
                    III tapes)
Approx cost:    lots
Interface:      SCSI
Controllers:    Adaptec 154xB
Informant:      davidb@otto.bf.rmit.oz.au (David Burren) May 1993
Comments:       Works with Julian's SCSI drivers.  As with the TZ30,
                "cannot prevent/allow" is reported but operation
                continues.
                As 386bsd has no "mt online" yet, cartridge loading is
                done manually, but unloading/advancing is done through
                "mt offline" as under Ultrix.
                I don't really use this drive, but I had access to it
                for a day and tried it out...


Name:           Exabyte 8200 8mm
Capacity:       2.2 GB
Approx cost:
Interface:      SCSI
Controllers:    Adaptec 154xB
Informant:      davidb@otto.bf.rmit.oz.au (David Burren) May 1993
		todd@flex.eng.mcmaster.ca (Todd Pfaff) Nov 1993
Comments:       Works perfectly with Julian's SCSI drivers.
                I use it all the time for my system dumps and for
                exchanging files with other machines.
		Works  great with FreeBSD-1.0-RELEASE although
                'mt -status' doesn't work properly.



Name:           Hewlett-Packard HP35480A DAT drive
Capacity:       4 GB
Approx Cost:    $1400
Interface:      SCSI
Controllers:    Adaptec 1542B
Informant:      karl@neosoft.com
Comments:       Great drive, flawless performance.  Requires
                variable length tapedrive patches which should be
                in the patchkit, but I haven't checked.  (They were
                submitted around November of '92)


Name:           Sankyo ST525
Capacity:       525 Mbyte
Approx Cost:    6000 SEK (US$850)
Interface:      SCSI (SCSI-2)
Controllers:    Adaptec 1542B
Informant:      jonas@carmen.volvo.se (Jonas Lagerblad)
Comments:       everything works allright except for one crash
                The SCSI bus seemed hang after running
                "dump 0uf - /dev/rsd0a | gzip --best |
                    dd of=/dev/rst0 bs=64k"
                for approx 1 hour. If I skip the compression
                everything works perfectly. (I am using Julian's
                SCSI driver) 386BSD-0.1 patchkit 0.2 patches 0-110


Name:           Sony SDT-1000 DAT
Capacity:       2 GB  on a 90 meter tape
Approx. Cost:   about $600 now, $3500 when purchased 3 yrs ago
Interface:      SCSI  (SCSI-2 also)
Controllers:    Adaptec 1542B
Informant:      steve@molly.dny.rockwell.com
Comments:       I have used it under 386BSD 0.1 and NetBSD 0.8.
                Under 386BSD, it didn't support all of the ioctl functions,
                but works without a hitch under NetBSD. I use it to do tar
                data backups and restores as well as interchanging data
                with an H-P 9000/755 using the HPUX tar command.


Name:           Tandberg 3600 series
Capacity:
Approx cost:
Interface:
Controllers:
Informant:      fredriks@austin.ibm.com (Lars Fredriksen)
Comments:       IN DEVELOPMENT.  So far I have it working with fixed
                and variable block micro code (original Tandberg vs. IBM firmware).

                I am adding support for selecting densities for the minor
                devices via IOCTLS,as well as setting the fixed blocksize via
                IOCTL. This work is almost done, and I will send the driver to
                julian. I see him as the distributor of fixes to his own code.

                So far I have not had any problems reading 30/60/150/250 Mb tapes.
                similarly no problems writing 150/250 Mb tapes.


Name:           Tandberg 3660
Capacity:       250Mb
Approx cost:
Interface:
Controllers:
Informant:      Per Anders Olausson <pao@cd.chalmers.se>
                meidinge@isar.de(Thomas Meidinger)
Comments:       DC6250, DC6150 (not tested) and DC600A.
                Reads and writes DC-6120 as well. [pao]

Name:           Tandberg TDC-3800 5.25" SCSI-1 325MB TBU
Capacity:       up to 520Mb (depending on media) uncompressed
Approx cost:    Didn't buy it new.
Interface:      SCSI-1
Controllers:    AHA1542B
Informant:      vax@ccwf.cc.utexas.edu (VaX#n8)
Comments:       Would not work with base 386bsd-0.1 kernel.
        	After applying patch kit, everything worked fine.
		Only tested reads on 250MB, reads and writes on 325MB,
		and reads and writes on 525MB.  Works great.
		Also fine under NetBSD-0.9. Even got "aspitar" from
		wuarchive to read tars from DOS. Don't mix 525 and 325MB
		tapes though, causes heads to wear out fast. Coexists with
		SCSI-2 drives just fine. Wouldn't trade it for anything but a
	        SCSI DAT or 8mm.Even then, I would have to think about it.


Name:           Tandberg 3820 5 1/4" HH internal QIC 525 SCSI streamer
Capacity:       up to 520Mb (depending on media) uncompressed
Approx cost:    (I bought mine two years ago--it wasn't cheap :-)
Interface:      SCSI-1/2
Controllers:    AHA1542B, 1742A, DTC3290
Informant:      tmh@first.gmd.de (Thomas M. Hoberg)
                stacey@guug.de (Julian Stacey)
                tomb@gator.bocaraton.ibm.com (Thomas Bagli)
Comments:       Works well with both the driver in the distribution kernel
                and julians' SCSI drivers. Reads all QIC media (tested
                QIC 40/60/120/150/525) Writes QIC 120/150/250/320/525
                (120/150/525 tested) Includes a 256k buffer. 2 rw
                speeds: 83k/s for QIC<320, 200k/sec for 320+
                Occasionally the file system can't keep up at
                200k/sec on backups (small files), somewhat more often
                on restores. The drive can directly seek to any block
                on the tape, so in theory at least with the
                appropriate device drive you could mount a file system
                on it (you better keep fragmentation low :-) As you
                can guess, I am EXTREMELY happy with it.
                [tmh]

                The Good Bit:
                It streams constantly without error (~40mins for 525M
                write @ 60K blocking).  Tape drive shares bus with 3
                SCSI-2 Seagate drives also OK with a SCSI-1 Micropolis 1684-7.
                The Bad Bit:
                We (several us of using these TDC3820s on different hardware)
                have undergone an eerom + eprom autodensity upgrade to allow
                150M writes (previously could only read 150M tapes +r&w 525M);
                this known as Revision 04908, Done 92 08 28.
                There is some kind of block size problem that prevents
                us reliably exchanging 525M tapes, 150M seems OK,
                problem is tape hardware oriented I believe,
                not 386BSD specific.
                Problem pre-existed the 150M write capability upgrade.
                A friend with same 386bsd + TDC3820 + 1542A can't read my tapes,
                neither can a PCS (M68000 based) computer with a TDC3820
                [stacey]

                We paid DM1000 (~$625) in early 1991.  This was a very
                special price, and I estimate that the actual cost would be
                (very) approximately 50% more (~$950).
                I've used it with an Adaptec 1742A, a DTC3290 (caching 1542B
                emulation), and a Mylex ?376? (caching, but only under DOS)
                SCSI controllers.  It doesn't just stream, it screams.  I've
                never seen a streamer that just streams without a pause,
                rewind or such.  This one does (not to say that the Tandberg
                is the sole reason for this).
                [tomb]


Name:           WangDAT 3200
Capacity:       2Gb (up to 8Gb w/compression) on a 90 meter tape
Approx cost:    US$1200-$1300 approx
Interface:      SCSI
Controllers:
Informant:      conklin@talisman.kaleida.com (J.T. Conklin)
                cgd@postgres.Berkeley.edu
Comments:       Works great with Julian's SCSI drivers and an Adaptec 1742...
                (I use it to do my dumps, and I've actually checked and made
                sure the restores work...  8-) [cgd]


Name:           Wangtek 5099EK
Capacity:       60M
Approx cost:
Interface:      PC/QIC-36
Controllers:
Informant:      robsch@robkaos.GUN.de (Robert Schien)
Comments:       The wt.c driver, which is delivered with FreeBSD-EPSILON,
                does not work with my Wangtek 5099EK (60 MB) tape drive.
                This drive has a PC/QIC-36 interface and it worked fine with
                ESIX 5.3.2D (For testing I tried SCO Xenix and ISC 2.2.1 and
                it worked with these OSs, too).  With the driver in
                386bsd-0.1, I could read tapes, but not write.  With the
                "improved" driver, I could neither read nor write (all minor
                devices tried). The solution was a driver from someone in
                Sweden (his name is Mikael Hybsch (sp?)), which worked for
                me already with 386bsd-0.1.



Name:           Wangtek 5099EN
Capacity:
Approx cost:
Interface:
Controllers:
Informant:      Original 386bsd.FAQ
Comments:


Name:           Wangtek 5099SC24, this is a QIC drive (same mechanical drive
                as 5099EN24) with a QIC24 to SCSI board by wangtek full height
Capacity:       60Mb w/DC600A, 100Mb w/DC6250
Approx cost:    Used as is drives US$25.00/each, refurbs ~US$100.00
Interface:      SCSI
Controllers:    Adaptec 1542B
Informant:      rgrimes@agora.rain.com
Comments:       works well with both the driver in the distribution
                kernel and julians' SCSI drivers.  Very old full height
                driver readily availiable in the surplus market.  I know
                where there are 50 or so of these for $25.00/each as is,
                they are pulls from old workstations.


Name:           Wangtek 5150EQ
Capacity:       250MB (QIC-150)
Approx cost:    400 UK pounds including software for DOS
Interface:      QIC-02
Controllers:    Wangtek QIC-02 included
Informant:      kd@doc.ic.ac.uk (K J Dryllerakis)
Comments:       Works with stock driver. Very very slow but reliable. Funny,
                it only seems to work if you use /dev/wt0 instead of /dev/rwt0.
                New driver in beta version by micke@dynas.se (Mikael Hybsch).



Name:           Wangtek 5150ES
Capacity:       250Mb
Approx cost:
Interface:      SCSI
Controllers:    Adaptec 1542B
Informant:      berry@max.IN-Berlin.DE (Stefan Behrens)
                duncan@zycad.com (Don)
Comments:       [With original 0.1 SCSI ...] it streams constantly
                and works without any errors.  Works with original
                as.c driver and with newer drivers from Julian
                [eg in patchkit 0.2.4].  [berry]

                Does not work with the 1742a and 386bsd!!!!!
                SCSI driver compatibility problems.  [duncan, ~Jun'93]
                NOTE: with the latest patchkit Stefan Behrens [berry]
                has reported that Julian's SCSI now works with it.
                No update yet on 1742A behaviour.


Name:           Wangtek 5525ES
Capacity:       525M
Approx cost:    US$600, CDN$1000
Interface:      Adaptec 1542B, Adaptec 1742
Controllers:    SCSI
Informant:      bky@eco.twg.com (Brian Yasaki)
                andrew@noware.ocunix.on.ca (Andrew Cornwall)
Comments:       Writes QIC120, 150, 250, 525. Reads QIC24 as well
                (untested). Works with the distribution kernel.


Name:           Wangtek QT60 (aka Tecmar QT60)
Capacity:       60M
Approx cost:
Interface:      QIC 02
Informant:      tcombs@pacific.urbana.mcd.mot.com (Tim Combs)
Comments:       It works although does not stream under 386BSD 0.1

END OF COMPATIBLE TAPE DRIVE LIST
---
Andrew Cornwall
andrew@noware.ocunix.on.ca




8.11	CD-ROMs

	The Sony Multispin drives work well for Charles Hannum using NetBSD
	and an SCSI controller.

	Many folks have announced that they had problems with Mitsumi
	CD-ROM drives.  It seems that there are nearly as many releases
	of the firmware as there were drives sold.  Many of the firmware
	versions were incompatible with each other.  A generic Mitsumi
	driver will be a hard act to accomplish, if it is possible at all.

-- 
TSgt Dave Burgess
NCOIC Applications Programming Branch
US Strategic Command, Offutt AFB, NE
burgessd@j64.stratcom.af.mil

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part10

Section 9	("Supported" Software List).

#9.1	Software known to run under 386BSD
#9.2	List whether patches are needed
#9.3	List version/release of program
#9.4	List who is supporting it if anyone
#9.5	List where you can get it

9.0	What GNU software has been tested and is working with Net/2 derived
	BSD systems for the 386?

	Just about all of it.


9.1	Has anyone ever gotten news to work?


	news running on 386bsd.  Here is a quick summary of the major 
	places to stumble:

	1)  get bash, gmake, gcc 2.X, cnews, trn (or your favorite reader).

	2)  Make uucp work. (Read the info files that come with the
	    original distribution for the whole scoop on configuration 
	    files.)

	Ed Note:  This step is not needed if you are imeplementing SLIP or
	are directly connected to a network.

	3)  Edit all the scripts which come with cnews and replace every 
	occurence of /bin/sh with /usr/local/bin/bash (or wherever you put 
	it).

	4)  Build cnews using bash, gmake and gcc 2.x

	5)  Install cnews in the directories you want it.  Some hand-hacking 
	of the intall scripts is required (Too long ago to remember the 
	details).

	6)  Change the permissions on all the scripts from execute only to 
	read-execute for group and other.  (On 386bsd, if you can't read 
	a script, you can't execute it).

	7)  Set up uucp to accept news

	8)  Post an article and steal it out of the uucp queue before it 
	gets sent.  Feed it to your rnews (as user uucp) instead and make 
	sure that it does not bomb out with permission denied or some such.

	9)  Have fun!

	Implementing innd is even easier.  The configure script that comes 
	with the system has been modified to work more correctly with
	Net/2 derived BSD systems.  There are rumors of  problems with 
	'lint', but these are easiest to find if you just run the configure
	script and let the system find the errors.  This patch file gives
	an example of the types of changes that need to be made.

	Ed Note:  This patch is reversed.  The first block in each
	section is the way your Makefile should look.

*** /usr/src/local/innd-1.4-dist/Makefile	Mon Jun 14 11:01:35 1993
--- /usr/src/local/innd-1.4-dist/Makefile.orig	Mon Jun 14 10:54:25 1993
***************
*** 35,46 ****
  	$(SHELL) ./makedirs.sh
  
  ##  Other generic targets.
! depend tags ctags profiled:
  	@$(MAKE) $(FLAGS) WHAT_TO_MAKE=$@ common
  
  clean:
  	@$(MAKE) $(FLAGS) WHAT_TO_MAKE=$@ common
! 	rm -f libinn.a libinn_p.a FILELIST
  
  ##  Common target.
  common:
--- 35,46 ----
  	$(SHELL) ./makedirs.sh
  
  ##  Other generic targets.
! lint depend tags ctags profiled:
  	@$(MAKE) $(FLAGS) WHAT_TO_MAKE=$@ common
  
  clean:
  	@$(MAKE) $(FLAGS) WHAT_TO_MAKE=$@ common
! 	rm -f libinn.a libinn_p.a llib-linn.ln FILELIST
  
  ##  Common target.
  common:
***************
*** 87,96 ****
  	-cd syslog; $(CC) -o syslogd syslogd.c ; cd ..
  	@echo "Install syslogd and syslog.conf as appropriate"
  
! ##  Configure, compile.
  world:		Install.ms
  	cd config ; $(MAKE) $(FLAGS) subst quiet ; cd ..
  	cd lib ; $(MAKE) $(FLAGS) install ; cd ..
  
  ##  Make a distribution.
  shar:
--- 87,99 ----
  	-cd syslog; $(CC) -o syslogd syslogd.c ; cd ..
  	@echo "Install syslogd and syslog.conf as appropriate"
  
! ##  Configure, compile, and lint.
  world:		Install.ms
  	cd config ; $(MAKE) $(FLAGS) subst quiet ; cd ..
+ 	cd lib ; $(MAKE) $(FLAGS) lint ; cd ..
+ 	cat lib/lint
  	cd lib ; $(MAKE) $(FLAGS) install ; cd ..
+ 	$(MAKE) $(FLAGS) lint
  
  ##  Make a distribution.
  shar:

  Simple as that :-)
-- 
TSgt Dave Burgess
NCOIC Applications Programming Branch
US Strategic Command, Offutt AFB, NE
burgessd@j64.stratcom.af.mil