*BSD News Article 30678


Return to BSD News archive

Xref: sserve comp.os.386bsd.announce:344 comp.answers:4989 news.answers:21403
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!uwm.edu!math.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!eff!news.duke.edu!godot.cc.duq.edu!nntp.club.cc.cmu.edu!news.mic.ucla.edu!ux1.lmu.edu!s069.infonet.net!s069.infonet.net!not-for-mail
From: burgess@s069.infonet.net (Dave Burgess)
Newsgroups: comp.os.386bsd.announce,comp.answers,news.answers
Subject: [comp.os.386bsd] BNR/2 derived BSD for PCs FAQ (Part 5 of 10)
Followup-To: comp.os.386bsd.misc
Date: 21 May 1994 23:07:06 -0000
Organization: Dave's House in Omaha
Lines: 453
Approved: news-answers-request@MIT.Edu
Distribution: world
Expires: 06/08/94
Message-ID: <386bsd-faq-5-769561614@s069.infonet.net>
References: <386bsd-faq-1-769561614@s069.infonet.net>
Reply-To: burgess@s069.infonet.net (386bsd FAQ Maintainer)
NNTP-Posting-Host: s069.infonet.net

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..

  Important note:  Most of these 'kernel patches' are to the original
  386bsd 0.1.  The really useful ones have been added to the kernel
  of both NetBSD and FreeBSD.

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"?

	When netstat was released, it came out as a binary patch and 
	source patch in the patchkit for 386bsd 0.1.  The program has
	been included in both NetBSD and FreeBSD.


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 (in 386bsd 0.1) 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 386bsd 0.1
	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.

	Also, when the internal structure of the kernel changes (as
	with the changes to NetBSD and FreeBSD that change fundamental
	parts of the kernel) a new ps, w, and uptime must usually be 
	recompiled.  If you are having trouble with your ps and have 
	recently upgraded/rebuilt your kernel, you will probably have 
	to rebuild ps etal.


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 were missing from libc.a in the original 386bsd 0.1.  
	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.
	The system hangs when trying to fsck -p both of my IDE hard drives
	at boot-up.

	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).

	It has been recently noted that, from time to time, a SCSI disk
	subsystem will behave exactly the same way.  It is usually because
	of bad/out-of-tolerance cables.  It is not a common problem, but it
	is one that you, the reader, may need to take into account when
	you are trouble-shooting your drives.

	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.


#include <std.disclaimer>

	[Ed. again] Other methods for fixing this problem include doing a 
	dd if=/dev/wd1d of=/dev/null count=1 before the initial 'fsck -p'.
	This method is considered brute force.  It works by making sure
	that the drive is properly initialized before the disklabel is
	read in the fsck.

	Another method involves using the '-l1' (little L) flag to make sure
	that the fsck doesn't try to open both unopened hard drives at the
	same time.  This method is a little better (from a purely brute
	viewpoint) but does caused your startup to run longer, since the
	purpose of this option is to have each of your fsck passes run
	one after another.


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,
	coordinated by Rodney Grimes (rgrimes@agora.rain.com) contained 
	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.

	Of course, there is no such thing as a patch kit for NetBSD or FreeBSD.
	The update method for these systems is different, and covered in the
	section about the System Update Protocol (sup) updates.


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.

	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.

	For NetBSD and FreeBSD users, two seperate and different shared 
	library systems have been developed.  This feature is included in
	the '-current' tree of both systems, and will be included in the
	next major release of eiter or both.


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

	NetBSD and FreeBSD have also adapted soundblaster drivers.  They
	are included in either the -current tree or in the most recent 
	release (depending on when you read this).

	For a fact, the following sound cards are supported in FreeBSD:

		1	Yamaha FM Synth
		2	Soundblaster/Soundblaster Pro DSP
		3	PAS PCM and Midi
		4	Gravis UltraSound
		5	MPU-401

	In the release notes I have, there is some doubt as to the 
	operational status of the MPU-401 sound card driver.  If you have 
	one of these cards and want to try the driver out, you should 
	contact Jordan Hubbard (jkh@freefall.cdrom.com) when you are 
	finished installing it and let him know how it is working.

	The docs for the FreeBSD driver are in 
	/usr/src/sys/i386/doc/sound.doc.
	

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:

	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. "

	Most of these busmouse drivers are now included in the current
	releases of NetBSD and FreeBSD.  There is some question about
	how well they work (especially the psm driver), but they are
	all there.


4.2.5	PPP Support

	A package to add PPP support to 386bsd can be found on agate
	in unofficial/drivers/net.  PPP support 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.

	These functions are (I think) included in the libcompat.a that
	comes with both NetBSD and FreeBSD.


4.2.7	Intel i82586 Ethernet Controller driver

	Garrett A. Wollman has written a 386bsd 0.1 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

	The patch that is included in the NetBSD and FreeBSD source trees
	is one written by Soerne Schmitt.  It appears to use the Sun-style
	/dev/audio interface and is different in goals and implementation
	from Andrew Chernov's speaker driver.  The source for this package
	is included in the source trees for both, but is not included in 
	the distribution kernels.

-- 
TSgt Dave Burgess               | Dave Burgess
NCOIC, USSTRATCOM/J6844         | *BSD FAQ Maintainer
Offutt AFB, NE                  | Burgess@cynjut.infonet.net or ...@s069.infonet...