Stany zasilania S3 (Suspend-to-RAM, Sleep) i S4 (Suspend-to-Disk, Hibernation) są zdefiniowane przez standard ACPI i zarządzane przez firmware BIOS/UEFI we współpracy z systemem operacyjnym. Problemy z wchodzeniem w te tryby lub wznawianiem z nich są jednymi z najczęstszych skarg użytkowników laptopów i mogą mieć zarówno przyczyny w firmware jak i w systemie operacyjnym czy sterownikach. Prawidłowa diagnoza wymaga systematycznego podejścia uwzględniającego wszystkie warstwy.
Ze względu na powszechność problemów z uśpieniem i hibernacją, technik serwisu firmware powinien mieć ugruntowaną wiedzę o tym, jak firmware kontroluje te procesy i kiedy naprawa firmware jest właściwym rozwiązaniem.
Jak firmware kontroluje S3 i S4
Firmware BIOS/UEFI definiuje dostępne stany zasilania przez tabele ACPI (FADT – stany S3 i S4 muszą być zadeklarowane) i implementuje procedury inicjalizacji sprzętu podczas wznowienia ze snu. Przejście do S3 wymaga: zamknięcia kontekstu wszystkich urządzeń przez sterowniki, zapisania stanu procesora w NVRAM (resume vector), wyłączenia zasilania wszystkich komponentów poza pamięcią RAM. Wznowienie z S3 wymaga od firmware: przywrócenia zasilania sprzętu, odtworzenia kontekstu z resume vector, przekazania sterowania do systemu operacyjnego.
Błąd w którymkolwiek z tych etapów może powodować: zawieszenie przy wchodzeniu w uśpienie (hang on sleep entry), czarny ekran przy wybudzeniu (no video on resume), BSOD po wybudzeniu (błąd sterownika podczas restoracji kontekstu), lub reboot zamiast wznowienia (firmware nie znalazł prawidłowego resume vector).
Firmware-level przyczyny problemów z S3/S4
Problemy z S3/S4 wynikające z firmware obejmują: brak deklaracji S3 lub S4 w FADT (firmware nie deklaruje obsługi tych stanów – Windows nie oferuje opcji uśpienia/hibernacji), błędna inicjalizacja urządzeń PCIe lub USB podczas wznowienia ze snu (urządzenia nie są prawidłowo reinicjalizowane przez firmware przed przekazaniem sterowania systemowi), niezgodność taktowania pamięci RAM przy wznawianiu (MRC używa innych timingów przy warm boot po S3 niż oczekuje zainstalowana pamięć), oraz przepełnienie bufora ACPI NVS podczas wchodzenia w S4 (brak miejsca dla stanu procesora).
Aktualizacja firmware jest najskuteczniejszą metodą naprawy tych problemów – producenci regularnie poprawiają procedury S3/S4 w aktualizacjach BIOS, szczególnie przy nowych wersjach Windows.
Diagnostyka S3/S4 a firmware vs system operacyjny
Kluczowe pytanie diagnostyczne: problem S3/S4 leży w firmware czy w systemie operacyjnym/sterownikach? Wskazówki: jeśli problem pojawia się na każdym systemie operacyjnym (Windows i Linux), przyczyną jest prawdopodobnie firmware lub hardware. Jeśli problem jest specyficzny dla Windows 11, ale nie Windows 10 (lub vice versa), przyczyną są sterowniki lub konfiguracja ACPI niekompatybilna z tą wersją systemu. Logi systemowe (Event Viewer → Power → Sleep and Wake) i wynik polecenia `powercfg /a` (dostępne stany zasilania) pomagają zawęzić diagnozę.
Polecenie `powercfg /a` w Windows pokazuje jakie stany zasilania są dostępne i dlaczego inne są niedostępne – np. „S3 is not supported by the system firmware" wskazuje jednoznacznie na brak deklaracji S3 w firmware ACPI.
Konfiguracja S3 vs Modern Standby po naprawie
Po naprawie firmware, konfigurujemy tryb uśpienia zgodnie z preferencjami klienta i możliwościami sprzętu. W nowoczesnych platformach Intel (12. gen+) S3 może być niedostępny przez firmware – wymuszony jest Modern Standby S0ix. W starszych platformach, klient może wybrać między S3 (pewne, sprawdzone, niski pobór mocy gdy działa poprawnie) a S0ix (powiadomienia w tle, szybkie budzenie, ale wyższy pobór mocy w problematycznych implementacjach). Dokumentujemy wybór i wyjaśniamy klientowi różnice praktyczne dla jego stylu użytkowania laptopa.
