panic: ttwu_activate() e500mc: 3.13.9.

[Scott Wood]

On Fri, 2014-05-23 at 14:22 -0500, John Donnelly wrote:
> The failing code snippet :
> 
> void ttwu_activate(struct rq *rq, struct task_struct *p, int en_flags)
> {
> c0088b90:       7c 08 02 a6     mflr    r0
> c0088b94:       90 01 00 04     stw     r0,4(r1)
> c0088b98:       4b f8 87 29     bl      c00112c0 <_mcount>
> c0088b9c:       94 21 ff f0     stwu    r1,-16(r1)
> c0088ba0:       7c 08 02 a6     mflr    r0
> c0088ba4:       90 01 00 14     stw     r0,20(r1)
> c0088ba8:       bf c1 00 08     stmw    r30,8(r1)
> c0088bac:       7c 9f 23 78     mr      r31,r4
> c0088bb0:       7c 7e 1b 78     mr      r30,r3
>         activate_task(rq, p, en_flags);
> c0088bb4:       4b ff f5 2d     bl      c00880e0 <activate_task>
>         p->on_rq = 1;
> 
>         /* if a worker is waking up, notify workqueue */
>         if (p->flags & PF_WQ_WORKER)
> c0088bb8:       81 3f 00 0c     lwz     r9,12(r31)
> 
> r31- looks valid ( 0xc0b0b340)

r31 isn't relevant -- it didn't fault on that lwz, but rather on a
branch to NULL, via CTR.  The branch to NULL could have been either
inside activate_task or after returning from activate_task.  Since LR
doesn't point to the instruction after a bctrl, that means it was a
non-linking bctr.  I believe it's the one at the end of enqueue_task()
that is responsible.

https://lkml.org/lkml/2011/9/19/331 suggests that a NULL enqueue_task
may be the result of the idle thread attempting to block.  Did you have
CONFIG_DEBUG_ATOMIC_SLEEP enabled?

> Entering kdb (current=0xe62b8000, pid 74) on processor 1 Oops: (null)
> due to oops @ 0x0
> dCPU: 1 PID: 74 Comm: kworker/1:1 Tainted: G        W    3.13.9+ #3

The taint shows that there's previously been a WARN() -- what was it?

Could you describe more about the circumstances of this?  Is it
reproducable?  Any special config?  What exact SHA?  Any local changes?

-Scott