Как выяснить причину полного зависания?

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

При загрузке мониторы температуры процессора показывают температуру от 70 до 80C. Перед зависанием я обычно занимался низкоинтенсивной деятельностью, например, веб-серфингом, около 50C.

Логи не показывают ничего особенного по сравнению с обычным выключением. Проверка памяти работает нормально с нулевыми дефектами.

Как я могу выяснить, почему он повесил трубку? Есть ли дополнительная информация, которую я могу найти для подсказки? Есть ли что-нибудь менее радикальное, чем отключение питания, чтобы получить какое-то действие, если только какая-то ограниченная раковина или просто звуковые сигналы, но может дать подсказку?

Машина представляет собой 17-дюймовый ноутбук Gateway P6860 (громоздкий, но мощный), и на нем установлена ​​последняя версия Arch 64bit (по состоянию на март 2011 года). У меня долгое время был Arch без этой проблемы, я перешел на Ubuntu около недели затем вернулся к новой установке Arch. Тогда начались завесы.

ОБНОВЛЕНИЕ: Да, конечно это перегревается. При одной температуре мышь и клавиатура перестают работать, иногда становясь работоспособными после нескольких минут охлаждения. При более высокой температуре происходят худшие вещи, такие как полная безответственность, включая игнорирование SysRq. Это условие вскоре сопровождается внезапным отключением питания. Я решил проблему, купив новый компьютер 8D

Ответ Фредерика, включающий магический SysRq и дампы ядра, будет работать, если ядро ​​все еще работает и не зависло. По какой-то причине ядро ​​может быть просто зациклено.

Тот факт, что он не реагирует на Ctrl-Alt-Del, говорит мне, что, вероятно, это не так, и что машина сильно зависает. Это означает аппаратный сбой или что-то тесно связанное, например, плохой драйвер.

Ваш тест проверки памяти хорош, если вы позволите ему работать достаточно долго. Вам также следует попробовать другие вещи, чтобы попытаться подчеркнуть систему, например, StressLinux . Длительные тесты тоже хороши.

Еще одна попытка - загрузить систему с живого компакт-диска Ubuntu и попытаться использовать систему в обычном режиме. Если такое временное возвращение в Ubuntu не приводит к повторению проблемы, есть большая вероятность, что на самом деле это не сломанное оборудование, а одна из связанных вещей, например, плохой драйвер или неправильно настроенное ядро. Вполне возможно, что более популярный дистрибутив, такой как Ubuntu, может иметь более стабильную конфигурацию ядра, чем дистрибутив, такой как Arch, просто из-за большего количества машин, на которых он был опробован на этапе тестирования дистрибутива.

Что касается заморозки, есть несколько вариантов:

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

• используя netconsole, чтобы получить дамп по сети, смотрите здесь .

• Используя kexec / kdump, вы получите локальный дамп, смотрите здесь .

Что касается проблемы с чистым отключением питания, я предлагаю вам использовать волшебный ключ SysRq для 'S' синхронизации дисков, 'U'монтирования их, а затем повторного' B'oot the box (буквы - те, которые вы должны ввести вместе с alt -sysrq.

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