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

это шутка?

Можно. Читай внимательно.

AMD Ryzen 2xxx segfault

Пофиксили ещё на 1xxx начиная с батчей ~33 недели.

Мазохизм какой-то.

В том и проблема, что тогда не до конца пофиксили, и официальных данных о закрытии проблемы не было, только в индивидуальном порядке предлагали замену и выдавали протестированные. Хотя и сравнивания отзывы до и после - новые были заметно стабильнее, даже учитывая микрокод.

Не пофиксили. Встречаются упоминания о глючных процессорах выпущенных после 33 недели 17 года.
Есть версия, что на «пофикшенных» процессорах тупо выключен µUP cache, который влияет на воспроизводимость бага, но скорее всего не является его первопричиной.


Ах да, еще кроме сегфолтов gcc на некоторых системах с кукурузеном происходят рандомные перезагрузки. Они очень редкие, но тем не менее, проблема остается.

Не знаю про 2к, но 1к не фиксили, в них просто отключали опкеш (амуда позорище).

У меня сегфолты излечились разгоном.

У меня сегфолты излечились разгоном.

Скорее поднятием напряжения.

Ну да, скорее.

А ты в теги gentoo добавь, они постоянно компилят

Пофиксили в тредрипперах и всём, что было после 1ххх. Пруфы, что после 33 недели проблема есть, здесь: https://community.amd.com/thread/215773

Так даже в последнем сообщении той темы:

I have just replaced my Ryzen 1700, bought in August 2017, from batch 1714 PGT .

The new processor is from batch 1738 SUS.

The segfault error seems to be gone, after mild testing. I'll test more, but that batch is likely error free.

Я думаю что действительно начиная с определённой ревизии в 1xxx пофиксили. Но даже если это правда, в любом случае покупать 1xxx не очень разумно, потому что вскрывать коробки с процессорами и объяснять продавцу «этот проц недостаточно новый, там вот такие вот глюки» чтоб заменили - как-то грустно. Лучше сразу 2xxx взять и не париться какой он недели там

У 2xxx ещё за счёт снижения каких-то там задержек ещё ipc вырос.

Задержки доступа к памяти уменьшили чуток. В стоке, естественно)

Скорее пофиксили, чем нет.

https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekM... здесь после 30й недели данных о багах не встречается.

информация от меня:

1717PGT 1700й: после разгона с поднятием напряжения баг пока не встречал. До разгона протестировать не успел.

Чуть позже появится информация по 21 рабочей станции на 2600Х. Маркировку не помню, поставка была в августе. На данный момент только введены в эксплуатацию.

2400G проблем нету

Есть же Кланг. Попробуйте ево.

Ты такой хороший, запускаешь компиляться OpenOffice в фоне, чтобы на экране одновременно с этим посмотреть киношку. И тут - хопа - Gрузин не тянет, комп становится раком, ресет не помогает. Весело.

У 1xxx вроде не было ревизий, все камни имеют одинаковый степпинг, просто какие-то подвержены багу, а какие-то - нет.

Свой 1600 купил в день старта продаж Ryzen. Первые месяцы были проблемы со случайными зависаниями, перезагрузками. После обновления bios, его настройки, обновления ядра машинка работает без сбоев.

вероятно - субтайминги памяти дотюнили. амд более переборчивы к плашкам памяти начиная с ам2+ камней - на многих плашках памяти, особенно если по 2 на канале, мемтест раз в сутки кидал ошибки, и система в работе вела себя непредсказуемо - сегфолты гцц, битые myisam и т.п., на ам3+ вроде грабля осталась, ам4 - хз, не тестил, но возможно грабли растут из того же места.

am3 наверное, а не am2+. am2 жрёт даже китайские 4 гб говнопланки.

am2+/am3 (хотя ам2+ таки к10.5 мне попадали в руки, типа фенома 940). am2 - там да, все ок.

А ну может быть, видимо обновление контроллера и смена техпроцесса сказались.

В результате купил данный процессор, но с другой материнкой (ASUS Prime B450). Обновил БИОС, ядро собрал последнее стабильное. ПК используется для разработки, нагрузка присутствует. 2 недели работает стабильно. Нареканий нет. Счастлив и радуюсь.

AMD Ryzen 2600

Архив с пакетом llvm70-7.0.0.txz для компиляции нового Firefox 62.0.3 скомпилировался и собрался за 1ч 15м без каких-либо сегфолтов. Архив с пакетом firefox-62.0.3,1.txz - за 50 минут. Продолжаю наблюдения. (Упаковка бинарников почему-то занимает заметно продолжительное время).

У меня на AMD Ryzen 7 1700 (и это ещё до 2xxx, да) компилировать очень даже можно, но у меня экземпляр с бажным энергосбережением. Приходится применять такие ядерные опции как, например, CONFIG_RCU_NOCB_CPU (с «rcu_nocbs=0-15 processor.max_cstate=5» в опциях загрузчика). Без этого внезапно происходят фризы. А с костылями всё очень даже стабильно.

2600? А чё так, кукуруза же тащет?

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

Да. Двухканал DDR4-2933. Надо ещё систему пересобрать - она под FX работала.

Сейчас не могу ничего сказать в защиту того или иного решения. Raidz ремонтируется - всё-таки накрылся один проблемный 8-летний HDD 2,5 - подменил залежавшимся терабайтником, чинится походу.

Но на компиляцию это не влияло - пул был временно отключен, использовался системный SSD.

2 канала это мусор, давайте 4 канала и дешевле интела иначе преимуществ 0

Упаковывай в несколько потоков, могу подсказать как это сделать в генте. Но вообще жирнолис на днищеинтеле из 2010 ~20 минут компилируется — у тебя странные цифры. Мжет отключить кукурузоядра надо? У кукурузоядер проблемы с smt особенно на венде, если отключить производительность вырастет.

Та это у него кукурузо-бздя, её надо отключать.

может в конфигурации ядра что-то забыл включить? там была какая-то опция связанная с io на amd.

firefox 2010 года может 20 минут и комиляется на днищеинтеле 2010 года, но не новый.

Да это в т.ч. и на несамосборных ядрах, в т.ч. и из Debian'а 9. В других дистрибутивах люди тоже наступали на эти грабли, и в интернетах есть, например, инструкция для Убунты по сборке своей версии ядра с включением этой опции.

Да нет, это аппаратный баг ризенов 1xxx.

IOMMU опция называется и у неё есть фичи для амд аж 2 версий.

На AMD FX-8320E (DDR3-1600 одноканал)Firefox 62.0 компилируется 35 минут вместе со сборкой в архив пакета. Меня другое настораживает: время упаковки в архив полученных бинарных файлов. Вот где затраты времени наблюдаются, и с чем это связано, предположить не могу - менял носитель-источник сборки, ничего не меняется - 5-15 минут на архивацию. Формат архива TXZ. Архиватор такой трудный, работает в однопотоке?

Эти опции кругом в дефолтных ядрах включены. И в Debian'е, и в Убунте,... и т.д. Но, у людей всё равно фризится. Пока не будет включена конкретно CONFIG_RCU_NOCB_CPU. А из коробки она включена только в ядрах RHEL'а/CentOS'а и Федоры.

Самый последний, базарю. Хромиум всего пару-тройку лет назад тоже в пределах 20 минут компилялся, но потом как то резко взлетел до часов (с каждый релизом +20 минут — очень показательно).

сколько gcc собирается на твоём днищеинтеле 2010 года?

Архиватор такой трудный, работает в однопотоке?

Очень может быть. Для этого в своё время pixz и pxz запилили.

xz давненько многопоточный. Только не по-умолчанию, многопоточность надо включать.

$ xz -h
...
  -T, --threads=NUM   use at most NUM threads; the default is 1; set to 0
                      to use as many threads as there are processor cores

А как включить многопоточность архиватора во FreeBSD, алиасом что ли?

В арче на это есть makepkg.conf

Про FreeBSD тебе лучше знать.

Да, последнего обновления chromium из исходников на AMD FX я так и дождался - после пары-тройки часов компиляции сборка выжрала остатки памяти из 8 ГБ ОЗУ и ушла в медитацию по ворочанию оставшимися ресурсами. На это раз попробую добить задание.

Найти конфиг вашей пердольной билдсистемы и изменить опции запуска xz. Или пихнуть переменную XZ_DEFAULTS=--threads=, но не факт что подхватится.

спасибо, почитал про эту фичу как workaround