Редкие зависания, чистый арч (райзен??)

marlock
Память в разгоне?
неа, там по умолчанию вроде 2400 у меня, в биосе от дефолтных только SVT включено (виртуализация)
Dejavu
Machine: Type: Desktop Mobo: ASUSTeK model: PRIME B350-PLUS v: Rev X.0x serial: <root required> UEFI: American Megatrends v: 5220 date: 09/12/2019
интересно, какая то машина времени получается
v: 5220 date: 09/12/2019
а судя по офсайту
Version 5220 2019/09/24

выходит либо до(если 09/12/2019 это 12 сентября) либо после(если 09/12/2019 это 9 декабря) но никак во время(2019/09/24 - 24 сентября)
Ну очевидно, что это 12 сентября, но да у асус всегда так, в биосе дата всегда другая стоит, хз, может дата подписи какая то. Хоть с этим биосом, хоть с предыдущим.
Dejavu, а это вы обновляли биос или уже было ?
ну конечно я, я купил новым в 2017 году. Сначала винда стояла какое то время, с начала 19 года арч
Вообщем решил вспомнить декодирование MCE ошибок, а то что то все подзабылось.
Пришлось залезти в спецификацию - и да, не зря писал про 4 первых бита 0:3, по ним действительно можно судить о некоторых стандартных ошибках, например
0000 - No Error (No error has been reported to this bank of error-reporting registers)
0010 - Microcode ROM Parity Error (Parity error in internal microcode ROM)
… и некоторые другие ...
их не много и, как правило, мало о чем говорят - кстати наш случай 1000 там отсутствует.
Но есть общий способ декодирования, описанный в этой же спецификации (просто раньше не обращал внимания) - там поле в 16 бит делится на 4 субполя по 4 бита каждый и несколько таблиц, используя которые получаем для нашего случая
0000  0001  0000  1000
{10}CASHE{00}_{0000}
и выходим на кэш процессора (точнее Cache Hierarchy Errors - ошибка уровней кэша), смотрим по таблицам и получаем
1. Transaction Type - Generic
2. Memory Hierarchy Level - L0
PS - Transaction Type может быть data, instruction, or generic. Generic - когда процессор не может определить тип транзакции.
Уровни памяти - общеизвестные - L1, L2, L3 .... (L4 вроде не везде) и L0 - самый близкий к ядру, объем менее 1K ... и вообщем то считается регистром

Плюс к этому бит 61 = 1, то есть ошибка не исправимая - грубо говоря проц восстановить работу не может и получаем скорее всего kernel panic.

Код ошибки узнали, на причину вышли, но в решении пробемы это не поможет.
В инете тоже решений не видно, возможно bug проца, тогда нужно ждать обновления микрокода/BIOS (хотя что то там про микрокод мелькало и в логах) … а вообще придется свыкнуться, проблема аппаратная … может и рассасется само по себе с обновлением ядра, BIOS, микрокода ...

EDIT 1 - как уже писал выше биты 52 - 38 равны нулю, то есть ни одна ошибка MCE не была исправлена, что еще раз подтверждает, что ошибка не исправимая и проц возобновить работу не может.

EDIT 2 - ввел небольшие пояснения. ------ а вообще, наверное, неплохо бы описать все это в блоге, чтобы бы все было в одном месте. MCE ошибки редкость, но вот с декодирование их обстоит не очень информативно, а лазать по спецификациям да и в поисках хороших статей, да еще как правило на en, довольно мучительно.
Ошибки не исчезают с опытом - они просто умнеют
Dejavu
Это было всегда с момента установки арча, на ядрах 5.0, 5.1, 5.2, 5.3. И возможно даже 4.19.
Dejavu
купил новым в 2017 году. Сначала винда стояла какое то время, с начала 19 года арч
ядро 5.0 завезли в марте 19 года
если не уверены со стабильностью работы в 4.19 то это можно легко проверить установив версию linux-lts ( 4.19.80 ) , еще для очистки совести можно попробовать ядро linux-zen

п.с.
после установки ядра не забудьте добавить его в загрузчик

п.с.2
надеюсь у вас установлен микрокод для процессоров АМД amd-ucode
И дополнительно рекомендую установить rasdaemon и помониторить ошибки, можно дополнительно при этом запустить stress.
Будет собирать не только MCE errors, но и PCI, Memory и др. При этом MCE errors могут быть расписаны более подробно.
Ошибки не исчезают с опытом - они просто умнеют
red
ядро 5.0 завезли в марте 19 года
если не уверены со стабильностью работы в 4.19 то это можно легко проверить установив версию linux-lts ( 4.19.80 )
повспоминал, да я пробовал (точно) ядро 4,19, я поставил в конце января арч, потом переустанавливал правда, в марте, когда ssd менял
red
ядро linux-zen
не пробовал такое
red
надеюсь у вас установлен микрокод для процессоров АМД amd-ucode
конечно
Name : amd-ucode
Version : 20190923.417a9c6-1
vasek
И дополнительно рекомендую установить rasdaemon
не пробовал эту штуку, спасибо попробую, также по быстрому успел прогнать stress (ну пока что очень по быстрому глянуть вдруг сразу завалится)
[lex@home-desktop ~]$ stress --cpu 12 --io 4 --vm 2 --vm-bytes 128M --timeout 60s
stress: info: [37100] dispatching hogs: 12 cpu, 4 io, 2 vm, 0 hdd
stress: info: [37100] successful run completed in 60s

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

Но нужно еще с --vm-bytes 128M поиграться, там ссылка на upstream битая (поищу доки в инете)
vasek
EDIT 1 - как уже писал выше биты 52 - 38 равны нулю, то есть ни одна ошибка MCE не была исправлена, что еще раз подтверждает, что ошибка не исправимая и проц возобновить работу не может.

А у меня первая ревизия + покупалось достаточно рано, в августе вроде, то есть первые партии.
К сожалению, это то, к чему я склоняюсь больше всего. Потому что действительно много нареканий в инете на первый райзен, правда я так и не попробовал еще отключить с биосе эти c6 тайминги. Просто сходу не знаю, что там клацать, а почитать еще особо времени не было.
Dejavu
не пробовал эту штуку
yay -S rasdaemon
далее активируем
sudo systemctl enable rasdaemon.service
sudo systemctl start rasdaemon.service
rasdaemon.service работает как демон и записывает события RAS в журнал systemd

проверяем статус - systemctl status rasdaemon.service
ну и проверим (хотя это лишнее) - journalctl -b | grep -i mce

Далее можно посмотреть много чего интересного, используя ras-mc-ctl , подробности в --help, например,
сводка ошибок - ras-mc-ctl --summary
полная информация об ошибках - ras-mc-ctl --errors
Информация копится ...

EDIT 1 - хотя можно установить только mcelog - он отслеживает только MCE error и, точно не помню, но вроде бы в нем больше подробностей
yay -Ss mcelog
aur/mcelog 164-1 (+4 0.09%)
    Print machine check event log from x86-64 kernel
aur/rasdaemon 0.6.4-1 (+24 0.10%)
    Logging daemon for Platform Reliability, Availability and Serviceability (RAS), replacing mcelog
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.