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

Dejavu	# 5 лет, 1 месяц назад
Темы: 1 Сообщения: 8 Участник с: 21 октября 2019	marlock Память в разгоне? неа, там по умолчанию вроде 2400 у меня, в биосе от дефолтных только SVT включено (виртуализация)

red	# 5 лет, 1 месяц назад
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	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 сентября)

red

# 5 лет, 1 месяц назад

Темы: 30

Сообщения: 1517

Участник с: 31 августа 2011

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 сентября)

Dejavu	# 5 лет, 1 месяц назад (отредактировано 5 лет, 1 месяц назад)
Темы: 1 Сообщения: 8 Участник с: 21 октября 2019	Ну очевидно, что это 12 сентября, но да у асус всегда так, в биосе дата всегда другая стоит, хз, может дата подписи какая то. Хоть с этим биосом, хоть с предыдущим.

red	# 5 лет, 1 месяц назад
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	Dejavu, а это вы обновляли биос или уже было ?

Dejavu	# 5 лет, 1 месяц назад
Темы: 1 Сообщения: 8 Участник с: 21 октября 2019	ну конечно я, я купил новым в 2017 году. Сначала винда стояла какое то время, с начала 19 года арч

vasek	# 5 лет, 1 месяц назад (отредактировано 5 лет, 1 месяц назад)
Темы: 47 Сообщения: 11856 Участник с: 17 февраля 2013	Вообщем решил вспомнить декодирование 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, довольно мучительно. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 1 месяц назад (отредактировано 5 лет, 1 месяц назад)

Темы: 47

Сообщения: 11856

Участник с: 17 февраля 2013

Вообщем решил вспомнить декодирование 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, довольно мучительно.

Ошибки не исчезают с опытом - они просто умнеют

red	# 5 лет, 1 месяц назад (отредактировано 5 лет, 1 месяц назад)
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	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

red

# 5 лет, 1 месяц назад (отредактировано 5 лет, 1 месяц назад)

Темы: 30

Сообщения: 1517

Участник с: 31 августа 2011

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

vasek	# 5 лет, 1 месяц назад
Темы: 47 Сообщения: 11856 Участник с: 17 февраля 2013	И дополнительно рекомендую установить rasdaemon и помониторить ошибки, можно дополнительно при этом запустить stress. Будет собирать не только MCE errors, но и PCI, Memory и др. При этом MCE errors могут быть расписаны более подробно. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 1 месяц назад

Темы: 47

Сообщения: 11856

Участник с: 17 февраля 2013

И дополнительно рекомендую установить rasdaemon и помониторить ошибки, можно дополнительно при этом запустить stress.
Будет собирать не только MCE errors, но и PCI, Memory и др. При этом MCE errors могут быть расписаны более подробно.

Ошибки не исчезают с опытом - они просто умнеют

Dejavu	# 5 лет, 1 месяц назад
Темы: 1 Сообщения: 8 Участник с: 21 октября 2019	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

# 5 лет, 1 месяц назад

Темы: 1

Сообщения: 8

Участник с: 21 октября 2019

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 тайминги. Просто сходу не знаю, что там клацать, а почитать еще особо времени не было.

vasek	# 5 лет, 1 месяц назад (отредактировано 5 лет, 1 месяц назад)
Темы: 47 Сообщения: 11856 Участник с: 17 февраля 2013	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` Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 1 месяц назад (отредактировано 5 лет, 1 месяц назад)

Темы: 47

Сообщения: 11856

Участник с: 17 февраля 2013

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

Ошибки не исчезают с опытом - они просто умнеют