AWS Graviton [1234] systems have a bug in their ACPI where they mark
the PL061's GPIO pins as needing to be configured in PullUp mode (in
fact the PL061 has no pullup/pulldown resistors); this flag needs to
be removed in order for _AEI objects to be handled on these systems.
Reviewed by: Ali Saidi
Approved by: re (kib)
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D47239
(cherry picked from commit 2f3f867ac6dd7ff3769366b828b79c44b38828e1)
(cherry picked from commit 5fa51c3653)
ACPI sleep states are only implemented on x86 systems, so having the
ACPI power button attempt to enter "S5" (or other state as configured
via the hw.acpi.power_button_state sysctl) is not useful.
On non-x86 systems, implement the power button with a call to
shutdown_nice(RB_POWEROFF)
to shut down the system.
Reviewed by: Andrew
Tested on: Graviton 2
Approved by: re (kib)
MFC after: 2 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D47094
(cherry picked from commit f41ef9d80b3d272e08dd9e2ea3c1d8d3f2818066)
(cherry picked from commit e177e64294)
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)
Commit 9a7bf07ccd from 2016 introduced a workaround for some broken
BIOSes that specified active-lo instead of active-hi polarity for ISA
IRQs for UARTs. The workaround assumed that edge-sensitive ISA IRQs
on x86 should always be active-hi. However, some recent AMD systems
actually use active-lo edge-sensitive ISA IRQs (and not just for
UARTs, but also for the keyboard and PS/2 mouse devices) and the
override causes interrupts to be dropped resulting in boot time hangs,
non-working keyboards, etc.
Add a hw.acpi.override_isa_irq_polarity tunable (readable as a sysctl
post-boot) to control this quirk. It can be set to 1 to force enable
the override and 0 to disable it. The log of original message
mentions an Intel motherboard as the sample case, so default the
tunable to 1 on systems with an Intel CPU and 0 otherwise.
Special thanks to Matthias Lanter <freebsd@lanter-it.ch> for tracking
down boot time issues on recent AMD systems to mismatched interrupt
polarity.
PR: 270707
Reported by: aixdroix_OSS@protonmail.com, Michael Dexter
Reported by: mfw_burn@pm.me, Hannes Hfauswedell <h2+fbsdports@fsfe.org>
Reported by: Matthias Lanter <freebsd@lanter-it.ch>
Reported by: William Bulley <web@umich.edu>
Reviewed by: imp, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D45554
(cherry picked from commit 0a34d050ae8ea14feddd3d2a62fd2f612613b2c5)
On laptops with builtin batteries, disconnecting the battery may show up
as a battery without any capacity information. (The theory is that one
is disconnecting the cells but the electronics identifying the battery
are still connected.) As a result, the loop over all batteries in
acpi_battery_get_battinfo results in total_lfcap == 0.
So, just check that total_lfcap is non-zero to avoid a division by zero
(triggerable by sysctl hw.acpi.battery).
Reported by: Stefano Marinelli
Tested by: Stefano Marinelli
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D44818
(cherry picked from commit 2e850b832f5d2adb9b230d191277d67c00caaab9)
This fixes a panic if a driver uses bus_set_resource to add a resource
that fails to reserve and then deletes the resource via
bus_delete_resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43891
(cherry picked from commit e05436d577de98944b97b9cf510b29c4d2091b3f)
acpi_set_resource excludes certain types of resources for certain
devices. The intention of this is to avoid adding resource entries
for bogus resources enumerated via _CRS. However, this also prevents
drivers from adding those resources explicitly if needed. To fix
this, move the logic to exclude these resources into an ignore hook
used when parsing _CRS to create the initial set of resources for each
device.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43892
(cherry picked from commit 055c1fe230ce5a2997c03a3cc2431baea1594566)
No functional change, but it is cleaner to use the existing generic
wrappers rather than KOBJ methods directly.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43686
(cherry picked from commit 1fb5445206a5ef2351c32f8bc6beb67605593caa)
The goal of reserving firmware-assigned resources is to ensure that
"wildcard" resource allocation requests will not claim an address
range that is actually in use even if no attached driver is actively
using that range. However, the current approach can break in some
cases.
In particular, ACPI can enumerate devices behind PCI bridges that
don't show up in a normal PCI scan, but those device_t objects can end
up as direct children of acpi0. Reserving resources for those devices
directly from acpi0 ends up conflicting with later attempts to reserve
the PCI bridge windows.
As a workaround, defer reserving unclaimed resources until after the
initial probe and attach scan. Eventually this pass of reserving
unclaimed resources can be moved earlier, but it requires changes to
other drivers in the tree to permit enumerating devices and reserving
firmware-assigned resources in a depth-first traversal before
attaching devices whose drivers request wildcard allocations.
PR: 272507
Reported by: Justin Tocci <justin@tocci.org>
Reported by: john@feith.com, many others
Tested by: Oleg Sidorkin <osidorkin@gmail.com>, dch
(cherry picked from commit f2fcb68074a51a8b399dc80d4c03fbe98a0ab92c)
For example, shutdown_panic wants to produce some output and maybe take
some input before a system is actually reset.
The change should only make difference for the case of system reset
(reboot), poweroff and halt should not be affected.
The change makes difference only if hw.acpi.handle_reboot is set. It
used to default to zero until r213755 / ac731af567.
Also, run shutdown_halt even later, after acpi_shutdown_final. The
reason for that is that poweroff is requested by RB_POWEROFF | RB_HALT
combination of flags. In my opinion, that command is a bit bipolar, but
since we've been doing that forever, then so be it. Because of that
flag combination, the order of shutdown_final handlers that check for
either flag does matter.
Some additional complexity comes from platform-specific shutdown_final
handlers that aim to handle multiple reboot options at once. E.g.,
acpi_shutdown_final handles both poweroff and reboot / reset. As
explained in 9cdf326b4f, such a handler must run after shutdown_panic to
give it a chance. But as the change revealed, the handler must also run
before shutdown_halt, so that the system can actually power off before
entering the halt limbo.
Previously, shutdown_panic and shutdown_halt had the same priority which
appears to be incompatible with handlers that can do both poweroff and
reset.
The above also applies to power cycle handlers.
(cherry picked from commit 9cdf326b4faef97f0d3314b5dd693308ac494d48)
(cherry picked from commit e4ab361e53945a6c3e9d68c5e5ffc11de40a35f2)
Remove extra acpi_UserNotify() call per event. Filter duplicate
notifications received from ACPI without actual status change.
Without this on my Dell XPS 13 9310 I saw 4 devd events for either
open or close, now only one.
MFC after: 1 month
(cherry picked from commit 1a3ee6002f3e008e0bc29d04c976285434503e19)
Instead of setting and clearing BUS_MASTER_RLD register on every C3
state enter/exit, set it only once if the system supports C3 state
and we are going to "disable" bus master arbitration while in it.
This is what Linux does for the past 14 years, and for even more time
this register is not implemented in a relevant hardware. Same time
since this is only a single bit in a bigger register, ACPI has to
do take a global lock and do read-modify-write for it, that is too
expensive, saved only by C3 not entered frequently, but enough to be
seen in idle system CPU profiles.
MFC after: 1 month
(cherry picked from commit 5bc10feacc9d81e3bba9d28734a85e996682b408)
In particular, this enables support for PCI config access for domains
(segments) other than 0.
Reported by: cperciva
Tested by: cperciva (m7i.metal-48xl AWS instance)
Reviewed by: imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D42828
(cherry picked from commit f54a3890b1f419d4a9edc99000efef52b9071b8f)
This commit changes the API of pci_cfgreg(read|write) to add a domain
argument (referred to as a segment in ACPI parlance) (note that this
is not the same as a NUMA domain, but something PCI-specific). This
does not yet enable access to domains other than 0, but updates the
API to support domains.
Places that use hard-coded bus/slot/function addresses have been
updated to hardcode a domain of 0. A few places that have the PCI
domain (segment) available such as the acpi_pcib_acpi.c Host-PCI
bridge driver pass the PCI domain.
The hpt27xx(4) and hptnr(4) drivers fail to attach to a device not on
domain 0 since they provide APIs to their binary blobs that only
permit bus/slot/function addressing.
The x86 non-ACPI PCI bus drivers all hardcode a domain of 0 as they do
not support multiple domains.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D42827
(cherry picked from commit 1587a9db92c03c738bb3f0fc5874b43c961e7c99)
In particular, don't reserve resources added by drivers via other
means (e.g. acpi_bus_alloc_gas which calls bus_alloc_resource
right after adding the resource).
The intention of reserved resources is to ensure that a resource range
that a bus driver knows is assigned to a device is reserved by the
system even if no driver is attached to the device. This prevents
other "wildcard" resource requests from conflicting with these
resources. For ACPI, the only resources the bus driver knows about
for unattached devices are the resources returned from _CRS. All of
these resources are already reserved now via acpi_reserve_resources
called from acpi_probe_children.
As such, remove the logic from acpi_set_resource to try to reserve
resources when they are set. This permits RF_SHAREABLE to work with
acpi_bus_alloc_gas without requiring hacks like the current one for
CPU device resources in acpi_set_resource.
Reported by: gallatin (RF_SHAREABLE not working)
Diagnosed by: jrtc27
(cherry picked from commit c6a488511ab1fbae8d16264b9e83c85024c9e1ce)
Currently if _BBN doesn't match the first bus in the decoded bus range
from _CRS for a Host to PCI bridge, the driver fails to attach as a
defensive measure.
There is now firmware in the field where these do not match, and the
_BBN values are clearly wrong, so rather than failing attach, trust
the range from _CRS over _BBN.
Co-authored-by: Justin Gibbs <gibbs@FreeBSD.org>
Reported by: gibbs
Reviewed by: imp (earlier version)
Differential Revision: https://reviews.freebsd.org/D42231
(cherry picked from commit 22a6678b627b39ceb94f7323be1010e928d92494)
On 64bit, there is a 4-byte hole in struct vdso_timekeep32 after
tk_current, if the structure is not packed. This is due to the MD
th_x86_pvc_last_systime being 64bit.
Change amd64 VDSO_TIMEHANDS_MD32 to not use uint64_t, replace it with
pair of uint32_t, as it is done for all other members.
PR: 273085
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
- Use an enum for the button type (it is not really a boolean value).
- Use bool for fixed.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D39922
A signed one-bit wide bit-field can take only the values 0 and -1. Clang
16 introduced a warning that "implicit truncation from 'int' to a
one-bit wide bit-field changes value from 1 to -1". Fix the warnings by
using C99 bool.
Reported by: Clang 16
Reviewed by: emaste, jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D39705
Started seeing the following after updating to VMware ESXi 8.0:
pcib2: <ACPI Host-PCI bridge> on acpi0
pcib2: could not evaluate _ADR - AE_NOT_FOUND
pci2: <ACPI PCI bus> on pcib2
vmx0: <VMware VMXNET3 Ethernet Adapter> ...
The virtual NIC works fine, and the code comment suggests that
missing _ADR is not something fatal, skip printing the message
if status is AE_NOT_FOUND.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/682
Along with _PSV, _HOT, and _CRT, ACPI supports the _CR3 threshold
which specifies a temperature above which a system should transition
to the S3 standby state.
On FreeBSD, this is more useful than _HOT, which specifies the S4
transition threshold temperature (since FreeBSD does not generally
support the S4 state), or, in many cases, _CRT, since after
transitioning to S3 the system can cool and then be resumed.
Reviewed by: jhb, bcr (manpages)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D35980
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
Buggy SMM implementations can hang while processing CPPC notifications.
This leads to some laptops (notably Thinkpads) hanging when the
hwpstate_intel driver is loaded.
Tell the SMM that we will handle CPPC notifications as described in:
- Intel® Processor Vendor-Specific ACPI
- Intel® 64 and IA-32 Architectures Software Developer’s Manual
CPPC events default to masked (disabled) so while we do not do any
handling right now this does not seem to lead to any issues.
This approach was found via this Linux Kernel patch:
https://lkml.org/lkml/2016/3/17/563
PR: 253288
Reviewed by: imp, jhb
Sponsored by: Modirum
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D36699
This will resolve a reference and return the appropriate handle, a node
on the simplebus or an ACPI_HANDLE for ACPI. For now we do not try to
further abstract the return type.
MFC after: 2 weeks
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D36793
This matches the return type of pmap_mapdev/bios.
Reviewed by: kib, markj
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D36548
Fixes INVARIANTS build with Clang 15, which previously failed due to
set-but-not-used variable warnings.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36096
With clang 15, the following -Werror warning is produced:
sys/dev/acpica/acpi_timer.c:402:16: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
acpi_timer_test()
^
void
This is because acpi_timer_test() is declared with a (void) argument
list, but defined with an empty argument list. Make the definition match
the declaration.
MFC after: 3 days
acpi_find_dsd() is not a bus function and we only need the acpi_device (ad).
The only caller has already looked up the ad (from ivars) for us.
Directly pass the ad to acpi_find_dsd() instead of bus, dev and remove
the extra call to device_get_ivars(); the changed argument also means we
now call AcpiEvaluateObject directly on the handle.
This optimisation was done a while ago while debugging a driver which
ended up with a bad bus, dev combination making the old version fail.
MFC after: 2 weeks
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D35558
