28.09.2017
München. Während üblicher Standard-Tests mit unserem Echtzeitbetriebssystem Symobi auf verschiedenen Plattformen, darunter auch zwei Tests auf AMD Ryzen CPUs, stießen wir auf ein seltsames Verhalten.
Da es jedoch nur auf der Ryzen-Plattform auftrat, gingen wir zunächst davon aus, das Problem würde an einer Inkompatibilität mit Symobi selbst liegen. Also gingen wir dem Ganzen auf den Grund, um die genaue Ursache zu finden und das Problem in Symobi zu beheben.
Allerdings mussten wir feststellen, dass die Ursache des Problems nicht wie erwartet an Symobi lag, sondern es zwei unabhängige Effekte auf der Ryzen-Plattform waren, welche in Kombination mit Symobi zutage kamen:
A. Symobi stürzte sporadisch ab. Wir konnten das Problem zwar reproduzieren, jedoch nicht deterministisch. Erwähnt sei zudem, dass das System und die Hardware keinen außergewöhnlichen Belastungen ausgesetzt waren.
B. Zunächst schien es, als würden die Gerätetreiber von Symobi einfrieren. Allerdings stellte sich heraus, dass sie in einigen Fällen nach dem Senden der Kommandos kein Interruptsignal erhielten und deshalb einfach im Wartezustand blieben.
Da wir als Hersteller unseres eigenen Betriebssystems über tiefere Einblicke in die Systeme und entsprechende Fähigkeiten verfügen, als viele andere Softwareentwickler, konnten wir analysieren was wirklich in der Hardware vor sich ging. Laut unseren Erkenntnissen muss AMD neben den in den vergangenen Monaten bisher bekannt gewordenen Bugs noch einige weitere beheben.
Unsere Analyse ergab nämlich folgendes:
A. Beide Ryzen CPUs wiesen sporadische Probleme beim Hardware-Task-Switching auf, solange SMT angeschaltet war. Tatsächlich stürzten sie mitten in der Ausführung des Task-Switches ab. Bei ausgeschaltetem SMT lief alles reibungslos. AMD hat bereits einige Probleme mit dem neu eingeführten SMT. Dieses Problem trat zwar zufällig auf, aber wir konnten es dennoch reproduzieren. Während all unserer Tests gab es keine extremen Arbeitsbedingungen des Systems.
B. Es stellte sich heraus, dass das Problem mit den IRQs auf den Chipsatz zurückzuführen war, nicht auf die CPU. Liefen die AMD Chipsätze A320 und B350 im PIC Modus (im Gegensatz zum APIC Modus), konnte der Interrupt Modus nicht auf „Level“ eingestellt werden, was aber nötig ist, um IRQs über mehrere Geräte zu verteilen. Darüber hinaus waren die Signale im „Edge“-Modus invertiert. Dies führte zum Verlust von IRQs und somit erhielt der Treiber keine Antwort auf Kommandos.
Selbstverständlich haben wir AMD kontaktiert und über unsere Ergebnisse informiert. Zur Zeit warten wir noch auf eine Antwort. Wir halten euch weiter auf dem Laufenden. Bleibt dran!