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

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

• Предупреждение (WARN), ошибка (BUG) или OOPS могут возникать, когда встроенные самопроверки ядра обнаруживают ситуацию, которая может привести к нестабильности системы или потере данных в будущем. Однако, вообще говоря, эти проблемы не вызывают (немедленного) сбоя системы. Как правило, OOPS являются наиболее серьезными из них и приведут к тому, что любые связанные процессы пользовательского пространства получат SIGKILL ("ты умрешь", а не "пожалуйста, уходи") сигнал от ядра.

• Паника - это то, когда система настолько взвинчена, что отказывается продолжать. В этом случае ядро ​​просто прекращает выполнение (после печати трассировки стека, если оно в состоянии это сделать) и передает управление… ничего. Обычно. Хотя, если у вас есть аварийное ядро, иногда поврежденное ядро ​​будет пытаться загрузить второе ядро, целью которого является сбор информации о причине сбоя, и попытаться записать его на диск. В общем случае даже очень надежное аварийное ядро ​​не может полностью восстановить состояние системы, чтобы оно могло быть снова работоспособным и стабильным без перезагрузки.

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

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

Похоже, что в вашем случае вы, возможно, испытали однократную ошибку, которая неправильно обрабатывается abrt система уведомления о событиях аварии (или инфраструктура пользовательского интерфейса GNOME, которая отображает ее вам).

26 мая 16:39:30 segtic-1c505e gnome-session: abrt-applet: повторяющаяся проблема в ядре, не отображается уведомление

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

Итак, здесь есть несколько проблем:

1. Вы не дали мне ничего dmesg журналы, которые указывают на повторную проблему. То, что вы показали в ACPI, может быть причиной одной ошибки, но это произошло очень рано при загрузке, и это не происходит снова и снова.

2. Инфраструктура сообщений об ошибках кажется сломанной. Я думаю, на каком-то уровне, abrt знает, что это повторное сообщение для одного и того же события (или последовательности независимых событий, идентичных по причине), но каким-то образом уведомления проходят через систему и в ваш пользовательский интерфейс в любом случае.

3. Очевидно, это проблема, связанная с тем, что у вас возникли какие-то сбои, или OOPS, или BUG, ​​или WARN, связанные с ядром Linux. Но так как журналы ядра, которые вы разместили, были минимальными и не особенно касающимися, корень проблемы кажется неуловимым прямо сейчас. Если он жалуется на проблему ACPI при ранней загрузке, он должен действительно учиться заткнуться; Дело в том, что ACDI DSDT материнской платы почти всегда ужасно искажены и сломаны, и ОС просто нужно научиться справляться с этим как можно лучше. Вы ничего не можете с этим поделать как конечный пользователь. Это не значит, что ваш производитель mobo все еще будет выпускать обновления BIOS, чтобы попытаться улучшить свою корректность DSDT (ну, в любом случае, вряд ли они это сделают).

Или, возможно, проблема совершенно не связана с ACPI, а фактический отчет о проблеме просто не попадает в кольцевой буфер ядра. Это было бы довольно странно, и не то, что я испытал раньше. В этом отношении я не уверен, какой механизм abrt использует для обнаружения наличия ошибки, если она не анализируется dmesg,

Когда дело доходит до проблем с ядром Linux и того, как они сообщаются в пользовательском интерфейсе, редко существует простой способ его диагностики. Это природа зверя.