http://blog.gmane.org/gmane.linux.acpi.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.acpi.devel/61606 <pre> Hi, Bob and Rafael, I'm out of the dialogue. I was working on other things. Thanks for doing so on PATCH 13-15 for me. I found them in the bleeding-edge branch of linux-pm repo. Many of the commit log issues are issues happened along with the release automation. I just played a monkey role in the release process with some committed tests performed. I agree it's a kind of policy issues. I will improve the release process continuously. Best regards -Lv </pre> Zheng, Lv 2013-06-20T00:41:49 http://permalink.gmane.org/gmane.linux.acpi.devel/61605 <pre>ACPI is implemented as a subsystem in Linux, it creates a device tree by mapping specific ACPI namespace objects (Device/Processor/PowerResource/ThermalZone) into Linux device objects. This patch adds documentation for the ACPI device tree. Signed-off-by: Lv Zheng &lt;lv.zheng&lt; at &gt;intel.com&gt; --- Documentation/acpi/namespace.txt | 395 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 Documentation/acpi/namespace.txt diff --git a/Documentation/acpi/namespace.txt b/Documentation/acpi/namespace.txt new file mode 100644 index 0000000..260f6a3 --- /dev/null +++ b/Documentation/acpi/namespace.txt &lt; at &gt;&lt; at &gt; -0,0 +1,395 &lt; at &gt;&lt; at &gt; +ACPI Device Tree - Representation of ACPI Namespace + +Copyright (C) 2013, Intel Corporation +Author: Lv Zheng &lt;lv.zheng&lt; at &gt;intel.com&gt; + + +Abstract: + +The Linux ACPI subsystem converts ACPI namespace objects into a Linux +device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon +receiving ACPI hotplug notification events. For each device object in this +hierarchy there is a corresponding symbolic link in the +/sys/bus/acpi/devices. +This document illustrates the structure of the ACPI device tree. + + +Credit: + +Thanks for the help from Zhang Rui &lt;rui.zhang&lt; at &gt;intel.com&gt; and Rafael J. +Wysocki &lt;rafael.j.wysocki&lt; at &gt;intel.com&gt;. + + +1. ACPI Definition Blocks + + The ACPI firmware sets up RSDP (Root System Description Pointer) in the + system memory address space pointing to the XSDT (Extended System + Description Table). The XSDT always points to the FADT (Fixed ACPI + Description Table) using its first entry, the data within the FADT + includes various fixed-length entries that describe fixed ACPI features + of the hardware. The FADT contains a pointer to the DSDT + (Differentiated System Descripition Table). The XSDT also contains + entries pointing to possibly multiple SSDTs (Secondary System + Description Table). + + The DSDT and SSDT data is organized in data structures called definition + blocks that contain definitions of various objects, including ACPI + control methods, encoded in AML (ACPI Machine Language). The data block + of the DSDT along with the contents of SSDTs represents a hierarchical + data structure called the ACPI namespace whose topology reflects the + structure of the underlying hardware platform. + + The relationships between ACPI System Definition Tables described above + are illustrated in the following diagram. + + +---------+ +-------+ +--------+ +------------------------+ + | RSDP | +-&gt;| XSDT | +-&gt;| FADT | | +-------------------+ | + +---------+ | +-------+ | +--------+ +-|-&gt;| DSDT | | + | Pointer | | | Entry |-+ | ...... | | | +-------------------+ | + +---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | | + | Pointer |-+ | ..... | | ...... | | +-------------------+ | + +---------+ +-------+ +--------+ | +-------------------+ | + | Entry |------------------|-&gt;| SSDT | | + +- - - -+ | +-------------------| | + | Entry | - - - - - - - -+ | | Definition Blocks | | + +- - - -+ | | +-------------------+ | + | | +- - - - - - - - - -+ | + +-|-&gt;| SSDT | | + | +-------------------+ | + | | Definition Blocks | | + | +- - - - - - - - - -+ | + +------------------------+ + | + OSPM Loading | + \|/ + +----------------+ + | ACPI Namespace | + +----------------+ + + Figure 1. ACPI Definition Blocks + + NOTE: RSDP can also contain a pointer to the RSDT (Root System + Description Table). Platforms provide RSDT to enable + compatibility with ACPI 1.0 operating systems. The OS is expected + to use XSDT, if present. + + +2. Example ACPI Namespace + + All definition blocks are loaded into a single namespace. The namespace + is a hierarchy of objects identified by names and paths. + The following naming conventions apply to object names in the ACPI + namespace: + 1. All names are 32 bits long. + 2. The first byte of a name must be one of 'A' - 'Z', '_'. + 3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0' + - '9', '_'. + 4. Names starting with '_' are reserved by the ACPI specification. + 5. The '\' symbol represents the root of the namespace (i.e. names + prepended with '\' are relative to the namespace root). + 6. The '^' symbol represents the parent of the current namespace node + (i.e. names prepended with '^' are relative to the parent of the + current namespace node). + + The figure below shows an example ACPI namespace. + + +------+ + | \ | Root + +------+ + | + | +------+ + +-| _PR | Scope(_PR): the processor namespace + | +------+ + | | + | | +------+ + | +-| CPU0 | Processor(CPU0): the first processor + | +------+ + | + | +------+ + +-| _SB | Scope(_SB): the system bus namespace + | +------+ + | | + | | +------+ + | +-| LID0 | Device(LID0); the lid device + | | +------+ + | | | + | | | +------+ + | | +-| _HID | Name(_HID, "PNP0C0D"): the hardware ID + | | | +------+ + | | | + | | | +------+ + | | +-| _STA | Method(_STA): the status control method + | | +------+ + | | + | | +------+ + | +-| PCI0 | Device(PCI0); the PCI root bridge + | +------+ + | | + | | +------+ + | +-| _HID | Name(_HID, "PNP0A08"): the hardware ID + | | +------+ + | | + | | +------+ + | +-| _CID | Name(_CID, "PNP0A03"): the compatible ID + | | +------+ + | | + | | +------+ + | +-| RP03 | Scope(RP03): the PCI0 power scope + | | +------+ + | | | + | | | +------+ + | | +-| PXP3 | PowerResource(PXP3): the PCI0 power resource + | | +------+ + | | + | | +------+ + | +-| GFX0 | Device(GFX0): the graphics adapter + | +------+ + | | + | | +------+ + | +-| _ADR | Name(_ADR, 0x00020000): the PCI bus address + | | +------+ + | | + | | +------+ + | +-| DD01 | Device(DD01): the LCD output device + | +------+ + | | + | | +------+ + | +-| _BCL | Method(_BCL): the backlight control method + | +------+ + | + | +------+ + +-| _TZ | Scope(_TZ): the thermal zone namespace + | +------+ + | | + | | +------+ + | +-| FN00 | PowerResource(FN00): the FAN0 power resource + | | +------+ + | | + | | +------+ + | +-| FAN0 | Device(FAN0): the FAN0 cooling device + | | +------+ + | | | + | | | +------+ + | | +-| _HID | Name(_HID, "PNP0A0B"): the hardware ID + | | +------+ + | | + | | +------+ + | +-| TZ00 | ThermalZone(TZ00); the FAN thermal zone + | +------+ + | + | +------+ + +-| _GPE | Scope(_GPE): the GPE namespace + +------+ + + Figure 2. Example ACPI Namespace + + +3. Linux ACPI Device Objects + + The Linux kernel's core ACPI subsystem creates struct acpi_device + objects for ACPI namespace objects representing devices, power resources + processors, thermal zones. Those objects are exported to user space via + sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The + format of their names is &lt;bus_id:instance&gt;, where 'bus_id' refers to the + ACPI namespace representation of the given object and 'instance' is used + for distinguishing different object of the same 'bus_id' (it is + two-digit decimal representation of an unsigned integer). + + The value of 'bus_id' depends on the type of the object whose name it is + part of as listed in the table below. + + +---+-----------------+-------+----------+ + | | Object/Feature | Table | bus_id | + +---+-----------------+-------+----------+ + | N | Root | xSDT | LNXSYSTM | + +---+-----------------+-------+----------+ + | N | Device | xSDT | _HID | + +---+-----------------+-------+----------+ + | N | Processor | xSDT | LNXCPU | + +---+-----------------+-------+----------+ + | N | ThermalZone | xSDT | LNXTHERM | + +---+-----------------+-------+----------+ + | N | PowerResource | xSDT | LNXPOWER | + +---+-----------------+-------+----------+ + | N | Other Devices | xSDT | device | + +---+-----------------+-------+----------+ + | F | PWR_BUTTON | FADT | LNXPWRBN | + +---+-----------------+-------+----------+ + | F | SLP_BUTTON | FADT | LNXSLPBN | + +---+-----------------+-------+----------+ + | M | Video Extension | xSDT | LNXVIDEO | + +---+-----------------+-------+----------+ + | M | ATA Controller | xSDT | LNXIOBAY | + +---+-----------------+-------+----------+ + | M | Docking Station | xSDT | LNXDOCK | + +---+-----------------+-------+----------+ + + Table 1. ACPI Namespace Objects Mapping + + The following rules apply when creating struct acpi_device objects on + the basis of the contents of ACPI System Description Tables (as + indicated by the letter in the first column and the notation in the + second column of the table above): + N: + The object's source is an ACPI namespace node (as indicated by the + named object's type in the second column). In that case the object's + directory in sysfs will contain the 'path' attribute whose value is + the full path to the node from the namespace root. + struct acpi_device objects are created for the ACPI namespace nodes + whose _STA control methods return PRESENT or FUNCTIONING. The power + resource nodes or nodes without _STA are assumed to be both PRESENT + and FUNCTIONING. + F: + The struct acpi_device object is created for a fixed hardware + feature (as indicated by the fixed feature flag's name in the second + column), so its sysfs directory will not contain the 'path' + attribute. + M: + The struct acpi_device object is created for an ACPI namespace node + with specific control methods (as indicated by the ACPI defined + device's type in the second column). The 'path' attribute containing + its namespace path will be present in its sysfs directory. For + example, if the _BCL method is present for an ACPI namespace node, a + struct acpi_device object with LNXVIDEO 'bus_id' will be created for + it. + + The third column of the above table indicates which ACPI System + Description Tables contain information used for the creation of the + struct acpi_device objects represented by the given row (xSDT means DSDT + or SSDT). + + The forth column of the above table indicates the 'bus_id' generation + rule of the struct acpi_device object: + _HID: + _HID in the last column of the table means that the object's bus_id + is derived from the _HID/_CID identification objects present under + the corresponding ACPI namespace node. The object's sysfs directory + will then contain the 'hid' and 'modalias' attributes that can be + used to retrieve the _HID and _CIDs of that object. + LNXxxxxx: + The 'modalias' attribute is also present for struct acpi_device + objects having bus_id of the "LNXxxxxx" form (pseudo devices), in + which cases it contains the bus_id string itself. + device: + 'device' in the last column of the table indicates that the object's + bus_id cannot be determined from _HID/_CID of the corresponding + ACPI namespace node, although that object represents a device (for + example, it may be a PCI device with _ADR defined and without _HID + or _CID). In that case the string 'device' will be used as the + object's bus_id. + + +4. Linux ACPI Physical Device Glue + + ACPI device (i.e. struct acpi_device) objects may be linked to other + objects in the Linux' device hierarchy that represent "physical" devices + (for example, devices on the PCI bus). If that happens, it means that + the ACPI device object is a "companion" of a device otherwise + represented in a different way and is used (1) to provide configuration + information on that device which cannot be obtained by other means and + (2) to do specific things to the device with the help of its ACPI + control methods. One ACPI device object may be linked this way to + multiple "physical" devices. + + If an ACPI device object is linked to a "physical" device, its sysfs + directory contains the "physical_node" symbolic link to the sysfs + directory of the target device object. In turn, the target device's + sysfs directory will then contain the "firmware_node" symbolic link to + the sysfs directory of the companion ACPI device object. + The linking mechanism relies on device identification provided by the + ACPI namespace. For example, if there's an ACPI namespace object + representing a PCI device (i.e. a device object under an ACPI namespace + object representing a PCI bridge) whose _ADR returns 0x00020000 and the + bus number of the parent PCI bridge is 0, the sysfs directory + representing the struct acpi_device object created for that ACPI + namespace object will contain the 'physical_node' symbolic link to the + /sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the + corresponding PCI device. + + The linking mechanism is generally bus-specific. The core of its + implementation is located in the drivers/acpi/glue.c file, but there are + complementary parts depending on the bus types in question located + elsewhere. For example, the PCI-specific part of it is located in + drivers/pci/pci-acpi.c. + + +5. Example Linux ACPI Device Tree + + The sysfs hierarchy of struct acpi_device objects corresponding to the + example ACPI namespace illustrated in Figure 2 with the addition of + fixed PWR_BUTTON/SLP_BUTTON devices is shown below. + + +--------------+---+-----------------+ + | LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: | + +--------------+---+-----------------+ + | + | +-------------+-----+----------------+ + +-| LNXPWRBN:00 | N/A | acpi:LNXPWRBN: | + | +-------------+-----+----------------+ + | + | +-------------+-----+----------------+ + +-| LNXSLPBN:00 | N/A | acpi:LNXSLPBN: | + | +-------------+-----+----------------+ + | + | +-----------+------------+--------------+ + +-| LNXCPU:00 | \_PR_.CPU0 | acpi:LNXCPU: | + | +-----------+------------+--------------+ + | + | +-------------+-------+----------------+ + +-| LNXSYBUS:00 | \_SB_ | acpi:LNXSYBUS: | + | +-------------+-------+----------------+ + | | + | | +- - - - - - - +- - - - - - +- - - - - - - -+ + | +-| * PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: | + | | +- - - - - - - +- - - - - - +- - - - - - - -+ + | | + | | +------------+------------+-----------------------+ + | +-| PNP0A08:00 | \_SB_.PCI0 | acpi:PNP0A08:PNP0A03: | + | +------------+------------+-----------------------+ + | | + | | +-----------+-----------------+-----+ + | +-| device:00 | \_SB_.PCI0.RP03 | N/A | + | | +-----------+-----------------+-----+ + | | | + | | | +-------------+----------------------+----------------+ + | | +-| LNXPOWER:00 | \_SB_.PCI0.RP03.PXP3 | acpi:LNXPOWER: | + | | +-------------+----------------------+----------------+ + | | + | | +-------------+-----------------+----------------+ + | +-| LNXVIDEO:00 | \_SB_.PCI0.GFX0 | acpi:LNXVIDEO: | + | +-------------+-----------------+----------------+ + | | + | | +-----------+-----------------+-----+ + | +-| device:01 | \_SB_.PCI0.DD01 | N/A | + | +-----------+-----------------+-----+ + | + | +-------------+-------+----------------+ + +-| LNXSYBUS:01 | \_TZ_ | acpi:LNXSYBUS: | + +-------------+-------+----------------+ + | + | +-------------+------------+----------------+ + +-| LNXPOWER:0a | \_TZ_.FN00 | acpi:LNXPOWER: | + | +-------------+------------+----------------+ + | + | +------------+------------+---------------+ + +-| PNP0C0B:00 | \_TZ_.FAN0 | acpi:PNP0C0B: | + | +------------+------------+---------------+ + | + | +-------------+------------+----------------+ + +-| LNXTHERM:00 | \_TZ_.TZ00 | acpi:LNXTHERM: | + +-------------+------------+----------------+ + + Figure 3. Example Linux ACPI Device Tree + + NOTE: Each node is represented as "object/path/modalias", where: + 1. 'object' is the name of the object's directory in sysfs. + 2. 'path' is the ACPI namespace path of the corresponding + ACPI namespace object, as returned by the object's 'path' + sysfs attribute. + 3. 'modalias' is the value of the object's 'modalias' sysfs + attribute (as described earlier in this document). + NOTE: N/A indicates the device object does not have the 'path' or the + 'modalias' attribute. + NOTE: The PNP0C0D device listed above is highlighted (marked by "*") + to indicate it will be created only when its _STA methods return + PRESENT or FUNCTIONING. </pre> Lv Zheng 2013-06-20T00:03:13 http://permalink.gmane.org/gmane.linux.acpi.devel/61604 <pre>Add initial ABI documentation for ACPI devices' sysfs interfaces. Contacts information fields are filled with current ACPI maintainer and the relevant authors are carbon copied. Signed-off-by: Lv Zheng &lt;lv.zheng&lt; at &gt;intel.com&gt; Cc: Lance Ortiz &lt;lance.ortiz&lt; at &gt;hp.com&gt; Cc: Lv Zheng &lt;lv.zheng&lt; at &gt;intel.com&gt; Cc: Patrick Mochel &lt;mochel&lt; at &gt;osdl.org&gt; Cc: Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt; Cc: Thomas Renninger &lt;trenn&lt; at &gt;suse.de&gt; Cc: Zhang Rui &lt;rui.zhang&lt; at &gt;intel.com&gt; --- Documentation/ABI/testing/sysfs-bus-acpi | 58 +++++++++++++++++++++++++++ Documentation/ABI/testing/sysfs-devices-sun | 2 +- MAINTAINERS | 1 + 3 files changed, 60 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-acpi diff --git a/Documentation/ABI/testing/sysfs-bus-acpi b/Documentation/ABI/testing/sysfs-bus-acpi new file mode 100644 index 0000000..c8942e9 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-acpi &lt; at &gt;&lt; at &gt; -0,0 +1,58 &lt; at &gt;&lt; at &gt; +What:/sys/bus/acpi/devices/.../path +Date:December 2006 +Contact:Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt; +Description: +This attribute indicates the full path of ACPI namespace +object associated with the device object. For example, +\_SB_.PCI0. +This file is not present for device objects representing +fixed ACPI hardware features (like power and sleep +buttons). + +What:/sys/bus/acpi/devices/.../modalias +Date:July 2007 +Contact:Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt; +Description: +This attribute indicates the PNP IDs of the device object. +That is acpi:HHHHHHHH:[CCCCCCC:]. Where each HHHHHHHH or +CCCCCCCC contains device object's PNPID (_HID or _CID). + +What:/sys/bus/acpi/devices/.../hid +Date:April 2005 +Contact:Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt; +Description: +This attribute indicates the hardware ID (_HID) of the +device object. For example, PNP0103. +This file is present for device objects having the _HID +control method. + +What:/sys/bus/acpi/devices/.../description +Date:October 2012 +Contact:Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt; +Description: +This attribute contains the output of the device object's +_STR control method, if present. + +What:/sys/bus/acpi/devices/.../adr +Date:October 2012 +Contact:Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt; +Description: +This attribute contains the output of the device object's +_ADR control method, which is present for ACPI device +objects representing devices having standard enumeration +algorithms, such as PCI. + +What:/sys/bus/acpi/devices/.../uid +Date:October 2012 +Contact:Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt; +Description: +This attribute contains the output of the device object's +_UID control method, if present. + +What:/sys/bus/acpi/devices/.../eject +Date:December 2006 +Contact:Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt; +Description: +Writing 1 to this attribute will trigger hot removal of +this device object. This file exists for every device +object that has _EJ0 method. diff --git a/Documentation/ABI/testing/sysfs-devices-sun b/Documentation/ABI/testing/sysfs-devices-sun index 86be984..625ce4b 100644 --- a/Documentation/ABI/testing/sysfs-devices-sun +++ b/Documentation/ABI/testing/sysfs-devices-sun &lt; at &gt;&lt; at &gt; -1,4 +1,4 &lt; at &gt;&lt; at &gt; -Whatt:/sys/devices/.../sun +What:/sys/devices/.../sun Date:October 2012 Contact:Yasuaki Ishimatsu &lt;isimatu.yasuaki&lt; at &gt;jp.fujitsu.com&gt; Description: diff --git a/MAINTAINERS b/MAINTAINERS index 2634a7b..04a5fef 100644 --- a/MAINTAINERS +++ b/MAINTAINERS &lt; at &gt;&lt; at &gt; -243,6 +243,7 &lt; at &gt;&lt; at &gt; F:drivers/pnp/pnpacpi/ F:include/linux/acpi.h F:include/acpi/ F:Documentation/acpi +F:Documentation/ABI/testing/sysfs-bus-acpi ACPI FAN DRIVER M:Zhang Rui &lt;rui.zhang&lt; at &gt;intel.com&gt; </pre> Lv Zheng 2013-06-20T00:02:44 http://permalink.gmane.org/gmane.linux.acpi.devel/61603 <pre>Documentation/acpi contains all of the Docunmentation for the Linux/ACPI subsystem. Adds this to the MAINTAINERS file. Signed-off-by: Lv Zheng &lt;lv.zheng&lt; at &gt;intel.com&gt; --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 62bb9c9..2634a7b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS &lt; at &gt;&lt; at &gt; -242,6 +242,7 &lt; at &gt;&lt; at &gt; F:drivers/acpi/ F:drivers/pnp/pnpacpi/ F:include/linux/acpi.h F:include/acpi/ +F:Documentation/acpi ACPI FAN DRIVER M:Zhang Rui &lt;rui.zhang&lt; at &gt;intel.com&gt; </pre> Lv Zheng 2013-06-20T00:02:20 http://permalink.gmane.org/gmane.linux.acpi.devel/61602 <pre>This patch set adds 2 ACPI documentation files with MAINTAINERS updated. Lv Zheng (3): ACPI: Update MAINTAINERS file to include Documentation/acpi ACPI: Add sysfs ABI documentation ACPI: Add ACPI namespace documentation Documentation/ABI/testing/sysfs-bus-acpi | 58 ++++ Documentation/ABI/testing/sysfs-devices-sun | 2 +- Documentation/acpi/namespace.txt | 395 +++++++++++++++++++++++++++ MAINTAINERS | 2 + 4 files changed, 456 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-acpi create mode 100644 Documentation/acpi/namespace.txt </pre> Lv Zheng 2013-06-20T00:01:39 http://permalink.gmane.org/gmane.linux.acpi.devel/61601 <pre> That code comes from the ACPICA project and doesn't follow the usual Linux kernel coding style. Please do not run this on files under drivers/acpi/acpica/. Thanks, Rafael </pre> Rafael J. Wysocki 2013-06-20T00:07:22 http://permalink.gmane.org/gmane.linux.acpi.devel/61600 <pre> Queued up for 3.11. Thanks, Rafael </pre> Rafael J. Wysocki 2013-06-20T00:03:58 http://permalink.gmane.org/gmane.linux.acpi.devel/61598 <pre> Applied now. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Rafael J. Wysocki 2013-06-19T23:57:32 http://permalink.gmane.org/gmane.linux.acpi.devel/61597 <pre> Queued up for 3.11 with the above information added to the changelog. Thanks Bob! Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Rafael J. Wysocki 2013-06-19T23:57:08 http://permalink.gmane.org/gmane.linux.acpi.devel/61596 <pre> I've added this info to the changelog and queued up the patch for 3.11. Thanks Bob! Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Rafael J. Wysocki 2013-06-19T23:56:20 http://permalink.gmane.org/gmane.linux.acpi.devel/61595 <pre> Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Rafael J. Wysocki 2013-06-19T23:35:42 http://permalink.gmane.org/gmane.linux.acpi.devel/61594 <pre> For both patches: Acked-by: Toshi Kani &lt;toshi.kani&lt; at &gt;hp.com&gt; Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Toshi Kani 2013-06-19T23:22:04 http://permalink.gmane.org/gmane.linux.acpi.devel/61592 <pre> Great, I'll take the patch at that time, then. Well, this is much better than what Lv sent, actually. We could use it for Linux too, I think, only without the "Notes" part. My general opinion is that we can simply use the same changelogs as the ACPICA upstream does, possibly amended with a more detailed explanation of the motivation behind the patch. In this case, however, the changelog wasn't even similar to the original one. Thanks, Rafael </pre> Rafael J. Wysocki 2013-06-19T23:10:30 http://permalink.gmane.org/gmane.linux.acpi.devel/61591 <pre> I will, thank you! Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Rafael J. Wysocki 2013-06-19T22:51:23 http://permalink.gmane.org/gmane.linux.acpi.devel/61588 <pre> Yes - this case (where the BIOS did all the threshold math and made the decision) should be one where Linux kernel could just implement the action directly. Perhaps controlled by a knob to say whether we really trust the BIOS that much. But we will also have cases where a smart user agent can correlate data from multiple sources to identify the real root cause (e.g. some temperature anomalies around the same time as some memory errors that occur at 10am on the third Tuesday each month -&gt; cause is air conditioner maintenance guy that shuts down the a/c for 10 minutes to change the filter). I'll leave writing an agent that smart as an exercise for the concerned data center manager :-) -Tony </pre> Luck, Tony 2013-06-19T22:08:53 http://permalink.gmane.org/gmane.linux.acpi.devel/61587 <pre> If we're going to be vendor-specific (which I'm pretty sure we will), we'd gonna have to export knobs to userspace which each vendor can tweak for themselves. Otherwise we'd get the DMI quirks ugliness all over again and we better nip it in the bud, while we can. Ok, so some sort of userspace is enforcing policy based on collected data/heuristics. The above question about what to do *without* going to userspace and back is maybe more interesting and we'd need a clean design there... we'll see. I know - that's why I'm trying to poke holes early... </pre> Borislav Petkov 2013-06-19T21:41:45 http://permalink.gmane.org/gmane.linux.acpi.devel/61586 <pre> Naveen - this one is for you (or for your BIOS team). Can you get us a sample CPER that you plan to provide when the BIOS decides that its threshold has been exceeded? How will it be different from what old WSM-EX platforms were sending to us? Hopefully the answer is encoded in the CPER record and not in some code we have to put in Linux to say "if (IBMplatform) do_thing_1(); else ... " mcelog(8) daemon has been doing this for years ... but it used the "predictive failure analysis" buzzwords that were popular way back then (today the marketing people seem to prefer "self healing" ). Whatever the name, the concept is the same ... take some set of corrected event reports and infer from them that something worse may happen soon, and use that information to try to avoid the (possibly) impending crash. Questions are good - they help fill out gaps -Tony </pre> Luck, Tony 2013-06-19T21:28:50 http://permalink.gmane.org/gmane.linux.acpi.devel/61585 <pre> Actually it uses ftrace's facilities but it is a tracepoint in the end. And I asked him nicely not to call it rasdaemon because I already have a RAS daemon but hey, whatever. The more confusion, the better. Ok, where is that semantics? What in a CPER record does say "this error should tell you that you need to offline the containing page and I'm telling you this exactly only once"? Error Severity 0, i.e. Recoverable? Ok, we're talking about the S in RAS now. Do we have error recovery strategies specified anywhere? Are they per-platform or generic? Is this CPER strategy above, for example, only valid for some platforms or for all APEI-using hardware? Questions over questions... </pre> Borislav Petkov 2013-06-19T21:07:06 http://permalink.gmane.org/gmane.linux.acpi.devel/61584 <pre> Oh ye of little faith - I'm sure the BIOS will get this right this time :-) Yes - a tracepoint is the right answer here for all the new stuff. Mauro has a rasdaemon in progress git://git.fedorahosted.org/rasdaemon.git just picks up perf/events and logs to a sqlite database. Because Linux can do runtime things that the BIOS can't - like offline a 4K page. Idea here is that BIOS does whatever the OEM thinks is the right level of threshholding - not bothering the OS with petty details of random corrected erorrs that mean nothing. But if there is some repeated error (like a stuck bit) then the BIOS can provide a CPER to the OS telling it that it would be a good idea to stop using that page. And this is where the semantics of a CPER change between the original WSM-EX implementation ... where Linux expects to see all the errors and do its own thresholding only taking a page offline if it sees a lot of CPER refer to the same page; and now - where the BIOS does the counting and tells Linux just once to take the page offline. -Tony </pre> Luck, Tony 2013-06-19T20:33:49 http://permalink.gmane.org/gmane.linux.acpi.devel/61583 <pre> Ha! Great, the CPER record is described in the UEFI spec. Those BIOS people are all like a mafia. Ok, seriously: so the situation should still be fine, FF reported errors get the CPER format while the rest, the "old" MCE format. cper.c is doing printk so I'm guessing it would need to get its own tracepoint and carry that to userspace. Concerning the RAS daemon, Robert and I are making good progress so once we have the persistent events in perf, we can read that tracepoint in userspace and do whatever we want with the error info. Why would Linux have to intervene if it is doing FF - wasn't the deal behind Firmware First for the firmware to get the error first and handle accordingly? </pre> Borislav Petkov 2013-06-19T20:14:38 http://permalink.gmane.org/gmane.linux.acpi.devel/61582 <pre> There is (or should be) a lot more interesting stuff in the CPER than just the address. Stuff that we don't have fields for in the existing mcelog structure. We also need to treat filtered records from modern APEI implementations a bit differently from the old stuff. The original user of this code was Westmere-EX, which used it as a workaround for a missing address in MCi_ADDR for corrected errors. So in that scenario we had every error being reported and mcelog(8) deamon doing the threshold analysis to decide when to take action. In this new modern world - Naveen wants to have the BIOS decide the threshold, so we'd like Linux to take some action as soon as it sees just one CPER. -Tony </pre> Luck, Tony 2013-06-19T19:05:16 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.acpi.devel