LINUX.ORG.RU

Нужна помощь в анализе journalctl

 , ,


0

1

Добрый день. Нужна помощь с анализом лога загрузки свежего арча с кедами.

Сразу говорю: система работает, явных проблем не видно. Но это на коротких «забегах» в режиме браузер, блокнот и офис. И под короткими я понимаю, в лучшем случае полдня. Длительной эксплуатации не было, так же не было каких-то серьезных нагрузок.

Для пояснения: я на стадии поставил что-то, посмотрел, удалил/сломал, снес систему, поставил что-то другое и так по кругу.

Результат sudo -E hw-probe -all -upload: https://linux-hardware.org/?probe=b0c0ad46de

Результат journalctl -p 3..0 -b -1:

[user1@test ~]$ journalctl -p 3..0 -b -1
ноя 16 11:48:49 test systemd-coredump[1864]: Failed to connect to coredump service: Connection refused
ноя 16 11:48:49 test pulseaudio[908]: Error opening PCM device front:0: Нет такого файла или каталога
ноя 16 11:48:49 test pulseaudio[908]: Error opening PCM device front:0: Нет такого файла или каталога
ноя 16 11:48:50 test kernel: watchdog: watchdog0: watchdog did not stop!

Эти ошибки возникают при выключении компьютера. Что нужно сделать, чтобы их исправить? И нужно ли что-то делать?

Из того что сам нашел, это поставить pavucontrol для исправления ошибки пульсы (еще не пробовал). Это свежая проблема, т.к. до этого пробовал с pipewire, а он спамит предупреждениями, а не ошибками.

Для исправления watchdog did not stop! встречал рекомендацию «пересобрать ядро». Но это выходит за рамки моих знаний, поэтому может кто-то подскажет другой вариант?

Результат journalctl -p 4..0 -b -1: https://pastebin.com/60nAH6QT

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

ноя 16 11:45:13 test kernel: asus_wmi: fan_curve_get_factory_default (0x00110024) failed: -61
ноя 16 11:45:13 test kernel: asus_wmi: fan_curve_get_factory_default (0x00110025) failed: -61

Они точно связаны со свежими ядрами, т.к. если ставить lts (5.15) ее нет. Поиск, говорит что проблема встречается на ноутах, хотя у меня стационарник. И я предполагаю, что именно из-за них, при загрузке вентилятор видеокарты разгоняется до максимальных оборотов, а потом отключается. Вентилятор отключен до тех пор, пока температура не поднимется до 48 градусов.

И в связи с этим, прошу пояснить:

[user1@test ~]$ inxi -s
Sensors:
  System Temperatures: cpu: 35.1 C mobo: N/A gpu: amdgpu temp: 47.0 C
  Fan Speeds (RPM): N/A gpu: amdgpu fan: 934

amdgpu fan должен же показывать скорость вентилятора видеокарты, а Fan Speeds - процессора? Или я не правильно понимаю? Потому что по факту, крутится только куллер процессора, а видекарты стоит.

ноя 16 11:45:13 test kernel: usb: port power management may be unreliable
ноя 16 11:45:13 test kernel: acpi PNP0C14:01: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00)
ноя 16 11:45:13 test kernel: acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00)
ноя 16 11:45:15 test kernel: amdgpu: SRAT table not found
ноя 16 11:48:49 test systemd[1]: systemd-oomd.socket: Failed to queue service startup job (Maybe the service file is missing or not a non-template unit?): Transaction for systemd-oomd.service/start is destructive (systemd-reboot.servic>
ноя 16 11:48:49 test systemd[1]: systemd-oomd.socket: Failed with result 'resources'.
ноя 16 11:48:50 test systemd[1]: run-credentials-systemd\x2dtmpfiles\x2dsetup.service.mount: Failed with result 'exit-code'.

Эти сообщения (плюс сообщения про вентиляторы) появляются еще на стадии минимальной установки арча (base{,devel} linux{,-headers,-firmware} nano bash-completion networkmanager amd-ucode). Из них, я знаю только как избавиться от сообщений киллера: отключить его. Поиск в основном приводит на другие темы, содержащие вывод dmesg (не всегда по той же проблеме) или рапорты о багах.

Также прошу поделиться опытом, что вы проверяете, после установки системы? Лог журнала и лог иксов или еще что-то? Насколько вообще стоит реагировать на предупреждения (warning)? Или на них можно/нужно забить?

З.Ы. Если кому интересно, то из трех DE: xfce, cinnamon и plasma. Крыса спамит наименьшее количество сообщений о проблемах, корица чуть больше чем крыса, но буквально на несколько строчек. И обе раза в 2-3 меньше чем плазма.

Но стоит отметить, что это не совсем чистый эксперимент и они были не в равных условиях. Плазма ставилась в минималке с доп пакетами. И возможно кто-то из них, ставился с полным набором пакетов иксов, а кто-то только с сервером.

Кроме ручной установки, пробовал готовые системы, EndeavourOS с несколькими DE, linux mint, debian. Кроме последнего, у всех есть ошибки и предупреждения. Debian вообще после установки незахотел загружаться, но думаю, тут я где-то накосячил.

Из того что сам нашел, это поставить pavucontrol для исправления ошибки пульсы (еще не пробовал). Это свежая проблема, т.к. до этого пробовал с pipewire, а он спамит предупреждениями, а не ошибками.

Забавно:

  • Установил pavucontrol > reboot > ошибка есть
  • Открыл pavucontrol прошелся по вкладкам, поменял опции туда-сюда > reboot > ошибки нет
  • Опять reboot > ошибка есть
  • Открыл pavucontrol, ничего не менял, только по вкладкам прошелся > reboot > ошибки нет

Предположение: конфликт plasma-pa с pavucontrol: pacman -Rns plasma-pa pavucontrol && reboot

Словил дополнительные ошибки:

ноя 16 13:31:42 test kernel: mce: [Hardware Error]: CPU 11: Machine Check: 0 Bank 0: be802800000c0135
ноя 16 13:31:42 test kernel: mce: [Hardware Error]: TSC 0 ADDR fffdfc00d080 MISC d012000000000000 IPID b000000000 
ноя 16 13:31:42 test kernel: mce: [Hardware Error]: PROCESSOR 2:870f10 TIME 1668594699 SOCKET 0 APIC d microcode 8701021

pacman -S pavucontrol && reboot

Ошибки Hardware Error исчезли. Ошибкам пульсы, пофиг. Буду дальше смотреть, как это можно исправить

ComIngSoon
() автор топика
Последнее исправление: ComIngSoon (всего исправлений: 1)
ноя 16 11:48:50 test kernel: watchdog: watchdog0: watchdog did not stop!

Если в кратце, то делать ничего не надо. Штатная работа подразумевает наличие ошибки. Поэтому, принято решение ничего не трогать, благо ничего не зависает. Все что написано дальше, скорее носит ознакомительный характер. Мало ли, кто-то также будет искать.

Если более подробно, то watchdog, он же сторожевой таймер, предназначен для исправления проблем с зависанием.

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

Если еще подробнее, про действия системы при выключении/перезагрузке, можно глянуть сообщение (на англ.)

В соответствии с вики: для проверки можно использовать:

cat /proc/sys/kernel/watchdog
1

Где 0 означает отключенный сторожевой таймер, а 1 соответственно включенный.

Для изменения состояния, можно использовать пареметр загрузки: nowatchdog. Для systemd-boot, в конфиге загрузки: options root=PARTUUID=... rw nowatchdog. Для остальных загрузчиков вики. Проверка дала, изменение состояния watchdog с 1 на 0, но от сообщения не избавила.

Благодаря этой теме, на форуме манджаро, второй способ посмотреть состояние:

[user1@test ~]$ sudo sysctl -a | grep watchdog
kernel.nmi_watchdog = 1
kernel.soft_watchdog = 1
kernel.watchdog = 1
kernel.watchdog_cpumask = 0-31
kernel.watchdog_thresh = 10

И для отключения, рекомендовали добавить nmi_watchdog=0, помимо nowatchdog. Пробовал и так, несмотря на то, что параметр ядра ссылка nowatchdog отключает и программный (kernel.soft_watchdog) и аппаратный (kernel.nmi_watchdog).

Дополнительно включал в черный список модули:

[user1@test ~]$ cat /etc/modprobe.d/watchdog.conf 
blacklist iTCO_wdt 
blacklist iTCO_vendor_support
blacklist intel_pmc_bxt

Как в варианте без intel_pmc_bxt (т.к. amd), так и с ним. Сообщения остаются.

При необходимости, к примеру, зависании при выключении, можно поиграться с параметрами конфигурации systemd /etc/systemd/system.conf) man. В частности параметр RebootWatchdogSec=10min отвечает за 10 минутное ожидание, в случае зависания при перезагрузке. Можно внести изменения в файл или, как рекомендуется, создать каталог /etc/systemd/system.conf.d/, в котором разместить файл, к примеру custom.conf. И все изменения вносить в него.

Для примера:

[user1@test ~]$ cat /etc/systemd/system.conf.d/stop.conf 
[Manager]
RebootWatchdogSec=0s

В этом случае, у меня отсутствуют сообщения об ошибке: watchdog did not stop!. Но, как и говорил ранее, планирую оставить все по умолчанию.

Из полезного, можно обратить внимание на RuntimeWatchdogSec. Если я правильно понял, то установка этого параметра в значение отличное от 0, будет выполнять перезагрузку системы при зависании в процессе работы. По умолчанию отключен. С подводными камнями, разбирайтесь сами.

ComIngSoon
() автор топика
Ответ на: комментарий от ComIngSoon
ноя 16 11:48:49 test pulseaudio[908]: Error opening PCM device front:0: Нет такого файла или каталога

Так и не понял, что там не так. Предположительно нужно настраивать вручную. Но учитывая, что на звуковой карте нет канала(?) PCM (смотрел через настройку alsamixer). А есть только на встроенной HD-Audio, через которую я так и не смог получить звук (включая проверки на готовых дистрибутивах).

Было принято решение об отключении ее через биос. Ошибки от пульсы, соответственно пропали. Хотя переодически появляется другая.

А вот с:

ноя 16 13:31:42 test kernel: mce: [Hardware Error]: CPU 11: Machine Check: 0 Bank 0: be802800000c0135
ноя 16 13:31:42 test kernel: mce: [Hardware Error]: TSC 0 ADDR fffdfc00d080 MISC d012000000000000 IPID b000000000 
ноя 16 13:31:42 test kernel: mce: [Hardware Error]: PROCESSOR 2:870f10 TIME 1668594699 SOCKET 0 APIC d microcode 8701021

Появилось развитие.

При большинстве загрузок, данная ошибка отсутствует. За два дня, не особо частых перезагрузок, ~30 +/-, ошибка возникала 4 раза, два раза с 11 и два раза с 7 процессором.

Было сделано предположение, что что-то не так с подхватыванием микрокода, поэтому он был исключен из процесса загрузки. В принципе, ошибка где-то тут, т.к. за еще около 30 перезагрузок, я ее не встретил ниразу.

Конечно есть вариант, что на нее как-то повлияли те действия. которые я предпринимал, когда развлекался с watchdog-ом. Поэтому пока отложено, до переустановки системы.

ComIngSoon
() автор топика

У меня наибольшее беспокойство вызывают следующие сообщения:

ноя 16 11:45:13 test kernel: asus_wmi: fan_curve_get_factory_default (0x00110024) failed: -61
ноя 16 11:45:13 test kernel: asus_wmi: fan_curve_get_factory_default (0x00110025) failed: -61

Скорее всего вызваны модулем eeepc-wmi. И если я правильно понимаю:

[~]$ modinfo eeepc_wmi
filename:       /lib/modules/6.0.9-arch1-1/kernel/drivers/platform/x86/eeepc-wmi.ko.zst
description:    Eee PC WMI Hotkey Driver
depends:        asus-wmi

[~]$ modinfo asus_wmi
filename:       /lib/modules/6.0.9-arch1-1/kernel/drivers/platform/x86/asus-wmi.ko.zst
description:    Asus Generic WMI Driver
depends:        wmi,platform_profile,rfkill,video,sparse-keymap,ledtrig-audio

отвечает за настройки дополнительных клавиш ноутбука eee pc.

This is a driver for newer Eee PC laptops. It adds extra features like wireless radio and bluetooth control, leds, hotkeys, backlight… ссылка

Какая связь между стационарником и ноутом, хз. Отключение данного модуля, избавляет от данных строчек в логе. На работу вентиляторов не влияет, если судить по изменению шума, при нагрузке видеокарты (тест glmark2).

inxi -s все также показывает 900+ оборотов, при неработающем вентиляторе видеокарты.

И в общем:

[~]$sudo modprobe eeepc-wmi
kernel: asus_wmi: ASUS WMI generic driver loaded
kernel: asus_wmi: Initialization: 0x0
kernel: asus_wmi: BIOS WMI version: 0.9
kernel: asus_wmi: SFUN value: 0x0
kernel: eeepc-wmi eeepc-wmi: Detected ASUSWMI, use DCTS
kernel: input: Eee PC WMI hotkeys as /devices/platform/eeepc-wmi/input/input11
kernel: asus_wmi: fan_curve_get_factory_default (0x00110024) failed: -61
kernel: asus_wmi: fan_curve_get_factory_default (0x00110025) failed: -61

[~]$sudo modprobe -r eeepc-wmi
kernel: asus_wmi: ASUS WMI generic driver unloaded

[~]$sudo modprobe asus_wmi
kernel: asus_wmi: ASUS WMI generic driver loaded

То есть, видно:

  • включение eeepc-wmi дополнительно включает asus_wmi и вызывает предупреждение asus_wmi: fan_curve_get_factory_default (0x00110025) failed: -61;
  • отключение eeepc-wmi отключает asus_wmi (а если смотреть lsmod, то и его зависимости);
  • включение asus_wmi включает его и зависимости, но не включает eeepc-wmi.

Учитывая то, что eeepc-wmi зависит от asus_wmi, а не наоборот, получаем, что asus_wmi не используется никем, кроме eeepc-wmi.

Так что на данный момент:

echo "blacklist eeepc_wmi" >> /etc/modprobe.d/blacklist.conf
ComIngSoon
() автор топика
Ответ на: комментарий от ComIngSoon

[Hardware Error]

За эти дни, данная ошибка появлялась еще несколько раз. Она не привязана к ядру процессора, помимо 11 и 7, появлялась и на других. Это на системах с ванильным ядром и использованием микрокода amd. Поиски в интернете, дали следующие результаты:

https://wiki.archlinux.org/title/Ryzen#Random_reboots

https://forum.manjaro.org/t/system-auto-rebooted-mce-hardware-error-in-dmesg-related-to-cpu/89580

Пишут, что причина в недостаточном напряжении при пиковой нагрузке.

В общем, еще одним из вариантов решения: поднять напряжение на процессоре. За около недели использования системы, сообщений не было. Но количество перезагрузок не слишком большое (~20).

ComIngSoon
() автор топика
Последнее исправление: ComIngSoon (всего исправлений: 2)