NetBSD Problem Report #59780

From www@netbsd.org  Fri Nov 21 06:46:42 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 051551A9239
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 21 Nov 2025 06:46:42 +0000 (UTC)
Message-Id: <20251121064640.E9FA71A923A@mollari.NetBSD.org>
Date: Fri, 21 Nov 2025 06:46:40 +0000 (UTC)
From: thorpej@me.com
Reply-To: thorpej@me.com
To: gnats-bugs@NetBSD.org
Subject: mvme68k GENERIC reports board not supported on MVME177
X-Send-Pr-Version: www-1.0

>Number:         59780
>Category:       port-mvme68k
>Synopsis:       mvme68k GENERIC reports board not supported on MVME177
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    thorpej
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 21 06:50:01 +0000 2025
>Closed-Date:    Sat Nov 22 14:31:26 +0000 2025
>Last-Modified:  Sat Nov 22 14:31:26 +0000 2025
>Originator:     Jason Thorpe
>Release:        NetBSD 11-BETA
>Organization:
Knights of the CISCadel
>Environment:
MVME177 netbooting NetBSD 11-BETA GENERIC
>Description:
Denis Ahrens reports that booting the GENERIC kernel on an MVME177 results in:

> > NetBSD/mvme68k MVME177 netboot (via netboot) [1.6 (Mon Dec 16 13:08:11 UTC 2024)]
device: ie0 attached to 08:00:3e:24:64:17
2717012+84516 [312672+188222]=0x326828
Start @ 0x8000 [1=0x2b3f78-0x32e828]...
Sorry, the kernel isn't configured for this model.
177-Bug>

Booting the VME177 kernel works.  Both kernel configurations have the MVME177 set (and confirmed by inspecting the generated opt_mvmeconf.h).  This means that there is some logic error in the multiple-configuration case.

>How-To-Repeat:
Boot NetBSD 11-BETA GENERIC on an MVME177.
>Fix:
N/A

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: port-mvme68k-maintainer->thorpej
Responsible-Changed-By: thorpej@NetBSD.org
Responsible-Changed-When: Sat, 22 Nov 2025 09:59:28 +0000
Responsible-Changed-Why:
Working on a fix.


State-Changed-From-To: open->analyzed
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Sat, 22 Nov 2025 09:59:28 +0000
State-Changed-Why:
Problem analyzed.


From: "Jason R Thorpe" <thorpej@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
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.

State-Changed-From-To: analyzed->feedback
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Sat, 22 Nov 2025 10:53:30 +0000
State-Changed-Why:
Awaiting confirmation w/ netbsd-11 kernel + fix.


State-Changed-From-To: feedback->needs-pullups
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Sat, 22 Nov 2025 14:01:52 +0000
State-Changed-Why:
Fix confirmed on netbsd-11-based kernel.  Needs pullup to that branch.


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59780 CVS commit: [netbsd-11] src/sys/arch/mvme68k/mvme68k
Date: Sat, 22 Nov 2025 14:16:43 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sat Nov 22 14:16:42 UTC 2025

 Modified Files:
 	src/sys/arch/mvme68k/mvme68k [netbsd-11]: locore.s

 Log Message:
 Pull up following revision(s) (requested by thorpej in ticket #98):

 	sys/arch/mvme68k/mvme68k/locore.s: revision 1.145

 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.131 -r1.131.4.1 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.

State-Changed-From-To: needs-pullups->closed
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Sat, 22 Nov 2025 14:31:26 +0000
State-Changed-Why:
Change pulled up to netbsd-11.


>Unformatted:

Home	PR Database Search