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