Паника ядра linux что это

Паника ядра

Kernel panic (англ. букв.: паника ядра) — сообщение о критической ошибке ядра операционной системы, после которой операционная система не может продолжать дальнейшую работу.

Обычно этот термин применяется в среде операционных систем типа Kernel panic: … » и именем функции ядра panic() из оригинальной ОС Linux возникновению паники ядра зачастую предшествует состояние под названием oops. В ряде случаев oops может приводить к такому же неработоспобному состоянию системы, как и паника ядра.

Содержание

История

Сообщение Kernel panic было введено в ранних версиях операционной системы от главного конкурента на то время, Денисом Ритчи [1] :

Я сказал Деннису, что примерно половина кода, который я написал для Multics, был кодом обработки ошибок. Он ответил: «Мы всё это отбросили. Если произошла ошибка, у нас есть процедура под названием panic и если она вызвана, компьютер зависает и вы кричите: „Эй, перезапустите его!“»

I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, «We left all that stuff out. If there’s an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, ‘Hey, reboot it.’

Изначальная функция panic() принципиально не менялась от UNIX V5 до базирующихся на бесконечный пустой цикл. Позже, в процессе развития UNIX, функция panic() также была доработана и стала выводить на терминал разнообразную информацию, необходимую для отладки.

Подобный принцип обработки критических ошибок был перенят большинством более поздних операционных систем, таких как Mac OS [2] или Microsoft Windows.

Причины для Kernel panic

В большинстве случаев причиной для Kernel panic является критическая аппаратная ошибка (отказ оперативной памяти, ошибка процессора или другого критически важного устройства) или ошибка в самом ядре операционной системы, например попытка обращения к ошибочному или запрещённому адресу в памяти. Также причиной для Kernel panic могут быть ошибки в драйверах периферийных устройств или ошибки в файловой системе.

Ошибки пользовательских программ в современных операционных системах не приводят к Kernel panic и должны корректно обрабатываться ядром.

Исходный код функции panic()

Исходный код функции panic() в [3] :

Обработка Kernel panic

В нормальном случае при возникновении Kernel panic происходит остановка работы операционной системы с выдачей сообщений об ошибках на экран, после чего система ожидает выключения компьютера или перезагрузки. Однако, такая обработка этого события неприемлема тогда, когда простой компьютера крайне нежелателен или человека нет рядом (например на удалённых серверах или в нерабочее время).

В современных операционных системах, таких как GNU/Linux, Solaris, существует возможность изменить стандартное поведение функции panic() и производить перезагрузку компьютера автоматически. В GNU/Linux данная настройка осуществляется при помощи

Чтобы изменения действовали в GNU/Linux и после перезагрузки, необходимо добавить в файл /etc/sysctl.conf строку:

В обоих примерах «5» — количество секунд, после которых произойдёт перезагрузка. При установке отрицательного или равного 0 значения этого параметра, автоматической перезагрузки не произойдёт. [4]

В Solaris автоматическая перезагрузка после Kernel panic является стандартным поведением системы. [6]

Перезагрузка после Kernel panic имеет и очень серьёзный недостаток, особенно если это изменение не пропадает после первой перезагрузки. В случае, если перезагрузка не устраняет ту ошибку, которая вызывает Kernel panic, система будет останавливаться и перезапускаться вновь и вновь, что может привести к аппаратным ошибкам или потерям данных.

Для изучения причины паники ядра Linux может пригодится файл Windows XP при возниковении ошибки компьютер перезагружается автоматически. Это поведение системы управляется через Панель управления Windows. Если ошибка происходит при загурзке ОС, изменить поведение системы можно через меню кнопки F8.

Kernel panic в различных операционных системах

Изначально сообщение о Kernel panic ограничивалось коротким текстом о необходимости перезагрузки системы. В современных системах обычно выдается больше дополнительной информации.

• GNU/Linux и большинство других отладки и поиска причин этой ошибки. Этот механизм носит название Linux oops.
• В Mac OS X это сообщение было упрощено и сообщает лишь о необходимости перезапустить компьютер. Среди пользователей оно получило название «The Gray Screen of Panic and Disarray».

В то время как термин Kernel panic употребляется в основном для операционных системах обработка критических ошибок методом остановки системы получила другие названия:

• В OS/2, Windows 3.x: Black Screen of Death (англ.)
• В современных версиях Windows: Blue Screen of Death
• В старых компьютерах
• На компьютерах Guru Meditation
• В PDA работающих под управлением Windows Mobile и Palmtop, Pocket PC, SmartPhone): White Screen of Death (англ.)
• На PSP это надпись на 10 языках: «Данные конфигурации повреждены. Нажмите O (кружок) для восстановления стандартной конфигурации.»
• В Synerji (на телефонах

Примечания

См. также

Ссылки

• Примеры исходного кода функции panic() в Darwin/Mac OS X, Minix и Linux
• Что такое Kernel panic на примере Mac OS X
• Информация о Kernel panic по-русски
• Изображения, посвящённые Kernel panic на Flickr

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое «Паника ядра» в других словарях:

The Gray Screen of Panic and Disarray — Kernel panic (англ. букв.: паника ядра) сообщение о критической ошибке ядра операционной системы, после которой операционная система не может продолжать дальнейшую работу. Обычно этот термин применяется в среде операционных систем типа Kernel… … Википедия

Kernel panic — Linux 2.6 не может смонтировать корневую файловую систему. Kernel panic (англ.: тревога, сбой в ядре) сообщение о критической о … Википедия

Ядерный взрыв — … Википедия

Падение Константинополя (1453) — У этого термина существуют и другие значения, см. Падение Константинополя (значения). Падение Константинополя Турецко византийские войны … Википедия

Дьявол из Джерси — Об одноимённом эпизоде «Секретных материалов» см. Дьявол из Джерси (Секретные материалы) … Википедия

Дьявол из Джерси (мифическое существо) — Рисунок дьявола из Джерси в газете Philadelphia Post 1909 года. Дьявол из Джерси легендарное существо (возможно, криптид), якобы живущее в степях Pine Barrens на юге американского штата Нью Джерси. Легенда о существе оказала огромное… … Википедия

Страх — У этого термина существуют и другие значения, см. Страх (значения). В Викисловаре есть статья «страх» … Википедия

Кокаин — Кокаин … Википедия

Банковская система — (Banking System) Банковская система это совокупность действующих в стране банков, кредитных учреждений и отдельных экономических организаций, которые действуют по единым правилам денежно кредитной политики страны Определение банковской системы,… … Энциклопедия инвестора

НАПОЛЕОН I — Французский император из династии Бонапартов, правивший в 1804 1814,1815 гг. Король Италии в 1805 1814 гг. Сын Карло Буонапарте и Летиции Рамолино. Ж.: 1) с 1796 г. Жозефина, урожденная Ташер де ла Пажери, вдова виконта Александра Богарнэ (род.… … Все монархи мира

Источник

Определение причины паники ядра Linux

Я использую производную Ubuntu 12.04 (amd64), и у меня недавно были действительно странные проблемы. По всей видимости, внезапно X на некоторое время полностью замерзнет (1-3 минуты?), А затем система перезагрузится. Эта система разогнана, но очень стабильна, как проверено в Windows, что наводит меня на мысль, что у меня паника ядра или проблема с одним из моих модулей. Даже в Linux я могу запустить LINPACK и не увидеть сбоя, несмотря на то, что нагрузка на процессор оказывается нелепой. Кажется, что аварии случаются в случайные моменты времени, даже когда машина бездействует.

Как я могу отладить то, что сбивает систему?

Предполагая, что это может быть проприетарный драйвер NVIDIA, я полностью вернулся к стабильной версии драйвера, версии 304, и до сих пор испытываю сбой.

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

Вот куча бревен, обычные преступники.

Я даже не могу найти запись об аварии вообще.

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

Процессор разогнан до частоты 4,8 ГГц, но он полностью стабилен и пережил огромные циклы LINPACK и 9 часов Prime95 вчера без единого сбоя.

Обновить

Я установил kdump , crash и linux-crashdump , а также символы отладки ядра для моего ядра версии 3.2.0-35. Когда я запускаю apport-unpack файл с разбитым ядром, а затем crash на VmCore аварийный дамп, вот что я вижу:

Когда я запускаю log из crash утилиты, я вижу это в нижней части журнала:

bt выводит обратную трассировку:

У меня есть два предложения для начала.

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

Второй — получить данные об ошибках, которые, как вы заметили, не попадают ни в одно из мест, которые вы упомянули. Если сбой происходит только во время работы X11, я думаю, что локальная консоль практически отсутствует (в любом случае, это боль), поэтому вам нужно сделать это через последовательную консоль, по сети или путем сохранения на локальный диск (что сложнее, чем это может звучать, потому что вы не хотите, чтобы ненадежное ядро ​​повредило вашу файловую систему). Вот несколько способов сделать это:

• используйте netdump для сохранения на сервере по сети. Я не делал этого годами, поэтому я не уверен, что это программное обеспечение все еще работает и работает с современными ядрами, но это достаточно просто, чтобы его попробовать.
• загрузка с использованием последовательной консоли ; вам понадобится свободный последовательный порт на обеих машинах (будь то старая школа или последовательный USB-адаптер) и нуль-модемный кабель; Вы должны настроить другую машину, чтобы сохранить вывод.
• Кажется, kdump — это то, что крутые ребята используют в наше время, и он выглядит довольно гибким, хотя я бы не стал его предпочитать, потому что он выглядит сложным в настройке. Короче говоря, это включает в себя загрузку другого ядра, которое может делать все что угодно и проверять содержимое памяти прежнего ядра, но вы должны по существу собрать весь процесс, и я не вижу большого количества готовых вариантов там. Обновление: на самом деле есть несколько хороших дистрибутивов; на Ubuntu, linux-crashdump

Как только вы получите отладочную информацию, есть инструмент под названием ksymoops, который вы можете использовать, чтобы превратить адреса в имена символов и начать понимать, как работает ваше ядро. И если символический дамп ничего не значит для вас, по крайней мере, об этом полезно сообщить здесь или, возможно, в списке рассылки / отслеживателе ошибок вашего дистрибутива Linux.

От crash на вашем crashdump, вы можете попробовать печатать log и bt получить немного больше информации (то регистрируется во время паники и стека трассировки). Вы , Fatal Machine check кажется, приходит от сюда , хотя. После сканирования кода ваш процессор сообщил об исключении проверки компьютера — аппаратная проблема. Опять же, моя первая ставка будет из-за разгона. Кажется, что в log выводе может быть более конкретное сообщение, которое может рассказать вам больше.

Также из этого кода, похоже, что если вы загрузитесь с mce=3 параметром ядра, он перестанет падать . но я бы не рекомендовал это, кроме как в качестве диагностического шага. Если ядро ​​Linux считает, что эта ошибка заслуживает сбоя, возможно, это правильно.

Источник

Kdump — диагностика и анализ причин сбоев ядра

Хотя в современных Linux-системах ядро отличается достаточно высоким уровнем стабильности, вероятность серьезных системных ошибок, тем не менее, имеется всегда. Когда происходит неисправимая ошибка, имеет место состояние, называемое паникой ядра (kernel panic): стандартный обработчик выводит на экран информацию, которая должна помочь в устранении неисправности, и входит в бесконечный цикл.

Для диагностики и анализа причин сбоев ядра разработчиками компании RedHat был разработан специализированный инструмент — kdump. Принцип его работы можно кратко описать следующим образом. Создается два ядра: основное и аварийное (именно оно используется для сбора дампа памяти). При загрузке основного ядра под аварийное ядро выделяется определенный размер памяти. При помощи kexec во время паники основного ядра загружается аварийное и собирает дамп.

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

Установка и настройка kdump

Установим kdump с помощью команды

Настройки kdump хранятся в конфигурационном файле /etc/default/kdump-tools

Чтобы активировать kdump, отредактируем этот файл и установим значение параметра USE_KDUMP=1.
Также в конфигурационном файле содержатся следующие параметры:

• KDUMP_KERNEL — полный путь к аварийному ядру;
• KDUMP_INITRD — полный путь к initrd аварийного ядра;
• KDUMP_CORE — указывает, где будет сохранен файл дампа ядра. По умолчанию дамп сохраняется в директории /var/crash (KDUMP_CORE=/var/crash);
• KDUMP_FAIL_CMD — указывает, какое действие нужно совершить в случае ошибки при сохранении дампа (по умолчанию будет выполнена команда reboot -f);
• DEBUG_KERNEL — отладочная версия работающего ядра. По умолчанию используются /usr/lib/debug/vmlinux-$. Если значение этого параметра не установлено, утилита makedumpfile создаст только дамп всех страниц памяти;
• MAKEDUMP_ARGS — содержит дополнительные аргументы, передаваемые утилите makedumpfile. По умолчанию этот параметр имеет значение ‘-c -d 31’, указывающую, что необходимо использовать сжатие и включать в дамп только используемые страницы ядра.

Установив все необходимые параметры, выполним команду update-grub и выберем install the package maintainer’s version.

Затем перезагрузим систему и убедимся в том, что kdump готов к работе:

Обратим особое внимание на параметр crashkernel=384 -:128M. Он означает, что аварийное ядро будет использовать 128 Мб памяти при загрузке. Можно прописать в grub параметр crashkernel = auto: в этом случае память под аварийное ядро будет выделяться автоматически.

Для того, чтобы мы могли анализировать дамп с помощью утилиты crash, нам понадобится также файл vmlinux, содержащий отладочную информацию:

По завершении установки еще раз проверим статус kdump:

Если kdump находится в рабочем состоянии, на консоль будет выведено следующее сообщение:

Тестируем kdump

Вызовем панику ядра при помощи следующих команд:

В результате их выполнения система «зависнет».

После этого в течение нескольких минут будет создан дамп, который будет доступен в директории /var/crash после перезагрузки.

Информацию о сбое ядра можно просмотреть с помощью утилиты crash:

На основе приведенного вывода мы можем заключить, что системному сбою предшествовало событие «Oops: 0002 [#1] SMP», произошедшее на CPU2 при выполнении команды tee.
Утилита crash обладает также широким спектром возможностей для диагностики причин краха ядра. Рассмотрим их более подробно.

Диагностика причин сбоя с помощью утилиты crash

Crash сохраняет информацию обо всех системных событиях, предшествовавших краху ядра. С ее помощью можно воссоздать состояние системы на момент сбоя: узнать, какие процессы были запущены на момент краха, какие файлы открыты и т.п. Эта информация помогает поставить точный диагноз и предупредить крахи ядра в будущем.

В утилите crash имеется свой набор команд:

Для каждой этой команды можно вызвать краткий мануал, например:

Все команды мы описывать не будем (с детальной информацией можно ознакомиться в официальном руководстве пользователя от компании RedHat), а расскажем лишь о наиболее важных из них.

В первую очередь следует обратить внимание на команду bt (аббревиатура от backtrace — обратная трассировка). С ее помощью можно посмотреть детальную информацию о содержании памяти ядра (подробности и примеры использования см. здесь). Однако во многих случаях для определения причины системного сбоя бывает вполне достаточно команды log, выводящее на экран содержимое буфера сообщений ядра в хронологическом порядке.

Приведем фрагмент ее вывода:

В одной из строк вывода будет указано событие, вызвавшее системную ошибку:

С помощью команды ps можно вывести на экран список процессов, которые были запущены на момент сбоя:

Для просмотра информации об использовании виртуальной памяти используется команда vm:

Команда swap выведет на консоль информацию об использовании области подкачки:

Информацию о прерываниях CPU можно просмотреть с помощью команды irq:

Вывести на консоль список файлов, открытых на момент сбоя, можно с помощью команды files:

Наконец, получить в сжатом виде информацию об общем состоянии системы можно с помощью команды sys:

Заключение

Анализ и диагностика причин падения ядра представляет собой очень специфическую и сложную тему, которую невозможно уместить в рамки одной статьи. Мы еще вернемся к ней в следующих публикациях.

Читателей, которые не могут оставлять комментарии здесь, приглашаем к нам в блог.

Источник