Crash after 'reboot' due to 9be4fd2c7723a

[Rafael J. Wysocki]

On Friday, May 20, 2016 09:36:52 PM Fabio Estevam wrote:
> On Fri, May 20, 2016 at 9:30 PM, Rafael J. Wysocki <rafael at kernel.org> wrote:
> 
> > What exactly do you mean by reverting here?  It surely cannot be
> > reverted by itself and there are many things that depend on it.
> 
> Yes, it cannot be reverted cleanly on 4.6.
> 
> If I do 'git checkout 9be4fd2c7723a30' and then 'git revert
> 9be4fd2c7723a30' then the reboot command works.

OK, so in fact you need to go all the way to the parent of 9be4fd2c7723a30.

> >>> Is this an SMP board, actually?
> >>
> >> Yes, this is a single core CortexA7.
> >
> > Hmm.  Single core means non-SMP rather?
> 
> CONFIG_SMP can be set or not in the kernel config. With CONFIG_SMP=n
> the issue does not happen.

Yes, you can run an SMP kernel on a non-SMP board too, which is what leads to
the problem you're seeing.

If I'm not mistaken, the patch below should allow irq_work to make forward
progress for you, so please check if it makes any difference.

The root of the problem seems to be arch_irq_work_raise() and specifically
the __smp_cross_call function that appears to have problems.

I bet that is_smp() should return false on your platform, but it returns
true for some reason.

---
 drivers/cpufreq/cpufreq_governor.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -362,6 +362,7 @@ static struct policy_dbs_info *alloc_pol
 	mutex_init(&policy_dbs->timer_mutex);
 	atomic_set(&policy_dbs->work_count, 0);
 	init_irq_work(&policy_dbs->irq_work, dbs_irq_work);
+	policy_dbs->irq_work.flags = IRQ_WORK_LAZY;
 	INIT_WORK(&policy_dbs->work, dbs_work_handler);
 
 	/* Set policy_dbs for all CPUs, online+offline */