From comp.unix.bsd Sun Aug 9 17:00:28 1992 Path: hcshh!unido!Germany.EU.net!news.netmbx.de!zrz.tu-berlin.de!math.fu-berlin.de!Sirius.dfn.de!darwin.sura.net!wupost!sdd.hp.com!uakari.primate.wisc.edu!usenet.coe.montana.edu!warp.mhd.montana.edu!osynw From: osynw@warp.mhd.montana.edu (Nate Williams) Newsgroups: comp.unix.bsd Subject: First posting of the 386BSD 0.1 unofficial bug-list 1/1 Keywords: info and stuff Message-ID: <1992Aug7.235255.3116@coe.montana.edu> Date: 7 Aug 92 23:52:55 GMT Sender: usenet@coe.montana.edu (USENET News System) Organization: Bugs 'R Us Lines: 1052 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. 7, 1992 Revision: 0.1 [As this is the very first attempt at this, and my first attempt at trying to organize something like this, 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. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=- BOOT AND DISKLABEL PROBLEMS ======================================== 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) ======================================== 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) ======================================== 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: ======================================== 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) ======================================== 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) ======================================== 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) ======================================== 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: ======================================== 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) INSTALLATION or CONFIGURATION Problems that occur after you have installed 386BSD 0.1, or during installation. ======================================== 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) ======================================== 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. ======================================== 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. 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. Also, a recent post to comp.unix.bsd stated that the floating point libraries have problems with precision, and when ps was linked with a different set of libraries, the floating point exception went away. Solution: 386BSD 0.2 will hopefully have the fix for this. Submitted by: osynw@terra.oscs.montana.edu (Nate Williams) Solved by: 386BSD 0.2 (Jolitz, et al) ======================================== 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) ======================================== 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) ======================================== 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. ======================================== 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) ======================================== 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) ======================================== 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 Solved by: (same) ======================================== 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) ======================================== 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) KERNEL 386BSD 0.1 kernel file bugs. (Anything that is below /sys) [but NOT boot stuff or disklabel] ======================================== 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) ======================================== 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: ======================================== 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 the 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 :-) *ENDNOTE* There was mention of this 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. *PATCH* There is a file called heavy_load.0_1 which is the fix that Bill mentioned in a net article. Submitted by: cgd@agate.berkeley.edu (Chris G. Demetriou) Solved by: wjolitz@soda.berkeley.edu (W. Jolitz) ======================================== 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: ======================================== 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) ======================================== 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 :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) ======================================== 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_kernexec.c has bugs: kern_kern_exec.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 ======================================== 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 Solved by: (same) cgd@agate.berkeley.edu (Chris G. Demetriou) ======================================== 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) PROGRAM Bugs in programs distributed with 386BSD. ======================================== 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: ======================================== 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: ======================================== 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: ======================================== 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: ======================================== 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) ======================================== 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: 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. ======================================== 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: ======================================== 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) ======================================== 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 Solved by: (same) ======================================== 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) ======================================== 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) ======================================== 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) ======================================== 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) ======================================== 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) ======================================== 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) ======================================== 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: ======================================== 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: ======================================== 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: ======================================== 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) -- 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?