Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!uunet!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news.mit.edu!raeburn From: raeburn@cambridge.cygnus.com (Ken Raeburn) Subject: problems bringing up 386BSD 0.1 Message-ID: <RAEBURN.92Jul17141049@cambridge.cygnus.com> Sender: news@athena.mit.edu (News system) Nntp-Posting-Host: cambridge.cygnus.com Organization: Cygnus Support, Cambridge MA Date: Fri, 17 Jul 1992 18:10:57 GMT Lines: 80 I've run into a number of problems bringing up 0.1 on my PC. Installation problems: After trying several times, I gave up on trying to get DOS and 386BSD to coexist. When I would boot 386BSD, it would tell me that the disk had no disk label, even after I'd finished editing it for more reasonable values than the "install" script set up. The default seems to be to set up one huge "a" partition, rather than the root/usr split that is fairly common, and no separate swap partition. Is all of this intentional? Should I have reserved some space so I can go set up a swap partition later, or has facility for swapping to files been added? (I intend to be doing some GNU software hacking, especially gcc, and using X, so I will definitely need more virtual memory than my 16M physical...) The "install.bin01" script is missing a space before a "]", causing a "[" test to fail. Network problems: Lots of "arst" characters in various patterns (usually "startart") got printed when I used the NE driver in the "Tiny" kernel. I didn't see any of this in the kernel sources, and when I rebuilt a kernel, this problem went away. Using ftp to copy something from a remote machine to local disk is very slow. Local disk-to-disk copy is fast, ftp into /dev/null is fast; it's only ftp to local disk that loses, perhaps pointing to some interaction between the network and file system (or the respective devices or drivers). I'm using an NE2000 card configured for IRQ 9, which is what the Tiny kernel seemed to default to. (Under 0.0, I used it at IRQ 3; the performance was fine, and I didn't have the second COM line configured.) I have successfully mounted and listed file systems from our Suns here at work. But NFS doesn't seem to recognize the responses to "read" requests. Using "nfsstat" on the Suns indicate that valid read requests are coming through; "nfsstat" on the PC indicates that it keeps retrying, and it eventually reports a timeout. There is no "netstat" on the PC, so I can't check for lower-level errors. (One Sun I tried it with has UDP checksums turned on, the other does not; 386BSD couldn't get data from either of them. My test was "file foo", where foo was some executable.) (These last two were with the rebuilt kernel; the Tiny one spit out too much garbage during network I/O to be really useable.) Kernel source problems: One of the more serious problems is that the kernel I've rebuilt from sources, as well as the Tiny kernel, seems to have some trouble reading some of the files on the disk. For example, /usr/libexec/cpp has the wrong `sum' value, and crashes when I run it. I had a similar problem under 0.0 also, but haven't taken enough time yet to determine whether it's actually the same problem now. (The disk is a Seagate 1239A -- IDE? 200 meg.) Do the sys.386bsd sources and GENERICISA config file exactly correspond to the Tiny kernel? Miscellaneous remarks: "man -k" doesn't work because there's no whatis database, and there's no makewhatis or catman for me to build it with. "netstat" and "pstat" ought to be available. The new install scheme for DOS coexistence -- if I could get it to work -- would be great. Better than having to hack it in myself... A sample transcript of such an install session might have helped a little; I don't know that I was doing everything correctly. ++++++++++++++++ Well, that's what I've got to show for the last 12 hours or so of work. If anyone's got suggestions, let me know. If I can get at least one file system up and working reliably, I can set about debugging some of the other problems myself. Ken