Bug 69711
|
Description
Enrico Etxe Arte
2014-01-30 08:01:49 UTC
Please attach your acpidump: # acpidump > acpidump.txt ---------------------------------------------------------------------------
There are two mechanisms in Linux kernel to achieve a table override:
1. The physical address override: CONFIG_ACPI_INITRD_TABLE_OVERRIDE, it can
override any table via initrd, please refer to
Documentation/acpi/initrd_table_override.txt.
2. The virtual address override: CONFIG_ACPI_CUSTOM_DSDT_FILE, it can only
override DSDT, please refer to Documentation/acpi/dsdt-override.txt.
And if you want to override SSDTs, you may need to:
2.1. put all of the SSDT listed in the RSDT/XSDT into this single DSDT
file;
2.2. compile the kernel with CONFIG_ACPI_CUSTOM_DSDT_FILE pointing to
the customized DSDT file;
2.3. boot the kernel with the acpi_no_auto_ssdt parameter.
Which kind of table override mechanism are you using?
---------------------------------------------------------------------------
I used the first method via initrd for testing, and it works fine, but i dont want to use an initrd. By the second method, also if you boot with acpi_no_auto_ssdt, the auxiliary tables don't load but the primary yes like i've said in my first post. I have found the cause is in drivers/acpi/pci.c where there is a quirk for all toshiba satellite to force the load of the ssdt, since the dsdt code do not remap the ssdt, this code is executed. I have fixed it by adding an option in the Kconfig CONFIG_ACPI_CUSTOM_SSDT_INCLUDED and used it in pci.c to force loading the satellite's ssdt only if this option isn't set I have also used this option to set acpi_no_auto_ssdt by default if present, because if the ssdt is compiled within the dsdt on the kernel, this might not be an option I can post a diff if this is of interrest. Thanks This fix sounds useful, possibly you can post it here and send it to linux-acpi@vger.kernel.org. Created attachment 126381 [details]
diff on linux-3.13.1 source tree
Maybe the same thing have to be done with the initrd method for the "toshiba satellite forced copy". I have not tested. Now, i have a question about asl code, but i don't know if i can talk about it here. Created attachment 126401 [details]
diff on linux-3.13.1 source tree
Sorry, corrected a mistake
Created attachment 126531 [details]
[DBG PATCH] ACPI: Fix several issues in using CONFIG_ACPI_CUSTOM_DSDT.
IMO, you don't need to to touch ACPICA code.
This patch might be closer to the final solution.
Could you give it a try?
Created attachment 126741 [details]
[DBG PATCH] ACPI: Fix several issues in using CONFIG_ACPI_CUSTOM_DSDT.
You're right , seems to be a much proper way to do it.
I just corrected a little error on the patch line 50 where ifdef must be ifndef.
I compiled it and it works fine.
dmesg | grep SDT
[ 0.000000] SSDT auto-load disabled
[ 0.000000] ACPI: XSDT 77cfe120 000064 (v01 TOSINV TOSINV00 00000001 01000013)
[ 0.000000] ACPI: Override [DSDT-TOSINV00], this is unsafe: tainting kernel
[ 0.000000] ACPI: DSDT 77cef000 Logical table override, new table: c192f7a0
[ 0.000000] ACPI: DSDT c192f7a0 00850F (v01 TOSINV TOSINV00 00000001 INTL 20140114)
[ 0.000000] ACPI: SSDT 77cec000 000655 (v01 PmRef CpuPm 00003000 INTL 20051117)
[ 0.009009] ACPI: Ignoring SSDT at 77cec000
No forced copy of the DSDT, acpi.no_auto_ssdt enforced as expected.
Just one thing :
ls /sys/firmware/acpi/tables
APIC ASF! BOOT DSDT dynamic FACP FACS HPET MCFG SLIC SSDT
There is always a local copy of the original SSDT, i'm not sure if it can cause problems, but surely it can cause confusion.
I don't know if this can be fixed without modify the acpica code.
In drivers/acpi/acpica/tbxfload.c :
/*
* Optionally do not load any SSDTs from the RSDT/XSDT. This can
* be useful for debugging ACPI problems on some machines.
*/
if (acpi_gbl_disable_ssdt_table_load) {
ACPI_INFO((AE_INFO, "Ignoring %4.4s at %p",
acpi_gbl_root_table_list.tables[i].signature.
ascii, ACPI_CAST_PTR(void,
acpi_gbl_root_table_list.
tables[i].address)));
continue;
}
Seems to working only for dynamic ssdt's.
(In reply to Enrico Etxe Arte from comment #9) > You're right , seems to be a much proper way to do it. > I just corrected a little error on the patch line 50 where ifdef must be > ifndef. > I compiled it and it works fine. Oops! Sorry for the mistake. > Just one thing : > ls > /sys/firmware/acpi/tables > APIC ASF! BOOT DSDT dynamic FACP FACS HPET MCFG SLIC SSDT > There is always a local copy of the original SSDT, i'm not sure if it can > cause problems, but surely it can cause confusion. > I don't know if this can be fixed without modify the acpica code. This can only be fixed in ACPICA. By moving the check to acpi_tb_parse_root_table(). OK, I'll give you another patch to achieve this. Then the following line in the dmesg output should also be eliminated: > [ 0.000000] ACPI: SSDT 77cec000 000655 (v01 PmRef CpuPm 00003000 INTL > 20051117) Hi, I want to know the requirement. Do you want all SSDT loading (including those not listed in XSDT/RSDT) prohibitted if CONFIG_ACPI_SSDT_INCLUDED is enabled? If so, we'll need several patches to cleanup the code to merge the table installation code path to achieve this. Hi, For the SSDT's not listed in XSDT/RSDT, it's ok. In fact all these tables don't load with the acpi.no_auto_ssdt option When the RSDT/XSDT is parsed, the SSDT is included on the root table list. If i'm right only 1 SSDT must be listed on RSDT/XSDT. So, what i'm looking for is making this one prohibited when CONFIG_ACPI_SSDT_INCLUDED is enabled. I have looked a little for understanding what could be a simply way to achieve this. Since acpi.no_auto_ssdt is enforced when CONFIG_ACPI_SSDT_INCLUDED is enabled, /sys/firmware/acpi/tables/dynamic isn't usefull, so why don't we replace it with /sys/firmware/acpi/tables/disable (for exemple), and so instead of prohibitting the load, just load it here and disable the parsing of methods ? I know that make no sense to keep a copy of the ssdt when it's not used, but i don't know if it's a real problem and so if it's make sense rewritting all this code. When i look on the code, it seems the methods are parsed if the table appear loaded, but i experienced the p-states on the overided dsdt with ssdt included are used without problems. I'm a little confused about where goes this methods. Say me what you think about it. Thanks (In reply to Enrico Etxe Arte from comment #12) > For the SSDT's not listed in XSDT/RSDT, it's ok. > In fact all these > tables don't load with the acpi.no_auto_ssdt option But they will still be loaded by a "Load", "LoadTable" execution. In the customized DSDT, you might be able to discard such opcode. So it might be an issue that users might be worrying about. Thus this just becomes the strategy that how ACPICA disable SSDT loadings. > Since > acpi.no_auto_ssdt is enforced when CONFIG_ACPI_SSDT_INCLUDED is enabled, > /sys/firmware/acpi/tables/dynamic isn't usefull, > so why don't we replace it with > /sys/firmware/acpi/tables/disable (for exemple), > and so instead of prohibitting the load, > just load it here and disable the parsing of methods? "/sys/firmware/acpi/tables/disable" looks hackish and requires userspace tool changes. In fact I'm able to remove all SSDTs from /sys/firmware/acpi/tables when acpi.no_auto_ssdt is specified. So that the folder /sys/firmware/acpi/tables only contains the tables that Linux is currently using. So don't worry about the difficulties. :-) I just need to know if acpi.no_auto_ssdt is specified, is there any requirement that /sys/firmware/acpi/tables/dynamic should also contain no SSDTs. Please see the previous comment of my point of view on this question. > I know that make no sense to keep a copy of the ssdt when it's not used, > but i don't know if it's a real problem and so if it's make sense rewritting > all this code. As long as it could avoid issues, we may do some cleanup. > When i look on the code, it seems the methods are parsed if > the table appear loaded, but i experienced the p-states on the overided dsdt > with ssdt included are used without problems. Let me tell you what is inside of ACPICA. A table will be handled in this way: 1. acpi_initialize_tables DSDT and all tables contained in the RSDT/XSDT are "INSTALLED" during this stage. Note that this only means there is a global variable now remembers the address of these tables. The acpi.no_auto_ssdt check is not happened here, that's why you still can see the static SSDT under /sys/firmware/acpi/tables. 2. acpi_load_tables All "INSTALLED" tables will be loaded in this stage, and table is now in "LOADED" state. The DSDT/SSDT will be parsed and the namespace nodes will be "loaded" in this stage. Note that acpi.no_auto_ssdt is checked here. That's why there isn't any issue that you can use the SSDT contained in the customized DSDT. This is because the SSDT contained in RSDT/XSDT actually isn't loaded not installed. To address the problem you mentioned, I only need to move the check here to the previous step. It is easy. 3. The ACPI sysfs module will get notified that a table is "loaded" and there are many ACPICA APIs named as "load". But actually, the table notification will be sent to the sysfs module as long as the table becomes "INSTALLED" not "LOADED". So we get a little confusion here by the namings. I guess the early stage of table loading is not in the original ACPICA code, but added by Linux requirement, thus the namings are left us with confusions. I have a small patch to cleanup the function namings for ACPICA. Possibly I should include this patch for you to test so that my fix needn't be a seperate fix and the naming cleanup needn't be rebased. 4. When a "Load" or "LoadTable" opcode is executed, ACPICA avoids tables that do not contain definition blocks (SSDT/PSDT/OEMx) to be "loaded", but can install any types of tables. So you'll get them appeared in /sys/firmware/acpi/tables/dynamic. The code to load table from RSDT/XSDT and the code to load table by "Load"/"LoadTable" opcodes can be merged. So my question actually means shall I move the check to the merged table loading function or move it before invoking this merged function in the RSDT/XSDT parsing code. Well, I think you don't need to worry about it. We can properly handle this question. :-) Hi, Thanks for explanations! 1. acpi.no_auto_ssdt is not specified on kernel command line, but acpi_no_auto_ssdt_setup is executed since i select CONFIG_ACPI_CUSTOM_SSDT_INCLUDED on kernel config (due to the patch) Note independently of our CONFIG_ACPI_CUSTOM_SSDT_INCLUDED, if we can remove also the static DSDT when acpi.no_auto_ssdt is specified on command line, i think this is a good thing. Personnally i have expected this was done when i have read on the doc "don't load any SSDT". 2. I don't see any requirements that /sys/firmware/acpi/tables/dynamic shouldn't contains tables when if acpi.no_auto_ssdt is specified. Do you want to move all SSDT's in the dynamic folder when not used ? If yes, i think we just move the confusion to another place because in normal way, the tables in dynamic folder are used by linux. If "/sys/firmware/acpi/tables/disable" looks too hackish, we can use "ignored" or anything else, i don't care about it :) When you say it "requires userspace tool changes", do you mean just on drivers/acpi/sysfs.c or something more deeper? For what you said about merging the code of "Load"/"LoadTable", i think it's a good thing anyway, and so performing the acpi.no_auto_ssdt check early. For me it seems more efficient like that. For your patch fixing the naming, yes include it and i test it with pleasure. Maybe, we can fix the SSDT loading code first, making it proper and at this point, see if we want to copy the ignored tables and where? Excuse me , it wasn't clear .. With "and so performing the acpi.no_auto_ssdt check early" , i mean performing it before the merged function, so we ensure to not load anything we don't want to be loaded. Don't worry. The bug can be fixed easily. But it is easier if I can fix this based on my cleanup series. Let me post the whole stacked patches that you need. Created attachment 128061 [details]
ACPICA: Remove indent divergences to reduce the difficulties of maintaining the revised ACPICA commits.
The required divergence fix so that automatically linuxized ACPICA patches can be applied directly.
Created attachment 128071 [details]
ACPICA: Tables: Fix the issues in handling virtual addressed tables.
A trivial fix.
Created attachment 128081 [details]
ACPICA: Tables: Fix the issue that multiple ACPI_FREE()s are invoked for same pointer around acpi_tb_add_table().
A trivial fix.
Created attachment 128091 [details]
ACPICA: Tables: Cleanup split INSTALLED/VALIDATED table state logics.
The required renaming cleanup.
Created attachment 128101 [details]
ACPICA: Tables: Fix the issue that table validations are not balanced.
A trivial fix.
Created attachment 128111 [details]
ACPICA: Tables: Fix the issue that table checksums are not always verified before installation.
The useful fix, which merges the code path and makes it easier to address your requirement.
Created attachment 128121 [details]
ACPICA: Tables: Cleanup ACPI_TABLE_ORIGIN_xxx flags.
Another renaming cleanup.
Created attachment 128131 [details]
ACPICA: Tables: Avoid SSDT installation when acpi_gbl_disable_ssdt_table_load is specified.
This patch can address your requirement.
Let me post test steps after uploading all of them.
Created attachment 128141 [details]
ACPICA: Tables: Add acpi_install_table() API to be invoked by OSPM early table installation.
This is required by ACPICA community.
Let me post it here for someone else to reference.
No need to perform test on this patch.
Here is the test request: 1. Please download and checkout the git repo that this series is based on (linux-pm/linux-next branch): # git clone https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git # git checkout -b linux-next --track origin/linux-next 2. Please apply the following 10 patches: attachment 126741 [details] attachment 128061 [details] - attachment 128141 [details] 3. Build the kernel with CONFIG_ACPI_CUSTOM_SSDT_INCLUDED enabled. 4. Boot the built kernel with "acpi_no_static_ssdt" specified as boot parameter. 5. Confirm the functionality in the kernel: There should be: "ACPI: Ignoring installation ..." in the dmesg, and there wouldn't be any static SSDTs installed, thus no SSDTs will appear under /sys/firmware/tables/. You could upload dmesg and "cat /sys/firmware/acpi/tables" output here. The last step is not required to be performed, you can try it for funny. 6. You still can dump SSDTs by using the latest ACPICA AcpiDump utility (available at acpica.org). To dump !customized tables, using "sudo acpidump > acpidump-bios.txt"; To dump customized tables, using "sudo acpidump -c > acpidump-ospm.txt". You can see SSDT and not customized DSDT in the acpidump-bios.txt and no such SSDT but the customized DSDT in acpidump-ospm.txt. You could upload the 2 acpidump outputs here. Thanks. Hi, I found a mistake in attachment 128131 [details], it is not rebased on attachment 126741 [details]. I'll check and fix it. And I can help to rebase the patches on the latest mainline kernel - v3.14-rc5 which seems to be easier for you, possibly the attachment 128131 [details] is the only patch that need to be rebased. Let me check and upload later. Created attachment 128641 [details]
ACPICA: Improve support for 32/64 bit physical addresses in printf().
The first dependent ACPICA patch in 201301 release.
If you are using v3.14-rc5, you need this patch.
Created attachment 128651 [details]
ACPICA: Deploy new 32/64 printf support for table override mechanism.
The second dependent ACPICA patch in 201301 release.
If you are using v3.14-rc, you need this patch.
Created attachment 128661 [details] ACPICA: Tables: Avoid SSDT installation when acpi_gbl_disable_ssdt_table_load is specified. This patch is rebased on v3.14-rc5. If you are using v3.14-rc5, this patch should be used instead of attachment 128131 [details] which is based on ACPICA 201402 release (not merged in v3.14-rc5). Created attachment 128671 [details] ACPI: Fix the issue that auto SSDT loading is conflict with customized SSDT that is included by the customized This patch is rebased on top of the table improvements. The attachment 125631 [details] is deprecated. Created attachment 128681 [details]
ACPI: Fix the issue that the DSDT local copy is conflict with the customized DSDT.
This is split from the original fix according to maintainer's requests.
Here is the test request: 1. Please download recent Linux kernel release (v3.14-rc5): 2. Please apply the following patches: *attachment 128641 [details] *attachment 128651 [details] attachment 128061 [details] attachment 128071 [details] attachment 128081 [details] attachment 128091 [details] attachment 128101 [details] attachment 128111 [details] attachment 128121 [details] *attachment 128661 [details] attachment 128141 [details] *attachment 128671 [details] *attachment 128681 [details] Please apply using the above order. 3. Build the kernel with CONFIG_ACPI_CUSTOM_SSDT_INCLUDED enabled. 4. Boot the built kernel with "acpi_no_static_ssdt" specified as boot parameter. 5. Confirm the functionality in the kernel: There should be: "ACPI: Ignoring installation ..." in the dmesg, and there wouldn't be any static SSDTs installed, thus no SSDTs will appear under /sys/firmware/tables/. You could upload dmesg and "cat /sys/firmware/acpi/tables" output here. The last step is not required to be performed, you can try it for fun. 6. You still can dump SSDTs by using the latest ACPICA AcpiDump utility (available at acpica.org). To dump !customized tables, using "sudo acpidump > acpidump-bios.txt"; To dump customized tables, using "sudo acpidump -c > acpidump-ospm.txt". You can see SSDT and not customized DSDT in the acpidump-bios.txt and no such SSDT but the customized DSDT in acpidump-ospm.txt. You could upload the 2 acpidump outputs here. Thanks. Created attachment 129081 [details] Results of my test Hi, It seems possible that I can perform the validation myself. I did the following steps: 1. I customized DSDT with SSDT1 copied into it. 2. I booted a customized DSDt kernel with "acpi_no_auto_ssdt", then obtained acpidump & acpidump -c result, and ls /sys/firmware/acpi/tables result after booting into the shell. 3. I booted a customized DSDT kernel without "acpi_no_static_ssdt", then obtained acpidump & acpidump -c result, and ls /sys/firmware/acpi/tables result after booting into the shell. All results are compressed and uploaded in this attachment. ls -R of the extracted tarball: ./nopatch: <- test results of step 2 acpidump-bios.txt <- acpidump output acpidump-ospm.txt <- acpidump -c output static-bug.txt <- ls /sys/firmware/acpi/tables output ./patch: <- test results of step 3 acpidump-bios.txt <- acpidump output acpidump-ospm.txt <- acpidump -c output static.txt <- ls /sys/firmware/acpi/tables output dsdt.asld sdt.aml dsdt.hex: The customized DSDT mentioned in step 1 where the static SSDT is included. cust-diff.txt: diff result of patch/acpidump-bios.txt and patch/acpidump-ospm.txt bios-diff.txt: diff result of nopatch/acpidump-bios.txt and patch/acpidump-bios.txt ospm-diff.txt: diff result of nopatch/acpidump-ospm.txt and patch/acpidump-ospm.txt It shows: 1. no differences between 2 acpidump-bios.txt (bios-diff.txt): --- diff ./acpidump-bios.txt ../nopatch/acpidump-bios.txt --- 2. the static SSDT is not listed in /sys/firmware/acpi/tables even when acpi_no_static_ssdt is omitted (patch/static.txt): --- # ls /sys/firmware/acpi/tables/ APIC BOOT DSDT FACP FACS HPET MCFG OSFR SLIC TCPA TMOR dynamic --- 3. the difference of 2 acpidump-ospm.txt is exactly the static SSDT (ospm-diff.txt): --- diff ./acpidump-ospm.txt ../nopatch/acpidump-ospm.txt 1082a1083,1162 > SSDT @ 0x0000000000000000 > 0000: 53 53 44 54 DC 04 00 00 02 F1 44 45 4C 4C 20 00 SSDT......DELL . > 0010: 43 70 75 50 6D 00 00 00 00 30 00 00 49 4E 54 4C CpuPm....0..INTL > 0020: 24 06 05 20 10 45 08 5C 00 08 53 53 44 54 12 43 $.. .E.\..SSDT.C > 0030: 05 0C 0D 43 50 55 30 49 53 54 20 00 0C 1D BD 6B ...CPU0IST ....k > 0040: 7F 0C 45 02 00 00 0D 43 50 55 31 49 53 54 20 00 ..E....CPU1IST . > 0050: 0C 62 BF 6B 7F 0C D4 00 00 00 0D 43 50 55 30 43 .b.k.......CPU0C > 0060: 53 54 20 00 0C 59 B6 6B 7F 0C 3F 06 00 00 0D 43 ST ..Y.k..?....C > 0070: 50 55 31 43 53 54 20 00 0C 98 BC 6B 7F 0C 85 00 PU1CST ....k.... > 0080: 00 00 08 43 46 47 44 0C B1 6E 20 13 08 5C 50 44 ...CFGD..n ..\PD > 0090: 43 30 0C 00 00 00 80 08 5C 50 44 43 31 0C 00 00 C0......\PDC1... > 00A0: 00 80 08 5C 53 44 54 4C 0A 00 10 48 21 5C 2E 5F ...\SDTL...H!\._ > 00B0: 50 52 5F 43 50 55 30 08 48 49 30 5F 0A 00 08 48 PR_CPU0.HI0_...H > 00C0: 43 30 5F 0A 00 14 48 06 5F 50 44 43 01 8A 68 0A C0_...H._PDC..h. > 00D0: 00 52 45 56 53 8A 68 0A 04 53 49 5A 45 70 87 68 .REVS.h..SIZEp.h > 00E0: 60 70 74 60 0A 08 00 61 5B 13 68 0A 40 77 61 0A `pt`...a[.h.@wa. > 00F0: 08 00 54 45 4D 50 08 53 54 53 30 11 07 0A 04 00 ..TEMP.STS0..... > 0100: 00 00 00 73 53 54 53 30 54 45 4D 50 62 5F 4F 53 ...sSTS0TEMPb_OS > 0110: 43 11 13 0A 10 16 A6 77 40 0C 29 BE 47 9E BD D8 C......w@.).G... > 0120: 70 58 71 39 53 52 45 56 53 53 49 5A 45 62 14 44 pXq9SREVSSIZEb.D > 0130: 19 5F 4F 53 43 04 8A 6B 0A 00 53 54 53 30 8A 6B ._OSC..k..STS0.k > 0140: 0A 04 43 41 50 30 8A 68 0A 00 49 49 44 30 8A 68 ..CAP0.h..IID0.h > 0150: 0A 04 49 49 44 31 8A 68 0A 08 49 49 44 32 8A 68 ..IID1.h..IID2.h > 0160: 0A 0C 49 49 44 33 08 55 49 44 30 11 13 0A 10 16 ..IID3.UID0..... > 0170: A6 77 40 0C 29 BE 47 9E BD D8 70 58 71 39 53 8A .w@.).G...pXq9S. > 0180: 55 49 44 30 0A 00 45 49 44 30 8A 55 49 44 30 0A UID0..EID0.UID0. > 0190: 04 45 49 44 31 8A 55 49 44 30 0A 08 45 49 44 32 .EID1.UID0..EID2 > 01A0: 8A 55 49 44 30 0A 0C 45 49 44 33 A0 36 92 90 90 .UID0..EID3.6... > 01B0: 93 49 49 44 30 45 49 44 30 93 49 49 44 31 45 49 .IID0EID0.IID1EI > 01C0: 44 31 90 93 49 49 44 32 45 49 44 32 93 49 49 44 D1..IID2EID2.IID > 01D0: 33 45 49 44 33 70 0A 06 88 53 54 53 30 0A 00 00 3EID3p...STS0... > 01E0: A4 6B A0 13 92 93 69 0A 01 70 0A 0A 88 53 54 53 .k....i..p...STS > 01F0: 30 0A 00 00 A4 6B 7D 7B 50 44 43 30 0C FF FF FF 0....k}{PDC0.... > 0200: 7F 00 43 41 50 30 50 44 43 30 A0 4C 05 7B 43 46 ..CAP0PDC0.L.{CF > 0210: 47 44 0A 01 00 A0 41 05 90 90 7B 43 46 47 44 0C GD....A...{CFGD. > 0220: 00 00 00 01 00 93 7B 50 44 43 30 0A 09 00 0A 09 ......{PDC0..... > 0230: 92 7B 53 44 54 4C 0A 01 00 7D 53 44 54 4C 0A 01 .{SDTL...}SDTL.. > 0240: 53 44 54 4C 5B 80 49 53 54 30 00 83 88 53 53 44 SDTL[.IST0...SSD > 0250: 54 0A 01 00 83 88 53 53 44 54 0A 02 00 5B 20 49 T.....SSDT...[ I > 0260: 53 54 30 48 49 30 5F A0 49 05 7B 43 46 47 44 0A ST0HI0_.I.{CFGD. > 0270: F0 00 A0 4E 04 90 90 7B 43 46 47 44 0C 00 00 00 ...N...{CFGD.... > 0280: 01 00 7B 50 44 43 30 0A 18 00 92 7B 53 44 54 4C ..{PDC0....{SDTL > 0290: 0A 02 00 7D 53 44 54 4C 0A 02 53 44 54 4C 5B 80 ...}SDTL..SDTL[. > 02A0: 43 53 54 30 00 83 88 53 53 44 54 0A 07 00 83 88 CST0...SSDT..... > 02B0: 53 53 44 54 0A 08 00 5B 20 43 53 54 30 48 43 30 SSDT...[ CST0HC0 > 02C0: 5F A4 6B 10 48 21 5C 2E 5F 50 52 5F 43 50 55 31 _.k.H!\._PR_CPU1 > 02D0: 08 48 49 31 5F 0A 00 08 48 43 31 5F 0A 00 14 48 .HI1_...HC1_...H > 02E0: 06 5F 50 44 43 01 8A 68 0A 00 52 45 56 53 8A 68 ._PDC..h..REVS.h > 02F0: 0A 04 53 49 5A 45 70 87 68 60 70 74 60 0A 08 00 ..SIZEp.h`pt`... > 0300: 61 5B 13 68 0A 40 77 61 0A 08 00 54 45 4D 50 08 a[.h.@wa...TEMP. > 0310: 53 54 53 31 11 07 0A 04 00 00 00 00 73 53 54 53 STS1........sSTS > 0320: 31 54 45 4D 50 62 5F 4F 53 43 11 13 0A 10 16 A6 1TEMPb_OSC...... > 0330: 77 40 0C 29 BE 47 9E BD D8 70 58 71 39 53 52 45 w@.).G...pXq9SRE > 0340: 56 53 53 49 5A 45 62 14 44 19 5F 4F 53 43 04 8A VSSIZEb.D._OSC.. > 0350: 6B 0A 00 53 54 53 31 8A 6B 0A 04 43 41 50 31 8A k..STS1.k..CAP1. > 0360: 68 0A 00 49 49 44 30 8A 68 0A 04 49 49 44 31 8A h..IID0.h..IID1. > 0370: 68 0A 08 49 49 44 32 8A 68 0A 0C 49 49 44 33 08 h..IID2.h..IID3. > 0380: 55 49 44 31 11 13 0A 10 16 A6 77 40 0C 29 BE 47 UID1......w@.).G > 0390: 9E BD D8 70 58 71 39 53 8A 55 49 44 31 0A 00 45 ...pXq9S.UID1..E > 03A0: 49 44 30 8A 55 49 44 31 0A 04 45 49 44 31 8A 55 ID0.UID1..EID1.U > 03B0: 49 44 31 0A 08 45 49 44 32 8A 55 49 44 31 0A 0C ID1..EID2.UID1.. > 03C0: 45 49 44 33 A0 36 92 90 90 93 49 49 44 30 45 49 EID3.6....IID0EI > 03D0: 44 30 93 49 49 44 31 45 49 44 31 90 93 49 49 44 D0.IID1EID1..IID > 03E0: 32 45 49 44 32 93 49 49 44 33 45 49 44 33 70 0A 2EID2.IID3EID3p. > 03F0: 06 88 53 54 53 31 0A 00 00 A4 6B A0 13 92 93 69 ..STS1....k....i > 0400: 0A 01 70 0A 0A 88 53 54 53 31 0A 00 00 A4 6B 7D ..p...STS1....k} > 0410: 7B 50 44 43 31 0C FF FF FF 7F 00 43 41 50 31 50 {PDC1......CAP1P > 0420: 44 43 31 A0 4C 05 7B 43 46 47 44 0A 01 00 A0 41 DC1.L.{CFGD....A > 0430: 05 90 90 7B 43 46 47 44 0C 00 00 00 01 00 93 7B ...{CFGD.......{ > 0440: 50 44 43 31 0A 09 00 0A 09 92 7B 53 44 54 4C 0A PDC1......{SDTL. > 0450: 10 00 7D 53 44 54 4C 0A 10 53 44 54 4C 5B 80 49 ..}SDTL..SDTL[.I > 0460: 53 54 31 00 83 88 53 53 44 54 0A 04 00 83 88 53 ST1...SSDT.....S > 0470: 53 44 54 0A 05 00 5B 20 49 53 54 31 48 49 31 5F SDT...[ IST1HI1_ > 0480: A0 49 05 7B 43 46 47 44 0A F0 00 A0 4E 04 90 90 .I.{CFGD....N... > 0490: 7B 43 46 47 44 0C 00 00 00 01 00 7B 50 44 43 31 {CFGD......{PDC1 > 04A0: 0A 18 00 92 7B 53 44 54 4C 0A 20 00 7D 53 44 54 ....{SDTL. .}SDT > 04B0: 4C 0A 20 53 44 54 4C 5B 80 43 53 54 31 00 83 88 L. SDTL[.CST1... > 04C0: 53 53 44 54 0A 0A 00 83 88 53 53 44 54 0A 0B 00 SSDT.....SSDT... > 04D0: 5B 20 43 53 54 31 48 43 31 5F A4 6B [ CST1HC1_.k > --- So all outputs of the applied kernel are correct. I'll mark this as resolved and start to ask upstream repos to merge this series. You can re-open it if you find issues in your test environment. Shipped in v3.15. Closing. |