On Mon, Aug 12, 2019 at 1:24 PM Thomas Gleixner <[email protected]> wrote: > On Mon, 12 Aug 2019, Woody Suwalski wrote: > > > I have added a timeout counter in __synchronize_hardirq(). > > At the bottom I have converted while(inprogress); to while(inprogress > > && timeout++ < 100); > > > > That is bypassing the suspend lockup problem. On both 32-bit and > > 64-bit VMs the countdown is triggered by sync of irq9. > > So ACPI triggered an interrupt, which got already forwarded to a CPU, but > it is not handled. That's more than strange. > > > Which probably means that there is some issue in ACPI handler and > > synchronize_hardirq() is stuck on it? > > 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? > Thomas, Rafael
A. Learning the Wonderfull World of Gmail Web Interface. Maybe w/o top posting this time.... B. On 5.3-rc4 problem is gone. I guess it is overall good sign. C. To recreate problem I went back to 5.2.4. The WARN_ON trace shows (in reverse): 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 Comm: systemd-sleep Would that help? Thanks, Woody
