[Discussione] AMD Ryzen - problematiche di Segmentation Fault (segfault)

[paolo.oliva2]

Domanda da.... idiota.

Ieri sera ho fatto tutto, bootato dalla penna, ho messo i file di test in un'altra penna... tutto ok, mi boota e vedo i file... ma con che mazza li carico? Io li ho visti con l'editor e altro... ma non ho trovato come caricarli per eseguirli.

Che programma è?

[Gioz]

Originariamente inviato da Ozozuz

Ho notato che alla fine anche ubuntu crasha, ma l'errore é diverso. Non si parla di seg-fault ma "tra le altre cose" di coredump.
La conclusione é sempre la stessa ? Non mi ritrovo AMD che tra un paio di settimane mi dice che tutto funziona e mi rimanda la stessa cpu indietro ? :c

per me questo è sempre dovuto alla saturazione della memoria.
core dump non significa che ti "muore un core della cpu" ma che è stata registrata una situazione anomala che ha portato ad interruzione il programma.

[s12a]

EDIT: attenzione, con Ubuntu 17.10 occorre usare questo zip:
https://github.com/Oxalin/ryzen-test/archive/master.zip

Proveniente da questo fork di Oxalin:
https://github.com/Oxalin/ryzen-test/

Originariamente inviato da paolo.oliva2

Domanda da.... idiota.

Ieri sera ho fatto tutto, bootato dalla penna, ho messo i file di test in un'altra penna... tutto ok, mi boota e vedo i file... ma con che mazza li carico? Io li ho visti con l'editor e altro... ma non ho trovato come caricarli per eseguirli.

Che programma è?

https://imgur.com/a/sv5r3

Mi sono appena reso conto che le istruzioni date in precedenza erano forse troppo sommarie e danno troppe cose per scontato. Ecco istruzioni passo-passo che usano Ubuntu 17.10 che ho linkato poco sopra in versione beta (dovrebbe uscire domani). Non dovrebbero esserci troppe differenze con la 17.04.

È più pratico se invece di usare una seconda chiavetta USB il file "https://github.com/Oxalin/ryzen-test/archive/master.zip" lo scarichi da Firefox su Ubuntu e lo apri usando l'interfaccia grafica, facendo "Open With".





Poi clicca extract, ed estrai nella directory di default (la "home")





Poi clicca "show files"



Clicca sulla cartella creata



Premi tasto destro nello spazio vuoto e poi "open in terminal"



Per eseguire lo script digita:

./kill-ryzen.sh

Poi rispondi "Y" alla domanda che fa; deve scaricare dei file. Una volta fatto, inizerà il test.

[s12a]

Originariamente inviato da Ozozuz

Ho notato che alla fine anche ubuntu crasha, ma l'errore é diverso. Non si parla di seg-fault ma "tra le altre cose" di coredump.
La conclusione é sempre la stessa ? Non mi ritrovo AMD che tra un paio di settimane mi dice che tutto funziona e mi rimanda la stessa cpu indietro ? :c

https://image.prntscr.com/image/xe88...qstg5OEQMw.png
https://image.prntscr.com/image/CVgP...WEo63lVXXQ.png

Credo sia sempre un errore correlato. Un segmentation fault è per definizione quando il programma legge o (scrive) in una zona di memoria non autorizzata (ed il kernel del sistema operativo se ne accorge). Se questo tipo di errore accade, può anche succedere che lo stesso avvenga in una zona di memoria autorizzata ma comunque non valida. Il tuo output dice che è stata trovata un'istruzione in linguaggio macchina (opcode) non valida. La tipologia di errore è la stessa, ma è diversa la manifestazione.

Su Phoronix c'era uno screenshot con un errore simile nello stesso test (invalid opcode).

https://i.imgur.com/yFovv9W.jpg

(fonte: https://www.phoronix.com/scan.php?pa...est-Stress-Run)

[alexsky8]

Originariamente inviato da s12a

https://imgur.com/a/sv5r3

Mi sono appena reso conto che le istruzioni date in precedenza erano forse troppo sommarie e danno troppe cose per scontato. Ecco istruzioni passo-passo che usano Ubuntu 17.10 che ho linkato poco sopra in versione beta (dovrebbe uscire domani). Non dovrebbero esserci troppe differenze con la 17.04.

È più pratico se invece di usare una seconda chiavetta USB il file "https://github.com/suaefar/ryzen-test/archive/master.zip" lo scarichi da Firefox su Ubuntu e lo scompatti ad esempio in Downloads usando l'interfaccia grafica, facendo "Open With".

provato ora la 17.10 live su chiavetta con la scheda Gigabyte Gaming 5 e finalmente zero problemi cosa che invece la 17.04 dava

quindi chi ha gigabyte o ha problemi scarichi subito la 17.10 segnalata da s12a

[alexsky8]

fra l altro e stato eliminato anche il problema che vedeva 1 o pochi core
ora li vede tutti 16



ho rifatto il test anche in OC CPU e RAM e per ora sta girando senza problemi

[s12a]

Originariamente inviato da ozozuz

Provata la 17.10 da live e non da VM e non crasha, cosa vuol dire questo, che tutti gli errori di prima venivano da altro e non dal bug? Non capisco :/

Papugo1980 aveva riportato che non si presenta in maniera regolare; dipenderà dal tipo di carico e dalle condizioni del PC (con una VM ad esempio ci sono anche i processi del sistema host. Ipotesi)

http://www.hwupgrade.it/forum/showpo...2&postcount=29

Originariamente inviato da papugo1980

Riguardo al test su Linux io l ho fatto 4 volte :
La prima e la seconda volta ha dato subito errore
La terza no infatti ero arrivato a 40 minuti e allora ho stoppato
La quarta volta anche subito l errore

[BuRn]

Originariamente inviato da s12a

Credo sia sempre un errore correlato. Un segmentation fault è per definizione quando il programma legge o (scrive) in una zona di memoria non autorizzata (ed il kernel del sistema operativo se ne accorge). Se questo tipo di errore accade, può anche succedere che lo stesso avvenga in una zona di memoria autorizzata ma comunque non valida. Il tuo output dice che è stata trovata un'istruzione in linguaggio macchina (opcode) non valida. La tipologia di errore è la stessa, ma è diversa la manifestazione.

Su Phoronix c'era uno screenshot con un errore simile nello stesso test (invalid opcode).

https://i.imgur.com/yFovv9W.jpg

(fonte: https://www.phoronix.com/scan.php?pa...est-Stress-Run)

Ciao, scrivo da interessato all'acquisto di 1700 e per ora mi sto trattenendo perchè tra i miei utilizzi ci sarebbero sicuramente quelli incriminati (mi occupo di sviluppo sw e avere tanti core su cui far partire immagini docker mi farebbe comodo).

Premesso che non mi occupo di sistemi operativi, l'utilizzo di linguaggi dove si agisce direttamente sulla memoria è un lontano ricordo e la conoscenza di come funziona una CPU sono quelle mere basi dei corsi universitari, secondo me il problema sta venendo sminuito.

La CPU non sa di star eseguendo istruzioni su Linux o di star compilando con gcc, la CPU processa le istruzioni e basta. Come diceva s12a, se si va a toccare una zona di memoria al di fuori di quella riservata dal kernel si ottiene un segfault, ma se si sbaglia indirizzo e il kernel non interviene possono succedere altre cose spiacevoli, si potrebbero ad esempio saltare delle istruzioni, causando dei crash all'avere qualche risultato sbagliato (pare che l'errore stia nell'indirizzo contenuto nel registro del program counter).

Probabilmente gcc presenta dei pattern di istruzioni che rendono probabile che il problema si manifesti, ma questo non esclude in alcun modo che non si presenti altrove.

Qui c'è un articolo blog-post:
http://fujii.github.io/2017/06/23/ho...luts-on-ryzen/

E qui c'è un post su phoronix di Matt Dillon, uno degli sviluppatori che per primo ha tracciato il bug:
https://www.phoronix.com/forums/foru...498#post955498

Sono cose che circolano da un po', comunque buona lettura.

Sarei curioso di capire alcune cose:
- Dillon parlava di un bug relativo all'SMT, non ho capito tra le decine di post sui forum se chi riscontra il problema lo riscontra anche con l'SMT disabilitato, perchè nel caso sarebbero due anomalie distinte (non necessariamente entrambe legate alla CPU, come sottolineava Dillon, ha potuto fare i test solo sulla sua configurazione)
- Quante persone riscontravano instabilità nel daily use che sono scomparse dopo l'RMA: Ryzen ha avuto i suoi problemi con le memorie, con i bios e con le schede madri, ma magari non tutti i problemi che gli utenti riscontravano erano legati a quello, magari una parte erano legati a questo problema
- Quante sono percentualmente le CPU bacate: sembra che la maggior parte di chi fa il test con cpu più "vecchie" scopre di avere il bug

Difficile fare una statistica su un forum, ma comunque i vostri commenti sono ben accetti.

Originariamente inviato da BuRn

--

Se compri su Amazon il 1700 sicuramente avrai uno post settimana 25 che da come sembra per la maggior parte sono esenti da bug (io ho ricevuto un ottimo esemplare settimana 34 proprio oggi),

Con questa nuova CPU la stabilità, per quanto assurdo sembra migliore, voltaggi più bassi, temperature più basse. Tra l'altro io penso che un buon 80% se non anche 90% di cpu prodotte nei primi mesi siano affette dal bug. Personalmente ne ho provate 2, entrambe con bug.

[Gioz]

Originariamente inviato da Ozozuz

So cos'é un coredump ma non riesco a immaginare da cosa possa essere stato provocato, la memoria era libera e 169secondi sono troppo pochi per saturare 8gb a quanto ho capito

scusami, avevo interpretato male il tuo post, ma ogni volta si interrompe in questo modo?

[alexsky8]

Originariamente inviato da BuRn

Difficile fare una statistica su un forum, ma comunque i vostri commenti sono ben accetti.

la mia era una CPU settimana 16 ed aveva il bug
non riscontravo alcuna anomalia nell'operatività ma avevo notato anomalia nella gestione delle temperature e Vcore cosa che con l'ultima CPU settimana 33 non ho

un consiglio però lo darei
andrei tranquillamente ad acquistare un sistema ryzen ma magari nel tuo caso lo farei con Amazon vista la politica semplificata nella gestione dei resi

[s12a]

Originariamente inviato da BuRn

Sarei curioso di capire alcune cose:
- Dillon parlava di un bug relativo all'SMT, non ho capito tra le decine di post sui forum se chi riscontra il problema lo riscontra anche con l'SMT disabilitato, perchè nel caso sarebbero due anomalie distinte (non necessariamente entrambe legate alla CPU, come sottolineava Dillon, ha potuto fare i test solo sulla sua configurazione)

Sembra che disabilitare il µOpCache aiuti più di disabilitare l'SMT. Tuttavia non tutte le schede madri permettono la prima opzione.

https://www.phoronix.com/forums/foru...lt-issue/page4
https://www.reddit.com/r/Amd/comment...8w&sh=ede4db77
https://www.reddit.com/r/Amd/comment...iu&sh=63037a3a
https://www.reddit.com/r/Amd/comment...bt&sh=501d2e0e
https://www.reddit.com/r/Amd/comment...3l&sh=f885717c
https://www.reddit.com/r/Amd/comment...x5&sh=634348ed

[alexsky8]

Originariamente inviato da moob1

Se compri su Amazon il 1700 sicuramente avrai uno post settimana 25 che da come sembra per la maggior parte sono esenti da bug (io ho ricevuto un ottimo esemplare settimana 34 proprio oggi),

Con questa nuova CPU la stabilità, per quanto assurdo sembra migliore, voltaggi più bassi, temperature più basse. Tra l'altro io penso che un buon 80% se non anche 90% di cpu prodotte nei primi mesi siano affette dal bug. Personalmente ne ho provate 2, entrambe con bug.

lo penso pure io ad ogni modo ad oggi sussiste la correlazione fra BUG e CPU uscite "meno bene"

[ccmarco2004]

Originariamente inviato da s12a

Un segmentation fault è per definizione quando il programma legge o (scrive) in una zona di memoria non autorizzata (ed il kernel del sistema operativo se ne accorge). Se questo tipo di errore accade, può anche succedere che lo stesso avvenga in una zona di memoria autorizzata ma comunque non valida. Il tuo output dice che è stata trovata un'istruzione in linguaggio macchina (opcode) non valida. La tipologia di errore è la stessa, ma è diversa la manifestazione.

Invalid Opcode e Memory Segfault sono due eccezioni di tipo differente, "trappate" da vettori separati, che a seconda delle opzioni di esecuzione del Kernel possono conseguire in un memory dump.

E' però vero che condividono molti meccanismi scatenanti ed in entrambi i casi il thread interessato viene "ucciso".

Finezze a parte, penso che ci sia una profonda differenza tra l'eseguire una distro di linux sotto VM e la sua esecuzione esclusiva sulla stessa macchina, in entrambi casi la procedura è troppo lunga e soggetta a troppe varianti.

E' plausibile pensare che in AMD abbiano sviluppato un tool software molto più sbrigativo per evidenziare il bug, magari sarebbe ora di distribuirlo, così come è successo quando Intel è stata messa all'angolo dai media ai tempi del Pentium DIV bug.

[digieffe]

Originariamente inviato da BuRn

secondo me il problema sta venendo sminuito.

La CPU non sa di star eseguendo istruzioni su Linux o di star compilando con gcc, la CPU processa le istruzioni e basta. Come diceva s12a, se si va a toccare una zona di memoria al di fuori di quella riservata dal kernel si ottiene un segfault, ma se si sbaglia indirizzo e il kernel non interviene possono succedere altre cose spiacevoli, si potrebbero ad esempio saltare delle istruzioni, causando dei crash all'avere qualche risultato sbagliato (pare che l'errore stia nell'indirizzo contenuto nel registro del program counter).

Probabilmente gcc presenta dei pattern di istruzioni che rendono probabile che il problema si manifesti, ma questo non esclude in alcun modo che non si presenti altrove.

Difficile fare una statistica su un forum, ma comunque i vostri commenti sono ben accetti.

... e quei pattern di istruzioni si potranno presentare anche in software futuri. Soprattutto se non verrà pubblicato qual'è/quali sono il pattern che lo genera/no.

Ps: non mi date dell'hater di amd, questo mio onesto pensiero (già espresso da tempo), che BuRn ha precisato meglio, è solo DOVUTO alle "minimizzazioni".
Se dovessi parlare di amd relativamente a questo bug avrei ben altri dubbi da sollevare, ma non sono un hater né ho tempo da spendere, lascio il tempo ad amd di sistemare.

[SpongeJohn]

Quanto sta accadendo ora é l'esatta riproduzione del non problema delle rx che assorbivano troppa potenza dallo slot pci. Un problema inesistente per il 99% della popolazione (perché vorrei ricordare che la percentuale di utilizzo di linux rispetto a win é dell'1%).

E no. L'errore in compilazione su win é assai molto piú raro e quasi non riproducibile.

No: gcc e i kernel linux non sono ottimizzati per ryzen, una ricerca di due minuti e si viene a sapere che i kernel e gcc sono ottimizzati genericamente per "AMD" e solo per l'architettura bd... Non scherzo.

E ancora: no, compilare in quel modo non é comune ne lo diverrà in futuro in nessun scenario d'utilizzo per l'utente comune ( ed ipotizzare che mandare in compilazione su tutti i core diventi di uso comune nell'uso quotidiano: é pura follia. Ma per favore...) che ripeto: corrisponde al 99% della popolazione che compra queste cpu.

A stare a sentire l'opinione dell'uomo comune anche le rx fondono gli slot pci. Peccato che non é cosí.

Purtroppo io la cpu devo rivenderla su questo forum nel momento in cui decideró di cambiarla. Altrimenti con il cavolo che avrei fatto un rma, lo faccio solo perché l'utenza di un certo tipo va assecondata quando ti metti dalla parte del venditore, anche nelle psicosi.

Se dall'oggi al domani venisse fuori che é un errore software, dato che ad esempio il solo aver aperto hwinfo64 inficia la stabilità delle build a base ryzen ( e che quindi il kernel linux, ne il compilatore, che ripeto: non sono ottimizzati per niente: in realtà hanno probabilmente molto a che fare con la non stabilità del sistema) cosa dovremmo dire? Ennesimo: ops abbiamo dato addosso senza tregua ad amd mentre si sorvola sulle cappellate di intel?
Ci sono i link in questa discussione dove si evince (se solo la gente li leggesse...) Che l'ht su skylake e kaby inficia la stabilità del sistema su alcune operazioni sotto linux. Bug scoperto un'anno prima che intel lo correggesse senza nel mentre dare notizia al pippo franco di turno...

Se non mi credete, date uno sguardo al ng degli sviluppatori di gcc. Le generiche ottimizzazioni che vengono usate anche ora quando si ha una cpu amd: sono le vecchie usate per bd... Due cpu che non hanno niente in comune.

[s12a]

Originariamente inviato da Ozozuz

Provata la 17.10 da live e non da VM e non crasha, cosa vuol dire questo, che tutti gli errori di prima venivano da altro e non dal bug? Non capisco :/

Da Windows mediante il WSL con Ubuntu o mediante VM, puoi verificare se prima di eseguire il test, digitando la seguente riga il problema viene mitigato notevolmente?

sudo sysctl kernel.randomize_va_space=0

Così si disabilita l'Address Space Layout Randomization. Sembra che sia una feature che accentua notevolmente l'insorgenza di questi errori di segfault su Linux. È attiva di default (valore=2), ma non so se abbia veramente effetto quando l'OS non gira nativamente sulla macchina. Wikipedia riporta che Windows usa questa feature solo in particolari casi.

Se ne controlla lo stato mediante uno dei seguenti comandi (non è rilevante, ma ho notato che kill-ryzen.sh usa il secondo; solitamente riporta "2", dunque attivato):

sysctl kernel.randomize_va_space

cat /proc/sys/kernel/randomize_va_space

[digieffe]

... e si continua a minimizzare e fare confronti con intel e con altre situazioni che non c'entrano nulla. Perchè quest'ultima necessità? mal comune (bug irrisolti) mezzo gaudio?

si parla di ottimizzazioni generiche per BD o amd, ma cosa centra? una cpu deve poter eseguire anche codice non ottimizzato!

e si parla di linux e/o di gcc quando se pur in maniera minima il problema compare è riproducibile in altri ambiti! (wsl, cygwin e visualstudio ?)

dalle ultime informazioni di è visto che si verifica anche con l'utilizzo di un solo core.

è chiaro cosa sia un pattern di istruzioni? da quanto si legge sembra proprio di no. Spero che qualcuno abbia voglia di spiegarlo adeguatamente.

pattern di istruzioni, motivo per il quale si potrà presentare anche in software futuri di qualsiasi natura che presentino la stessa situazione.


Non ancora è chiaro in quale status della cpu l'errore emerga, ma soprattutto non si sa se l'errore si presenta su base probabilistica o deterministica. Il che la dice tutta sulla natura di quest'errore!

e per favore basta con le minimizzazioni

Ps: mi scuso se non ho tempo di argomentare nei dettagli, spero che qualcuno se ne prenda la briga.

[s12a]

Il primo screenshot, che non riporta errori dal kernel, potrebbe essere correlato a problemi di saturazione memoria o di spazio nel filesystem temporaneo creato per la root dal sistema, anche se il ramdisk creato dal test è ben lungi dall'essere riempito (non ho investigato il motivo, ma credo sia il motivo principale per il quale eseguire a lungo il test tramite Live porta inevitabilmente ad interruzioni di questo genere. Puoi monitorare la situazione con il comando 'df'). Il secondo invece sembra proprio il problema della CPU.

Nelle varie prove che ho fatto ieri mediante VM usando varie distro Live ho notato che i problemi di memoria o esaurimento spazio si ripetono sempre dopo circa lo stesso tempo di esecuzione del test, a seconda delle impostazioni iniziali di numero loop e thread dello stesso. Per cui mi sto un po' ricredendo sulla validità di una distribuzione Live come test come originariamente consigliato: sembra un po' troppo facile incappare in falsi positivi (o altri problemi), a meno di analizzare nel dettaglio l'errore.

Errori espliciti di segfault ed invalid opcode dovrebbero invece uscire fuori in maniera non deterministica ed essere indicativi del bug. Io non ne ho mai visti con la mia configurazione.

[digieffe]

occhio ad ubuntu 17.10

qui http://fujii.github.io/2017/06/23/ho...luts-on-ryzen/ tra i requisiti dice che è necessario che gcc e bash non siano PIE.

"Check your gcc and bash are not PIE (Position-independent executables). In Ubunt 17.04, gcc and bash aren’t PIE, but clang and dash are PIE."

ma nella 17.10 tutti gli eseguibili dovrebbero essere PIE. Per la verifica seguire le istruzioni nel link.


dunque non so in questa condizione "PIE" quanto sia valido il test.