Vor ein paar Monaten hatte ich mich ja ein wenig über Linux und Notebooks ausgekotzt:

Linux und das leidige Problem mit Notebooks

Auch wenn ich seit dieser Zeit Windows 10 auf dem Notebook installiert habe, hat mich das Problem nicht losgelassen:

Wie kann es sein, dass bestimmte Notebooks von verschiedenen Herstellern nahezu problemlos den neuen Suspendmodus unter Linux unterstützen, andere aber massive Probleme haben? Vor zwei Tagen bin ich dann auf den folgenden Bugreport gestoßen:

https://gitlab.freedesktop.org/drm/amd/-/issues/1721

Der Ersteller des Bugreports besitzt exakt das gleiche Modell des Notebooks und ein Vorschlag in dem Report war, zwei kleine Patches auszuprobieren:

https://patchwork.kernel.org/project/platform-driver-x86/list/?series=556591&state=%2A&archive=both

Hier sind sie mal im Ganzen:

diff --git a/drivers/platform/x86/amd-pmc.c b/drivers/platform/x86/amd-pmc.c
index d6a7c896ac86..fc95620101e8 100644
--- a/drivers/platform/x86/amd-pmc.c
+++ b/drivers/platform/x86/amd-pmc.c
@@ -476,6 +476,7 @@  static const struct acpi_device_id amd_pmc_acpi_ids[] = {
 	{"AMDI0006", 0},
 	{"AMDI0007", 0},
 	{"AMD0004", 0},
+	{"AMD0005", 0},
 	{ }
 };
 MODULE_DEVICE_TABLE(acpi, amd_pmc_acpi_ids);

diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index bd92b549fd5a..1c48358b43ba 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -371,7 +371,7 @@  static int lps0_device_attach(struct acpi_device *adev,
 		return 0;
 
 	if (acpi_s2idle_vendor_amd()) {
-		/* AMD0004, AMDI0005:
+		/* AMD0004, AMD0005, AMDI0005:
 		 * - Should use rev_id 0x0
 		 * - function mask > 0x3: Should use AMD method, but has off by one bug
 		 * - function mask = 0x3: Should use Microsoft method
@@ -390,6 +390,7 @@  static int lps0_device_attach(struct acpi_device *adev,
 					ACPI_LPS0_DSM_UUID_MICROSOFT, 0,
 					&lps0_dsm_guid_microsoft);
 		if (lps0_dsm_func_mask > 0x3 && (!strcmp(hid, "AMD0004") ||
+						 !strcmp(hid, "AMD0005") ||
 						 !strcmp(hid, "AMDI0005"))) {
 			lps0_dsm_func_mask = (lps0_dsm_func_mask << 1) | 0x1;
 			acpi_handle_debug(adev->handle, "_DSM UUID %s: Adjusted function mask: 0x%x\n",

Jeder Patch fügt einzig zwei zusätzliche Zeilen Code (Eine Zeile ist nur ein Kommentar) ein. Der Patch wurde wegen Problemen mit dem Microsoft Surface Laptop 4 eingeführt:

The Surface Laptop 4 AMD has used the AMD0005 to identify this
controller instead of using the appropriate ACPI ID AMDI0005.  Include
AMD0005 in the acpi id list.

Die Diskussion dreht sich dann grundsätzlich nur noch darum ob die Patches zu Regressionen führen. Am Ende wurden sie aber ohne weitere Diskussionen in den Master-Branch von Linux gemergt und sind dadurch auch in Linux 5.14.4 und 5.15-rc6 gelandet.

Da ich ein, von Natur aus, neugieriger Mensch bin, wollte ich natürlich wissen ob die zwei Zeilen Code das Problem bei meinem Notebook lösen. Also schnell Ubuntu 21.10 und die aktuellste Kernelversion aus dem Mainline-PPA installiert. Und siehe da:

Die Patches wirken! Das Notebook legt sich jetzt vollkommen problemlos schlafen und wacht auch innerhalb von Sekundenbruchteilen zuverlässig aus dem Schlaf auf. Mit der Version 5.14.3 funktionierte es noch nicht.

Was mich an der ganzen Sache wurmt, ist die Tatsache, dass der Fehler auf Seiten von Acer zu suchen ist. Hätten die Firmwareentwickler nicht gepennt und den Eintrag in den ACPI-Tabellen korrekt geschrieben („AMDI0005“ anstatt „AMD0005“) dann gäbe es die Probleme erst gar nicht. Die Frage, die sich mir jetzt nur stellt, ist, wie Windows solche Dinge handhabt. Das Problem muss grundsätzlich auch unter Windows existieren und zwar aus folgenden zwei Gründen:

• In einem anderen Bugeintrag erwähnte ein Benutzer, dass ein BIOS-Update für sein Desktop-Mainboard eben diese ACPI-ID verändert hat und danach der s2idle-Modus fehlerfrei funktioniert hat. Große Hersteller wie Gigabyte ändern selten ACPI-Einträge, außer es gibt unter Windows Probleme. Linux interessiert die wenigsten Hersteller.
• Auf meinem Notebook funktionierte der Stromsparmodus unter Windows 10 auch nicht zu 100%. Ich habe das aber erst jetzt kapiert. Ich hatte mich nämlich schon die ganze Zeit gewundert warum mein Acer-Notebook im Suspend-Modus gefühlt mehr Strom als andere Notebooks im gleichen Zustand benötigt hat (z.B. mein altes Lenovo Thinkpad T460). Dieses konnte ich locker mehrere Tage suspenden, beim Acer ist nach spätestens zwei Tagen Sense. Und das Notebook hat sich nach einer bestimmten Zeit immer selbst heruntergefahren, obwohl noch genug Saft im Akku war. Das deutet darauf hin, dass das Notebook nicht wirklich geschlafen hat und Windows nach einer bestimmten Zeit den Rechner in den Hibernate-Modus versetzt hat. Dadurch, dass Windows auf SSDs und dank Fastboot ziemlich schnell wieder betriebsbereit ist, dürfte dieses Verhalten nur wenigen Benutzern auffallen.

Eine Recherche im Acer-Community-Forum brachte dann auch einige Threads bezüglich des Suspend-Verhaltens zu Tage:

https://community.acer.com/en/discussion/602424/sf314-42-doesnt-wake-up-from-sleep-mode-windows-restarts-instead-please-help

Es gibt also auch bei vielen anderen Benutzern unter Windows Probleme und erst einige BIOS-Updates haben diese soweit beseitigt, dass sich weniger Benutzer gemeldet haben.

Lange Rede, kurzer Sinn:

Mein Notebook funktioniert jetzt endlich wie gewollt unter Linux und ich muss auch kein Windows mehr darauf benutzen 😉