From: Chris Bainbridge <chris.bainbridge@gmail.com>
To: "Zheng, Lv" <lv.zheng@intel.com>
Cc: "Moore, Robert" <robert.moore@intel.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] ODEBUG: assert_init not available (active state 0)
Date: Sat, 27 Feb 2016 19:08:28 +0000 [thread overview]
Message-ID: <20160227190828.GA4751@localhost> (raw)
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E883BB4DCCD@SHSMSX101.ccr.corp.intel.com>
On Tue, Feb 23, 2016 at 02:18:22AM +0000, Zheng, Lv wrote:
>
> 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?
Yes it was a bisection result for the ODEBUG errors.
> 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.
I've checked again and the bisect result is correct. It could be that
the issue was always there, but this error is new on my system at least.
> 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.
That branch also gives the ODEBUG error.
> 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
Patch series does not apply cleanly (3 4 5 6 12 14 fail)
> Especially this one:
> http://www.spinics.net/lists/linux-acpi/msg63558.html
No change, ODEBUG error still occurs.
To sum up test results:
v4.4-rc7-48-g849c25719ac6
- ok
v4.4-rc7-49-gefaed9be998b
- odebug error
acpia-test
- odebug error
http://www.spinics.net/lists/linux-acpi/msg63550.html
- patch series does not apply cleanly (3 4 5 6 12 14 fail)
http://www.spinics.net/lists/linux-acpi/msg63558.html (patch7)
- odebug error
next prev parent reply other threads:[~2016-02-27 19:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-03 10:36 [BUG] ODEBUG: assert_init not available (active state 0) Chris Bainbridge
2016-02-05 2:52 ` Zheng, Lv
2016-02-14 10:59 ` Chris Bainbridge
2016-02-23 2:18 ` Zheng, Lv
2016-02-27 19:08 ` Chris Bainbridge [this message]
2016-03-05 15:11 ` [PATCH] ACPICA: Events: Execute some _REG methods in early boot Chris Bainbridge
2016-03-07 6:36 ` Zheng, Lv
2016-03-07 10:19 ` Chris Bainbridge
2016-03-08 0:54 ` Zheng, Lv
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160227190828.GA4751@localhost \
--to=chris.bainbridge@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).