Thread (29 messages) 29 messages, 4 authors, 2016-05-23

Crash after 'reboot' due to 9be4fd2c7723a

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 ...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help