From nobody Sat Nov 25 18:30:13 2023 X-Original-To: dev-commits-src-all@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 4Sd0lD00Msz52S2m; Sat, 25 Nov 2023 18:30:16 +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 4Sd0lC6J20z3dmw; Sat, 25 Nov 2023 18:30:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700937015; 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=m2VywToliUyTTMXWJc/U7M1LdUtbA8uR5Tqk5kyS3pE=; b=iRmY03dtrtDL66a84EAUhz/HQ1LcwvsaOF6Xb6n7TReSyyN1m5akhn8FEORm7YHbuN0EGH 17Egho46ruvUXTDF+ziTuuBmdCh8a8ElnErMKcEEQSLslCkcynzWcWJi1izLXtI7sDwMoY GMbk79Eftld3n+EzV/jWKxH3Ioj063DWWTmcFbUZB0cTEO1OW9eRIt/8eJQupIkHW9V1NZ p4XkhgLboGMIQgaNISB2pjdT6I8kOsuYreCDWtoUmXzu00l65b9Ptv9NdwgR8dZ5N7YPOx ePxJuk262sZh1u6vGXVImXHsMtvLJQeakLNS8fhT5VP4PtUkv9nfX37niCS1qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700937015; 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=m2VywToliUyTTMXWJc/U7M1LdUtbA8uR5Tqk5kyS3pE=; b=by14rzhskcXkyA3a/8ipCyyPsdzQ250XmAipHcqNunbv5cnE99lUqXvZSrUDTLm9+ZRSDA qIk6gG28e45BM3oZNb13XOiN0w68EFkSwzx8jbaQH1Bco6QC4SyIBfoy95RVGkY136Z0X0 BdR8zK3ErhR4wI3Ibj68Rl+Kyz8KH4hE9G2aweNVz2+Io6REbmwPBggOtVa+Uj3zvWjEJA coqPulcDF8rmkdxPUeSxg3nQBnMXKYpaV9ZkKzyRlOo2FmnT7J2N6fwZd98b2av+yT04eB SyyZG/peqZIvr7dymNLIeD+CFNeiPyP4v9eUvynqbIZMhgyWHw5QIYXCPy9Ryw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700937015; a=rsa-sha256; cv=none; b=W7IJAALgenKj0rFROTbA8gstaIc9P6KiHB1g4v9LpTHI3w63gfolJR7oDQrVHhwU+IW/bz x0E2XvgJSVs+Xc4NAi9KnY3Oqos+93ujRvn8HcstXMJiAZfuQ7TD0PXfwohQKFA/CClViD qDXIx2tVwGs5/OD2wupcv1vsbFfRBfn4q9u8Jh3xDQisNTGhFy5VEaBZQ459Bz5jWNqcdL UH/mdPNzYNePGLFJrv0JobZjd65NrusUD8cIOqhl7T7XpZEDGf+Y10q5FkPGZDpz3p9CTl KYTs2J3lw3FKIkOkMWi+KnCBnEQrTCsXgpuErdojSqCQI97v/fAvK3wSXwjRjg== Received: from [IPV6:2601:648:8384:fd00:815b:80c5:5564:2a43] (unknown [IPv6:2601:648:8384:fd00:815b:80c5:5564:2a43]) (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 4Sd0lC1tfFz13LB; Sat, 25 Nov 2023 18:30:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <0e2a051b-d676-4f28-b0c6-60b5409d931e@FreeBSD.org> Date: Sat, 25 Nov 2023 10:30:13 -0800 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: 19f073c612af - main - new-bus: Add resource_validate_map_request function Content-Language: en-US To: Konstantin Belousov , d@delphij.net Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202311231707.3ANH758D008755@gitrepo.freebsd.org> <934faa57-60d2-4be7-bdd3-e64c62ae71ad@delphij.net> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/25/23 12:39 AM, Konstantin Belousov wrote: > On Fri, Nov 24, 2023 at 10:49:06PM -0800, Xin Li wrote: >> On 2023-11-23 09:07, John Baldwin wrote: >>> The branch main has been updated by jhb: >>> >>> URL: https://cgit.FreeBSD.org/src/commit/?id=19f073c612afa0111d216e5ccab9525bfc97ec32 >>> >>> commit 19f073c612afa0111d216e5ccab9525bfc97ec32 >>> Author: John Baldwin >>> AuthorDate: 2023-11-23 17:06:24 +0000 >>> Commit: John Baldwin >>> CommitDate: 2023-11-23 17:06:24 +0000 >>> >>> new-bus: Add resource_validate_map_request function >>> This helper function for BUS_MAP_RESOURCE performs common argument >>> validation. >>> Reviewed by: imp >>> Differential Revision: https://reviews.freebsd.org/D42723 >> >> After this change my kernel panics with: >> >> HPTS is in INVARIANT mode!! >> random: entropy device external interface >> kbd0 at kbdmux0 >> WARNING: Device "spkr" is Giant locked and may be deleted before FreeBSD >> 15.0. >> vtvga0: >> aesni0: >> acpi0: >> acpi0: Power Button (fixed) >> cpu0: on acpi0 >> hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >> panic: bus_generic_rman_activate_resource: rman 0xffffffff81222770 doesn't >> match for resource 0xfffff80003d1a400 >> cpuid = 0 >> time = 1 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xffffffff82d5c880 >> vpanic() at vpanic+0x132/frame 0xffffffff82d5c9b0 >> panic() at panic+0x43/frame 0xffffffff82d5ca10 >> bus_generic_rman_activate_resource() at >> bus_generic_rman_activate_resource+0x146/frame 0xffffffff82d5ca70 >> acpi_alloc_sysres() at acpi_alloc_sysres+0x81/frame 0xffffffff82d5cab0 >> acpi_alloc_resource() at acpi_alloc_resource+0x106/frame 0xffffffff82d5cb70 >> bus_alloc_resource() at bus_alloc_resource+0x9b/frame 0xffffffff82d5cbd0 >> hpet_attach() at hpet_attach+0xb4/frame 0xffffffff82d5ccb0 >> device_attach() at device_attach+0x3bc/frame 0xffffffff82d5ccf0 >> device_probe_and_attach() at device_probe_and_attach+0x70/frame >> 0xffffffff82d5cd20 >> bus_generic_attach() at bus_generic_attach+0x18/frame 0xffffffff82d5cd40 >> acpi_probe_children() at acpi_probe_children+0x226/frame 0xffffffff82d5cda0 >> acpi_attach() at acpi_attach+0x97b/frame 0xffffffff82d5ce30 >> device_attach() at device_attach+0x3bc/frame 0xffffffff82d5ce70 >> device_probe_and_attach() at device_probe_and_attach+0x70/frame >> 0xffffffff82d5cea0 >> bus_generic_attach() at bus_generic_attach+0x18/frame 0xffffffff82d5cec0 >> device_attach() at device_attach+0x3bc/frame 0xffffffff82d5cf00 >> device_probe_and_attach() at device_probe_and_attach+0x70/frame >> 0xffffffff82d5cf30 >> bus_generic_new_pass() at bus_generic_new_pass+0xed/frame 0xffffffff82d5cf60 >> bus_set_pass() at bus_set_pass+0x36/frame 0xffffffff82d5cf90 >> configure() at configure+0x9/frame 0xffffffff82d5cfa0 >> mi_startup() at mi_startup+0x1c8/frame 0xffffffff82d5cff0 >> KDB: enter: panic >> [ thread pid 0 tid 100000 ] >> Stopped at kdb_enter+0x32: movq $0,0xa388b3(%rip) >> db> > > Me too. > > But in my case, it is not HPET but atrtc_acpi_attach(). I think I know why this is, and I'll have to disable the assertion for now. Logically speaking, bus devices should not be passing resources they've created form their internal rman's up to a parent device to activate. Instead, when a device allocates a rman such as the sysres rman for ACPI, or the windows for PCI-PCI bridges, it allocates a real resource from the upstream bus and then uses an rman to sub-allocate that resource to child devices. What these bus devices should be doing (eventually) is taking a request to map one of these resources and turning it into a request to map the corresponding window (subset) of the resource allocated from the parent. bus_map/unmap_resource are designed to facilitate that. For now I can quiet the assertion, but I will fix the ACPI bus eventually. This also provides a better way to handle "translated" resources btw as a host bridge that does translation (e.g. of PCI BARs) should allocate the "translated" resource from the parent and use bus_map/unmap to activate regions of that parent resource to use as mappings of the child resources allocated from an internal rman in the bridge driver. However, fixing all that requires having proper bus_map/unmap up in all the nexus drivers which we don't have yet (I have most (all?) of them fixed in a branch that these recent patches came from). I'm not sure why the VM I tested booted didn't trip over this case though as bhyve VMs do have ACPI devices that allocate from sysres ranges. :( -- John Baldwin