Jak zbadać przyczynę całkowitego zawieszenia?

Moja maszyna Arch czasami zawiesza się, nagle nie reagując w żaden sposób na mysz lub klawiaturę. Kursor jest zamrożony. Ctrl-Alt-Backsp nie zatrzyma X11, a ctrl-alt-del nie robi dokładnie nic. Wykresy aktywności procesora, sieci i dysku w conky i icewm przestają się aktualizować. Za kilka minut włącza się wentylator. Jedynym sposobem, aby komputer w ogóle cokolwiek zrobił, jest wyłączenie zasilania.

Po uruchomieniu monitory temperatury procesora pokazują 70 do 80 ° C. Przed zawieszeniem zwykle wykonywałem czynności o niskiej intensywności, takie jak surfowanie po Internecie w około 50 ° C.

Dzienniki nie pokazują nic specjalnego w porównaniu do normalnego wyłączenia. Kontroler pamięci działa poprawnie z zerowymi defektami.

Jak mogę sprawdzić, dlaczego się zawiesił? Czy mogę znaleźć dodatkowe informacje na temat wskazówek? Czy jest coś mniej drastycznego niż wyłączenie zasilania, aby uzyskać jakąś akcję, choćby tylko niewielką liczbę pocisków lub tylko sygnały dźwiękowe, ale które mogą dać wskazówkę?

Maszyna jest 17-calowym laptopem Gateway P6860 (nieporęcznym, ale potężnym) i na razie działa na Arch 64-bitowym (od marca 2011 r.) Arch miałam przez długi czas bez tego problemu, przełączyłam się na Ubuntu na około tydzień następnie wycofał się z powrotem do nowej instalacji Arch. Wtedy zaczęły się zawieszania.

AKTUALIZACJA: Tak, na pewno się przegrzewa. W jednej temperaturze mysz i klawiatura przestają działać, a czasem stają się funkcjonalne po kilku minutach ochładzania. W wyższej temperaturze zdarzają się gorsze rzeczy, takie jak całkowity brak odpowiedzi, w tym ignorowanie SysRq. Po tym stanie następuje nagłe wyłączenie zasilania. Rozwiązałem problem, kupując nowy komputer 8D

Odpowiedź Frederika dotycząca magicznego SysRq i zrzutów jądra zadziała, jeśli jądro nadal działa i nie jest naprawdę zawieszone. Jądro może być z jakiegoś powodu po prostu zapętlone.

Fakt, że nie reaguje na Ctrl-Alt-Del, mówi mi, że prawdopodobnie tak nie jest i że maszyna mocno się blokuje. Oznacza to awarię sprzętu lub coś blisko ze sobą związanego, np. Zły sterownik.

Test sprawdzania pamięci jest dobry, jeśli pozwalasz mu działać wystarczająco długo. Powinieneś także spróbować innych rzeczy, aby spróbować obciążać system, takich jak StressLinux . Długoterminowe testy porównawcze są również dobre.

Inną rzeczą do wypróbowania jest uruchomienie systemu z Live CD Ubuntu i próba korzystania z systemu w normalny sposób. Jeśli tymczasowy powrót do Ubuntu nie powoduje ponownego wystąpienia problemu, istnieje duża szansa, że ​​nie jest to zepsuty sprzęt, ale jedna z powiązanych rzeczy, takich jak zły sterownik lub niepoprawnie skonfigurowane jądro. Jest całkiem możliwe, że bardziej popularna dystrybucja, taka jak Ubuntu, może mieć bardziej stabilną konfigurację jądra niż taka jak Arch, po prostu z powodu większej liczby maszyn, na których testowano ją podczas fazy testowej dystrybucji.

Jeśli chodzi o zamrożenie, istnieje kilka opcji:

• używając portu szeregowego, jeśli twoje urządzenie ma taki, aby uzyskać zrzut tam, dodając console=ttyS0opcje rozruchu, jak opisano tutaj . Potrzebujesz drugiej maszyny z portem szeregowym i zerowym kablem modemowym, aby przechwycić plik zrzutu.

• za pomocą netconsole, aby uzyskać zrzut przez sieć, patrz tutaj .

• Używając kexec / kdump w ten sposób otrzymujesz zrzut lokalny, patrz tutaj .

Jeśli chodzi o problem z wyłączeniem zasilania, sugeruję użyć magicznego klucza SysRq do „S'ync the discs”, „U'mount je, a następnie ponownie„ B'oot the box (litery to te, które należy wpisać wraz z alt -sysrq.

Edycja: Jeśli opublikujesz oops / trace do lkml, powinieneś użyć najnowszej (najlepiej najnowszej) wersji jądra i żadnych zastrzeżonych modułów.