[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161017181312.GA6248@htj.duckdns.org>
Date: Mon, 17 Oct 2016 14:13:12 -0400
From: Tejun Heo <tj@...nel.org>
To: Michael Ellerman <mpe@...erman.id.au>
Cc: torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
jiangshanlai@...il.com, akpm@...ux-foundation.org,
kernel-team@...com,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue
available early during boot)
Hello,
On Sat, Oct 15, 2016 at 08:48:01PM +1100, Michael Ellerman wrote:
> > Hmm... it doesn't reproduce it here and can't see how the commit would
> > affect this given that it doesn't really change when the kworker
> > kthreads are being created.
>
> Try turning on CONFIG_DEBUG_PER_CPU_MAPS=y ?
>
> That will warn if you're indexing off the end of a cpu mask and just
> getting lucky with the result.
That's not happening on x86. That could mean that powerpc is
initializing cpu_possible_mask after workqueue_init_early(). Looking
into it.
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at ../kernel/sched/core.c:1602 try_to_wake_up+0x3f4/0x5c0
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-compiler_gcc-6.2.0-next-20161014-dirty #116
> task: c000000ff9200000 task.stack: c000001ffc084000
> NIP: c0000000000f1ba4 LR: c0000000000f180c CTR: 0000000000000000
> REGS: c000001ffc0878f0 TRAP: 0700 Not tainted (4.8.0-compiler_gcc-6.2.0-next-20161014-dirty)
> MSR: 9000000002029033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 28000422 XER: 00000000
> CFAR: c0000000000f18bc SOFTE: 0
> GPR00: c0000000000f180c c000001ffc087b70 c000000000e83400 0000000000000000
> GPR04: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
> GPR08: c000000000dc3400 0000000000000001 0000000000000002 0000000000000000
> GPR12: 0000000000000000 c00000000fb80000 c00000000000e0c8 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000 c000000000eb8960
> GPR24: 0000000000000000 c000000000d8ce00 0000000000000000 0000000000000000
> GPR28: c0000007f54050f4 0000000000000000 0000000000000000 c0000007f5404900
> NIP [c0000000000f1ba4] try_to_wake_up+0x3f4/0x5c0
> LR [c0000000000f180c] try_to_wake_up+0x5c/0x5c0
> Call Trace:
> [c000001ffc087b70] [c0000000000f180c] try_to_wake_up+0x5c/0x5c0 (unreliable)
> [c000001ffc087bf0] [c0000000000d53e4] create_worker+0x144/0x250
> [c000001ffc087c90] [c000000000cf7930] workqueue_init+0x170/0x19c
> [c000001ffc087d00] [c000000000ce0e74] kernel_init_freeable+0x158/0x360
> [c000001ffc087dc0] [c00000000000e0e4] kernel_init+0x24/0x160
> [c000001ffc087e30] [c00000000000bfa0] ret_from_kernel_thread+0x5c/0xbc
> Instruction dump:
> e8790890 4bff6ed9 2fa30000 419e00dc 60000000 4bfffe54 3d02fff4 8928d7f9
> 2f890000 409e0018 39200001 9928d7f9 <0fe00000> 60000000 60420000 3b5f0368
> ---[ end trace 0000000000000000 ]---
>
> But I'm not sure that tells us anything new?
Yeah, I should have asked to print out information of the target task
but it looks like we have enough information now.
Thanks.
--
tejun
Powered by blists - more mailing lists