Bug 150841
| Summary: | Module level code (Lock) - sysfs is broken due to LoadTable("OEM"...) | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Lv Zheng (lv.zheng) |
| Component: | ACPICA-Core | Assignee: | Lv Zheng (lv.zheng) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | high | CC: | francisco.j.leoner.soto, jason.voelz |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.10, 4.6 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg from Fedora 24 boot
Dmseg log [PATCH 1/5] ACPICA: Tables: Remove acpi_tb_install_fixed_table() [PATCH 2/5] ACPICA: Tables: Remove wrong table event macros [PATCH 3/5] ACPICA: Tables: Add new table events indicating table installation/uninstallation [PATCH 4/5] ACPI / sysfs: Fix an issue for LoadTable opcode [PATCH 5/5] ACPI / sysfs: Update sysfs signature handling code |
||
Hi, Jason (jason.voelz@intel.com) Could you provide dmesg output (kernel boot log) using the latest upstream kernel? Thanks Created attachment 227481 [details]
dmesg from Fedora 24 boot
Created attachment 227571 [details]
Dmseg log
Dmesg from RHEL 7.2 Kernel 3.10.0-327
I think the problem is related to the acpidump. Could you also upload acpidump -v output here? Thanks Lv acpidump -v Intel ACPI Component Architecture ACPI Binary Table Dump Utility version 20160729-64 Copyright (c) 200 - 2016 Intel Corporation There is a known bug in ACPICA/Linux sysfs code. IMO, ACPICA should provide INSTALL/UNINSTALL table events. So that Linux can use these events instead of LOAD/UNLOAD events to insert dynamic tables into sysfs folder. The known problem is related to LoadTable opcode. For which, the target table should have already been listed in RSDT/XSDT (INSTALLED). So when sysfs code enumerated tables, this table can be found. When LoadTable opcode is invoked, sysfs code could see this table again via LOAD event. This might be the cause of OEM12 file. And using LOAD/UNLOAD has another problem: If some data tables were installed by some OSPM specific facilities, Linux couldn’t see them in the sysfs folder. Because we never “load” these tables as load means “interpreter AML tables”. So I'll prepare a patchset for you to try. Thanks I can reproduce this issue locally with initrd table upgrade mechanism. Created attachment 229021 [details]
[PATCH 1/5] ACPICA: Tables: Remove acpi_tb_install_fixed_table()
Created attachment 229031 [details]
[PATCH 2/5] ACPICA: Tables: Remove wrong table event macros
Created attachment 229041 [details]
[PATCH 3/5] ACPICA: Tables: Add new table events indicating table installation/uninstallation
Created attachment 229051 [details]
[PATCH 4/5] ACPI / sysfs: Fix an issue for LoadTable opcode
Created attachment 229061 [details]
[PATCH 5/5] ACPI / sysfs: Update sysfs signature handling code
The issue has been fixed. After applying PATCH 1-4, acpidump doesn't complain an error. Hope someone here can help to confirm using these patches. Thanks Patch upstreamed: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=307ecb0aa3a24528efd1cfcea8215b2d82df6e10 Closing... |
We are running into an issue in Linux with using dynamic tables and I was hoping you could help or shed some light on the issue. We are creating dynamic OEMx tables based on OS capabilities from _OSC method for CPU power management. During boot time, we patch and install these OEMx tables based on certain setup questions so that they are in ACPI memory and linked in with RSDT/XSDT. In the ASL, we will load them using LoadTable: LoadTable("OEM1", "INTEL", "CPU EIST",,,) // Dynamically load the CPUEIST table However, in Linux, it is generating a blank OEM12 file at the location: /sys/firmware/acpi/tables/dynamic/OEM12 If we use an acpidump tool to dump ACPI tables, we will get an error: /sys/firmware/acpi/tables/dynamic/OEM12 Could not get ACPI table at index 36, AE_BAD_HEADERTool's /sys/firmware/acpi/tables/OEM1 is present and functionality wise, it is working as expected. Any ideas why this table is generated with no data? Is this an issue with Linux by chance or is there a different way to program our ASL to avoid this? We have protections around the LoadTable calls to avoid loading them multiple times.