toppin@melpar.UUCP (Doug Toppin) (12/07/89)
We are running SCO Xenix 2.2.3 on the 286. I am having trouble with kernel configuration parameters making the kernel too large to link. I have had to reduce the parameters to significantly smaller values than are the defaults. This is due to adding several vendor drivers for multiport card, windowing, and network. One of the vendors has said that the Xenix 2.3 solves this problem but didn't know how. A tech support person at SCO told me that 2.3 would make no difference. I would like confirmation of this from anyone that has had similar problems or knows anything about it. If you are aware of anything along this line please drop me a line. thanks Doug Toppin uunet!melpar!toppin
soup@penrij.UUCP (John Campbell) (12/13/89)
In article <251@melpar.UUCP>, toppin@melpar.UUCP (Doug Toppin) writes: > We are running SCO Xenix 2.2.3 on the 286. > I am having trouble with kernel configuration parameters > making the kernel too large to link. I have had to reduce > the parameters to significantly smaller values than are > the defaults. This is due to adding several vendor drivers for > multiport card, windowing, and network. One of the vendors > has said that the Xenix 2.3 solves this problem but didn't know how. > A tech support person at SCO told me that 2.3 would make no difference. > I would like confirmation of this from anyone that has had > similar problems or knows anything about it. If you are aware of > anything along this line please drop me a line. > thanks > Doug Toppin > uunet!melpar!toppin XENIX 2.2+ and 2.3+ both use a deviant of MIDDLE model; In fact, some of the data actually _does_ live in additional data segments. I suspect that the drivers you are using are sucking up too much of that "NEAR" space in the kernel. Look at your SABUFS parameter in your /usr/sys/conf/xenixconf and /usr/sys/conf/master files. This is the number of NEAR buffers. Also, look at the number of mounts your system is allowing- these block live in near space. Please be aware that each of these buffers are 1K in size for a XENIX system. Other things to look at are the number of screens (I'm not sure where they live) and hash buffer sizes. Tuning is a series of compromises compromised by compromises. Expect a LOT of having a /xenix.keep which runs but which you won't blow away so that you've got something to fall back on. I've had people need my little special boot diskette to get an O/S back when they blew away the one which worked... YOU DO NOT WANT the 2.3+ development system (If it ever sees the light of day). It uses Microsoft's C 5.0+ compiler which emulates intergalactic vacuum; it generates decent 386 code but has got serious problems with anything less than a 386. -- John R. Campbell (soup@penrij.LS.COM) 1438 Schoolhouse Road Perkasie, PA 18944 (215) 453-8177 "In /dev/null no one can hear you scream"