Crash after 'reboot' due to 9be4fd2c7723a
From: rafael@kernel.org (Rafael J. Wysocki)
Date: 2016-05-23 21:03:01
Also in:
linux-pm
From: rafael@kernel.org (Rafael J. Wysocki)
Date: 2016-05-23 21:03:01
Also in:
linux-pm
On Mon, May 23, 2016 at 10:59 PM, Fabio Estevam [off-list ref] wrote:
On Mon, May 23, 2016 at 5:23 PM, Rafael J. Wysocki [off-list ref] wrote:quoted
For one, if that platform is not capable of raising interrupts for IRQ works, I'm not sure why arch_irq_work_has_interrupt() returns true on it.It returns true because the kernel was built with CONFIG_SMP=y. On ARM we have: static inline bool arch_irq_work_has_interrupt(void) { return is_smp(); } and then: static inline bool is_smp(void) { #ifndef CONFIG_SMP return false; #elif defined(CONFIG_SMP_ON_UP) extern unsigned int smp_on_up; return !!smp_on_up; #else return true; #endif } So if CONFIG_SMP=y, is_smp() returns 1. As I mentioned before, the reboot problem does not happen with CONFIG_SMP=n.
First, why don't the other ARM UP platforms have this problem when SMP kernels are run on them? Second, quite evidently, the platform says "I can raise interrupts for IRQ works", but then it doesn't do that. That doesn't seem particularly consistent to me ...