Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1340181 > unrolled thread
| Started by | "Zheng, Lv" <lv.zheng@intel.com> |
|---|---|
| First post | 2016-02-23 03:20 +0100 |
| Last post | 2016-02-27 20:10 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
RE: [BUG] ODEBUG: assert_init not available (active state 0) "Zheng, Lv" <lv.zheng@intel.com> - 2016-02-23 03:20 +0100
Re: [BUG] ODEBUG: assert_init not available (active state 0) Chris Bainbridge <chris.bainbridge@gmail.com> - 2016-02-27 20:10 +0100
| From | "Zheng, Lv" <lv.zheng@intel.com> |
|---|---|
| Date | 2016-02-23 03:20 +0100 |
| Subject | RE: [BUG] ODEBUG: assert_init not available (active state 0) |
| Message-ID | <r5aJX-6Z4-7@gated-at.bofh.it> |
Hi, > From: Chris Bainbridge [mailto:chris.bainbridge@gmail.com] > Subject: Re: [BUG] ODEBUG: assert_init not available (active state 0) > > On 5 February 2016 at 02:52, Zheng, Lv <lv.zheng@intel.com> 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
[toc] | [next] | [standalone]
| From | Chris Bainbridge <chris.bainbridge@gmail.com> |
|---|---|
| Date | 2016-02-27 20:10 +0100 |
| Message-ID | <r6Spz-7yF-3@gated-at.bofh.it> |
| In reply to | #1340181 |
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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web