NetBSD Problem Report #58320
From tsutsui@ceres.dti.ne.jp Sat Jun 8 15:19:12 2024
Return-Path: <tsutsui@ceres.dti.ne.jp>
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)
client-signature RSA-PSS (2048 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 7B26E1A923A
for <gnats-bugs@gnats.NetBSD.org>; Sat, 8 Jun 2024 15:19:12 +0000 (UTC)
Message-Id: <202406081519.458FJ6ME013124@ceres.dti.ne.jp>
Date: Sun, 9 Jun 2024 00:19:06 +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: NetBSD/macppc 10.0 INSTALL kernel stalls on Power Mac G4
X-Send-Pr-Version: 3.95
>Number: 58320
>Category: port-macppc
>Synopsis: NetBSD/macppc 10.0 INSTALL kernel stalls on Power Mac G4
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: port-macppc-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Jun 08 15:20:00 +0000 2024
>Last-Modified: Sat May 03 01:00:02 +0000 2025
>Originator: Izumi Tsutsui
>Release: NetBSD 10.0
>Organization:
>Environment:
System: NetBSD 10.0 (INSTALL) #0: Thu Mar 28 08:33:33 UTC 2024 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/macppc/compile/INSTALL macppc
Architecture: powerpc
Machine: macppc
>Description:
NetBSD/macppc 10.0 INSTALL kernel booted from an official
NetBSD-10.0-macppc.iso stalls just after genfb(4) is attached.
See the following video for details:
https://www.youtube.com/watch?v=C2HhzWNuR0A
Note GENERIC kernel that uses r128fb(4) instead of genfb(4)
works fine.
---
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013,
2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023,
2024
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 10.0 (GENERIC) #0: Thu Mar 28 08:33:33 UTC 2024
mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/macppc/compile/GENERIC
total memory = 1024 MB
oea_startup: failed to allocate DEAD ZONE: error=12
avail memory = 977 MB
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
found openpic PIC at 80040000
OpenPIC Version 1.2: Supports 4 CPUs and 64 interrupt sources.
bootpath: /pci@f2000000/@d/mac-io@7/ata-4@1f000/disk@1:0/netbsd
mainbus0 (root)
cpu0 at mainbus0: 7400 (Revision 2.9), ID 0 (primary)
cpu0: HID0 0x8094c0a4<EMCP,DOZE,DPM,EIEC,ICE,DCE,SGE,BTIC,BHT>, powersave: 1
cpu0: 400.00 MHz, no-parity 1MB WB L2 cache (PB SRAM) at 2:1 ratio
memory0 at mainbus0: len=512
spdmem0 at memory0
spdmem0: SDRAM, no parity or ECC, 256MB, 133MHz (PC-133)
spdmem0: 12 rows, 10 cols, 2 banks, 4 banks/chip, 7.5ns cycle time
spdmem0: tAA-tRCD-tRP-tRAS: 3-20-20-45
spdmem0: voltage LvTTL (not 5V tolerant), refresh time 15.625us (self-refreshing)
spdmem1 at memory0
spdmem1: SDRAM, no parity or ECC, 256MB, 133MHz (PC-133)
spdmem1: 12 rows, 10 cols, 2 banks, 4 banks/chip, 7.5ns cycle time
spdmem1: tAA-tRCD-tRP-tRAS: 3-20-20-45
spdmem1: voltage LvTTL (not 5V tolerant), refresh time 15.625us (self-refreshing)
spdmem2 at memory0
spdmem2: SDRAM, no parity or ECC, 256MB, 133MHz (PC-133)
spdmem2: 12 rows, 10 cols, 2 banks, 4 banks/chip, 7.5ns cycle time
spdmem2: tAA-tRCD-tRP-tRAS: 3-20-20-45
spdmem2: voltage LvTTL (not 5V tolerant), refresh time 15.625us (self-refreshing)
spdmem3 at memory0
spdmem3: SDRAM, no parity or ECC, 256MB, 133MHz (PC-133)
spdmem3: 12 rows, 10 cols, 2 banks, 4 banks/chip, 7.5ns cycle time
spdmem3: tAA-tRCD-tRP-tRAS: 3-20-20-45
spdmem3: voltage LvTTL (not 5V tolerant), refresh time 15.625us (self-refreshing)
uni_n0 at mainbus0 address 0xf8000000
ki2c0 at uni_n0 address 0xf8001000
iic0 at ki2c0: I2C bus
uninorth0 at mainbus0
pci0 at uninorth0 bus 0
pci0: i/o space, memory space enabled
pchb0 at pci0 dev 11 function 0
pchb0: Apple Computer UniNorth AGP Interface (rev. 0x00)
r128fb0 at pci0 dev 16 function 0: ATI Technologies Rage Fury MAXX AGP 4x (TMDS) (rev. 0x00)
r128fb0: 64 MB aperture at 0x94000000
wsdisplay0 at r128fb0 kbdmux 1: console (default, vt100 emulation)
wsmux1: connecting to wsdisplay0
uninorth1 at mainbus0
pci1 at uninorth1 bus 0
pci1: i/o space, memory space enabled
pchb1 at pci1 dev 11 function 0
pchb1: Apple Computer UniNorth Host-PCI Bridge (rev. 0x00)
ppb0 at pci1 dev 13 function 0: Digital Equipment DC21154 PCI-PCI Bridge (rev. 0x05)
pci2 at ppb0 bus 1
pci2: i/o space, memory space enabled
obio0 at pci2 dev 7 function 0: addr 0x80000000
obio0: enabling KeyLargo internal modem
zsc0 at obio0 irq 22,50
zstty0 at zsc0 channel 0
zstty1 at zsc0 channel 1
awacs0 at obio0 offset 0x14000 Screamer: irq 24,9,10
awacs0: speaker
audio0 at awacs0: playback, capture, full duplex
audio0: slinear_be:16 2ch 44100Hz, blk 4096 bytes (23.2ms) for playback
audio0: slinear_be:16 2ch 44100Hz, blk 4096 bytes (23.2ms) for recording
spkr0 at audio0: PC Speaker (synthesized)
wsbell at spkr0 not configured
pmu0 at obio0 offset 0x16000 irq 47: rev. 12
pmu0: initializing RTC
pmu0: power-mgt not configured
ki2c1 at obio0
iic1 at ki2c1: I2C bus
wdc0 at obio0 offset 0x1f000 irq 19, level triggered: DMA transfer
atabus0 at wdc0 channel 0
wdc1 at obio0 offset 0x20000 irq 20, level triggered: DMA transfer
atabus1 at wdc1 channel 0
wdc2 at obio0 offset 0x21000 irq 21, level triggered: DMA transfer
atabus2 at wdc2 channel 0
ohci0 at pci2 dev 8 function 0: Apple Computer KeyLargo USB Controller (rev. 0x00)
ohci0: interrupting at irq 27
ohci0: OHCI version 1.0
usb0 at ohci0: USB revision 1.0
ohci1 at pci2 dev 9 function 0: Apple Computer KeyLargo USB Controller (rev. 0x00)
ohci1: interrupting at irq 28
ohci1: OHCI version 1.0
usb1 at ohci1: USB revision 1.0
fwohci0 at pci2 dev 10 function 0: Texas Instruments TSB12LV26 IEEE 1394 Host Controller (rev. 0x00)
fwohci0: interrupting at irq 63
fwohci0: OHCI version 1.0 (ROM=0)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:30:65:ff:fe:c4:d2:90
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
ieee1394if0 at fwohci0: IEEE1394 bus
fwip0 at ieee1394if0: IP over IEEE1394
fwohci0: Initiate bus reset
uninorth2 at mainbus0
pci3 at uninorth2 bus 0
pci3: i/o space, memory space enabled
pchb2 at pci3 dev 11 function 0
pchb2: Apple Computer UniNorth Host-PCI Bridge (rev. 0x00)
gem0 at pci3 dev 15 function 0: Apple Computer GMAC Ethernet (rev. 0x01)
gem0: interrupting at irq 41
brgphy0 at gem0 phy 0: BCM5400 1000BASE-T media interface, rev. 7
brgphy0: 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
gem0: Ethernet address 00:30:65:c4:d2:90, 10KB RX fifo, 4KB TX fifo
vmmask 73fc0000 schedmask 7ffc0000 highmask 7ffc0000
timecounter: Timecounter "mftb" frequency 24907667 Hz quality 100
fwohci0: BUS reset
fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode
ieee1394if0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me)
ieee1394if0: bus manager 0
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
WARNING: system needs entropy for security; see entropy(7)
IPsec: Initialized Security Association Processing.
uhub0 at usb0: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub1 at usb1: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
wd0 at atabus0 drive 0
wd0: <IBM-DTLA-305020>
wd0: drive supports 16-sector PIO transfers, LBA addressing
wd0: 19623 MB, 39870 cyl, 16 head, 63 sec, 512 bytes/sect x 40188960 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd1 at atabus0 drive 1
wd1: <WDC WD200BB-75CAA0>
wd1: drive supports 16-sector PIO transfers, LBA addressing
wd1: 19073 MB, 38752 cyl, 16 head, 63 sec, 512 bytes/sect x 39062500 sectors
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(wdc0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4 (Ultra/66) (using DMA)
wd1(wdc0:0:1): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4 (Ultra/66) (using DMA)
uhub2 at uhub1 port 1: Chicony (0x04fe) Generic USB Hub (0x0008), class 9/0, rev 1.10/1.02, addr 2
uhub2: 3 ports with 2 removable, bus powered
uhidev0 at uhub2 port 1 configuration 1 interface 0
uhidev0: Chicony (0x04fe) PFU-68 USB Keyboard (0x0007), rev 1.10/1.02, addr 3, iclass 3/1
ukbd0 at uhidev0: 8 Variable keys, 6 Array codes
wskbd0 at ukbd0: console keyboard, using wsdisplay0
atapibus0 at atabus1: 2 targets
cd0 at atapibus0 drive 0: <HITACHI DVD-ROM GD-7000, , 016J> cdrom removable
cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
cd0(wdc1:0:0): using PIO mode 4, DMA mode 2 (using DMA)
swwdog0: software watchdog initialized
boot device: wd1
root on wd1a dumps on wd1b
root file system type: ffs
kern.module.path=/stand/macppc/10.0/modules
entropy: best effort
---
NetBSD/macppc 9.4 INSTALL kernel works and genfb(4) is attached
without visible problems. 8.3 INSTALL also works.
>How-To-Repeat:
Boot an official NetBSD-10.0-macppc.iso on Power Mac G4 with ATI Rage128,
as noted above.
>Fix:
No idea.
Bisect netbsd-9 and netbsd-10?
---
Izumi Tsutsui
>Audit-Trail:
From: Michael <macallan1888@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls on
Power Mac G4
Date: Sun, 9 Jun 2024 18:40:22 -0400
> NetBSD/macppc 10.0 INSTALL kernel booted from an official
> NetBSD-10.0-macppc.iso stalls just after genfb(4) is attached.
I'll check if I can reproduce this on the Pismo. If not, I have an AGP
R128 somewhere that I could stick in the Quicksilver.
IIRC the only code I added to genfb between 9 and 10 was a glyph
caching scheme, but that isn't enabled by default and doesn't use video
memory.
have fun
Michael
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@netbsd.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls onPower
Mac G4
Date: Mon, 10 Jun 2024 22:07:42 +0900
> IIRC the only code I added to genfb between 9 and 10 was a glyph
> caching scheme, but that isn't enabled by default and doesn't use video
> memory.
There were more other changes (for x86 and arm? etc.):
https://github.com/NetBSD/src/commit/56b9a4e51561e9ad4e14e38e8a06b43b8bede03a
> wsfb: Prefer wide fonts when EDID data is available.
https://github.com/NetBSD/src/commit/e69e27c5ad55100572023af4b1ecc2e003c8ec82
> Add 10-bit pixel format support.
https://github.com/NetBSD/src/commit/71baff76aa4ee3604639f7e7212eb328df46381b
> PR kern/57035
> genfb(4): Fix blank screen after switching to WSDISPLAYIO_MODE_EMUL for
> some GPU models like Ice Lake integrated GPU:
I'll check if reverting these changes helps.
---
Izumi Tsutsui
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: tsutsui@ceres.dti.ne.jp
Cc: gnats-bugs@netbsd.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls onPowerMac
G4
Date: Tue, 11 Jun 2024 01:53:51 +0900
> There were more other changes (for x86 and arm? etc.):
>
> https://github.com/NetBSD/src/commit/56b9a4e51561e9ad4e14e38e8a06b43b8bede03a
> > wsfb: Prefer wide fonts when EDID data is available.
>
> https://github.com/NetBSD/src/commit/e69e27c5ad55100572023af4b1ecc2e003c8ec82
> > Add 10-bit pixel format support.
These doesn't help, and even sources reverted to genfb.c rev 1.64
(and necessary changes) except thorpej-cfargs also fail (black screen).
> https://github.com/NetBSD/src/commit/71baff76aa4ee3604639f7e7212eb328df46381b
> > PR kern/57035
> > genfb(4): Fix blank screen after switching to WSDISPLAYIO_MODE_EMUL for
> > some GPU models like Ice Lake integrated GPU:
Neither this one.
Maybe we have to check macppc VM changes?
---
Izumi Tsutsui
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@netbsd.org
Cc: thorpej@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls on
Power Mac G4
Date: Thu, 13 Jun 2024 04:39:48 +0900
> Maybe we have to check macppc VM changes?
git bisect shows:
---
7d632b8ba47400f8dd90e2764265a9747c581aca is the first bad commit
commit 7d632b8ba47400f8dd90e2764265a9747c581aca
Author: thorpej <thorpej@NetBSD.org>
Date: Wed Feb 24 16:42:38 2021 +0000
Add a provision for a per-cpu battable. Each CPU starts with the global
one, but this allows CPUs to temporarily switch to an alternate battable
if needed.
sys/arch/powerpc/include/cpu.h | 6 +++++-
sys/arch/powerpc/oea/cpu_subr.c | 12 ++++++++----
sys/arch/powerpc/oea/genassym.cf | 3 ++-
sys/arch/powerpc/powerpc/trap_subr.S | 26 +++++++++++++++++++-------
4 files changed, 34 insertions(+), 13 deletions(-)
---
I.e. the following commit causes this ATI Rage128 genfb(4) problem:
https://github.com/NetBSD/src/commit/7d632b8ba47400f8dd90e2764265a9747c581aca
https://mail-index.netbsd.org/source-changes/2021/02/24/msg127234.html
http://www.execsw.org/netbsd/changeset.cgi?id=20210224T164238Z.40f74c2f3ab23c266a2191d7d79f3c29dcf90b7d
Jason, could you take a look at this?
Thanks,
---
Izumi Tsutsui
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: thorpej@NetBSD.org
Cc: gnats-bugs@netbsd.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls on
Power Mac G4
Date: Tue, 29 Apr 2025 04:46:44 +0900
I wrote:
> git bisect shows:
>
> ---
> 7d632b8ba47400f8dd90e2764265a9747c581aca is the first bad commit
> commit 7d632b8ba47400f8dd90e2764265a9747c581aca
> Author: thorpej <thorpej@NetBSD.org>
> Date: Wed Feb 24 16:42:38 2021 +0000
>
> Add a provision for a per-cpu battable. Each CPU starts with the global
> one, but this allows CPUs to temporarily switch to an alternate battable
> if needed.
>
> sys/arch/powerpc/include/cpu.h | 6 +++++-
> sys/arch/powerpc/oea/cpu_subr.c | 12 ++++++++----
> sys/arch/powerpc/oea/genassym.cf | 3 ++-
> sys/arch/powerpc/powerpc/trap_subr.S | 26 +++++++++++++++++++-------
> 4 files changed, 34 insertions(+), 13 deletions(-)
> ---
>
> I.e. the following commit causes this ATI Rage128 genfb(4) problem:
> https://github.com/NetBSD/src/commit/7d632b8ba47400f8dd90e2764265a9747c581aca
> https://mail-index.netbsd.org/source-changes/2021/02/24/msg127234.html
> http://www.execsw.org/netbsd/changeset.cgi?id=20210224T164238Z.40f74c2f3ab23c266a2191d7d79f3c29dcf90b7d
After a few hours dumb printf debug with serial console, it turns out:
- NetBSD/macppc 10.1 INSTALL kernel gets panic at
genfb_pci_attach() -> genfb_attach() -> genfb_init_palette()
-> genfb_putpalreg() -> of_set_palette() via "gcc_set_mapreg" callback
that is set in copy_disp_props() in macppc/machdep.c
---
[ 1.0000000] trap: kernel write DSI trap @ 0x900000b0 by 0xff80b578 (DSISR 0x42000000, err=14), lr 0xff93dce8
[ 1.0000000] panic: trap
[ 1.0001160] rebooting
---
- It works around to disable ".ci_battable replacements" on OF calls
in sys/arch/powerpc/oea/ofw_subr.S:
---
diff --git a/sys/arch/powerpc/oea/ofw_subr.S b/sys/arch/powerpc/oea/ofw_subr.S
index 8e1bb806c39e..1e8a3b213d04 100644
--- a/sys/arch/powerpc/oea/ofw_subr.S
+++ b/sys/arch/powerpc/oea/ofw_subr.S
@@ -195,11 +195,13 @@ ENTRY_NOPROFILE(openfirmware_trampoline)
cmpwi %r5,0
bne 1b
2:
+#if 0
/* curcpu()->ci_battable = &ofw_battable */
GET_CPUINFO(%r4)
lis %r5,_C_LABEL(ofw_battable)@ha
addi %r5,%r5,_C_LABEL(ofw_battable)@l
stw %r5,CI_BATTABLE(%r4)
+#endif
lis %r4,ofentry@ha /* get firmware entry point */
lwz %r4,ofentry@l(%r4)
@@ -216,11 +218,13 @@ ENTRY_NOPROFILE(openfirmware_trampoline)
mtmsr %r0
isync
+#if 0
/* curcpu()->ci_battable = &battable */
GET_CPUINFO(%r4)
lis %r5,_C_LABEL(battable)@ha
addi %r5,%r5,_C_LABEL(battable)@l
stw %r5,CI_BATTABLE(%r4)
+#endif
lis %r4,clsrsave@ha /* restore saved SRs */
addi %r4,%r4,clsrsave@l
---
- or it also works to use explicitly battable[] (as before) in dsitrap:
---
diff --git a/sys/arch/powerpc/powerpc/trap_subr.S b/sys/arch/powerpc/powerpc/trap_subr.S
index d66515f039a3..3487eab5cb04 100644
--- a/sys/arch/powerpc/powerpc/trap_subr.S
+++ b/sys/arch/powerpc/powerpc/trap_subr.S
@@ -269,8 +269,13 @@ _C_LABEL(dsitrap):
/* get segment * 8 */
/* Get address of this CPU's current battable */
+#if 0
GET_CPUINFO(%r30)
ldreg %r30,CI_BATTABLE(%r30)
+#else
+ lis %r30,_C_LABEL(battable)@ha
+ addi %r30,%r30,_C_LABEL(battable)@l
+#endif
/* Add offset to the slot we care about. */
add %r31,%r31,%r30
---
I'm not sure what should be done to fix this issue,
but I guess the essencial problem is
"using an OF function to setup genfb(4) palette even after
VA region for the PCI framebuffer is mapped by bus_space_map(9)."
Possible workarounds are:
1) disable "have_palette" in macppc/machdep.c:copy_disp_props()
in case of PCI framebuffers that don't require genfb(4) in GENERIC
(i.e. chipsfb(4), gffb(4), pm3fb(4), tdvfb(4), r128fb(4), voodoofb(4))
because at least the ATI Rage 128 on my G4 Mac doesn't show
"green" kernel messages on INSTALL kernel (just "white on black")
2) set up "ofw_battable[]" for OF functions (which is currently empty)
properly, at least for PCI framebuffers
(not sure which regions are actually necessary for the fb ops though)
3) other alternatives? (replace dsitrap handler during OF calls?)
(I have few experiences of PPC BAT settings)
Thanks,
---
Izumi Tsutsui
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls on
Power Mac G4
Date: Mon, 28 Apr 2025 22:12:04 +0200
On Mon, Apr 28, 2025 at 07:50:02PM +0000, Izumi Tsutsui via gnats wrote:
> 2) set up "ofw_battable[]" for OF functions (which is currently empty)
> properly, at least for PCI framebuffers
> (not sure which regions are actually necessary for the fb ops though)
This all is very tricky, the best solution is to not call OF functions
"later" in the kernel, especially anything that could trigger changes
in mappings. For other functions we could merge the OF entries with the
kernel entries and keep them alive.
Can the palette stuff be done before we take over the MMU?
Martin
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@netbsd.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls onPower
Mac G4
Date: Tue, 29 Apr 2025 20:20:45 +0900
martin@ wrote via gnats:
> On Mon, Apr 28, 2025 at 07:50:02PM +0000, Izumi Tsutsui via gnats wrote:
> > 2) set up "ofw_battable[]" for OF functions (which is currently empty)
> > properly, at least for PCI framebuffers
> > (not sure which regions are actually necessary for the fb ops though)
>
> This all is very tricky, the best solution is to not call OF functions
> "later" in the kernel, especially anything that could trigger changes
> in mappings. For other functions we could merge the OF entries with the
> kernel entries and keep them alive.
>
> Can the palette stuff be done before we take over the MMU?
On macppc (with sys/arch/powerpc/oea/ofw_consinit.c) it doesn't
look to support early console detection at least for displays.
The cnattach functions are called during configure(9) and
Openfirmware console functions are used until genfb(4)
(or other PCI framebuffer drivers) are attached, like
sparc ports.
---
Izumi Tsutsui
From: Michael <macallan1888@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls on
Power Mac G4
Date: Tue, 29 Apr 2025 19:34:54 -0400
Hello,
On Mon, 28 Apr 2025 19:50:02 +0000 (UTC)
"Izumi Tsutsui via gnats" <gnats-admin@NetBSD.org> wrote:
> 1) disable "have_palette" in macppc/machdep.c:copy_disp_props()
> in case of PCI framebuffers that don't require genfb(4) in GENERIC
> (i.e. chipsfb(4), gffb(4), pm3fb(4), tdvfb(4), r128fb(4), voodoofb(4))
> because at least the ATI Rage 128 on my G4 Mac doesn't show
> "green" kernel messages on INSTALL kernel (just "white on black")
Hmm, the INSTALL config doesn't have any of the native drivers, only
genfb. We should probably enable at least the most common ones ( like
machfb, r128fb and radeonfb )
Without them the only way to change palette registers is via OF calls.
That being said, IIRC macppc bus_space_map() doesn't actually map
anything on 32bit hardware but relies on the entire PCI space being
BAT-mapped 1:1, there's a function in arch/powerpc/oea which tries to
figure out which parts we need and set up BAT registers accordingly, I
had to add stuff to that before to make trm work on a beige G3.
Although, if that was the problem we'd crash in native drivers, not OF
calls. This sounds more like OF's mappings not being properly restored
before calling OF, and
[ 1.0000000] trap: kernel write DSI trap @ 0x900000b0 by 0xff80b578
(DSISR 0x42000000, err=14), lr 0xff93dce8
is something trying to access the r128's palette index register,
apparently expecting 1:1 mapping.
have fun
Michael
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@netbsd.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls onPower
Mac G4
Date: Sat, 3 May 2025 09:55:58 +0900
macallan@ wrote:
> On Mon, 28 Apr 2025 19:50:02 +0000 (UTC)
> "Izumi Tsutsui via gnats" <gnats-admin@NetBSD.org> wrote:
>
> > 1) disable "have_palette" in macppc/machdep.c:copy_disp_props()
> > in case of PCI framebuffers that don't require genfb(4) in GENERIC
> > (i.e. chipsfb(4), gffb(4), pm3fb(4), tdvfb(4), r128fb(4), voodoofb(4))
> > because at least the ATI Rage 128 on my G4 Mac doesn't show
> > "green" kernel messages on INSTALL kernel (just "white on black")
>
> Hmm, the INSTALL config doesn't have any of the native drivers, only
> genfb. We should probably enable at least the most common ones ( like
> machfb, r128fb and radeonfb )
> Without them the only way to change palette registers is via OF calls.
>
> That being said, IIRC macppc bus_space_map() doesn't actually map
> anything on 32bit hardware but relies on the entire PCI space being
> BAT-mapped 1:1, there's a function in arch/powerpc/oea which tries to
> figure out which parts we need and set up BAT registers accordingly, I
> had to add stuff to that before to make trm work on a beige G3.
> Although, if that was the problem we'd crash in native drivers, not OF
> calls. This sounds more like OF's mappings not being properly restored
> before calling OF, and
> [ 1.0000000] trap: kernel write DSI trap @ 0x900000b0 by 0xff80b578
> (DSISR 0x42000000, err=14), lr 0xff93dce8
> is something trying to access the r128's palette index register,
> apparently expecting 1:1 mapping.
Is it possible to setup "ofw_battable" for such OF's mappings?
The problem was triggered by "per-cpu battable in cpuinfo" changes:
https://github.com/NetBSD/src/commit/7d632b8ba47400f8dd90e2764265a9747c581aca
https://github.com/NetBSD/src/commit/b4b0bdf37162bd57950a60dfdf755002dc307dcb
and it looks the "ofw_battable" is empty:
>> Additionally, in the firmware trampoline, point curcpu at an empty
>> ofw_battable. This ensures that the DSI exception handler won't
>> load a BAT register with a kernel block translation that clobbers
>> a segment translation owned by the firmware. Eventually, this ofw_battable
>> might contain some of the larger translations owned by the firmware.
---
Izumi Tsutsui
(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.
Home