Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls on Power Mac G4

["Izumi Tsutsui via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: thorpej%NetBSD.org@localhost
Cc: gnats-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
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@localhost>
 > 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