Boot fails on 64M minix file systems

[Mellvik]

A few years back - on ELKS - the max size of minix file systems was increased from 32M to 64M. That has worked fine since, probably rely used on ELKS, while on TLVC, 64M has been the standard for HD file systems since the fork.

There have been occasional boot failures (code 4, bad kernel signature) but too rare to chase.

Recently that has changed. For whatever reason, most likely file systems filling up with whatever debugging entails (such as big dummy files, 10 or 20 variants of the kernel, whatever...) plenty of space invites to laziness as far as deleting is concerned.

So, a new kernel is more likely to end up in the upper half of the 64M file system. That - as it turns out makes ut unbootable. The boot code uses an unsigned int to hold the block to read, and shifts it left before calling disk_read. With obvious consequences for kernel (and indirect map) blocks above 32k.

@ghaerr, this is the reason for the problems reported in #205 (comment) - so the unlimited bootopts implementation is in the clear (as far as this is concerned).

I'm looking at ways to fix this right now. The extremely tight space make changes tricky.

This presumably also being a problem on ELKS, you may want to take a look, @ghaerr.

[ghaerr]

Hi @Mellvik,

Yes, nice catch - I can see the four places where the block number is shifted left to get a sector number in every call to disk_read in the MINIX boot code in C, so very much a bug when block numbers are > 32767.

One scenario for a solution would be that the disk_read function take a block number, not a sector number, as the first argument. Removing those four left shifts should allow for a few more instructions. Then, in the disk_read ASM function, using a few instructions to compute the sector number into a pair of registers (the upper half would always be 0 or 1), would pass that to the modified CHS function to get CHS from 32-bit sector number.

The whole things's a huge mess though - since the single ASM call to disk_read in boot_sect.S cheats by passing sector number 1 to read the second half of the "payload" block. So the routine either needs an additional entry point for disk_read_sector, unless the load address is changed by 512 bytes and two sectors read. The other huge problem is that the same disk_read function is used by boot_sect_fat.h to boot from FAT and requires a sector number, not block number, and the source code is shared. On ELKS, PC-98 is supported in the same source, adding tons of ifdefs to the mess.

I've been traveling for 5 days and just started an 8-day trip out of the country, so I don't have too much time at the moment, but will continue to look at this. Geez, the rabbit holes that have opened up since we started the "easy" talking about just getting the NIC drivers cleaned up for ELKS, then long interrupt cleanup discussion, and now this!! When it rains, it pours, that's for sure!

[Mellvik]

One scenario for a solution would be that the disk_read function take a block number, not a sector number, as the first argument. Removing those four left shifts should allow for a few more instructions. Then, in the disk_read ASM function, using a few instructions to compute the sector number into a pair of registers (the upper half would always be 0 or 1), would pass that to the modified CHS function to get CHS from 32-bit sector number.

Yes, that's probably the way to go unless we decide to redo the whole thing (not tempting). I wrote up a hack this morning - works on QEMU, to be tested on HW. Proof of concept, all kinds of non-sustainable tricks to get the code to fit. Needs some real smart thinking.

Enjoy traveling.

[Mellvik]

Geez, the rabbit holes that have opened up since we started the "easy" talking about just getting the NIC drivers cleaned up for ELKS, then long interrupt cleanup discussion, and now this!! When it rains, it pours, that's for sure!

It is indeed interesting. It seems that ELKS needs more hardware exposure, TLVC needs more exposure in general - more eyes and (wider) use. Anyway, important commonalities, mutually beneficial differences.

Every time we stumble into one of these rabbit holes, we come out with both systems improved. It's inspiring!

Thanks.

[Mellvik]

The other huge problem is that the same disk_read function is used by boot_sect_fat.h to boot from FAT and requires a sector number, not block number, and the source code is shared. On ELKS, PC-98 is supported in the same source, adding tons of ifdefs to the mess.

disk_read has 2 entry points, one exposed externally, the other internal (underscore prepended). I haven't looked at the fat code yet though, that may complicate things further. Thanks for the hint.

[Mellvik]

Fixed in #210