Odpowiedzi:
Te zawieszenia występują, gdy procesor próbuje wejść w stan niskiego poboru mocy (stan c), którego jądro nie obsługuje. Ten problem został wprowadzony przez
commit 8fb55197e64d5988ec57b54e973daeea72c3f2ff
Date: Tue Apr 7 16:20:28 2015 +0100
drm/i915: Aggressive downclocking on Baytrail
To poszło w górę w jądrze 4.2 i od tego czasu mieliśmy problemy. Jak wyjaśniono w odpowiedzi heynnema (i w tym poście, w którym próbowałem zestawić informacje ), istnieje proste i skuteczne obejście, przekazujące parametr rozruchowy, który wyłącza stany niskiej mocy.
Dostępna obecnie wersja beta 17.04 używa wersji 4.9 (bazuje na wersji 4.9.6, jak rozumiem), i do czasu wydania wersji w kwietniu, sądzę, że będzie korzystać z wersji 4.10 . Problem nadal istnieje w tych jądrach, więc doszedłem do wniosku, że na razie nie jest rozwiązany . Sprawdziłem dzienniki zmian jądra Ubuntu i nie znalazłem nic, ale poprawcie mnie, jeśli się mylę.
I zostały śledzenia błędów c-state tu na kernel.org przez długi czas. W styczniu 2017 roku Mika Kuoppala dodała tę poprawkę do wątku. Najwyraźniej cofa wcześniejsze zatwierdzenie, które spowodowało problem. Łatka nazywa się
drm/i915/byt: Avoid tweaking evaluation thresholds
Testy wykazały bardzo dobre wyniki dzięki tej poprawce, która została przesłana właścicielom sterowników i915 25 stycznia. Wszystko dobrze, może zostać scalone w oknie 4.11. Jądro 4.11 może zostać wydane pod koniec kwietnia. Wersja tej łatki została scalona w oknie 4.11, a raporty wskazują, że błąd został naprawiony w 4.11.
Każdy z kłopotliwych procesorów BayTrail zachowuje się nieco inaczej z każdym innym jądrem. W 16.04 (jądro 4.4) mój czas pracy na Atom Z3735F bez parametru intel_idle wynosił około 15 minut przed zamrożeniem. Testowałem wersję beta 17.04 ISO w trybie na żywo i nie dostałem zamrożenia w 90 minut, więc wygląda na to, że mam szczęście z tym jądrem. Możesz zrobić to samo, aby przetestować dowolny obraz w systemie - po prostu utwórz bootowalny USB i „wypróbuj Ubuntu bez instalacji” i przetestuj go tak długo, jak to możliwe.
Kiedy pojawiło się 17.04, zainstalowałem go, aw pierwszych dwóch tygodniach uruchomiłem go bez intel_idleparametru, miałem tylko trzy stop-klatki, co jest ogromnym ulepszeniem we wcześniejszych wersjach.
Najbezpieczniej jest użyć parametru rozruchu. Na podstawie moich badań spodziewam się, że błąd zostanie naprawiony w 17.10 (oraz w innych wydaniach dystrybucji w tym roku), który będzie korzystał z jądra> = 4.11, ale nie w 17.04.
Jednak zawsze istnieje możliwość, że zespół jądra Ubuntu może załatać go samodzielnie. Jeśli czasami możesz tolerować uruchamianie niestabilnego systemu, możesz obserwować postęp, uruchamiając regularne aktualizacje ( sudo apt update && sudo apt full-upgrade) i testując każde nowe jądro bez parametru rozruchowego, gdy tylko się pojawi. Możesz także czytać dzienniki zmian podczas instalowania nowych pakietów lub (ponownie, jeśli tolerujesz niestabilność) zainstalować jądro linii głównej .
i915więc prawdopodobnie zostanie naprawiony przez tę samą łatkę, ale raport o błędzie dotyczy problemów naprawionych przez parametr intel_idle, a jeśli to nie zadziała, jest to inny błąd zgodnie z ludzie jądra. Czy możesz podać raport o błędzie lub wątek na forum (mówisz, że inni dzielą się twoim problemem), w którym mogę dowiedzieć się więcej, aby ci doradzić, co dalej? (Myślę, że być może będziesz musiał zadać nowe pytanie)
Jest to poprawione w Jak ustawić intel_idle.max_cstate = 1 .
W terminalwpisz:
gksudo gedit /etc/default/grub
i zmień ten wiersz:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
aby to uwzględnić:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"
następnie wykonaj:
sudo update-grub
reboot
To jest problem Intela, nie problem Ubuntu, ale dzięki Bogu, że mamy naprawę.
Nikt nie wie, czy Ubuntu 17.04 będzie wymagać tej poprawki, czy nie.
Zgodnie z komentarzem nr 1013 w zgłoszeniu błędu jest teraz naprawiony:
Dawno nie sprawdzałem tego wątku, ale pomyślałem, że powinienem opublikować moje odkrycia, na wypadek, gdyby były przydatne dla kogokolwiek.
Komputer z niższej półki zasilany procesorem Intel N2807, który nigdy nie działał więcej niż 30 minut bez awarii, gdy nie ustawiłem ... max_cstates = 1 teraz działa doskonale dobrze z podstawowym jądrem wer. 5.3.1 lub 4.19.75. Uruchomiłem go przez kilka dni z każdą wersją bez żadnych problemów. Średnie zużycie energii również spadło o nieco ponad 10%.
Naprawienie tego błędu zajęło około czterech lat, po raz pierwszy zgłoszone 8 grudnia 2015 r.