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

[ccmarco2004]

Originariamente inviato da bagnino89

Sarà anche un problema insignificante, -cut

non si può propio dire che sia insignificante, coinvolge in primo luogo una fascia di utenti che fa un utilizzo "non ludico" del personal computer e che ha scelto Ryzen in virtù dell'alto numero di cores per velocizzare le fasi di compilazione di codice sorgente saturando le risorse del processore.

Io direi che è un problema importante.

[s12a]

Originariamente inviato da Ozozuz

Il tempo massimo trascorso prima dell'errore é stato di 8 minuti, altre volte come da screen succede entro i 5, immagino siano tutte conferme del fatto che la cpu sia fallata no ? Posso inviare AMD senza paura che facciano storie ?

Non dovrebbero fare storie. Le Virtual Machine sono usate in ambiti seri potenzialmente per gli stessi tipi di workload. L'errore è lo stesso che hanno altri usando Linux direttamente, e non dovrebbe accadere.

edit: 4 4 anche qui
https://image.prntscr.com/image/Zuo8...fKc7zl59nA.png

E diminuendo ulteriormente loop e processi? Direi che sia fallata, comunque.

[ccmarco2004]

Originariamente inviato da Mister D

Sì hai ragione ma se non lo fa nemmeno intel a volte come puoi aspettarti che lo faccia uno più piccolo? E con questo NON giustifico né AMD né Intel:
https://www.tomshw.it/cpu-intel-rece...hreading-86594
-cut

Nella fattispecie Intel oltre a pubblicare il technical sheet ha risolto il problema con una modifica del microcodice prontamente distribuita ai produttori di mainboard, il confronto che porti non regge.

Ritengo lodevole la creazione di questo 3ad, dopo i vari attacchi ed il denial perpetrato nel 3ad principale questo è l'unico modo per fare un'informazione obiettiva riguardo a questo bug, in un clima "sereno".

Originariamente inviato da ccmarco2004

Nella fattispecie Intel oltre a pubblicare il technical sheet ha risolto il problema con una modifica del microcodice prontamente distribuita ai produttori di mainboard, il confronto che porti non regge.

Ritengo lodevole la creazione di questo 3ad, dopo i vari attacchi ed il denial perpetrato nel 3ad principale questo è l'unico modo per fare un'informazione obiettiva riguardo a questo bug, in un clima "sereno".

Troppi fanboy nel thread principale

[Tcx]

Attenzione su distribuzioni diverse da ubuntu l'errore potrebbe anche non essere il segfault...ma magari qualche pacchetto/libreria che manca o qualcosa del genere...ad esempio a me su Fedora crashava subito ma dal log ho scoperto che non crashava la compilazione ma la configurazione perchè non trovava un "pacchetto"...una volta installato è partito e non mi ha dato problemi (o meglio dopo circa 50 minuti è andato in errore ma aveva saturato il ramdisk...ho 16Gb di ram). Per sicurezza ho provato anche da live ubuntu...

[s12a]

Originariamente inviato da Ozozuz

Resta il fatto che la VM con ubuntu a paritá di settaggi non crasha, c'é da dire che quella con Mint porta la cpu a 90% mentre quella con ubuntu al ~40, quindi immagino sia sua la colpa.

Strano per Ubuntu. Per sicurezza, hai controllato le impostazioni per quella VM? Il seguente comando da terminale (usato da kill-ryzen.sh) quanti core rileva?

cat /proc/cpuinfo | grep -i -E "(model name|microcode)"

Usando VMWare Workstation 14 Player con una VM di OpenSUSE Tumbleweed mi vengono rilevati 4 core (quelli del effettivi processore ed assegnati), e 4 ne usa durante il test (cpu occupata al 100% - cosa che anche Windows mostra).

Originariamente inviato da Tcx

Attenzione su distribuzioni diverse da ubuntu l'errore potrebbe anche non essere il segfault...ma magari qualche pacchetto/libreria che manca o qualcosa del genere...ad esempio a me su Fedora crashava subito ma dal log ho scoperto che non crashava la compilazione ma la configurazione perchè non trovava un "pacchetto"...una volta installato è partito e non mi ha dato problemi (o meglio dopo circa 50 minuti è andato in errore ma aveva saturato il ramdisk...ho 16Gb di ram). Per sicurezza ho provato anche da live ubuntu...

Confermo e successo anche a me con OpenSUSE.

[evil weasel]

Originariamente inviato da Ozozuz

Il tempo massimo trascorso prima dell'errore é stato di 8 minuti, altre volte come da screen succede entro i 5, immagino siano tutte conferme del fatto che la cpu sia fallata no ? Posso inviare AMD senza paura che facciano storie ?

edit: 4 4 anche qui

Per avere la certezza dovresti appunto controllare che quando crasha non sia satura la memoria.
Il fatto che il problema si prensenti una volta a 5 minuti ed una ad 8 mi fa pensare che la tua CPU sia fallata ed il crash non dipenda dalla RAM piena.

p.s. non capisco perchè vi ostiniate ad usare quella porcheria di ubuntu quando fedora è ugualmente facile da usare e funziona correttamente.

Arrivato Ryzen 7 1700 da Amazon. Settimana 34

[alexsky8]

Originariamente inviato da moob1

Arrivato Ryzen 7 1700 da Amazon. Settimana 34

facci saper come ti va rispetto al vecchio

[papugo1980]

Originariamente inviato da moob1

Arrivato Ryzen 7 1700 da Amazon. Settimana 34

Per favore controlla pure online se corrisponde la settimana di produzione tramite seriale

[Alex656]

Originariamente inviato da moob1

Troppi fanboy nel thread principale

Credo di saperne qualcosa

[Gioz]

Originariamente inviato da Ozozuz

ramdisk é disabilitato, in entrambi i test.
btw questo é un 4 4 su VM

questo dovrebbe essere il risultato "positivo" al test.

Originariamente inviato da papugo1980

Per favore controlla pure online se corrisponde la settimana di produzione tramite seriale

Delivery Date: 2017-09-30
MFG Date: 2017-09-29


sembra molto recente.

edit: 10 minuti di test senza alcun problema. Prima l'errore arrivava in pochi secondi.

edit2: in overclock un altro livello: http://www.hwupgrade.it/forum/showpo...ostcount=20732

[s12a]

Originariamente inviato da evil weasel

p.s. non capisco perchè vi ostiniate ad usare quella porcheria di ubuntu quando fedora è ugualmente facile da usare e funziona correttamente.

L'idea era usare una procedura standardizzata, testata, ed il più semplice possibile con qualcosa che bene o male più utenti hanno esperienza di utilizzo o familiarità. Credo che lo script sia stato testato principalmente con Ubuntu, sia dall'autore che dagli utenti.

Ad esempio, poco fa ho provato con Mint Cinnamon (che dovrebbe essere molto simile ad Ubuntu) in modalità "live" in una VM ed ho incontrato problemi a causa del fatto che i repository di default non erano aggiornati (risolti con un "apt-get update").

Ho provato anche Fedora in VM (installata), ma per qualche motivo - suppongo versioni dei pacchetti diverse da quelle usate da Ubuntu - il test fallisce poco prima che inizi effettivamente a compilare, dopo la fase di "configure"; non ho voluto perdere troppo tempo a capire perché (EDIT: alla fine ho risolto, era un pacchetto mancante: "gcc-c++").

Visto che la maggior parte degli utenti non ha dimestichezza con Linux e che anche chi ha un po' di esperienza potrebbe avere problemi, meglio evitarne di ulteriori che diluiscano gli sforzi e facciano perdere tempo.

[Gioz]

Originariamente inviato da Ozozuz

Quindi solo io ho beccato un week 34 piú fallato di uno della 7 ?

è possibile, la questione "settimana" è stata derivata da utenti come noi analizzando le cpu che restituiscono il segfault e quelle ricevuta come rma, non è scontato che tutte le cpu recenti siano esenti.

[s12a]

Originariamente inviato da moob1

edit: 10 minuti di test senza alcun problema. Prima l'errore arrivava in pochi secondi.
edit2: in overclock un altro livello: http://www.hwupgrade.it/forum/showpo...ostcount=20732

Per curiosità, in overclock lo mostra il segfault durante il test di compilazione?
Chissà se non sia anche un ottimo modo per verificare la stabilità effettiva della CPU in tale condizione.

[evil weasel]

Sarà anche una distro certificata per alcuni sistemi ma, diciamocela tutta, funziona dimmerda con ryzen.
Poi oh, liberi di fare come preferite, io avevo proposto di usare un'altra distro perchè testare la CPU con un sistema operativo che riesce ad usare un solo core non mi sembra una idea geniale.

[s12a]

Il discorso è giusto, ma servono istruzioni replicabili, e con facilità. Fedora live ad esempio di default potrebbe non funzionare di default con il ryzen-test - non ho ancora provato però (avevo scaricato la NetInstall perché sono 480 MB contro 1.5GB).

[SpongeJohn]

Originariamente inviato da ccmarco2004

Nella fattispecie Intel oltre a pubblicare il technical sheet ha risolto il problema con una modifica del microcodice prontamente distribuita ai produttori di mainboard, il confronto che porti non regge.

Ritengo lodevole la creazione di questo 3ad, dopo i vari attacchi ed il denial perpetrato nel 3ad principale questo è l'unico modo per fare un'informazione obiettiva riguardo a questo bug, in un clima "sereno".

Veramente, da che fu scoperto quel bug alla pubblicazine del fix, passò circa un'anno, e da intel non venne rilasciata nessuna comunicazione. Chi ha scoperto quel bug ha saputo del fix solo leggendo poi dei "bugfix" pubblicati da intel a giugno.
https://lists.debian.org/debian-deve.../msg00308.html
Ed aggiungo da Tom's:

"Difficile comunque stabilire la gravità del bug, dato che è stato riscontrato da un "toolchain developer" di OCaml e dalla comunità, che ha indagato per circa un anno."

Quanto scritto sopra non giustifica AMD. Però va aggiunto quanto segue (sempre da Tom's):

"Se siete un utente comune non è il caso che vi facciate prendere dal panico: se tutti i vostri software hanno funzionato a dovere sino a oggi, potete continuare a usare il PC come al solito."

[s12a]

Originariamente inviato da s12a

Il discorso è giusto, ma servono istruzioni replicabili, e con facilità. Fedora live ad esempio di default potrebbe non funzionare di default con il ryzen-test - non ho ancora provato però (avevo scaricato la NetInstall perché sono 480 MB contro 1.5GB).

Per la cronaca, ho provato con Fedora Live: il file system della partizione di root dopo un po' che si iniziano a scaricare le dipendenze necessarie per far partire ryzen-test va in sola lettura per eccessivo spazio occupato ed il processo si blocca. L'ultima daily build di Ubuntu 17.10, sempre in modalità live (prima del rilascio ufficiale di domani, immagino) procede senza problemi con il test. Impiega inoltre tutta la CPU.