Crash after 'reboot' due to 9be4fd2c7723a
Rafael J. Wysocki
rjw at rjwysocki.net
Fri May 20 17:56:20 PDT 2016
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(+)
@@ -362,6 +362,7 @@ static struct policy_dbs_info *alloc_pol
+ policy_dbs->irq_work.flags = IRQ_WORK_LAZY;
/* Set policy_dbs for all CPUs, online+offline */
More information about the linux-arm-kernel