> I've had similar problems with NetBSD-current/sparc64.  I have a
> number of kernels with identical md5's, and some boot and some do
> not.  In private email Manuel Bouyer suggested it was related to the
> disk blocks occupied by the kernels,

That would be my suspicion too.

> and an integer overflow somewhere in the boot code.

That seems less likely to me.

>>> How large is your / partition ?
>> %df -kl   
>> Filesystem  1K-blocks     Used     Avail Capacity  Mounted on
>> /dev/wd0a     7728318  3464694   3877208    47%    /
>>> Less than 8G, shouldn't cause any problems.

I'd expect possible problems at four points:

(1) 1G, if the ROM code uses 6-byte CDBs.  (I'd've hoped such code
would have been stamped out before the sparc64s were made, but the
ability of corporations to do stupid things amazes me.)

(2) 2G, if signed 32-bit byte offsets are relevant.

(3) 4G, if unsigned 32-bit byte offsets are relevant.

(4) 256T, where 10-byte CDBs (32-bit block numbers) run out.

I can't see why there would be any limit at 8G.

Limits (1) and (4) apply to where the blocks are relative to the
beginning of the disk and has nothing to do with partition placement;
limits (2) and (3) may be partition-relative or may not, depending on
where the relevant code is.

>  fsdb of a bad kernel:

>    fsdb (inum: 531508)> blks
> [block numbers in the range 2131232..2132608]

>  fsdb of a good kernel:

>    fsdb (inum: 531538)> blks
> [block numbers in the range 2077720..2087472]

These results are consistent with the 1G-limit theory, assuming your
boot partition begins at the beginning of the disk (and either it uses
half-K frags or the numbers printed by fsdb are post-fsbtodb()).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B