Messages in this thread | | | From | Woody Suwalski <> | Date | Tue, 13 Aug 2019 11:19:18 -0400 | Subject | Re: Kernel 5.3.x, 5.2.2+: VMware player suspend on 64/32 bit guests |
| |
On Mon, Aug 12, 2019 at 1:24 PM Thomas Gleixner <tglx@linutronix.de> 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
| |