From nobody Mon Oct 28 23:03:24 2024 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 4XcppN52ZWz5btbn; Mon, 28 Oct 2024 23:03:24 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XcppN45W2z57l6; Mon, 28 Oct 2024 23:03:24 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730156604; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=LIpQa8gdVDoAphPZ/th+GFFNZMaGczSJPGUdQ++19yg=; b=Q2hbQ0tQ8u3VMW+7ZHwRkKweSCZEUW3fegfLbkRJ53UOA4/kVogvc0OudxirakOfDbjk9T 7DQoKGHo/m8GUnOW7tTrGAG7yOekMcYl7/Kh+W+MINif1s7QO367oHZCl7ksQlC8JDw0EY Fil9f8TszTAbrokTLMVTsZVoK9sVxMkCNq/qsaYWZJUOpLp2rwU8LyAQfW9spRPY/kOiMJ 2wcExe4V8yq13N0ERAzUIEO1iSpNQ1K64B2cY1cw3BA7B7S3hdZsGRxI/+GDmuU41h3pxK dBr9VxQwMVvlDAA+sH1Vbc88TcYhGBPOje4q6/ePAd8TXG8F7soZRvvK2f22dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730156604; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=LIpQa8gdVDoAphPZ/th+GFFNZMaGczSJPGUdQ++19yg=; b=PidvuGsx/UA8PICgFRCZfLnL8Tta/T7Rpfypx7cbYJmWaYiEBtDaW8TgtnUQvP/ZxtAKNP Te5IAcysjm3SuHTd27R8HPNYtSgFlBvq0E3aokuJ6oFi0I+PF+YH5hHUDaqa/q+qX0pRSr cdjImJ6en+x98DHk3QgOjcw7kfEPjzbgrcXKjnuDWug2cROJ29JaLHsgs0f2mk/+DpV7S7 WnQKvE7BHZDgnV/shGsqby+788diaAaBwfy1+P9xMsNH7PILqD1/JF7pJCAixF5eV4PLsy cXEAB9sIaL+jUj/ywmAs72qxw49lZr8mHv7MPMKgTTUDUMqELZVJGq9mjol2Cw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730156604; a=rsa-sha256; cv=none; b=sJq0rlHNom4CN8PPtoNqWHT2TXnh29eaP1wegmhugtYMvFnrA2X3iUNs0MYMxdNXNAWsML gR0VGwpEQPGhc+geSxlyNYFd1++CdXRlF4MIoiq1o12kMSDExhcDVQWLVORHnYNdJ+UvZi 32SrrV5ZYEKqvpfgKeG57OxpXs4w+cRq8lAaXINDNLSBU91k0tY7rZQ4gmJPsy3WGLMx8a l+ptp+NAbYJSXliANCp0iwJDEIrmOVLInGbpqw1GkXXzgk2Q3C+9Rn3cbbG4Xsmf0/tBt+ MtuZcc8i241wWzRXc7Hn8j7o3XbYKvJQceA9VVT2zL7HAkVGtv+DNPVuonApDg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4XcppN3cJCzxyp; Mon, 28 Oct 2024 23:03:24 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.18.1/8.18.1) with ESMTP id 49SN3Osu024161; Mon, 28 Oct 2024 23:03:24 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.18.1/8.18.1/Submit) id 49SN3OnE024158; Mon, 28 Oct 2024 23:03:24 GMT (envelope-from git) Date: Mon, 28 Oct 2024 23:03:24 GMT Message-Id: <202410282303.49SN3OnE024158@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-branches@FreeBSD.org From: Andrew Gallatin Subject: git: ee373c1234d3 - stable/14 - acpi_ged: Handle events directly 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: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: gallatin X-Git-Repository: src X-Git-Refname: refs/heads/stable/14 X-Git-Reftype: branch X-Git-Commit: ee373c1234d33d68e91fbe51f846e265cbce9e72 Auto-Submitted: auto-generated The branch stable/14 has been updated by gallatin: URL: https://cgit.FreeBSD.org/src/commit/?id=ee373c1234d33d68e91fbe51f846e265cbce9e72 commit ee373c1234d33d68e91fbe51f846e265cbce9e72 Author: Andrew Gallatin AuthorDate: 2023-10-12 15:15:06 +0000 Commit: Andrew Gallatin CommitDate: 2024-10-28 23:02:24 +0000 acpi_ged: Handle events directly Handle ged interrupts directly from the interrupt handler, while the interrupt source is masked, so as to conform with the acpi spec, and avoid spurious interrupts and lockups on boot. When an acpi ged interrupt is encountered, the spec requires the os (as stated in 5.6.4: General Purpose Event Handling) to leave the interrupt source masked until it runs the EOI handler. This is not a good fit for our method of queuing the work (including the EOI ack of the interrupt), via the AcpiOsExecute() taskqueue mechanism. Note this fixes a bug where an arm64 server could lock up if it encountered a ged interrupt at boot. The lockup was due to running on a single core (due to arm64 not using EARLY_AP_STARTUP), and due to that core encountering a new interrupt each time the interrupt handler unmasked the interrupt source, and having the EOI queued on a taskqueue which never got a chance to run. This is also possible on any platform when using just a single processor. The symptom of this is a lockup at boot, with: "AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable" scrolling on console. Similarly, spurious interrupts would occur when running with multiple cores, because it was likely that the interrupt would fire again immediately, before the ged task could be run, and before an EOI could be sent to lower the interrupt line. I would typically see 3-5 copies of every ged event due to this issue. This adds a tunable, debug.acpi.ged_defer, which can be set to 1 to restore the old behavior. This was done because acpi is a complex system, and it may be theoretically possible something the ged handler does may sleep (though I cannot easily find anthing by inspection). MFC after: 1 month Reviewed by: andrew, jhb, imp Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D42158 (cherry picked from commit be91b4797e2c8f3440f6fe3aac7e246886f9ebca) --- sys/dev/acpica/acpi_ged.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/sys/dev/acpica/acpi_ged.c b/sys/dev/acpica/acpi_ged.c index e7dcc1ffb0ac..23e125f277c5 100644 --- a/sys/dev/acpica/acpi_ged.c +++ b/sys/dev/acpica/acpi_ged.c @@ -81,6 +81,11 @@ static driver_t acpi_ged_driver = { DRIVER_MODULE(acpi_ged, acpi, acpi_ged_driver, 0, 0); MODULE_DEPEND(acpi_ged, acpi, 1, 1, 1); +static int acpi_ged_defer; +SYSCTL_INT(_debug_acpi, OID_AUTO, ged_defer, CTLFLAG_RWTUN, + &acpi_ged_defer, 0, + "Handle ACPI GED via a task, rather than in the ISR"); + static void acpi_ged_evt(void *arg) { @@ -92,7 +97,12 @@ acpi_ged_evt(void *arg) static void acpi_ged_intr(void *arg) { - AcpiOsExecute(OSL_GPE_HANDLER, acpi_ged_evt, arg); + struct acpi_ged_event *evt = arg; + + if (acpi_ged_defer) + AcpiOsExecute(OSL_GPE_HANDLER, acpi_ged_evt, arg); + else + AcpiEvaluateObject(evt->ah, NULL, &evt->args, NULL); } static int acpi_ged_probe(device_t dev)