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

Crash after 'reboot' due to 9be4fd2c7723a

From: linux@armlinux.org.uk (Russell King - ARM Linux)
Date: 2016-05-23 21:11:14
Also in: linux-pm

On Mon, May 23, 2016 at 11:03:01PM +0200, Rafael J. Wysocki wrote:
On Mon, May 23, 2016 at 10:59 PM, Fabio Estevam [off-list ref] wrote:
quoted
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 ...
Maybe someone has implemented a SoC which has a CPU capable of SMP
but the GIC isn't...  I'm just guessing again.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help