Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!munnari.oz.au!anucsd!ccadfa!csadfa!wkt
From: wkt@csadfa.cs.adfa.oz.au
Newsgroups: comp.os.minix
Subject: Re: Receiving General Protection panic from 386 Minix
Message-ID: <5632@munnari.oz.au>
Date: 26 Sep 90 23:28:15 GMT
Sender: news@cs.mu.oz.au
Lines: 20
Organisation: Computer Science Dept, Australian Defence Force Academy

In article <1990Sep25.221053.23430@dsuvax.uucp>, Guy Helmer writes:
>This morning, though, I rebuilt everything after changing the number
>of buffers in the cache to 30, and 386 Minix started without any complaints.
>I'd like to find the source of the trouble when using large numbers
>of buffers and the plain Minix bootstrap.

Bruce Evans wrote to me a few weeks ago explaining the problem. It seems
that when build is compiled as a 16-bit binary it can't cope with sizes
bigger than 64K. Specifying a buffer size bigger than this gives the
problem you've see.

Solution: Build a '386 kernel with 30 buffers. Use it to make a 32-bit
build, and use _it_ to build a kernel with, say, 300 buffers. This works!

BTW, you get an awfully large image, around 500K, with this. This is mostly
empty space. Has anybody thought of a method of removing the empty
(uninitialised data) part of the image, and to create this at boot time?!

Cheers,
	Warren Toomey	wkt@csadfa.cs.adfa.oz.au