From nobody Mon Feb 12 18:41:55 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 4TYYGZ0DJbz5BKkZ for ; Mon, 12 Feb 2024 18:42:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TYYGY1WWSz4hd5 for ; Mon, 12 Feb 2024 18:42:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707763330; bh=Yd2DIrIA/QSXA+wsPbV5dwmQIQlse/+QachCcoyatx0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ouwnnp41isMVep5LIW9Zs+OCheOFdya+RRdq/6Ey7ByFhyhy6T3ycVf432kq2qUQ7AOh0gvebrEHCgEcZDjUOrsRj9ANxd/lM7m7Wp0MejTLNYHKc0smtH/1nMC2pAHAzV65e/zw/qxVGNcVDAUCn30F159MasIWs/DfFBSgVr4kFckGueg/bw4lzBgHTkxbznXovVPtAMgVCfN8m2Hi9yOXUQrQ5XANJyEmlF1DTWuCOymcW0XKVlnkPyKXgWy99EmXkDtc+n4OclvWEYIjwutZ2eHPupUPvLf7HfGqlB1XdUdcujXubzXG9WbiXWOfn7EcVYg4BNDymOkA4YvgfQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707763330; bh=kcG0vqm6PtEPB3dGxBQwRKT0umVjSv1YuBoAdKAX5p0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TnTytltks55wRUSUMhYOBwTMZz/Xn0ZZi4LvcsftYEfOWjxf43GHBvZLP++Tz1l/rFgdFjbPRlbzsjPXsv8yP1iVqEfr2T8opJWyciG/T2wg+xNut/qh46qUubajM0IQQ1V8Zt5aGPgfdwvv/3zyErs2KUtVcvH0TLbsTGj4j8an4q+Eba+DT8Zew3uCbCJqerSlc/BHLf067hz9QgzPLzFLDIyBKSzEpLTLRfCdh7ulF0KFcabnKX6nYrCuUlGi2uzg1NJjbI0oIZnaHGNuzeMsF9lyJ86lEUSaJD16qA7b8Qb8wT8QWV0w+W5lFphxrEGDao0KkmLR/mFlatbSeA== X-YMail-OSG: 50VU.9AVM1mhymbfJuxht2FXtzGb7OcxH53SHdpUffCyG9hh_5vLO.LYTHofVy. MrecZNVJo9Cr.im8JE0BD3SrEMc271mJvp9EZ_Hx8RY7WpDkp_Ab.Je9.Bk2wsJ.Uidfy4KuonIT jsLVW998urMrV8MSVFD.sxk34wvU1RYMHCfT8C7BvnPXwUp61UoOxv3ld5T9K6E7eJn8CKFhX19. zV8MTZk29QazdhH5Hh17IfYs1WuVnTwERfUD1bYFnI581we0aIX632IR1ZEMga9DrHxLysK1CVT_ MYZIn5AnolY1TNJ8GrM11fHlv2c2RtgVj.q_vZ0Nm2VMK416Rdq8VpfgyKQD6eFj_vxdlx0RRmr1 OxphENkPCphELkQvTTvBMo34nRZieWtVyBjlGSbRepBYZ5RfipfockEo_wVWa3NjWaHghkhdkT1x I4d0UWOFd7nxLuh0BXhelKnI39hrdTCIMBuvexlfJRZnJUzA1anmHOXc2j3rwfrLYfVjUYr9bBCc QeNYop9XJAoFZ.E1gW5x6TPaTNg9PNMdYsEkhXyUlIgAJ61ckq4hFTngjUaPTBbyT9v9T0XVKcOG HUgokDaNhy8pXofU5am2ycBGN1WPpnVGVDfLTWbahj2_s3faDPAoTjgTHl7mSA2XJBnksfAsmBW9 aHj3LMID0KCCYgDsdKEEF_3rFaeugHL1D.AWP1sNcfI6mUXpYKSa1ByVZEoYoeMAwrot1tOLrNsN ry0p.xU6fJnFpRN16RL4nTA_ElQsL8d9OL2UpG.LQ6mstz8thjwtW6q.Ls4XufxFXhlteKQlFqWV CrNv0WOj5gQdKbuVhdX4laCmf1UKiUS79YHE_HW9YCJfHpWOLSur2Pg6M0Grhz5vqPowpZLLHc0Z 8Xl8cHTUggN_u22mrcxf9BpulZv.kxCY89njWEieFRDOwt_79Jy1Kvz1M7Yzg1vVkaeQFUazVUIQ EsGom6AhSCVNemgLozTgWwtRc07A0094TPTu_FZxY7Ffavd5pMR213o5bIRiaWgvdhzhPOn7P3s. 89qyqF0bCCe_WPpaxhgva5gDrM_2zeWbF6AzMRUNTOVLX3tB.FKrvJw9FNAmdtp9cr4cdVsBDz4P zTWyTPvtLjR0b_WS9qnGV4LFchVYQa7qS.EikI7RgM474XeO6kMNvS2SLoa0uLdfb0Ytb0CIeSXc cxqCBQLKBLNxdsfsmWEe.C.cTzjdaFpsRgOEqQmBqLUAO_GlllnxIHxsxDmmerb8CnZLAUD_Dewp SeSp9oAuzkc7abeNCeHW2htdl95Wv6wlxIUfD35wKFjaX56GHjKpvnsl.8S8UQz8o.1G9ddDVc8P dZrAgQcQgzxY.sQ729tbOHlQ0FgzpRj3I98ASqSFiqpMvx0rigA4NIsAlMACaIwdhc2iAoHuZ2Hk z5LDh9KRrK1NEayOgV.c1QcqOeYFT9rz_Nwl8TFYQ56Q84PUiz9I9NauUVTSFl31kamtO0rkhpBy 8c3StunSeibwMIkqVikD5Zqi1ZpOYf_uQuleKYCh.zsixNnuZIXZipmGORs8LEd9Jn89ngBcnvZN y82njc6OEatuVFx5tlDrlM0kvvK0p9JCtKWXEUci.Gaw.V1RDMuoUV1LL_ZVL3I2aHDtZBJrjbUy _K6hPykkXUl4Uglpek1HXwh_SdJ0k.Tb.XO12gu0dc_HtBmBP1YYatT2Meyka2HdvTBKj6gjbVfG Qao8jWjHHI.tGsl9fXR7fv4eRzTpfCyUHcGtsnObiMgCHeRw8W_O1fRB2_hVD2._udyTwEvFWRWF WEB_7nPAMMBn5ZDcE1E76F0Uq8.684aYAy7f4GGvmDQBY46Eh4OH4zLfyIobY1en96cnARqRuKdE H0FaTjtjnTV46NiGk5DjlMNsnrRMYe3YqJyDdAKP5FwZaR8XRJaia3ViXxczwesQZWlnWtSmIA1O AcNTitZressfYLH54CRyxXd35rcNLBSs9tLfLM54yiLXfBrqnvuhsqqT8rZmAvB.iCgrFXTEQ2Vu vvOyVkZ8nYM5CBwFipje28FrDP797YdOPUIBpklkXRKRlRwpYYcrWGSHcCbkU3iHyBBE0WD7t63j vCS_nYPDhc2NtOeiden.05hvCQoiaFNTTWRDZ2.w9wS7Sgul1Pno2a_QjA0h8snxPM2c1zoS.yxw StUxXeIX88Bv3XT5nmgtIqgt0651QYmXeN5Em6yOmvA_gv9vYpyBDB.MsU3MvRlYrylFEQq3E0iw qh3cceHENqnV6u6nWRPj8XJnrQegdYrRxd.Iw8Z_.EeS.3THCYY8VskanlUboJYo56DUb8edH_Sk - X-Sonic-MF: X-Sonic-ID: 6b369b64-70c3-40aa-b0af-62fa45efb13c Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Feb 2024 18:42:10 +0000 Received: by hermes--production-gq1-5c57879fdf-27p5r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 040bb44139625531b00f5b5a08bc626a; Mon, 12 Feb 2024 18:42:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic From: Mark Millard In-Reply-To: Date: Mon, 12 Feb 2024 10:41:55 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com> References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4TYYGY1WWSz4hd5 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Feb 12, 2024, at 09:32, John Baldwin wrote: > 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 >=20 > 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. >=20 > 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. >=20 >> Detail: >> . . . >> pcib0: mem = 0x7d500000-0x7d50930f irq 80,81 on simplebus2 >> pcib0: parsing FDT for ECAM0: >> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000 >=20 > This indicates this is a translating bus. >=20 >> pcib1: irq 91 at device 0.0 on pci0 >> rman_manage_region: request: start 0x1, end 0x1 >> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, = count=3D0x100000 >> 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 >=20 > 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. >=20 > 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. >=20 > Logging the return value from rman_manage_region would be the first = step I think > to see which error value it is returning. Looking at the code in sys/kern/subr_rman.c for rman_manage_region I see the (mostly) return rv related logic only has ENONMEM (explicit return) = and EBUSY as non-0 possibilities (no other returns). All the rv references = and all the returns are shown below: int rv =3D 0; . . . r =3D int_alloc_resource(M_NOWAIT); if (r =3D=3D NULL) return ENOMEM; . . . /* Check for any overlap with the current region. */ if (r->r_start <=3D s->r_end && r->r_end >=3D = s->r_start) { rv =3D EBUSY; goto out; } /* Check for any overlap with the next region. */ t =3D TAILQ_NEXT(s, r_link); if (t && r->r_start <=3D t->r_end && r->r_end >=3D = t->r_start) { rv =3D EBUSY; goto out; } . . . out: mtx_unlock(rm->rm_mtx); return rv; int_alloc_resource failure would be failure (NULL) from the: struct resource_i *r; =20 r =3D malloc(sizeof *r, M_RMAN, malloc_flag | M_ZERO); (associated with the M_NOWAIT argument). The malloc failure would likely go in a very different direction. Side note: looks like the EBUSY cases leak what r references. > Probably I should fix pci_host_generic.c to handle translation = properly however. > I can work on a patch for that. =3D=3D=3D Mark Millard marklmi at yahoo.com