firmware requests to do so. This cures severe overhating (> 120 C) observed
on many laptops, being also on par with the specification(s). This can be
reverted by using the new "hw.acpi.cpu.dynamic" sysctl variable.
(a) This should be removed once C-states are supported.
(b) As there seems to be no reliable way to detect whether C1E is present,
the quirk blindly assumes that C1E is used on families 10h and 11h.
required information. Problem found and diagnosed by jakllsch@; on some AMD
systems vendors fill _PSS correctly, but do not duplicate the data in XPSS.
this, the structure acpi_pciinfo now tells whether the ACPI
device node is a PCI bridge, a regular PCI device, or both.
Problem reported by jmcneill@, who also suggested the solution.
ok jmcneill@, jruoho@
control and output switching, through ACPI video extensions.
TODO: use wsconsctl(8) instead of sysctl(8) for brightness control.
ok jruoho@
also discussed with cegger@ and jmcneill@
don't use ACPI on BIOS which advertise release years <= 2000. This
can be changed by setting option ACPI_BLACKLIST_YEAR=0 or by setting
acpi_force_load=1.
still matches more boards that just the one with the problem.
Interrupts from the SATA controllers on my MSI K8N Neo3 boards
(which both versions of this quirk matched) are broken when ACPI
is disabled. My board does not exhibit AE_AML_INFINITE_LOOP
problems.
If we want to avoid manually specifying RB_MD2 in boothowto on
pgoyette@'s board, we're going to have to find another way; perhaps
with the DMI strings available from pmf(9).
Anyhow, some boards needing RB_MD2 during boot(8) is in my opinion
better than others needing to set acpi_force_load in ddb or gdb.
Note that the solution is not optimal. If ichlpcib(4) provides SpeedStep
support, possible I/O resource conflicts may occur with acpicpu(4). Ideally,
as noted for instance in Windows design documents, ichlpcib(4) should never
expose SpeedStep when ACPI is being used. The probability for potential race
conditions is however very small, being limited to few P4-era machines and
being dependent on user actions.
for an unknown notify. (The ACPI drivers should really not print anything
as we now have a global notify handler that can catch the debug information.)
will go backwards; K7 will not be supported already due doubts about
availability and reliability of ACPI during that era. Some unfortunate code
duplication is present (but not overly much). Thanks to cegger@ and jakllsch@
for patiently testing this.
do the status-check when the comparison value reported by BIOS is not zero.
The uncertainty noted in the previous commit still applies. But if we ever
see a timeout again, it will likely be either a firmware bug or a special
case like the Intel Turbo Boost.
ACPI_NOTIFY_DEVICE_WAKE. Control method power and sleep buttons can
generate this event upon waking from G1 sleep to indicate that it was
responsible for waking the system.
- XPSS spec says that Status{,Mask} and Control{,Mask} buffers are 8 bytes
- use ACPI_GET64 macros instead of memcpy when reading from buffers
This makes acpicpu work again on my VIA C7-M, whose firmware reports
malformed XPSS packages but has a working _PSS
invariant APIC timer or an "ARAT" ("always running APIC timer"). This means
that the APIC timer may keep ticking at the same rate also in deep C-states
with some new or forthcoming Intel CPUs.
Intel processors. The invariance means that TSC runs at a constant rate
during all ACPI state changes. If it is variant, skew may occur and TSC is
generally unsuitable for wall clock services. This is especially relevant
with C-states; with variant TSC, the whole counter may be stopped with states
larger than C1. All x86 CPUs before circa mid-2000s can be assumed to have a
variant time stamp counter.
config_interrupts(9) to be executed. This is necessary because: (a) the
initialization routines must be run only once after interrupts are enabled
and (b) all ACPI CPUs have attached.
Comparable to T-states, this gives effectively a window of available
performance states for passive cooling. An example:
Init: max = 0, min = Pn.
Time j. Time j + 1.
----------- -----------
2000 MHz P0 max P0
P1 P1 max
P2 ==> P2
P3 P3 min
P4 P4
P5 min P5
500 Mhz Pn Pn
----------- -----------
Search: repeat (i = P0; i <= P5) repeat (i = P1; i <= P3)
1. Initialize P-states properly to P0. It is processor-specific
what value we might get without initialization. (Some AMD CPUs
have even specific registers for the state after cold reset.)
2. Following design notes for Windows, set the lowest-power P-state
upon suspend and restore the saved state after resume.
dynamic maximum is nonexistent. Unsurprisingly, there is vagueness in the
standards; in ACPI 3.0 and 4.0 it is clearly indicated that also these methods
must be present, but the earlier standards are less stringent. Without too
much effort, at least one old P4-system was located that lacks _PPC.
Remarks:
1. Native instructions are supported only on Intel. Native support for
other x86 vendors will be investigated. By assumption, AMD and others
use the I/O based approach.
2. The existing code, INTEL_ONDEMAND_CLOCKMOD, must be disabled in
order to use acpicpu(4). Otherwise fatal MSR races may occur.
Unlike with P-states, no attempt is done to disable the existing
implementation.
3. There is no rationale to export controls to user land.
4. Throttling is an artefact from the past. T-states will not be used for
power management per se. For CPU frequency management, P-states are
preferred in all circumstances. No noticeable additional power savings
were observed in various experiments. When the system has been scaled
to the highest (i.e. lowest power) P-state, it is preferable to move
from C0 to deeper C-states than it is to actively throttle the CPU.
5. But T-states need to be implemented for passive cooling via acpitz(4).
As specified by ACPI and Intel documents, these can be used as the
last line of defence against critical thermal conditions. Support
for this will be added later.
(required for interaction with T-states), and (3) use aprint_debug(9)
instead of the ACPI_DEBUG_PRINT(x) macro for the dynamic frequency changes
(for the time being, people need easier way to observe the dynamic changes).
/*
* XXX: The pci_find_device(9) function only deals with
* attached devices. Change this to use something like
* pci_device_foreach(), and implement it for IA-64.
*/
functional, the previously loaded EST code may have used frequencies that
are not present in the BIOS. This will cause failures since acpicpu(4) will
treat these unknown frequencies as errors. "Fix" this by initializing the
cached P-state to P0, regardless of what the true state might be.
Remarks:
1. All processors (x86 or not) for which the vendor has implemented
ACPI I/O access routines are supported. Native instructions are
currently supported only for Intel's "Enhanced Speedstep". Code for
"PowerNow!" (AMD) will be merged later. Native support for VIA's
"PowerSaver" will be investigated.
2. Backwards compatibility with existing userland code is maintained.
Comparable to the case with cpu_idle(9), the ACPI CPU driver
installs alternative functions for the existing sysctl(8) controls.
The "native" behavior (if any) is restored upon detachment.
3. The dynamic nature of ACPI-provided P-states needs more investigation.
The maximum frequency induced (but not forced) by the firmware may
change dynamically. Currently, the sysctl(8) controls error out with
a value larger than the dynamic maximum. The code itself does not
however yet react to the notifications from the firmware by changing
the frequencies in-place. Presumably the system administrator should
be able to choose whether to use dynamic or static frequencies.
This can help when dealing with problem reports, as the user does not need
to reboot nor compile a kernel. Instead: 'modload -b dump=true acpiverbose'.
when the idle-information is being updated (e.g. due acpiacad(4) events),
we can not enter the idle-loop. The lock must run at the same priority
(IPL_NONE) as ACPICA's mutexes obtained via AcpiOsCreateMutex() a.k.a.
AcpiOsCreateSemaphore(). Also check want_resched as the first thing and
clarify the suspend/resume path.
There is still one race condition identified: when the driver is loaded as a
module, we must gracefully kick all CPUs out from the ACPI idle-loop upon
detachment.
It was analyzed that this DSDT busy-loops some unknown PCI memory regions in
several places. Because the regions are apparently almost constant, this
causes several conditions where the interpreter might enter into an infinite
loop. Luckily ACPICA detects this and rightly spams AE_AML_INFINITE_LOOP
warnings.
Not much we can do. Declare as broken beyond repair. Set acpi_force_load=1
to use ACPI or use a custom DSDT.
sanity check before casting to the GAS. Rename the _CSD structure; the
optional "cross logical processor dependency information" is almost
identical in C, P, and T states. Add some comments to the header.
activity (BM_STS) by reading from the PM1 register. According to the Intel
processor specification for ACPI, the FFH GAS encoding may provide a hint
that the check is not required. This may help some systems to enter C2/C3
even when e.g. usb(4) keeps the BM_STS bit always enabled.
existing ACPICPU_FLAG_C, as was intended. Set that flag only after the
idle-loop has been installed, so that the notify handler errors out if an
interrupt is received before the idle-loop is in place.
This makes my laptop boot instead of panic:
panic: kernel diagnostic assertion "native_idle != NULL" failed: file "../../../../arch/x86/acpi/acpi_cpu_md.c", line 155
fatal breakpoint trap in supervisor mode
type 1 code 0 rip ffffffff8022e4ad cs 8 rflags 246 cr2 0 cpl 0 rsp ffff80004c37db10
trace
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x2ba
kern_assert() at netbsd:kern_assert+0x2d
acpicpu_md_idle_stop() at netbsd:acpicpu_md_idle_stop+0x62
acpicpu_cstate_callback() at netbsd:acpicpu_cstate_callback+0x34
sysmon_task_queue_thread() at netbsd:sysmon_task_queue_thread+0x41
1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that
2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of
attaching the unmatched ones, make the match fail. Do we want to
attach and do nothing instead?
3. Create a flag, and only set it after we are completely initialized,
so the sysmon thread does not try to access unitialized state.
larger than the upper limit constants. Only sanity check against these
defaults when operating with FADT. This is also noted in a fine print of the
specification (ACPI 4.0, p. 314): "[...] The worst-case latency to enter and
exit the C State (in microseconds). There are no latency restrictions."
also known as C-states. The code is modular and provides an easy way to add
the remaining functionality later (namely throttling and P-states).
Remarks:
1. Commented out in the GENERICs; more testing exposure is needed.
2. The C3-state is disabled for the time being because it turns off
timers, among them the local APIC timer. This may not be universally
true on all x86 processors; define ACPICPU_ENABLE_C3 to test.
3. The algorithm used to choose a power state may need tuning. When
evaluating the appropriate state, the implementation uses the
previous sleep time as an indicator. Additional hints would include
for example the system load.
Also bus master activity is evaluated when choosing a state. The
usb(4) stack is notorious for such activity even when unused.
Typically it must be disabled in order to reach the C3-state,
but it may also prevent the use of C2.
4. While no extensive empirical measurements have been carried out, the
power savings are somewhere between 1-2 W with C1 and C2, depending
on the processor, firmware, and load. With C3 even up to 4 W can be
saved. The less something ticks, the more power is saved.
ok jmcneill@, joerg@, and discussed with various people.
Fixes PR kern/42937 from Ryo Onodera.
As acpi_match_hid() matches also "compatible IDs" (CIDs), we must be careful
when adding devices to this list. For example, the above PR revealed that
the following is a fairly typical way to define the HPET device:
Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (_CID, EisaId ("PNP0C01"))
...
Arguably this is a BIOS bug, given that PNP0C01 and PNP0C02 should uniquely
identify a device (or a resource template) that has nothing to do with HPET.
state. This follows the "bus power state" -logic noted in the spec:
bus: D1
device A : D1 -> D0 -> error
device B : D1 -> D2 -> success
-> bus must remain in D1 due device A
Following this scheme, it is easy to derive the "bus power state" now that
we have the device nodes in a tree-like structure. If required, separate
acpi_power_get_bus() and acpi_power_set_bus() can be added in the future.
all "struct acpi_devnodes" to their corresponding ACPI_HANDLEs. Anywhere in
the acpi(4) subtree, the node-structure can be obtained from a handle via
acpi_get_node(). The idea is similar to e.g. device_private().
Benefits: (a) simplifies code, (b) avoids issues with locking as ACPICA does
the serialization for us, (c) avoids the need to access the glocal softc, and
(d) avoids the O(n) loop required to search for a handle from the node queue.
GPEs, but unset only wake GPEs. The old behavior was questionable, as the
intention was only to disable a device's ability to wake the system.
Maintaining the runtime GPE generation is more important now as ACPICA
supports sharing a single GPE across multiple devices.
Discussed with jmcneill@.
interrupt handler. However, all edge-triggered GPEs should already be
cleared before our GPE handler has a chance to run.
The reason can be found from the changes in the locking primitives of
ACPICA. All GPE operations now use a spin mutex on AcpiGbl_GpeLock, acquired
via AcpiOsAcquireLock(). This same lock is now acquired unconditionally in
the AcpiClearGpe() function. This causes a deadlock of the following form:
...
AcpiEvGpeDetect() : acquire AcpiGbl_GpeLock;
-> AcpiEvGpeDispatch();
-> acpiec_gpe_handler();
-> AcpiClearGpe() : acquire AcpiGbl_GpeLock;
-> panic.
Completed a major update for the GPE support in order to improve
support for shared GPEs and to simplify both host OS and ACPICA
code. Added a reference count mechanism to support shared GPEs that
require multiple device drivers. Several external interfaces have
changed. One external interface has been removed. One new external
interface was added. Most of the GPE external interfaces now use the
GPE spinlock instead of the events mutex (and the Flags parameter
for many GPE interfaces has been removed.) See the updated ACPICA
Programmer Reference for details. Matthew Garrett, Bob Moore, Rafael
Wysocki. ACPICA BZ 831.
Changed:
AcpiEnableGpe, AcpiDisableGpe, AcpiClearGpe, AcpiGetGpeStatus
Removed:
AcpiSetGpeType
New:
AcpiSetGpe
order to be ready for possible future API changes, call it if we failed to
install the fixed event handlers. Also small ACPI_DEBUG_PRINT clarifications.
/*
* sleep(9) isn't safe because AcpiOsStall may be called
* with interrupt-disabled. (eg. by AcpiEnterSleepState)
* we should watch out for long stall requests.
*/
ACPICA has long printed a similar warning by itself. Moreover, this message
was never reached as the interpreter does not invoke AcpiOsStall() when a
delay longer than 255 usec is requested.
This is now in ACPICA (20100528):
Added support to limit the maximum time for the ASL Sleep()
operator. To prevent accidental deep sleeps, limit the maximum time
that Sleep() will actually sleep. Configurable, the default maximum
is two seconds. ACPICA bugzilla 854.
devices should be placed in the D0 state ("fully on") after resume. We were
not prepared to handle the previous value as it implied that devices could
be placed in an arbitrary power state once in S0.
Minimal functional change, given that the _DSW is seldom seen in the field.
This "fixes" the issue observed by dyoung@. Since the AML may not keep any
state by itself, it is possible that the firmware tries to continuously put
a device into a power state where the device already is (e.g. D3 -> D3).
XXX: The code (like the old power resource code) rests on the assumption
that it is possible to reliably obtain the power state of a device
either directly via _PSC or indirectly via _STA. However, because there
is some evidence that few broken systems implement these methods
incorrectly (e.g. always returns D0 as a constant, even if the state
would be D3 in reality), we may need to revisit this by always setting
the power state, even if it is impossible to get the power state.
by defining 'options ACPIVERBOSE' in the kernel config file (no change
from current behavior), or it can be loaded at boot time on those
architectures that support the boot loader's "load" command.
ACPIVERBOSE also includes code to dump acpi/wmi data.
has no support for it. For example, in Kurt Schreiner's Shuttle G61:
Device (FAN)
{
Name (_HID, EisaId ("PNP0C0B"))
Method (_INI, 0, NotSerialized)
{
Store (TP1H, CTOS)
Store (TP1L, CTHY)
}
}
Obviously acpitz(4) has little use for a device that only contains _INI.
(The handle of this device is referenced incorrectly in _AL0.)
seconds. It is known that there are systems in the field that pass bogus AML
values to the Sleep() operation code, possibly requesting delays that could
be measured in days.
Discussed with jmcneill@.
XXX: While the used mstohz(9) is documented to round to one second if the
passed value is larger than 131072 ms, we may still need to force a
sensible upper limit if this warning starts to appear.
include all device nodes, regardless of the status of the device.
XXX: It is known that some systems implement the _STA method incorrectly.
If needed in the future, attachment based on the values from this
method may need revisiting. Same goes for ACPI_ACTIVATE_DEV.
laptop there is a PNP0C0B ("ACPI fan") with the following properties:
_PSC : Power state for D3 (alone).
_PR0 : Power resources for D0.
_PSx : Power state switch for D0 and D3.
Thus, it is impossible to get or set the D3 power state via power resources
alone; there is only a single PowerResource() and it is for D0.
To tackle this:
1. Evaluate the direct _PSC control method if and only if there is no
given _PRx. The order is important; it is known that some other
systems implement the _PSC method (like _STA) incorrectly.
2. If no _PRx is available (and thus no _ON or _OFF), do not error out.
Instead, if we have AE_NOT_FOUND, continue to evaluate the power state
switch method, _PSx, which (on this laptop) should alone suffice for
the D0 -> D3 transition.
admirable goal, it is pretty much mission impossible; the specifications are
nearly thousand pages each and the amount of methods is counted in hundreds.
In addition, use ACPICA's native constants from <actypes.h> when possible.
Also move ACPI_STA_OK from "mpacpi.c" to <dev/acpi/acpireg.h> to simplify
the evaluation of device status.
We really should not add code that aims to satisfy some oddball firmware,
not in the generic drivers that aim to comply with the specifications.
In the long-term this is even worse than quirk tables.
This in turn was caused by a bug in ACPICA, which reports the types of _SB_
and _TZ_ scopes incorrectly for its own internal reasons (utglobal.c):
/*
* Predefined ACPI Names (Built-in to the Interpreter)
*
* NOTES:
* 1) _SB_ is defined to be a device to allow \_SB_._INI to be run
* during the initialization sequence.
* 2) _TZ_ is defined to be a thermal zone in order to allow ASL code to
* perform a Notify() operation on it.
*/
Thanks to cegger@ for noticing the bug and testing a fix.
This retrieves a struct acpi_devnode from a handle. Since this requires
accessing the global softc, it is better to do it in one place alone. The
same goes for possible locking of the node-queue; it is better not to
publicize such a lock for generic device drivers.
detachment routine for acpitz(4). Add comments explaining the relationship
between power resources and active cooling. Also some improvements to code
readability.
The old code served us well, but a major overhaul would have been needed for
it to cope with the increased demands of the code -- and the specifications.
ok jmcneill@, pgoyette@
correctly pick PCI segment groups, PCI bus numbers, PCI root bridges,
PCI-to-PCI bridges, and PCI devices, among other things. In short: it is
more robust than the old code or anything in sys/arch/x86/x86/mpacpi.c.
ok cegger@, jmcneill@
installed via AcpiInstallAddressSpaceHandler(). This was already commented
out because ACPICA does this for us when ACPI_NO_ADDRESS_SPACE_INIT is not
specified when calling AcpiEnableSubsystem().
AcpiInitializeTables() instead of pushing 128 statically allocated
descriptors. This will eliminate also the need to call
AcpiReallocateRootTable().
The rationale for the statically allocated table descriptors is to allow
initialization without virtual/dynamic memory. Later these should be copied
to dynamic memory via AcpiReallocateRootTable(). But since in NetBSD both
functions were called in the very same acpi_probe(), this dance was
completely unnecessary.
around so that they appear in their logical order and place, etc. In
addition, split the utility functions to a separate file.
No functional change. Ok jmcneill@.
Changes:
hw.wake -> hw.acpi.wake
hw.acpi.debug_layer -> hw.acpi.debug.layer
hw.acpi.debug_level -> hw.acpi.debug.level
Additions:
hw.acpi.stat.gpe # Number of dispatched GPEs
hw.acpi.stat.sci # Number of SCI interrupts
hw.acpi.stat.fixed # Number of fixed events
hw.acpi.stat.method # Number of executed methods
ok jmcneill@
ok jmcneill@
XXX: This is broken: it calls methods with absolute pathnames (almost
guaranteed not to be portable across models), it accesses methods
that are in the domain of other drivers, it walks the namespace on
its own, it contains plenty of magic constants, it does not
integrate with existing KPIs, etc. Summa summarum: this should be
rewritten as a more generic toshiba_acpi(4).
Thanks to apb@ and cegger@ for initial testing.
XXX: This conflicts with hpqlb(4). Someone with the suitable hardware needs
to complete the list of hotkeys before -- and if -- this can replace
hpqlb(4). For now, the driver was left uncommented in the GENERICs.
Implemented a post-order callback to AcpiWalkNamespace. The existing
interface only has a pre-order callback. This change adds an
additional parameter for a post-order callback which will be more
useful for bus scans. ACPICA BZ 779. Lin Ming. Updated the ACPICA
Programmer Reference.
We will use the old "pre-order callback" for the time being.
initialization of sysmon_envsys(9), otherwise, if _STA does not return true
during the attachment of the driver, it is possible that a flag is never
set. This flaw has always been present, but it only got exposed after the
conversion to use the sysmon-limits.
Note, config whines about things like:
files.acpi:30: attaching undefined device `apm'
I intentionally was a lazy boy and didn't include a ton of dirt to
keep the hot napalm and riot blasts in the config thread rolling ;)
tested by jruoho (thanks!)
information related to ACPI device nodes: (a) introduce a generic scan
function for ACPI device driver "capabilities", and (b) eliminate local data
structures from ACPI wake-devices. Discussed with jmcneill@.
