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

Kein Hardware-Bug? Warum nicht?

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema


  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


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. Senior Software Requirements Engineer (w/m/d)
    AIXTRON SE, Herzogenrath
  2. IT-Manager*in (m/w/d)
    BAM - Bundesanstalt für Materialforschung und -prüfung, Berlin
  3. Softwareentwickler (m/w/d) Embedded Systems - Linux
    SICK AG, Waldkirch bei Freiburg im Breisgau
  4. Software Projektmanager / Product Owner (m/w/d)
    Microtrac Retsch GmbH, Haan (Home-Office)

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. Ryzen 7 5800X für 469€)
  2. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de