Bug 112911 - Module level code (_REG) [BUG] ODEBUG: assert_init not available (active state 0)
Summary: Module level code (_REG) [BUG] ODEBUG: assert_init not available (active stat...
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: EC (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Lv Zheng
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-23 02:12 UTC by Lv Zheng
Modified: 2016-09-27 07:17 UTC (History)
3 users (show)

See Also:
Kernel Version: v4.5-rc2
Tree: Mainline
Regression: No


Attachments
fix.patch (938 bytes, patch)
2016-03-07 16:03 UTC, Chris Bainbridge
Details | Diff
[PATCH] ACPICA / Interpreter: Fix a regression triggered because of wrong Linux ECDT support (6.37 KB, patch)
2016-03-08 08:11 UTC, Lv Zheng
Details | Diff
[PATCH 07/14] ACPICA: Events: Fix an issue that _REG association can happen before namespace is initialized (5.48 KB, patch)
2016-03-08 08:12 UTC, Lv Zheng
Details | Diff
[PATCH 08/14] ACPI 2.0 / ECDT: Split EC_FLAGS_HANDLERS_INSTALLED (5.83 KB, application/octet-stream)
2016-03-08 08:13 UTC, Lv Zheng
Details
[PATCH 09/14] ACPI 2.0 / ECDT: Remove early namespace reference from EC (11.84 KB, patch)
2016-03-08 08:13 UTC, Lv Zheng
Details | Diff
[PATCH 10/14] ACPI 2.0 / ECDT: Enable correct ECDT initialization order (2.91 KB, patch)
2016-03-08 08:14 UTC, Lv Zheng
Details | Diff
[PATCH 11/14] ACPI 2.0 / AML: Improve module level execution by moving the If/Else/While execution to per-table basis (1.36 KB, patch)
2016-03-08 08:15 UTC, Lv Zheng
Details | Diff
[PATCH] ACPICA / Interpreter: Fix a regression triggered because of wrong Linux ECDT support (6.02 KB, patch)
2016-03-08 08:46 UTC, Lv Zheng
Details | Diff
[PATCH 1/3] ACPI 2.0 / AML: Add TermList parsing support for table loading (14.83 KB, patch)
2016-03-10 03:14 UTC, Lv Zheng
Details | Diff
[PATCH 2/3] ACPI 2.0 / AML: Enable correct ACPI subsystem initialization order for new table loading mode (1.53 KB, patch)
2016-03-10 03:15 UTC, Lv Zheng
Details | Diff
[PATCH 3/3] ACPI 2.0 / AML: Fix module level execution by correctly parsing table as TermList (1.24 KB, patch)
2016-03-10 03:16 UTC, Lv Zheng
Details | Diff
[PATCH 1/3] ACPI 2.0 / AML: Add TermList parsing support for table loading (15.89 KB, patch)
2016-03-15 07:17 UTC, Lv Zheng
Details | Diff

Description Lv Zheng 2016-02-23 02:12:19 UTC
v4.5-rc2.
Macbook 2012 (IVB).

ODEBUG reports an error or two at shutdown. Apart from the ODEBUG
error(s), this bug also seems to cause some graphical corruption when
typing in Firefox text fields.


efaed9be998b5ae0afb7458e057e5f4402b43fa0 is the first bad commit
commit efaed9be998b5ae0afb7458e057e5f4402b43fa0
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Tue Dec 29 14:03:08 2015 +0800

    ACPICA: Events: Enhance acpi_ev_execute_reg_method() to ensure no _REG evaluations can happen during OS early boot stages
    
    ACPICA commit 31178590dde82368fdb0f6b0e466b6c0add96c57
    
    We can ensure no early _REG evaluations by ensuring the following rules in
    acpi_ev_execute_reg_method():
    1. If an address space handler is installed during early stage,
       _REG(CONNECT) evaluations are blocked. This is achieved using
       acpi_gbl_reg_methods_enabled which is renamed from
       acpi_gbl_reg_methods_executed.
    2. If _REG(CONNECT) has never been evalauted for the region object,
       _REG(DISCONNECT) evaluations are blocked. This is achieved by a new
       region object flag: AOPOBJ_REG_CONNECTED.
    Note that, after applying this patch, we can ensure _REG(DISCONNECT) is
    always paired to _REG(CONNECT). Lv Zheng
    
    Link: https://github.com/acpica/acpica/commit/31178590
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

:040000 040000 357c50e20ee06ad557c77a2a03d09719dae9dc52 3e0610826dc9cb86454baf06de9392aa31e0aa91 M	drivers


[   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 ]---
[   34.512830] ------------[ cut here ]------------
[   34.512833] WARNING: CPU: 0 PID: 4975 at lib/debugobjects.c:263 debug_print_object+0x85/0xa0()
[   34.512835] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: stub_timer+0x0/0x20
[   34.512836] Modules linked in:
[   34.512838] CPU: 0 PID: 4975 Comm: systemd Tainted: G        W       4.4.0-rc7+ #353
[   34.512839] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B0A.1509130955 09/13/2015
[   34.512842]  ffffffff81f9b41c ffff880227a1bdb0 ffffffff814ec829 ffff880227a1bdf8
[   34.512845]  ffff880227a1bde8 ffffffff810cd831 ffff880227a1be90 ffffffff822514c0
[   34.512847]  ffffffff81f9b4c2 ffffffff8331f388 00007f29190ba700 ffff880227a1be48
[   34.512848] Call Trace:
[   34.512850]  [<ffffffff814ec829>] dump_stack+0x4b/0x72
[   34.512853]  [<ffffffff810cd831>] warn_slowpath_common+0x81/0xc0
[   34.512855]  [<ffffffff810cd8b7>] warn_slowpath_fmt+0x47/0x50
[   34.512857]  [<ffffffff811398c2>] ? do_init_timer+0x52/0x60
[   34.512859]  [<ffffffff8150a015>] debug_print_object+0x85/0xa0
[   34.512861]  [<ffffffff81139830>] ? trace_event_raw_event_tick_stop+0x100/0x100
[   34.512864]  [<ffffffff8150ac38>] debug_object_assert_init+0xf8/0x130
[   34.512865]  [<ffffffff8111a5bd>] ? trace_hardirqs_on+0xd/0x10
[   34.512868]  [<ffffffff8113afdf>] del_timer+0x1f/0x70
[   34.512869]  [<ffffffff811c2331>] laptop_sync_completion+0x61/0x100
[   34.512871]  [<ffffffff811c22d0>] ? laptop_io_completion+0x30/0x30
[   34.512873]  [<ffffffff812569cf>] sys_sync+0x7f/0x90
[   34.512876]  [<ffffffff81b88e17>] entry_SYSCALL_64_fastpath+0x12/0x6f
[   34.512877] ---[ end trace 8fe52cbaccc47e67 ]---
Comment 1 Lv Zheng 2016-02-24 08:24:42 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
Comment 2 Lv Zheng 2016-02-24 08:40:29 UTC
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
Comment 3 Lv Zheng 2016-02-24 08:52:25 UTC
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
Comment 4 Chris Bainbridge 2016-03-07 16:03:17 UTC
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
Comment 5 Lv Zheng 2016-03-08 06:51:42 UTC
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
Comment 6 Lv Zheng 2016-03-08 07:13:28 UTC
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
Comment 7 Lv Zheng 2016-03-08 08:11:25 UTC
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.
Comment 8 Lv Zheng 2016-03-08 08:12:37 UTC
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.
Comment 9 Lv Zheng 2016-03-08 08:13:19 UTC
Created attachment 208161 [details]
[PATCH 08/14] ACPI 2.0 / ECDT: Split EC_FLAGS_HANDLERS_INSTALLED

Rebased fix from AML2.0 fix series.
Comment 10 Lv Zheng 2016-03-08 08:13:59 UTC
Created attachment 208171 [details]
[PATCH 09/14] ACPI 2.0 / ECDT: Remove early namespace reference from EC

Rebased fix from AML2.0 series.
Comment 11 Lv Zheng 2016-03-08 08:14:57 UTC
Created attachment 208181 [details]
[PATCH 10/14] ACPI 2.0 / ECDT: Enable correct ECDT initialization order

Rebased fix from AML2.0 series.
Comment 12 Lv Zheng 2016-03-08 08:15:46 UTC
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.
Comment 13 Lv Zheng 2016-03-08 08:21:09 UTC
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
Comment 14 Lv Zheng 2016-03-08 08:46:54 UTC
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.
Comment 15 Lv Zheng 2016-03-08 08:48:32 UTC
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
Comment 16 Chris Bainbridge 2016-03-09 10:37:48 UTC
> 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)
Comment 17 Chris Bainbridge 2016-03-09 10:44:07 UTC
> 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.
Comment 18 Lv Zheng 2016-03-10 02:49:14 UTC
(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
Comment 19 Lv Zheng 2016-03-10 03:14:59 UTC
Created attachment 208591 [details]
[PATCH 1/3] ACPI 2.0 / AML: Add TermList parsing support for table loading

New MLC approach.
Comment 20 Lv Zheng 2016-03-10 03:15:33 UTC
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.
Comment 21 Lv Zheng 2016-03-10 03:16:09 UTC
Created attachment 208611 [details]
[PATCH 3/3] ACPI 2.0 / AML: Fix module level execution by correctly parsing table as TermList

New MLC approach.
Comment 22 Lv Zheng 2016-03-10 03:21:45 UTC
(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.
Comment 23 Lv Zheng 2016-03-10 03:24:41 UTC
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
Comment 24 Chris Bainbridge 2016-03-11 11:15:59 UTC
> 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
Comment 25 Lv Zheng 2016-03-15 07:17:40 UTC
Created attachment 209221 [details]
[PATCH 1/3] ACPI 2.0 / AML: Add TermList parsing support for table loading

Rebase issue fixed module level support
Comment 26 Lv Zheng 2016-03-15 07:22:20 UTC
(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
Comment 27 Chris Bainbridge 2016-03-18 12:53:28 UTC
> 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.
Comment 28 Lv Zheng 2016-04-05 05:54:40 UTC
(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
Comment 29 Lv Zheng 2016-04-05 05:56:08 UTC
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

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