PR/59780 CVS commit: src/sys/arch/mvme68k/mvme68k

["Jason R Thorpe" <thorpej%netbsd.org@localhost>]

The following reply was made to PR port-mvme68k/59780; it has been noted by GNATS.

From: "Jason R Thorpe" <thorpej%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/59780 CVS commit: src/sys/arch/mvme68k/mvme68k
Date: Sat, 22 Nov 2025 10:13:32 +0000

 Module Name:	src
 Committed By:	thorpej
 Date:		Sat Nov 22 10:13:32 UTC 2025
 
 Modified Files:
 	src/sys/arch/mvme68k/mvme68k: locore.s
 
 Log Message:
 In the Lbrdmatch loop, fix the number of bytes the pointer is advanced
 when a match is not found (code was using 18, correct number is 10).
 
 Explainer:
 
 The board type entries consist of 4 shorts + 1 long for a total of 12
 bytes.  When comparing the board ID, the pointer is advanced meaning
 that there are 10 bytes left to skip in the case of a non-match.
 
 As for why the old code was using 18 (0x12) bytes, a comment that says
 "Each entry is 20-2 bytes long" provides a clue: if the CPU type, MMU
 type, and FPU type entries were longs, each entry would in fact be 18
 bytes -- and maybe this was the case in the distant past.  However, it
 still would be wrong to advance 18 bytes because of the auto-increment
 used during the compare.
 
 scw@ is a smart guy and I'm certain this worked at some point, but I'm
 not going to go and do the archeology needed to figure out exactly when
 this broke.  If you happened to have an MVME147 (first entry in the board
 type list) or booted a single-type kernel, it would work fine.  But If you
 had an MVME16x or MVME17x, then this small error would bite your behind
 when booting GENERIC.
 
 PR port-mvme68k/59780
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.144 -r1.145 src/sys/arch/mvme68k/mvme68k/locore.s
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.