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 (cherry picked from commit cd8c3af747cc300c8257c315c7576644e2bb86ff)
Commit 9a7bf07ccdc1 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) (cherry picked from commit 788987e034b1c73d779a3aa179f79f672bbdb366)
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)
No functional change intended. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D44402 (cherry picked from commit 579cb41b132f532bf4915121c0d0b2f43688242e) (cherry picked from commit ddd779a062c1de28a3f632ece9fe4d1abf07dbdb)
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 / ac731af5670c7. 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)
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)