У райзенов подъём частоты памяти до 3600 (на зен2) это первое, что нужно делать (дальше профит минимален). И если в случае АПУ это поможет по сути только видеосистеме, то для просто ЦПУ это в первую очередь повышение пропускной способности и уменьшение задержек внутренней шины через которую части процессора между собой и с памятью общаются. У 2400G штатная частота памяти 2933, а у 3700x - 3200, и это не просто так. На 2400 они хоть и могут работать, но далеко не в лучшей форме.

А что бы получить ещё больше профита на той же частоте, есть калькулятор: https://www.techpowerup.com/download/ryzen-dram-calculator/

Похоже, могу дать ответ. Попадались коменты от разработчиков ROCm, но линки сейчас не могу уже найти. У меня тоже были траблы с R3-2200G c Raven Ridge.

Короче вот здесь https://rocm.github.io/ROCmInstall.html пишут, что можно не ставить dkms-драйвер amdgpu для ядра, а пользоваться free драйвером из mainline ядра, но только для определённых версий ядра. И тогда ROCm будет работать.

Обратите внимание на фразу «Not currently supported on kernels newer than 4.18»

Т.е., получается, что free драйвер amdgpu в ядре 4.18 настолько хорош, что не нужен проприетарный. А всё потому, что нем уже есть драйвер admkfd. А вот в более новых ядрах (4.19 и выше) драйвер admkfd отсутствует, поэтому в них и есть проблемы.

В dkms-драйверах и ROCm и amdpru-pro драйвер admkfd в наличие. Но для ядер старше 3.10 (версии от RedHat Centos 7) ROCm dkms драйвер не собирается (я проверял начиная с 4.11 и выше). А проприетарный amdpru-pro dkms-драйвер ставится вполне нормально и работает стабильно с проприетарным же xorg-x11-drv-amdgpu.

С free драверами чуть сложнее. На момент выхода ядра 4.18 в amdkfd не было нормальной поддержки для Raven Ridge. Здесь патч, который её добавляет. https://patchwork.freedesktop.org/patch/238463/?series=46440&rev=2

Замечу лишь, что его возможно нужно будет подправить под целевую сборку ядра 4.18. Я подправил вполне успешно для fedora для ядра 4.18.19. Стабильность персоналки отличная: max uptime 10 суток без проблем, вероятно и больше, просто не требовалось.

Проблема только с переходом на новые версии fedora с новыми версиями ядер.

Например, в 5.3 появился раздражающий сбой «dcn_calcs», который уже был ранее на ядрах для CentOS 7 (в принципе для всех Vega10 видео-карт насколько я понял).

пардон, ошибся, соседний патч https://patchwork.freedesktop.org/patch/238465/?series=46440&rev=2 правильный

Спасибо за информацию! Буду разбираться.

В соседнем топике, использовали опцию ядра amdgpu.dc=1 https://www.linux.org.ru/forum/linux-hardware/14373405. на 5 ядре как говорят уже не актуально, но сегодня сам попробую, мой вывод dmesg с такой же ошибкой как у ТСа.

Глянул ещё раз. Модуль amdkfd теперь похоже включён в ядро не модулем, а постоянно (CONFIG_HSA_AMD=y) как раз с 4.19 и выше. Патч для Raven Ridge в них присутствует. Ну, не знаю, что там ещё изменилось, в общем с 4.19 и выше были траблы.

А на описанном решении уже полгода живу вполне нормально. Asus B350, R3-2200G, RAM CRUCIAL 2x8GB, всё стандартно. Fedora 29, патченое под Raven Ridge ядро 4.18.16 (под F-27 было 4.18.19). Собирал rpmbuild-ом из src.rpm.

Причем, на этом же решении нормально работает ROCm + TensorFlow-ROCm, в headless режиме само собой.

about unixway:

запилите новость

про книгу

UNIX: A History And A Memoir

Brian Kernighan

Добавлю для интересующихся: (ядро 4.18 с патчем для Raven Ridge) тест с apitrace replay приводит к зависанию видеокарты (из сообщения Зависания GNU/Linux на Ryzen 2400g (комментарий)), компьютер остаётся доступен по сети, но при попытке перезагрузки зависание. Так что решение не идеальное.

У меня на последних версиях он не весит графику. Видимо что-то стало лучше

Неа. Первый GNC работает на radeon.

aploskov , darkenshvein

Если Вам еще интересна эта тема - обновился я до Kubuntu 19.10 и начались интересные вещи. Да, зависания намертво прекратились, перезагружать компьютер больше не приходится. Но мелкие подвисания на несколько секунд остались и происходят даже чаще, микрофризы что-ли или как это назвать даже не знаю. Раньше примерно раз в день или два все зависало на несколько секунд намертво, даже указатель мыши не двигался, потом указатель мыши начинал двигаться но больше никаких реакций, лечилось только перезагрузкой и после этого все было нормально, как правило на день хватало. Теперь все тоже самое, также система намертво зависает на несколько секунд, но потом восстанавливается, и через непродолжительное время это повторяется. Т.е. вместо одного зависания в день лечащегося перезагрузкой получаем микрофризы и подвисания каждые полчаса. Мне это поднаедоело немного уже, сижу думаю от чего проще отказаться - от 2400g или линукса, склоняюсь ко второму )) Единственное что вселяет оптимизм - я опытным путем выяснил что именно вызывает эти подвисания в 100% случаях, это нажатие на служебные кнопки в Chromium, типа «импортированные закладки» на панели или кнопка настроек (три точки) справа вверху. При нажатии на них зависает 100% всегда. Аппаратное ускорение выключено. Я и раньше помню что зависало почти всегда только в Хроме или его клонах, а если и не в них то они всегда были открыты в фоновом режиме.

так используй файрфокс

общеизвестно, что хуанг пропихнул свой геймворкс в хром, чтобы подгадить амд

Интересное наблюдение. У меня, репортившего что проблема сама по себе не проявляется, как раз фаерфокс.

Обнови ядро.

Название материнской платы и версия BIOS?

я опытным путем выяснил что именно вызывает эти подвисания в 100% случаях

Тогда зарепорти баг на амдэшные дрова. У тебя идеальный сценарий, а если ты ещё будешь готов пересобрать чёнить - так вообще цены тебе нет.

Хм, я и правда сейчас лисой пользуюсь. Но я вообще сижу на Debian 10 сейчас (Gnome 3) и не грущу.

Вчера, вон, отдал свои две планки по 8 DDR4-2400 родственникам, готовлюсь либо к миграции на ASRock A300 (чтобы в качестве NAS у меня работал, либо к дальнейшему апгрейду системы.

В любом случае, обновлюсь где-то в середине января. Могу потом прислать старую материнку для диагностики, какое железо виновато. А камень перенесу в ASRock, скорее всего.

Ryzen 2400g, MSI B350M PRO-VDH, 2 планки Kingston HyperX Predator [HX430C15PB3/8] по 8 ГБ работают на частоте 2933 MHz. BIOS (EFI) самый свежий.

Да я сам скоро обновлять железо буду наверное, так что проблема в любом случае решится.

Думаешь? Ладно, попробую может.

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

Модули памяти в те слоты установлены (A2, B2)?

Возможно, вам стоит попробовать более подходящую для десктопа ОС, у которой нет проблем с новым железом?

Так на винде то не зависает, все ОК. Следовательно при чем тут железо?

Из таких знаю только Windows 10, она давно стоит на отдельном SSD. Но я считаю что ограничивать себя только виндой это такой же отказ от свободы как и ограничивать себя только линуксом. Хотелось бы чтобы был выбор и работало все.

да тоже там зависает на встройках, просто реже. Выглядит это как bsod с VIDEO_TDR_FAILURE поскольку перезапуск зависшей видяхи невозможен.
Дискретные же не виснут, там перезапуск работает

как вариант юзать efi gop вместо драйвера в линуксе,а играть в винде. llvmpipe хватит на рендеринг браузера, интерфейс выбрать такой, чтобы не зависел от opengl. Я пару месяцев так сидел когда достали зависания. Как раз в этот период сделал софтрендер в xash3d на основе квакового

Здесь https://bbs.archlinux.org/viewtopic.php?id=250297 обсуждаются 2 метода обхода такой же проблемы для R5 2500U:

1. опции rcu_nocbs=0-3 idle=nomwait для ядра <5.1.14
2. опция iommu=pt для ядра >=5.4

Сам использую опции: amd_iommu=fullflush iommu=pt . Т.е. второй метод я всё время использовал для ядра 4.18 (с патчем для Raven) из других соображений, и для 5.3.11 . Возможно, поэтому у меня и не было зависаний. Также упоминается и lvmpipe (к сожалению, с ним идут не все приложения). Первый метод у меня не решил проблему для 4.18 с apitrace тестом. При использовании 5.3.11 зависаний iGPU пока не видел.

Намучавшись с постоянными зависаниями, решил часть проблемы без патчей. Имеется: Ryzen 2400g, Linux 5.3, xserver-xorg-video-amdgpu (19.0.1-1), c-states вырублен (что избавило от железного зависания). При каждом зависании подключался по ssh с телефона и находил одну и ту же ошибку - «amdgpu_job_timedout». А предваряла эту ошибку еще одна - «ring sdma0 timeout», что натолкнуло на мысль использовать следующие параметры при загрузке: iommu=merge mes=1 В ядре 5.3 iommu fullflush стоит по дефолту. Две недели без зависаний (микрофризы остались). Срок небольшой, но раньше зависания проявлялись каждый день. Инфа отсюда и отсюда

На 5.1 с iommu=pt трейс уже не виснет. Но стал виснуть cpu

Если кому интересно, могу дать подробную инструкцию для R3-2200, R5-2400 и подобных, как под linux-ом корректно «отключить» iGPU и задействовать dGPU типа AMD RX-400/500, чтобы встройка не мешала работе дискретки.

cursed

OS: Ubuntu 19.10, CPU: Ryzen 3 2200G, MB: ASRock B450M-HDV

Зависания случаются внезапно и никаких признаков надвигающегося reset’a нет. Типична ситуация: открываю YT в браузере с каким-нибудь муз. стриммом, а на другом раб. столе книга. И тут бац! Картинка встала, музыка еще некоторое время играет, переферия отрубается тоже со временем. Не припомню зависаний во время игры в CS:GO.

Есть комп с Threadripper, Windows Server 2016, видеокарта Nvidia. Дрова устанволены от 10-ки. Так вот этот комп тоже зависает. Обычно 1 раз в сутки, после полуночи. И почти 100% зависнет если начать передавать в вирт. машину Hyper-V данные больше 4ГБ.

Я сегодня как раз обновился до kubuntu 20.04, пока проблем не наблюдаю вообще. Собственно и после обновления до 19.10 проблем почти уже не было, оставались небольшие фризы в хроме, но возможно проблемы были в самом хроме, а обновить хром как-то все лень было. Зависания вылечились уже давно установкой свежих ядер.

Да, с каждым новым релизом эти глюки начинают проявляться всё реже. Но полностью не уходят. Сегодня обновил BIOS. Посмотрим как это повлияет на ситуацию.
PS Мне трудно оправдать производителя, когда стабильность работы не гарантирована и в любую минуту работа может прерваться. С процессорами Intel таких проблем не встречал. Зависит от задач. Иногда лучше переплатить.

Если завтра выйдет новая архитектура от Intel с абсолютно новым видеоядром то установив на него текущую Ubuntu ты получишь точно такие же проблемы, потому что драйвера напишут через год или два, а глючить они перестанут лет через 5. Т.е. это не зависит от того Intel или AMD, поставь линукс на какой-нибудь старый процессор от AMD которому лет 5 и проблем точно также будет ноль. Не в производителе же дело, а в том что в линуксе всегда было плохо с новым железом, а ryzen g2400 на то время когда у меня были с ним проблемы был достаточно новым продуктом, это же первые APU на ryzen + новое видеоядро.

Господа, в чем может быть проблема?

Как обычно в чём – проблемы линупсоедов вендоров не колышат.

amd не исправят существующее оборудование

Так это проблемы вендоров. APU так же радостно виснут под оффтопиком

в моём случае - проблема была в дровах, которые почему то ровно работали с FX и старой видеокартой 7970.
но как только я проапгрейдился до ryzen - появился глюкодром(толлько на онтопике) на обоих драйверах и radeon и amdgpu.
поменял видюху на рыксу 580 - глюки прекратились

Уверен, эти глюки не только в Linux. Тут ещё важный момент, не программы аварийно завершают работу или что-то не запускается, а система полностью зависает во время работы. И абсолютно не ясно как с этим разобраться. Я такого не видел раньше.
Linux всегда было плохо с поддержкой внешних устройств(видеокарты, wifi, web-камеры и т.д.). Я могу смириться с этим. Но когда CPU под вопросом, это уже повод задуматься над качеством изделия.

избавлением от APU. ещё раз, APU и на винде виснет намертво при ошибке в драйвере, это видно там как синий экран VIDEO_TDR_FAILURE. При этом дискретные gpu такой пробелмой не страдают - при краше драйвер их рестартит. Рестартнуть APU же почти нереально. У меня получалось рестартнуть APU переводом системы в suspend после краша. Штатный запрос рестарта не работает.
На линуксе ещё добавляется вторая проблема - из-за отсутствия обработки потери контекста в иксах (и wayland) после успешного рестарта gpu всю графику приходится перезапускать. Но в отличие от проблемы с зависанием gpu тут можно надеятся что это будет решено в будущем и перезапускать надо будет только игры

жыды из амд хотят чтобы ты апргерйдился полностью, очевидно же

А я на этом 2400g на винде играю в GTA5. Да, прям на APU, без видеокарты. На средних настройках, не на минималках. Уже полтора года. За все это время под виндой ни одного зависания, вообще ни одной проблемы ни разу. Я это к чему - если рожа крива нечего на зеркало пенять. Или если проще - если проблемы с данным APU только в линуксе то причину надо искать в линуксе а не в APU.

а какие проблемы в линуксе, есле это амуде дрова для линукса так и не может нормально написать

Драйвера давно написаны нормально, просто с момента их написания до того как они попали в релиз ядра, а само это ядро в убунту прошло пару лет. Ну и собственно а почему они должны вкладывать в разработку драйвера для ОС с 1% на рынке те же ресурсы что и для ОС занимающей 95%? Другими словами если ты напишешь свою АнонимОС которой будут пользоваться два с половиной калеки и в ней под 2400g не будет драйвера от amd то виновато будет amd? С одной то стороны да, а с другой это объективная реальность.

но ведь амд это светило опенсорса ❤️❤️❤️

Цель любой коммерческой компании - получение прибыли. Других целей нет и быть не может. Если для увеличения продаж среди красноглазых надо прикинуться светилом опенсорса то это нормальный бизнес.

Ну так зависания не в direct3d играх, а в opengl обычно под виндой. И в 2д пртложениях. Нашёл пример блин

Не, именно код amdgpu косячит. На radeon такого не было.
В спешке реализовали новые фичи не обеспечив стабильность. Сколько раз у меня уже TMM протекал так что кончалась видеопамять. Обработать ошибку нехватки памяти? Нет, лучше мы фризнем драйвер.
То же самое с зависанием gpu. Зачем было фризить систему? Да чтобы всякие fence под новый gl и вулкан прикрутить. Так они тупо быстрее работают.
А винда кстати не виснет и может спокойно вывести bsod