1. Foren
  2. Kommentare
  3. Sonstiges
  4. Alle Kommentare zum Artikel
  5. › Ryzen-CPU: Ach AMD!

Kein Hardware-Bug? Warum nicht?

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Kein Hardware-Bug? Warum nicht?

    Autor: nate 23.03.17 - 10:59

    > Doch obwohl AMD den Fehler nachvollziehen kann und ihn bestätigt,
    > kann dies kein direkter Hardware-Bug sein.

    Mit welcher Begründung? Nur, weil er unter Linux nicht auftritt? Das ich nicht ausreichend, um einen Hardware-Bug auszuschließen -- es kann ohne weiteres ein Bug sein, der von der Konfiguration der CPU-Kerne, CCX, Fabrics/Switche, Speichercontroller o.ä. abhängig ist, und die kann sich je nach Betriebssystem auch mal unterscheiden.

  2. Re: Kein Hardware-Bug? Warum nicht?

    Autor: CrasherAtWeb 23.03.17 - 11:03

    Weil ein reiner Hardware-Bug eben nicht auf Software-Ebene lösbar wäre. Ist er ja aber bei Linux offensichtlich.

  3. Re: Kein Hardware-Bug? Warum nicht?

    Autor: SYS1 23.03.17 - 11:16

    CrasherAtWeb schrieb:
    --------------------------------------------------------------------------------
    > Weil ein reiner Hardware-Bug eben nicht auf Software-Ebene lösbar wäre. Ist
    > er ja aber bei Linux offensichtlich.
    Ein richtiger Hardware-Bug lässt sich aber möglicherweise umgehen, indem in der Software bestimmte Befehlsmuster nicht auftreten.

  4. Re: Kein Hardware-Bug? Warum nicht?

    Autor: CrasherAtWeb 23.03.17 - 11:19

    Hier wurde ja aber explizit die gleiche Software, bloß unter unterschiedlichen Betriebssystemen ausgeführt. Es gibt keinen expliziten Workaround im Linux-Kernel für Ryzen. Also muss der Fehler in der Kommunikation zwischen Windows und Ryzen liegen.

  5. Re: Kein Hardware-Bug? Warum nicht?

    Autor: nate 23.03.17 - 11:19

    > Weil ein reiner Hardware-Bug eben nicht auf Software-Ebene lösbar wäre.

    Wir sprechen ja nicht von irgendeiner Software, sondern vom Prozessor-Microcode. Und dort kann AMD durchaus Dinge tun wie z.B. Waitstates oder Locking einfügen, um einer Race Condition entgegenzuwirken.

  6. Re: Kein Hardware-Bug? Warum nicht?

    Autor: HubertHans 23.03.17 - 11:21

    CrasherAtWeb schrieb:
    --------------------------------------------------------------------------------
    > Weil ein reiner Hardware-Bug eben nicht auf Software-Ebene lösbar wäre. Ist
    > er ja aber bei Linux offensichtlich.

    -_-

    Natuerlich sind Hardware-Bugs vom verwendeten Code abhaengig. Wenn Linux etwas anders macht als Windows, bedeutet das nicht, das Windows schuld ist, bloß weil der Hardware-Bug eben nur unter einem nativen Windows 10 auftritt. Der ganze Artikel besteht aus Spekulationen.

  7. Re: Kein Hardware-Bug? Warum nicht?

    Autor: HubertHans 23.03.17 - 11:23

    CrasherAtWeb schrieb:
    --------------------------------------------------------------------------------
    > Hier wurde ja aber explizit die gleiche Software, bloß unter
    > unterschiedlichen Betriebssystemen ausgeführt. Es gibt keinen expliziten
    > Workaround im Linux-Kernel für Ryzen. Also muss der Fehler in der
    > Kommunikation zwischen Windows und Ryzen liegen.


    Du weißt schon, das die Software nicht von alleine laeuft, sondern auf Funktionen des Betriebssystems angewiesen ist? Speziell Kernel und Task Sheduler/ APIs usw...

  8. Re: Kein Hardware-Bug? Warum nicht?

    Autor: CrasherAtWeb 23.03.17 - 11:29

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > CrasherAtWeb schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Hier wurde ja aber explizit die gleiche Software, bloß unter
    > > unterschiedlichen Betriebssystemen ausgeführt. Es gibt keinen expliziten
    > > Workaround im Linux-Kernel für Ryzen. Also muss der Fehler in der
    > > Kommunikation zwischen Windows und Ryzen liegen.
    >
    > Du weißt schon, das die Software nicht von alleine laeuft, sondern auf
    > Funktionen des Betriebssystems angewiesen ist? Speziell Kernel und Task
    > Sheduler/ APIs usw...

    Ja, das weiß ich. Deswegen habe ich ja auch explizit darauf hingewiesen habe, dass es im Linux-Kernel keinen speziellen Workaround speziell für die Ryzen-Prozessoren gibt.

  9. Re: Kein Hardware-Bug? Warum nicht?

    Autor: bofhl 23.03.17 - 11:30

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > CrasherAtWeb schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Hier wurde ja aber explizit die gleiche Software, bloß unter
    > > unterschiedlichen Betriebssystemen ausgeführt. Es gibt keinen expliziten
    > > Workaround im Linux-Kernel für Ryzen. Also muss der Fehler in der
    > > Kommunikation zwischen Windows und Ryzen liegen.
    >
    > Du weißt schon, das die Software nicht von alleine laeuft, sondern auf
    > Funktionen des Betriebssystems angewiesen ist? Speziell Kernel und Task
    > Sheduler/ APIs usw...

    Genau das wird hier ja geschrieben - Linux macht was anderes als Windows und dort führt es aber zu einem Fehler! Und die Software/Programm ist bei beiden OS die selbe - ruft also die selben Aktionen/APIs auf...
    Das Problem liegt im OS-Code von Microsofts Windows (10) verborgen - und das da schon desöfteren mal Schrott mit eingebaut wird dürfte jeden in den letzten Monaten aufgefallen sein.

  10. Re: Kein Hardware-Bug? Warum nicht?

    Autor: KarstenS2 23.03.17 - 11:52

    CrasherAtWeb schrieb:
    --------------------------------------------------------------------------------
    > Weil ein reiner Hardware-Bug eben nicht auf Software-Ebene lösbar wäre. Ist
    > er ja aber bei Linux offensichtlich.


    Selbstverständlich geht das. Schon zu Amiga Zeiten wurde das so praktiziert. Der Patcher musste im Bootscript auch gleich an erster Stelle stehen, weil dir das System je nach CPU sonst schon beim booten abgeschmiert ist.

    Hardwarefehler wurde über Conditions abgefangen und in eine Softwareemulation umgeleitet.



    2 mal bearbeitet, zuletzt am 23.03.17 11:54 durch KarstenS2.

  11. Re: Kein Hardware-Bug? Warum nicht?

    Autor: bombinho 23.03.17 - 11:52

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > Du weißt schon, das die Software nicht von alleine laeuft, sondern auf
    > Funktionen des Betriebssystems angewiesen ist? Speziell Kernel und Task
    > Sheduler/ APIs usw...

    Nunja, der Crash tritt bei einem Befehl auf, richtig? Also muesste man unter Windows davon ausgehen, dass _immer_ wenn der Befehl aufgerufen wird, Windows in bitgenau dem selben unguenstigen Status waere. Und unter Linux/ VM/etc. niemals.

  12. Re: Kein Hardware-Bug? Warum nicht?

    Autor: KarstenS2 23.03.17 - 11:58

    HubertHans schrieb:
    --------------------------------------------------------------------------------

    > Du weißt schon, das die Software nicht von alleine laeuft, sondern auf
    > Funktionen des Betriebssystems angewiesen ist? Speziell Kernel und Task
    > Sheduler/ APIs usw...

    Wie viel hängt jedoch von der Programmierung ab, insbesondere ob managed Code oder native. Benchmarks verwenden ziemlich sicher so viel native Code wie nur geht.

  13. Re: Kein Hardware-Bug? Warum nicht?

    Autor: HubertHans 23.03.17 - 12:02

    bofhl schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > CrasherAtWeb schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Hier wurde ja aber explizit die gleiche Software, bloß unter
    > > > unterschiedlichen Betriebssystemen ausgeführt. Es gibt keinen
    > expliziten
    > > > Workaround im Linux-Kernel für Ryzen. Also muss der Fehler in der
    > > > Kommunikation zwischen Windows und Ryzen liegen.
    > >
    > >
    > > Du weißt schon, das die Software nicht von alleine laeuft, sondern auf
    > > Funktionen des Betriebssystems angewiesen ist? Speziell Kernel und Task
    > > Sheduler/ APIs usw...
    >
    > Genau das wird hier ja geschrieben - Linux macht was anderes als Windows
    > und dort führt es aber zu einem Fehler! Und die Software/Programm ist bei
    > beiden OS die selbe - ruft also die selben Aktionen/APIs auf...
    > Das Problem liegt im OS-Code von Microsofts Windows (10) verborgen - und
    > das da schon desöfteren mal Schrott mit eingebaut wird dürfte jeden in den
    > letzten Monaten aufgefallen sein.

    Herrgottnochmal. Das ist eine falsche Schlussfolgerung! Das Probloem ist nicht der Code von Windows 10, außer AMD sagt was anderes. Der fehler wird unter WIndows 10 ausgeloest, liegt aber nach bisherigem Informationsstand NICHT AN WINDOWS 10!

  14. Re: Kein Hardware-Bug? Warum nicht?

    Autor: SirFartALot 23.03.17 - 12:04

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > Herrgottnochmal. Das ist eine falsche Schlussfolgerung! Das Probloem ist
    > nicht der Code von Windows 10, außer AMD sagt was anderes. Der fehler wird
    > unter WIndows 10 ausgeloest, liegt aber nach bisherigem Informationsstand
    > NICHT AN WINDOWS 10!

    Sondern?

    "It's time to throw political correctness in the garbage where it belongs" (Brigitte Gabriel)
    Der Stuhlgang während der Arbeitszeit ist die Rache des Proletariats an der Bourgeoisie.

  15. Re: Kein Hardware-Bug? Warum nicht?

    Autor: CrasherAtWeb 23.03.17 - 12:04

    KarstenS2 schrieb:
    --------------------------------------------------------------------------------
    > CrasherAtWeb schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Weil ein reiner Hardware-Bug eben nicht auf Software-Ebene lösbar wäre.
    > Ist
    > > er ja aber bei Linux offensichtlich.
    >
    > Selbstverständlich geht das. Schon zu Amiga Zeiten wurde das so
    > praktiziert. Der Patcher musste im Bootscript auch gleich an erster Stelle
    > stehen, weil dir das System je nach CPU sonst schon beim booten
    > abgeschmiert ist.
    >
    > Hardwarefehler wurde über Conditions abgefangen und in eine
    > Softwareemulation umgeleitet.

    In dem von dir beschriebenen Fall wird das Problem aber nicht gelöst, sondern schlichtweg umgangen. Das was du beschreibst ist ein Workaround. Den gibt es aber nicht im Linux-Kernel. Es wird da keine Softwareemulation oder sonst dergleichen gefahren, die das Problem umgeht, wie in deinem Beispiel dargestellt. Unter Linux werden explizit die Befehlssätze auf dem Prozessor angesprochen, die unter Windows ein Problem bilden. Das Problem liegt also definitiv in der Kommunikation zwischen Windows und Ryzen.

  16. Re: Kein Hardware-Bug? Warum nicht?

    Autor: HubertHans 23.03.17 - 12:08

    bombinho schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Du weißt schon, das die Software nicht von alleine laeuft, sondern auf
    > > Funktionen des Betriebssystems angewiesen ist? Speziell Kernel und Task
    > > Sheduler/ APIs usw...
    >
    > Nunja, der Crash tritt bei einem Befehl auf, richtig? Also muesste man
    > unter Windows davon ausgehen, dass _immer_ wenn der Befehl aufgerufen wird,
    > Windows in bitgenau dem selben unguenstigen Status waere. Und unter Linux/
    > VM/etc. niemals.

    Auch hier: Falsche gezogene Zusammenhaenge. Windows und Linux sind untrschiedliche Betriebssysteme und haben andere Kernel. Was unter Windows passiert und unter Linux ist unter der Haube nun einmal anders. Und welche Instruktionen genutzt werden ist irrelevant wenn es dadurch bedingt ist, wie die Instruktionen genutzt werden. Und da ist eben nicht gleich Windows schuld, sondern das Verhalten der CPU. Bis jetzt ist der Fehler von AMD nicht auf Windows geschoben worden. Du kannst also komplett davon ausgehen, das die CPU einen Errata hat, der eben unter den unter Windows 10 auftretenden Umstaenden zu einem Absturz fuehrt.

  17. Re: Kein Hardware-Bug? Warum nicht?

    Autor: HubertHans 23.03.17 - 12:08

    SirFartALot schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Herrgottnochmal. Das ist eine falsche Schlussfolgerung! Das Probloem ist
    > > nicht der Code von Windows 10, außer AMD sagt was anderes. Der fehler
    > wird
    > > unter WIndows 10 ausgeloest, liegt aber nach bisherigem
    > Informationsstand
    > > NICHT AN WINDOWS 10!
    >
    > Sondern?

    An einem Errata der CPU!

  18. Re: Kein Hardware-Bug? Warum nicht?

    Autor: HubertHans 23.03.17 - 12:11

    KarstenS2 schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    >
    > > Du weißt schon, das die Software nicht von alleine laeuft, sondern auf
    > > Funktionen des Betriebssystems angewiesen ist? Speziell Kernel und Task
    > > Sheduler/ APIs usw...
    >
    > Wie viel hängt jedoch von der Programmierung ab, insbesondere ob managed
    > Code oder native. Benchmarks verwenden ziemlich sicher so viel native Code
    > wie nur geht.

    Wo haste das her?

    Schreiben die sich ihre OpenCL/ OpenGL/ DirectX-Apis selber? Auch die fuer die Fensterdarstellung usw?

    Ich finde die Kandidaten heir im Forum immer wieder lustig. postfaktisches Zeitalter. Grandios!

    Ein Programm, was du unter WIndows ausfuehrst, wird immer vom OS abhaengig sein. Nativ in Assembler programiiert so gut wie keiner, weil die wenigsten Leute in der Lage waeren anstaendigen Code fuer die ganzen verfuegbaren CPU-Modelle abzudecken. Das koennen Compiler besser.

  19. Re: Kein Hardware-Bug? Warum nicht?

    Autor: Truster 23.03.17 - 12:19

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > Der ganze Artikel besteht aus Spekulationen.

    Deshalb leuchtet er unter der Kategorie IMHO.

  20. Re: Kein Hardware-Bug? Warum nicht?

    Autor: CrasherAtWeb 23.03.17 - 12:20

    Aber wieso sollte es ein AMD-Fehler sein, wenn Microsoft mit all seiner intensiven Zusammenarbeit mit den CPU-Herstellern etwas nicht auf die Reihe bekommt, was ein Linux-Kernel ohne gesonderte Anpassung ohne Probleme schafft? Ist doch irgendwie mal so gar nicht logisch, oder?

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Klinikum Neumarkt, Neumarkt i.d.OPf.
  2. Hays AG, Affalterbach
  3. Westermann Gruppe, Braunschweig
  4. Kassenärztliche Vereinigung Sachsen (KVS), Dresden

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 26,99€
  2. 52,79€


Haben wir etwas übersehen?

E-Mail an news@golem.de


PC-Hardware: Warum Grafikkarten derzeit schlecht lieferbar sind
PC-Hardware
Warum Grafikkarten derzeit schlecht lieferbar sind

Eine RTX 3000 oder eine RX 6000 zu bekommen, ist schwierig: Eine hohe Nachfrage trifft auf Engpässe - ohne Entspannung in Sicht.
Eine Analyse von Marc Sauter

  1. Instinct MI100 AMDs erster CDNA-Beschleuniger ist extrem schnell
  2. Hardware-accelerated GPU Scheduling Besseres VRAM-Management unter Windows 10

IT-Teams: Jeder möchte wichtig sein
IT-Teams
Jeder möchte wichtig sein

Teams bestehen in der IT häufig aus internen und externen, angestellten und freien Mitarbeitern. Damit alle zusammenarbeiten, müssen Führungskräfte umdenken.
Von Miriam Binner

  1. Digital-Gipfel Wirtschaft soll 10.000 zusätzliche IT-Lehrstellen schaffen
  2. Weiterbildung Was IT-Führungskräfte können sollten
  3. IT-Profis und Visualisierung Sag's in Bildern

Star Wars: Darth-Vader-Darsteller Dave Prowse ist tot
Star Wars
Darth-Vader-Darsteller Dave Prowse ist tot

Er war einer der großen Stars der originalen Star-Wars-Trilogie und doch kaum jemandem bekannt. David Prowse ist im Alter von 85 Jahren gestorben.
Ein Nachruf von Peter Osteried

  1. Spaceballs Möge der Saft mit euch sein
  2. The Mandalorian Erste Folge der zweiten Staffel ist online
  3. Star Wars Disney und Lego legen Star Wars Holiday Special neu auf