From nobody Mon Feb 12 17:32:34 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TYWkF2YQ6z5BCXl; Mon, 12 Feb 2024 17:32:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TYWkF0gVcz4LrM; Mon, 12 Feb 2024 17:32:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707759157; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LsyJLlg3EirIgXm1spHayzb3Tu9WXObkdrJBXLjF7dk=; b=lvIC3N0tuOvBoWEz2v+riXovBl+OKlRVs3GRQG5jGMsx0JE1Bj2IUIJ2J7HC+I3bS6JH5s 7xXdU9Q4pEXmsUZpGrNhmkiXbV2HlASjT0FkLciwCMFNEi2+SYHfiRG5ehrmzU+K/BEo06 +ex6WhDubZdXGV8dgqyjm9/NMHAr+4z2x8mCGtpa1YdJAFm9jqxTVpFmE94NAYRf+MGTR7 gt5bMuWMQwme9dGtofa15XV15e+4t+wPmgZ1HLo/l7tpXB6EVbtHnXs86lV2RnQRQM8je4 alCPWDO/DHbu15fK92eFCDfpp4fvuhqxnbBN6DzbsZA/WhFpN3z6bx2JBuOYgw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707759157; a=rsa-sha256; cv=none; b=IMEaPIfAHELyBe6wiyKiEM3t0uyAqly3U8HuKSv8Hl05qRIqDVMoKoWkIx+3npVEXTDVtt p48+w+nivJHlOZ8BZ/TS5RYAoF1MpQnm/7ZbQM2VXBFnU9+b8H8HtvESmZeLmDNckASu0N /xmdJSp2+bs9AtTYee9cEH9bqBi/NEs0enRvxJbe6UrPG1lq5ekkRAD6mHhbZcCM0N7kM/ WdHpcIuCuNnAB+tnsiMHakRwLm+sSFmq3TDo1U+XVZQVO3dgk0YWzen88pLsmtW6TtBrud 5mjJ1Wpwkre3J1933G4kDTqiJkjeBLGlh0mw+08C6k3xL/cjIWIwT8Xqe6ul1A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707759157; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LsyJLlg3EirIgXm1spHayzb3Tu9WXObkdrJBXLjF7dk=; b=fz8Gxhqmjf1WxMCSwiu1XDcxZKmxN2CLXbQH4brHe1JAgfLrmxLKoY1pLC/PssnT1ObM+l U/CAnceU20/V3lW2xBZEQARITEgtd+nbJSmPdGTG4aK7tqLwVBKkaj3LnJNZMd7YDAu46L u0yZgAto3FD15IekoSb4ZruiUDAO2nRrBLX3pWhg1PRBTSGYf5HmR7cLEl2QtMLx6ngOMk 3xUyMexxgzSJHyTf5mIOJBlPlFOgOK/VC0luPEef681nVJORszLdyNzDAY6mmsw041iXM1 FH1hPi3wSz+1C75I1r47VZA2PfxZbBSc1voebXr4BPQhjnzY/lWKXk4B6ji6KQ== Received: from [IPV6:2601:644:937c:5920:4c63:23c7:5c22:d7ba] (unknown [IPv6:2601:644:937c:5920:4c63:23c7:5c22:d7ba]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TYWkD3XvBzTfh; Mon, 12 Feb 2024 17:32:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Mon, 12 Feb 2024 09:32:34 -0800 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic Content-Language: en-US To: Mark Millard , FreeBSD ARM List , Current FreeBSD Cc: Warner Losh References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> From: John Baldwin In-Reply-To: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/9/24 8:13 PM, Mark Millard wrote: > Summary: > > pcib0: mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2 > pcib0: parsing FDT for ECAM0: > pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000 > . . . > rman_manage_region: request: start 0x600000000, end 0x6000fffff > panic: Failed to add resource to rman Hmmm, I suspect this is due to the way that bus_translate_resource works which is fundamentally broken. It rewrites the start address of a resource in-situ instead of keeping downstream resources separate from the upstream resources. For example, I don't see how you could ever release a resource in this design without completely screwing up your rman. That is, I expect trying to detach a PCI device behind a translating bridge that uses the current approach should corrupt the allocated resource ranges in an rman long before my changes. That said, that doesn't really explain the panic. Hmm, the panic might be because for PCI bridge windows the driver now passes RF_ACTIVE and the bus_translate_resource hack only kicks in the activate_resource method of pci_host_generic.c. > Detail: > > > . . . > pcib0: mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2 > pcib0: parsing FDT for ECAM0: > pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000 This indicates this is a translating bus. > pcib1: irq 91 at device 0.0 on pci0 > rman_manage_region: request: start 0x1, end 0x1 > pcib0: rman_reserve_resource: start=0xc0000000, end=0xc00fffff, count=0x100000 > rman_reserve_resource_bound: request: [0xc0000000, 0xc00fffff], length 0x100000, flags 102, device pcib1 > rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xfffff> > considering [0xc0000000, 0xffffffff] > truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 (requested 0x100000) > candidate region: [0xc0000000, 0xc00fffff], size 0x100000 > allocating from the beginning > rman_manage_region: request: start 0x600000000, end 0x6000fffff The fact that we are trying to reserve the CPU addresses in the rman is because bus_translate_resource rewrote the start address in the resource after it was allocated. That said, I can't see why rman_manage_region would actually fail. At this point the rman is empty (this is the first call to rman_manage_region for "pcib1 memory window"), so only the check that should be failing are the checks against rm_start and rm_end. For the memory window, rm_start is always 0, and rm_end is always 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new (0x60000000 - 0x600fffffff) ranges are within those bounds. I would instead expect to see some other issue later on where we fail to allocate a resource for a child BAR, but I wouldn't expect rman_manage_region to fail. Logging the return value from rman_manage_region would be the first step I think to see which error value it is returning. Probably I should fix pci_host_generic.c to handle translation properly however. I can work on a patch for that. -- John Baldwin