On Friday, May 20, 2016 09:36:52 PM Fabio Estevam wrote:

On Fri, May 20, 2016 at 9:30 PM, Rafael J. Wysocki [off-list ref] wrote:

quoted

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.

quoted

quoted

quoted

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 */