RE: [BUG] ODEBUG: assert_init not available (active state 0)

[Zheng, Lv]

Hi,

> From: Chris Bainbridge [mailto:chris.bainbridge@xxxxxxxxx]
> Subject: Re: [BUG] ODEBUG: assert_init not available (active state 0)
> 
> On 5 February 2016 at 02:52, Zheng, Lv <lv.zheng@xxxxxxxxx> wrote:
> >
> > 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

Thanks and best regards
-Lv