https://bugzilla.kernel.org/show_bug.cgi?id=218557
--- Comment #4 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) --- > Besides, in the "good case" log there is this line: > kernel: amd_pmc AMDI0009:00: Last suspend didn't reach deepest state If the last suspend didn't reach the deepest state with that reverted I do agree it's not actually fixing the root of the issue; it's masking it. Could you repeat your bisect keeping this in mind? > Mario Limonciello from AMD said it's "an HP EC bug" (embedded controller) > > however it's weird and alarming we now have _two_ vendors with the same > issue. I need to point out that the EC is proprietary to each vendor. I have no knowledge of their codebase. It's entirely possible they issue some of the same commands to the SoC though. Mark, would you be able to find out more from your EC team what their expectations are for this situation compared to how Windows behaves? I wonder if we have a "mismatch" scenario that the EC is "expecting" the system to wake up and react; but we don't do that in Linux - we wait for a second interrupt to be active (like the GPIO controller) before we wake the system. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
