Аппаратное обеспечение (информация):

надеюсь это не аппаратная проблема...

    ОС: Убунту 21.10
    ЦП: ЦП Intel(R) Core(TM) i7-8550U с тактовой частотой 1,80 ГГц, 1 физический процессор; 4 ядра; 8 потоков
    Оперативная память: 7858608 КиБ (или 8 ГБ)
    Материнская плата: Lenovo YOGA 730-13IKB/LNVNB161216 (LENOVO)
    Графика: 1920x1080 (неизвестно) Фонд X.Org
    Хранилище: (по какой-то причине ничего не показывает, но я уже открыл свой компьютер, чтобы очистить его, чтобы решить эту проблему, и я подтвердил, что это твердотельный накопитель NVMe.
    Принтеры: (не имеет значения)
    Аудио: USB-аудио — USB-устройство 0x46d

Симптомы:

Что я презираю.

Теперь, после обновления с Ubuntu 20.04 LTS до Ubuntu 21.04, у меня возникли некоторые сбои, эти сбои:

• Не перезагружаться автоматически
• являются спонтанными
• Происходит ТОЛЬКО при подключении к сети переменного тока
• Нигде нет признаков логирования
• Пункт списка

Попытки:

Вещи, которые не сработали

Пробовал переустанавливать систему как минимум два раза (как-то забыл, но было два и более), обновляя с 21.04 до 21.10 в процессе.Также стоит отметить, что я выбирал, какие программы бэкапить, выбирая только те, которые были:

• Не устанавливается автоматически
• Не локальный (позже я мог бы сам переустановить эти дебы)
• Все не автоматические библиотеки разработки

Единственное заметное отличие от 21.04 и 21.10 в сбоях — нет (IIRC).

Другие вещи, которые я пробовал:

• Обновление BIOS
• Переустановка термический
• Отключение c-состояния (и включение их снова из-за того, что они не помогают)
• Пытался ядро журнала (не удалось настроить правильно, ручной краш не дал лога)
• Настраивать постоянный журнал (ничего полезного там не нашел, но могу выложить, если нужно)

Дополнительный

Некоторая дополнительная информация, которая может помочь

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

Личный журнал:

Когда я обновился до Ubuntu 21.04, все пошло не так.
Я предполагаю, что schedutil что-то делает, так как компьютер иногда дает сбой, нет журнала или чего-то еще.
Я проверил /var/log/kern.log среди прочих и ничего не нашел.

Я подозреваю, что это как-то связано с «P-состояниями» и «C-состояниями».
P-состояния, обозначающие состояния производительности, используются для оптимизации энергопотребления во время выполнения кода. Они могут быть изменены ОС для изменения напряжения ЦП (короче говоря, для изменения частоты ЦП).
C-состояния, с другой стороны, используются для оптимизации/снижения энергопотребления в режиме ожидания (когда код не выполняется).
Типичные C-состояния:
    C0 — ЦП активно выполняет код (P-состояния)
    C1 — ЦП использует инструкцию HLT в режиме ожидания, часы привязаны к частям ядра, но пробуждаются относительно быстро.
    C1E — на самом деле это просто C1, за исключением случаев, когда C1E включен, ЦП снижает скорость и напряжение ЦП, когда он находится в C1.
    C2 и выше — ЦП отключает различные части ядра для большей экономии энергии за счет того, что больше не просыпается.
Источник: «Управление использованием C-состояний процессора в Linux, технический документ Dell, описывающий использование C-состояний в операционных системах Linux».

В любом случае, все это все еще происходит сейчас, даже в 21.10, так что это должно быть проблемой ядра.
Хотя установка "intel_idle.max_cstate=0" не останавливает сбои, так что, возможно, это другая проблема.
Я уже использовал «memtest86», и моя система в порядке.
Я собираюсь перезагрузить свой компьютер и посмотреть, есть ли какие-либо настройки c-state в BIOS/UEFI (эти настройки все еще называются BIOS?).

Да я проверял, ничего не нашел.

PDF-файл Dell C-state (тот же, что и в источнике выше) имеет этот раздел прямо под разделом C-состояний (который является первым www) под названием «Проверка использования C-состояния». В нем говорится:
    Есть несколько способов узнать, сколько времени простоя тратится в различных C-состояниях. 
    Сначала проверьте сообщения ядра при загрузке (например, «dmesg |grep idle» или «grep idle /var/log/messages»), чтобы увидеть, какой драйвер ожидания используется.

Вот что я получил:
    sudo dmesg |grep бездействует
    [sudo] пароль для ws: 
    [ 0.028186] источник часов: уточненный-jiffies: маска: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 нс
    [0.076265] источник часов: hpet: маска: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635855245 нс
    [0.100211] источник часов: tsc-early: маска: 0xffffffffffffffffff max_cycles: 0x39a8208cdd2, max_idle_ns: 881590748921 нс
    [0.104538] процесс: использование mwait в бездействующих потоках
    [ 0.128722] источник часов: jiffies: маска: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 нс
    [ 0.132319] cpuidle: использование лестницы губернатора
    [0.132322] cpuidle: использование меню регулятора
    [0.389960] источник часов: acpi_pm: маска: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 нс
    [1.426615] источник часов: tsc: маска: 0xffffffffffffffffff max_cycles: 0x396d4ffc055, max_idle_ns: 881590662783 нс
    [4.981048] systemd-journald[323]: varlink-22: varlink: установка состояния бездействующего сервера
    [ 4.981116] systemd-journald[323]: varlink-22: varlink: изменение состояния idle-server – метод обработки
    [ 5.336734] systemd-journald[323]: varlink-22: varlink: изменение состояния обработанный-метод – бездействующий-сервер
    [ 5.339242] systemd-journald[323]: varlink-22: varlink: изменение состояния бездействующего сервера – ожидание отключения
Кажется, я ничего здесь не вижу, но я помню, что в настройках BIOS/UEFI что-то говорило ACPI вместо RXS или как там это называется.
Я не могу открыть папку "/proc/acpi/processor/CPU0/power", так как ее не существует (достигает только "acpi").

Некоторое время спустя я решил переустановить Ubuntu, что я и сделал, первый день (и второй) все работало хорошо, а потом произошел сбой.
Немного повозившись, я решил запустить «датчики часов» и кое-что обнаружил; когда я играл в osu!, моя температура подскочила до ~95°C, достигнув 99°C!
Просто хочу отметить, что выключатель ПК срабатывает при 100°C, я был в 1 градусе от него, а большую часть времени в 2 (~96-98°C большую часть времени)!

Еще одна идея, это может быть проблема с блоком питания, так как я никогда не видел, чтобы он отключался от сети.

«kernelUpdateCrash» было старым именем этого файла, теперь это «cleaningComputer», я открыл компьютер и, черт возьми, в вентиляторах было столько дерьма.
Не вылетает с тех пор, как я его почистил! Не очень подробно, потому что этот файл такой длинный, а также я открыл другой компьютер, который будет в другой истории (думаю, я назову его «firstUbuntuInstallation»).


Обновите, опять вылетело.
Этого не произошло, пока он был сбоку, поэтому я думаю, что это проблема с воздухопроводностью вентилятора.
На вопрос askubuntu их компьютер отключился из-за нагрева, я не уверен, нагревается ли он в моем случае, но помогло обновление BIOS.
Источник: https://askubuntu.com/questions/1232813/ubuntu-20-04-shutdown-after-overheating.

Я сделал это, мне пришлось загрузиться с USB-накопителя Windows PE, чтобы запустить программу, но программа не работала...
Поэтому вместо того, чтобы отметить опцию «Установить», я выбрал опцию «Распаковать», и она распаковала другой исполняемый файл с тем же именем, за исключением того, что теперь все буквы были заглавными!
В любом случае, я запустил его, и это была эта странная схематичная установка, которая, казалось, использовала WinAPI для размещения текста там, где его не должно быть, и он не работал без питания от сети.
Я подключил его и снова запустил, у него было странное и, вероятно, сломанное изображение талисмана, похожего на карандаш?
Я прикрепил 2 изображения, которые сделал на свой телефон, поэтому эта история в папке.
ПК перезагрузился, все заработало, а потом вентиляторы начали жужжать, как будто вот-вот взорвется, никогда такого не видел, видимо временное перенапряжение вентиляторов при попытке перезагрузить компьютер.
Так что да, я снова изменил название этого.

Опять разбился...

В последний раз я модифицировал этот файл: 2021å¹´10æ26æ¥ 19æ55å59ç§.
Теперь это: 2021å¹´11æ06æ¥ 23æ10å36ç§
Я только что переустановил термик, вроде работает, не уверен, дросселирует хорошо, думаю.
Сценарии setPerformanceMode.sh и setPowersaveMode.sh, которые я создал (используя cpufreq), похоже, больше ничего не меняют.
Так что давайте просто надеяться, что это сработает, даже если thermod был установлен по умолчанию...
PS: у меня на терминале i7z установлено значение «Всегда сверху», поэтому я могу отслеживать частоту, C-состояния и температуру ядер ЦП (4 физических, логических).

Bruh Thermald тормозит до 400 МГц во время игры.
Я выхожу из программы, он возвращается к 1 ГГц, что?
Хорошо, я сделал Осу! установите ограничение FPS на V-Sync (60 кадров в секунду) вместо удвоенного значения (120 кадров в секунду, которое было раньше), и это кажется хорошим, даже когда компьютер не на его стороне (обычно он не зависал, когда на боку , как отметили поклонники.

Итак, я проверил журналы журнала и получил:
"thermald.service: изменен запуск -> стоп-сигтерм"
хм...
О, подождите, это в конце журнала, возможно, он отключен ç¬.

Ключевые слова проверены с помощью «journalctl -g ???»:
    тепловой
    закрытие
    крушение
    паника
    искра
Он просто разбился при поиске в journalctl... Давайте разберемся с помощью "journalctl -b -1". Ха, последний лог за 4 минуты до крушения, ладно...
Да, это я прошу помощи в AskUbuntu, надо было сделать это давным-давно!
Хорошо, теперь мне просто нужно скопировать это в вопрос.

Сноска

Если есть какая-либо другая информация, которую я мог бы предоставить, оставьте комментарий, я проверю ее.

регулярно и соответственно обновлять пост. Опять же, это может быть проблема с оборудованием, но это произошло, когда я обновил свою систему, и в настоящее время из-за Wayland и некоторых других вещей я не могу перейти на 20.04 LTS и работать над этим.