Bug 150841 - Module level code (Lock) - sysfs is broken due to LoadTable("OEM"...)
Summary: Module level code (Lock) - sysfs is broken due to LoadTable("OEM"...)
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Lv Zheng
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-01 02:16 UTC by Lv Zheng
Modified: 2016-11-07 21:08 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.10, 4.6
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg from Fedora 24 boot (126.08 KB, text/plain)
2016-08-03 20:33 UTC, Jason Voelz
Details
Dmseg log (166.08 KB, text/plain)
2016-08-04 16:20 UTC, Francisco Leoner
Details
[PATCH 1/5] ACPICA: Tables: Remove acpi_tb_install_fixed_table() (5.63 KB, patch)
2016-08-16 08:45 UTC, Lv Zheng
Details | Diff
[PATCH 2/5] ACPICA: Tables: Remove wrong table event macros (1.61 KB, patch)
2016-08-16 08:45 UTC, Lv Zheng
Details | Diff
[PATCH 3/5] ACPICA: Tables: Add new table events indicating table installation/uninstallation (2.10 KB, patch)
2016-08-16 08:46 UTC, Lv Zheng
Details | Diff
[PATCH 4/5] ACPI / sysfs: Fix an issue for LoadTable opcode (1.97 KB, patch)
2016-08-16 08:46 UTC, Lv Zheng
Details | Diff
[PATCH 5/5] ACPI / sysfs: Update sysfs signature handling code (3.53 KB, patch)
2016-08-16 08:46 UTC, Lv Zheng
Details | Diff

Description Lv Zheng 2016-08-01 02:16:47 UTC
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.
Comment 1 Lv Zheng 2016-08-01 02:59:59 UTC
Hi, Jason (jason.voelz@intel.com)

Could you provide dmesg output (kernel boot log) using the latest upstream kernel?

Thanks
Comment 2 Jason Voelz 2016-08-03 20:33:05 UTC
Created attachment 227481 [details]
dmesg from Fedora 24 boot
Comment 3 Francisco Leoner 2016-08-04 16:20:14 UTC
Created attachment 227571 [details]
Dmseg log

Dmesg from RHEL 7.2  Kernel 3.10.0-327
Comment 4 Lv Zheng 2016-08-05 00:36:13 UTC
I think the problem is related to the acpidump.
Could you also upload acpidump -v output here?

Thanks
Lv
Comment 5 Francisco Leoner 2016-08-08 19:23:23 UTC
acpidump -v

Intel ACPI Component Architecture
ACPI Binary Table Dump Utility version 20160729-64
Copyright (c) 200 - 2016 Intel Corporation
Comment 6 Lv Zheng 2016-08-15 01:22:58 UTC
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
Comment 7 Lv Zheng 2016-08-15 09:22:47 UTC
I can reproduce this issue locally with initrd table upgrade mechanism.
Comment 8 Lv Zheng 2016-08-16 08:45:26 UTC
Created attachment 229021 [details]
[PATCH 1/5] ACPICA: Tables: Remove acpi_tb_install_fixed_table()
Comment 9 Lv Zheng 2016-08-16 08:45:46 UTC
Created attachment 229031 [details]
[PATCH 2/5] ACPICA: Tables: Remove wrong table event macros
Comment 10 Lv Zheng 2016-08-16 08:46:14 UTC
Created attachment 229041 [details]
[PATCH 3/5] ACPICA: Tables: Add new table events indicating table installation/uninstallation
Comment 11 Lv Zheng 2016-08-16 08:46:35 UTC
Created attachment 229051 [details]
[PATCH 4/5] ACPI / sysfs: Fix an issue for LoadTable opcode
Comment 12 Lv Zheng 2016-08-16 08:46:54 UTC
Created attachment 229061 [details]
[PATCH 5/5] ACPI / sysfs: Update sysfs signature handling code
Comment 13 Lv Zheng 2016-08-16 08:48:20 UTC
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

Note You need to log in before you can comment on or make changes to this bug.