From comp.unix.bsd Sun Nov 1 13:03:22 1992 Path: hcshh!Germany.EU.net!mcsun!uunet!olivea!decwrl!usenet.coe.montana.edu!nate.oscs.montana.edu!root From: root@nate.oscs.montana.edu (Superuser) Newsgroups: comp.unix.bsd Subject: 386BSD 0.1 *Unofficial* Bug Report Summary: Still needs work Message-ID: <1992Nov1.004059.19331@coe.montana.edu> Date: 1 Nov 92 00:40:59 GMT Sender: usenet@coe.montana.edu (USENET News System) Organization: None Lines: 1904 U N O F F I C I A L 3 8 6 B S D B U G L I S T -------------------------------------------------------- ~Date: Oct. 31, 1992 - Scary Bugs for Halloween :-) Revision: 0.9 [If you have any suggestions, additions, format changes, etc... please send me mail, I'm open to suggestions] Administration stuff - Where to get patches: I am now following Terry Lambert's patchkit. To get the patchkit, ftp to agate.berkeley.edu, and it is located in pub/386BSD/386bsd-0.1/unofficial/patchkit directory. I recommend you install all of the patches recommended by Terry in the patchkit (some of them should not be installed per the patch kit instructions for certain hardware) - How to submit bug reports, or submit patches. Mail to osynw@terra.oscs.montana.edu with a subject line of "386BSD BUGS". To help aid me in getting these reports out quickly, if you follow the report I have below, it makes my life *much* easier. -------------------------Bug Report Format-------------------------- Name: Email address: ~Date: Hardware info: [Whatever you think is necessary for creating the problem CPU, BIOS, Chipset, Memory, cards, disk, .... If the problem is independent of hardware, don't bother] Problem description: [As much info as you can give, how to re-produce, etc..] Problem suspicions: [What/where you think the problem is if you don't have a fix, if you have an idea but can't follow up on it] Solution: [A patch, or an explanation of how to solve the problem] -------------------------Bug Report Format-------------------------- - Future direction o Incorporating Terry Lambert's patchkit format - This way you want have my hodge-podge of patches in scattered format to worry about. Terry's software takes care of dependent patches, applying patches out of order, etc. o 'Blessing' certain patched version as acceptable and functional. There are some 'competing' patches floating around, and I wish to make an 'official' unofficial version. o Supplying a generic kernel that has all of the accepted patches applied to it. Some of the patches supplied are not patches as much as hacks, and if these hacks aren't necessary for running the system, I don't want to include them. o Adding more software kits like the VGA pccons driver, the new SCSI drivers, etc.. to the list. Hopefully, this will make getting this software easier for new users, as it will be archived along with the bug report o anything else that I can think of that takes up time I don't have. ;-) -----------------------------THE REPORT----------------------------- 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. Use the entire disk for 386BSD. 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. *NOTE* There has been a LOT of traffic on how to 'fix' this bug, so hopefully something acceptable will be given as a solution to this problem 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 2) PATCH00049 3) PATCH00021 Submitted by: wkt@csadfa.cs.adfa.oz.au (Warren Toomey) rd@phoenix.aii.com (Bob Thrush) 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: PATCH00022 PATCH00023 PATCH00014 *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: PATCH00021 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! The keyboard delay routine doesn't seem to work correctly on all keyboards. HACK-PATCH PATCH00055 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 . 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. The kernel supplied with the distribution has been stripped, so there are no symbols in it. See the PROG009 entry. Solution: 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: There have been a couple add_users scripts posted to the newsgroup. Hopefully, they should be archived somewhere. 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 # For the DST code in the kernel. PATCH00044 -NOTE- Some BIOS's automatically have Daylight Savings time set up, so you have two options. 1) Change the time in your BIOS so that 386BSD will have the correct time. However, your clock will be an hour off if you run DOS also. 2) Patch the kernel code to read the DST value out of the BIOS. This works well, and I recommend it. -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 PATCH00026 Submitted by: James Jegers Solved by: (same) ======================================== Bug Number: INST010 Problem: Slip is configured and started in my /etc/rc file, but doesn't seem to work. OR Slip hangs after I get a number of com#: silo overflow errors. Explanation: Somehow slattach is being killed when run from /etc/rc. The slip interface was ignoring the notice from the tty driver on any problems (parity, framing errors, overruns). Solution: add a nohup to the slattach command in /etc/rc. Ex: nohup slattach /dev/com1 2400 To fix slip from hanging. PATCH00019 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 Better solution: Use Julian Elischer's (julian@tfs.com) new scsi drivers. They work very well, and support for other SCSI adaptors is in the works. Submitted by: comp.unix.bsd Solved by: wjolitz@soda.berkeley.edu (W. Jolitz) julian@tfs.com (Julian Elischer) ======================================== 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. PATCH00004 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: 1) PATCH00002 2) Hack the as driver to retry and get the block size when it is way out of line. Or use the new scsi drivers from Julian Elischer. 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) julian@tfs.com (Julian Elischer) ======================================== Bug Number: KERN002 Problem: The following simple program would hang the computer: #include 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...) Lynne Jolitz writes: It most likely you have too little memory and it's paging itself into a deficit. The current page replacement algorithm isn't up to the task for systems with 4 MB RAM or less. The page replacement algorithm is being reworked (it's horrible) to operate correctly, but it's slow going. 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. PATCH00002 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. I believe this has to do with the spl() handling in com.c. Submitted by: osynw@terra.oscs.montana.edu (Nate Williams) Solved by: cgd@agate.berkeley.edu ======================================== 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 :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. Also, Terry Lambert has made a patch to allow to CMOS size to be different than expected. PATCH00003 Submitted by: terry_lambert@gateway.novell.com (Terry Lambert) Solved by: (same) ayang@pollux.svale.hp.com (Alan Yang) terry_lambert@gateway.novell.com (Terry Lambert) ======================================== 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: PATCH00025 PATCH00024 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: PATCH00001 Submitted by: James Jegers Solved by: (same) cgd@agate.berkeley.edu (Chris G. Demetriou) ======================================== Bug Number: KERN009 Problem: Incorrect results from using floating point calculations on non-FP machines OR 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: There are errors in the FP emulation code. This panic is typical. 22 is T_DNA in . 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: PATCH00046 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: PATCH00011 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. Explanation: A good explanation for these is included in the patch. Solution: PATCH00007 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: PATCH00033 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: PATCH000010 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: PATCH000017 Submitted by: fpm@crash.cts.com (Frank MacLachlan) Solved by: fpm@crash.cts.com (Frank MacLachlan) ======================================== Bug Number: KERN016 Problem: Using the chroot system call causes a reboot. Explanation: Because the process root is _above_ the process cwd. Solution: PATCH00006 Submitted by: bs@Germany.EU.net (Bernard Steiner) Solved by: chmr@edvz.tu-graz.ac.at (Christoph M. Robitschko) ======================================== Bug Number: KERN016 Problem: The kernel doesn't allocate the amount of buffers it claims to. Explanation: The code in i386/i386/machdep does not do what its comments claim it to do. Solution: *PATCH* There is a patch called buf_alloc.0_1 which contains a fix to allocate the 'correct' amount of buffers. Submitted by: tih@barsoom.nhh.no (Tom Ivar Helbekkmo) Solved by: tih@barsoom.nhh.no (Tom Ivar Helbekkmo) ======================================== Bug Number: KERN017 Problem: There is a bug in the mbuf allocation code which may result in occasional hangs or panics. Explanation: While the flags in sys/mbuf.h define M_DONTWAIT and M_WAIT in terms of M_NOWAIT and M_WAITOK, these flags are only used for the kernel malloc. But the actual code in kern/uipc_mbuf.h uses kmem_malloc, which has only a parameter canwait. To stick with Murphy's law :-) this parameter has just the opposite meaning from the flag values above. Solution: PATCH00009 Submitted by: ws@tools.de (Wolfgang Solfrank) Solved by: ws@tools.de (Wolfgang Solfrank) ======================================== Bug Number: KERN018 Problem: I can't get my NE1000 ethernet card to work. Explanation: 386BSD sees my card on bootup, but reports the wrong address. Solution: The unofficial (though correct) fix to this is to change the definition of the "boarddata" variable. It currently reads static u_short boarddata[16]; and it should read static u_char boarddata[16]; Submitted by: pnutty@nutt.demon.co.uk (Peter C Allnutt) Solved by: scott@clmqt.marquette.MI.US (Scott Reynolds) ======================================== Bug Number: KERN019 Problem: The interface between the com drivers and slip interface needs some cleanup. OR slip doesn't work consistently. Explanation: The slip interface will disregard any notice from the tty-driver about errors it receives from the com driver. Solution: PATCH00019 Submitted by: phk@data.fls.dk (Poul-Henning Kamp) Solved by: phk@data.fls.dk (Poul-Henning Kamp) ======================================== Bug Number: KERN020 Problem: I/O errors are not reported when reading/writing to/from the raw disk disk device. Explanation: The wd driver, '/sys/i386/isa/wd.c', sets the B_ERROR bit in bp->b_flags at lines 533 and 553, but fails to put an error code into bp->b_error. Physio() in '/sys/kern/kern__physio.c', which manages the raw I/O in this case, ignores the B_ERROR bit in b_flags and looks for an error code in b_error. The user program is fed garbage data and has no clue that an error occurred. Solution: PATCH00038 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: PATCH00056 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: PATCH00041 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: PATCH00032 PATCH00036 PATCH00051 PATCH00052 Submitted by: comp.unix.bsd davidg%implode@percy.rain.com (David Greenman) Solved by: pk@cs.few.eur.nl (Paul Kranenburg) davidg%implode@percy.rain.com (David Greenman) ======================================== Bug Number: PROG010 Problem: cpio doesn't work with symlinks with the combination of certain switches ("-pdl" is one) Explanation: Guy Harris made some symlink changes while at Sun, and the net-2 version also had these changes, which had a bug in it. Solution: PATCH00048 Submitted by: comp.unix.bsd Solved by: guy@auspex.com (Guy Harris) ======================================== Bug Number: PROG010 Problem: If make is called with an arguement of a lone dash (-), it will loop indefinitely. Explanation: getopt is re-examining the - arguement over and over. Solution: PATCH00015 Submitted by: jfw@eddie.mit.edu (John Woods) Solved by: jfw@eddie.mit.edu (John Woods) ======================================== Bug Number: PROG011 Problem: Man doesn't work correctly when you add entries to /etc/man.conf Explanation: Description: In the function config.c:cadd() the pointer bp isn't recalculated when the pathbuf needs to be realloced. If realloc moves the storage 'bp' is left hanging. The bug manifests itself when you modify man.conf such that the pathbuf expands beyond 1k. Solution: PATCH00008 Submitted by: jdolter@sawtooth.eecs.umich.edu (James Dolter) Solved by: jdolter@sawtooth.eecs.umich.edu (James Dolter) ======================================== Bug Number: PROG012 Problem: If I do a 'pwd', my directory goes away. Explanation: This problem only occurs in /bin/sh. Avoid longjump'ing out of the routine `getpwd()' in src/bin/sh/cd.c (in case an error occurs). Solution: PATCH00050 Submitted by: comp.unix.bsd Solved by: pk@cs.few.eur.nl (Paul Kranenburg) ======================================== Bug Number: PROG012 Problem: the 'whatis' program would occasionally core-dump, depending on initial conditions. Explanation: There were two uninitialized pointers. Solution: PATCH00005 Submitted by: alm@netcom.com (Andrew Moore) Solved by: alm@netcom.com (Andrew Moore) 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 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 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 , include . 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) PATCH00054 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: PATCH00018 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: PATCH00027 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: PATCH00021 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: Use the /usr/bin/crontab command to add new entries to /var/cron/tabs/root using the /etc/crontab file as a template. Submitted by: jimj@miller.cs.uwm.edu (James Jegers) Solved by: jimj@miller.cs.uwm.edu (James Jegers) vixie@pa.dec.com (Paul A Vixie) ======================================== Bug Number: MISC019 Problem: NFS bugs. Appending to already existing files. Read request hangs. IBM AIX 3.2 client fixes. reserved ports for NFS. Subdirectories can be exported. Explanation: In the patch. Solution: PATCH00016 PATCH00042 PATCH00053 Submitted by: comp.unix.bsd root@snowhite.cis.uoguelph.ca (gopher I) Solved by: comp.unix.bsd arnej@Lise.Unit.NO (Arne Henrik Juul) martin@innovis.com (Martin Galassi) 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: PATCH00012 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) ======================================== PATCH Number: BIG004 Description: This is the alternate scsi code. I have taken the liberty of unsharing the files, and making compressed tar files out of the sources. This code is more generic, and will make it easier for new drivers to be added. *PATCH* The file big/new_scsi/scsi_boot.tar.Z contains the new boot blocks, to be untarred in the /sys directory. The file big/new_scsi/scsi_drive.tar.Z contains the new scsi code, to be untarred in the /sys directory also. There are README's in each of the tar files. They will give you instructions as to how to install the drivers. Submitted by: julian@tfs.com (Julian Elischer)