Hat jemand einen Ryzen (AM4) welcher ab der 25. Kalenderwoche produziert wurde?

[DEFCON2]

Bei AMD scheint es aktuell jedoch so, als wäre die Ursache kein Chip-Errata, ansonsten könnte man einen Workaround anbieten, entweder per AGESA Update oder falls es nicht anders geht, durch Workarounds in den Compilern, um bestimmte Anweisungen nicht zu verwenden.

Ich denke es war ein anstatt kein gemeint, sonst macht die Aussage nich so viel sinn.

Es heißt übrigens in der Einzahl "Erratum" und nur in der Mehrzahl "Errata"

 

[DEFCON2]

Gentlemen, nach 10 Tagen halte ich einen 1728SUS Made in China in Händen, der offensichtlich auf dem Prüfstand war (Packungsboden ohne Siegel und Spuren auf dem Heatspreader). Werde am Wochenende mal testen

Edit: Nach 36 Stunden mit besagtem Skript und gut 120 mal GCC ohne Probleme kompilieren würde ich sagen, der Prozessor ist gut. Lasse es jetzt noch testweise 24h im Idle.

 

[AnotherWorld]

Auf meinem 1700 steht 1721SUS. Ist dieser also auch betroffen?

 

[DEFCON2]

Lass mal das zuvor genannte Skript laufen. Ansonsten ist es Spekulation - ich würde zu "ja" tendieren.

 

[dominic.e]

Es gibt jetzt wohl auch ein Win-Script: https://github.com/corngood/kill-ryzen-win

 

[Simpson474]

Ja endlich, damit sollte diese ewige Diskussion, dass der Fehler doch nur beim Kompilieren auftritt, wohl bald der Geschichte angehören.

 

[DEFCON2]

Das Windows Skript ist auch nur ein Wrapper für diverse wiederholte Kompiliervorgänge, d.h. das stimmt schon noch, dass es primär das Kompilieren betrifft.

Bisher ist mir nicht bekannt, dass mit dem Skript schon jemand auf Windows das Problem reproduzieren konnte.

 

[Simpson474]

Der Absturz ist in einer nativen Windows DLL (crypt32.dll), welche von sehr vielen Programmen verwendet wird. Wir Programmierer sind deterministisches Verhalten von einem Compiler gewohnt, wenn man eine Datei 1000-mal übersetzt, so muss immer das gleiche Ergebnis rauskommen, alles andere wäre fatal. Daher werden solche Fehler von Softwareentwicklern viel kritischer betrachtet als von Endnutzern. Ein Endnutzer wird sicherlich nicht genauer nachforschen, wenn ein Programm oder Spiel sporadisch abstürzt - dort wird sofort dem Hersteller der Software vorgeworfen, ein unfertiges Produkt auf den Markt gebracht zu haben.

Ich hoffe für AMD, sie verstehen was da schiefgeht: ich bin weiterhin der Meinung, es ist ein Fertigungsproblem und kein echtes Chip-Erratum. Wäre es ein AGESA-Problem, so hätte man es ohne RMA gefixt. Wäre es ein Masken-Fehler, so hätte man das Stepping geändert (und man könnte auch wie Intel mal ein Errata-Sheet veröffentlichen), doch laut Screenshots melden sich die getauschten CPUs mit identischen Daten. Beruflich waren es bisher immer Fertigungsprobleme, wenn ein Fehler ab einem bestimmten Batch behoben wurde, die Chip-Revision aber unverändert blieb. Es kann - muss aber nicht - heißen, dass AMD jetzt mehr Schrott produziert: Chips in dieser Größe erlauben es sehr, sehr viele Parameter am offenen Die zu parametrisieren. Vor allem bei sehr frühen Samples fehlen noch die Erfahrungswerte und Fehler werden daher häufig erst später gefunden.

 

[AnotherWorld]

Gibt es dafür irgendwo eine Schritt für Schritt-Anleitung für absolute Laien?

 

[dominic.e]

Wenn du absoluter Laie bist, sollte dich der Bug sowieso nicht interessieren

 

[DEFCON2]

Jetzt noch nicht, aber im Laufe der Nutzungszeit der CPU ist ja nicht ausgeschlossen, dass man dazulernt.

Eigentlich ist es ziemlich einfach. Installier dir einfach ein Ubuntu, dazu gibt es haufenweise step by step Anleitungen, lade das Script von github runter, öffne in dem Ordner ein Terminal, oder irgendwo und wechsle dann mit cd in den Ordner, wo das Skript liegt. Gib ./kill-ryzen.sh ein.

 

[Chaserheart]

Was macht AMD eigentlich mit diesen Prozessoren die den Fehler aufweisen und per RMA getauscht wurden? Schrotten? So eine schande^^

 

[KenshiHH]

Grad mal das skript laufen lassen, bin leider auch betroffen. werde die tage mal checken aus welcher produktionswoche meine cpu ist.

ist ne tray cpu vom damaligen deal von proshop.de

tauscht amd nur boxed versionen oder auch tray versionen aus?

 

[DEFCON2]

Ich denke nicht, dass AMD das mitteilen wird - sie sind recht verschwiegen in dieser Sache. Ich vermute mal, die CPUs werden entweder weggeworfen, falls die neu produzierten mittlerweile keine Probleme mehr machen, oder wieder verkauft, falls das nicht der Fall ist und sich das überhaupt finanziell lohnt (glaube ich nicht).

Da ich nicht angeben musste, ob boxed oder tray, und dies dann erst festgestellt werden konnte, nachdem die CPU dort war, denke ich, dass alle getauscht werden.

 

[AnotherWorld]

Hallo, ich vermute, ich habe das Script unter linux (ubuntu live DVD) zum laufen bekommen.
Nun stelle ich mir die Frage, was genau dort nun passiert ist. Ich sehe nur, dass etwas versagt hat.
Ich poste hier einfach mal den kompletten Verlauf und hoffe, jemand hat eine Antwort für mich:

Reading package lists... Done
Building dependency tree
Reading state information... Done
build-essential is already the newest version (12.1ubuntu2).
build-essential set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Create compressed ramdisk
64G
Download GCC sources
--2017-09-25 14:42:00-- ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-7.1.0/gcc-7.1.0.tar.bz2
=> 'gcc-7.1.0.tar.bz2'
Resolving ftp.fu-berlin.de (ftp.fu-berlin.de)... 130.133.3.130
Connecting to ftp.fu-berlin.de (ftp.fu-berlin.de)|130.133.3.130|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /unix/languages/gcc/releases/gcc-7.1.0 ... done.
==> SIZE gcc-7.1.0.tar.bz2 ... 84303533
==> PASV ... done. ==> RETR gcc-7.1.0.tar.bz2 ... done.
Length: 84303533 (80M) (unauthoritative)

gcc-7.1.0.tar.bz2 100%[==============================================>] 80.40M 5.18MB/s in 18s

2017-09-25 14:42:18 (4.58 MB/s) - 'gcc-7.1.0.tar.bz2' saved [84303533]

Extract GCC sources
Download prerequisites
wget: unable to resolve host address 'gcc.gnu.org'
error: Cannot download gmp-6.1.0.tar.bz2 from ftp://gcc.gnu.org/pub/gcc/infrastructure/
cat /proc/cpuinfo | grep -i -E "(model name|microcode)"
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
model name : AMD Ryzen 7 1700 Eight-Core Processor
microcode : 0x8001126
sudo dmidecode -t memory | grep -i -E "(rank|speed|part)" | grep -v -i unknown
Speed: 3200 MHz
Part Number: F4-3200C14-8GFX
Rank: 1
Configured Clock Speed: 1600 MHz
Speed: 3200 MHz
Part Number: F4-3200C14-8GFX
Rank: 1
Configured Clock Speed: 1600 MHz
uname -a
Linux ubuntu 4.10.0-19-generic #21-Ubuntu SMP Thu Apr 6 17:04:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
cat /proc/sys/kernel/randomize_va_space
2
/ /mnt/ramdisk/workdir
/mnt/ramdisk/workdir
Using 16 parallel processes
[KERN] -- Logs begin at Mon 2017-09-25 14:31:19 UTC. --
[KERN] Sep 25 14:36:27 ubuntu kernel: sd 9:0:0:0: Attached scsi generic sg1 type 0
[KERN] Sep 25 14:36:27 ubuntu kernel: sd 9:0:0:0: [sda] 62333952 512-byte logical blocks: (31.9 GB/29.7 GiB)
[KERN] Sep 25 14:36:27 ubuntu kernel: sd 9:0:0:0: [sda] Write Protect is off
[KERN] Sep 25 14:36:27 ubuntu kernel: sd 9:0:0:0: [sda] Mode Sense: 23 00 00 00
[KERN] Sep 25 14:36:27 ubuntu kernel: sd 9:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[KERN] Sep 25 14:36:27 ubuntu kernel: sda: sda1
[KERN] Sep 25 14:36:27 ubuntu kernel: sd 9:0:0:0: [sda] Attached SCSI removable disk
[KERN] Sep 25 14:41:58 ubuntu kernel: zram: Added device: zram0
[KERN] Sep 25 14:41:58 ubuntu kernel: zram0: detected capacity change from 0 to 68719476736
[KERN] Sep 25 14:41:59 ubuntu kernel: EXT4-fs (zram0): mounted filesystem with ordered data mode. Opts: discard
[loop-0] Mon Sep 25 14:42:32 UTC 2017 start 0
[loop-1] Mon Sep 25 14:42:33 UTC 2017 start 0
[loop-2] Mon Sep 25 14:42:34 UTC 2017 start 0
[loop-3] Mon Sep 25 14:42:35 UTC 2017 start 0
[loop-4] Mon Sep 25 14:42:36 UTC 2017 start 0
[loop-5] Mon Sep 25 14:42:37 UTC 2017 start 0
[loop-6] Mon Sep 25 14:42:38 UTC 2017 start 0
[loop-7] Mon Sep 25 14:42:39 UTC 2017 start 0
[loop-0] Mon Sep 25 14:42:40 UTC 2017 configure failed
[loop-1] Mon Sep 25 14:42:40 UTC 2017 configure failed
[loop-1] TIME TO FAIL: 8 s
[loop-0] TIME TO FAIL: 8 s
[loop-5] Mon Sep 25 14:42:40 UTC 2017 configure failed
[loop-5] TIME TO FAIL: 8 s
[loop-4] Mon Sep 25 14:42:40 UTC 2017 configure failed
[loop-4] TIME TO FAIL: 8 s
[loop-6] Mon Sep 25 14:42:40 UTC 2017 configure failed
[loop-6] TIME TO FAIL: 8 s
[loop-3] Mon Sep 25 14:42:40 UTC 2017 configure failed
[loop-2] Mon Sep 25 14:42:40 UTC 2017 configure failed
[loop-3] TIME TO FAIL: 8 s
[loop-2] TIME TO FAIL: 8 s
[loop-7] Mon Sep 25 14:42:40 UTC 2017 configure failed
[loop-7] TIME TO FAIL: 8 s
[loop-8] Mon Sep 25 14:42:40 UTC 2017 start 0
[loop-8] Mon Sep 25 14:42:41 UTC 2017 configure failed
[loop-8] TIME TO FAIL: 9 s
[loop-9] Mon Sep 25 14:42:41 UTC 2017 start 0
[loop-9] Mon Sep 25 14:42:42 UTC 2017 configure failed
[loop-9] TIME TO FAIL: 10 s
[loop-10] Mon Sep 25 14:42:42 UTC 2017 start 0
[loop-10] Mon Sep 25 14:42:43 UTC 2017 configure failed
[loop-10] TIME TO FAIL: 11 s
[loop-11] Mon Sep 25 14:42:43 UTC 2017 start 0
[loop-11] Mon Sep 25 14:42:44 UTC 2017 configure failed
[loop-11] TIME TO FAIL: 12 s
[loop-12] Mon Sep 25 14:42:44 UTC 2017 start 0
[loop-12] Mon Sep 25 14:42:45 UTC 2017 configure failed
[loop-12] TIME TO FAIL: 13 s
[loop-13] Mon Sep 25 14:42:45 UTC 2017 start 0
[loop-13] Mon Sep 25 14:42:46 UTC 2017 configure failed
[loop-13] TIME TO FAIL: 14 s
[loop-14] Mon Sep 25 14:42:46 UTC 2017 start 0
[loop-14] Mon Sep 25 14:42:47 UTC 2017 configure failed
[loop-14] TIME TO FAIL: 15 s
[loop-15] Mon Sep 25 14:42:47 UTC 2017 start 0
[loop-15] Mon Sep 25 14:42:48 UTC 2017 configure failed
[loop-15] TIME TO FAIL: 16 s

Vielen Dank!

(Falls es eine Funktion gibt, den langen Text zu verstecken, so,
dass er nur sichtbar wird, wenn man ihn anklickt, gebt mir Bescheid. Sorry!)

 

[DEFCON2]

error: Cannot download gmp-6.1.0.tar.bz2 from ftp://gcc.gnu.org/pub/gcc/infrastructure/

Daran wird's wohl liegen. Die Datei ist aber auf dem Server vorhanden. Einfach nochmal probiert?

 

[mr_drum]

Hallo AnotherWorld,

ich konnte das kill-ryzen Skript ebenfalls mit einer Ubuntu 17.10 Live-CD sowie in einer Ubuntu 17.04 -VirtualBox unter Windows 10 zum Laufen bringen und mit meinem Ryzen 1700 den segfault-Fehler reproduzieren. Allerdings sah dies dann folgendermaßen aus:

.........
[loop-12] Wed Sep 20 13:38:57 UTC 2017 start 0
[loop-13] Wed Sep 20 13:38:58 UTC 2017 start 0
[loop-14] Wed Sep 20 13:38:59 UTC 2017 start 0
[loop-15] Wed Sep 20 13:39:00 UTC 2017 start 0
[loop-13] Wed Sep 20 13:44:18 UTC 2017 build failed
[loop-13] TIME TO FAIL: 334 s

[KERN] Sep 20 13:44:18 ubuntu kernel: cc1p1us[384]: segfault at 20af90 ip 000000
0901234517 sp 00007ffd71aded30 error 4 in cc1p1us[400000+1667000]

Ich wollte mich dann daran machen verschiedene Spannungseinstellungen zu testen, seit letzten Mittwoch Abend bekomme ich das Skript jedoch nicht mehr zum Laufen und es produziert den gleichen Output wie bei dir (UTC 2017 configure failed). Ich vermutete, dass das Skript aufgrund eines Updates der zugehörigen Quellen nicht mehr ordnungsgemäß funktioniert und wäre dankbar für einen Tip.

Vielen Dank.

 

[DEFCON2]

Konnte das gerade nicht reproduzieren auf Ubuntu 16.04.2.
Drei einfache Vorschläge:

- Neuste Version von kill_ryzen von GitHub holen
- Alle außer den files von github aus dem Verzeichnis löschen
- Skript im home Verzeichnis ausführen oder mit sudo

Die Datei ist in jedem Fall noch auf dem mirror. Wenns nicht klappt kann ich mal in die /gcc-7.1.0/contrib/download_prerequisites reinschauen. Im Prinzip muss ja sowieso nicht jedes mal der Quellcode und die dependencies geladen werden. Dann müsstet ihr das Zeug hält von Hand runterladen.

 

[mr_drum]

Danke, ich habe das Skript jetzt von dem Ubuntu Live-USB-Stick durch Neueinlesen der Paketlisten mittels SUDO APT-GET UPDATE vor Ausfuehren von kill-ryzen.sh wieder zum Laufen bekommen.

Leider produziert es wieder segfaults

[loop-9] TIME TO FAIL: 174 s
[KERN] Sep 25 21:49:38 ubuntu kernel: bash[12596]: segfault at 2e1c4d8d ip 0000000000435d8e sp 00007ffd7abca550 error 6 in bash[400000+100000]

Werde wenn ich etwas mehr Zeit habe mal verschiedene Speicher&Voltage-Einstellungen durchprobieren

 

[AnotherWorld]

Ich habe es gestern irgendwie zum laufen bekommen, brach es dann aber vorzeitig ab,
weil sich eine Weile nichts tat, um das Terminalfenster zu kopieren.
Nach ungefähr 5 weiteren Versuchen, es erneut zum laufen zu bekommen gab ich wieder auf.
Obwohl ich mir den Log gespeichert hatte und genau das gleiche wie vorher machte, funktionierte es nicht wieder.
Das Problem scheint dabei immer wieder das Gleiche zu sein "error: Cannot download gmp-6.1.0.tar.bz2 from ftp://gcc.gnu.org/pub/gcc/infrastructure/"

Nun stelle ich mir natürlich die Frage, warum das Script kurz funktionierte und dann 5 Minuten später geht es nicht mehr.
Als es funktionierte machte ich vorher noch ein Update via "sudo apt-get update". So machte ich es dann beim nächsten mal auch,
aber der Kontakt zum FTP-Server war nicht möglich.

Was mir das Terminal ausgespuckt hatte, bevor ich abbrach, war:
[KERN] Sep 26 19:28:36 ubuntu kernel: traps: bash[14759] general protection ip:4cbe80 sp:7ffef2d71530 error:0
[KERN] Sep 26 19:28:36 ubuntu kernel: in bash[400000+100000]
[KERN] Sep 26 19:28:36 ubuntu kernel: bash[14048]: segfault at 8 ip 0000000000431f20 sp 00007ffdbab69d68 error 6 in bash[400000+100000]
[KERN] Sep 26 19:28:36 ubuntu kernel: bash[14513]: segfault at 6ec510 ip 0000000000435d74 sp 00007ffc903e5cd8 error 4 in bash[400000+100000]
[loop-7] Tue Sep 26 19:28:36 UTC 2017 build failed