Ryzen gcc segfault bug больше не с нами :(

типичный софтовый баг

А ты уверен, что они не отключили какой-нибудь блок в процессоре или снизили частоту?

А вот вот на этом моменте поподробнее. Я как раз в AMD пишу :) Они просто замены CPU делали, если чо.

Ну в общем отключение opcache control, которое фиксило этот баг, замедляло rodinia, 7-zip и c-ray. Сейчас со включенным opcache control протестировал, ничего не замедлилось с момента апдейта биоса.

Выдай железячные параметры, пожалуйста.

Заходишь в downloads твоей материнки и качаешь bios, шьёшь его, баг уходит. Пишешь зря, они тебе пришлют процессор с отключенным по дефолту opcache, вот и весь фикс.

Суперминиатюрный патч flashrom для прошивки райзенов:

--- flashrom/sb600spi.c	2017-10-12 15:16:15.679890290 +0300
+++ flashrom1/sb600spi.c	2017-10-12 14:58:41.915766606 +0300
@@ -156,7 +156,7 @@ static void determine_generation(struct
 			return;
 		}
 		uint8_t rev = pci_read_byte(smbus_dev, PCI_REVISION_ID);
-		if (rev == 0x4a) {
+		if (rev == 0x4a || rev == 0x59) {
 			amd_gen = CHIPSET_YANGTZE;
 			msg_pdbg("Yangtze detected.\n");
 		} else {

Если BIOS в формате CAP, то компиляешь UEFITool и вытаскиваешь оттуда .rom файл.

Заходишь в downloads твоей материнки и качаешь bios, шьёшь его, баг уходит.

Я это щас как раз и делаю, да. Интересно будет сравнить результаты.

Обновился. Они поправили UEFI, там теперь EFI/<OS> вместо EFI/BOOT, что не может не радовать. Сижу, смотрю на выхлоп kill-ryzen.

Что, реально есть толк? Не обновлялся, потому что лень все настройки каждый раз восстанавливать. У платы есть функция сохранения настроек в текстовый файл, но она нифига не работает при обновлении прошивки. И зачем она тогда нужна?

kill-ryzen грохнулся:

Using 16 parallel processes
[loop-0] Sat Dec 16 21:28:32 MSK 2017 start 0
[loop-1] Sat Dec 16 21:28:33 MSK 2017 start 0
[loop-2] Sat Dec 16 21:28:34 MSK 2017 start 0
[loop-3] Sat Dec 16 21:28:35 MSK 2017 start 0
[loop-4] Sat Dec 16 21:28:36 MSK 2017 start 0
[loop-5] Sat Dec 16 21:28:37 MSK 2017 start 0
[loop-6] Sat Dec 16 21:28:38 MSK 2017 start 0
[loop-7] Sat Dec 16 21:28:39 MSK 2017 start 0
[loop-8] Sat Dec 16 21:28:40 MSK 2017 start 0
[loop-9] Sat Dec 16 21:28:41 MSK 2017 start 0
[loop-10] Sat Dec 16 21:28:42 MSK 2017 start 0
[loop-11] Sat Dec 16 21:28:43 MSK 2017 start 0
[loop-12] Sat Dec 16 21:28:44 MSK 2017 start 0
[loop-13] Sat Dec 16 21:28:45 MSK 2017 start 0
[loop-14] Sat Dec 16 21:28:46 MSK 2017 start 0
[loop-15] Sat Dec 16 21:28:47 MSK 2017 start 0
[loop-5] Sat Dec 16 21:34:58 MSK 2017 build failed
[loop-5] TIME TO FAIL: 386 s

Вывод dmesg:

[  706.273215] traps: as[23839] trap invalid opcode ip:402b5e sp:7ffc71e406e8 error:0 in as[400000+5a000]

Стоит признать, что ошибка слегка изменилась :)

Все равно валится... А попробуй ядро 4.15

Все равно валится... А попробуй ядро 4.15

Это lucky guess, или там что-то поменяли?

Блин, я несколько раз долбал на двух компах, хоть бы хны, но на них rc стоят. Там для райзена дохрена патчей.

Блин, я несколько раз долбал на двух компах, хоть бы хны, но на них rc стоят.

Скинь конфиг ядра, я попробую с ним собраться.

P.S. Второй тест не падает гораздо дольше.

http://paste.org.ru/?sed0h8

стандартный арчевский конфиг, обновленный методом зажатия enter и с добавленными настройками радеонов.

Ну вот я скинул кеши, запустил второй раз kill-ryzen и он уже минут 15 работает без проблема. Может, конечно, повезло, и в ld действительно есть похожий баг. Всякое бывает.

Я сглазил :(

[KERN] Dec 16 21:53:32 gentoo kernel: traps: sh[24072] general protection ip:7f529dcdcac9 sp:7fff1aded818 error:0 in libc-2.26.so[7f529db98000+1ae000]
[loop-1] Sat Dec 16 21:53:33 MSK 2017 build failed
[loop-1] TIME TO FAIL: 74 s
^C

В общем фейл. С 6-го раза лопнул быстро.

Вот шлак. У меня просто довольно мерзкая штука — моя МП не умеет отключать mOP.

Есть патченные биосы, заливаются через flashrom.

Есть патченные биосы, заливаются через flashrom.

Ну как последний вариант. Насчет того, что они просто присылают чипы с отключенным opcache control — ты это точно знаешь, или это слухи?

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

или это слухи?

Официально не подтверждено, но скорость компиляции ниже на 5-10% чем на аналогичных старых процессорах. К тому у многих опять баги выскакивают на новых ревизиях.

Официально не подтверждено, но скорость компиляции ниже на 5-10% чем на аналогичных старых процессорах. К тому у многих опять баги выскакивают на новых ревизиях.

Гм... Понятно. Но это лучше, чем 30% шанс получить сломанную сборку.

P.S. Полуркал в BIOS. Opcache Control таки добавили. Хотя бы можно не отсылать процессор :D

Полуркал в BIOS. Opcache Control таки добавили. Хотя бы можно не отсылать процессор :D

Протестируй, что он не отваливается.

Протестируй, что он не отваливается.

Ага.

К сожалению скорее всего баг таки аппаратный.

От себя (как обладателя 3х Ryzen 1800) могу добавить что помогаетстановится немного лучше с отключением: CPU Boost, энергосбережения CPU(в биосах по разному называется), и SMT. В особо запущеных случаях требуется повышать напряжение Vcore и SoC. Данные действия позволили в моём случае увеличить время вылета kill-ryzen.sh с нескольких минут до десятков часов. А самое главное пропали(рандомные зависания которые могли быть раз в месяц, а могли быть несколько раз в день).

Рандомных зависаний нет, хотя компьютеры включены целый день. Какая память?

Motherboard: ASUS PRIME B350M-A

CPU: AMD Ryzen 7 1700X

RAM: Crucial X2 Ballistix Sport LT Gray 16GB DDR4-2400 UDIMM

(виноват в 1 посте неправильно указал проц)

И таких вот 3 штуки. Хотя память еще другая стоит какая то на 1пк. Чего только не делал с ними, пока не пришел к тем настройкам какие изложил выше. Проблема сильно усугубляется специфичностью нагрузки, оно может работать без каких либо видимых проблем, а может зависать(это было для меня наибольшей проблемой) по нескольку раз в день.

Как воспроизвести баг? Я вчера нормально ядро собрал в 12 потоков.

ахтунг говнокодище https://github.com/suaefar/ryzen-test/blob/master/kill-ryzen.sh

Райзен ненавидит микроны же.

Сегодня постараюсь проверить. AGESA 1.0.0.6b сейчас на материнской плате и модули памяти от Samsung.

Насколько мне известно, сам по себе бренд «Crucial» можно перевести на русский как «Не берите эту память - она говно при любом раскладе».