mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-10-31 08:28:13 +00:00
ffc10d82ff
/sys/firmware/acpi/hotplug/force_remove was presumably added to support auto offlining in the past. This is, however, inherently dangerous for some hotplugable resources like memory. The memory offlining fails when the memory is still in use and cannot be dropped or migrated. If we ignore the failure we are basically allowing for subtle memory corruption or a crash. We have actually noticed the later while hitting BUG() during the memory hotremove (remove_memory): ret = walk_memory_range(PFN_DOWN(start), PFN_UP(start + size - 1), NULL, check_memblock_offlined_cb); if (ret) BUG(); it took us quite non-trivial time realize that the customer had force_remove enabled. Even if the BUG was removed here and we could propagate the error up the call chain it wouldn't help at all because then we would hit a crash or a memory corruption later and harder to debug. So force_remove is unfixable for the memory hotremove. We haven't checked other hotplugable resources to be prone to a similar problems. Remove the force_remove functionality because it is not fixable currently. Keep the sysfs file and report an error if somebody tries to enable it. Encourage users to report about the missing functionality and work with them with an alternative solution. Reviewed-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
196 lines
6.1 KiB
Text
196 lines
6.1 KiB
Text
What: /sys/firmware/acpi/bgrt/
|
|
Date: January 2012
|
|
Contact: Matthew Garrett <mjg@redhat.com>
|
|
Description:
|
|
The BGRT is an ACPI 5.0 feature that allows the OS
|
|
to obtain a copy of the firmware boot splash and
|
|
some associated metadata. This is intended to be used
|
|
by boot splash applications in order to interact with
|
|
the firmware boot splash in order to avoid jarring
|
|
transitions.
|
|
|
|
image: The image bitmap. Currently a 32-bit BMP.
|
|
status: 1 if the image is valid, 0 if firmware invalidated it.
|
|
type: 0 indicates image is in BMP format.
|
|
version: The version of the BGRT. Currently 1.
|
|
xoffset: The number of pixels between the left of the screen
|
|
and the left edge of the image.
|
|
yoffset: The number of pixels between the top of the screen
|
|
and the top edge of the image.
|
|
|
|
What: /sys/firmware/acpi/hotplug/
|
|
Date: February 2013
|
|
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Description:
|
|
There are separate hotplug profiles for different classes of
|
|
devices supported by ACPI, such as containers, memory modules,
|
|
processors, PCI root bridges etc. A hotplug profile for a given
|
|
class of devices is a collection of settings defining the way
|
|
that class of devices will be handled by the ACPI core hotplug
|
|
code. Those profiles are represented in sysfs as subdirectories
|
|
of /sys/firmware/acpi/hotplug/.
|
|
|
|
The following setting is available to user space for each
|
|
hotplug profile:
|
|
|
|
enabled: If set, the ACPI core will handle notifications of
|
|
hotplug events associated with the given class of
|
|
devices and will allow those devices to be ejected with
|
|
the help of the _EJ0 control method. Unsetting it
|
|
effectively disables hotplug for the correspoinding
|
|
class of devices.
|
|
|
|
The value of the above attribute is an integer number: 1 (set)
|
|
or 0 (unset). Attempts to write any other values to it will
|
|
cause -EINVAL to be returned.
|
|
|
|
What: /sys/firmware/acpi/interrupts/
|
|
Date: February 2008
|
|
Contact: Len Brown <lenb@kernel.org>
|
|
Description:
|
|
All ACPI interrupts are handled via a single IRQ,
|
|
the System Control Interrupt (SCI), which appears
|
|
as "acpi" in /proc/interrupts.
|
|
|
|
However, one of the main functions of ACPI is to make
|
|
the platform understand random hardware without
|
|
special driver support. So while the SCI handles a few
|
|
well known (fixed feature) interrupts sources, such
|
|
as the power button, it can also handle a variable
|
|
number of a "General Purpose Events" (GPE).
|
|
|
|
A GPE vectors to a specified handler in AML, which
|
|
can do a anything the BIOS writer wants from
|
|
OS context. GPE 0x12, for example, would vector
|
|
to a level or edge handler called _L12 or _E12.
|
|
The handler may do its business and return.
|
|
Or the handler may send send a Notify event
|
|
to a Linux device driver registered on an ACPI device,
|
|
such as a battery, or a processor.
|
|
|
|
To figure out where all the SCI's are coming from,
|
|
/sys/firmware/acpi/interrupts contains a file listing
|
|
every possible source, and the count of how many
|
|
times it has triggered.
|
|
|
|
$ cd /sys/firmware/acpi/interrupts
|
|
$ grep . *
|
|
error: 0
|
|
ff_gbl_lock: 0 enable
|
|
ff_pmtimer: 0 invalid
|
|
ff_pwr_btn: 0 enable
|
|
ff_rt_clk: 2 disable
|
|
ff_slp_btn: 0 invalid
|
|
gpe00: 0 invalid
|
|
gpe01: 0 enable
|
|
gpe02: 108 enable
|
|
gpe03: 0 invalid
|
|
gpe04: 0 invalid
|
|
gpe05: 0 invalid
|
|
gpe06: 0 enable
|
|
gpe07: 0 enable
|
|
gpe08: 0 invalid
|
|
gpe09: 0 invalid
|
|
gpe0A: 0 invalid
|
|
gpe0B: 0 invalid
|
|
gpe0C: 0 invalid
|
|
gpe0D: 0 invalid
|
|
gpe0E: 0 invalid
|
|
gpe0F: 0 invalid
|
|
gpe10: 0 invalid
|
|
gpe11: 0 invalid
|
|
gpe12: 0 invalid
|
|
gpe13: 0 invalid
|
|
gpe14: 0 invalid
|
|
gpe15: 0 invalid
|
|
gpe16: 0 invalid
|
|
gpe17: 1084 enable
|
|
gpe18: 0 enable
|
|
gpe19: 0 invalid
|
|
gpe1A: 0 invalid
|
|
gpe1B: 0 invalid
|
|
gpe1C: 0 invalid
|
|
gpe1D: 0 invalid
|
|
gpe1E: 0 invalid
|
|
gpe1F: 0 invalid
|
|
gpe_all: 1192
|
|
sci: 1194
|
|
sci_not: 0
|
|
|
|
sci - The number of times the ACPI SCI
|
|
has been called and claimed an interrupt.
|
|
|
|
sci_not - The number of times the ACPI SCI
|
|
has been called and NOT claimed an interrupt.
|
|
|
|
gpe_all - count of SCI caused by GPEs.
|
|
|
|
gpeXX - count for individual GPE source
|
|
|
|
ff_gbl_lock - Global Lock
|
|
|
|
ff_pmtimer - PM Timer
|
|
|
|
ff_pwr_btn - Power Button
|
|
|
|
ff_rt_clk - Real Time Clock
|
|
|
|
ff_slp_btn - Sleep Button
|
|
|
|
error - an interrupt that can't be accounted for above.
|
|
|
|
invalid: it's either a GPE or a Fixed Event that
|
|
doesn't have an event handler.
|
|
|
|
disable: the GPE/Fixed Event is valid but disabled.
|
|
|
|
enable: the GPE/Fixed Event is valid and enabled.
|
|
|
|
Root has permission to clear any of these counters. Eg.
|
|
# echo 0 > gpe11
|
|
|
|
All counters can be cleared by clearing the total "sci":
|
|
# echo 0 > sci
|
|
|
|
None of these counters has an effect on the function
|
|
of the system, they are simply statistics.
|
|
|
|
Besides this, user can also write specific strings to these files
|
|
to enable/disable/clear ACPI interrupts in user space, which can be
|
|
used to debug some ACPI interrupt storm issues.
|
|
|
|
Note that only writing to VALID GPE/Fixed Event is allowed,
|
|
i.e. user can only change the status of runtime GPE and
|
|
Fixed Event with event handler installed.
|
|
|
|
Let's take power button fixed event for example, please kill acpid
|
|
and other user space applications so that the machine won't shutdown
|
|
when pressing the power button.
|
|
# cat ff_pwr_btn
|
|
0 enabled
|
|
# press the power button for 3 times;
|
|
# cat ff_pwr_btn
|
|
3 enabled
|
|
# echo disable > ff_pwr_btn
|
|
# cat ff_pwr_btn
|
|
3 disabled
|
|
# press the power button for 3 times;
|
|
# cat ff_pwr_btn
|
|
3 disabled
|
|
# echo enable > ff_pwr_btn
|
|
# cat ff_pwr_btn
|
|
4 enabled
|
|
/*
|
|
* this is because the status bit is set even if the enable bit is cleared,
|
|
* and it triggers an ACPI fixed event when the enable bit is set again
|
|
*/
|
|
# press the power button for 3 times;
|
|
# cat ff_pwr_btn
|
|
7 enabled
|
|
# echo disable > ff_pwr_btn
|
|
# press the power button for 3 times;
|
|
# echo clear > ff_pwr_btn /* clear the status bit */
|
|
# echo disable > ff_pwr_btn
|
|
# cat ff_pwr_btn
|
|
7 enabled
|
|
|