home *** CD-ROM | disk | FTP | other *** search
Text File | 1992-08-12 | 38.6 KB | 1,322 lines |
- Newsgroups: comp.unix.bsd
- Path: sparky!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?
-