Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA1512 ; Tue, 23 Feb 93 14:46:07 EST
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!spool.mu.edu!yale.edu!yale!gumby!destroyer!news.itd.umich.edu!spumco.css.itd.umich.edu!pauls
From: pauls@css.itd.umich.edu (Paul Southworth)
Newsgroups: comp.os.386bsd.questions
Subject: Current FAQ (I think)
Date: 18 Feb 1993 03:14:44 GMT
Organization: University of Michigan ITD Consulting and Support Services
Lines: 1665
Distribution: world
Message-ID: <1luuv4$b2k@terminator.rs.itd.umich.edu>
NNTP-Posting-Host: spumco.css.itd.umich.edu
>From csus.edu!wupost!sdd.hp.com!uakari.primate.wisc.edu!usenet.coe.montana.edu!terra2!osynw Wed Sep 16 14:10:52 PDT 1992
Article: 5717 of comp.unix.bsd
Newsgroups: comp.unix.bsd
Path: netcom.com!csus.edu!wupost!sdd.hp.com!uakari.primate.wisc.edu!usenet.coe.montana.edu!terra2!osynw
From: osynw@terra2.oscs.montana.edu (Nathan Williams)
Subject: 386BSD Bug Report 1/1
Message-ID: <1992Sep16.054657.485@coe.montana.edu>
Summary: Here it is!
Keywords: n
Sender: usenet@coe.montana.edu (USENET News System)
Organization: Montana State University
References: <1992Sep16.053926.29739@coe.montana.edu>
Date: Wed, 16 Sep 1992 05:46:57 GMT
Lines: 1648
U N O F F I C I A L 3 8 6 B S D B U G L I S T
--------------------------------------------------------
Date: Sept. 15, 1992
Revision: 0.4
[Still welcoming criticism, helpful suggestions, etc...]
Send Bug Reports or Bug fixes to: osynw@terra.oscs.montana.edu
with a subject line of "386BSD BUGS"
Patches can be found on agate.berkeley.edu
~pub/incoming/nate/patches.tar.Z
[Until Chris moves them, where they will be in the unofficial
directory under "osynw" or "williams"]
Index:
BOOT and DISKLABEL -
If you machine won't boot, or it will boot but doesn't
do what it is supposed to, check here
INSTALL and CONFIGURATION -
These are configuration problems that exist after you
have successfully installed 386BSD 0.1. If a program
won't work, but it seems to run, check here.
KERNEL -
These are REAL (tm) bugs in the operating system, with
unofficial patches. If you are getting kernel panics,
or something in the system doesn't work right, check
here
PROGRAM -
These are bugs in the programs that are distributed
with 386BSD 0.1. It's pretty scarce right now, but
most of these bugs could probably be fixed fairly
easily by non-guru's.
MISC -
Anything else. It will probably be split up as I get
suggestions, and as the list grows.
BIG -
This is a section directed to large patches that I
don't want to leave out, but I don't really want
to put in misc. either.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-
BOOT AND DISKLABEL PROBLEMS
========================================
Bug Number: BOOT001
Problem:
386BSD 0.1 ignores the hard disk geometries given
in the CMOS ram on IDE disks OR
My machine will not boot off an IDE drive. OR
various IDE drive problems
Explanation:
Instead of getting the geometries from CMOS, it (apparently) gets
the geometries direct from the disk itself. This causes problems
when IDE disks are running in translation mode, because the BIOS
is old and doesn't allow customized disk geometries.
Solution:
Use the real parameters of the IDE drive in the CMOS table, and don't
use the translation parameters.
I don't have a source fix, sorry. Only fix then is to upgrade to
a new BIOS, backup your hard disk, customize your CMOS and your
DOS partitions (if needed) to fit in with the correct geometry,
and restore.
Submitted by:
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
(same)
========================================
Bug Number: BOOT002
Problem:
disklabel isn't working correctly.
I can't boot after installing the software OR
I can't disklabel my second drive OR
System will not recognize second hard drive and/or it crashes
when you try to access a second drive which is configured but not
connected.
Explanation:
1) Can't boot. /sys/i386/stand/wd.c is checking an invalid
register after resetting the controller. Depending on the
controller, this may or may not hang forever.
2) With partition 3 marked as 00 (unused), I can read from
/dev/rwd1d and do disklabel -r wd1. I get the information from
the first absolute sector of drive 2 in this case.
With partition 3 marked as A5 (386BSD), doing anything with
rwd1d, or disklabel -r wd1, the whole system hangs. The terminal
driver seems to still be working, as characters such as ^V still
work. The system must be reset at this stage.
3) The wd driver has bugs in it.
It will try to open all configured disks at boot time
and print the identification strings.
Solution:
1) Get patched binaries from agate. OR
*PATCH*
There is a file called noboot_wd.0_1 which fixes wd.c
to allow you to boot off the hard-drive.
2) None yet
*PATCH*
3) There is a patch file available, called 2_disk.wd.0_1 which
contains a cdiff which fixes these problems.
Submitted by:
rd@phoenix.aii.com (Bob Thrush)
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
rd@phoenix.aii.com (Bob Thrush)
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
========================================
Bug Number: BOOT003
Problem:
shutdown -todos doesn't work as documented.
Explanation:
The program complains about being unable to make the DOS
partition bootable
Solution:
Boot off a floppy that has fdisk on it and use fdisk to change
the active partition to the DOS one.
From Terry Lambert's FAQ-
This will not work if your partition is larger than about 30K
(the point at which DOS will use a 16 bit FAT). Apparently, it
will only work with 8 bit FATs, so if it is possible, use a
smaller DOS partition, or several smaller partitions instead of
one large one.
Submitted by:
kevinz@storage.tandem.com (Kevin Zeigler)
Solved by:
terry@icarus.weber.edu (Terry Lambert)
========================================
Bug Number: BOOT004
Problem:
Bringing the machine into single user mode doesn't work
correctly. AND
After people log out of the machine, who and last show
them as still logged on. AND
Signal handling is screwed up when commands are run from
/etc/rc.
Explanation:
/sbin/init didn't set some internal flags correctly (Reboot, drain)
This caused it to not execute /etc/rc again if the system was
brought down to single-user and the back up again.
It also tried to start multi-user mode when you tried
hat or reboot in single-user (when the single-use shell was terminated
by halt/reboot).
/sbin/init wasn't cleaning up the utmp and wtmp files correctly.
I made a patch that caused normal login/logouts to be updated
correctly, but single user shutdown and reboots still need
some code added.
In the process of cleaning up Dan L.'s code (init author)
someone deleted several sigsetmask(0L) calls. So, assuming the
mask isn't reset by fork or exec these days, /etc/rc is being
run with init's signal mask which blocks SIGHUP and SIGTERM.
Solution:
*PATCH*
There is a patch file available, called init_single.0_1 which
contains a cdiff to correct the single user problem.
*PATCH*
There is a patch file available, called init_utmp.0_1 which
contains a cdiff to correct the utmp/wtmp problem.
*PATCH*
There is a patch called init_signal.0_1 which contains a cdiff to
add a sigsetmask to correct the signal problem
*NOTE*
Mark Tinguely suggested using the init he posted to the
comp.unix.bsd group a while back, since it doesn't seem to have
the problems the current one does.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
tinguely@plains.nodak.edu (Mark Tinguely)
pk@cs.few.eur.nl (Paul Kranenburg)
========================================
Bug Number: BOOT005
Problem:
386BSD does not use the values in the disklabel. It will
use the parameters in the /etc/fstab file.
Explanation:
Even though the label was written that a partition was unused,
the fstab file stated that partition was swap, and starting
writing to that partition.
Solution:
BE CAREFUL!!
Submitted by:
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
(same)
========================================
Bug Number: BOOT006
Problem:
Machine will not boot 386bsd on a warm reboot.
Explanation:
During a warm reboot, in wd.c the machine is picking up the same
memory segment as before and so it appears that the drive is
already open.
Solution:
Bzero out the memory malloced by wdprobe. There are a couple
patches to the wd.c code, and one of them contains the
patch which bzeroes out the memory.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
(same)
========================================
Bug Number: BOOT007
Problem:
WD8013EP ethernet card ('EtherCard Plus Elite 16') only works
after a warm boot.
Explanation:
On the first boot after switching on the workstation,
I only get the well-known Reject xxxxx -Messages.
Solution:
None-yet.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
========================================
Bug Number: BOOT008
Problem:
I get the error "isr 15 and error: isr 17" on an NE2000 card, OR
I have some card on IRQ2 and it doesn't work; why?
Explanation:
Some VGA cards use IRQ 2 for a vertical retrace interrupt. Even
when the interrupt is not enabled in the VGA, some cards drive
IRQ 2 inactive instead of leaving the signal tristate.
Solution:
If this is the problem, you can use Scotch tape to cover the IRQ
2 signal on the VGA's ISA connector., or cut the IRQ trace on
your board.
An alternate solution would be to remove your ethernet card
until you have rebuilt the kernel so that it expects it at an
interrupt other than 2, re-jumper it, and re-install it. This
gets around both the tape and exacto knife solutions, plus you
don't have to know which pin is IRQ2 (something you need a
technical reference for the bus to find out).
Submitted by:
The net.
Solved by:
james@bigtex.cactus.org (James Van Artsdalen)
========================================
Bug Number: BOOT009
Problem:
Machine will not boot, have tried everything.
Explanation:
Diskettes used:
dist.fs (Jolitz .01.24), dist.fs, (cgd) fixit.fs (cgd)
Copyright notice appears, disk access light stays on, cursor
blinks, nothing else ever happens. I think I have seen a similar
problem on this group but not the solution. Tried all three
disks, disabled or disconnected all optional hardware, disabled
various CMOS settings. All three disks had exact same problem.
486/33mhz OPTI-486WB with 8MB RAM
OPTI chipset, AMI BIOS (6/6/91)
"Groundhog Graphics" ET4000 SVGA card
Quantum 234mb IDE drive
1.2mb and 1.44mb drives (1.2mb is boot)
All serial and parallel cards removed after initial failure
All "shadow" options disabled in CMOS after initial failure
All caches disabled in CMOS after initial failure
Speed reduced to "16mhz" after additional failures
Solution:
Try this!
*PATCH*
There is a patch called keybd_delay.0_1 which will fix
some of the booting problems encountered.
But one needs to get a working system first before the patch can
be applied, and I found a crazy hack for that. At the point
where the boot appears to be hanging, just unplug and replug the
keyboard and the boot will continue normally.
Otherwise - None yet :(
Submitted by:
barnesdo@cs.colostate.edu (douglas barnes)
Solved by:
terry@uivlsisd.csl.uiuc.edu (Terry Lee)
fpm@crash.cts.com (Frank Maclachlan)
========================================
Bug Number: BOOT010
Problem:
Machine will not reboot.
Explanation:
reboot(8) syncs the disks, but the machine is then hung. Also,
the same things happens with <CTRL><ALT><DEL>.
Under SysVR4, the keyboard controller is used to reboot the machine,
but under 386BSD ???.
Solution:
none
Submitted by:
andrewh@molly.cs.monash.edu.au (Andrew Herbert)
Solved by:
INSTALLATION or CONFIGURATION
Problems that occur after you have installed 386BSD 0.1, or during
installation.
========================================
Bug Number: INST001
Problem:
I can't unpack the etc01 distribution OR
I get the error "too many files open" unpacking the etc01
distribution.
Explanation:
The problem is from cat command leaving the file open after
reading it. Since the default shell only allows 64 files open,
it will not allow you to read more than 64 files.
Solution:
Move all the etc01.* files to a different directory (I used
/usr/tmp) so that they won't get deleted when you reboot.
Boot up with the bin01 distribution loaded and login as root.
Next (root uses csh as the default shell), do a
cd /; cat /usr/tmp/etc01.* | zcat | cpio -iadmlu and wait for
etc01 to unpack everything where it's supposed to go.
Submitted by:
comp.unix.bsd
Solved by:
(same)
========================================
Bug Number: INST002
Problem:
/usr/bin/tip doesn't work.
Explanation:
tip is setuid "uucp". It wants to create a lock file under
/var/spool/lock, but lock is owned by root and mode 0755. Since
uucp can't create a lock, it dies.
Solution:
There are two solutions to the problem. The first is to make
tip setuid root (chmod 4755 /usr/bin/tip), but that is not the
best solution.
The preferred solution is to change the ownerships on the
/var/spool/lock directory to allow tip to create a lock file. Another
little problem is /var/spool/aculog is written by tip, so uucp
also needs to own that.
I added the /dev/com devices because I wanted to make sure tip
could always connect to them. This may be un-necessary.
Ex:
pc # chown uucp /var/spool/lock /dev/com* /var/spool/aculog
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
The net at large.
========================================
Bug Number: INST003
Problem:
When I run ps, I get an error that it can't find _foo symbols...
ps -u gives me a floating point exception.
Explanation:
There are not enough symbols in the kernel. First of all, the
kernel supplied with the distribution has been stripped, so
there are no symbols in it. Also, there are some missing
symbols in the symbols.raw file which determines which symbols
will be present in the kernel. Bill Jolitz mentioned this in a
net article, and said the fix for this was in patch1. Patch1
doesn't appear to be coming, but version 0.2 was mentioned
recently.
See the PROG009 entry.
Solution:
386BSD 0.2 will hopefully have the fix for this. Also, if you
re-compile the kernel, most of the needed symbols will be in the
kernel.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
386BSD 0.2 (Jolitz, et al)
davidg%implode@agora.rain.com (David Greenman)
========================================
Bug Number: INST004
Problem:
Mtools doesn't work.
Explanation:
Mtools is looking for devices that don't exist in the standard
distribution. You need to create the device special files for
mtools to use.
Solution:
Use MAKEDEV to create the /dev/fd* devices required by mtools.
Ex:
pc # cd /dev
pc # sh MAKEDEV fd0 fd1
pc # dev_mkdb
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
========================================
Bug Number: INST005
Problem:
User's can't create files in their home directories.
Explanation:
As distributed, home directories are owned by root and not by
the user.
Solution:
Ex:
pc # cd /usr/nate
pc # chown nate.staff . .??*
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
========================================
Bug Number: INST006
Problem:
I can't create any new users. I've edited the passwd file, but
the changes don't seem to get added.
Explanation:
386BSD is using a shadow password utility which hides the
encrypted passwords in a separate, root-only readable file
called master.passwd. Also, there are database files created
when you change the master.passwd file, so you need to go
through the supplied "vipw" utility to add users.
Solution:
Use the "/usr/sbin/vipw" program to add users. After you have
added the user(s), you can copy the /usr/share/skel/dot.* files
into their home directory and change the ownerships of the
directory and files to the user.
Ex:
pc # vipw
[Added user foo]
pc # mkdir /usr/foo
pc # cd /usr/foo
pc # cp /usr/share/skel/.??* .
pc # chown foo . .??*
[This assumes you have changed the names of /usr/share/skel/dot.cshrc to
/usr/share/skel/.cshrc. It makes adding users much nicer]
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
The net at large.
========================================
Bug Number: INST007
Problem:
Normal users can't use vi (elvis).
Explanation:
The /tmp and /var/tmp directories have incorrect permissions as
distributed, and elvis can't write a temporary file to them.
Solution:
Change the permissions on those directories. I change them to
everyone read, write, execute, plus the sticky bit so that the
users can't delete other user's files.
Ex:
pc # chmod 1777 /tmp /var/tmp
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
========================================
Bug Number: INST008
Problem:
My computer does not have the correct time that is set in my
BIOS.
Explanation:
386BSD uses a file /etc/localtime which tells it which timezone
you are in. As distributed, it has a symbolic link to
/usr/share/zoneinfo/US/Pacific-New, the correct time for Bill
and Lynne. You need to remove the old /etc/localtime and link it
to the correct time for you area.
There is code in the kernel which will use the DST in the BIOS,
which was commented out. There is a patch file to fix it.
Solution:
rm /etc/localtime and make a new symbolic to link to the new
time zone.
Ex:
pc # rm /etc/localtime
pc # date
Wed Jul 29 21:58 GMT 1992
pc # ln -s /usr/share/zoneinfo/US/Mountain /etc/localtime
pc # date
Wed Jul 29 14:59 MDT 1992
pc #
-NOTE-
Some BIOS's automatically have Daylight Savings time set up, so
you have three options.
1) Change the time in your BIOS so that 386BSD will have
the correct time. This is the best option.
2) Hack up on of the datafiles in
/usr/othersrc/share/zoneinfo/datafiles to have the
correct time for your machine.
3) Fix the kernel code to read the DST value out of the
BIOS
*PATCH*
There is a patch called kernel_time.0_1 which allows the kernel
to read the DST from the BIOS.
-ENDNOTE-
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
arnej@lise.unit.no (Arne Henrik Juul)
========================================
Bug Number: INST009
Problem:
man -k doesn't work.
Explanation:
You need to create the whatis.db file. However, there is a ^H in
all the man pages that messes up apropos, with needs to be
stripped out.
Solution:
in /usr/othersrc/share/man/Makefile, add a col -b to strip out
the ^H's from the man pages.
Ex:
makedb:
..
..
done | sort -u > whatis.db
becomes:
done | col -b | sort -u > whatis.db
*PATCH*
There is also a patch file called man_make.0_1 which
contains the fix to the makefile.
Submitted by:
James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
(same)
========================================
Bug Number: INST010
Problem:
Slip is configured and started in my /etc/rc file, but doesn't
seem to work
Explanation:
Somehow slattach is being killed when run from /etc/rc.
Solution:
add a nohup to the slattach command in /etc/rc.
Ex:
nohup slattach /dev/com1 2400
Submitted by:
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
(same)
========================================
Bug Number: INST011
Problem:
I can't get my tape drive to work (SCSI).
Explanation:
The /dev/ras4* device special files are wrong in the
distribution. You need to make new ones using the mknod
command.
Solution:
rm /dev/ras4*, and create new ras4* nodes.
Ex:
pc # cd /dev
pc # rm /dev/ras4*
pc # mknod ras4a c 13 32
pc # mknod ras4d c 13 35
Submitted by:
comp.unix.bsd
Solved by:
wjolitz@soda.berkeley.edu (W. Jolitz)
========================================
Bug Number: INST011
Problem:
There is a serious bug in the bad block handling.
Explanation:
In 0.1, the driver checks the bad block list for every block,
but the test is wrong for reads of multiple blocks - it only
tests if the initial block is on the list. And when the initial
block is on the list, it doesn't split up the i/o, so good
blocks after the bad one are messed up.
Solution:
I think there is a problem in the 386BSD 0.1
'usr/src/sys.386bsd/i386/isa/wd.c' when the first sector in a
multi-sector read or write request is present in the bad144
table. The bad144 table search code at line 382 finds the sector
in the bad144 table and replaces the block number, cylinder,
head, and sector addresses with values corresponding to the
replacement sector. At line 434, the sector count register is
loaded with the number of sectors in the entire transfer. This
is wrong; it *MUST* be set to *one* sector. A read would return
the wrong data in sectors after the first; a write would
*overwrite* other replacement sectors or even the bad144 table
on the last track.
*PATCH*
There is a file called bad_wd.0_1 which contains a fix
to the bad block handling code in wd.c
Submitted by:
bde@runx.oz.au (Bruce Evans)
Solved by:
fpm@crash.cts.com (Frank Maclachlan)
KERNEL
386BSD 0.1 kernel file bugs. (Anything that is below /sys)
[but NOT boot stuff or disklabel]
========================================
Bug Number: KERN001
Problem:
Machine panics with: kmem_malloc: kmem_map too small
Explanation:
I have seen two reasons for this. The first is the most
common.
1) There are not enough map entries for computers with >12 MB of
memory.
2) The problem I am having stems from the fact that the
drive comes back with nonsense when hit with a SCSI read
capacity command. The block size is way out of line. If I retry
the command, all is well. I can not figure out why the drive
responds normally *every* time when configured as SCSI id 0, or
1. It may be possible that the buffer is getting stepped on
after the command has completed.
Solution:
*PATCH*
1)
There is also a patch file called kmem_panic.0_1 which
contains the below fix.
in the file /sys/vm/vm_map.h, there is a:
#define MAX_KMAPENT 500
which needs to be
#define MAX_KMAPENT 1000
2) Hack the as driver to retry and get the block size when it is way
out of line.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
jones@cs.Buffalo.EDU (Terry A. Jones)
Solved by:
wjolitz@soda.berkeley.edu (W. Jolitz)
scott@pita.cns.ucla.edu (Scott Burris)
========================================
Bug Number: KERN002
Problem:
The following simple program would hang the computer:
#include <stdio.h>
main()
{
char data[8192];
FILE *f;
f = fopen("Test2.file", "w+");
while(1)
{
fread(data, 1, 8192, f);
rewind(f);
fwrite(data, 1, 8192, f);
}
}
Explanation:
There is some sort of bug in the scheduler relating to charging
a process for the CPU while doing heavy disk I/O... If you try
out a similar program which does main(){while(1);} you get the
proper priority of the process as well as proper load averages.
If however you run the above not only does the priority
mechanism fail but I imagine the load average is not correct.
Solution:
None yet. But....
The bug is probably in kern_clock.c or in kern_synch.c ... I
have not tried to investigate this further as it may be a
problem with the system as a whole and not a simple bug. (ie.
relating to the assigned interrupt levels in the kernel...)
Submitted by:
pao@cd.chalmers.se (Andrew Olausson)
Solved by:
========================================
Bug Number: KERN003
Problem:
System hanging under heavy disk activity and high load
Explanation:
Things are getting put to sleep waiting for pages, and
are never being awakened.
This problem was noticed when using DDB. I found that there
were *NO* processes on any of the run queues, and a lot of
processes waiting for disk pages...)
Solution:
None yet.
*NOTE*
Karl Lehenbauer (karl@neosoft.com) made mention of the fact that
in 0.0, the swap partition must be on cylinder boundaries.
The check for this is to run disklabel -r wd0 (as0)
and if there are stars after each partition, the partition
is NOT on a partition boundary. After hearing this, I hand
installed 386BSD, and I have not had any problems with machine
lockups because of heavy cpu/load. (though I have had lockups
for other reasons :-)
dawes@physics.su.oz.au (David Dawes) was having the lockups
on his machine after installing the patches, and after
increasing his swap space and aligning it on cylinder bound-
aries, his lockups went away.
If you can't compile a kernel because of lockups, you may
be able to mount the filesystem to do synchronous writes. This
is very slow, but it *may* help the lockups until you can
compile the fixed kernel.
*ENDNOTE*
*PATCH*
There was mention of this bug in a net article, with a patch by
Bill Jolitz, which may or may not solve this problem. It was
kind of vague, but you may try it. However, in the same
article, Bill did mention that main purpose of version 0.2 was
to fix this bug.
There is a file called heavy_load.0_1 which is the fix that
Bill mentioned in his article.
Submitted by:
cgd@agate.berkeley.edu (Chris G. Demetriou)
Solved by:
wjolitz@soda.berkeley.edu (W. Jolitz)
========================================
Bug Number: KERN004
Problem:
Various machine lockups when doing com stuff.
Explanation:
kermitting through com1, or downloading via zmodem
Occasionally, I get a console message: communication disconnect
and the machine is locked up. No panel lights, no 3-finger
salute. A hard reset was required to bring the machine back to
life.
Other times, kermit was put into a state where a
kill -9 would not even do anything, so a reboot was necessary
to use the modem. The machine was still usable (via screen)
so serial communication was only affected.
Solution:
I suspect the com driver. Maybe replace it with the beta com
driver on agate.berkeley.edu by Chris D.
*NOTE*
[I had more problems with Chris's driver than I did with
the stock driver. This may be a single case, but I thought
I would note it. This by no means says that Chris is a bad
programmer or anything, but that I had problems with that
driver]
*ENDNOTE*
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
========================================
Bug Number: KERN005
Problem:
The serial ports don't work at all on my machine.
Explanation:
There is probably a card in you machine that has IRQ 4. Check
out all your cards, and make sure there is nothing that is using
IRQ 4.
Solution:
Change the offending card to NOT use IRQ 4.
Submitted by:
terry_lambert@gateway.novell.com (Terry Lambert)
Solved by:
(same)
========================================
Bug Number: KERN006
Problem:
Flashing multi-colored characters and a ptdi81061 prompt.
Explanation:
The problem is that the code checking the return from the read of
the CMOS RAM value falls through in the case of an invalid value.
What really is needed is the non-existence "else" case for a bad
CMOS setup, which goes and probes memory to see it's size. What
currently happens is that the code falls through, the Maxmem is set
to zero, and the maxmem and physmem are set to -1 (this is a bad
thing).
Solution:
The quick and dirty workaround: If you download dist.fs from
Chris G. Demetriou's upload on agate.berkeley.edu for the hard disk
boot problem (this MUST be dist.fs, and not one of the other dist.fs
files modified for Isolan or WD ethernet and named something else!),
you can use uzap (available for anon ftp from wuarchive.wustl.edu,
located at mirrors2/unix-c/editors/uzap.tar-z) to binary edit the
dist.fs at byte offset 946834; it should be changed from 81FE8002
to 81FE7F02. This is the compare for 640K in the bogus code. You
can look for the pattern 81FE8002 in the other *.fs files, including
fixit.fs, and change it there, if you MUST use one of them instead.
The more preffered fix comes from Alan Yang at HP.
For those of you are using HP VECTRA QS/RS model, you probably
have observed the "flashing multi-colored characters and
ptdi81061 prompt" error. The cause for that had been described
in the FAQ posting. The way that you can get around with the
problem is by doing:
1. run setup, and type 'yada' at the Enter option number and
press <ENTER>:prompt
2. select 1 from next menu to turn off the EX_BIOS and
HIL_BIOS.
3. Exit after that.
HP Vectra QS/RS system is using 4k memory for EX_BIOS and HP HIL
bios at the bottom of 640K. By doing the above, you are turning
off the bios and the system gives you back the 4k memory which
allows the 386bsd0.1 to boot and install successfully without
any patches.
Submitted by:
terry_lambert@gateway.novell.com (Terry Lambert)
Solved by:
(same)
ayang@pollux.svale.hp.com (Alan Yang)
========================================
Bug Number: KERN007
Problem:
nroff doesn't work OR
I can't get 386BSD to recognize my #! scripts OR
Even after I change the permissions of a certain program to
no execute, users can still execute it.
Explanation:
/sys/kern/kern_execve.c.c has bugs:
kern_execve.c needs to have modifications to add the #!
checking
This is a big security hole. In 0.0, a VOP_ACCESS was used, but
root always succeeds (and tries to execute anything). But the
check for a single execute bit it wrong too. I put the
VOP_ACCESS back but also checked to make sure at least one
execute bit is on before root can execute the file. I also
checked if the filesystem was mount for execution:
Solution:
*PATCH*
There is a file called kern_shell.0_1 which adds the
#! checking to kern_execve.c.
*PATCH*
There is a file called kern_perms.0_1 which contains
the permission and execute bit fixes.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
tinguely@plains.nodak.edu
Solved by:
pk@cs.few.eur.nl (Paul Kranenburg)
tinguely@plains.nodak.edu
========================================
Bug Number: KERN008
Problem:
As distributed, you can't make a kernel because the makefile
doesn't include vers.c/vers.o.
Explanation:
You need to patch the /sys/i386/conf/Makefile.i386 to
add dependencies and such for vers.o.
Solution:
Chris Demetriou has a patch on agate that fixes the
problem.
*PATCH*
I have made chris's patch available, which is in the Makefile.cgd
directory. There are some more patches in there. Check the
README for more info.
Submitted by:
James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
(same)
cgd@agate.berkeley.edu (Chris G. Demetriou)
========================================
Bug Number: KERN009
Problem:
Kernel panics from using floating point routines at the same
time in two programs. OR
a panic with a description like -
trap type 22 .....
Explanation:
This panic is typical. 22 is T_DNA in <machine/trap.h>. DNA is
for device-not-available which is used to help switch FPU
contexts. It's not supposed to be generated from inside the
kernel, but is (or at least appears to be generated in the
kernel after the kernel screws up trap frame stuff).
It may also show up quickly with one copy and with another
program causing a lot of context switches and/or a lot of
interrupts (run a serial download to get a lot of interrupts).
Solution:
None yet
Submitted by:
bde@runx.oz.au (Bruce Evans)
Solved by:
========================================
Bug Number: KERN010
Problem:
If you set a breakpoint in a program under gdb, the breakpoint
will not be cleared and you will get a trace trap if you
run the program again.
Explanation:
The 386 does not generate a page protection fault while it is
executing in supervisor mode :-(, so copy on write handling
never takes place when the kernel stuffs data into a process's
text- or any other non-anonymous segment. So these cases must be
explicitly checked for.
Solution:
*PATCH*
There is a patch which supposedly fixes this particular
instance of the bug, but is not a complete fix. It is
called gdb_bp.0_1.
Submitted by:
bde@runx.oz.au (Bruce Evans)
Solved by:
pk@cs.few.eur.nl (Paul Kranenburg)
========================================
Bug Number: KERN011
Problem:
Double Density 3.5" floppies do not work correctly.
Explanation:
The code in the fd.c driver does not have an entry for the 3.5"
720K floppy.
Solution:
*PATCH*
There is a file called fd_720.0_1 which contains a patch to
correct this problem.
Submitted by:
rahn@sage.cc.purdue.edu (Dale Rahn)
Solved by:
rahn@sage.cc.purdue.edu (Dale Rahn)
========================================
Bug Number: KERN012
Problem:
The buffer cache has very bad performance. OR
A process can't grow greater than 6MB data/stack.
Explanation:
A good explanation for these is included in the patch.
Solution:
*PATCH*
The is a file called fs_buf.0_1 which contains explanations and
bugfixes for the FS and virtual memory limitations for
386BSD.
Submitted by:
davidg%implode@percy.rain.com (David Greenman)
Solved by:
davidg%implode@percy.rain.com (David Greenman)
========================================
Bug Number: KERN013
Problem:
Kernel panics when reading /dev/drum
Explanation:
There is an improper initialization buffer in the routine
physstrat
Solution:
*PATCH*
There is a file called drum_fix.0_1 which contains a patch
which fixes the /sys/kern/kern__physio.c
Submitted by:
pk@cs.few.eur.nl (Paul Kranenburg)
Solved by:
pk@cs.few.eur.nl (Paul Kranenburg)
========================================
Bug Number: KERN014
Problem:
Machine reboots or crashes when rapidly scrolling backwards.
Explanation:
The problem is caused by sput() in pccons being reentered while
processing escape sequences. Sput(), however, is not reentrant;
in this particular case, the parameter to the scroll down code
was being modified when sput() was reentered resulting in the
kernel being scrolled down (or somewhere). :-(
Solution:
*PATCH*
There is a file called scroll_back.0_1 which fixes pccons.
Submitted by:
fpm@crash.cts.com (Frank MacLachlan)
Solved by:
fpm@crash.cts.com (Frank MacLachlan)
========================================
Bug Number: KERN015
Problem:
DMA handling is incorrect.
Explanation:
At line 389 in isa_dmarangecheck(), the automatic variable
priorpage is used without being initially set to 0. This causes
the function to flag special handling for virtually all DMA
transfer requests. Also, no check is made for DMA requests
crossing DMA page boundaries (64k for DMA chans 0..3, 128k for
DMA chans 4..7). This problem is masked by priorpage not being
initialized - almost all DMA is done to/from safe 'bounce'
buffers which don't cross DMA page boundaries and the data are
block moved from/to the user's buffer.
Solution:
*PATCH*
There is a file called dma_page.0_1 which fixes the dma
code to work correctly.
Submitted by:
fpm@crash.cts.com (Frank MacLachlan)
Solved by:
fpm@crash.cts.com (Frank MacLachlan)
PROGRAM
Bugs in programs distributed with 386BSD.
========================================
Bug Number: PROG001
Problem:
chmod +t or chmod +s do not work. You must use the octal
notation to get those permissions set.
Explanation:
Solution:
/usr/bin/chmod does not have the code for +t or +s, so it should
be trivial to fix this bug.
*PATCH*
A yacc version of chmod was sent to me. If you wish to use it,
it is called yacc_chmod.0_1 It appears to be a fully working
version of chmod, and I have made it my default version.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
deraadt@newt.cuc.ab.ca (Theo Deraadt)
========================================
Bug Number: PROG002
Problem:
diff sometime thinks a text file is a binary file.
Explanation:
Not sure, probably a bug in diff. Diff appears to be a Gnu one,
so getting a newer version may solve the problem.
Solution:
Get a different version of diff.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
========================================
Bug Number: PROG003
Problem:
ln -s foo bar doesn't give an error if bar already exists.
Explanation:
There a bug in ln.
Solution:
None yet.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
========================================
Bug Number: PROG004
Problem:
running rogue will reboot the system.
Explanation:
when rogue updates it's score file, you get a automatic reboot.
No panic, no crash dump, nothing but a reboot.
Solution:
don't play rogue :-(
Submitted by:
bs@germany.eu.net (Bernard Steiner)
Solved by:
========================================
Bug Number: PROG005
Problem:
The stock stty in the bin01 distribution is unable to set the
baud rate correctly.
Explanation:
Solution:
Recompiling stty solves the problem.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
(same)
========================================
Bug Number: PROG006
Problem:
talk does not work, and dies with a "Can't bind socket: Can't
assign requested address"
Explanation:
This can happen when there is no network interface for the IP
address of the machine.
Solution:
Add "127.1 `hostname`" to /etc/hosts if running standalone, or ensure
that the `hostname` entry corresponds with an interface address as
returned by "netstat -i".
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
andrew@werple.pub.uu.oz.au
========================================
Bug Number: PROG007
Problem:
Less will not compile as distributed
Explanation:
It's using the wrong regular expression package
Solution:
It has a define in defines.h to choose the correct
package. You need to define REGCOMP 1.
*PATCH*
There is a patch called less.0_1 which fixes the
define to allow less to compile
Submitted by:
karl@neosoft.com (Karl Lehenbauer)
Solved by:
(same)
========================================
Bug Number: PROG008
Problem:
vi (elvis) doesn't handle yanking and multiple files.
Explanation:
This was the result of three lines near the end of the
tmpabort() function (in tmp.c) that unconditionally closed and
unlinked the temp file. These three lines were not present in
the distribution of elvis 1.5 that I had gotten back in April
(from prep.ai.mit.edu, I believe).
Solution:
*PATCH*
There is a patch file called elvis.0_1 which contains a
snippet of the discussion and a patch which should fix
elvis.
Also, version 1.6 has been released, and is on Simtel20, so
it may be to our advantage to upgrade to the newer release.
Submitted by:
bob%obiwan.UUCP@cs.utexas.edu (Bob Willcox)
Solved by:
bob%obiwan.UUCP@cs.utexas.edu (Bob Willcox)
barnesdo@CS.ColoState.EDU (douglas barnes)
========================================
Bug Number: PROG009
Problem:
ps -u gives me a Floating Point exception OR
The Resident Memory Size (RSS) and %MEM
reported are incorrect OR
ps is *slow*
Explanation:
The kvm library routine has some problems, and ps was
missing a function declaration.
Solution:
*PATCH*
There is a file called kvm_ps.0_1 which contains an
explanation and the fixes to kvm and ps.
Submitted by:
comp.unix.bsd
davidg%implode@percy.rain.com (David Greenman)
Solved by:
davidg%implode@percy.rain.com (David Greenman)
MISC
The catch-all list where I am not sure where to put the bugs.
This list will probably be fragmented into other smaller lists.
========================================
Bug Number: MISC001
Problem:
/dev/stdout does not work. I assume /dev/stdin does not either,
but I don't know how they are set up.
Explanation:
Try doing a make tags in one of the source directories, and the
error: /dev/stdout: Device not configured will occur.
A recent post made notice of that fact the /dev/std* had
a major device of 53. I am not sure what major device these
should be, but I think 53 is probably a little high.
Solution:
None yet.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
========================================
Bug Number: MISC002
Problem:
The man pages for magic and file are incorrect.
Explanation:
The are too many dots before each command, so the dots must be
removed.
Solution:
Remove one of the dots in the magic and file manpages before the
name.
Submitted by:
James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
(same)
========================================
Bug Number: MISC003
Problem:
/usr/libexec/locate.updatedb doesn't work.
Explanation:
In /usr/libexec/locate.updatedb it calls the sort program. The
arguments are "-T /var/tmp" for the temp directory. The sort
program distributed does not have a "-T" option.
Solution:
Remove the "-T /var/tmp" from locate.updatedb
Submitted by:
James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
(same)
========================================
Bug Number: MISC004
Problem:
When linking program FOO, I can't find stty and gtty.
Explanation:
These routines don't *officially* exist in 386BSD. They
are easy to add, though.
Solution:
#define gtty(fd, argp) ioctl(fd, TIOCGETP, argp)
#define stty(fd, argp) ioctl(fd, TIOCSETP, argp)
*PATCH*
There is a patch called gtty_add.0_1 which also contains this
information.
Submitted by:
rivers@ponds.uucp (Thomas David Rivers)
Solved by:
(same)
========================================
Bug Number: MISC005
Problem:
Multiple errors compiling programs with keywords like
TIOCSETP, TIOCGETP, ECHO, RAW, etc ...
Explanation:
386BSD is using the new termio library, instead of the older
ioctl library.
If the program you are compiling is using the ioctl.h
include file, then you need to add another for for 386BSD.
Solution:
Just before your program include <sys/ioctl.h>, include
<sys/ioctl_compat.h>.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
========================================
Bug Number: MISC006
Problem:
mountd hangs when exporting a file system sub-directory
Explanation:
If /etc/exports contained:
/usr/src -root=0
And /usr was not a file system unto itself, mountd went into an
infinite loop and stayed there.
Solution:
The fix: in /usr/src/sbin/mountd/mountd.c, line 592 reads:
while (*cp == '/' && cp > ep->ex_dirp)
and should read:
while (*(cp-1) == '/' && cp > ep->ex_dirp)
Submitted by:
roe@unibase.sk.ca (Roe Peterson)
Solved by:
(same)
========================================
Bug Number: MISC007
Problem:
One needs to type 2 ^V's in screen to get one to show up.
Explanation:
When screen is compiled with POSIX termios, you should disable
ICANON and IEXTEN to get raw mode correctly.
Solution:
In the code that sets the screen to raw mode, add IEXTEN to the
flags to disable.
Submitted by:
sim@cory.berkeley.edu
Solved by:
(same)
========================================
Bug Number: MISC008
Problem:
/usr/include/sys/termios.h doesn't setup it's environment
correctly.
Explanation:
In /usr/include/sys/termios.h, NCCS is only set if _POSIX_SOURCE
is not defined.
Solution:
If you exchange lines 80 and 81, (ie put the line '#define NCCS
20' after the #endif) it works.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
(same)
========================================
Bug Number: MISC009
Problem:
select(2) doesn't work with the com driver. OR
The kernel reports 'com1: silo overflow'
although I am only using com2. OR
X doesn't work correctly with my mouse OR
X is using a lot of resources.
Explanation:
The com driver uses (minor(dev) -1) as the unit number, so
/dev/com1 is COM0 and /dev/com2 is COM1;
However, ttselect() also accesses some structures of the com driver,
but with an index of (minor(dev)). So, select() on /dev/com1
really uses /dev/com2, and select() on /dev/com2 uses an undefined
entry and (usually) returns true.
Solution:
*PATCH*
There is a patch called select.0_1 which is a patch to the
stock 0.1 driver. I believe that Chris Demitrou has also
included this fix into his driver also.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
comp.unix.bsd
Solved by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
========================================
Bug Number: MISC010
Problem:
fread(a,0,1,b) returns zero in old 4.3 and one in 386BSD.
Explanation:
I don't think this is a bug - however, it is inexplicably
different from the usage on the evil old VAX 11/750 running
4.3BSD+SUNNFS (take it from me, very very very old).
Solution:
Use of code: only used in obscure cases (as should be obvious)
to check for EOF condition without having to write a binding for
feof. So, check for the special cases.
Submitted by:
comrade@uniwa.uwa.edu.au (Peter Cooper)
Solved by:
========================================
Bug Number: MISC011
Problem:
Sockets have a real problem with raw mode sockets.
Explanation:
This is actually a 0.0 bug - but it may be worth checking in 0.1.
If you Telnet into 386bsd (using NCSA Telnet from a DOS PC),
login and 'stty sane'. Your session will appear to lockup. It
appears that characters are going from Telnet to 386bsd OK, but
nothing comes back.
Solution:
None yet.
Submitted by:
raz@socs.uts.EDU.AU
Solved by:
========================================
Bug Number: MISC012
Problem:
The library routines toupper and tolower are broken as far as
ANSI is concerned.
Explanation:
The library functions as supplied don't check to see if the
character is lower/upper, and changes it anyway.
Solution:
*PATCH*
There is a patch file available, called lib_toupper.0_1 which
contains a cdiff to correct the problem.
Submitted by:
wiljo@freeside.ki.open.de (Wiljo Heinen)
Solved by:
(same)
========================================
Bug Number: MISC013
Problem:
I can't set up a secondary swap partition on a
different drive. The message is:
/dev/wd1b: device not configured
Explanation:
If the config is setup properly (so that the counts of NWD in
wd.h are appropriate), then config should generate the above itself.
However, config had some bugs in it.
Solution:
*PATCH*
There is a file called config_2drive.0_1 which fixes some errors
that 386BSD has with two drives (and possibly two controllers).
Submitted by:
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
tih@barsoom.nhh.no (Tom Ivar Helbekkmo)
========================================
Bug Number: MISC014
Problem:
386BSD did not recognize my ethernet card (WD8003- EtherCard
PLUS Elite)
Explanation:
/sbin/init was not executable. This caused many reboots with
the message ("init died", "saving RAM..." or such)
After fixing and re-booting, 386BSD no longer knew my EtherCard.
Solution:
boot up DOS , start diagnose program and ... well it said, "LAN
Address ROM" faulty.
run ezsetup, store the configuration (no changes) anew, run
diagnose -> board tests fine, boot 386BSD -> ethernet ok.
Submitted by:
wiljo@freeside.ki.open.de (Wiljo Heinen)
Solved by:
(same)
========================================
Bug Number: MISC015
Problem:
These are less than bugs, but will call them major
annoyances.
1) kernel panics don't allow you to read what happened
2) timezone in the config file is not used
3) date/time bugs
a) GMT must be in CMOS
b) running date doesn't set the CMOS time
c) if daylight savings time is used, must redo CMOS time
4) console message are doubled/tripled
[One duplicate is from syslog telling both /dev/console and
all users logged in as root]
Explanation:
Things are (hopefully) trivial things that need to be fixed.
Solution:
None yet.
Submitted by:
terry@spcvxa.spc.edu (Terry Kennedy)
Solved by:
========================================
Bug Number: MISC016
Problem:
NCSA tn3270 (IBM PC program) can't talk with 386BSD-0.1 via
ethernet
Explanation:
The solution.
Solution:
Recompile telnetd w/o KLUDGELINEMODE
Submitted by:
merlin%neuro.usc.edu@usc.edu (merlin)
Solved by:
(same)
========================================
Bug Number: MISC017
Problem:
when ec0 is ifconfig'd, a bogus 'ecinit' prints on console.
There is a "extra" ecinit in the
Explanation:
A printf statement with "ecinit" was left in the ec driver.
Solution:
Hack 'ecinit' text out of ec.c.
Submitted by:
terry@spcvxa.spc.edu (Terry Kennedy)
Solved by:
terry@spcvxa.spc.edu (Terry Kennedy)
========================================
Bug Number: MISC018
Problem:
The /etc/crontab file doesn't get run. OR
cron doesn't work.
Explanation:
The cron that is supplied with 4.X BSD is Paul Vixie's
cron, which has separate crontab files contained in
/var/cron/tabs/username.
Solution:
Move the /etc/crontab file to /usr/cron/tabs/root, and edit
it to be in the new crontab format.
Submitted by:
jimj@miller.cs.uwm.edu (James Jegers)
Solved by:
jimj@miller.cs.uwm.edu (James Jegers)
========================================
Bug Number: MISC019
Problem:
NFS bugs.
Appending to already existing files.
IBM AIX 3.2 client fixes.
reserved ports for NFS.
Subdirectories can be exported.
Explanation:
In the patch.
Solution:
*PATCH*
There is a file called nfs_misc.0_1 which contains information
and a patch which fixes the above mentioned problems.
Submitted by:
comp.unix.bsd
root@snowhite.cis.uoguelph.ca (gopher I)
Solved by:
comp.unix.bsd
root@snowhite.cis.uoguelph.ca (gopher I)
========================================
Bug Number: MISC020
Problem:
Sometimes a program running in raw mode would 'hang' on a
keypress until a second key was typed.
Explanation:
The RB_LEN() macro in /usr/include/sys/tty.h is sometimes out by
1. In particular, in the case of a buffer containing a single
character at the very end, RB_LEN() would return 0. This caused
ttread() to block until a 2nd character was read before
delivering them both. The user would find RAW mode programs
such as vi would occasionally (1 in 1024 keypresses) get "stuck"
requiring a second keypress to bring it to life.
Solution:
*PATCH*
There is a file called two_keypress.0_1 which fixes the
RB_LEN macro.
Submitted by:
Stephen McKay
Solved by:
Stephen McKay
BIG PATCH
This addition is for patches I didn't know what to do with. I
didn't want to ignore them, but neither did I know where to
file them, so here they are.
========================================
PATCH Number: BIG001
Description:
This set of patches is an attempt to make adding a SCSI disk
safer and easier. There are patches to the scsi code,
disklabel, and the ufs disk code. It's pretty self explanatory,
so have at it.
*PATCH*
In the big directory under the patches, called lotsa_scsi.0_1.
Submitted by:
fty@bizarre.rtpnc.epa.gov (Frank Terhaar-Yonkers)
========================================
PATCH Number: BIG002
Description:
This is a replacement pccons driver that supports all sorts
of good things. Vt100, VGA (only), cheap virtual screen etc.
*PATCH*
big/vga, and everything in it.
Submitted by:
hm@hcshh.hcs.de (hellmuth michaelis)
========================================
PATCH Number: BIG003
Description:
These are the patches to the lpt driver that explain
how to setup up the lpt device, along with the
two patches required to make it work correctly.
*PATCH*
There is a directory in the big directory called
lpt which has instructions and patches
to the lpt.c that is already in 386BSD 0.1.
*NOTE*
It is 'a good thing' to re-compile the lpd daemon,
since it appears that it may not work correctly until
after you recompile it. This is especially important
if you have made any of the 'kvm' patches.
Submitted by:
ejh@slustl.slu.edu (Eric J. Haug)
cflatter@nrao.edu (Chris Flatters)
alm@netcom.com (Andrew Moore)
--
osynw@terra.oscs.montana.edu | A hacker w/out a home.
work: (406) 994-5991 | Keeper of the Unofficial 386BSD Bug Report
home: (406) 586-0579 | Please send bugs and/or fixes you find.