Woody, On Tue, 13 Aug 2019, Woody Suwalski wrote: > On Mon, Aug 12, 2019 at 1:24 PM Thomas Gleixner <t...@linutronix.de> wrote: > > The ACPI handler is not the culprit. This is either an emulation bug or > > something really strange. Can you please use a WARN_ON() if the loop is > > exited via the timeout so we can see in which context this happens? > > > > B. On 5.3-rc4 problem is gone. I guess it is overall good sign.
Now the interesting question is what changed between 5.3-rc3 and 5.3-rc4. Could you please try to bisect that? > C. To recreate problem I went back to 5.2.4. The WARN_ON trace shows > (in reverse): Next time you can spare yourself the work to reverse the stack trace. We are all used to read it the other way round :) > entry_SYSCALL_64_after_hwframe > do_syscall_64 > ksys_write > vfs_write > kernfs_fop_write > state_store > pm_suspend.cold.3 > suspend_devices_and_enter > dpm_suspend_noirq > suspend_device_irqs > ?ktime_get > ?synchronize > synchronize_irq > __synchronize_hardirq.cold.9 dpm_suspend_noirq() is called with all CPUs online and interrupts enabled. In that case an interrupt pending in IRR does not make any sense at all. Confused. Thanks, tglx