[Thread Ufficiale] CPU Zen 14/12/7nm: AMD Ryzen!

[Cfranco]

Rdrand è un' istruzione aggiunta su Ivy bridge, mentre su AMD è arrivata nel 2015
Peraltro a partire da Broadwell e Zen è stata praticamente rimpiazzata da RdSeed.

[Alex656]

Originariamente inviato da Gigibian

Spero davvero che sia così. La mia scimmia sta impazzendo.

https://www.phoronix.com/scan.php?pa...-Systemd-Maybe

[bremen79]

"The Ryzen 3000 Boot Problem With Newer Linux Distros Might Be Due To RdRand Issue"

"For those that missed my launch day article, check it out for more details and then all the benchmarks for when running very performant on the likes of Ubuntu 18.04 LTS where the issue does not occur."

Usando Ubuntu 18.04 LTS o simili non si presenta nessun problema con Zen2, anche usando gli ultimissimi kernel, perchè in quel caso RdRand non viene proprio chiamato in causa.

https://www.phoronix.com/scan.php?pa...-Systemd-Maybe

Ad esempio DragonFlyBSD non usa minimamente RdRand ma hanno dovuto fixare uno stupido baco per permettere il boot.
https://www.phoronix.com/scan.php?pa...x=DragonFlyBSD

"The three-line patch is now present in DragonFlyBSD Git and thus allowing their latest daily images to hopefully boot fine on all new AMD Zen 2 systems. I'll have some Zen 2 + BSD benchmarks in due course."

"The Linux RDRAND issue is more related to its userland conditionalizing the use of the instruction and then behaving badly when it didn't work as expected. This is more an issue with over-optimization by Linux. No libraries or applications should be using those extensions directly from userland, but the Linux devs sometimes throw caution to the wind in order to make things go faster. "

https://www.phoronix.com/forums/foru...n-2-processors

Quindi prima di cominciare un'altra "saga" come quella dei primi lotti di Ryzen che davano segfault in linux, sarebbe meglio aspettare un attimo.
Per la cronaca ho un 1800X, del famoso primo batch, e lo uso per fare simulazioni sotto linux dal dayone.

[Gigibian]

Originariamente inviato da Cfranco

Rdrand è un' istruzione aggiunta su Ivy bridge, mentre su AMD è arrivata nel 2015
Peraltro a partire da Broadwell e Zen è stata praticamente rimpiazzata da RdSeed.

Grazie delle info, mai approfondito queste cose

Da quello che leggo qui:

https://software.intel.com/en-us/blo...and-and-rdseed

"The decision process for which instruction to use is mercifully simple, and based on what the output will be used for.

If you wish to seed another pseudorandom number generator (PRNG), use RDSEED

For all other purposes, use RDRAND

That's it. RDSEED is intended for seeding a software PRNG of arbitrary width. RDRAND is intended for applications that merely require high-quality random numbers."

Probabilmente systemd non implementa un PRNG, e preferisce avere un numero random affidabile dalla cpu.

Era meglio che AMD togliesse direttamente il supporto a rdrand allora, piuttosto che lasciarlo bacato.

[Alex656]

Don't panic!
https://www.forbes.com/sites/jasonev...gpus-on-linux/

Soller also notes that an AMD firmware update should resolve the issue for people using distros that don't regularly re-roll their ISOs, but there's no firm timeline on that yet.

[Gigibian]

Originariamente inviato da bremen79

"The Ryzen 3000 Boot Problem With Newer Linux Distros Might Be Due To RdRand Issue"

"For those that missed my launch day article, check it out for more details and then all the benchmarks for when running very performant on the likes of Ubuntu 18.04 LTS where the issue does not occur."

Usando Ubuntu 18.04 LTS o simili non si presenta nessun problema con Zen2, anche usando gli ultimissimi kernel, perchè in quel caso RdRand non viene proprio chiamato in causa.

https://www.phoronix.com/scan.php?pa...-Systemd-Maybe

Ad esempio DragonFlyBSD non usa minimamente RdRand ma hanno dovuto fixare uno stupido baco per permettere il boot.
https://www.phoronix.com/scan.php?pa...x=DragonFlyBSD

"The three-line patch is now present in DragonFlyBSD Git and thus allowing their latest daily images to hopefully boot fine on all new AMD Zen 2 systems. I'll have some Zen 2 + BSD benchmarks in due course."

"The Linux RDRAND issue is more related to its userland conditionalizing the use of the instruction and then behaving badly when it didn't work as expected. This is more an issue with over-optimization by Linux. No libraries or applications should be using those extensions directly from userland, but the Linux devs sometimes throw caution to the wind in order to make things go faster. "

https://www.phoronix.com/forums/foru...n-2-processors

Quindi prima di cominciare un'altra "saga" come quella dei primi lotti di Ryzen che davano segfault in linux, sarebbe meglio aspettare un attimo.
Per la cronaca ho un 1800X, del famoso primo batch, e lo uso per fare simulazioni sotto linux dal dayone.

Non si inizia nessuna "saga" a mio parere.
Pero' nemmeno bisogna avere le fette di prosciutto sugli occhi.

Il fatto che il tuo 1800X non abbia problemi, non rende lecito negare i problemi ed i richiami di CPU di migliaia di persone.

In ogni caso, questa parte scritta da Larabel che hai quotato:

""The Linux RDRAND issue is more related to its userland conditionalizing the use of the instruction and then behaving badly when it didn't work as expected. This is more an issue with over-optimization by Linux. No libraries or applications should be using those extensions directly from userland, but the Linux devs sometimes throw caution to the wind in order to make things go faster. "

Non è applicabile in questo caso. Systemd è obbligato ad usare quell'istruzione perchè non puo' chiamare la syscall getrandom() in quanto al boot il kernel non ha abbastanza entropy.

[Gigibian]

Originariamente inviato da Alex656

Don't panic!
https://www.forbes.com/sites/jasonev...gpus-on-linux/

Soller also notes that an AMD firmware update should resolve the issue for people using distros that don't regularly re-roll their ISOs, but there's no firm timeline on that yet.

Bene! incrociamo le dita.

[ninja750]

IMPORTANTE

leggendo nel web amd ha fatto una precisazione per quelli preoccupati per voltaggi e mhz in idle: causa nuova architettura è necessario NON usare nessun tool in background come hwinfo64 ecc e usare SOLO ryzen master oppure SOLO cpu-z in questo modo non si ha un poll continuo di monitoring e si dovrebbe vedere circa 2200mhz e circa 0,9v in idle in combinazione con il piano ryzen balanced

usandoli insieme oppure usando hwinfo in background i core vengono sempre svegliati dal deep sleep e si vedranno sempre full mhz e full voltaggi

[Randa71]

Originariamente inviato da Gigibian

Non si inizia nessuna "saga" a mio parere.
Pero' nemmeno bisogna avere le fette di prosciutto sugli occhi.

Il fatto che il tuo 1800X non abbia problemi, non rende lecito negare i problemi ed i richiami di CPU di migliaia di persone.

In ogni caso, questa parte scritta da Larabel che hai quotato:

""The Linux RDRAND issue is more related to its userland conditionalizing the use of the instruction and then behaving badly when it didn't work as expected. This is more an issue with over-optimization by Linux. No libraries or applications should be using those extensions directly from userland, but the Linux devs sometimes throw caution to the wind in order to make things go faster. "

Non è applicabile in questo caso. Systemd è obbligato ad usare quell'istruzione perchè non puo' chiamare la syscall getrandom() in quanto al boot il kernel non ha abbastanza entropy.

Concordo. SE il problema HW esiste, esiste. Che poi possa essere aggirato/risolto è un discorso.
Ma che una CPU appena uscita abbia di questi problemi...mah...anche perchè non siamo + nella condizione di lancio dei primi Ryzen, dove di fatto era tutto nuovo....Avrebbero potuto porre + attenzione.....Come qcuno ha scritto era meglio che togliessero il supporto piuttosto che lasciare l'istruzione bacata....
Considerato che ZEN2 lo useranno anche per i Server...e il linux nei server è molto + presente..e considerato che con ZEN avevano già avuto problemi con linux.
Da quello che sto vedendo ho sempre + la sensazione che abbiano corso per arrivare primi...ma onestamente non ne capisco il motivo...vista l'assenza di novità da parte della concorrenza.
Mia personalissima opinione: con i problemi avuti al lancio non ci stanno facendo una grandissima bella figura...considerate le aspettative

[Bi7hazard]

Il ryzen 5 3600 essendo a 7nm ,pur avendo frequenze di clock superiori, dovrebbe scaldare leggermente di meno rispetto il 2600 giusto?

[Gyammy85]

Originariamente inviato da ninja750

IMPORTANTE

leggendo nel web amd ha fatto una precisazione per quelli preoccupati per voltaggi e mhz in idle: causa nuova architettura è necessario NON usare nessun tool in background come hwinfo64 ecc e usare SOLO ryzen master oppure SOLO cpu-z in questo modo non si ha un poll continuo di monitoring e si dovrebbe vedere circa 2200mhz e circa 0,9v in idle in combinazione con il piano ryzen balanced

usandoli insieme oppure usando hwinfo in background i core vengono sempre svegliati dal deep sleep e si vedranno sempre full mhz e full voltaggi

Non è la prima volta che sti programmi di monitoring causano problemi, pure nelle vga

[ninja750]

Originariamente inviato da Bi7hazard

Il ryzen 5 3600 essendo a 7nm ,pur avendo frequenze di clock superiori, dovrebbe scaldare leggermente di meno rispetto il 2600 giusto?

liscio vs liscio più o meno uguale

[ninja750]

altra info direttamente da AMD: con 3xxx non undervoltare, nemmeno con offset

la risultante sembra che la cpu boosti un pelo più su es 100mhz ma mediamente si avranno risultati peggiori

[Giux-900]

Originariamente inviato da Alex656

Don't panic!
https://www.forbes.com/sites/jasonev...gpus-on-linux/

Soller also notes that an AMD firmware update should resolve the issue for people using distros that don't regularly re-roll their ISOs, but there's no firm timeline on that yet.

Hopefully an AMD firmware update can work around this issue with the current ISOs for those distributions that do not regularly re-roll their ISOs.

Dal testo sembra che un fix via firmware può (''si spera'') risolvere i problemi di boot, ma a me rimane il dubbio che si limita solo a fare da workaround per il boot di linux, e non un fix in generale...

Io spero in nuove revisioni hardware on the road...

[Operapia]

Originariamente inviato da Gigibian

Puzza di RMA anche per i nuovi ryzen 3000.

https://linuxreviews.org/AMD_Ryzen_3..._distributions

Un bug HARDWARE abbastanza scandaloso.

Sembra che quando venga chiama l'istruzione cpu che genera numeri random, questa NON funziona, dice chè è stato effettivamente generato un numero random (non è vero) ma poi ritorna un errore generico.

"The bug in Ryzen 3000 series CPUs is different from the bug in earlier AMD chips - and by earlier we do not mean Ryzen 1000 or 2000 series CPUs who do not have this problem - we mean ancient APUs. Ryzen 3000 series CPUs will always fail to produce random data when RDRAND is called while older APUs fails to do so when returning from suspend to RAM. "

"This is a hardware bug in AMD CPUs. systemd is a piece of software. Software using the CPU instruction clzero or movbe should not have pages of code verifying that those instructions work as advertised. systemd freezing is simply a result of it being in charge very early in the boot process.

This is, in truth, AMDs fault. It is a hardware problem. The upcoming systemd 243 will, when released, work around this problem - it will not solve it because it can't actually fix what is a hardware problem."

Che macello AMD, che macello. Ho paura che anche destiny 2 non funzioni per lo stesso motivo.

A mio avviso tutti i problemi che stanno avendo questi nuovi ryzen, sarebbe bene aprire un thread specifico per le technical issue, così da tenerne meglio traccia e capire quando sono risolte...avvisando anche i possibili acquirenti.

E lo posti qui?
Era meglio se andavi a predicare il vangelo in un covo di jihadisti. ahahahahah

[capitan_crasy]

Originariamente inviato da Randa71

Concordo. SE il problema HW esiste, esiste. Che poi possa essere aggirato/risolto è un discorso.
Ma che una CPU appena uscita abbia di questi problemi...mah...anche perchè non siamo + nella condizione di lancio dei primi Ryzen, dove di fatto era tutto nuovo....Avrebbero potuto porre + attenzione.....Come qcuno ha scritto era meglio che togliessero il supporto piuttosto che lasciare l'istruzione bacata....
Considerato che ZEN2 lo useranno anche per i Server...e il linux nei server è molto + presente..e considerato che con ZEN avevano già avuto problemi con linux.
Da quello che sto vedendo ho sempre + la sensazione che abbiano corso per arrivare primi...ma onestamente non ne capisco il motivo...vista l'assenza di novità da parte della concorrenza.
Mia personalissima opinione: con i problemi avuti al lancio non ci stanno facendo una grandissima bella figura...considerate le aspettative

Non esageriamo...
Il primo Ryzen ha avuto un "grave problema" sulle istruzioni FMA3 che causava il blocco del sistema, risolta attraverso FIX BIOS...
Inoltre l'architettura ZEN supporta sulla carta (ma anche nella realtà) FMA4, ma AMD ha tolto il supporto per un presunto BUG/vulnerabilità proprio in questa istruzione.
Paradossalmente quasi nessuno conosce questi "gravi" problemi a livello hardware, eppure ha preso più piede il segfault che fra l'altro non è neanche un BUG ed è presente solo su determinate CPU costruite in uno specifico breve periodo...
Una CPU senza BUG è semplicemente utopia, col tempo le cose vanno al giusto posto, compresi i BIOS poco ottimizzati...

[Randa71]

Originariamente inviato da capitan_crasy

Non esageriamo...
Il primo Ryzen ha avuto un "grave problema" sulle istruzioni FMA3 che causava il blocco del sistema, risolta attraverso FIX BIOS...
Inoltre l'architettura ZEN supporta sulla carta (ma anche nella realtà) FMA4, ma AMD ha tolto il supporto per un presunto BUG/vulnerabilità proprio in questa istruzione.
Paradossalmente quasi nessuno conosce questi "gravi" problemi a livello hardware, eppure ha preso più piede il segfault che fra l'altro non è neanche un BUG ed è presente solo su determinate CPU costruite in uno specifico breve periodo...
Una CPU senza BUG è semplicemente utopia, col tempo le cose vanno al giusto posto, compresi i BIOS poco ottimizzati...

Tu che sei sicuramente più addentro di me in AMD, ma non potevano prendersi qualche mese in + x uscire magari più "easy"? oppure avevano scadenze dettate magari da azionisti o da situazioni che non conosco...e che quindi, sono usciti a luglio? O magari semplice fisiologico ritardo nello sviluppare le CPU e che quindi per rispettare la roadmap sono lo stesso usciti a luglio? Sono curioso su questa cosa....alla fine se uscivano a settembre, che sarebbe cambiato? domanda mia da ignorante..avrebbero avuto + tempo per sistemare le cose...Poi certo corretto dargli la giusta importanza anche perchè come hai giustamente e correttamente scritto sul discorso segfault, poi alla fine le persone di ricordano + delle notizie che sostanzialmente hanno fatto clamore

[Alex656]

Originariamente inviato da Giux-900

Dal testo sembra che un fix via firmware può (''si spera'') risolvere i problemi di boot, ma a me rimane il dubbio che si limita solo a fare da workaround per il boot di linux, e non un fix in generale...

Io spero in nuove revisioni hardware on the road...

Via firmware si dovrebbe sistemare definitivamente il problema dell'istruzione che non viene eseguita correttamente, non soltanto il boot di linux; bisogna comunque aspettare che sia AMD a comunicare qualcosa in proposito e, a quanto ne so, non l'ha ancora fatto; sicuramente a loro converrebbe un aggiornamento piuttosto che un intervento sull'hardware visto i costi che comporterebbe; stiamo a vedere.

[tartamania]

Originariamente inviato da Randa71

Tu che sei sicuramente più addentro di me in AMD, ma non potevano prendersi qualche mese in + x uscire magari più "easy"? oppure avevano scadenze dettate magari da azionisti o da situazioni che non conosco...e che quindi, sono usciti a luglio? O magari semplice fisiologico ritardo nello sviluppare le CPU e che quindi per rispettare la roadmap sono lo stesso usciti a luglio? Sono curioso su questa cosa....alla fine se uscivano a settembre, che sarebbe cambiato? domanda mia da ignorante..avrebbero avuto + tempo per sistemare le cose...Poi certo corretto dargli la giusta importanza anche perchè come hai giustamente e correttamente scritto sul discorso segfault, poi alla fine le persone di ricordano + delle notizie che sostanzialmente hanno fatto clamore

Pienamente daccordo.Utente medio come me che se acquista ora nuovo procio e scheda madre b450 li deve tenere nel cassetto perchè non funzionano è da sclerare.La gatta frettolosa...

[ysc]

Scusatemi..è un problema che si ripercuote anche in ambiente windows o solo linux ?

Inviato dal mio SM-G970F utilizzando Tapatalk