Bug 112911
|
Description
Lv Zheng
2016-02-23 02:12:19 UTC
From: Zheng, Lv <lv.zheng@intel.com> Just post my reply here. > From: Chris Bainbridge [mailto:chris.bainbridge@gmail.com] > > From: Zheng, Lv <lv.zheng@intel.com> > > So you could wait for just several days to test it again. > > And report here if you can still see issues. > > I didn't notice any revert last week, is there something specific that > I should test? I just noticed that there are graphical glitches in > Firefox on Youtube as well. [Lv Zheng] In fact, I don't understand what your report is. What did you mean by referring the following commit: > ACPICA: Events: Enhance acpi_ev_execute_reg_method() to ensure no _REG > evaluations can happen during OS early boot stages Was this a bisection result for an issue? And what was the issue? If the issue is the following warning messages: > [ 34.512758] ------------[ cut here ]------------ > [ 34.512765] WARNING: CPU: 0 PID: 4975 at lib/debugobjects.c:263 > debug_print_object+0x85/0xa0() > [ 34.512770] ODEBUG: assert_init not available (active state 0) object > type: > timer_list hint: stub_timer+0x0/0x20 > [ 34.512772] Modules linked in: > [ 34.512774] CPU: 0 PID: 4975 Comm: systemd Not tainted 4.4.0-rc7+ #353 > [ 34.512776] Hardware name: Apple Inc. MacBookPro10,2/Mac- > AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B0A.1509130955 09/13/2015 > [ 34.512779] ffffffff81f9b41c ffff880227a1bdb0 ffffffff814ec829 > ffff880227a1bdf8 > [ 34.512782] ffff880227a1bde8 ffffffff810cd831 ffff880227a1be90 > ffffffff822514c0 > [ 34.512785] ffffffff81f9b4c2 ffffffff8327e288 00007f29190ba700 > ffff880227a1be48 > [ 34.512786] Call Trace: > [ 34.512790] [<ffffffff814ec829>] dump_stack+0x4b/0x72 > [ 34.512793] [<ffffffff810cd831>] warn_slowpath_common+0x81/0xc0 > [ 34.512795] [<ffffffff810cd8b7>] warn_slowpath_fmt+0x47/0x50 > [ 34.512798] [<ffffffff811398c2>] ? do_init_timer+0x52/0x60 > [ 34.512800] [<ffffffff8150a015>] debug_print_object+0x85/0xa0 > [ 34.512802] [<ffffffff81139830>] ? > trace_event_raw_event_tick_stop+0x100/0x100 > [ 34.512805] [<ffffffff8150ac38>] debug_object_assert_init+0xf8/0x130 > [ 34.512807] [<ffffffff8111a5bd>] ? trace_hardirqs_on+0xd/0x10 > [ 34.512810] [<ffffffff8113afdf>] del_timer+0x1f/0x70 > [ 34.512813] [<ffffffff811c2331>] laptop_sync_completion+0x61/0x100 > [ 34.512815] [<ffffffff811c22d0>] ? laptop_io_completion+0x30/0x30 > [ 34.512819] [<ffffffff812569cf>] sys_sync+0x7f/0x90 > [ 34.512824] [<ffffffff81b88e17>] entry_SYSCALL_64_fastpath+0x12/0x6f > [ 34.512825] ---[ end trace 8fe52cbaccc47e66 ]--- Our investigation result shows this is caused by a multiple deletion on the same Linux kernel timer. And the commit you reported shouldn't be the culprit. So it looks to me like a wrong bisection result if it was a bisection result. While the following commit may trigger such breakage: > ACPICA: Parser: Fix for SuperName method invocation So I think you need to test again after reverting this patch. The patch is actually reverted in ACPICA 20160212 release. You can use the following branch where ACPICA 20160212 release is applied: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/?h=acpica-test test it again to confirm if such breakage still can be seen. If the issue is some graphical glitches. As I said, the commit is just a part of whole series that try to make Linux ACPICA initialization sequences correctly ordered. It, along with other patches try to make Linux working as spec compliant (also proven by Windows behavior). So you really need to apply more patches on top of acpica-test branch to confirm again. For example, patches from this series: http://www.spinics.net/lists/linux-acpi/msg63550.html Especially this one: http://www.spinics.net/lists/linux-acpi/msg63558.html There are simply so many issues fixed by the series. The series contains many reversions reverting old wrong fixes, and fixes those issues using different approaches that can be spec compliant. The wrong fixes are proven to be wrong, but they've been there for so many years, making Linux working on those old platforms. Thus without fixing them all together, we may see regressions. And it is likely that there are still cases not covered by this series. Thus we may need your test support to learn the new cases. Probably also need graphic developers' help to root cause your issue. Let me just file a kernel Bugzilla bug, so that we can communicate there to do more investigation. https://bugzilla.kernel.org/show_bug.cgi?id=112911 The commit in question: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=efaed9b may look wrong because it doesn't reset AOPOBJ_REG_CONNECTED when a region handler is uninstalled. But this the current ACPICA behavior. So this is an existing issue. Let me clarify: ACPICA only invokes _REG(DISCONNECT) when a region object is freed (whose reference count drops to 0). So we can see "no handler" error messages after Linux uninstalls a region handler. BIOS tables are not notified by ACPICA of the _REG(DISCONNECT). Thus region accesses can still be triggered from ACPI table and result such an error. There are only 2 cases a region object will be deleted: 1. When the owner table is unloaded. Unfortunately, ACPICA doesn't support table unloading, so this is a dead case. 2. When the evaluation of a control method that creates the region object is ended. Then it looks we needn't worry about this case, because the region object is deleted and when the control method is evaluated again, it will be created again with AOPOBJ_REG_CONNECTED unset. So there won't be anything working differently from the existing code. What I was really worrying about is: If _REG(CONNECT) is invoked too early (for example, before the namespace is fully loaded), and the _REG method node is not found for this region object just because this process happens too early, then the handler driver surely need the whole process to happen again after the namespace is loaded. This is a known issue (but is also an existing issue) and only can be triggered by early opregion handlers (for which, it is possible to access during the table loading). And among the early opregion handlers, EC opregion handler is the only one that need us to worry about. While this case is fixed by this patch: http://www.spinics.net/lists/linux-acpi/msg63558.html So I don't think this commit is wrong. What may cause reviewers to think it is wrong are all existing issues. You really need to confirm it again by running on top of the new release series. Thanks and best regards -Lv Sorry, let me correct: The following statement is wrong: The commit in question may look wrong because it doesn't reset AOPOBJ_REG_CONNECTED when a region handler is uninstalled. When region handler is uninstalled, AcpiEvDetachRegion() will be invoked, and AOPOBJ_REG_CONNECTED will be reset after the _REG(DISCONNECT) evaluation. So no worry here. Thanks and best regards -Lv Created attachment 207931 [details] fix.patch With this patch applied the ODEBUG errors do not occur. Relevant thread at https://lkml.org/lkml/2016/3/7/197 IMO, we haven't reached to the real fix. The fix suggested by me only tries to stop the regression. We still need the logic: acpi_gbl_reg_methods_enabled = TRUE; set after acpi_ns_initialize_objects(). Let me just paste what you found here first: The regression caused _REG methods to not be run in early boot for all space IDs, but a removed comment stated that _REG methods should be executed for IDs like embedded_controller. Before the regression this was the case: [ 0.230469] Executing Method \_SB.PCI0.LPCB.EC._REG [ 0.230531] Initializing Region \GNVS [ 0.230607] Initializing Region \_SB.PCI0.LPCB.EC.ECOR [ 0.231043] Initializing Region \_SB.PCI0.IGPU.IGDM After the regression the initialisation is not done and ODEBUG warnings are shown at boot and/or shutdown: [ 6.676570] WARNING: CPU: 0 PID: 3317 at lib/debugobjects.c:263 debug_print_object+0x85/0xa0() [ 6.676576] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: stub_timer+0x0/0x20 [ 6.676578] Modules linked in: [ 6.676582] CPU: 0 PID: 3317 Comm: ccpd Not tainted 4.5.0-rc6 #509 [ 6.676584] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B0A.1509130955 09/13/2015 [ 6.676586] 0000000000000000 ffff880256543db0 ffffffff814802b5 ffff880256543df8 [ 6.676590] ffffffff81f40dbd ffff880256543de8 ffffffff810bd0ec ffff880256543e90 [ 6.676594] ffffffff822532c0 ffffffff81f40e63 ffffffff83138c88 0000000001fdf040 [ 6.676598] Call Trace: [ 6.676603] [<ffffffff814802b5>] dump_stack+0x67/0x92 [ 6.676608] [<ffffffff810bd0ec>] warn_slowpath_common+0x7c/0xb0 [ 6.676611] [<ffffffff810bd167>] warn_slowpath_fmt+0x47/0x50 [ 6.676614] [<ffffffff8149d7a5>] debug_print_object+0x85/0xa0 [ 6.676616] [<ffffffff8111f440>] ? cascade+0x70/0x70 [ 6.676620] [<ffffffff8149e398>] debug_object_assert_init+0xf8/0x130 [ 6.676624] [<ffffffff811038cd>] ? trace_hardirqs_on+0xd/0x10 [ 6.676626] [<ffffffff8111fcff>] del_timer+0x1f/0x70 [ 6.676631] [<ffffffff811852f1>] laptop_sync_completion+0x61/0x100 [ 6.676633] [<ffffffff81185290>] ? laptop_io_completion+0x30/0x30 [ 6.676637] [<ffffffff81212c9f>] sys_sync+0x7f/0x90 [ 6.676641] [<ffffffff81ad0d97>] entry_SYSCALL_64_fastpath+0x12/0x6f Thanks -Lv The problem we know is: The commit in question doesn't match the current kernel ECDT probing order. It also blocks EC._REG execution invoked in ECDT probing. And currently, there is no chance for the kernel to re-execute EC._REG. But this is intended. According to the spec, on ECDT platforms, EC._REG is not required to be executed before accessing the EC opregion fields. In the whole fix series, this problem is covered. When EC probing happens, EC region handler will be installed without executing _REG. After namespace is fully initialized, EC region handler will be removed and re-installed again using namespace EC, this time _REG will be executed. Thus the problem we know is about the _REG execution and since it is fixed in the whole series, I suggested you to try the whole fix series. ===== But I'm not clear about what has been caused on your platform if the order is not matched because I don't know what the "Initializing Region" is. [ 0.230469] Executing Method \_SB.PCI0.LPCB.EC._REG [ 0.230531] Initializing Region \GNVS [ 0.230607] Initializing Region \_SB.PCI0.LPCB.EC.ECOR [ 0.231043] Initializing Region \_SB.PCI0.IGPU.IGDM Could you tell me what function was executed for ’Initializing Region", or paste your debugging patch here? So that I can know if there is something I don't know. ===== If there is nothing beyond what I know, then a better regression stopper fix could apply (I'll post it later). Which ensures "acpi_gbl_reg_methods_enabled = TRUE" executed after acpi_ns_initialize_objects(). This is what we want to ensure. If it can work, we'd better to have this upstreamed instead of the simple fix. Thanks in advance -Lv Created attachment 208141 [details]
[PATCH] ACPICA / Interpreter: Fix a regression triggered because of wrong Linux ECDT support
This is the fix I'm going to send it to the upstream.
It includes the regression fix.
But I need your confirmation if the rest of the stuff (will be enabled after fixing ECDT order) is correct.
I'll describe the test steps later.
Created attachment 208151 [details]
[PATCH 07/14] ACPICA: Events: Fix an issue that _REG association can happen before namespace is initialized
Rebased fix from the AML2.0 fixing series.
Created attachment 208161 [details]
[PATCH 08/14] ACPI 2.0 / ECDT: Split EC_FLAGS_HANDLERS_INSTALLED
Rebased fix from AML2.0 fix series.
Created attachment 208171 [details]
[PATCH 09/14] ACPI 2.0 / ECDT: Remove early namespace reference from EC
Rebased fix from AML2.0 series.
Created attachment 208181 [details]
[PATCH 10/14] ACPI 2.0 / ECDT: Enable correct ECDT initialization order
Rebased fix from AML2.0 series.
Created attachment 208191 [details]
[PATCH 11/14] ACPI 2.0 / AML: Improve module level execution by moving the If/Else/While execution to per-table basis
Rebased fix from AML2.0 series.
Here is the test request: 1. Please download the linux-next branch of linux-pm.git: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/?h=linux-next 2. Please apply the following patch and try to see if the problem still exists: attachment 208141 [details] According to comment 4, you have tested this to be working. 3. Please apply the following patches and try to see if the problem still exists: attachment 208141 [details] attachment 208151 [details] attachment 208161 [details] attachment 208171 [details] attachment 208181 [details] attachment 208191 [details] This is what I need you to confirm, I need to make sure what I added in the fix patch can still work after fixing the ECDT order issue. Thanks and best regards -Lv Created attachment 208201 [details]
[PATCH] ACPICA / Interpreter: Fix a regression triggered because of wrong Linux ECDT support
Sorry for making a mistake in the previous version.
“
This is the fix I'm going to send it to the upstream.
It includes the regression fix.
But I need your confirmation if the rest of the stuff (will be enabled after fixing ECDT order) is correct.
”
I'll update the test request later.
Here is the test request: 1. Please download the linux-next branch of linux-pm.git: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/?h=linux-next 2. Please apply the following patch and try to see if the problem still exists: attachment 208201 [details] According to comment 4, you have confirmed this to be working. 3. Please apply the following patches and try to see if the problem still exists: attachment 208201 [details] attachment 208151 [details] attachment 208161 [details] attachment 208171 [details] attachment 208181 [details] attachment 208191 [details] This is what I need you to confirm, I need to make sure what I added in the fix patch can still work after fixing the ECDT order issue. Thanks and best regards -Lv > But I'm not clear about what has been caused on your platform if the order is
> not matched because I don't know what the "Initializing Region" is.
> [ 0.230469] Executing Method \_SB.PCI0.LPCB.EC._REG
> [ 0.230531] Initializing Region \GNVS
> [ 0.230607] Initializing Region \_SB.PCI0.LPCB.EC.ECOR
> [ 0.231043] Initializing Region \_SB.PCI0.IGPU.IGDM
> Could you tell me what function was executed for ’Initializing Region", or
> paste your debugging patch here? So that I can know if there is something I
> don't know.
This is just the output when kernel parameter acpi.debug_level=0x20 is
set (the actual print is done by function acpi_ut_display_init_pathname)
> 2. Please apply the following patch and try to see if the problem still > exists: > attachment 208201 [details] > According to comment 4, you have confirmed this to be working. Yes that works. No ODEBUG errors with that patch applied. > 3. Please apply the following patches and try to see if the problem still > exists: > attachment 208201 [details] > attachment 208151 [details] > attachment 208161 [details] > attachment 208171 [details] > attachment 208181 [details] > attachment 208191 [details] > This is what I need you to confirm, I need to make sure what I added in the > fix > patch can still work after fixing the ECDT order issue. This works. No ODEBUG errors and dmesg shows _REG being executed: [ 0.309299] ACPI : EC: EC stopped [ 0.309564] ACPI : EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62 [ 0.309570] ACPI : EC: EC started [ 0.309654] Executing Method \_SB.PCI0.LPCB.EC._REG So patch looks good. Please let me know if there's any other information you need. (In reply to Chris Bainbridge from comment #17) > > 2. Please apply the following patch and try to see if the problem still > exists: > > attachment 208201 [details] > > According to comment 4, you have confirmed this to be working. > > Yes that works. No ODEBUG errors with that patch applied. > > > 3. Please apply the following patches and try to see if the problem still > > exists: > > attachment 208201 [details] > > attachment 208151 [details] > > attachment 208161 [details] > > attachment 208171 [details] > > attachment 208181 [details] > > attachment 208191 [details] > > This is what I need you to confirm, I need to make sure what I added in the > fix > > patch can still work after fixing the ECDT order issue. > > This works. No ODEBUG errors and dmesg shows _REG being executed: > > [ 0.309299] ACPI : EC: EC stopped ECDT EC (early EC) is unregistered here. > [ 0.309564] ACPI : EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62 > [ 0.309570] ACPI : EC: EC started DSDT EC (late EC) is re-registered here. > [ 0.309654] Executing Method \_SB.PCI0.LPCB.EC._REG And _REG can be executed after applying the whole series. Good indications! > > So patch looks good. OK, thanks for the confirmation. I'll send the regression fix to the community. > Please let me know if there's any other information > you need. Yes, I have another test need your help. I'll post patches here later after sending out the fix. Thanks and best regards -Lv Created attachment 208591 [details]
[PATCH 1/3] ACPI 2.0 / AML: Add TermList parsing support for table loading
New MLC approach.
Created attachment 208601 [details]
[PATCH 2/3] ACPI 2.0 / AML: Enable correct ACPI subsystem initialization order for new table loading mode
New MLC approach.
Created attachment 208611 [details]
[PATCH 3/3] ACPI 2.0 / AML: Fix module level execution by correctly parsing table as TermList
New MLC approach.
(In reply to Chris Bainbridge from comment #16) > > But I'm not clear about what has been caused on your platform if the order > is > > not matched because I don't know what the "Initializing Region" is. > > Could you tell me what function was executed for ’Initializing Region", or > > paste your debugging patch here? So that I can know if there is something I > > don't know. > > This is just the output when kernel parameter acpi.debug_level=0x20 is > set (the actual print is done by function acpi_ut_display_init_pathname) So after applying the whole series, you may see the following order: Initializing Region \GNVS Initializing Region \_SB.PCI0.LPCB.EC.ECOR Initializing Region \_SB.PCI0.IGPU.IGDM Executing Method \_SB.PCI0.LPCB.EC._REG This is the preferred order, and I'm working on fixing this. Could you help to confirm if it is correct after applying the whole series. Here is the last test request: 1. Please download the linux-next branch of linux-pm.git: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/?h=linux-next 2. Please apply the following patches and try to see if the problem still exists: attachment 208201 [details] attachment 208151 [details] attachment 208161 [details] attachment 208171 [details] attachment 208181 [details] attachment 208191 [details] attachment 208591 [details] attachment 208601 [details] attachment 208611 [details] Please help to confirm if anything wrong with the addtional 3 patches applied. Please also tell me the acpi_ut_display_init_pathname() order for this test. Thanks and best regards -Lv > attachment 208611 [details]
After this patch (ACPI 2.0 / AML: Fix
module level execution by correctly parsing table as TermList) is
applied all of the "Initializing Region" lines are missing.
Before:
[ 0.000000] ACPI: ECDT 0x0000000088D87000 000053 (v01 APPLE Apple00 00000001 Loki 0000005F)
[ 0.201717] ACPI : EC: EC description table is found, configuring boot EC
[ 0.201729] ACPI : EC: EC started
[ 0.234444] Initializing Region \_PR.PPMT
[ 0.237741] Initializing Region \_SB.PCI0.HBUS
[ 0.237786] Initializing Region \_SB.PCI0.MCHT
[ 0.237867] Initializing Region \_SB.PCI0.PEG1.A1E0
[ 0.237896] Initializing Region \_SB.PCI0.PEG1.A1E1
[ 0.237926] Initializing Region \_SB.PCI0.PEG1.A1E2
[ 0.237951] Initializing Region \_SB.PCI0.PEG1.A1E3
[ 0.237975] Initializing Region \_SB.PCI0.PEG1.C38H
[ 0.238001] Initializing Region \_SB.PCI0.PEG1.C20H
[ 0.238028] Initializing Region \_SB.PCI0.PEG1.UPSB.A1E0
[ 0.238057] Initializing Region \_SB.PCI0.PEG1.UPSB.A1E1
[ 0.238085] Initializing Region \_SB.PCI0.PEG1.UPSB.A1E2
[ 0.238113] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB0.A1E0
[ 0.238142] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB0.A1E1
[ 0.238169] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB0.A1E2
[ 0.238213] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB0.NHI0.A1E0
[ 0.238251] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.A1E0
[ 0.238283] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.ARE0
[ 0.238310] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB0.A1E0
[ 0.238345] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB3.A1E0
[ 0.238377] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB3.UPS0.ARE0
[ 0.238406] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB3.UPS0.DSB0.A1E0
[ 0.238443] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB3.UPS0.DSB3.A1E0
[ 0.238480] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB3.UPS0.DSB4.A1E0
[ 0.238517] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB3.UPS0.DSB5.A1E0
[ 0.238551] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB3.UPS0.DSB6.A1E0
[ 0.238587] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB4.A1E0
[ 0.238623] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB4.UPS0.ARE0
[ 0.238658] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB4.UPS0.DSB0.A1E0
[ 0.238695] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB4.UPS0.DSB3.A1E0
[ 0.238732] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB4.UPS0.DSB4.A1E0
[ 0.238770] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB4.UPS0.DSB5.A1E0
[ 0.238804] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB4.UPS0.DSB6.A1E0
[ 0.238839] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB5.A1E0
[ 0.238872] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB1.UPS0.DSB6.A1E0
[ 0.238905] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.A1E0
[ 0.238937] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.ARE0
[ 0.238964] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB0.A1E0
[ 0.239000] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB3.A1E0
[ 0.239032] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB3.UPS0.ARE0
[ 0.239061] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB3.UPS0.DSB0.A1E0
[ 0.239097] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB3.UPS0.DSB3.A1E0
[ 0.239134] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB3.UPS0.DSB4.A1E0
[ 0.239171] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB3.UPS0.DSB5.A1E0
[ 0.239206] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB3.UPS0.DSB6.A1E0
[ 0.239241] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB4.A1E0
[ 0.239273] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB4.UPS0.ARE0
[ 0.239302] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB4.UPS0.DSB0.A1E0
[ 0.239339] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB4.UPS0.DSB3.A1E0
[ 0.239376] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB4.UPS0.DSB4.A1E0
[ 0.239413] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB4.UPS0.DSB5.A1E0
[ 0.239447] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB4.UPS0.DSB6.A1E0
[ 0.239482] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB5.A1E0
[ 0.239514] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB2.UPS0.DSB6.A1E0
[ 0.239548] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB3.A1E0
[ 0.239580] Initializing Region \_SB.PCI0.PEG1.UPSB.DSB4.A1E0
[ 0.239633] Initializing Region \_SB.PCI0.IGPU.GFXH
[ 0.239696] Initializing Region \_SB.PCI0.IGPU.IGDP
[ 0.239727] Initializing Region \_SB.PCI0.IGPU.IGDM
[ 0.239753] Initializing Region \GNVS
[ 0.239991] Initializing Region \_SB.PCI0.SBUS.SMBP
[ 0.240017] Initializing Region \_SB.PCI0.SBUS.SMPB
[ 0.240042] Initializing Region \_SB.PCI0.SBUS.SMBI
[ 0.242003] Initializing Region \_SB.PCI0.LPCB.LPC1
[ 0.242028] Initializing Region \_SB.PCI0.LPCB.LPC0
[ 0.242382] Initializing Region \_SB.PCI0.LPCB.EC.ECOR
[ 0.242494] Initializing Region \_SB.PCI0.HDEF.HDAR
[ 0.242526] Initializing Region \_SB.PCI0.RP01.A1E0
[ 0.242563] Initializing Region \_SB.PCI0.RP01.SDXC.ARE1
[ 0.242595] Initializing Region \_SB.PCI0.RP02.A1E0
[ 0.242638] Initializing Region \_SB.PCI0.RP02.ARPT.ARE2
[ 0.243529] Initializing Region \_SB.PCI0.XHC1.XH1C
[ 0.243559] Initializing Region \_SB.PCI0.XHC1.XHC2
[ 0.243875] Initializing Region \_SB.PCI0.MCHP
[ 0.244382] Initializing Region \PRT0
[ 0.244407] Initializing Region \PLMT
[ 0.244436] Initializing Region \SPRT
[ 0.244466] Initializing Region \IO_T
[ 0.244491] Initializing Region \IO_D
[ 0.244516] Initializing Region \IO_H
[ 0.244541] Initializing Region \PMIO
[ 0.244574] Initializing Region \GPIO
[ 0.244677] Initializing Region \RCRB
[ 0.250763] Executing Method \_SB._STA
[ 0.250773] Executing Method \_SB._INI
[ 0.250904] Executing Method \_SB.PCI0._STA
[ 0.250914] Executing Method \_SB.PCI0._INI
[ 0.251067] Executing Method \_SB.PCI0.XHC1._STA
[ 0.251076] Executing Method \_SB.PCI0.XHC1._INI
[ 0.311848] ACPI : EC: EC stopped
[ 0.312125] ACPI : EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
[ 0.312131] ACPI : EC: EC started
[ 0.312216] Executing Method \_SB.PCI0.LPCB.EC._REG
[ 0.407484] ACPI: SBS HC: EC = 0xffff880260b24800, offset = 0x20, query_bit = 0x10
After:
[ 0.000000] ACPI: ECDT 0x0000000088D87000 000053 (v01 APPLE Apple00 00000001 Loki 0000005F)
[ 0.204426] ACPI : EC: EC description table is found, configuring boot EC
[ 0.204438] ACPI : EC: EC started
[ 0.242853] Executing Method \_SB._STA
[ 0.242864] Executing Method \_SB._INI
[ 0.242998] Executing Method \_SB.PCI0._STA
[ 0.243008] Executing Method \_SB.PCI0._INI
[ 0.243163] Executing Method \_SB.PCI0.XHC1._STA
[ 0.243171] Executing Method \_SB.PCI0.XHC1._INI
[ 0.301474] ACPI : EC: EC stopped
[ 0.301768] ACPI : EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
[ 0.301775] ACPI : EC: EC started
[ 0.301859] Executing Method \_SB.PCI0.LPCB.EC._REG
[ 0.397768] ACPI: SBS HC: EC = 0xffff88026099c800, offset = 0x20, query_bit = 0x10
Created attachment 209221 [details]
[PATCH 1/3] ACPI 2.0 / AML: Add TermList parsing support for table loading
Rebase issue fixed module level support
(In reply to Chris Bainbridge from comment #24) > > attachment 208611 [details] > > After this patch (ACPI 2.0 / AML: Fix > module level execution by correctly parsing table as TermList) is > applied all of the "Initializing Region" lines are missing. Sounds like a wrong rebase result of attachment 208591 [details]. As we changed the region initialization code in the regression fix (attachment 208201 [details])... It's hard to say if this is a problem because all object initialization code will be invoked again before the object is accessed. But anyway, this is too aggressive to have this cleanup done in this patch. So I rebased attachment 208591 [details] to attachment 209221 [details] And here is the refreshed test request: 1. Please download the linux-next branch of linux-pm.git: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/?h=linux-next 2. Please apply the following patches and try to see if the problem still exists: attachment 208201 [details] attachment 208151 [details] attachment 208161 [details] attachment 208171 [details] attachment 208181 [details] attachment 208191 [details] attachment 208591 [details] -> attachment 209221 [details] attachment 208601 [details] attachment 208611 [details] Please help to confirm if anything wrong with the addtional 3 patches applied. Please also tell me the acpi_ut_display_init_pathname() order for this test. > > Before: > > [ 0.000000] ACPI: ECDT 0x0000000088D87000 000053 (v01 APPLE Apple00 > 00000001 Loki 0000005F) > [ 0.201717] ACPI : EC: EC description table is found, configuring boot EC > [ 0.201729] ACPI : EC: EC started > [ 0.234444] Initializing Region \_PR.PPMT ... > [ 0.244677] Initializing Region \RCRB > [ 0.250763] Executing Method \_SB._STA > [ 0.250773] Executing Method \_SB._INI > [ 0.250904] Executing Method \_SB.PCI0._STA > [ 0.250914] Executing Method \_SB.PCI0._INI > [ 0.251067] Executing Method \_SB.PCI0.XHC1._STA > [ 0.251076] Executing Method \_SB.PCI0.XHC1._INI > [ 0.311848] ACPI : EC: EC stopped > [ 0.312125] ACPI : EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62 > [ 0.312131] ACPI : EC: EC started > [ 0.312216] Executing Method \_SB.PCI0.LPCB.EC._REG > [ 0.407484] ACPI: SBS HC: EC = 0xffff880260b24800, offset = 0x20, > query_bit = 0x10 Good indications. > > After: > > [ 0.000000] ACPI: ECDT 0x0000000088D87000 000053 (v01 APPLE Apple00 > 00000001 Loki 0000005F) > [ 0.204426] ACPI : EC: EC description table is found, configuring boot EC > [ 0.204438] ACPI : EC: EC started > [ 0.242853] Executing Method \_SB._STA > [ 0.242864] Executing Method \_SB._INI > [ 0.242998] Executing Method \_SB.PCI0._STA > [ 0.243008] Executing Method \_SB.PCI0._INI > [ 0.243163] Executing Method \_SB.PCI0.XHC1._STA > [ 0.243171] Executing Method \_SB.PCI0.XHC1._INI > [ 0.301474] ACPI : EC: EC stopped > [ 0.301768] ACPI : EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62 > [ 0.301775] ACPI : EC: EC started > [ 0.301859] Executing Method \_SB.PCI0.LPCB.EC._REG > [ 0.397768] ACPI: SBS HC: EC = 0xffff88026099c800, offset = 0x20, > query_bit = 0x10 As I said above, the region initialization can be done in a different place. Can you see strange things happening there without this object initialization step executed? For example, still suffer from the ODEBUG issue? Thanks -Lv > 1. Please download the linux-next branch of linux-pm.git: > > https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/?h=linux-next > > 2. Please apply the following patches and try to see if the problem still > exists: > attachment 208201 [details] > attachment 208151 [details] > attachment 208161 [details] > attachment 208171 [details] > attachment 208181 [details] > attachment 208191 [details] > attachment 208591 [details] -> attachment 209221 [details] > attachment 208601 [details] > attachment 208611 [details] > Please help to confirm if anything wrong with the addtional 3 patches > applied. > Please also tell me the acpi_ut_display_init_pathname() order for this test. 208201 is already in linux-next I merged 208151 208161 208171 208181 208191 209221 208601 208611 After that there is no change - the Region and BufferField initialization are still missing. > > After: > > > > [ 0.000000] ACPI: ECDT 0x0000000088D87000 000053 (v01 APPLE Apple00 > > 00000001 Loki 0000005F) > > [ 0.204426] ACPI : EC: EC description table is found, configuring boot > EC > > [ 0.204438] ACPI : EC: EC started > > [ 0.242853] Executing Method \_SB._STA > > [ 0.242864] Executing Method \_SB._INI > > [ 0.242998] Executing Method \_SB.PCI0._STA > > [ 0.243008] Executing Method \_SB.PCI0._INI > > [ 0.243163] Executing Method \_SB.PCI0.XHC1._STA > > [ 0.243171] Executing Method \_SB.PCI0.XHC1._INI > > [ 0.301474] ACPI : EC: EC stopped > > [ 0.301768] ACPI : EC: GPE = 0x17, I/O: command/status = 0x66, data = > 0x62 > > [ 0.301775] ACPI : EC: EC started > > [ 0.301859] Executing Method \_SB.PCI0.LPCB.EC._REG > > [ 0.397768] ACPI: SBS HC: EC = 0xffff88026099c800, offset = 0x20, > > query_bit = 0x10 > > As I said above, the region initialization can be done in a different place. > Can you see strange things happening there without this object initialization > step executed? > For example, still suffer from the ODEBUG issue? The Region and BufferField initialization never appears to happen (there is nothing in dmesg). Apart from that, I haven't noticed any problems and the ODEBUG issue is fixed. (In reply to Chris Bainbridge from comment #27) > > 1. Please download the linux-next branch of linux-pm.git: > > > https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/?h=linux-next > > > > 2. Please apply the following patches and try to see if the problem still > > exists: > > attachment 208201 [details] > > attachment 208151 [details] > > attachment 208161 [details] > > attachment 208171 [details] > > attachment 208181 [details] > > attachment 208191 [details] > > attachment 208591 [details] -> attachment 209221 [details] > > attachment 208601 [details] > > attachment 208611 [details] > > Please help to confirm if anything wrong with the addtional 3 patches > applied. > > Please also tell me the acpi_ut_display_init_pathname() order for this > test. > > 208201 is already in linux-next > > I merged 208151 208161 208171 208181 208191 209221 208601 208611 > > After that there is no change - the Region and BufferField > initialization are still missing. > OK, all above patches are sent to the community. > > > After: > > > > > > [ 0.000000] ACPI: ECDT 0x0000000088D87000 000053 (v01 APPLE Apple00 > > > 00000001 Loki 0000005F) > > > [ 0.204426] ACPI : EC: EC description table is found, configuring boot > EC > > > [ 0.204438] ACPI : EC: EC started > > > [ 0.242853] Executing Method \_SB._STA > > > [ 0.242864] Executing Method \_SB._INI > > > [ 0.242998] Executing Method \_SB.PCI0._STA > > > [ 0.243008] Executing Method \_SB.PCI0._INI > > > [ 0.243163] Executing Method \_SB.PCI0.XHC1._STA > > > [ 0.243171] Executing Method \_SB.PCI0.XHC1._INI > > > [ 0.301474] ACPI : EC: EC stopped > > > [ 0.301768] ACPI : EC: GPE = 0x17, I/O: command/status = 0x66, data = > 0x62 > > > [ 0.301775] ACPI : EC: EC started > > > [ 0.301859] Executing Method \_SB.PCI0.LPCB.EC._REG > > > [ 0.397768] ACPI: SBS HC: EC = 0xffff88026099c800, offset = 0x20, > > > query_bit = 0x10 > > > > As I said above, the region initialization can be done in a different > place. > > Can you see strange things happening there without this object > initialization > > step executed? > > For example, still suffer from the ODEBUG issue? > > The Region and BufferField initialization never appears to happen (there > is nothing in dmesg). Apart from that, I haven't noticed any problems > and the ODEBUG issue is fixed. It seems I can confirm this locally to improve the last fix. So thanks for your help, let me close the bug. Thanks -Lv Closing as the regression fix has been already upstreamed: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5508df89 Thanks -Lv |