System zawiesza się całkowicie dzięki Intel Bay Trail


29

Mój system zawiesza się całkowicie w przypadkowych, częstych odstępach czasu. Zacząłem mieć ten sam problem w Ubuntu 14.04, ale po ostatniej aktualizacji do 16.04 nie ma poprawy, w rzeczywistości wydaje się gorzej.

Kiedy to się stanie, nic nie można zrobić. Próbowałem już wszystkiego w tym wątku: co zrobić, gdy Ubuntu zawiesza się, ale nic nie działa, muszę mocno zresetować. Przeczytałem wszystkie logi systemowe, journalctlale nigdy nie ma żadnych informacji, które mogłyby pomóc w zdiagnozowaniu problemu.

Jest to system podwójnego rozruchu z systemem Windows 10 i nie ma tam problemu, więc nie jest to wadliwy sprzęt.

Mój laptop ma procesor Intel Bay Trail (Pentium N3540)


Odpowiedzi:


37

Na twój procesor wpływa błąd stanu c

Powoduje to całkowite zawieszenie, gdy procesor próbuje wejść w nieobsługiwany stan uśpienia. Jest to problem dla wielu urządzeń Bay Trail, szczególnie w przypadku nowszych (4. *) jąder.

Dotyczy procesorów AFAIK:

Atom Z3735F (Asus X205TA, Acer Aspire Switch 10, Lenovo MIIX 3 1030) 
Atom Z3735G
Celeron J1900 (Asus ET2325IUK, shuttle XS35V4)
Celeron N2940 (Acer Aspire ES1-711, Chromebook)
Celeron N2840 (Acer Aspire ES1-311)
Celeron N2930 (Jetway JBC311U93, Zotac Nano CI320)
Pentium N3520 
Pentium N3530 (Acer V3-111P)
Pentium N3540 (Dell Inspiron 15 3000, Lenovo G50, ASUS X550MJ)

(proszę (zasugeruj) edycję, aby dodać własne urządzenie, jeśli dotyczy)

Pełną listę procesorów Bay Trail można znaleźć tutaj

Istnieje proste obejście tego problemu, dopóki nie zostanie poprawnie naprawione na początku.

Wystarczy przekazać parametr rozruchowy jądra, a losowe zatrzymanie zostanie całkowicie zatrzymane. Ten parametr może nieznacznie zwiększyć zużycie baterii, ale da ci użyteczny system.

Robisz to, edytując plik konfiguracyjny GRUB:

Uruchom Ubuntu i otwórz terminal, naciskając Ctrl+ Alt+, Ta następnie wpisz

sudo nano /etc/default/grub

Znajdź linię, która się zaczyna GRUB_CMDLINE_LINUX_DEFAULT=

Należy to zmienić, aby uwzględnić intel_idle.max_cstate=1

Więc po twojej edycji brzmi mniej więcej tak

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"

quieti splashsą domyślnymi parametrami dla Ubuntu Desktop - nie trzeba ich zmieniać ani żadnych innych wcześniej istniejących parametrów

Teraz zapisz plik naciskając ctrl+ onastępnie enteri wyjdź naciskając ctrl+x

Teraz biegnij

sudo update-grub

Następnie uruchom ponownie.


Co zrobić, jeśli nie masz wystarczająco dużo czasu, aby zawiesić system

Nie ma problemu. Jak wyjaśniono na stronie pomocy, do której odsyłałem wcześniej, możesz dodać parametr do GRUB-a przed uruchomieniem. Zauważ, że przekazuje to parametr tylko dla bieżącego rozruchu, więc nadal musisz edytować /etc/default/grubpo uruchomieniu, aby zmiana była trwała.

Musisz przejść do menu GRUB . Jeśli uruchamiasz podwójnie, to i tak się pojawi, jeśli nie, musisz nacisnąć i przytrzymać (lub dotknąć) shiftpo naciśnięciu przycisku zasilania, aby włączyć.

Po przejściu do tego ekranu wybierz Opcje zaawansowane dla Ubuntu . Możesz przenieść kursor do innego jądra lub pozostawić go w miejscu, aby edytować opcje domyślne. Zamiast naciskać enter, naciśnij ei pójdziesz do trybu edycji, patrząc niejasno jak ten .

Przesuń kursor w dół tam, gdzie jest napisane quiet splash, umieść spację po rozbryzgu i ostrożnie intel_idle.max_cstate=1pisz, upewniając się, że po nim również jest spacja.

Teraz naciśnij F10lub Ctrl+, xaby uruchomić.


@Arronical hehe dzięki! Muszę to wiedzieć - mój system pozostanie bez niego przez ~ 15 minut, ale z param nigdy go nie zamrozi :) Całe uznanie dla naprawdę niesamowitych hakerów, którzy to wymyślili
Zanna

Dziękuję Ci! Czy to powstrzymuje brak odpowiedzi na Ctrl Alt REISUB? Odpowiedź na powyższą edycję GRUB była taka, że ​​jeśli ustawiony jest ukryty limit czasu, powyższa edycja nie będzie działać. Jak obejść ten problem, jeśli problem będzie się powtarzał?
clr

@clr c-state zawiesza się nie reaguje na Magic Sysrq REISUB, ale ta poprawka zatrzymuje c-state zawiesza się. Jeśli system zawiesza się z innego powodu, REISUB może działać. GRUB_HIDDEN_TIMEOUT nie ma wpływu na parametry rozruchowe i dostęp do menu powinien być możliwy po naciśnięciu klawisza shift podczas uruchamiania. Jeśli nie możesz, w przypadku gdy system zawiesza się zbyt szybko, abyś mógł go edytować /etc/default/grub, to jest problem, ale możesz spróbować uruchomić sesję na żywo wersji ze starszym jądrem, aby edytować plik - zamontuj partycję root na /mnti edytuj /mnt/etc/default/grubw dodaj parametr.
Zanna

Dzięki za jasne instrukcje. Mam nadzieję, że to wystarczy. Zamelduję się tutaj, jeśli nie będzie. Obecnie korzystam z wersji 16.10 na Zotac Nano CI320. Próbowałem wcześniej 16.04 i Debian 8, a także doświadczyłem losowych zawieszeń. Próbowałem 16.10, mając nadzieję, że problem zniknie z nowszym jądrem. Co ciekawe, za jednym razem, gdy próbowałem REISUB (nie pamiętam, jaki system operacyjny) zadziałało - może się okazać, że mam inny problem.
Jeremy Cook

@JeremyCook Właśnie zainstalowałem 16.10 i pierwszą rzeczą, którą zrobiłem, było edytowanie parametrów rozruchu - powinienem naprawdę sprawdzić to nowe jądro! Daj mi znać, czy to działa, czy nie tutaj.
Zanna

1

Linux na Bay Trail i procesory Braswell losowo zawiesza się przy wbudowanych urządzeniach wideo.

Problem dotyczy kontroli temperatury. Po prostu wyjmij moduł Thermald:

sudo apt-get remove thermald 

3
Uważam, że błąd w Bay Trail dotyczy sterownika i915 (Intel CPU). Procesor stale próbuje przejść w stan uśpienia, który nie jest przez niego obsługiwany. Problemy dla użytkowników Bay Trail zaczęły się po zatwierdzeniu wersji i915, więc zawsze była to wina. Być może jednak istnieje inna przyczyna i nie mam pojęcia o tym, że Braswell zawiesza się i byłoby wspaniale wiedzieć, że zostały naprawione przez jakąś (bezpieczną?) Akcję. Czy masz jakieś odniesienia do tych informacji, czy możesz nam powiedzieć, na jakim sprzęcie został przetestowany i działał?
Zanna,

Wygląda na to, że nadal jest to problem z 19.04. Miałem nadzieję, że zostanie to już naprawione. Stało się na moim laptopie od 14.04. 15.10 było prawie niemożliwe do naprawienia.
crip659

0

Dla osób śledzących ten błąd tutaj jest aktualizacja. Idź do: Bug 109051 - intel_idle.max_cstate = 1 wymagany na baytrail, aby zapobiec awariom i naciśnij Endklawisz. W razie potrzeby naciśnij, Page Upaby wyświetlić komunikat # 1013.

Zgodnie z komentarzem # 1013 jest to teraz naprawione w najnowszych jądrach:

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 napędzany 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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.