Сервер Debian Linux заблокирован - в журналах нет подсказок?

У меня сегодня утром завис сервер. Вот снимок экрана с консоли:

Ни одно из сообщений со снимка экрана для меня ничего не значит. Такое ощущение, что важные вещи наверняка прокручиваются с консоли. Я не могу найти ни одного сообщения из приведенного выше снимка экрана в системном журнале, сообщении, dmesg, журналах отладки или что-либо еще, что было зарегистрировано во время сбоя. Разве это не должно было быть зарегистрировано?

Это коробка Debian, на которой работает Proxmox. uname вывод:

2.6.32-4-pve # 1 SMP Понедельник, 9 мая 12:59:57 CEST 2011 x86_64 GNU / Linux

Сервер был в сети около года без каких-либо сбоев и снова загрузился нормально.

Я хотел бы выяснить, в чем могла быть проблема, чтобы мы могли предотвратить ее повторение в будущем. Но из имеющихся у меня доказательств я даже не знаю, была ли это проблема аппаратного или программного обеспечения. Идеи?

Какой именно выпуск ядра Debian вы используете? Вы можете увидеть полные номера версий и ревизий, выполнив команду «dpkg -l | grep linux-image».

Похоже, вы попали в довольно распространенная ошибка которые я видел много раз: в ядрах до 3.2 mainline, до 2.6.32.50 стабильный и до Debian 2.6.32-45 (на основе стабильной версии 2.6.32.50), есть переполнение часов, которое произойдет после ~ 208 дней безотказной работы, что, в свою очередь, позволит потенциал сбоя. Я не знаю точно, что может вызвать сбой после этого времени; сам патч довольно расплывчато об этом слишком:

Although we may still have enough bits to store the value of ns,
in some cases, we may not have enough bits to store cycles * cyc2ns_scale,
leading to an incorrect result.

Я видел более сотни сбоев из-за этой проблемы, прежде чем было определено, что ее вызвало, и патч не был развернут.

Ошибка была подробно обсуждается в lkml в конце 2011 года. Возможна ссылка на это деление на ноль ошибка, но я не нашел никакого вывода.

TL; DR: вероятным решением будет обновление до версии Linux-образа Debian 2.6.32-45 или позже.

Это скриншот паники ядра. Трассировка печатается наизнанку, так что какая бы функция в конечном итоге не убила ядро, она находится вне верхней части экрана, но, начиная с вершины, это вызов divide_error() в hpet_msi_next_event() divide_error() определяется в ядре как ловушка для FPE_INTDIV, так что-то в hpet_msi_next_event() попытался разделить на ноль.

К сожалению, причиной этого может быть аппаратное и программное обеспечение, или даже временная ошибка переворота битов. (Вы используете RAM ECC?)