Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!uunet!gatech!concert!rutgers!cmcl2!newsserv.cs.sunysb.edu!stark.UUCP!stark!stark!gene From: stark!gene@newsserv.cs.sunysb.edu (Gene Stark) Newsgroups: comp.os.386bsd.bugs Subject: Re: PROBLEMS WITH FreeBSD Message-ID: <STARK!GENE.93Dec28074153@stark.uucp> Date: 28 Dec 93 12:41:53 GMT References: <CIq8w7.7rM@csi.compuserve.com> Organization: Gene Stark's home system Lines: 111 NNTP-Posting-Host: stark.uucp In-reply-to: mfoley@csi.compuserve.com's message of Tue, 28 Dec 1993 04:09:42 GMT mfoley@csi.compuserv.com (M Foley) writes: > The following are some of the misc. problems I have experienced > installing FreeBSD 1.0e. If anyone has advice or insight, I would > appreciate a mail message as I no long have ready access to these news > groups. > > 2. Why do I have to have a limit on the root file system size? I took the > default which, I believe, turned out to be ~14M. I would have > preferred the entire disk as a single file system. This *feature* has > caused some minor reconfiguration problems. Also, this configuration > does not allow enough root file system space for the /var/crash files. You don't have to have this. It is a good idea to have a small root partition, because this way you can get your system up and running in a usable state more quickly after a crash. When fsck fixes problems on the root partition, it has to reboot. But once this is done, problems can be fixed on the other partitions without rebooting. Maybe the best configuration for you would be a small root partition of about 15-16meg, and the rest of the disk in another partition. Please note that /var/crash can be a link, and you can also change the place where the crash dumps are put by editing /etc/rc. > 3. I modified the kernel as shown in the attached config file. This was to > get the correct timezone, get the proper irq for my ethernet card, and > remove some devices I am not using. This worked OK - except, I got a > "panic: lock_set_recursive: don't have write lock" when doing the make > depend the 1st time. Why? This would seem to indicate serious problems with either your hardware or configuration. You should not get panics like this. > 4. I cannot use the sio devices. I tried, but could not log in to my tty01. > I reran 'MAKEDEV sio0 sio1 sio2 sio3' - didn't help. The ttys and > gettytab files are vanilla - I haven't touched them since the system > install (except that I commented out tty00 - the mouse). When I tried > to cat something to tty01 logged in as root - I was dead. It never came > back. I couldn't ^C out. I had to reset the system. Check your cables. I suspect you do not have properly jumpered cables. The sio drivers require that DCD be asserted before it will allow the device to be opened. You can work around this by: stty -f /dev/sioxx clocal Or, I think that FreeBSD now supports clocal as an option in /etc/ttys, but I'm not absolutely sure. > 5. Before I had the ed0 device configured for my SMC Elite card's irq and > port (i.e. using the original kernel), the probe function (guess) > seemed to modify my card's nvrom irq address. I had it set to 10. After > booting with my new kernel it probed to 2 and once to 9. I had to boot > DOS and run a setup program to get it back to 10. This happens each > time I boot from the generic kernel. The generic kernel undoubtedly has the SMC Elite configured at IRQ 9. It looks like after probing the card and finding it, it sets the IRQ to 9. You will probably need a new kernel to fix this. > 6. When compiling bash, and about 20 times when making a new kernel, the > make stopped with: > > cc: Internal compiler error: program gcc1 got fatal signal 11 > > Restarting the make would resume at the right place and continue for > a few more programs before stopping again. Finally, I disengaged turbo > mode (front panel switch), and the kernel make seemed to proceed without > problems. I have had a number of flakey problems like this (see next item) > which seem to have gone away without turbo. I hope this is not a > permanent problem since I am now running as a 386/16 rather than a 386/25. This is symptomatic of bad external cache hardware. Try disabling your external cache from the BIOS setup screen, and see how many of the above problems go away. If the problems cease, then have a look at the markings on your cache chips to see if they are fast enough. If not, replace them. If so, then you probably have a crummy motherboard, and the only fix would be to get a better one. The only thing that surprises me about this is that you were running 386bsd successfully. It would seem like cache problems would have shown up there. > 7. When doing a "zcat | cpio -o" operation, the system paniced, dumped and > rebooted. Upon reboot I got through the file system checks and then: > > : > Checking for core dump > vm_fault (fe32a900, 1ab2000,1,0) -> 1 > type c, code fe010000 > trap type 12 code=fe010000 eip = fe01aff2 cs=8 eflags = 10282 cr2 1ab2ea6 cpl 0 > panic: trap > Syncing disks ... > > At this point the system was hung. I had to reset. I was about to give > up and reinstall 386bsd when I decided to try taking off the turbo > switch again. That worked. I was also able to complete the cpio > operation. I don't have a generic kernel handy to look at the namelist, but judging from my kernel the eip above is probably in the vnode open routine. The cr2 address of 1ab2ea6 is pretty large, and is not in any kernel text/static data/bss area, so it is either a stray pointer or else is in a kernel dynamically allocated memory area. Again, the above is consistent with the theory that you have bad cache hardware, or possibly that your swap area is misconfigured, so that it overlaps a filesystem or something like that. Check your disklabel carefully. - Gene Stark --