Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!pollux.usc.edu!kjh
From: kjh@pollux.usc.edu (Kenneth J. Hendrickson)
Newsgroups: comp.os.minix
Subject: bootblok.s and/or build.c for Minix-386
Message-ID: <33395@usc.edu>
Date: 6 Jun 91 10:32:59 GMT
Sender: news@usc.edu
Organization: EE-Systems, USC, Los Angeles
Lines: 39
Nntp-Posting-Host: pollux.usc.edu

There is a strange phenomenon happening for me while building boot disks
for Minix-386.  I am using the traditional tools in /usr/src/tools, and
my boot floppy is a 1.2M in /dev/at0.

When NR_BUFS is >= 200, the boot process fails somewhere in bootblok.s
after printing the greet message, and before running menu.

When NR_BUFS is <= 150, everything works great.  Nothing else changed.

Here is the data for the 8 words documented in the beginning of
bootblok.s, which are filled in by build.c:

od -x image | grep aa55			# 150 buffers
0000760 4ee0 0000 4ee0 0275 4c50 0000 4b50 aa55

od -x image | grep aa55			# 200 buffers
0000760 5c30 0000 5c30 02df 59a0 0000 58a0 aa55

			^
			|
So exactly 106 extra sectors must be loaded in by bootblok.s.  This
makes sense, because there are 50k more buffers, requiring 100 more
sectors of 512 bytes each.  The smallest multiple of 16 larger than 100
is 106.

		    ^			^
		    |			|
This indicates that db and menu are 3408*16 == 53.25k further down in
memory with the extra 50k of buffers.  This also seems reasonable.

Does anybody know what's going on?  Any suggestions?  Build seems to be
inserting reasonable values, and bootblok.s works fine with the smaller
number of buffers.  I've studied the code for bootblok.s quite a bit,
and I don't see any glaring errors.  Any and all help will be appreciated.
I think there may be an obscure bug.

-- 
favourite oxymorons:   student athlete, military justice, mercy killing
Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh