Паника ядра
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] :
panic
Обработка Kernel panic
В нормальном случае при возникновении Kernel panic происходит остановка работы операционной системы с выдачей сообщений об ошибках на экран, после чего система ожидает выключения компьютера или перезагрузки. Однако, такая обработка этого события неприемлема тогда, когда простой компьютера крайне нежелателен или человека нет рядом (например на удалённых серверах или в нерабочее время).
В современных операционных системах, таких как GNU/Linux, Solaris, существует возможность изменить стандартное поведение функции panic() и производить перезагрузку компьютера автоматически. В GNU/Linux данная настройка осуществляется при помощи
/proc/sys/kernel/panic
Чтобы изменения действовали в GNU/Linux и после перезагрузки, необходимо добавить в файл /etc/sysctl.conf строку:
kernel.А в /etc/sysctl.conf :
ddb.В обоих примерах «5» — количество секунд, после которых произойдёт перезагрузка. При установке отрицательного или равного 0 значения этого параметра, автоматической перезагрузки не произойдёт. [4]
options PANIC_REBOOT_WAIT_TIME=В Solaris автоматическая перезагрузка после Kernel panic является стандартным поведением системы. [6]
Перезагрузка после Kernel panic имеет и очень серьёзный недостаток, особенно если это изменение не пропадает после первой перезагрузки. В случае, если перезагрузка не устраняет ту ошибку, которая вызывает Kernel panic, система будет останавливаться и перезапускаться вновь и вновь, что может привести к аппаратным ошибкам или потерям данных.
Для изучения причины паники ядра Linux может пригодится файл Windows XP при возниковении ошибки компьютер перезагружается автоматически. Это поведение системы управляется через Панель управления Windows. Если ошибка происходит при загурзке ОС, изменить поведение системы можно через меню кнопки F8.
Kernel panic в различных операционных системах
Kernel panic в Mac OS X
Изначально сообщение о 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 (на телефонах
Примечания
- ↑Unix and Multics
- ↑Причины для Kernel panic в Mac OS X
- ↑Исходный код prf.c UNIX V6
- ↑TIP Kernel Panic Reboot
- ↑OpenBSD SYSCTL.CONF man page
- ↑Device Driver Testing Tips (Solaris)
Почему в Linux может возникнуть паника ядра?
Как вы хорошо знаете, паника ядра (паника ядра) — это сообщение об ошибке, которое отображается ядром Unix-подобной операционной системы, когда что-то произошло, что не может быть восстановлено. Обычно эти сообщения содержат отладочную информацию, которая может быть полезна, чтобы узнать, откуда взялась проблема, и что разработчики могут решить эти проблемы.
Если вы из мира Microsoft Windows, это эквивалент знаменитого BSoD (Синий экран смерти), то есть те знаменитые синие экраны, которые иногда случаются в этих операционных системах, когда что-то идет не так. Только в средах * nix они известны как паника ядра .
Хотя многие хорошо знают, что такое паника ядра, и даже пострадали от некоторых из них в какой-то момент, не все знают все возможные причины почему вы можете создать его на ядре Linux вашего любимого дистрибутива. А может, кто-то не знает всех возможных причин .
Чтобы вы знали мотивыВот список наиболее частых причин возникновения паники ядра:
- Они могут возникнуть, когда Образ initramfs поврежден. Эта система, используемая во время загрузки, жизненно важна для запуска и, если с ней что-то случится, может вызвать панику ядра.
- Это также может произойти, когда initramfs был создан неправильно для конкретного ядра. Имейте в виду, что для каждой версии ядра нужны собственные файлы initramfs. Если это не так, вы можете получить панику ядра.
- Другой причиной могло быть то, что ядро неправильно установлено или не поддерживается.
- Если ничего из вышеперечисленного не произойдет, вы также можете получить панику ядра из-за патчи или обновления недавние, в которых есть какая-то неисправность.
- Другая возможность — когда модуль Он был установлен из сети или из другого источника, но образ initrd не был правильно создан с этим установленным модулем.
- Когда вы хотите прочитать неверный или недопустимый адрес памяти. Какими бы ни были причины .
- Un аппаратная проблема это также могло вызвать панику ядра. Или если отсутствует модуль или драйвер, необходимый для определенных основных компонентов.
- Определенные действия по эксплуатации уязвимости драйверы ядра или их драйверы также могут создавать его, нарушая целостность системы.
Содержание статьи соответствует нашим принципам редакционная этика. Чтобы сообщить об ошибке, нажмите здесь.
Полный путь к статье: Любители Linux » GNU / Linux » ядро » Почему в Linux может возникнуть паника ядра?
3 комментариев, оставьте свой
Оставьте свой комментарий Отменить ответ
Карлос Фонсека сказал
тому назад 3 лет
Несколько раз я видел это из-за аппаратного сбоя.
прокатка сказал
тому назад 3 лет
Поскольку я использую Linux в 2014 году, у меня никогда не было паники ядра, и что как только вышло новое ядро, я установил его на свой Ubuntu 14.04, который у меня был в то время.
Дуард сказал
тому назад 3 лет
Я только помню, как в далекие дни у меня была проблема с ядром, когда я перекомпилировал ядро, чтобы попытаться немного повысить производительность своего компьютера. Еще в начале 2000-х. С тех пор никаких проблем.
Kernel (Русский)
Состояние перевода: На этой странице представлен перевод статьи Kernel. Дата последней синхронизации: 10 июля 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.
Ядро Linux — ядро операционной системы, соответствующее стандартам POSIX, составляющее основу операционных систем семейства Linux.
Дистрибутив Arch Linux основан на ядре Linux. Помимо основной стабильной (stable) версии в Arch Linux можно использовать некоторые альтернативные ядра. В статье описываются доступные в официальных репозиториях версии ядер, возможные патчи, а также способы, которыми пользователи могут скомпилировать собственное ядро.
Пакет ядра устанавливается в файловую систему в каталоге /boot/ . Для загрузки нужного ядра при запуске системы необходимо соответствующим образом настроить загрузчик.
Официальные ядра
Помощь при работе с официальными ядрами можно найти на форуме и в баг-трекере.
- Stable — «ванильное» ядро Linux с модулями и некоторыми патчами.
- Hardened — ориентированное на безопасность ядро Linux с набором патчей, защищающих от эксплойтов ядра и пространства пользователя. Содержит больше защитных особенностей, чем linux .
- Longterm — ядро и модули с долгосрочной поддержкой (Long Term Support, LTS).
- Zen Kernel — результат коллективных усилий исследователей с целью создать лучшее из возможных ядер Linux для систем общего назначения. Подробности проекта можно найти на сайте liquorix.net (там же можно скачать двоичные файлы Zen-ядра для Debian).
Компиляция
Скомпилировать собственное ядро можно двумя способами:
/Arch Build System Преимущества — наличие готового PKGBUILD для пакета linux и удобство системы управления пакетами. /Традиционная компиляция Ручная загрузка архива файлов с исходными кодами ядра и их компиляция.
- Нестандартное ядро чревато всевозможными проблемами в плане надёжности и стабильности работы, поэтому настоятельно рекомендуется использовать резервное копирование.
- Arch Linux поддерживает только #Официальные ядра. Если вы работаете с другим ядром, то не забывайте упоминать это в запросах в поддержку.
- Лучший способ повысить производительность — адаптировать ядро под свою систему, в первую очередь под архитектуру и тип процессора.
- Если оставить в ядре только действительно нужные вам функции, то удастся уменьшить его размер и, следовательно, время сборки. Например, удалите из него Bluetooth, Video4Linux, 1000Mbit Ethernet и прочие вещи, которые на вашей машине точно не понадобятся.
Файлы конфигурации пакетов с ядрами Arch можно найти в исходниках (например, файл [1] из linux ). Если включена опция ядра CONFIG_IKCONFIG_PROC , то файл /proc/config.gz содержит настройки ядра, которое работает на вашей машине в данный момент.
Некоторые из перечисленных пакетов могут быть также доступны в двоичном виде в неофициальных репозиториях.
Ядра kernel.org
- Git — ядро Linux, собранное из файлов с исходным кодом из git-репозитория Линуса Торвальдса.
- Mainline — ядра, в которых появляются все нововведения. Выходят каждые 2-3 месяца.
- Next — самые новейшие ядра, с улучшениями, которые будут добавлены в следующий mainline-выпуск.
- Longterm 4.14 — LTS-ядро версии 4.14.
- Longterm 4.19 — LTS-ядро версии 4.19.
- Longterm 5.4 — LTS-ядро версии 5.4.
- Longterm 5.10 — LTS-ядро версии 5.10.
- Longterm 5.15 — LTS-ядро версии 5.15.
Неофициальные ядра
- Ck — патч от Con Kolivas, повышение быстродействия для настольных систем с любым типом нагрузки.
- Clear — патчи проекта Clear Linux от Intel. Содержит улучшения производительности и безопасности.
- GalliumOS — ядро Linux с патчами GalliumOS для Хромбуков.
- Libre — без проприетарных или обфусцированных драйверов устройств.
- Liquorix — ядро, собранное из исходного кода Zen с настройками для Debian. Разработан для настольных, мультимедийных и игровых систем, часто используется в качестве замены основному ядру Debian. Создатель патча Liquorix, Damentz, также является разработчиком набора патчей Zen.
- pf-kernel — набор неплохих улучшений, не вошедших в mainline. Сопровождается разработчиком ядра. Предоставляет порты улучшений для новых версий ядра, если они не были выпущены официально. Наиболее важные нововведения — UKSM.
- Репозиторий, linux-pfAUR от разработчика pf-kernel, post-factum.
- Realtime kernel — поддерживается небольшой группой разработчиков, возглавляемой Ingo Molnar. Патч позволяет применять kernel preemption практически ко всему ядру за исключением небольших участков кода («raw_spinlock critical regions»). Этого удалось добиться за счёт замены большинства спинлоков ядра на мьютексы с поддержкой наследования приоритета, а также перемещением всех прерываний (в том числе и программных) в потоки ядра.
- Tkg — ядро с набором патчей для планировщиков PDS и Project C / BMQ. Стандартный планировщик CFS также доступен. Изменения нацелены на улучшение баланса интерактивность/производительность в играх. Автор и сопроводитель — Etienne Juvigny (Tk-Glitch).
- VFIO — патч ядра от Alex Williamson с поддержкой PCI Passthrough для KVM на некоторых машинах.
- XanMod — улучшение производительности ядер рабочих станций, игровых компьютеров, медиацентров и других систем. Включает планировщик MuQSS, планировщик ввода-вывода BFQ, алгоритм дедупликации памяти в реальном времени UKSM, алгоритм управления перегрузками TCP BBR, расширенный набор команд для архитектуры x86_64 и другие изменения.
Решение проблем
Паника ядра
Паника ядра (kernel panic) возникает, когда ядро Linux попадает в состояние невосстановимого сбоя. Это состояние обычно возникает из-за ошибок в драйверах оборудования, в результате чего система попадает в deadlock, не реагирует на запросы и требует перезагрузки. Непосредственно перед deadlock генерируется диагностическое сообщение, состоящее из: состояния компьютера, когда произошел сбой, трассировки (call trace), ведущей к функции ядра, распознавшей сбой, и списка загруженных в данный момент модулей. К счастью, паники ядра случаются нечасто при использовании основных версий ядра — таких, которые поставляются из официальных репозиториев — но когда они случаются, необходимо знать, как с ними бороться.
Примечание: Паники ядра иногда называются oops или kernel oops. Хотя и то, и другое возникает в результате сбоя, oops является более общим явлением, поскольку не обязательно приводит к deadlock — иногда ядро может восстановиться после oops, убив проблемную задачу и продолжив работу.
Совет: Передайте параметр ядра oops=panic при загрузке или запишите 1 в /proc/sys/kernel/panic_on_oops , чтобы заставить восстановимый oops выдавать панику. Это рекомендуется сделать, если вас волнует небольшая вероятность получения нестабильной системы после восстановления из oops, что может затруднить диагностику будущих ошибок.
Изучение сообщения паники
Если паника ядра происходит очень рано в процессе загрузки, вы можете увидеть в консоли сообщение «Kernel panic — not syncing:», но после запуска systemd сообщения ядра обычно перехватываются и записываются в системный журнал. Однако, когда возникает паника, диагностическое сообщение, выдаваемое ядром, почти никогда не записывается в файл журнала на диске, потому что компьютер попадает в deadlock до того, как system-journald получит шанс записать журнал. Поэтому единственный способ просмотреть сообщение о панике — это просмотреть его на консоли в момент возникновения (не прибегая к установке kdump crashkernel). Вы можете сделать это, загрузившись со следующими параметрами ядра и попытавшись воспроизвести панику на tty1:
systemd.journald.forward_to_console=1 console=tty1
Совет: Если сообщение о панике прокручивается слишком быстро, попробуйте передать параметр ядра pause_on_oops=секунды при загрузке.
Пример сценария: плохой модуль
Можно сделать предположение о том, какая подсистема или модуль вызывает панику, используя информацию в диагностическом сообщении. В этом сценарии мы имеем панику на некотором воображаемом компьютере во время загрузки. Обратите внимание на строки, выделенные жирным:
kernel: BUG: unable to handle kernel NULL pointer dereference at (null) [1] kernel: IP: fw_core_init+0x18/0x1000 [firewire_core] [2] kernel: PGD 718d00067 kernel: P4D 718d00067 kernel: PUD 7b3611067 kernel: PMD 0 kernel: kernel: Oops: 0002 [#1] PREEMPT SMP kernel: Modules linked in: firewire_core(+) crc_itu_t cfg80211 rfkill ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_ipv4 . [3] kernel: CPU: 6 PID: 1438 Comm: modprobe Tainted: P O 4.13.3-1-ARCH #1 kernel: Hardware name: Gigabyte Technology Co., Ltd. H97-D3H/H97-D3H-CF, BIOS F5 06/26/2014 kernel: task: ffff9c667abd9e00 task.stack: ffffb53b8db34000 kernel: RIP: 0010:fw_core_init+0x18/0x1000 [firewire_core] kernel: RSP: 0018:ffffb53b8db37c68 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 kernel: RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffffc16d3af4 kernel: RBP: ffffb53b8db37c70 R08: 0000000000000000 R09: ffffffffae113e95 kernel: R10: ffffe93edfdb9680 R11: 0000000000000000 R12: ffffffffc16d9000 kernel: R13: ffff9c6729bf8f60 R14: ffffffffc16d5710 R15: ffff9c6736e55840 kernel: FS: 00007f301fc80b80(0000) GS:ffff9c675dd80000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000000 CR3: 00000007c6456000 CR4: 00000000001406e0 kernel: Call Trace: kernel: do_one_initcall+0x50/0x190 [4] kernel: ? do_init_module+0x27/0x1f2 kernel: do_init_module+0x5f/0x1f2 kernel: load_module+0x23f3/0x2be0 kernel: SYSC_init_module+0x16b/0x1a0 kernel: ? SYSC_init_module+0x16b/0x1a0 kernel: SyS_init_module+0xe/0x10 kernel: entry_SYSCALL_64_fastpath+0x1a/0xa5 kernel: RIP: 0033:0x7f301f3a2a0a kernel: RSP: 002b:00007ffcabbd1998 EFLAGS: 00000246 ORIG_RAX: 00000000000000af kernel: RAX: ffffffffffffffda RBX: 0000000000c85a48 RCX: 00007f301f3a2a0a kernel: RDX: 000000000041aada RSI: 000000000001a738 RDI: 00007f301e7eb010 kernel: RBP: 0000000000c8a520 R08: 0000000000000001 R09: 0000000000000085 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000c79208 kernel: R13: 0000000000c8b4d8 R14: 00007f301e7fffff R15: 0000000000000030 kernel: Code: 04 25 00 00 00 00 01 00 00 00 bb f4 ff ff ff e8 73 43 9c ec 48 kernel: RIP: fw_core_init+0x18/0x1000 [firewire_core] RSP: ffffb53b8db37c68 kernel: CR2: 0000000000000000 kernel: ---[ end trace 71f4306ea1238f17 ]--- kernel: Kernel panic - not syncing: Fatal exception [5] kernel: Kernel Offset: 0x80000000 from 0xffffffff810000000 (relocation range: 0xffffffff800000000-0xfffffffffbffffffff kernel: ---[ end Kernel panic - not syncing: Fatal exception
- [1] Указывает тип ошибки, вызвавшей панику. В данном случае это была ошибка программиста.
- [2] Указывает, что паника произошла в функции под названием fw_core_init в модуле firewire_core.
- [3] Указывает, что firewire_core был последним загруженным модулем.
- [4] Указывает, что функция, вызвавшая функцию fw_core_init, была do_one_initcall.
- [5] Указывает на то, что это сообщение oops на самом деле является паникой ядра, и система ушла в deadlock.
Мы можем предположить, что паника произошла во время инициализации модуля firewire_core при его загрузке. (Тогда можно предположить, что аппаратное обеспечение компьютера несовместимо с данной версией модуля драйвера firewire из-за ошибки программиста, и придётся ждать новой версии). Тем временем, самый простой способ заставить компьютер снова работать — это предотвратить загрузку проблемного модуля. Это можно сделать одним из двух способов:
- Если модуль загружается в процессе работы initramfs, перезагрузитесь с параметром ядра rd.blacklist=firewire_core .
- Иначе перезагрузитесь с параметром ядра module_blacklist=firewire_core .
Отладка регрессий
Прежде всего проверьте ядро linux-mainline AUR на предмет того, не была ли проблема уже решена. В прикреплённом комментарии указан репозиторий с уже собранными ядрами, так что собирать ядро вручную не придётся.
Если проблема проявляется не слишком часто, то имеет смысл попробовать LTS-ядро ( linux-lts ). Старые версии LTS-ядер можно найти в архиве Arch Linux.
Если избавиться от проблемы не удалось, попробуйте локализовать баг в linux-git AUR , после чего сообщите о нём в баг-трекер ядра. Важно проверять ванильное непропатченное ядро, чтобы убедиться, что причиной ошибки является не патч. Если проблемы вызывает патч, то сообщите об этом его автору.
Примечание: Локализация местонахождения бага в коде может занять много времени, поскольку придётся многократно пересобирать ядро.
Смотрите также
- O’Reilly — Linux Kernel in a Nutshell — электронная книга «Ядро Linux в двух словах».
- Какую из stable-версий ядра лучше использовать? от Greg Kroah-Hartman.
- Документация ядра Linux
Паника ядра — Kernel panic
Сообщение о панике ядра из системы Linux 
Паника ядра в Ubuntu 13.04 (Linux 3.8) в Oracle VM VirtualBox
A kernel panic (иногда сокращенно KP ) — это мера безопасности, принимаемая ядром операционной системы при обнаружении внутренняя фатальная ошибка, при которой невозможно безопасное восстановление или система не может продолжать работать без гораздо более высокого риска серьезной потери данных. Этот термин в основном характерен для Unix и Unix-подобных систем. Для операционных систем Microsoft Windows эквивалентным термином является «Stop error », что приводит к появлению экрана проверки ошибок, на котором код проверки ошибок отображается на синем фоне в ранних версиях Windows (в просторечии известный как «Синий экран смерти » или BSoD) или на зеленом фоне на платформе Xbox One, а также в предварительных сборках Windows 10.
Подпрограммы ядра , которые обрабатывают паники, известные как panic () в ATT -предполагаемом и BSD исходном коде Unix кода, обычно предназначены для вывода сообщения об ошибке в консоль, выгрузки образа памяти ядра на диск для посмертной отладки, а затем либо ожидания для перезагрузки системы вручную или инициировать автоматическую перезагрузку. Предоставленная информация носит сугубо технический характер и призвана помочь системному администратору или разработчику программного обеспечения в диагностике проблемы. Паника ядра также может быть вызвана ошибками, происходящими вне пространства ядра. Например, во многих операционных системах Unix происходит паника, если процесс init, который выполняется в пользовательском пространстве, завершается.
- 1 История
- 2 Причины
- 3 Особенности операционной системы
- 3.1 Linux
- 3.2 macOS
История
Ядро Unix поддерживает внутреннюю согласованность и корректность времени выполнения с утверждениями в качестве механизма обнаружения ошибок. Основное предположение состоит в том, что оборудование и программное обеспечение должны работать правильно, а сбой утверждения приводит к панике, то есть к добровольной остановке всей активности системы. Паника ядра была введена в ранней версии Unix и продемонстрировала существенное различие между философией проектирования Unix и ее предшественником Multics. Разработчик Multics Том ван Влек вспоминает обсуждение этого изменения с разработчиком Unix Деннисом Ритчи :
Я заметил Деннису, что половина кода, который я писал в Multics, составляла код восстановления после ошибок. Он сказал: «Мы оставили все это. Если есть ошибка, у нас есть такая процедура, которая называется паника, и когда она вызывается, машина вылетает, и вы кричите по коридору:« Эй, перезагрузите ее »».
Исходная функция panic () практически не изменилась с пятой редакции UNIX на UNIX 32V на основе VAX и выводила только сообщение об ошибке без другой информации, а затем отбрасывала систему в бесконечный цикл холостого хода.
Исходный код функции panic () в V6 UNIX :
/ * * Если консоль выключена, * panicstr содержит аргумент для последнего * вызова паники. * / char * panicstr; / * * Паника вызывается при * неустранимых фатальных ошибках. * Он синхронизирует, печатает «panic: mesg» и * затем зацикливается. * / panic (s) char * s;
Поскольку кодовая база Unix была расширена, функция panic () также была расширена для вывода на консоль различных форм отладочной информации.
Причины
Паника может возникнуть в результате аппаратного сбоя или ошибки программного обеспечения в операционной системе. Во многих случаях операционная система способна продолжить работу после возникновения ошибки. Однако система находится в нестабильном состоянии, и вместо того, чтобы рисковать нарушениями безопасности и повреждением данных, операционная система останавливается, чтобы предотвратить дальнейшее повреждение и облегчить диагностику ошибки, и, в обычных случаях, перезапускается.
После перекомпиляции двоичный образ ядра из исходного кода, паника ядра при загрузке результирующего ядра является общей проблемой, если ядро было неправильно настроено, скомпилировано или установлено. Дополнительное оборудование или неисправность RAM также могут быть источниками фатальных ошибок ядра во время запуска из-за несовместимости с ОС или отсутствия драйвера устройства. Ядро также может перейти в panic () , если оно не может найти корневую файловую систему. На заключительных этапах инициализации ядра пользовательского пространства обычно запускается паника, если не удается создать init. Также может возникнуть паника, если процесс инициализации завершится, поскольку в этом случае система станет непригодной для использования.
Ниже представлена реализация финальной инициализации ядра Linux в kernel_init () :
static int __ref kernel_init (void * unused) if (! run_init_process ("/ sbin / init") ||! run_init_process ("/ etc / init") ||! run_init_process ("/ bin / init") ||! run_init_process ("/ bin / sh")) возврат 0; panic («Не найдено ни одного файла инициализации. Попробуйте передать параметр init = ядру.» «См. документацию Linux / init.txt для руководства.»); >Особенности операционной системы
Linux
Паника ядра в консоли iKVM
Паника ядра появляется в Linux, как и в других Unix-подобных, но они также могут генерировать другой вид состояния ошибки, известный как ядро oops. В этом случае ядро обычно продолжает работать после убийства вызывающего нарушение процесса процесса. Поскольку ошибка может привести к недоступности некоторых подсистем или ресурсов, позже они могут привести к полной панике ядра.
В Linux из-за паники ядра индикаторы клавиатуры мигают как визуальное указание критического состояния.
macOS
Когда паника ядра происходит в Mac OS X 10.2–10.7, компьютер отображает многоязычное сообщение, информирующее пользователя о необходимости перезагрузки системы. До версии 10.2 отображалось более традиционное сообщение о панике в стиле Unix; в 10.8 и более поздних версиях компьютер автоматически перезагружается, и после перезагрузки отображается сообщение. Формат сообщения варьируется от версии к версии:
- 10.0–10.1: система отображает на экране текст с подробными сведениями об ошибке и перестает отвечать.
- 10.2: опускается черная прозрачная занавеска затем отображает сообщение на белом фоне, информирующее пользователя о том, что он должен перезагрузить компьютер. Сообщение отображается на английском, французском, немецком и японском.
- 10.3–10.5: паника ядра почти такая же, как и в версии 10.2. но фон экрана ошибки черный.
- 10.6–10.7-10.8: текст был изменен и теперь включает перевод на испанский.
- 10.9 и более поздние версии: Компьютер перестает отвечать и сразу же перезагружается. Когда компьютер запускается из резервной копии, он показывает предупреждающее сообщение в течение нескольких секунд о перезагрузке компьютера из-за паники ядра, а затем компьютер перезагружается. Теперь сообщение содержит перевод на китайский.
Иногда, когда в течение трех минут после первой аварии ядра возникает пять или более, Mac отображает запрещающий знак в течение 30 секунд., а затем завершите работу (это известно как «повторяющаяся паника ядра»).
Во всех версиях выше 10.2 текст накладывается на символ режима ожидания и не является полноэкранным. Информация об отладке сохраняется в NVRAM и записывается в файл журнала при перезагрузке. В 10.7 есть функция автоматического перезапуска после паники ядра. В некоторых случаях в 10.2 и более поздних версиях помимо символа режима ожидания может отображаться белый текст с подробным описанием ошибки.
Паника ядра Mac OS X 10.0–10.1
Паника ядра Mac OS X 10.2
Паника ядра Mac OS X 10.3–10.5
Паника ядра Mac OS X 10.6 и 10.7
Отображаемое сообщение после перезагрузки компьютера из-за паники ядра в OS X 10.8 и более поздних версиях
См. также
На Викискладе есть носители, относящиеся к панике ядра.