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

[papugo1980]

Originariamente inviato da nagashadow

Quello di prima settimana 14 Malesia,quello nuovo china....ho notato subito temperature più basse sia idle che in full

Ok grazie
L hai testato per vedere se è affetto?
P.s qualcuno tra voi che ha una CPU affetta da segfault può provare un gioco in DX12 (specialmente con vga Nvidia)
Per vedere se ha il mio stesso problema?
Grazie

[alexsky8]

Originariamente inviato da jam71

Io purtroppo l'ho comprata su uno eshop non molto veloce con le pratiche rma quindi dovro' mandarlo ad amd direttamente ma aspetto ancora .

Fai bene ad attendere ancora anzi io aspetterei la prossima primavera inoltrata per avere un quadro più completo del problema o di altri problemi correlati

Originariamente inviato da beee

Non sono d'accordo! Appurato che il bug è irrilevante, la RMA si fa solamente per avere una cpu migliore, con silicio migliore.... e se paghi ti arrangi!
La cpu 'nuova', andrà esattamente come la 'vecchia', le uniche differenze si vedranno in overclock. Se AMD decidesse di cambiare solo le cpu i cui proprietari
dovranno dimostrare di lanciare normalmente per lavoro o per hobby 4 istanze di un compilatore C, compilando programmi abnormi..... beh, non ci sarebbe da meravigliarsi, io lo troverei normale!
Ripeto per chi non ci sente: il bug è irrilevante!

Ecco hai proprio cannato
Come ho già scritto PER ESPERIENZA DIRETTA e non per sentito dire non cambia solo in OC ma anche con la cpu stock le temperature calano di un 5 10 gradi e il Vcore di un 10% non parliamo di noccioline ma quasi di 2 generazioni di cpu differenti

E se in un primo momento pareva fosse correlato direttamente ho poi visto che anche cpu ben riuscite potevano avere il problema
La mia cpu settimana 33 va benissimo anche in oc ma presenta il problema di segfault

[nagashadow]

Si confermo temperature nettamente inferiori.....Alex la tua dov'è stata prodotto?

[papugo1980]

Da controllare sarebbe anche la prima lettera dopo la settimana che sarebbe dove é stato prodotto il wafer
Edit: ho sbagliato..la terza indica la provenienza del wafer

[alexsky8]

Originariamente inviato da nagashadow

Si confermo temperature nettamente inferiori.....Alex la tua dov'è stata prodotto?

made in Malaysia
codice 1733PGS

[SpongeJohn]

Originariamente inviato da Ozozuz

:



Ah, ovviamente ci sono stati casi e segnalazioni al di fuori del macroblocco linux+compilazione/programmazioni che invece riguardando il normale utilizzo windows o addirittura alcuni giochi dx12, di questi parlo per sentito dire perché non ho mai riscontrato problemi, semplicemente sono moolto piú randomici e difficili da delineare.

Ed é qui che casca l'asino. Prove delle vostre affermazioni con bench che falliscono con configurazioni a default e build soft/hardware sotto win e dx quelle che volete e per di piú stabili: non ne avete.
Altrimenti fornireste i link.

Capisco chi sviluppa software con linux e quelli a cui piace moddare il proprio software (sempre sotto linux, erché prove concrete di instabilità sotto win, a costo di ripetermi: NON LE AVETE ANCORA FORNITE) , ma al resto del mondo?

fornitemi bench e prove varie. non chiacchiere da bar, e per inciso, ancora una volta: chi vi dice che il carico software (totalmente legato alle righe di codice e marginalmente all'hardware) legato alla compliazione diverrà roba di tutti i giorni. Vi sta dicenco una cazzata bella e buona, legata al loro desiderio di sentirsi "professionisti".
Pfff compilare e win... ma che vi siete fumati?

Detto questo, addio.

edit: allo stesso livello di delirio si arrivò ( se mai verrà dimostrato scientificamente che l'errore é puramente legato all'architettura della cpu) ad averlo coi pentium ed il famoso errore in floating point.
Errore che affliggeva il 2% deigli scenarii di utilizzo per le quali le cpu venivano vendute e che costó ad intel svariati inutili milioni.

[mavvy]

Anche io sono affetto dal bug. Ma al momento il sistema è stabile, non ho problemi di sorta, uso prevalenetemente Windows ed i sistemi Linux vanno lisci come l'olio. Per ora... Quindi apsetto l'evolvere della situazione, come si muoverà anche AMD e quello che succederà con il parco software. Ho due anni di garanzia e magari aspettare qualche mese può giovare anche per l'affineamento della loro produzione e test

[metal master]

ragazzi scusate ma vedo che sta cosa del bug da fastidio a qualcuno.
si sta dicendo tranquillamente che amd è a conoscenza del problema e che cambia le cpu col problema, che il problema si verifica solo sotto particolari condizioni e che quasi sicuramente chi utilizza il pc in modo normale il problema forse non lo verificherà ne adesso ne mai, però è anche vero che chi vuole può farsi cambiare la cpu perchè è la stessa amd che dopo verifiche consiglia l'rma.

l'autore del thread ha spiegato il tutto in maniera perfetta in prima pagina, e ancora c'è chi non si rassegna.....

dei problemi di intel sinceramente in questo topic a noi non interessa, interessa solo che amd risolva i suoi (e li sta risolvendo)

p.s: di questo problema se ne parla proprio nel forum ufficiale di amd, ed il thread è stato flaggato pure come utile: https://community.amd.com/thread/215773

[BuRn]

Originariamente inviato da beee

Ok, spiegami che problemi provoca il bug, naturalmente escludendo script che lo tirano fuori con le pinze!

Il bug sembra causare l'esecuzione di un'istruzione a un indirizzo errato, per cui o punti a un'istruzione fuori dall'area di memoria riservata all'applicazione (segfault) o punti a un indirizzo che non è l'inizio di un'istruzione (invalid opcode) o punti l'istruzione sbagliata (e possono succedere cose varie, dal niente al crash dell'applicazione).

Non è chiaro se il problema si verifichi solo compilando: la logica non usclude che possa accadere altrove, il test di compilazione viene utilizzato perchè in quel caso il problema si verifica con una certa regolarità. Ma ripeto, questo non esclude che possa accadere altrove.

A riguardo, nel topic si parla anche questo, capire se chi ha verificato di avere problemi di compilazione con il test ha riscontrato problemi anche altrove. Purtroppo non è semplice avere dei risultati coerenti dalle prove degli utenti perchè larga parte delle persone che scrivono qui hanno smanettato (giustamente) con overclock, overclock della ram, voltaggi, timings, ecc. e quindi quando un utente riporta un problema (specie su una piattaforma nuova come Ryzen), sarà il bug o saranno settaggi non completamente stabili? Sì cerca di capire un po' alla volta e di aiutarsi a vicenda.

Non prendete la discussione come un attacco personale eh: pare che quando si discute di argomenti come questi salti fuori la solita vecchia storia che chi ha comprato un prodotto lo deve difendere oltre ogni logica, in virtù di non si sa quale orgoglio.

[ccmarco2004]

Originariamente inviato da beee

Non sono d'accordo! Appurato che il bug è irrilevante, la RMA si fa solamente per avere una cpu migliore, con silicio migliore.... e se paghi ti arrangi!
La cpu 'nuova', andrà esattamente come la 'vecchia', le uniche differenze si vedranno in overclock. Se AMD decidesse di cambiare solo le cpu i cui proprietari
dovranno dimostrare di lanciare normalmente per lavoro o per hobby 4 istanze di un compilatore C, compilando programmi abnormi..... beh, non ci sarebbe da meravigliarsi, io lo troverei normale!
Ripeto per chi non ci sente: il bug è irrilevante!

Non hai la minima idea di cosa stai parlando.

Nei panni dell'OP mi cadrebbero le braccia, nonostante lo sbattimento organizzativo del 3ad, continuano ad arrivare perle come questa ad alimentare la campagna di minimizzazione.

Tutti azionisti AMD ?

[Operapia]

Originariamente inviato da metal master

ragazzi scusate ma vedo che sta cosa del bug da fastidio a qualcuno.
si sta dicendo tranquillamente che amd è a conoscenza del problema e che cambia le cpu col problema, che il problema si verifica solo sotto particolari condizioni e che quasi sicuramente chi utilizza il pc in modo normale il problema forse non lo verificherà ne adesso ne mai, però è anche vero che chi vuole può farsi cambiare la cpu perchè è la stessa amd che dopo verifiche consiglia l'rma.

l'autore del thread ha spiegato il tutto in maniera perfetta in prima pagina, e ancora c'è chi non si rassegna.....

dei problemi di intel sinceramente in questo topic a noi non interessa, interessa solo che amd risolva i suoi (e li sta risolvendo)

p.s: di questo problema se ne parla proprio nel forum ufficiale di amd, ed il thread è stato flaggato pure come utile: https://community.amd.com/thread/215773

Hai capito perchè prima che aprissero questa discussione i risultati tel mio test te li ho mandati in privato? Era proprio per evitare discussioni assurde come queste.

Vedo però che neanche aprendo una discussione idonea si evitano sterili polemiche. Francamente non capisco cosa ci sia di male a farsi sostituire una cpu che AMD stessa dichiara portatrice di un problema. mah

[Mikkinen]

Qualcuno di voi che ora ha la cpu perfetta che tipo di ram monta?
Ci sono stati miglioramenti? In particolare riguardanti hynix...
Potrebbe essere legata la cosa?

[s12a]

Ho provato ad ideare un semplice test per verificare se chi ha il segfault può avere problematiche in condizioni di carico simili (ma in ambiti differenti) su Windows.

Servono Python 3.6+ ed ImageMagick (un programma in riga di comando per la conversione ed elaborazione immagini in vari formati) in versione 64bit portable (link diretto qui).

Di ImageMagick serve solo magick.exe. Dalla directory di installazione di Python servono i file sotto elencati oltre a magick.exe



Se vi fidate (ma suggerisco di non fidarvi) qui c'è un pacchetto completo e pronto in formato zip:
https://mega.nz/#!OpQGGYgS!_1pOyoeGF...fAzYyyn7_KReC4

Il codice Python è il seguente:

# -*- coding: utf-8 -*-
"""
Created on Wed Oct 25 02:52:15 2017

@author: s12a
"""

import multiprocessing as mp
import subprocess
import time
import sys


magick = "magick.exe"
time_0 = time.time()

def worker(n, size):     
    subprocess.run(f"{magick} xc: +noise Random -resize {size} png:>NUL", shell=True)

    if n % 50 == 0:
        print(f"{n}:{int(time.time() - time_0)}", flush=True, end='')
    else:
        print(".", flush=True, end='')
        

if __name__ == "__main__":

    if len(sys.argv) >= 3:
        workers, jobs, size = sys.argv[1:]
    
        # Sanitizing values
        try:
            workers = int(workers)
            jobs = int(jobs)
            size = int(size)
        except ValueError:
            print("Error parsing command line arguments.")
            sys.exit(-1)
            
    else:
        workers=mp.cpu_count()
        jobs=5000
        size=3000       
      

    print("\n"
          "=========================================\n"
          "To stop the script press Ctrl+Break/Pause\n"
          "=========================================\n")

    print(f"Workers: {workers}, Images: {jobs}, Image size: {size}px\n")


    pool = mp.Pool(processes=workers)
    [pool.apply_async(worker, args=(n, size)) for n in range(jobs)]
    pool.close()
    pool.join()

Nella pratica viene creata un'immagine con rumore casuale, ingrandita a n pixel di larghezza, e questo si ripete per x volte su un numero di worker di default equivalente al numero di core logici della CPU. Il test dovrebbe emulare la conversione parallela di un grande numero di file.

Per eseguirlo, una volta che i file sono tutti nella stessa directory, da riga di comando va fatto:

python.exe worker.py

In assenza di argomenti da linea di comando vengono usati tutti i core della CPU, 5000 immagini in totale ridimensionate ad una larghezza di 3000 pixel. Se vengono aggiunti argomenti alla linea di comando, occorre specificarli tutti; ad esempio:

python.exe worker.py 20 10000 1500

Questo vuol dire 20 worker, 10000 immagini in totale, ridimensionate a 1500 pixel di dimensione.

Le immagini non vengono salvate da nessuna parte; finiscono nell'equivalente Windows di /dev/null.

Non devono accadere errori durante l'operazione, che è piuttosto intensiva. (occhio anche alla temperatura della CPU)



Durante l'operazione viene creato e terminato un numero significativo di processi (principalmente cmd.exe, magick.exe; quelli di python.exe sono fissi), situazione simile a quella che avviene durante la compilazione con GCC, MSVC, ecc.

Più la dimensione delle immagini è alta più memoria verrà occupata e più ogni worker richiederà tempo per ciascuna immagine, quindi attenzione a non esagerare per non saturare tutta la RAM ed oltre. Consiglio di usare almeno qualche worker in più dei core logici della CPU.

[BuRn]

Originariamente inviato da s12a

Ho provato ad ideare un semplice test per verificare se chi ha il segfault può avere problematiche in condizioni di carico simili (ma in ambiti differenti) su Windows.

--

Mi hai battuto sul tempo!
Avevo pensato di mettere su lo stesso identico test, solo con Node.JS al posto che con Python.

Ora non resta che vedere che risultati da.

[bagnino89]

Stasera provo il test, grazie.

[fedexx2]

Il mio 1700X datato "1717 SUT" ha presentato il bug e oggi parte per la sostituzione (spedizione di andata pagata da AMD).

Per tappare il buco e non rimanere fermo col pc ho preso un R3 1200 datato "1725PGT" che più tardi testerò per bene

[papugo1980]

Originariamente inviato da fedexx2

Il mio 1700X datato "1717 SUT" ha presentato il bug e oggi parte per la sostituzione (spedizione di andata pagata da AMD).

Per tappare il buco e non rimanere fermo col pc ho preso un R3 1200 datato "1725PGT" che più tardi testerò per bene

Ciao per caso avevi riscontrato problemi in DX12?

[fedexx2]

Originariamente inviato da papugo1980

Ciao per caso avevi riscontrato problemi in DX12?

Ciao, Non ho provato nessun gioco DX12...
Però qualche encoding video pesante con diversi filtri avisynth sopra mi ha dato dei crash random

[Gioz]

Originariamente inviato da s12a

Ho provato ad ideare un semplice test per verificare se chi ha il segfault può avere problematiche in condizioni di carico simili (ma in ambiti differenti) su Windows.

per darti un primo feedback: con impostazioni che nel test restituivano segfault pressoché istantaneamente qui non ho problemi, anche lato consumo e temperatura il carico non è particolarmente intensivo.

suppongo che non si verifichino quei cambi di stato in successione tali da innescare il problema.
credo sia improbabile tentare con script di varia natura senza conoscere l'esatta condizione che può portare all'errore e di conseguenza riuscire a far eseguire le istruzioni adeguate.

a sinistra esecuzione "liscia" a destra "32 10000 1500", lanciati consecutivamente e non simultaneamente:
https://imgur.com/tyPwwBa

[bagnino89]

Originariamente inviato da papugo1980

Ciao per caso avevi riscontrato problemi in DX12?

Che problemi hai in DX12? Con che giochi?