acpi: Mark the GED ithread as sleepable

We need to complete calling the ACPI method before marking the interrupt
as complete. If two threads are inspecting the ACPI tables at the same
time they may

acpi: Mark the GED ithread as sleepable

We need to complete calling the ACPI method before marking the interrupt
as complete. If two threads are inspecting the ACPI tables at the same
time they may both try to lock the ACPI mutex causing one to sleep. If
this is the ithread it will panic the kernel as this is not allowed.

Update the ged ithread to allow sleeping as it is expected this lock
will be uncommon enough any sleep will be short.

PR: 283103
Reviewed by: markj (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48284

show more ...

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

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

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

acpi_ged: fix build with ACPI_DEBUG

acpi_ged: fix build, as module and non INTRNG case.

Reviewed-by: cy

Differential Revision: https://reviews.freebsd.org/D37104

acpi_ged: New driver to ACPI generic event device

New driver to ACPI generic event device, defined in ACPI spec.
Some ACPI power button may not work without this.

In qemu arm64 with "virt" machin

acpi_ged: New driver to ACPI generic event device

New driver to ACPI generic event device, defined in ACPI spec.
Some ACPI power button may not work without this.

In qemu arm64 with "virt" machine, with ACPI firmware,
enable devd check devd message by
and invoke following command in qemu monitor
(qemu) system_powerdown
and make sure some power button input event appear.
(setting sysctl hw.acpi.power_button_state=S5 is not work,
because ACPI tree does not have \_S5 object.)

Reviewed by: andrew, hrs
Differential Revision: https://reviews.freebsd.org/D37032

show more ...