Some Fujitsu Lifebooks return an invalid _BIX object. The first element
of _BIX is a revision number, which indicates what elements will follow:
* ACPI 4.0 defined _BIX revision 0 with 20 elements.
* ACPI 6.0 introduced _BIX revision 1 with 21 elements.
The problem is that the offending Lifebooks have the a non-zero _BIX
revision, but provide 20 fields only.
The ACPICA parser chokes on this [1], but that seems to be
inconsequential. More importantly, our own battery info handling code
also verifies that for revision > 0, there are at least 21 fields - and
refuses to process the invalid _BIX. One workaround would be to
introduce special case / quirk handling for Fujitsu Lifebooks. A better
one is to relax the requirements check: If there are only 20 elements,
treat the _BIX as revision 0, no matter what revision number was
provided by the device.
Linux doesn't run into this problem by the way because it only supports
the 20 fields defined in the ACPI 4.0 spec [3]. It never looks at the
revision number or the 21st field added in ACPI 6.0.
[1] https://cgit.freebsd.org/src/tree/sys/contrib/dev/acpica/components/namespace/nsprepkg.c#n815
[2] https://cgit.freebsd.org/src/tree/sys/dev/acpica/acpi_cmbat.c#n371
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/battery.c#n418
PR: 252030
Reviewed by: imp
MFC After: 2 weeks
All architectures define PCI_RES_BUS unconditionally now that only
NEW_PCIB is supported, so we no longer need the legacy code.
Reviewed by: jhb, andrew
Differential Revision: https://reviews.freebsd.org/D32955
All architectures enable NEW_PCIB in DEFAULTS (arm being the most recent
to do so in 121be55599 (arm: Set NEW_PCIB in DEFAULTS rather than a
subset of kernel configs")), so it's time we removed the legacy code
that no longer sees much testing and has a significant maintenance
burden.
Reviewed by: jhb, andrew, emaste
Differential Revision: https://reviews.freebsd.org/D32954
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
In 2001 when the ACPI timer was introduced, it included code to check
for a bug present in some Pentium II and Pentium III chipsets; if the
bug was found to be present, ACPI-safe (which was slower but had a
workaround for the bug) would be used rather than ACPI-fast (which
read the same timer but without the workaround).
In a8b89dff6a (September 2021) I disabled this check by default,
with a loader tunable available to re-enable it; I announced at the
time that it would go away in FreeBSD 15 if I didn't receive any
reports of problems. I have received no such problems, so this code
is now going away.
The debug.acpi.timer_test loader variable triggered a lengthy (in fact,
infinitely long) test of the ACPI timer and appears to have been
introduced as part of the process of writing the ACPI timer (and the
associated ACPI-safe workaround) in 2001; since we are dropping support
for systems with this ACPI bug, there is no need to keep that test code
either.
Some bus drivers use rmans to suballocate resources to child devices.
When the driver for a child device requests a mapping for a
suballocated resource, the bus driver translates this into a mapping
request for a suitable subrange of the original resource the bus
driver allocated from its parent. This nested mapping request should
look like any other resource mapping request being made by the bus
device (i.e. as if the bus device had called bus_map_resource() or
bus_alloc_resource() with RF_ACTIVE).
I had slightly flubbed this last bit though since the direct use of
bus_generic_map/unmap_resource passed up the original child device
(second argument to the underlying kobj interface). While this is
currently harmless, it is not strictly correct as the resource being
mapped is owned by the bus device, not the child and can break for
other bus drivers in the future.
Instead, use bus_map/unmap_resource for the nested request where the
requesting device is now the bus device that owns the parent resource.
Reviewed by: imp
Fixes: 0e1246e334 acpi: Cleanup handling of suballocated resources
Fixes: b377ff8110 pcib: Refine handling of resources allocated from bridge windows
Fixes: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
Fixes: d714e73f78 vmd: Use bus_generic_rman_* for PCI bus and memory resources
Differential Revision: https://reviews.freebsd.org/D45433
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
The public bus_release_resource() API still accepts both forms, but
the internal kobj method no longer passes the arguments.
Implementations which need the rid or type now use rman_get_rid() or
rman_get_type() to fetch the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44131
The public bus_activate/deactivate_resource() API still accepts both
forms, but the internal kobj methods no longer pass the arguments.
Implementations which need the rid or type now use rman_get_rid() or
rman_get_type() to fetch the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44130
The public bus_map/unmap_resource() API still accepts both forms, but
the internal kobj methods no longer pass the argument.
Implementations which need the type now use rman_get_type() to fetch
the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44129
The public bus_adjust_resource() API still accepts both forms, but the
internal kobj method no longer passes the argument. Implementations
which need the type now use rman_get_type() to fetch the value from
the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44128
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
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
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
For resources suballocated from the system resource rmans, handle
those in the ACPI bus driver without passing them up to the parent.
This means using bus_generic_rman_* for several bus methods for
operations on suballocated resources. For bus_map/unmap_resource,
find the system resource allocated from the parent bus (nexus) that
contains the range being mapped and request a mapping of that parent
resource.
This avoids a layering violation where nexus drivers were previously
asked to manage the activation and mapping of resources created
belonging to the ACPI resource managers.
Note that this does require passing RF_ACTIVE (with RF_UNMAPPED) when
allocating system resources from the parent.
While here, don't assume that the parent bus (nexus) provides a
resource list that sysres resources are placed on. Instead, create a
dedicated resource_list in the ACPI bus driver's softc to hold sysres
resources.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43687
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
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.
Work around vendors who use the same address for multiple
ReadAckRegisters in their ACPI HEST table. This
allows apei to attach cleanly on Ampere Altra servers.
Note the issue is not specific to Ampere, I've run into
it with at least one other vendor (whose server is not
yet released).
Sponsored by: Netflix
Reviewed by: jhb
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
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
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
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
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
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
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
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
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
