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

[s12a]

Originariamente inviato da digieffe

"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."

Mi sembra che dica "controllate che non lo siano".

I comandi dati per compilare GCC dal test sembrano forzarne la sua assenza con -fno-PIE comunque (fermo restando che non ho idea delle implicazioni di questo). Ecco uno screenshot da un test che sto facendo in questo momento con OpenSUSE installata in una VM (aveva anch'essa delle librerie mancanti, sempre relative a "gcc-c++"):

[digieffe]

Originariamente inviato da s12a

Mi sembra che dica "controllate che non lo siano".

I comandi dati per compilare GCC dal test sembrano forzarne la sua assenza con -fno-PIE comunque (fermo restando che non ho idea delle implicazioni di questo). Ecco uno screenshot da un test che sto facendo in questo momento con OpenSUSE installata in una VM (aveva anch'essa delle librerie mancanti, sempre relative a "gcc-c++"):

se non stiamo equivocano stiamo dicendo la stessa cosa: verificare che gcc e bash non siano PIE, giusto?

nella 17.04 dovrebbero essere NON PIE alias EXEC, quindi ok (ho apena controllato).

nella 17.10 dovrebbero essere PIE alias DYN, quindi NON ok

comunque meglio verificare

[s12a]

Originariamente inviato da Ozozuz

Ubuntu anche da subsystem é sempre stato "particolare" come errori, mentre Mint schiaffava direttamente una seg-fault lui era piú fantasioso.
Erano entrambi 4 4 e quando son crashati a circa 2-3gb occupati su 16, mi pare strano possa essere lui.

Non mi riferisco a tutta memoria fisica, ma a quella assegnata alla root di sistema, che suppongo deve potere essere in grado di eseguire un numero limitato di scritture per file temporanei, eventuali pacchetti, ecc.

Il motivo è che usando una distribuzione Live non vengono effettuate scritture direttamente sul supporto di avvio. Da quello che mi sembra di capire, viene creato un ramdisk (non compresso) dedicato per la root, di dimensioni abbastanza limitate. Ipotizzo che le voci di log create durante l'operazione contribuiscano a diminuire lentamente lo spazio libero.

Anche perché é crashato dopo 7 minuti, il primo tentativo per crashare causa saturazione ce ne ha messi ~25

Se con le stesse impostazioni succede ad intervalli di tempo non regolari, è probabilmente il problema della CPU, ma è sempre meglio analizzare nel dettaglio la cosa.

Proprio adesso ad esempio, dopo circa 19 minuti di test mi è fallito il test su OpenSUSE, incomprensibilmente per un errore nel codice sorgente andando a controllare build.log (Non stavo usando un ramdisk, ma la ram assegnata era solo 4GB, senza swapfile; non mi sembrava fosse satura ma non ci ho fatto troppa attenzione). Niente segfault od errori di opcode, solo "build failed" su tutti i loop contemporaneamente.

[evil weasel]

Originariamente inviato da 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%).

1% sono svariate migliaia di utenti, ti sembra un problema marginale?
A me no.

Originariamente inviato da SpongeJohn

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

Più raro ma non assente.
Il fatto che ora accada meno spesso non vuol dire che non sia un problema e soprattutto non vuol dire che in futuro il problema non possa presentarsi con una frequenza maggiore o anche in altri ambiti.

Originariamente inviato da SpongeJohn

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.

Questo è falso.
GCC permette, già dalla versione 6.*, di specificare march=znver1, le differenze passando da una impostazione MARCH ad un'altra sono presenti ed abbastanza significative.
Chi si lamentava di binari poco ottimizzati rispetto all'impostazione march=haswel usava GCC vecchio, in combinazione con altre impostazioni non consigliate (ad esempio -O3) a pochissima distanza dal lancio.
Aggiungo poi che malgrado march=hawsel producesse binari più efficienti lo faceva a discapito della stabilità.
Sul fatto che il kernel Linux sia poco ottimizzato per Ryzen io avrei da ridire, ad esempio XFR e C&Q hanno subito funzionato correttamente.
È Windows quello che ha avuto bisogno di un nuovo profilo energetico apposito e tutt'ora è comunque pieno di gente che bestemmia per far andare correttamente il C&Q.

Originariamente inviato da SpongeJohn

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.

Te lo ripeto, uso comune non vuol dire niente quando si parla di un prodotto distribuito nell'ordine delle decine/centinaia di migliaia di unità.
Anche fosse solo il 1% di utenti interessati siamo comunque di fronte a numeri esageratamente elevati.

Originariamente inviato da SpongeJohn

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

Questo, se possibile, è anche peggio perchè c'è il rischio di incendio.
Anche in questo caso, fosse solo il 1% la percentuale di schede utilizzate si parla di svariate migliaia di utenti.

Originariamente inviato da SpongeJohn

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.

Qui siamo proprio all'apoteosi.
Tu quindi ti saresti tenuto una CPU fallata per far risparmiare un reso alla amata AMD?
Tu e gli altri fenomeni nel thread ufficiale avete un attaccamento anomalo a questa azienda, manco fosse un vostro parente.
Queste son multinazionali dai fatturati esagerati, se fanno una cappellata è giusto che sistemino il guaio a loro spese.

Originariamente inviato da SpongeJohn

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?

GCC è open source, ti invito a scaricare i sorgenti e trovare l'errore software di cui millanti la presenza.
Aggiungo, perchè secondo me ti sfugge, che Linux e GCC sono entrambi progetti open source a cui partecipano attivamente le società interessate (Intel, AMD, etc).
AMD ha tutti gli strumenti per eventualmente correggere il presunto bug di GCC, migliorare il supporto a Ryzen da parte del kernel Linux, etc.
Il fatto che stiano cambiando le CPU senza dire bah è sintomatico del fatto che anche loro siano convinti che non sia un problema software.

Originariamente inviato da SpongeJohn

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...

E a noi esattamente cosa interessa questo?
Io ho comprato 380 € di CPU da AMD, non Intel.

Originariamente inviato da SpongeJohn

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.

Posta i link, possibilmente non risalenti a 6 mesi fa.

[SpongeJohn]

Originariamente inviato da 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.
..

Dimostrazione finale che i link manco li hai letti.
Non si tratta di "mal comune..." Ma di "due pesi, due misure" se vogliamo rimanere nell'ambito delle ovvietà dei detti popolari.

Prima di affermare che il suddetto "bug" si presenta anche con visualstudio, cygwin: vorrei leggere bug report dettagliati e chiarificatori. Link? O ancora meglio: fonte?

Ma anche fosse cosí, vogliamo tirare fuori i numeri di quanti usano una cpu per programmare e aggreghiamo i numeri di chi usa linux e win? A quanto ammontiamo come percentuale rispetto all'uso comune che si fa di un pc?

Intorno al 5%? Abbondiamo, 6?
Anche nel caso il problema si presenti sotto windows (e ripeto, le fonti di questa affermazione o le si posta ed é bene che siano affidabili, o la si finisce di ripeterlo), nessun programma di uso comune (anche in ambito lavorativo) non farà mai uso di quelle "istruzioni". Ci vogliamo inventare di sana pianta che dall'oggi al domani compilare diverrà cruciale per chi usa excel, photoshop, blender, firefox autocad etc etc?
Credici pure, se tu lo ritieni possibile. Peccato che nella vita reale non accadrà mai.
Stiamo parlando delle classiche paranoie da forum

Ultimo appunto, dichiarare che le ottimizzazioni (mancanti o errate) del compilatore o del kernel non contano perché qualsiasi cpu deve essere in grado di compilare in qualsiasi condizione: o lo dimostri ad esempio usando degli i5 e dandogli in pasto i comandi per BD e lo lasci compilare per anche 48 ore (beninteso, alcuni si lamentano che questa sono le condizioni alle quali si presentno i segfault: loop di 48 ore... Manco la nasa), usando un kerbel compilato per Bd.
Vediamo con queste condizioni, quante macchine passano il test.

[s12a]

Originariamente inviato da digieffe

se non stiamo equivocano stiamo dicendo la stessa cosa: verificare che gcc e bash non siano PIE, giusto?

L'equivoco era nato dal fatto che stavo guardando i flag di compilazione usati dal test invece del binario di gcc (e bash).

In ogni caso, pensavo che nel link dicesse che non devono essere PIE, ma da una distratta lettura non era chiaro. Mi sono alla fine andato a leggere su Wikipedia cosa significhi esattamente. Fa parte delle funzionalità di Address Space Layout Randomization (ASLR). Gli eseguibili compilati in modalità Position-Independent-Executable (PIE) possono fare uso dell'ASLR, che è attivo di default su Linux.

Dato che è stato determinato in precedenza che questa funzionalità di ASLR aumenta significativamente le possibilità di osservare l'errore, allora vuol dire che gli eseguibili devono essere preferibilmente stati compilati in modalità PIE affinché esso esca fuori più rapidamente (disabilitare l' ASLR non elimina totalmente il problema).

EDIT: potrei stare capendo male, lascio comunque il testo qui per eventuali ripensamenti.

nella 17.04 dovrebbero essere NON PIE alias EXEC, quindi ok (ho apena controllato).

nella 17.10 dovrebbero essere PIE alias DYN, quindi NON ok

comunque meglio verificare

It’s PIE if the type is DYN, non-PIE if EXEC.

Usando il comando provvisto in quella pagina ("readelf -h $(which bash)" oppure "readelf -h $(which gcc)"):

• Su OpenSUSE Tumbleweed (installata da VM) che sto usando bash è DYN, mentre gcc è EXEC.
• Su Ubuntu 16.04 LTS (WSL su Windows) sia bash che gcc sono EXEC.
• Su Ubuntu 17.10 (Live da VM) sia bash che gcc (una volta installato) sono EXEC.

Ozozuz comunque ha osservato segfault anche su Ubuntu 17.10 live, sembra.

A proposito: anche dopo avere aumentato la memoria a 8 GB OpenSUSE mi falisce il test sempre dopo 19 minuti (senza segfault).

[alexsky8]

Originariamente inviato da evil weasel

Anche fosse solo il 1% di utenti interessati siamo comunque di fronte a numeri esageratamente elevati.

il problema è marginale negli effetti perchè chi incappa in quell'errore non utilizza la CPU come il 99,999% degli utenti
ma secondo me le CPU affette da quell'errore sono molte ma molte più dell' 1% però ripeto nell'operatività normale "per ora" non sono segnalate anomalie

Originariamente inviato da evil weasel

Qui siamo proprio all'apoteosi.
Tu quindi ti saresti tenuto una CPU fallata per far risparmiare un reso alla amata AMD?
Tu e gli altri fenomeni nel thread ufficiale avete un attaccamento anomalo a questa azienda, manco fosse un vostro parente.
Queste son multinazionali dai fatturati esagerati, se fanno una cappellata è giusto che sistemino il guaio a loro spese.

[SpongeJohn]

Originariamente inviato da moob1

La mia cpu a default passa 3 ore di blend test con prime 95 (oltre non vado dato che la corrente la pago), 10 cicli a very high di IBT e svariate e svariate sessioni di utillizzo per svariate ore: senza l'ombra di un problema.
Ergo: la mia cpu funziona.

Non farei RMA perchè come vedi non ne ho bisogno. MA visto che la cpu dovrò rivenderla: già so come andrebbe a finire se poi mi verrebbe chiesto: ma va in segfault?

Al che la mia contro-domanda sarebbe: ma usi linux? E vai col mambo.

Originariamente inviato da SpongeJohn

La mia cpu a default passa 3 ore di blend test con prime 95 (oltre non vado dato che la corrente la pago), 10 cicli a very high di IBT e svariate e svariate sessioni di utillizzo per svariate ore: senza l'ombra di un problema.
Ergo: la mia cpu funziona.

Non farei RMA perchè come vedi non ne ho bisogno. MA visto che la cpu dovrò rivenderla: già so come andrebbe a finire se poi mi verrebbe chiesto: ma va in segfault?

Al che la mia contro-domanda sarebbe: ma usi linux? E vai col mambo.

Sono un programmatore, scrivo programmi cross platform e per compilare, per una questione pratica uso Linux. Se vuoi ti linko anche alcuni progetti open source belli pesanti a cui lavoro e ho lavorato

Comunque come ti è stato detto il problema non è relativo a Linux ma relativo alla CPU e si presenta anche su Windows, quindi la tua domanda ha ben poco valore.

[Mister D]

Originariamente inviato da evil weasel

Qui siamo proprio all'apoteosi.
Tu quindi ti saresti tenuto una CPU fallata per far risparmiare un reso alla amata AMD?
Tu e gli altri fenomeni nel thread ufficiale avete un attaccamento anomalo a questa azienda, manco fosse un vostro parente.
Queste son multinazionali dai fatturati esagerati, se fanno una cappellata è giusto che sistemino il guaio a loro spese.

L'apoteosi è il tuo ragionamento se ho compreso bene dove vuoi arrivare.
In pratica per te visto che AMD, o intel, giustamente e in modo assolutamente sacrosanto, ti danno il diritto a poter sostituire la cpu non conforme con una conforme, l'utente è in dovere di farsela sostituire (quindi da un diritto diventa un obbligo)???? Ma in quale mondo vivi?

Non ci sta scritto da nessuna parte che se hai un diritto questo diventi automaticamente un dovere.
Per cui:
CASO A

Sono un utente che non programma, non usa linux, né VM, né WSL e scopro di questo bug.
Decido, che siccome non interessa il mio ambito di utilizzo e che quindi il mio pc è stabile da quando l'ho preso senza nessun problema, preferisco non avvalermi del mio diritto di RMA perché il pc rimarebbe fermo e perché probabilmente dovrò pagare le spese di andata.
Ha ragione? SI'

CASO B

Sono un utente che non programma, non usa linux, né VM, né WSL e scopro di questo bug.
Decido, che siccome ho diritto ad avere la cpu perfettamente conforme e mi da fastidio tenermi una cosa che potrebbe anche solo mostrare un giorno un problema e che non saperei se dipende o no d questo bug, di farmela sostituire.
Ha ragione? Ancora SI'

Capisci che a volte entrambe le visioni sono corrette? O vuoi uniformare il pensiero degli altri al tuo? Forse non ti sei reso conto dell'assurdità di tale ragionamento: DIRITTO è diverso da DOVERE.

Poi per tutti quelli che dicono che si minimizza il problema. Ma dove? Ma se anche sul thread principale vi hanno consigliato di aprire un thread apposito e farlo pinnare in evidenza nella sezione questo vorrebbe dire mettere a tacere questa importante discussione? Ma siete seri????? Non ci posso credere.

Sarebbe stato molto peggio e forse equivalente ad insabbiarlo (poi con che movente me lo dovresti spiegare) tenere la discussione nel thread ufficiale facendo apposta non rispondervi e facendo passare con indifferenza il problema, in modo che il problema stesso fosse "insabbiato" dall'elevato numero di post del thread ufficiale.

Incomincio a sospettare che si stia perdendo il buon senso e la ragionevolezza.

AMD ha detto che esiste il problema, che ha fatto dei test, che per lei è un problema solo su linux e non su tutte le cpu, che ha modificato la selezione, che tutti hanno diritto a sacrosanta RMA e che verrà spedita cpu da loro testata, cos'altro doveva fare?
Sì una cosa avrebbe dovuto farla: pubblicare prima tutti gli errata e purtroppo ancora non lo ha fatto e questo sì che potete puntargli il dito addosso perché è un comportamento poco trasparente visto che con tutte le altre cpu ha sempre pubblicato il "revision guide".

[s12a]

Originariamente inviato da alexsky8

il problema è marginale negli effetti perchè chi incappa in quell'errore non utilizza la CPU come il 99,999% degli utenti
ma secondo me le CPU affette da quell'errore sono molte ma molte più dell' 1% però ripeto nell'operatività normale "per ora" non sono segnalate anomalie

Provando a leggere in giro nel corso dei giorni passati ho notato report di problemi potenzialmente correlati al segfault, come ad esempio (Windows):

https://community.amd.com/message/28...825959#2825959

Had my setup for about three weeks, Ryzen 1600X on an MSI X370 Gaming Titanium, GSkill 3600 CL15 RAM, watercooled etc etc

After putting my rig through various stress tests while trying to find a stable overclock I was getting perplexed on why somedays I could be prime95 stable custom 14000mb for over 8 hours, but then the next day would fail instantly, then after a reboot would be stable for several hours etc etc

So I decided to try out the different tool available for testing if my CPU was also part of the 'fault' batches.

And here I am,

My 1600X segfaulted first after 136 seconds with the BIOS set at optimized default, so I thought id better manually key in the memory timings that I had been using that had tested stable with prime95.

Segfault after 148 seconds......

In un caso un utente ha riportato che la sostituzione del processore che mostrava segfault ha risolto problemi di reboot, errori hardware, etc (Linux):

https://www.phoronix.com/forums/foru...443#post980443

Sembra che alcuni (non tutti) utenti Ryzen abbiano problemi con un certo programma su Windows per inserire rom nella SNES Mini; potrebbe essere correlato al Segfault:

https://github.com/ClusterM/hakchi2/issues/620

Altri ad esempio dal forum sul sito AMD riguardante il segfault hanno anche problemi di reboot che a volte vengono risolti in parte disabilitando i C-state inferiori.

Non è chiaro se questi siano tutti riconducibili allo stesso inconveniente, o se siano qualcosa di diverso. Se rimane la possibilità, il dubbio rimane.



Per conto mio, io avevo intenzione non urgente di upgradare ad un processore 8C/16T per usarlo anche in ambiti come la compilazione in particolar modo di alcuni programmi grafici cross-platform che uso spesso (principalmente Krita, Blender), con la possibilità di testare anche frequentemente altri branch in sviluppo. Dunque farei parte di quello 0.X% di utenti potenzialmente interessato dal problema. Visto che sembrano essercene potenzialmente anche altri e che non è sicuro se sia stato totalmente risolto con la nuova produzione, non ho problemi a rinviare l'acquisto.

[Mister D]

Originariamente inviato da moob1

Sono un programmatore, scrivo programmi cross platform e per compilare, per una questione pratica uso Linux. Se vuoi ti linko anche alcuni progetti open source belli pesanti a cui lavoro e ho lavorato

Comunque come ti è stato detto il problema non è relativo a Linux ma relativo alla CPU e si presenta anche su Windows, quindi la tua domanda ha ben poco valore.

Tu sei un programmatore.
Lui non lo è.
Tu hai il diritto a fartela sostituire e te ne avvali.
Lui ha il diritto a farsela sostitutire e NON se ne avvale.

Per te c'è uno che sbaglia e uno che fa giusto? Per me no in quando entrambi fate bene. Cavolo è difficile da capire che entrambe le visioni sono corrette e condivisibili? No perché nel vostro mondo di perfezione se uno ha un diritto deve farsela sostituire, non è che può farsela sostituire.

[Mister D]

Originariamente inviato da Ozozuz

Io ho notato molto astio verso chi vuole farsi cambiare la cpu anche se non fa parte del nostro 1% di utilizzatori a cui il bug potrebbe effettivamente danneggiare la produttivitá, cosa a mio avviso incredibilmente sbagliata.
Ma si, tutte le scelte sono legittime, anche di quella del povero Pippo che ha pagato 300€ di cpu per giocare senza aver la piú pallida idea di cosa sia Linux ma vuole comunque farsi cambiare la cpu.

Io invece ho notato astio per chi ha il diritto di farsela sostituire ma decide di non farsela sostituire come fosse un cavolo di obbligo sociale!
Avete il sacrosanto diritto di essere incavolati, di farvela sostituire dal produttore ma non avete il diritto di far diventare un obbligo la sostituzione anche per chi non la pensa come voi. Questo è il succo.

[Mister D]

Originariamente inviato da Ozozuz

Io ho notato molto astio verso chi vuole farsi cambiare la cpu anche se non fa parte del nostro 1% di utilizzatori a cui il bug potrebbe effettivamente danneggiare la produttivitá, cosa a mio avviso incredibilmente sbagliata.
Ma si, tutte le scelte sono legittime, anche di quella del povero Pippo che ha pagato 300€ di cpu per giocare senza aver la piú pallida idea di cosa sia Linux ma vuole comunque farsi cambiare la cpu.

Edit - forse OT: Ho inviato la richiesta per l'rma ieri e sto ricevendo strane mail da AMD, non iniziamo bene

Quindi cosa vorrebbe dire questo? Che AMD lo sta facendo apposta perché non vuole sostituirtela e vuole risparmiarsi un reso? Spero sia una bella battuta

[Mister D]

Originariamente inviato da Ozozuz

Abbiamo avuto una percezione completamente opposta della cosa, siccome i piú saggi dicono come la veritá stia nel mezzo, pace fatta e chiudiamo questa diatriba

Io sono pronto a chiuderala, basta che poi non si attacchi nuovamente un'utente solo perché ha deciso di non farla sostituire e questa non è una percezione:
Quote:
Originariamente inviato da SpongeJohn Guarda i messaggi
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.

risposta che suona come attacco personale per non aver deciso di sostituirla perché fallata, ma sostituita per futura rivendita:
Qui siamo proprio all'apoteosi.
Tu quindi ti saresti tenuto una CPU fallata per far risparmiare un reso alla amata AMD?
Tu e gli altri fenomeni nel thread ufficiale avete un attaccamento anomalo a questa azienda, manco fosse un vostro parente.
Queste son multinazionali dai fatturati esagerati, se fanno una cappellata è giusto che sistemino il guaio a loro spese.

Ora rispondi, ho percepito male? Per me è oggettivo cosa si scrive. verba volant, scripta manent.

[SpongeJohn]

Originariamente inviato da evil weasel

1% sono svariate migliaia di utenti, ti sembra un problema marginale?
A me no.



Più raro ma non assente.
Il fatto che ora accada meno spesso non vuol dire che non sia un problema e soprattutto non vuol dire che in futuro il problema non possa presentarsi con una frequenza maggiore o anche in altri ambiti.



Questo è falso.
GCC permette, già dalla versione 6.*, di specificare march=znver1, le differenze passando da una impostazione MARCH ad un'altra sono presenti ed abbastanza significative.
Chi si lamentava di binari poco ottimizzati rispetto all'impostazione march=haswel usava GCC vecchio, in combinazione con altre impostazioni non consigliate (ad esempio -O3) a pochissima distanza dal lancio.
Aggiungo poi che malgrado march=hawsel producesse binari più efficienti lo faceva a discapito della stabilità.
Sul fatto che il kernel Linux sia poco ottimizzato per Ryzen io avrei da ridire, ad esempio XFR e C&Q hanno subito funzionato correttamente.
È Windows quello che ha avuto bisogno di un nuovo profilo energetico apposito e tutt'ora è comunque pieno di gente che bestemmia per far andare correttamente il C&Q.

Posta i link, possibilmente non risalenti a 6 mesi fa.

Non si sta parlando di win vs linux, detto questo ti rispondo (anche se dopo i tuoi insulti di qualche tempo fa, dovrei proprio evitare ma vuoi i link, quindi...)

Buona lettura.
https://gcc.gnu.org/ml/gcc-patches/2.../msg00428.html
https://gcc.gnu.org/ml/gcc-patches/2.../msg00427.html
https://gcc.gnu.org/ml/gcc-patches/2.../msg00272.html
https://gcc.gnu.org/ml/gcc-patches/2.../msg00624.html

Ancora nessuno comunque mi ha spiegato perchè ad esempio se è assodato che un singolo programma (sotto win) che monitora temp/timings e frequenze (hwinfo64) può far andare in schermata blu una configurazione che passa ore di OCCT e compagnia cantata: perché non può essere un errore software in congiunzione con la scarsa ottimizzazione lato bios/kernel il problema dell'instabilità sotto linux.

P.s. l'uscita sui presunti incendi è da incorniciare. Nessuna scheda madre ha preso fuoco per colpa di una RX, era un'esagerazione di alcuni smartass riguardo all'assorbimento fuori specifica dallo slot Pci. Polemica assolutamente inutile ma che ha lasciato talmente il segno che per mesi si è sentito: Ma è sicuro montare una rx o brucio il pc?

[Mister D]

Originariamente inviato da Ozozuz

? Mai nemmeno accennato una cosa del genere , e poi parli di astio verso chi non vuole cambiare la cpu.
Semplicemente mi sta un po'stressando questa storia e volevo scherzarci su.

Edit: e magari sapere se qualcuno aveva giá avuto esperienza di RMA con AMD visto che per me é la prima volta al di fuori di amazon

Si ma se tu posti una cosa del genere sembra vuoi sottintendere qualcosa. Questo lo capisci vero? Infatti te l'ho chiesto e ora ho appurato che non lo hai fattoin cattiva fede, ma bensì in buona fede per riderci su ma qualcuno lo può leggere diversamente. Non trovi?

[SpongeJohn]

Originariamente inviato da Mister D

Io sono pronto a chiuderala, basta che poi non si attacchi nuovamente un'utente solo perché ha deciso di non farla sostituire e questa non è una percezione:
Quote:
Originariamente inviato da SpongeJohn Guarda i messaggi
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.

risposta che suona come attacco personale per non aver deciso di sostituirla:
Qui siamo proprio all'apoteosi.
Tu quindi ti saresti tenuto una CPU fallata per far risparmiare un reso alla amata AMD?
Tu e gli altri fenomeni nel thread ufficiale avete un attaccamento anomalo a questa azienda, manco fosse un vostro parente.
Queste son multinazionali dai fatturati esagerati, se fanno una cappellata è giusto che sistemino il guaio a loro spese.

Ora rispondi, ho percepito male? Per me è oggettivo cosa si scrive. verba volant, scripta manent.

Per la cronaca: io ho deciso di fare RMA giorni fa, sono tra i primi ad aver postato in questo thread gli screenshot e la mia decisione (pagina 2?) ...

Il motivo l'ho spiegato più volte, di fare un piacere ad AMD non facendo RMA non mi passa manco per l'anticamera del cervello. La mia motivazione è sia una questione di correttezza verso chi acquisterà la mia cpu. Sia economica, visto che dovrei rivenderla come "presumibilmente difettata".

[digieffe]

Originariamente inviato da SpongeJohn

Dimostrazione finale che i link manco li hai letti.
Non si tratta di "mal comune..." Ma di "due pesi, due misure" se vogliamo rimanere nell'ambito delle ovvietà dei detti popolari.

Prima di affermare che il suddetto "bug" si presenta anche con visualstudio, cygwin: vorrei leggere bug report dettagliati e chiarificatori. Link? O ancora meglio: fonte?

Ma anche fosse cosí, vogliamo tirare fuori i numeri di quanti usano una cpu per programmare e aggreghiamo i numeri di chi usa linux e win? A quanto ammontiamo come percentuale rispetto all'uso comune che si fa di un pc?

Intorno al 5%? Abbondiamo, 6?
Anche nel caso il problema si presenti sotto windows (e ripeto, le fonti di questa affermazione o le si posta ed é bene che siano affidabili, o la si finisce di ripeterlo), nessun programma di uso comune (anche in ambito lavorativo) non farà mai uso di quelle "istruzioni". Ci vogliamo inventare di sana pianta che dall'oggi al domani compilare diverrà cruciale per chi usa excel, photoshop, blender, firefox autocad etc etc?
Credici pure, se tu lo ritieni possibile. Peccato che nella vita reale non accadrà mai.
Stiamo parlando delle classiche paranoie da forum

Ultimo appunto, dichiarare che le ottimizzazioni (mancanti o errate) del compilatore o del kernel non contano perché qualsiasi cpu deve essere in grado di compilare in qualsiasi condizione: o lo dimostri ad esempio usando degli i5 e dandogli in pasto i comandi per BD e lo lasci compilare per anche 48 ore (beninteso, alcuni si lamentano che questa sono le condizioni alle quali si presentno i segfault: loop di 48 ore... Manco la nasa), usando un kerbel compilato per Bd.
Vediamo con queste condizioni, quante macchine passano il test.

John, con tutto il rispetto, ciò che ho scritto, pur senza spiegarlo sufficientemente, sarebbe ovvio per qualunque programmatore assembler con conoscenze di micro-architettura.
Col massimo rispetto, permettimi che faccia una supposizione, da ciò che scrivi sembra che tu non sia nè programmatore assembler, né conosca bene la micro-architettura dei calcolatori, mi confermi ciò?
(poi può benissimo essere che per motivi tuoi tu lo sia ma ti sei espresso in con contenuto ed modi impropri all'argomento tecnico).

ti dico ciò perché, in questo periodo il mio tempo libero scarseggia (e non sono stipendiato dalle due case che producono x86) e non vorrei trovarmi a fare un lavoro di ricerca di fonti e spiegazioni tecniche a fronte di tanti argomenti che a me sembrano non congrui: da come parli di istruzione (invece di pattern), di ottimizzazione, kernel, Nasa ecc. sembra che tu non abbia ben chiaro in profondità di cosa tu stia parlando
chiaro, sempre con rispetto

Ps: se non avessi letto i link come avrei fatto a mettere il post sul PIE?
Ps2: alla nasa utilizzano versioni "particolari di cpu" oltre alle verifiche formali.
Ps3: tutte le macchine in quelle condizioni DEVONO passare il test


avevo scritto il post come sopra ma non avevo fatto caso a questa frase
"Credici pure, se tu lo ritieni possibile. Peccato che nella vita reale non accadrà mai."
per formazione non avresti potuto mai scrivere una cosa del genrere, vero che non sei nè ingegnere nè informatico? :-/

cerca di scrivere cose coerenti così ne riparliamo