NetBSD Problem Report #59176

From martin@aprisoft.de  Fri Mar 14 11:40:23 2025
Return-Path: <martin@aprisoft.de>
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 0B4F31A9239
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 14 Mar 2025 11:40:23 +0000 (UTC)
Message-Id: <20250314114014.14AC35CC7DB@emmas.aprisoft.de>
Date: Fri, 14 Mar 2025 12:40:14 +0100 (CET)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: bogus call to oea_iobat_add() in rbus_pccbb_parent_mem()
X-Send-Pr-Version: 3.95

>Number:         59176
>Category:       port-macppc
>Synopsis:       bogus call to oea_iobat_add() in rbus_pccbb_parent_mem()
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-macppc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 14 11:45:00 +0000 2025
>Last-Modified:  Mon Mar 17 08:25:01 +0000 2025
>Originator:     Martin Husemann
>Release:        NetBSD 10.99.12
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD gethsemane.aprisoft.de 10.99.12 NetBSD 10.99.12 (GETHSEMANE) #393: Tue Mar 11 10:41:48 CET 2025  martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/macppc/compile/GETHSEMANE macppc
Architecture: powerpc
Machine: macppc
>Description:

I have a PCI cardbus bridge in one of my Macs and it shows up at OF level
as:

name                    cardbus 
device_type             cardbus 
compatible              pci1180,0475
                        cardbus-bridge
model                   XXX,PCIXXXX-81
reg                     00009800 00000000 00000000  00000000 00000000
                        02009810 00000000 00000000  00000000 00001000
                        01009844 00000000 00000000  00000000 00000004
                        21009898 00000000 00000000  00000000 00000010
#address-cells          00000003
#size-cells             00000002
[..]
assigned-addresses      81009844 00000000 00009010  00000000 00000004 
                        81009898 00000000 00009000  00000000 00000010 
                        82009810 00000000 a0102000  00000000 00001000 

and attaches as:

cbb0 at pci1 dev 19 function 0: Ricoh 5C475 PCI-CardBus Bridge (rev. 0x81)
[..]
cbb0: cacheline 0x0 lattimer 0x10
cbb0: bhlc 0x21000
cbb0: interrupting at irq 53
cardslot0 at cbb0
cardbus0 at cardslot0: bus 1
pcmcia0 at cardslot0

The code in rbus_pccb_parent_mem() has a strange XXX clause:

        node = pcidev_to_ofdev(pa->pa_pc, pa->pa_tag);
        OF_getprop(node, "assigned-addresses", reg, sizeof(reg));

        start = reg[2];
        size = reg[4];

        /* XXX PowerBook G3 */
        if (size < 0x10000) {
                start = 0x90000000;
                size  = 0x10000000;
        }

        oea_iobat_add(start, size);

Now this has multiple issues. The "unit" of size passed to oea_iobat_add()
is in BAT_BL_* defines, the firmware says 4 which would be BAT_BL_256K.

The "XXX PowerBook G3" code seems to work in units of bytes instead, and since
this if is not conditionalized on the mainboard model, this all goes very
wrong (the size < 0x10000 triggers for all valid firmware values and the
size  = 0x10000000 is an invalid input to oea_iobat_add).

Even with this XXX if() fixed, it would panic in oea_iobat_add() as that
does not allow anything below 8M BAT entries:

void
oea_iobat_add(paddr_t pa, register_t len)
{
        static int z = 1;
        const u_int n = BAT_BL_TO_SIZE(len) / BAT_BL_TO_SIZE(BAT_BL_8M); 
        const u_int i = BAT_VA2IDX(pa) & -n; /* in case pa was in the middle */
        const int after_bat3 = (oeacpufeat & OEACPU_HIGHBAT) ? 4 : 8;

        KASSERT(len >= BAT_BL_8M);

So I better not insert a cardbus card that requires a mem mapping.

>How-To-Repeat:
s/a

>Fix:
n/a

>Audit-Trail:
From: Michael <macallan1888@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-macppc/59176: bogus call to oea_iobat_add() in
 rbus_pccbb_parent_mem()
Date: Sun, 16 Mar 2025 19:23:43 -0400

 Hello,

 That is ... strange.
 I used cardbus and PCMCIA cards in powerbooks, but those were either
 wifi or USB, so no memory ranges.
 Looks like that's supposed to be the memory space assigned to the
 bridge, which on my alubook at least, isn't in reg or
 assigned-addresses. Instead there's 'reserved-segment'. It's in
 'ranges' as well.
 Same on Pismo.
 I think I can see where that came from though, the 3400c has this:
 assigned-addresses      82009800 00000000 a0000000 00000000   ................
             0010:       10000000 82009810 00000000 80804000   ..............@.
             0020:       00000000 00001000 81009898 00000000   ................
             0030:       80801000 00000000 00000010 ........
             ............

 IIRC we BAT-map the entire PCI space anyway so this seems kinda pointless.

 have fun
 Michael

From: "Michael Lorenz" <macallan@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59176 CVS commit: src/sys/arch/macppc/macppc
Date: Mon, 17 Mar 2025 08:23:13 +0000

 Module Name:	src
 Committed By:	macallan
 Date:		Mon Mar 17 08:23:13 UTC 2025

 Modified Files:
 	src/sys/arch/macppc/macppc: rbus_machdep.c

 Log Message:
 when looking for the cardbus bridge's memory range:
 - check 'reserved-segment' first, all core99 machines should have it
 - if that fails, look at 'assigned-addresses' which has the range on older OF,
   notably the 3400c
 - if that doesn't return anything useful, fall back to the default
 should fix PR59176


 To generate a diff of this commit:
 cvs rdiff -u -r1.20 -r1.21 src/sys/arch/macppc/macppc/rbus_machdep.c

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

Home	PR Database Search