14.05.2024 13:10, Michael Tokarev wrote:
So it looks like hibernate/resume cycle changes something in ACPI and makes acpi_cpufreq module confused - either when it's already loaded (happens at resume), or when it gets loaded for the first time *after* the resume. I think some ACPI table dump (before-after) might be needed here, which one?
I checked the ACPI tables. And indeed, after regular platform-based hibernate-resume cycle, some of them changes. For one, SSDT5 (which includes \_PR.C003._PPC method) becomes basically garbled. iasl does not recognize it. Before hibernate: * Original Table Header: * Signature "SSDT" * Length 0x0000119C (4508) * Revision 0x01 * Checksum 0x5A * OEM ID "LENOVO" * OEM Table ID "TP-R13 " * OEM Revision 0x00000001 (1) * Compiler ID "AMD " * Compiler Version 0x00000001 (1) After hibernate: [000h 0000 4] Signature : "CRAT" [004h 0004 4] Table Length : 00000810 [008h 0008 1] Revision : 01 [009h 0009 1] Checksum : 5F [00Ah 0010 6] Oem ID : "LENOVO" [010h 0016 8] Oem Table ID : "TP-R13 " [018h 0024 4] Oem Revision : 000011E0 [01Ch 0028 4] Asl Compiler ID : "PTEC" [020h 0032 4] Asl Compiler Revision : 00000002 **** Unknown ACPI table signature [CRAT] No doubt acpi_cpufreq will be confused by this garbage. Can something be said from here? (windows10 does hibernate/resume just fine, - but setting acpi_osi="Windows 2022" does not change anything). Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
