Прежде всего, ваше ядро не падает . В случае сбоя ваша система полностью зависнет и вы не сможете ее использовать.
Есть несколько типов проблем, которые могут возникнуть в ядре.
Предупреждение (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?), Который не обнаруживает повторяющиеся проблемы и сбивает вас с одного и того же. над.
Итак, здесь есть несколько проблем:
Вы не дали мне никаких
dmesgжурналов, которые указывают на повторную проблему. То, что вы показали в ACPI, может быть причиной одной ошибки, но это произошло очень рано при загрузке, и это не происходит снова и снова.Инфраструктура сообщений об ошибках кажется сломанной. Я думаю, что на каком-то уровне он
abrtзнает, что это повторяющееся сообщение для одного и того же события (или последовательности независимых событий, идентичных по причине), но каким-то образом уведомления проходят через систему и в ваш пользовательский интерфейс в любом случае.Очевидно, это вопрос, который вы испытываете какое - то авария или OOPS или BUG или WARN, связанный с ядром Linux в первую очередь . Но так как журналы ядра, которые вы разместили, были минимальными и не особенно касающимися, корень проблемы кажется неуловимым прямо сейчас. Если это жалуется, что ACPI вопрос с начала загрузки, он должен действительно научиться заткнуться; Дело в том, что ACDI DSDT материнской платы почти всегда ужасно искажены и сломаны, и ОС просто нужно научиться справляться с этим как можно лучше. Вы ничего не можете с этим поделать как конечный пользователь. Не похоже, что ваш производитель mobo все еще будет выпускать обновления BIOS, чтобы попытаться улучшить свою корректность DSDT (ну, в любом случае, вряд ли они это сделают).
Или, возможно, проблема совершенно не связана с ACPI, а фактический отчет о проблеме просто не попадает в кольцевой буфер ядра. Это было бы довольно странно, и не то, что я испытал раньше. В этом отношении я не уверен, какой механизм abrtиспользует, чтобы обнаружить существование ошибки, если это не анализирует dmesg.
Когда дело доходит до проблем с ядром Linux и того, как они сообщаются в пользовательском интерфейсе, редко существует простой способ его диагностики. Это природа зверя.