Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!usc!rpi!usenet.coe.montana.edu!warp.mhd.montana.edu!osynw
From: osynw@warp.mhd.montana.edu (Nate Williams)
Subject: Unofficial Bug Report, #2 1/1
Message-ID: <1992Aug13.050945.22291@coe.montana.edu>
Summary: The report!
Keywords: 386BSD bugs
Sender: usenet@coe.montana.edu (USENET News System)
Organization: I as unorganized as they come
Date: Thu, 13 Aug 1992 05:09:45 GMT
Lines: 1309
U N O F F I C I A L 3 8 6 B S D B U G L I S T
--------------------------------------------------------
Date: Aug. 12, 1992
Revision: 0.2
[As this is still in the early stage, suggestions and helpful
criticism is welcome, flames -> /dev/null]
Index:
BOOT and DISKLABEL -
If you machie won't boot, or it will boot buts doesn't
do what it is supposed to, check here
INSTALL and CONFIGURATION -
These are configuration problems that exist after you
have succesfully installed 386BSD 0.1. If a program
won't work, but it seems to run, check here.
KERNEL -
These are REAL (tm) bugs in the operating system, with
unofficial patches. If you are getting kernel panics,
or something in the system doesn't work right, check
here
PROGRAM -
These are bugs in the programs that are distributed
with 386BSD 0.1. It's pretty scarce right now, but
most of these bugs could probably be fixed fairly
easily by non-guru's.
MISC -
Anything else. It will probably be split up as I get
suggestions, and as the list grows.
***READ THIS***
The patches mentioned in this list are currently archived on
plains.nodak.edu ~ftp/pub/386BSD. If Glen has not moved them there yet,
they are in the (unreadable directory) ~ftp/pub/386BSD/.n/patches.tar.Z
I have also uploaded them to agate, ~ftp/pub/incoming/patches.tar.Z.
The file is around 41K compressed.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-
BOOT AND DISKLABEL PROBLEMS
========================================
Bug Number: BOOT001
Problem:
386BSD 0.1 ignores the hard disk geometries given
in the CMOS ram on IDE disks OR
My machine will not boot off an IDE drive. OR
various IDE drive problems
Explanation:
Instead of getting the geometries from CMOS, it (aparently) gets
the geometries direct from the disk itself. This causes problems
when IDE disks are running in translation mode, because the BIOS
is old and doesn't allow customised disk geometries.
Solution:
Use the real parameters of the IDE drive in the CMOS table, and don't
use the translation parameters.
I don't have a source fix, sorry. Only fix then is to upgrade to
a new BIOS, backup your hard disk, customise your CMOS and your
DOS partitions (if needed) to fit in with the correct geometry,
and restore.
Submitted by:
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
(same)
========================================
Bug Number: BOOT002
Problem:
disklabel isn't working correctly.
I can't boot after installing the software OR
I can't disklabel my second drive OR
System wll not recognize second hard drive and/or it crashes
when you try to acces a second drive which is configured but not
connected.
Explanation:
1) Can't boot. /sys/i386/stand/wd.c is checking an invalid
register after resetting the controller. Depending on the
controller, this may or may not hang forever.
2) With partition 3 marked as 00 (unused), I can read from
/dev/rwd1d and do disklabel -r wd1. I get the information from
the first absolute sector of drive 2 in this case.
With partition 3 marked as A5 (386BSD), doing anything with
rwd1d, or disklabel -r wd1, the whole system hangs. The terminal
driver seems to still be working, as characters such as ^V still
work. The system must be reset at this stage.
3) The wd driver has bugs in it.
It will try to open all configured disks at boot time
and print the identification strings.
Solution:
1) Get patched binaries from agate. OR
*PATCH*
There is a file called noboot_wd.0_1 which fixes wd.c
to allow you to boot off the hard-drive.
2) None yet
*PATCH*
3) There is a patch file available, called 2_disk.wd.0_1 which
contains a cdiff which fixes these problems.
Submitted by:
rd@phoenix.aii.com (Bob Thrush)
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
rd@phoenix.aii.com (Bob Thrush)
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
========================================
Bug Number: BOOT003
Problem:
shutdown -todos doesn't work as documented.
Explanation:
The program complains about being unable to make the DOS
partition bootable
Solution:
Boot off a floppy that has fdisk on it and use fdisk to change
the active partition to the DOS one.
No real solution.
Submitted by:
kevinz@storage.tandem.com (Kevin Zeigler)
Solved by:
========================================
Bug Number: BOOT004
Problem:
Bringing the machine into single user mode doesn't work
correctly. OR
After people log out of the machine, who and last show
them as still logged on.
Explanation:
/sbin/init didn't set some internal flags correctly (Reboot, drain)
This caused it to not execute /etc/rc again if the system was
brought down to singleuser and the back up again.
It also tried to start multiuser mode when you tried
hat or reboot in singleuser (when the singleuser shell was terminated
by halt/reboot).
/sbin/init wasn't cleaning up the utmp and wtmp files correctly.
I made a patch that caused normal login/logouts to be updated
correctly, but single user shutdown and reboots still need
some code added.
Solution:
*PATCH*
There is a patch file available, called init.single.0_1 which
contains a cdiff to correct the single user problem.
*PATCH*
There is a patch file available, called init_utmp.0_1 which
contains a cdiff to correct the utmp/wtmp problem.
*NOTE*
Mark Tinguely suggested using the init he posted to the
comp.unix.bsd group a while back, since it doesn't seem to have
the problems the current one does.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
tinguely@plains.nodak.edu (Mark Tinguely)
========================================
Bug Number: BOOT005
Problem:
386BSD does not use the values in the disklabel. It will
use the parameters in the /etc/fstab file.
Explanation:
Even though the label was written that a partition was unused,
the fstab file stated that partition was swap, and starting
writing to that partition.
Solution:
BE CAREFUL!!
Submitted by:
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
(same)
========================================
Bug Number: BOOT006
Problem:
Machine will not boot 386bsd on a warm reboot.
Explanation:
During a warm reboot, in wd.c the machine is picking up the same
memory segment as before and so it appears that the drive is
already open.
Solution:
Bzero out the memory malloced by wdprobe. There are a couple
patches to the wd.c code, and one of them contains the
patch which bzoeros out the memory.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
(same)
========================================
Bug Number: BOOT007
Problem:
WD8013EP ethernet card ('EtherCard Plus Elite 16') only works
after a warm boot.
Explanation:
On the first boot after switching on the workstation,
I only get the well-knownn Reject xxxxx -Messages.
Solution:
None-yet.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
========================================
Bug Number: BOOT008
Problem:
I get the error "isr 15 and error: isr 17" on an NE2000 card, OR
I have some card on IRQ2 and it dosn't work; why?
Explanation:
Some VGA cards use IRQ 2 for a vertical retrace interrupt. Even
when the interrupt is not enabled in the VGA, some cards drive
IRQ 2 inactive instead of leaving the signal tristate.
Solution:
If this is the problem, you can use Scotch tape to cover the IRQ
2 signal on the VGA's ISA connector., or cut the IRQ trace on
your board.
An alternate soloution would be to remove your ethernet card
until you have rebuilt the kernel so that it expects it at an
interrupt other than 2, rejumper it, and reinstall it. This
gets around both the tape and exacto knife soloutions, plus you
don't have to know which pin is IRQ2 (something you need a
techincal reference for the bus to find out).
Submitted by:
The net.
Solved by:
james@bigtex.cactus.org (James Van Artsdalen)
========================================
Bug Number: BOOT009
Problem:
Machine will not boot, have tried everything.
Explanation:
Diskettes used:
dist.fs (Jollitz .01.24), dist.fs, (cgd) fixit.fs (cgd)
Copyright notice appears, disk access light stays on, cursor
blinks, nothing else ever happens. I think I have seen a similar
problem on this group but not the solution. Tried all three
disks, disabled or disconnected all optional hardware, disabled
various CMOS settings. All three disks had exact same problem.
486/33mhz OPTI-486WB with 8MB RAM
OPTI chipset, AMI BIOS (6/6/91)
"Groundhog Graphics" ET4000 SVGA card
Quantum 234mb IDE drive
1.2mb and 1.44mb drives (1.2mb is boot)
All serial and parallel cards removed after initial failure
All "shadow" options disabled in CMOS after initial failure
All caches disabled in CMOS after initial failure
Speed reduced to "16mhz" after additional failures
Solution:
None yet
Submitted by:
barnesdo@cs.colostate.edu (douglas barnes)
Solved by:
========================================
Bug Number: BOOT010
INSTALLATION or CONFIGURATION
Problems that occur after you have installed 386BSD 0.1, or during
installation.
========================================
Bug Number: INST001
Problem:
I can't unpack the etc01 distribution OR
I get the error "too many files open" unpacking the etc01
distribution.
Explanation:
The problem is from cat command leaving the file open after
reading it. Since the default shell only allows 64 files open,
it will not allow you to read more than 64 files.
Solution:
Boot up with the bin01 distribution loaded and login as root.
Next (root uses csh as the default shell), do a
cd /; cat /tmp/etc01.* | zcat | cpio -iadmlu and wait for etc01
to unpack everything where it's supposed to go.
Submitted by:
comp.unix.bsd
Solved by:
(same)
========================================
Bug Number: INST002
Problem:
/usr/bin/tip doesn't work.
Explanation:
tip is setuid "uucp". It wants to create a lock file under
/var/spool/lock, but lock is owned by root and mode 0755. Since
uucp can't create a lock, it dies.
Solution:
There are two solutions to the problem. The first is to make
tip setuid root (chmod 4755 /usr/bin/tip), but that is not the
best solution.
The preferred solution is to change the ownerships on the
/var/spool/lock directory to allow tip to create a lock file. Another
little problem is /var/spool/aculog is written by tip, so uucp
also needs to own that.
I added the /dev/com devices because I wanted to make sure tip
could always connect to them. This may be un-necessary.
Ex:
pc # chown uucp /var/spool/lock /dev/com* /var/spool/aculog
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
The net at large.
========================================
Bug Number: INST003
Problem:
When I run ps, I get an error that it can't find _foo symbols...
ps -u gives me a floating exception
Explanation:
There are not enough symbols in the kernel. First of all, the
kernel supplied with the distribution has been stripped, so
there are no symbols in it. Also, there are some missing
symbols in the symbols.raw file which determines which symbols
will be present in the kernel. Bill Jolitz mentioned this in a
net article, and said the fix for this was in patch1. Patch1
doesn't appear to be coming, but version 0.2 was mentioned
recently.
This problem was because there wasn't a prototype given for
getcpu, so it was returning an int (default) and was causing
a floating point exception.
Solution:
386BSD 0.2 will hopefully have the fix for this. Also, if you
re-compile the kernel, most of the needed symbols will be in the
kernel.
*PATCH*
There is a file called ps_fp.0_1 which fixes the floating point
exception problem.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
386BSD 0.2 (Jolitz, et al)
davidg%implode@agora.rain.com (David Greenman)
========================================
Bug Number: INST004
Problem:
Mtools doesn't work.
Explanation:
Mtools is looking for devices that don't exist in the standard
distribution. You need to create the device special files for
mtools to use.
Solution:
Use MAKEDEV to create the /dev/fd* devices required by mtools.
Ex:
pc # cd /dev
pc # sh MAKEDEV fd0 fd1
pc # dev_mkdb
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
========================================
Bug Number: INST005
Problem:
User's can't create files in their home directories.
Explanation:
As distributed, home directories are owned by root and not by
the user.
Solution:
Ex:
pc # cd /usr/nate
pc # chown nate.staff . .??*
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
========================================
Bug Number: INST006
Problem:
I can't create any new users. I've edited the passwd file, but
the changes don't seem to get added.
Explanation:
386BSD is using a shadow password utility which hides the
encrypted passwords in a separate, root-only readable file
called master.passwd. Also, there are database files created
when you change the master.passwd file, so you need to go
through the supplied "vipw" utility to add users.
Solution:
Use the "/usr/sbin/vipw" program to add users. After you have
added the user(s), you can copy the /usr/share/skel/dot.* files
into their home directory and change the ownerships of the
directory and files to the user.
Ex:
pc # vipw
[Added user foo]
pc # mkdir /usr/foo
pc # cd /usr/foo
pc # cp /usr/share/skel/.??* .
pc # chown foo . .??*
[This assumes you have changed the names of /usr/share/skel/dot.cshrc to
/usr/share/skel/.cshrc. It makes adding users much nicer]
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
The net at large.
========================================
Bug Number: INST007
Problem:
Normal users can't use vi (elvis).
Explanation:
The /tmp and /var/tmp directories have incorrect permissions as
distributed, and elvis can't write a temporary file to them.
Solution:
Change the permissions on those directories. I change them to
everyone read, write, execute, plus the sticky bit so that the
users can't delete other user's files.
Ex:
pc # chmod 1755 /tmp /var/tmp
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
========================================
Bug Number: INST008
Problem:
My computer does not have the correct time that is set in my
BIOS.
Explanation:
386BSD uses a file /etc/localtime which tells it which timezone
you are in. As distributed, it has a symbolic link to
/usr/share/zoneinfo/US/Pacific-New, the correct time for Bill
and Lynne. You need to remove the old /etc/localtime and link it
to the correct time for you area.
Solution:
rm /etc/localtime and make a new symbolic to link to the new
time zone.
Ex:
pc # rm /etc/localtime
pc # date
Wed Jul 29 21:58 GMT 1992
pc # ln -s /usr/share/zoneinfo/US/Mountain /etc/localtime
pc # date
Wed Jul 29 14:59 MDT 1992
pc #
*NOTE*
Some BIOS's automaticaly have Daylight Saving's time set up, so
you have two options.
1) Change the time in your BIOS so that 386BSD will have
the correct time. This is the best option.
2) Hack up on of the datafiles in
/usr/othersrc/share/zoneinfo/datfiles to have the
correct time for your machine.
*ENDNOTE*
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
========================================
Bug Number: INST009
Problem:
man -k doesn't work.
Explanation:
You need to create the whatis.db file. However, there is a ^H in
all the man pages that messes up apropos, with needs to be
stripped out.
Solution:
in /usr/othersrc/share/man/Makefile, add a col -b to strip out
the ^H's from the man pages.
Ex:
makedb:
.
.
done | sort -u > whatis.db
becomes:
done | col -b | sort -u > whatis.db
*PATCH*
There is also a patch file called man_make.0_1 which
contains the fix to the makefile.
Submitted by:
James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
(same)
========================================
Bug Number: INST010
Problem:
Slip is configured and started in my /etc/rc file, but doesn't
seem to work
Explanation:
Somehow slattach is being killed when run from /etc/rc.
Solution:
add a nohup to the slattach command in /etc/rc.
Ex:
nohup slattach /dev/com1 2400
Submitted by:
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
(same)
========================================
Bug Number: INST011
Problem:
I can't get my tape drive to work (SCSI).
Explanation:
The /dev/ras4* device special files are wrong in the
distribution. You need to make new ones using the mknod
command.
Solution:
rm /dev/ras4*, and create new ras4* nodes.
Ex:
pc # cd /dev
pc # rm /dev/ras4*
pc # mknod ras4a c 13 32
pc # mknod ras4d c 13 35
Submitted by:
comp.unix.bsd
Solved by:
wjolitz@soda.berkeley.edu (W. Jolitz)
========================================
Bug Number: INST011
Problem:
There is a serious bug in the bad block handling.
Explanation:
In 0.1, the driver checks the bad block list for every block,
but the test is wrong for reads of multiple blocks - it only
tests if the initial block is on the list. And when the initial
block is on the list, it doesn't split up the i/o, so good
blocks after the bad one are messed up.
Solution:
None yet.
Submitted by:
bde@runx.oz.au (Bruce Evans)
Solved by:
KERNEL
386BSD 0.1 kernel file bugs. (Anything that is below /sys)
[but NOT boot stuff or disklabel]
========================================
Bug Number: KERN001
Problem:
Machine panics with: kmem_malloc: kmem_map too small
Explanation:
There are not enough map entries for computers with >12 MB of
memory.
Solution:
in the file /sys/vm/vm_map.h, there is a:
#define MAX_KMAPENT 500
which needs to be
#define MAX_KMAPENT 1000
*PATCH*
There is also a patch file called kmem_panic.0_1 which
contains the above fix.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
wjolitz@soda.berkeley.edu (W. Jolitz)
========================================
Bug Number: KERN002
Problem:
The following simple program would hang the computer:
#include <stdio.h>
main()
{
char data[8192];
FILE *f;
f = fopen("Test2.file", "w+");
while(1)
{
fread(data, 1, 8192, f);
rewind(f);
fwrite(data, 1, 8192, f);
}
}
Explanation:
There is some sort of bug in the scheduler relating to charging
a process for the CPU while doing heavy disk I/O... If you try
out a similar program which does main(){while(1);} you get the
proper priority of the process as well as proper load averages.
If however you run the above not only does the priority
mechanism fail but I imagine the load average is not correct.
Solution:
None yet. But....
The bug is probably in kern_clock.c or in kern_synch.c ... I
have not tried to investigate this further as it may be a
problem with the system as a whole and not a simple bug. (ie.
relating to the assigned interrupt levels in the kernel...)
Submitted by:
pao@cd.chalmers.se (Andrew Olausson)
Solved by:
========================================
Bug Number: KERN003
Problem:
System hanging under heavy disk activity and high load
Explanation:
Things are getting put to sleep waiting for pages, and
are never being awakened.
This problem was noticed when using DDB. I found that there
were *NO* processes on any of the run queues, and a lot of
processes waiting for disk pages...)
Solution:
None yet.
*NOTE*
Karl Lehenbauer (karl@neosoft.com) made mention of the fact that
in 0.0, the swap partition must be on cylinder boundaries.
The check for this is to run disklabel -r wd0 (as0)
and if there are stars after each partition, the partition
is NOT on a partition boundary. After hearing this, I hand
installed 386BSD, and I have not had any problems with machine
lockups because of heavy cpu/load. (though I have had lockups
for other reasons :-)
dawes@physics.su.oz.au (David Dawes) was having the lockups
on his machine after installing the patches, and after
increasing his swap space and aligning it on cylinder bound-
aries, his lockups went away.
If you can't compile a kernel because of lockups, you may
be able to mount the filesystem to do synchronous writes. This
is very slow, but it *may* help the lockups until you can
compile the fixed kernel.
*ENDNOTE*
*PATCH*
There was mention of this bug in a net article, with a patch by
Bill Jolitz, which may or may not solve this problem. It was
kind of vague, but you may try it. However, in the same
article, Bill did mention that main purpose of version 0.2 was
to fix this bug.
There is a file called heavy_load.0_1 which is the fix that
Bill mentioned in his article.
Submitted by:
cgd@agate.berkeley.edu (Chris G. Demetriou)
Solved by:
wjolitz@soda.berkeley.edu (W. Jolitz)
========================================
Bug Number: KERN004
Problem:
Various machine lockups when doing com stuff.
Explanation:
kermitting through com1, or downloading via zmodem
Occasionally, I get a console message: communication disconnect
and the machine is locked up. No panel lights, no 3-finger
salute. A hard reset was required to bring the machine back to
life.
Other times, kermit was put into a state where a
kill -9 would not even do anything, so a reboot was necessary
to use the modem. The machine was still usable (via screen)
so serial communication was only affected.
Solution:
I suspect the com driver. Maybe replace it with the beta com
driver on agate.berkely.edu by Chris D.
*NOTE*
[I had more problems with Chris's driver than I did with
the stock driver. This may be a single case, but I thought
I would note it. This by no means says that Chris is a bad
programmer or anything, but that I had problems with that
driver]
*ENDNOTE*
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
========================================
Bug Number: KERN005
Problem:
The serial ports don't work at all on my machine.
Explanation:
There is probably a card in you machine that has IRQ 4. Check
out all your cards, and make sure there is nothing that is using
IRQ 4.
Solution:
Change the offending card to NOT use IRQ 4.
Submitted by:
terry_lambert@gateway.novell.com (Terry Lambert)
Solved by:
(same)
========================================
Bug Number: KERN006
Problem:
Flashing multi-colored characters and a ptdi81061 prompt.
Explanation:
The problem is that the code checking the return from the read of
the CMOS RAM value falls through in the case of an invalid value.
What really is needed is the non-existance "else" case for a bad
CMOS setup, which goes and probes memory to see it's size. What
currently happens is that the code falls through, the Maxmem is set
to zero, and the maxmem and physmem are set to -1 (this is a bad
thing).
Solution:
The quick and dirty workaround: If you download dist.fs from
Chris G. Demetriou's upload on agate.berkeley.edu for the hard disk
boot problem (this MUST be dist.fs, and not one of the other dist.fs
files modified for Isolan or WD ethernet and named something else!),
you can use uzap (available for anon ftp from wuarchive.wustl.edu,
located at mirrors2/unix-c/editors/uzap.tar-z) to binary edit the
dist.fs at byte offset 946834; it should be changed from 81FE8002
to 81FE7F02. This is the compare for 640K in the bogus code. You
can look for the pattern 81FE8002 in the other *.fs files, including
fixit.fs, and change it there, if you MUST use one of them instead.
The more preffered fix comes from Alan Yang at HP.
For those of you are using HP VECTRA QS/RS model, you probably
have observed the "flashing multicolored characters and
ptdi81061 prompt" error. The cause for that had been described
in the FAQ posting. The way that you can get around with the
problem is by doing:
1. run setup, and type 'yada' at the Enter option number and
press <ENTER>:prompt
2. select 1 from next menu to turn off the EX_BIOS and
HIL_BIOS.
3. Exit after that.
HP Vectra QS/RS system is using 4k memory for EX_BIOS and HP HIL
bios at the bottom of 640K. By doing the above, you are turning
off the bios and the system gives you back the 4k memory which
allows the 386bsd0.1 to boot and install successfully without
any patches.
Submitted by:
terry_lambert@gateway.novell.com (Terry Lambert)
Solved by:
(same)
ayang@pollux.svale.hp.com (Alan Yang)
========================================
Bug Number: KERN007
Problem:
nroff doesn't work OR
I can't get 386BSD to recognize my #! scripts OR
Even after I change the permissions of a certain program to
no execute, users can still execute it.
Explanation:
/sys/kern/kernexecve.c has bugs:
kern_execve.c needs to have modifications to add the #!
checking
This is a big security hole. In 0.0, a VOP_ACCESS was used, but
root always succeeds (and tries to execute anything). But the
check for a single execute bit it wrong too. I put the
VOP_ACCESS back but also checked to make sure at least one
execute bit is on before root can execute the file. I also
checked if the filesystem was mount for execution:
Solution:
*PATCH*
There is a file called kern_shell.0_1 which adds the
#! checking to kern_execve.c.
*PATCH*
There is a file called kern_perms.0_1 which contains
the permission and execute bit fixes.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
tinguely@plains.nodak.edu
Solved by:
??@*.eur.nl [If you wrote this, let me know]
tinguely@plains.nodak.edu
========================================
Bug Number: KERN008
Problem:
As distributed, you can't make a kernel because the makefile
doesn't include vers.c/vers.o.
Explanation:
You need to patch the /sys/i386/conf/Makefile.i386 to
add dependcies and such for vers.o.
Solution:
Chris Demetriou has a patch on agate that fixes the
problem.
*PATCH*
I have made chris's patch available, which is in the Makefile.cgd
directory. There are some more patches in there. Check the
README for more info.
Submitted by:
James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
(same)
cgd@agate.berkeley.edu (Chris G. Demetriou)
========================================
Bug Number: KERN009
Problem:
Slip is configured and started in my /etc/rc file, but doesn't
seem to work
Explanation:
Somehow slattach is being killed when run from /etc/rc.
Solution:
add a nohup to the slattach command in /etc/rc.
Ex:
nohup slattach /dev/com1 2400
Submitted by:
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
(same)
========================================
Bug Number: KERN010
Problem:
Kernel panics from using floating point routines at the same
time in two programs. OR
a panic with a description like -
trap type 22 .....
Explanation:
This panic is typical. 22 is T_DNA in <machine/trap.h>. DNA is
for device-not-available which is used to help switch FPU
contexts. It's not supposed to be generated from inside the
kernel, but is (or at least appears to be generated in the
kernel after the kernel screws up trap frame stuff).
It may also show up quickly with one copy and with another
program causing a lot of context switches and/or a lot of
interrupts (run a serial download to get a lot of interrupts).
Solution:
None yet
Submitted by:
bed@runx.oz.au (Bruce Evans)
Solved by:
PROGRAM
Bugs in programs distributed with 386BSD.
========================================
Bug Number: PROG001
Problem:
chmod +t or chmod +s do not work. You must use the octal
notation to get those permissions set.
Explanation:
Solution:
/usr/bin/chmod does not have the code for +t or +s, so it should
be trivial to fix this bug.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
========================================
Bug Number: PROG002
Problem:
diff sometime thinks a text file is a binary file.
Explanation:
Not sure, probably a bug in diff. Diff appears to be a Gnu one,
so getting a newer version may solve the problem.
Solution:
Get a different version of diff.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
========================================
Bug Number: PROG003
Problem:
ln -s foo bar doesn't give an error if bar already exists.
Explanation:
There a bug in ln.
Solution:
None yet.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
========================================
Bug Number: PROG004
Problem:
running rogue will reboot the system.
Explanation:
when rogue updates it's score file, you get a automatic reboot.
No panic, no crash dump, nothing but a reboot.
Solution:
don't play rogue :-(
Submitted by:
bs@germany.eu.net (Bernard Steiner)
Solved by:
========================================
Bug Number: PROG005
Problem:
The stock stty in the bin01 distribution is unable to set the
baud rate correctly.
Explanation:
Solution:
Recompiling stty solves the problem.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
(same)
========================================
Bug Number: PROG006
Problem:
talk does not work, and dies with a "Can't bind socket: Can't
assign requested address"
Explanation:
I think talk is doing something it shouldn't because screen
seems to work fine with sockets.
Solution:
None yet.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
========================================
Bug Number: PROG007
Problem:
Less will not compile as distributed
Explanation:
It's using the wrong regular expression package
Solution:
It has a define in defines.h to choose the correct
package. You need to define REGCOMP 1.
*PATCH*
There is a patch called less.0_1 which fixes the
define to allow less to compile
Submitted by:
karl@neosoft.com (Karl Lehenbauer)
Solved by:
(same)
MISC
The catch-all list where I am not sure where to put the bugs.
This list will probably be fragmented into other smaller lists.
========================================
Bug Number: MISC001
Problem:
/dev/stdout does not work. I assume /dev/stdin does not either,
but I don't know how they are set up.
Explanation:
Try doing a make tags in one of the source directories, and the
error: /dev/stdout: Device not configured will occur.
A recent post made notice of that fact the /dev/std* had
a major device of 53. I am not sure what major device these
should be, but I think 53 is probably a little high.
Solution:
None yet.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
========================================
Bug Number: MISC002
Problem:
The man pages for magic and file are incorrect.
Explanation:
The are too many dots before each command, so the dots must be
removed.
Solution:
Remove one of the dots in the magic and file manpages before the
name.
Submitted by:
James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
(same)
========================================
Bug Number: MISC003
Problem:
/usr/libexec/locate.updatedb doesn't work.
Explanation:
In /usr/libexec/locate.updatedb it calls the sort program. The
arguements are "-T /var/tmp" for the temp directory. The sort
program distributed does not have a "-T" option.
Solution:
Remove the "-T /var/tmp" from locate.updatedb
Submitted by:
James Jegers <jimj@miller.cs.uwm.edu>
Solved by:
(same)
========================================
Bug Number: MISC004
Problem:
When linking program FOO, I can't find stty and gtty.
Explanation:
These routines don't *officially* exist in 386BSD. They
are easy to add, though.
Solution:
#define gtty(fd, argp) ioctl(fd, TIOCGETP, argp)
#define stty(fd, argp) ioctl(fd, TIOCSETP, argp)
There is a patch called gtty_add.0_1 which also contains this
information.
Submitted by:
rivers@ponds.uucp (Thomas David Rivers)
Solved by:
(same)
========================================
Bug Number: MISC005
Problem:
Multiple errors compiling programs with keywords like
TIOCSETP, TIOCGETP, ECHO, RAW, etc ...
Explanation:
386BSD is using the new termio library, instead of the older
ioctl library.
If the program you are compiling is using the ioctl.h
include file, then you need to add another for for 386BSD.
Solution:
Just before your program include <sys/ioctl.h>, include
<sys/ioctl_compat.h>.
Submitted by:
osynw@terra.oscs.montana.edu (Nate Williams)
Solved by:
(same)
========================================
Bug Number: MISC006
Problem:
Slip is configured and started in my /etc/rc file, but doesn't
seem to work
Explanation:
Somehow slattach is being killed when run from /etc/rc.
Solution:
add a nohup to the slattach command in /etc/rc.
Ex:
nohup slattach /dev/com1 2400
Submitted by:
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
(same)
========================================
Bug Number: MISC007
Problem:
mountd hangs when exporting a file system sub-directory
Explanation:
If /etc/exports contained:
/usr/src -root=0
And /usr was not a file system unto itself, mountd went into an
infinite loop and stayed there.
Solution:
The fix: in /usr/src/sbin/mountd/mountd.c, line 592 reads:
while (*cp == '/' && cp > ep->ex_dirp)
and should read:
while (*(cp-1) == '/' && cp > ep->ex_dirp)
Submitted by:
roe@unibase.sk.ca (Roe Peterson)
Solved by:
(same)
========================================
Bug Number: MISC008
Problem:
One needs to type 2 ^V's in screen to get one to show up.
Explanation:
When screen is compiled with POSIX termios, you should disable
ICANON and IEXTEN to get raw mode correctly.
Solution:
In the code that sets the screen to raw mode, add IEXTEN to the
flags to disable.
Submitted by:
sim@cory.berkeley.edu
Solved by:
(same)
========================================
Bug Number: MISC009
Problem:
/usr/include/sys/termios.h doesn't setup it's environment
correctly.
Explanation:
In /usr/include/sys/termios.h, NCCS is only set if _POSIX_SOURCE
is not defined.
Solution:
If you exchange lines 80 and 81, (ie put the line '#define NCCS
20' after the #endif) it works.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
(same)
========================================
Bug Number: MISC010
Problem:
select(2) doesn't work with the com driver.
Explanation:
It always says there is something to read when there isn't.
I tried it with the stock com driver and with Chris Demetriou's .
Solution:
None yet.
Submitted by:
chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Solved by:
========================================
Bug Number: MISC011
Problem:
fread(a,0,1,b) returns zero in old 4.3 and one in 386BSD.
Explanation:
I don't think this is a bug - however, it is inexplicably
different from the usage on the evil old VAX 11/750 running
4.3BSD+SUNNFS (take it from me, very very very old).
Solution:
Use of code: only used in obscure cases (as should be obvious)
to check for EOF condition without having to write a binding for
feof. So, check for the special cases.
Submitted by:
comrade@uniwa.uwa.edu.au (Peter Cooper)
Solved by:
========================================
Bug Number: MISC012
Problem:
Sockets have a real problem with raw mode sockets.
Explanation:
This is actually a 0.0 bug - but it may be worth checking in 0.1.
If you Telnet into 386bsd (using NCSA Telnet from a DOS PC),
login and 'stty sane'. Your session will appear to lockup. It
appears that characters are going from Telnet to 386bsd OK, but
nothing comes back.
Solution:
None yet.
Submitted by:
raz@socs.uts.EDU.AU
Solved by:
========================================
Bug Number: MISC013
Problem:
The library routines toupper and tolower are broken as far as
ANSI is concerned.
Explanation:
The library functions as supplied don't check to see if the
character is lower/upper, and changes it anyway.
Solution:
*PATCH*
There is a patch file available, called lib_toupper.0_1 which
contains a cdiff to correct the problem.
Submitted by:
wiljo@freeside.ki.open.de (Wiljo Heinen)
Solved by:
(same)
========================================
Bug Number: MISC014
Problem:
I can't set up a secondary swap partition on a
different drive. The message is:
/dev/wd1b: device not configured
Explanation:
If the config is setup properly (so that the counts of NWD in
wd.h are appropriate), then config should gen the above itsself.
However, config had some bugs in it.
Solution:
*PATCH*
There is a file called config_2drive.0_1 which fixes some errors
that 386BSD has with two drives (and possibly two controllers).
Submitted by:
wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Solved by:
tih@barsoom.nhh.no (Tom Ivar Helbekkmo)
========================================
Bug Number: MISC015
Problem:
386BSD did not recognize my ethernet card (WD8003- EtherCard
PLUS Elite)
Explanation:
/sbin/init was not executable. This caused many reboots with
the message ("init died", "saving RAM..." or such)
After fixing and re-booting, 386BSD no longer knew my EtherCard.
Solution:
boot up DOS , start diagnose program and ... well it said, "LAN
Adress ROM" faulty.
run ezsetup, store the configuration (no changes) anew, run
diagnose -> board tests fine, boot 386BSD -> ethernet ok.
Submitted by:
wiljo@freeside.ki.open.de (Wiljo Heinen)
Solved by:
(same)
========================================
Bug Number: MISC016
Problem:
These are less than bugs, but will call them major
annoyances.
1) kernel panics don't allow you to read what happened
2) timezone in the config file is not used
3) date/time bugs
a) GMT must be in CMOS
b) running date doesn't set the CMOS time
c) if daylight savings time is used, must redo CMOS time
4) console message are doubled/tripled
[One duplicate is from sylog telling both /dev/console and
all users logged in as root]
Explanation:
Things are (hopefully) trivial things that need to be fixed.
Solution:
None yet.
Submitted by:
terry@spcvxa.spc.edu (Terry Kennedy)
Solved by:
========================================
Bug Number: MISC017
Problem:
NCSA tn3270 (IBM PC program) can't talk with 386BSD-0.1 via
ethernet
Explanation:
The solution.
Solution:
Recompile telnetd w/o KLUDGELINEMODE
Submitted by:
merlin%neuro.usc.edu@usc.edu (merlin)
Solved by:
(same)
========================================
Bug Number: MISC018
Problem:
There are several bugs in the kernel namelist db creation/use
and bugs in kvm.c which causes ps and several other utils to
fail to work correctly.
Explanation:
It's a bug!
Solution:
There is a patch file called kvm_util.0_1 which contains
fixes for the kvm.c library routine and the kvm_mkdb
system program.
Submitted by:
Solved by:
(same)
--
osynw@terra.oscs.montana.edu | A hacker w/out a home. Anyone interested
work: (406) 994-5991 | in a used Sys. Admin., with alot of
home: (406) 586-0579 | good hacks left?