Як розслідувати причину тотальної повіси?

Моя машина Arch іноді зависає, раптом жодним чином не реагуючи на мишу чи клавіатуру. Курсор заморожений. Ctrl-Alt-Backsp не зупинить X11, а ctrl-alt-del точно нічого не робить. Графіки активності процесора, мережі та диска в коньках та icewm зупиняються на оновленні. Через кілька хвилин вентилятор включається. Єдиний спосіб змусити комп’ютер взагалі щось робити - це вимкнути живлення.

Коли він завантажується, монітори температурних процесорів показують від 70 до 80 ° C. Перед тим, як повісити, я, як правило, займався низькою інтенсивністю, наприклад, веб-серфінгом, що займав 50 °

Журнали не показують нічого особливого порівняно із звичайним відключенням. Перевірка пам’яті працює нормально з нульовими дефектами.

Як я можу розслідувати, чому вона зависла? Чи є додаткова інформація, яку я можу знайти для підказки? Чи є щось менш драстичне, ніж вимкнення, щоб зробити якісь дії, якщо тільки обмежена оболонка або просто звукові сигнали, але це може дати підказку?

Машина являє собою 17-дюймовий ноутбук Gateway P6860 (об'ємний, але потужний) і він працює на базі Arch 64bit, на сьогоднішній день (станом на березень 2011 року). У мене Arch був тривалий час без цієї проблеми, перейшов на Ubuntu приблизно на тиждень потім відступив назад до нової установки Arch. Ось тоді почалися завіси.

ОНОВЛЕННЯ: Так, точно перегрів. При одній температурі миша та клавіатура перестають працювати, іноді стають функціональними після декількох хвилин охолодження. При більш високій температурі відбуваються гірші речі, як тотальна невідповідність, включаючи ігнорування SysRq. Цей стан невдовзі супроводжується раптовим відключенням живлення. Я вирішив проблему, купивши новий комп'ютер 8D

Відповідь Фредеріка, що стосується магічних SysRq та скидів ядра, спрацює, якщо ядро ​​все ще працює, а не справді висіло. Ядро може чомусь просто зайняте циклом.

Той факт, що він не відповідає Ctrl-Alt-Del, говорить мені, що, мабуть, це не так, і що машина замикається важко. Це означає несправність обладнання або щось близько пов'язане, наприклад, поганий драйвер.

Ваш тест перевірки пам’яті хороший, якщо ви даєте йому працювати досить довго. Ви також повинні спробувати інші речі, щоб спробувати підкреслити систему, як-от StressLinux . Тривалі показники також хороші.

Інша річ, яку слід спробувати, - це завантажувати систему з живим компакт-диском Ubuntu і намагатися використовувати систему як звичайну. Якщо повернення до Ubuntu тимчасово подібне не спричиняє повторення проблеми, є хороший шанс, що це насправді не зламане обладнання, а одна з пов’язаних речей, наприклад, поганий драйвер або неправильно налаштоване ядро. Цілком можливо, що більш популярний дистрибутив, подібний Ubuntu, міг би мати більш стабільну конфігурацію ядра, ніж аналогічний Arch, просто завдяки більшій кількості машин, на яких пробувались на етапі тестування дистрибутива.

Щодо заморожування, є кілька варіантів:

• використовуючи послідовний порт, якщо у вашому вікні є такий, щоб отримати там дамп, додавши console=ttyS0параметри завантаження, як описано тут . Вам потрібна друга машина з послідовним портом і нульовим модемним кабелем, щоб захопити файл дампа.

• Використовуючи мережеву консоль, щоб отримати дамп по мережі, дивіться тут .

• Використовуючи kexec / kdump таким чином, ви отримуєте локальний дамп, дивіться тут .

Щодо проблеми з чистим відключенням живлення, я пропоную вам скористатися магічною клавішею SysRq для 'S'ync дисків', вимкніть їх, а потім перезавантажте поле (літери - це ті, які слід вводити разом з alt -sysrq.

Редагувати: Якщо ви опублікуєте oops / trace у lkml, вам слід скористатись останньою (бажано останньою) версією ядра та без власних модулів.