From nobody Mon Feb 12 20:00:16 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 4TYb0x1lS6z5BTMX for ; Mon, 12 Feb 2024 20:00:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (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 4TYb0w38rcz43F5 for ; Mon, 12 Feb 2024 20:00:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kbzG8HaK; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707768029; bh=G8j0tnRXRCO2xAZjQvWZnJ4hPvXSgdIDKRGQKVs/SVI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kbzG8HaKxtvkCoILEfYw9jWzvCRGccLjQU+f9hHnZmF9ZahGWxDhcLZtQdK/UzcuJ/TH3EduXee8Gs08GtuGq3j9EcIQGO3xcxCCoBhc08XXJfjCrkThoEyj86HESvN85UK3wfSZDutVMdxAG4TLdcCE9Ffgst8BW/NjsJdpdd4cGe2dO4DHOsiqjEgnw77dLFA+iou80vG91I6avtqsqEudXnZihsVf1L+DHlwmVQuwGvTWRrmM/mcD/uQVSEBu3/GLfwC3JnGSRnHKDqrOO0b69XtYCgm/Qo9icfhMTo764yKCBMP/91TacUWBvTWabCNueXSt5LufGSKIM0M4XA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707768029; bh=ts6CMOyIS7djgJxcf2y2dNlZjt3Y6hiSnSdAeIfgnCH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=GC6rMmiU6a+ryTOd+9/3qR9RLM05pdwb6FxtcixkrJA05W0OVv2eZMEti8oowlgnBHyD8h9/tFjh/s8MB8JolaRyxv1UGCA2KNS6wH+IRagm0yIGcckH2OWq1QYPr4np4EceeSmckg6bBaY3YS7JEbPepBwUag/B5UStFhC0tZUywqkp9Ak3LoKAZ2sAYvAInuToQ0bQiJCYSnw5FqkIJsDzAe6zUmyhjAxr5+nz1JmTOLGVTRU+yQi7cf59Dmy/OYbmTtKn+GSNs+cXUq7w7B5RHflr5k4ft/Vr3G2yznKHRYLGdzdNQJ4Tho7XK/6BVv6U3t8hAyHaCYJTg4CB6Q== X-YMail-OSG: gxcR.tsVM1mhndE7Dc4gWvyNQvxEm2tIM.TSMNtir8..IfpVAHMn1Zo4ipTsywm DQy194QeI_1UUHFerRzVyulbSpkYdedfJ411b0vmGJkCSVv4dZJTy2BJb1qD_wwYc9r4eEwypZPD G.VuL.5CFr.y8c567ou_Gbx5dYJfDPWiO677CqEWvRLMu42tt0fsL5QG3rRpVnQ_jGShEpZNrt2p wGSL1SBzoKVtYfAmSFWAeb_Bo.PhN0APCYHdC..3Jsi7vFnlKDgTySpK4_ERZMLIJzeqDZyU2bLc b0ALzKYLk6CFqIHTRToOgL_jKYzYznSQM3ckMehbIIUipSCi7KU6iUMFdxZtQtpQUggZaHeQP1P8 Bj2bqvG1sWmPu1dGLXPPAlVx0vK0lbWPeh8h9iqtVnkS7lVDi25K3GyZgYLWrr3za1rIVkOGBqhC lXWwazIEuISC05OHBoJoTF3ulrrw722EWCtEnB.7PDQX6BZlQFtgsSRbJFYt1zwD5hpan5JmCb1F _xBA1_UBBCU9hJ8bmz_2AwRXcQxniA_BvQ.ts.KMWam4tNXxjEa0Li2zhc1ngDxWOAQxOWOQJqI0 xy3BX.BCPJkL7b_R3KJ0aEm_dKkPoLjTN8S5NxMMPlm.W07ei9LQq9E1KdH9PS_b0Zu8ju2zYc9i 0wlqbeM8.RHBicdVExEJUbu.uLUwHAEepsLZwYuJeP3MvR2KF8Aq4pggT5TAhcN0GEWNu10jbE4W JZW77q.RNJyJghSS59eTFQE7Jh5GZLi.7kCqz68PxKr4k4LTTl2GiYDmsyXrNJK8bZeGv1d4gqQN ofW92t_pFZcfQQBLKeiMu5CC8_C4CszQMzUswEnaMrDfWCwyzzQgKmfOn0sSYD.Ah9AMf5PT.AXs IgfvV0GSwrT8IP__1.yS9vTeZoYAx_R6CWWh2GldRgLaPWDiPBymX.rw1.G2RLlMAz3NJqS47XLS hY7knZuYZxdvwQQV4GciTdms2DNz7gsXubOuOSBXPh3DML.aC7lsKpcDi7nQ4Orwsky3zduCfG2v EC5BXKeAATRVGrImJyG1EhAkM1c2LQa4u7lnUk9Wb87cJho1tCUjVGi6qTlzJdMAw9k1vKGZaLWg .uWsDaHa5Hcu5NirCAligClxMzGH3l5zhbGRcmXQUlxwS1TrMJXCcbYhklxX5NjmvhkrfYF5jC9N 6bxfJBVEr1jdoGhI57MJ1s_6MeTLDETXU9PKf.lZIur2fkFO57VU4S5UgkJOdVpUspOb6Zh0bs1I CVvHlTtWfwYYhBe.1aAMY2oNtU2dZNFDcCaU5xQkiW1bhoQ9lH3rTSRMNWT46nXnSIgXxYgHXJ8l wbTqIR6lnBDyLeIWiuiX5DjYaphXOcXziuy9sWJljgyMLxOtDG98__tSqYyZmKl.htm3dTtw47Pt Egt3qB0hDQdJIzoS1CnkSP8CE2kBZrMpr.F8BnY.ko3chIJilDJBcuiorHQZkLNi0p9pL0FYqMHF _EzACguOu5TuG1Zy0iULI_tB._sPA2VkmpfgPDDqHej98aS.nat1Y1UYX75hQ26fEuYS.hbrEAKL KR3U_dsdH5Msbh0WDvrXuwy5kihQSfEp0xKVQ4DJ6Rb51QIujdgBB65Lw3jlWhhaCLSs1NzQVEvT McM29l34CTnZ.a17wAYHI.QOZTRZQXqwZhTTwF7Z1__rV1r8Q3fEBWXvis4ZoVA0N4K9doz4y_rh _gY8u7f7mFAPl0F6kuQX_8gqYTb7rHWiN2.WYU7EmBnBFNV3UumhtlVH5g0qANIcTFhkJmVXkktD zyYv_HXTBJUvbjkzFPFTpOxFzo8QNbwDfa8t5jaXBazsbS63tLXGKizpEIFvh2rKGDhMOL2jmaQJ KMGGfPNcZtvKS4Otpm6v4.KRDtXsfRv4Pn3rt5f81wl_Jbc_48FgmxViWr7APOoC5Lf1iC2Z4ekd zcmoeLPC_PyeaYUawqsGwLPRPx3L7Oj4RRmU20zFcs1ZQG1FDbbdug0ecukEwN.08Wkj8zDbR..S xZz5D5em96sf7Da35WCdOiP.ocRWIyLFPjWaNIvNi1oINqFbhNSplTU3KI4YJL3hWmYzJXKfCH1q S8Og3fxJ5NpGYU01unSGWy48TDOxIvOBDeGlhkYKDev.jOSz7JsnkgCs19B0yFAxBfi9_yLW33i5 hnsxUMScWxhOeyl9mz_3VNlwtpl_ROm_x4S2iLMgc2pm4JVT3oJZ8akEX74sOu2uJoJrYtqDW4LR 78h7tC6tBmu2rMWQeReR7F3Wc4hCRFvjvFFfzNy4yNtZ.v2j0HawnHQoZ8E30wOZzs5f3XDY46ts - X-Sonic-MF: X-Sonic-ID: 6c6cc0f3-3a3b-4919-ad8f-cddc5ce9064e Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Feb 2024 20:00:29 +0000 Received: by hermes--production-gq1-5c57879fdf-qprqq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0ec8a9cfc035de1a91425f5ef22695fc; Mon, 12 Feb 2024 20:00:26 +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: <1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com> Date: Mon, 12 Feb 2024 12:00:16 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com> References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4TYb0w38rcz43F5 [Gack: I was looking at the wrong vintage of source code, predating your changes: wrong system used.] On Feb 12, 2024, at 10:41, Mark Millard wrote: > On Feb 12, 2024, at 09:32, John Baldwin wrote: >=20 >> 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. >=20 > 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). The modern code also has EINVAL via an explicit return. > All the rv references and > all the returns are shown below: >=20 > int rv =3D 0; > . . . The modern code also has here: DPRINTF(("rman_manage_region: <%s> request: start %#jx, end = %#jx\n", rm->rm_descr, start, end)); if (start < rm->rm_start || end > rm->rm_end) return EINVAL; Adding rm->rm_start and rm->rm_end to the message might be appropriate --and would also be enough additional information to know if EINVAL would be returned. > 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; > } >=20 > /* 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; >=20 > int_alloc_resource failure would be failure (NULL) from the: >=20 > struct resource_i *r; >=20 > r =3D malloc(sizeof *r, M_RMAN, malloc_flag | M_ZERO); >=20 > (associated with the M_NOWAIT argument). >=20 > The malloc failure would likely go in a very different direction. >=20 >=20 >=20 > Side note: looks like the EBUSY cases leak what r references. Still true in the newer code. >> Probably I should fix pci_host_generic.c to handle translation = properly however. >> I can work on a patch for that. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com