Kernel (Русский)

• Git — ядро Linux, собранное из файлов с исходным кодом из git-репозитория Линуса Торвальдса.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git || linux-git^AUR

• Longterm 4.9 — LTS-ядро версии 4.9.

https://www.kernel.org/ || linux-lts49^AUR

• Longterm 5.4 — LTS-ядро версии 5.4.

https://www.kernel.org/ || linux-lts54^AUR

• MultiPath TCP — ядро с поддержкой Multipath TCP.

https://multipath-tcp.org/ || linux-mptcp^AUR

• Репозиторий разработчика pf-kernel, post-factum.
• Репозиторий с пакетами и от создателя форка pf-kernel, Thaodan.
• от yurikoles

• Realtime kernel — поддерживается небольшой группой разработчиков, возглавляемой Ingo Molnar. Патч позволяет применять kernel preemption практически ко всему ядру за исключением небольших участков кода ("raw_spinlock critical regions"). Этого удалось добиться за счёт замены большинства спинлоков ядра на мьютексы с поддержкой наследования приоритета, а также перемещением всех прерываний (в том числе и программных) в потоки ядра.

https://wiki.linuxfoundation.org/realtime/start || linux-rt^AUR, linux-rt-lts^AUR

Паника ядра (kernel panic) возникает, когда ядро Linux попадает в состояние невосстановимого сбоя. Это состояние обычно возникает из-за ошибок в драйверах оборудования, в результате чего система попадает в deadlock, не реагирует на запросы и требует перезагрузки. Непосредственно перед deadlock генерируется диагностическое сообщение, состоящее из: состояния компьютера, когда произошел сбой, трассировки (call trace), ведущей к функции ядра, распознавшей сбой, и списка загруженных в данный момент модулей. К счастью, паники ядра случаются нечасто при использовании основных версий ядра — таких, которые поставляются из официальных репозиториев — но когда они случаются, необходимо знать, как с ними бороться.

Если паника ядра происходит очень рано в процессе загрузки, вы можете увидеть в консоли сообщение "Kernel panic - not syncing:", но после запуска systemd сообщения ядра обычно перехватываются и записываются в системный журнал. Однако, когда возникает паника, диагностическое сообщение, выдаваемое ядром, почти никогда не записывается в файл журнала на диске, потому что компьютер попадает в deadlock до того, как получит шанс записать журнал. Поэтому единственный способ просмотреть сообщение о панике — это просмотреть его на консоли в момент возникновения (не прибегая к установке kdump crashkernel). Вы можете сделать это, загрузившись со следующими параметрами ядра и попытавшись воспроизвести панику на tty1:

systemd.journald.forward_to_console=1 console=tty1

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

• [1] Указывает тип ошибки, вызвавшей панику. В данном случае это была ошибка программиста.
• [2] Указывает, что паника произошла в функции под названием fw_core_init в модуле firewire_core.
• [3] Указывает, что firewire_core был последним загруженным модулем.
• [4] Указывает, что функция, вызвавшая функцию fw_core_init, была do_one_initcall.
• [5] Указывает на то, что это сообщение oops на самом деле является паникой ядра, и система ушла в deadlock.

Мы можем предположить, что паника произошла во время инициализации модуля firewire_core при его загрузке. (Тогда можно предположить, что аппаратное обеспечение компьютера несовместимо с данной версией модуля драйвера firewire из-за ошибки программиста, и придётся ждать новой версии). Тем временем, самый простой способ заставить компьютер снова работать — это предотвратить загрузку проблемного модуля. Это можно сделать одним из двух способов:

• Если модуль загружается в процессе работы initramfs, перезагрузитесь с параметром ядра .
• Иначе перезагрузитесь с параметром ядра .

См. General troubleshooting#Debugging regressions.

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

Если проблема проявляется не слишком часто, то имеет смысл попробовать LTS-ядро (). Старые версии LTS-ядер можно найти в архиве Arch Linux.

Если избавиться от проблемы не удалось, попробуйте локализовать баг в linux-git^AUR, после чего сообщите о нём в баг-трекер ядра. Важно проверять ванильное непропатченное ядро, чтобы убедиться, что причиной ошибки является не патч. Если проблемы вызывает патч, то сообщите об этом его автору.