NetBSD Problem Report #54876

From tsutsui@ceres.dti.ne.jp  Sun Jan 19 05:10:25 2020
Return-Path: <tsutsui@ceres.dti.ne.jp>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id A4AEC7A149
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 19 Jan 2020 05:10:25 +0000 (UTC)
Message-Id: <202001190510.00J5AF3F000746@ceres.dti.ne.jp>
Date: Sun, 19 Jan 2020 14:10:15 +0900 (JST)
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Reply-To: tsutsui@ceres.dti.ne.jp
To: gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: sun3 9.0_RC1 GENERIC + ufsboot fails to load symbols
X-Send-Pr-Version: 3.95

>Number:         54876
>Category:       port-sun3
>Synopsis:       sun3 9.0_RC1 GENERIC + ufsboot fails to load symbols
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    tsutsui
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 19 05:15:00 +0000 2020
>Closed-Date:    Fri Dec 23 13:01:38 +0000 2022
>Last-Modified:  Sat Aug 22 15:05:01 +0000 2026
>Originator:     Izumi Tsutsui
>Release:        NetBSD 9.0_RC1
>Organization:
>Environment:
System: NetBSD 9.0_RC1 (GENERIC) #0: Wed Nov 27 16:14:52 UTC 2019  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/sun3/compile/GENERIC
Architecture: m68k
Machine: sun3
>Description:
On my 24MB 3/60, it looks the secondary bootloader "ufsboot" fails
to load GENERIC kernel symbol table, so several command like savecore(8)
fails to check symbols. If the same GENERIC kernel is loaded via network
using "netboot" loader, symbols can be used correctly.

---
>b sd() -s
Boot: sd(0,0,0) -s
>> NetBSD/sun3 ufsboot [1.13 (Wed Nov 27 16:14:52 UTC 2019)]
ufsboot: trying netbsd
1754348+93012 [167792+151501]=0x211358
starting program at 0x4000
console is ttya
[   1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
[   1.0000000]     2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
[   1.0000000]     2018, 2019 The NetBSD Foundation, Inc.  All rights reserved.
[   1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[   1.0000000]     The Regents of the University of California.  All rights reserved.

[   1.0000000] NetBSD 9.0_RC1 (GENERIC) #0: Wed Nov 27 16:14:52 UTC 2019
[   1.0000000] 	mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/sun3/compile/GENERIC
[   1.0000000] Model: sun3 60
[   1.0000000] fpu: mc68881
[   1.0000000] total memory = 24576 KB
[   1.0000000] avail memory = 22096 KB
[   1.0000000] mainbus0 (root)
[   1.0000000] obio0 at mainbus0
[   1.0000000] zsc0 at obio0 addr 0x0 ipl 6: (softpri 3)
[   1.0000000] kbd0 at zsc0 channel 0: baud rate 1200
[   1.0000000] ms0 at zsc0 channel 1: baud rate 1200
[   1.0000000] zsc1 at obio0 addr 0x20000 ipl 6: (softpri 3)
[   1.0000000] zstty0 at zsc1 channel 0 (console i/o)
[   1.0000000] zstty1 at zsc1 channel 1
[   1.0000000] eeprom0 at obio0 addr 0x40000
[   1.0000000] oclock0 at obio0 addr 0x60000 ipl 5: intersil7170
[   1.0000000] memerr0 at obio0 addr 0x80000 ipl 7: (Parity memory)
[   1.0000000] intreg0 at obio0 addr 0xa0000
[   1.0000000] le0 at obio0 addr 0x120000 ipl 3: address 08:00:20:06:a2:15
[   1.0000000] le0: 8 receive buffers, 2 transmit buffers
[   1.0000000] si0 at obio0 addr 0x140000 ipl 2: options=0xf
[   1.0000000] scsibus0 at si0: 8 targets, 8 luns per target
[   1.0000000] obmem0 at mainbus0
[   1.0000000] bwtwo0 at obmem0 addr 0xff000000 (1152x900)
[   1.0000000] enabling interrupts
[   1.0300220] scsibus0: waiting 2 seconds for devices to settle...
[   5.3400220] sd0 at scsibus0 target 0 lun 0: <MELCO, DSC-UE4.3G, 1.05> disk fixed
[   5.3800220] sd0: 4103 MB, 12968 cyl, 6 head, 108 sec, 512 bytes/sect x 8403264 sectors
[   5.4000220] sd0: async, 8-bit transfers
[   7.9000220] boot device: sd0a
[   7.9500220] root on sd0a dumps on sd0b
[   8.0600220] root file system type: ffs
[   8.0900220] kern.module.path=/stand/sun3/9.0/modules
Enter pathname of shell or RETURN for /bin/sh: 
We recommend that you create a non-root account and use su(1) for root access.
# mount -a
# uname -a
NetBSD  9.0_RC1 NetBSD 9.0_RC1 (GENERIC) #0: Wed Nov 27 16:14:52 UTC 2019  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/sun3/compile/GENERIC sun3
# savecore -c
savecore: (null): _dumpdev not in namelist
# halt
halt: halted by root
[  65.6900220] syncing disks... done
[  65.7100220] unmounting file systems...
[  66.0100220] unmounting done
[  66.0200220] halted.
>b le() -as
Boot: le(0,0,0) -as
Using IP Address 192.168.20.65 = C0A81441
Booting from tftp server at 192.168.20.1 = C0A81401
Downloaded 24264 bytes from tftp server.

>> NetBSD/sun3 netboot [1.13 (Wed Nov 27 16:14:52 UTC 2019)]
Using IP Address 192.168.20.65 = C0A81441
filename? [netbsd]: 
1754348+93012 [167792+151501]=0x211358
starting program at 0x4000
console is ttya
[   1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
[   1.0000000]     2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
[   1.0000000]     2018, 2019 The NetBSD Foundation, Inc.  All rights reserved.
[   1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[   1.0000000]     The Regents of the University of California.  All rights reserved.

[   1.0000000] NetBSD 9.0_RC1 (GENERIC) #0: Wed Nov 27 16:14:52 UTC 2019
[   1.0000000] 	mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/sun3/compile/GENERIC
[   1.0000000] Model: sun3 60
[   1.0000000] fpu: mc68881
[   1.0000000] total memory = 24576 KB
[   1.0000000] avail memory = 22096 KB
[   1.0000000] mainbus0 (root)
[   1.0000000] obio0 at mainbus0
[   1.0000000] zsc0 at obio0 addr 0x0 ipl 6: (softpri 3)
[   1.0000000] kbd0 at zsc0 channel 0: baud rate 1200
[   1.0000000] ms0 at zsc0 channel 1: baud rate 1200
[   1.0000000] zsc1 at obio0 addr 0x20000 ipl 6: (softpri 3)
[   1.0000000] zstty0 at zsc1 channel 0 (console i/o)
[   1.0000000] zstty1 at zsc1 channel 1
[   1.0000000] eeprom0 at obio0 addr 0x40000
[   1.0000000] oclock0 at obio0 addr 0x60000 ipl 5: intersil7170
[   1.0000000] memerr0 at obio0 addr 0x80000 ipl 7: (Parity memory)
[   1.0000000] intreg0 at obio0 addr 0xa0000
[   1.0000000] le0 at obio0 addr 0x120000 ipl 3: address 08:00:20:06:a2:15
[   1.0000000] le0: 8 receive buffers, 2 transmit buffers
[   1.0000000] si0 at obio0 addr 0x140000 ipl 2: options=0xf
[   1.0000000] scsibus0 at si0: 8 targets, 8 luns per target
[   1.0000000] obmem0 at mainbus0
[   1.0000000] bwtwo0 at obmem0 addr 0xff000000 (1152x900)
[   1.0000000] enabling interrupts
[   1.0300220] scsibus0: waiting 2 seconds for devices to settle...
[   5.3400220] sd0 at scsibus0 target 0 lun 0: <MELCO, DSC-UE4.3G, 1.05> disk fixed
[   5.3700220] sd0: 4103 MB, 12968 cyl, 6 head, 108 sec, 512 bytes/sect x 8403264 sectors
[   5.4000220] sd0: async, 8-bit transfers
[   7.9000220] boot device: le0
[   7.9100220] root device (default le0): sd0a
[   7.9800220] dump device (default sd0b): 
[   8.0100220] file system (default generic): 
[   8.0300220]  dumps on sd0b
[   8.1400220] root file system type: ffs
[   8.1800220] kern.module.path=/stand/sun3/9.0/modules
[   8.3100220] init path (default /sbin/init): 
[   8.3500220] init: trying /sbin/init
Enter pathname of shell or RETURN for /bin/sh: 
We recommend that you create a non-root account and use su(1) for root access.
# mount -a
# uname -a
NetBSD  9.0_RC1 NetBSD 9.0_RC1 (GENERIC) #0: Wed Nov 27 16:14:52 UTC 2019  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/sun3/compile/GENERIC sun3
# savecore -c
# 

---

Note I cannot reproduce on TME with 2GB disk image,
so it might be 3/60 specific or possible hardware issue.
(though I don't have a scenario how netboot works in that case)

I'll also check how a disk image dd'ed from the 3/60 disk
works with TME.

>How-To-Repeat:
- install NetBSD/sun3 9.0_RC1 via miniroot
  (fix in PR/54833 required for network installation)
- prepare root partition (sd0a) as 512MB
- preceed installation
- boot GENERIC kernel from sd0a

Full installation log is available:
 https://gist.github.com/tsutsui/00d204d2e96ae45e05bf25ec776891f8

>Fix:
Currently not.

On sun3 a kernel is loaded at 0x4000 and bootloader is located at 0x28000.
A size of 9.0_RC1 GENERIC is:
>    text    data     bss     dec     hex filename
> 0x1a0368 0xc16c 0x16b40 1847316  1c3014 netbsd
so kernel size should not be an issue.

One possibility is ufs functions in ufsboot uses too many stack
on loading kernel?
(stack for bootloader is allocated just before bootloader, i.e. 0x28000)
 https://nxr.netbsd.org/xref/src/sys/arch/sun68k/stand/libsa/SRT0.S?r=1.2#79



>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: port-sun3-maintainer->tsutsui
Responsible-Changed-By: tsutsui@NetBSD.org
Responsible-Changed-When: Sun, 05 Jul 2020 15:13:16 +0000
Responsible-Changed-Why:
I'll handle this.


State-Changed-From-To: open->analyzed
State-Changed-By: tsutsui@NetBSD.org
State-Changed-When: Sun, 05 Jul 2020 15:13:15 +0000
State-Changed-Why:
Shrinking GENERIC kernel by the following -fno-unwind-tables changes
seems to solve this issue on NetBSD 9.0.
https://mail-index.netbsd.org/source-changes/2020/06/19/msg118468.html


State-Changed-From-To: analyzed->closed
State-Changed-By: tsutsui@NetBSD.org
State-Changed-When: Fri, 23 Dec 2022 13:01:38 +0000
State-Changed-Why:
NetBSD/sun3 9.3 GENERIC on 4.3GB SCSI HDD works.
NetBSD/sun3 9.3 GENERIC on 20GB SCSI HDD fails to start loaded kernel.
Maybe there is some restriction on PROM functions (require more workarea?)
on larger disks.


From: "Izumi Tsutsui" <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/54876 CVS commit: src/sys/arch/sun68k/stand/libsa
Date: Wed, 19 Aug 2026 18:14:08 +0000

 Module Name:	src
 Committed By:	tsutsui
 Date:		Wed Aug 19 18:14:08 UTC 2026

 Modified Files:
 	src/sys/arch/sun68k/stand/libsa: sun3.c version

 Log Message:
 sun68k: avoid PROM DVMA map aliasing in sun3 bootloader

 NetBSD/sun3 11.0 GENERIC fails to boot from a SCSI disk on
 my Sun 3/60 with at least PROM revisions 2.8.3 and 3.0.1.

 It looks sun3 PROM SCSI driver allocates internal resources
 in DVMA space starting at 0xfff00000. The sun3 standalone
 DVMA setup currently aliases its local address range starting
 at 0x200000 to that same address.

 Since the alias is created by sharing PMEGs, PTE changes made by
 the PROM in its DVMA space also change the corresponding standalone
 mappings. These mappings are inherited by the loaded kernel.

 On Sun3, pmap_bootstrap() derives the first available PA from
 (nextva - KERNBASE3), assuming that the kernel bootstrap VA range
 is backed by the corresponding contiguous physical addresses.

 A leaked alias can instead map part of that range to an unrelated
 physical page, leaving that use unaccounted for. Then the page can
 be registered as available memory by uvm_page_physload() (via
 machine_init_common() in HEAD) even though it is already used for
 kernel bootstrap data such as the symbol table and kernel stack etc.
 Maybe this is the real reason that also caused PR/54876.

 Move the lower end of the standalone alias from 0x200000/0xfff00000
 to 0x240000/0xfff40000 to avoid aliasing the PROM DVMA mappings.
 Keep the upper limit unchanged, so existing local-to-DVMA address
 translations for the remaining range are preserved.

 Bump version to denote this fix.

 Should be pulled up to netbsd-11 and netbsd-10.


 To generate a diff of this commit:
 cvs rdiff -u -r1.12 -r1.13 src/sys/arch/sun68k/stand/libsa/sun3.c
 cvs rdiff -u -r1.6 -r1.7 src/sys/arch/sun68k/stand/libsa/version

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/54876 CVS commit: [netbsd-10] src/sys/arch/sun68k/stand/libsa
Date: Sat, 22 Aug 2026 10:57:27 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sat Aug 22 10:57:27 UTC 2026

 Modified Files:
 	src/sys/arch/sun68k/stand/libsa [netbsd-10]: sun3.c version

 Log Message:
 Pull up following revision(s) (requested by tsutsui in ticket #1329):

 	sys/arch/sun68k/stand/libsa/sun3.c: revision 1.12
 	sys/arch/sun68k/stand/libsa/sun3.c: revision 1.13
 	sys/arch/sun68k/stand/libsa/version: revision 1.7

 sun68k: fix typo in physical address calculation in dev3_mapin()

 This typo was introduced in the sun3/sun3x merge 28 years ago,
 so maybe harmless.

 sun68k: avoid PROM DVMA map aliasing in sun3 bootloader

 NetBSD/sun3 11.0 GENERIC fails to boot from a SCSI disk on
 my Sun 3/60 with at least PROM revisions 2.8.3 and 3.0.1.

 It looks sun3 PROM SCSI driver allocates internal resources
 in DVMA space starting at 0xfff00000. The sun3 standalone
 DVMA setup currently aliases its local address range starting
 at 0x200000 to that same address.

 Since the alias is created by sharing PMEGs, PTE changes made by
 the PROM in its DVMA space also change the corresponding standalone
 mappings. These mappings are inherited by the loaded kernel.

 On Sun3, pmap_bootstrap() derives the first available PA from
 (nextva - KERNBASE3), assuming that the kernel bootstrap VA range
 is backed by the corresponding contiguous physical addresses.

 A leaked alias can instead map part of that range to an unrelated
 physical page, leaving that use unaccounted for. Then the page can
 be registered as available memory by uvm_page_physload() (via
 machine_init_common() in HEAD) even though it is already used for
 kernel bootstrap data such as the symbol table and kernel stack etc.

 Maybe this is the real reason that also caused PR/54876.

 Move the lower end of the standalone alias from 0x200000/0xfff00000
 to 0x240000/0xfff40000 to avoid aliasing the PROM DVMA mappings.

 Keep the upper limit unchanged, so existing local-to-DVMA address
 translations for the remaining range are preserved.

 Bump version to denote this fix.


 To generate a diff of this commit:
 cvs rdiff -u -r1.11 -r1.11.20.1 src/sys/arch/sun68k/stand/libsa/sun3.c
 cvs rdiff -u -r1.6 -r1.6.94.1 src/sys/arch/sun68k/stand/libsa/version

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/54876 CVS commit: [netbsd-11] src/sys/arch/sun68k/stand/libsa
Date: Sat, 22 Aug 2026 15:00:20 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sat Aug 22 15:00:20 UTC 2026

 Modified Files:
 	src/sys/arch/sun68k/stand/libsa [netbsd-11]: sun3.c version

 Log Message:
 Pull up following revision(s) (requested by tsutsui in ticket #420):

 	sys/arch/sun68k/stand/libsa/sun3.c: revision 1.12
 	sys/arch/sun68k/stand/libsa/sun3.c: revision 1.13
 	sys/arch/sun68k/stand/libsa/version: revision 1.7

 sun68k: fix typo in physical address calculation in dev3_mapin()

 This typo was introduced in the sun3/sun3x merge 28 years ago,
 so maybe harmless.

 sun68k: avoid PROM DVMA map aliasing in sun3 bootloader

 NetBSD/sun3 11.0 GENERIC fails to boot from a SCSI disk on
 my Sun 3/60 with at least PROM revisions 2.8.3 and 3.0.1.

 It looks sun3 PROM SCSI driver allocates internal resources
 in DVMA space starting at 0xfff00000. The sun3 standalone
 DVMA setup currently aliases its local address range starting
 at 0x200000 to that same address.

 Since the alias is created by sharing PMEGs, PTE changes made by
 the PROM in its DVMA space also change the corresponding standalone
 mappings. These mappings are inherited by the loaded kernel.

 On Sun3, pmap_bootstrap() derives the first available PA from
 (nextva - KERNBASE3), assuming that the kernel bootstrap VA range
 is backed by the corresponding contiguous physical addresses.

 A leaked alias can instead map part of that range to an unrelated
 physical page, leaving that use unaccounted for. Then the page can
 be registered as available memory by uvm_page_physload() (via
 machine_init_common() in HEAD) even though it is already used for
 kernel bootstrap data such as the symbol table and kernel stack etc.

 Maybe this is the real reason that also caused PR/54876.

 Move the lower end of the standalone alias from 0x200000/0xfff00000
 to 0x240000/0xfff40000 to avoid aliasing the PROM DVMA mappings.

 Keep the upper limit unchanged, so existing local-to-DVMA address
 translations for the remaining range are preserved.

 Bump version to denote this fix.


 To generate a diff of this commit:
 cvs rdiff -u -r1.11 -r1.11.28.1 src/sys/arch/sun68k/stand/libsa/sun3.c
 cvs rdiff -u -r1.6 -r1.6.102.1 src/sys/arch/sun68k/stand/libsa/version

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.