kjh@pollux.usc.edu (Kenneth J. Hendrickson) (06/06/91)
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
evans@syd.dit.CSIRO.AU (Bruce.Evans) (06/06/91)
In article <33395@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: >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. The following problems with the "traditional tools" are known: 1) bootblok overwrites itself without checking if the image is large. Kludge fix: increase BOOTSEG to 0x9FA0 (or less if you don't have 640K). Correct fix: ask the BIOS for the size, give up if not enough, otherwise calculate BOOTSEG to be just large enough and continue as now. 2) build doesn't handle NR_BUFS above about 50 in 16-bit mode. Fix: leave NR_BUFS as 30 and use the 16-bit build. Rebuild the system with NR_BUFS big and use the 32-bit build. 3) build gets the sector count short by 1. Usually this doesn't matter because the symbol table for menu provides suitable (junk) padding. It does matter with the dummy db. Fixes: use the standard build and bootblok.s (patched for bug 1) so as not to get db; add 1 in build; or add 512 bytes of dummy data in db.s. I'm not sure how versions built with the ACK compiler work, because there is no symble table. Perhaps unimportant bss is left out, and this is why menu1.s wastes time clearing the bss after it has already been cleared by build. -- Bruce Evans evans@syd.dit.csiro.au