ACPI-Firmware-Bug bei Asus-Gaming-Laptops

 (github.com/Zephkek)
2 Punkte von GN⁺ 2025-09-18 | 1 Kommentare | Auf WhatsApp teilen
  • Bei ASUS-ROG-Gaming-Laptops treten durch ACPI.sys-DPC-Latenzen schwerwiegende Leistungseinbußen wie Audio-Aussetzer, einfrierende Mausbewegungen und Fehler bei der Videowiedergabe auf.
  • Die Ursache liegt in ineffizientem oder fehlerhaftem ACPI Machine Language (AML)-Code in der Firmware (BIOS) und kann daher weder durch einen Wechsel des Betriebssystems noch durch andere Treiber behoben werden.
  • Periodische Hardware-Ereignisse (GPE) und Aufgaben rund um den Embedded Controller (EC) belegen CPU-Kern 0 exklusiv; fehlerhafte Interrupt-Verarbeitung wie Sleep()-Aufrufe wirkt sich negativ auf Latenz und Systemreaktionsfähigkeit aus.
  • Die Firmware wiederholt GPU-Power-Cycling ohne Berücksichtigung des MUX-Modus, was von kurzen Systemhänger bis hin zu Bluescreens verschiedenste Fehler verursacht.
  • Das Problem wird seit 2021 bei verschiedenen ASUS-Gaming-Laptop-Modellen konsistent gemeldet, eine offizielle Reaktion von ASUS bleibt aus.

Bedeutung und Hintergrund des Projekts

Dieses Open-Source-Repository ist ein tiefgehender technischer Bericht, der die Grundursache der wiederholt auftretenden ACPI.sys-DPC-Latenzprobleme bei ASUS-Gaming-Laptops wie der ROG-Serie auf Firmware- und ACPI-Tabellen-Ebene analysiert. Insbesondere leistungsstarke Modelle wie Zephyrus, Strix und Scar erleben selbst bei grundlegenden Nutzungsszenarien wie YouTube-Wiedergabe, Sprach-/Videoanrufen oder Mausbewegungen häufig Ruckler, Lags und Audiofehler. Versuche mit anderen Treibern, einer Neuinstallation von Windows oder dem Wechsel zu Linux bleiben wirkungslos, da die Ursache ausschließlich in fehlerhaftem AML-Code in der Firmware liegt.

Wichtige Symptome und Messergebnisse

  • Messungen mit Tools wie LatencyMon zeigen, dass Echtzeit-Audio und andere Aufgaben nicht zuverlässig verarbeitet werden können.
  • Es wurde bestätigt, dass der ACPI.sys-Treiber in Interrupts und DPC-Routinen einen bestimmten Kern (CPU 0) über längere Zeiträume belegt.
    • Interrupt-to-Process-Latenz: maximal 65.816μs, durchschnittlich 23,29μs
    • DPC-Routinen-Latenz: maximal 5.998μs
  • CPU 0 wird exklusiv über mehr als 90 Sekunden für die Interrupt-Verarbeitung genutzt; das deutet nicht auf fehlgeschlagenes Load Balancing hin, sondern darauf, dass die Firmware so entworfen wurde, einen einzelnen Kern zu belegen.
  • Die Ursache ist kein simples Windows-Treiberproblem, sondern entsteht dadurch, dass ineffizienter oder fehlerhafter AML-Code aus der Firmware an ACPI.sys übergeben und dort ausgeführt wird. Besonders GPE (General Purpose Events) und Embedded-Controller-(EC)-Traffic lösen das Problem aus.

Detaillierte Analyse: Erweiterte ACPI-Logverfolgung und Problemmuster

  • Ergebnisse aus Windows Performance Analyzer und ETW-Tracing zeigen, dass diese Latenz regelmäßig in Intervallen von 30 bis 60 Sekunden auftritt.
  • Der zentrale Event-Handler _GPE._L02 läuft ungewöhnlich lange (z. B. 13,6 ms), was die Echtzeitleistung stark beeinträchtigt.
  • Befehle für das GPU-Power-Management werden wiederholt unabhängig vom Status des MUX-Modus (Multi-GPU-Auswahlmodus) ausgeführt; selbst in Umgebungen, in denen tatsächlich nur die dGPU mit dem Display verbunden ist, werden weiter unmögliche Zustandswechsel versucht.
  • Dabei werden kritische Fehler ausgelöst, etwa Bluescreens (BSOD) oder Treiber-Threads, die in einen unendlichen Wartezustand geraten.

Extraktion und Dekompilierung des Firmware-Codes

  • Die ACPI-Tabellen wurden mit Tools wie acpidump und iasl extrahiert, dekompiliert und analysiert.
  • Der problematische GPE-Handler ist vereinfacht:
    • _L02: \_SB.PC00.LPCB.ECLV() aufrufen
  • Innerhalb der Methode ECLV() passiert jedoch Folgendes:
    • wiederholte CPU-blockierende Aufrufe wie Sleep(25~100ms)
    • künstliche Erzeugung von Ereignissen selbst dann, wenn die EC-Event-Queue leer ist (Self-Rearm), wodurch ein Endlosschleifenmuster entsteht
  • Sleep-Aufrufe innerhalb eines GPE sind im Interrupt-Kontext tabu und blockieren einen Kern für mehrere zehn Millisekunden, was Echtzeit-Scheduling, Eingaben und Audio deutlich verschlechtert.

Logik für Event-Verarbeitung/Dispatch und Energieverwaltung

  • GPE-Ereignisse führen zum Aufruf von Wrapper-Funktionen für Batteriestatus sowie GPU-Strom- und Display-Umschaltung.
  • PWCG(): wiederholtes Polling von Batterie-/Netzadapterstatus und wiederholte OS-Benachrichtigungssignale
  • NOD2(): Benachrichtigung an den NVIDIA-Treiber zur Neubewertung des Energiezustands
  • Eigentlich müsste der MUX-Modus-Status (HGMD == 0x03) geprüft werden, damit die Logik auf die korrekte GPU zielt. Im tatsächlichen Codepfad wird dies jedoch ausgelassen, wodurch unabhängig vom Modus wahllos Power-Cycle-Befehle wiederholt werden.

Derselbe Fehler über System- und Modellgrenzen hinweg

  • Bei mehreren Modellen wie Scar 15 und Zephyrus M16 wurden nahezu identische Event-Laufzeiten, GPU-Power-Cycle-Intervalle und WMI-Aufrufmuster beobachtet.
  • Es wird vermutet, dass Armoury Crate (WMI-Dienst) das Problem zusätzlich verschärft.

Grundursache und Zusammenfassung des Designfehlers

  • Missverständnis des Interrupt-Kontexts: Während der Ausführung von GPE-Methoden maskiert die Firmware GPE-Signale, sodass ACPI-/EC-Aufgaben serialisiert werden; interne Sleep()-Aufrufe verlängern die Latenz auf mehrere zehn Millisekunden.
  • Fehlerhafte Interrupt-Verarbeitung: Wiederholte GPE-Auslösung durch unendliches Self-Rearm ohne Löschen der GPE-Quelle (wirkt wie ein periodischer Timer)
  • Unkenntnis des Plattform-(Hardware-)Status: GPU-Power-Management-Befehle werden gesendet, ohne den MUX-Modus zu prüfen.
  • Insgesamt werden Anforderungen an Echtzeitfähigkeit (Audio/Video usw.) nicht erfüllt; zudem ist dies ein Grund für das Scheitern am offiziellen Microsoft-HLK-GlitchFree-Test.

Nutzerberichte und Fortbestehen des Problems

  • Seit 2021 wird dasselbe Verhalten in offiziellen ASUS-Foren, auf Reddit und anderswo wiederholt gemeldet.
  • Die Symptome sind über die gesamte Produktlinie hinweg konsistent, einschließlich Strix, TUF und der G-Serie.
  • Auch bei den neuesten Modellen von 2023 bis 2024 besteht derselbe Fehler weiter; es gibt nur temporäre Workarounds.

Fazit: Wesen des Problems und Implikationen

  • Messbeleg: Der GPE-Handler blockiert einen Kern über 13 ms hinweg.
  • Codebeleg: Explizite Sleep()-Aufrufe im Interrupt-Handler
  • Logikbeleg: Fehlende Prüfung des MUX-Modus
  • Systembeleg: Reproduzierbarkeit über mehrere Modelle und BIOS-Versionen hinweg
  • Ein scheinbar einfacher, aber fataler Designfehler – „bloß ineffiziente Sleep-Aufrufe in Interrupt-Handlern und keine Prüfung des GPU-Zustands“ – führt dazu, dass Millionen ASUS-Laptop-Nutzer selbst bei grundlegenden Aufgaben Aussetzer erleben.
  • ASUS hat bis zum Zeitpunkt dieser Analyse keinen offiziellen Plan für Reaktion oder Behebung veröffentlicht.

Analysemethode und Referenzen

  • Dieser Bericht basiert auf Datenextraktion an realen Geräten und direkter Analyse des AML-Codes mit Tools wie Windows Performance Toolkit, acpidump und iasl.
  • Alle wesentlichen Belege (Traces, Methoden, Befehle) sind reproduzierbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-09-18
Hacker-News-Kommentare

  • Ich bin beeindruckt, was für eine erstaunliche Entdeckung, was für ein Artikel und was für ein Fix-Vorschlag das ist; er zeigt sehr gut, wie moderne PCs funktionieren und wie tief man sogar in die „versteckten“ Teile eindringen kann. Nachdem ich jahrelang Embedded-Firmware geschrieben habe, habe ich immer davon geträumt, dass ein Endnutzer einmal einen Bug auf genau diesem Niveau findet. Ich wünschte, wir würden in einer Welt leben, in der Asus genau solche talentierten Nutzer zu einem kurzfristigen Vertrag einlädt, sie ein paar Tage mit den Firmware-Ingenieuren zusammenarbeiten lässt, sie mit Zehntausenden von Dollar entlohnt und ihnen ihren Laptop mit dem neuesten Production-BIOS neu ausliefert. Es ist traurig, dass dieser Bug mehr als vier Jahre lang liegen gelassen wurde.

    • Die technische Ursachenanalyse ist interessant, aber mich interessiert auch die Ursachenanalyse auf Ebene der Geschäftsprozesse. Wenn dieses Problem so breit reproduzierbar ist, frage ich mich, wie es nicht über den technischen Support oder RMA gemeldet wurde. Ich frage mich, ob die Beweislage einfach zu dünn war, um die Zusammenhänge zu erkennen, oder ob ASUS zwar untersucht hat, aber zu falschen Schlussfolgerungen gekommen ist (z. B. eine fehlerhafte Silizium-Charge), oder ob vielleicht genug Beweise da waren und sie trotzdem ignoriert wurden. Wenn sich das Verhalten direkt während der Nutzung zeigt, wie sah dann der QA-Prozess aus — ist das nicht ein Problem, das man eigentlich nicht übersehen kann? Jetzt, da sie es wissen, frage ich mich, welche Maßnahmen sie wohl ergreifen werden. Wenn es sich um eine Luxusmarke handeln würde, müsste sie sowohl die Problemlösung als auch die Wiederherstellung ihres Rufs konsequent angehen, um zu überleben. Ich habe früher ROG gekauft, aber nachdem ich so etwas gesehen habe, werde ich wohl keines mehr kaufen. Wenn ich noch einmal darüber nachdenke, ist schon dieser Firmware-Bug selbst wirklich schockierend. Andere Bugs kann man vielleicht damit erklären, dass sich Hardware-Annahmen geändert haben oder dass beim Wiederverwenden bestehenden Codes Fehler passiert sind, aber in einem Interrupt zu schlafen, ist gravierend. Ich frage mich, wie das durch ein Code-Review gekommen ist und wie die Firmware überhaupt getestet wurde.

    • Das AML-Bytecode-System von ACPI ist ein zweischneidiges Schwert. Ein Vorteil ist, dass Reverse Engineering möglich ist und Nutzer Bugs selbst analysieren und beheben können. Aber es ist eine furchtbare Programmierumgebung, und dazu muss ein ziemlich schwergewichtiger Interpreter mit höchsten Kernel-Rechten laufen, was riskant ist. Systemintegratoren nutzen solche Tricks gern, aber die Codequalität liegt unter den Erwartungen. Wenn man eigene Linux-Treiber bauen muss, beginnt die Arbeit gefühlt immer damit, erst einmal den ACPI-Code wegzuwerfen.

    • Als Nutzer und Programmierer ist es traumhaft, so ein Know-how zu haben. Ich finde das im Artikel enthaltene Fachwissen beeindruckend. Ich habe auch schon verschiedene Teile meines Laptops analysiert, bin aber beim ACPI-Teil an eine Wand gestoßen; ich habe Tabellen gedumpt und den Code dekompiliert, aber es war alles nur Dummy-Code. Ich wollte eigene Linux-Treiber für meinen Laptop bauen, bin aber gescheitert. Ich habe großen Respekt vor Menschen, die so etwas schaffen.

    • Ich frage mich, welcher Fix am Ende herausgekommen ist. Endete die verlinkte Github-Seite nicht einfach mit „Ich habe alle Materialien veröffentlicht, jetzt soll Asus es reparieren“?

    • Wirklich eine tolle Analyse, und erstaunlich, wie viel Mühe Asus in die QA dieser „Müll“-Qualität gesteckt hat … also so tun als ob; tatsächlich haben sie sich wohl überhaupt keine Mühe gemacht, was bitter ist.

  • Es ist erstaunlich, dass es in Gaming-Laptops vier Jahre lang fatales Stuttering gegeben hat. Das lässt mich fragen, welche Psychologie dahintersteckt, dass Verbraucher die Produkte nicht massenhaft zurückgegeben haben. Es wird ein Beispiel aus dem verlinkten Reddit-Post zitiert: „Ich habe alles ausprobiert, aber nichts hat sich geändert; ich habe es auf Garantie eingeschickt und war gespannt auf das Ergebnis, aber der Service stellte ‚kein Fehler fest‘ fest, also habe ich mich einfach daran gewöhnt und trage Bluetooth-Ohrhörer, sodass ich das Problem gar nicht mehr bemerke.“

    • Meine beiden Erfahrungen mit Gaming-Laptops endeten ähnlich: Die Probleme wurden nie gelöst. Einer davon war ein Alienware M17 der ersten Generation mit Dual GTX 270M und einer integrierten Nvidia-GPU. Es gab Stuttering und Audiostörungen, und ich konnte es teilweise beheben, indem ich SLI und die integrierte GPU deaktivierte und einen Treiber aus irgendeinem Forum verwendete. Später gab es einen BIOS-Patch, mit dem sich SLI wieder nutzen ließ, aber eine vollständige Lösung gab es am Ende nie, und das Gerät erreichte schließlich sein Lebensende. Beim zweiten, einem ASUS-ROG-Laptop, traten fast dieselben Symptome auf. Ich hatte ebenfalls nicht das Wissen, mich tief in den ACPI-Code einzuarbeiten, und konnte es daher nicht vollständig lösen. LatencyMon hat die Probleme verschiedenen DLLs zugeschrieben, und ich habe provisorische Verbesserungen versucht, etwa durch den Austausch des WLAN-Treibers oder das Deaktivieren der dGPU. Es gab auch seltsame Punkte, zum Beispiel, dass die Störungen in Spielen eher seltener auftraten. Am Ende habe ich aufgehört, Gaming-Laptops zu kaufen. Nach diesem Artikel habe ich den Eindruck, dass die Lage selbst heute kaum besser geworden ist.

    • Das ist das Ergebnis davon, dass die Computerindustrie den Verbrauchern über Jahrzehnte beigebracht hat, dass „kaputt der Normalzustand“ sei. In anderen Branchen wäre so etwas am ersten Tag vollständig retourniert worden. Mein Lehrer hat das vor 35 Jahren mit Schuhen verglichen, die beim Binden der Schnürsenkel zufällig explodieren. Immerhin etabliert sich inzwischen eine Entwicklung hin zu Verbraucherschutzgesetzen.

    • Ich habe ein ASUS-Produkt (Zenphyrus G14) damals gekauft, weil ASUS eine Zeit lang exklusiv AMDs Ryzen 4xxxHS einsetzte. Anfangs war die Leistung gut, aber nach zwei Jahren zeigte sich Leistungsabfall durch Thermal Throttling. Das erneute Auftragen von Wärmeleitpads half nur teilweise, die eigentliche Ursache konnte ich nicht finden. Ich habe auch die nachlassende Akkuleistung untersucht und stellte schließlich fest, dass die iGPU dauerhaft unter Volllast lief und das Problem verursachte. Wenn ich die Priorität auf die dGPU setzte, wurde die Akkulaufzeit sogar leicht besser. Als sich dann auch noch mechanische Defekte häuften, bin ich auf ein FW16 umgestiegen und habe jegliche Lust verloren, noch einmal ein Produkt einer Gaming-Laptop-Marke zu kaufen. Ich hatte das Gefühl, dass dem Hersteller die Verbraucher völlig egal sind, und damit verschwand auch die Kaufmotivation.

    • Dieser Defekt tritt nur im Ultimate-Modus auf. Er passiert nur dann, wenn der Nutzer per MUX explizit auf die dGPU umschaltet. Diese Funktion ist ein wichtiges Extra, wenn man hauptsächlich auf einem externen Display spielt. Im Optimus-Modus funktionieren externe Displays ebenfalls gut, nur mit leichtem Leistungsverlust und gewissen Einschränkungen bei einigen Display-Funktionen wie G-Sync. Die meisten Nutzer verwenden vermutlich nur den Optimus-Modus und haben deshalb kaum eine Gelegenheit, diesen Defekt überhaupt zu bemerken. Der Kern des Problems ist, dass Asus zusätzliche Hardwarefunktionen offenbar nicht ordentlich per QA getestet und trotzdem ausgeliefert hat. Ich vermute eine Tendenz, nur den „Golden Path“ zuverlässig zu testen.

    • Nutzer von Windows-Laptops sind inzwischen so abgestumpft gegenüber der Realität, dass nicht alles perfekt funktioniert, dass sie sich angewöhnt haben, die Unannehmlichkeiten einfach hinzunehmen.

  • Im Vorspann stand, dass ein LLM (Large Language Model) verwendet wurde, und diesen Stil merkt man wirklich sehr stark. Die Informationen sind solide, aber dieser übermäßig geglättete Tonfall gefällt mir nicht, weil er nicht wie die Arbeit eines Menschen wirkt. Ich frage mich, warum alle unbedingt menschlich wirkende Ausdrucksweisen vermeiden wollen.

  • Ich frage mich, warum Produktrezensenten — sogar verbraucherfreundliche und angesehene Seiten wie rtings oder notebookcheck — selbst allgemein bekannte Schwächen in ihren Reviews nicht erwähnen. Es ist unerquicklich, wenn man sich von Mundpropaganda und stellar Reviews zum Kauf verleiten lässt, dann Probleme erlebt und auf Reddit nur zu hören bekommt: „Das ist halt normal.“ Ich frage mich wirklich, warum es diese Kultur gibt.

    • Um das Problem tatsächlich zu finden, muss man den MUX-Schalter auf dGPU-only stellen und LatencyMon länger als 2 Minuten laufen lassen. (Ob das auch im iGPU-Freipass-Modus so ist, weiß ich nicht.) notebookcheck hat die LatencyMon-Werte tatsächlich protokolliert und sogar explizit vermerkt, dass das Gerät für Echtzeit-Audio ungeeignet ist
      Beispielreview von notebookcheck Solch extreme Latenzen wurden dort allerdings nicht festgestellt.

    • Wenn man direkter und sensibler hinschaut, ist es vernünftig zu prüfen, von wem solche Review-Seiten gesponsert werden.

  • Ich frage mich, ob dieser „Programmierer“ (streng genommen nicht der richtige Ausdruck) den Code, der innerhalb eines Interrupts schläft, überhaupt selbst getestet hat oder ob das in einem aufgesplitteten Arbeitsablauf in einer anderen Abteilung gleichgültig durchgewunken wurde. Es ist auch gut möglich, dass einfach die automatisierten Tests bestanden wurden und man sich danach dachte: „Egal, weiter.“ Wenn es einen Dogfooding-Prozess im Microsoft-Stil gegeben hätte, also dass Entwickler ihre eigenen Produkte tatsächlich selbst benutzen, hätten sie dieses Verhalten auf ihren eigenen Laptops wahrscheinlich erlebt und behoben.

    • Als ich früher Firmware als externer Dienstleister für ein großes Hardware-Unternehmen in Taipeh gemacht habe, habe ich mir angewöhnt, Bugs komplett zu ignorieren. Wenn man einen Bug meldete, wurde man ausgeschimpft, weil man sich mit etwas beschäftigt hatte, das nicht zu den zugewiesenen Aufgaben gehörte. Das Hardware-Team bezeichnete Firmware-/Treiber-/Software-Entwickler mit abwertenden Begriffen, und Feedback wurde ebenfalls ignoriert. Solche Geschichten überraschen mich daher nicht.

  • Dasselbe Problem tritt auch auf meinem MSI-Gaming-Laptop von 2019 (GS65 Stealth) auf. Innerhalb einer Minute nach dem Start von LatencyMon erscheinen ständig >10-ms-Stotterer. Wenn ich alle ACPI-Geräte deaktiviere, verschwindet das Stuttering, aber dann kann ich zugleich die dGPU nicht mehr verwenden. Ich vermute, dass dieses Problem bei vielen Gaming-Laptops mit dGPU weit verbreitet zusammenhängen könnte. Es wird auch auf einen MSI-Forenbeitrag zu ACPI-Latenzproblemen verwiesen. Es wird empfohlen, nach „nvidia gaming laptop stutter latencymon acpi“ zu suchen.

  • Kurzfassung: ASUS-Gaming-Laptops sollte man nicht kaufen, bis dieser Defekt vollständig behoben ist; wer noch in der Garantiezeit ist, sollte einen Garantieanspruch geltend machen und bereit sein, notfalls sogar vor das Small Claims Court zu gehen.

    • Die meisten Laptops haben von vornherein gar keinen dGPU-only-Modus, in dem dieser Bug sichtbar wird. Tatsächlich habe ich auf meinem Laptop nie den dGPU-only-Modus per MUX verwendet; dieser Modus verbraucht nur mehr Strom und bringt fast nichts.

  • Ich verstehe Leute, die Macs aus US-Produktion pushen. Es ist kaum zu glauben, dass ein derart schwerwiegendes Problem fast vier Jahre lang ausgeliefert wurde. Ich weiß jetzt immerhin sicher, was ich künftig nicht mehr kaufen werde.

    • Apple hatte auch ähnliche Probleme. Als Beispiel wird ein Fall genannt, in dem ein EFI-Firmware-Problem abgestritten wurde
      Verwandter Artikel

    • Auch für Nutzer außerhalb des „Reality Distortion Field“ ist klar, dass Apple seine ganz eigenen Probleme hat.

    • Ich habe acht Jahre lang bei der Arbeit Macs benutzt, und im Großen und Ganzen liefen sie gut, aber ich hatte zwei größere Probleme. a) Einmal wurde plötzlich nicht mehr geladen; als der Akku noch voll war, habe ich sofort die Daten migriert und das Gerät ersetzt, wobei ich Wechselspeicher vermisst habe. b) Ein Jahr lang gab es bei iTunes beim Start eines Streams mit etwa 25 % Wahrscheinlichkeit statt Musik heftiges Rauschen; wenn man erneut auf Play drückte, war es meistens behoben. Das begann mit einer bestimmten OS-Version und war in der nächsten Version wieder behoben; in anderen Apps trat das nicht auf. Wegen der Vorstellung „Macs sind grundsätzlich perfekt“ gab es dazu kaum Informationen, und ich habe viel Zeit sinnlos investiert. Weniger gravierend, aber ebenfalls störend, war ein Problem, bei dem der Akku leer wurde und das Gerät heiß wurde, wenn Outlook lief und ich den Laptopdeckel schloss. Outlook hat einen schlechten Ruf, aber in einem Exchange-Unternehmen kommt man letztlich doch zu dem Schluss, dass man es einfach benutzen sollte.

    • Auch bei MSI-Laptops gab es tatsächlich einen EFI-Bug, durch den der Befehl rm -rf / dazu führen konnte, dass UEFI-Booten nicht mehr möglich war
      Erklärung des Problems

    • Zur Formulierung „Macs pushen“ wird gefragt, ob man das auch Gamern oder VR-Nutzern gegenüber sagen kann.

  • Seit etwa 2015 habe ich beschlossen, nie wieder einen Laptop mit umschaltbarer Grafik zu kaufen, und das hat sich bewährt. Ich finde es immer lächerlich, wie „Premium“-Marken praktisch nichts in Firmware-Entwickler investieren, aber enorme Summen ins Marketing stecken.

    • Ich hatte ebenfalls 2013 einen „Optimus“-Laptop und schwor mir danach, nie wieder so etwas zu benutzen. Zwar bedeutete das mehr Aufwand mit Desktop oder Server, aber ich habe es nie bereut, am Ende nur noch die iGPU zu verwenden.

  • ASUS hätte mit nur 0,01 % seines Marketingbudgets die Erfahrung von Millionen Nutzern verbessern, Austauschkosten senken und den Ruf der Marke steigern können. Solche Phänomene zeigen, dass viele Unternehmen organisatorisch falsch aufgestellt sind, weil sie fälschlich glauben, Marketing sei effizienter als gute Ingenieursarbeit.