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
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.