APEX 17 MAX: Taktet nicht runter?

Locutus2002

Lt. Junior Grade
Registriert
Okt. 2008
Beiträge
441
Hallo,

Gestern kam mein neues APEX 17 MAX an und mir fiel auf, dass im permanent der Lüfter läuft, selbst wenn ich nichts daran mache, sogar im Energiesparmodus in Kombination mit dem "Lautlos"-Profil im Control Center. Ein weiterer Blick dort verriet mir, dass die CPU praktisch nie unter ca. 2,4 GHz taktet, lediglich der Energiesparmodus von Windows limitiert den Takt auf 2 GHz, die dann aber dauerhaft anliegen, sodass der Lüfter ständig mit ca. 2500 RPM dreht (wenn auch nicht laut). Im Vergleich zum Entertainment-Modus scheint das Lautlos-Profil völlig wirkungslos zu sein und verdient seinen Namen nicht im Geringsten.

Erst im Akkubetrieb liegen dann auch mal niedrigere Taktraten unter 1 GHz an, der Lüfter läuft dann aber trotzdem noch bei ca. 1680 RPM.

Ist das normal, soll das so sein? Ich kann es mir ehrlich gesagt nicht vorstellen.

Windows 11 ist frisch installiert, außer Treibern, inkl. Control Center, 7-zip, HWInfo und Acrobat Reader ist noch nichts installiert. Ich habe für Chipsatz und GPUs direkt die neusten Treiber verwendet, außer bei der iGPU, da habe ich wie empfohlen erst die OEM-Treiber vom mitgelieferten Stick installiert und danach auf das Update auf 25.3.2 vollzogen.

Was könnte die Ursache sein?
 
Bitte warte zunächst ein paar Tage, bis alle Windows-Updates und Hintergrundprozesse nach Ersteinrichtung durch sind, bevor du die Geräuschkulisse bei geringer Last abschließend beurteilst.

Solltest du anschließend noch Probleme mit Lüfterlautstärke im Idle haben, lege bitte einen Sensor-Log an. Am besten im "Unterhaltungsmodus", mit angeschlossenem Netzteil und mit einem Idle-Vorgang direkt nach Kaltstart.
Achte dabei auch auf die Frage, ob deine NVIDIA-GPU sich schlafen legt oder durch eine Hintergrundsoftware oder durch die Verwendung von externen Monitoren wachgehalten wird. Siehe auch:
Insgesamt ist es auf jeden Fall richtig, dass diese AMD-CPU-Serie (Dragon Range) einen für moderne Verhältnisse relativ hohen Idle-Verbrauch hat. Andererseits ist die reine Taktrate kein eindeutiger Indikator mehr für den Stromverbrauch, da Multi-Core-CPUs (der Ryzen 9 7945HX hat 16 gleichwertige Kerne) tendenziell eher Kerne abschalten (core parking), anstatt die Taktrate für die noch aktiven Kerne zu senken. Eine objektive Beurteilung der Lage ist daher nur durch Beobachtung von "CPU Package Power" und "GPU Power" in HWiNFO64 möglich.

VG,
Tom
 
Ich konnte das Problem auf sehr einfache Art lösen: ich habe im UEFI einmal die Standardeinstellungen geladen. Das war offensichtlich nicht gemacht worden, da u.A. die Webcam und die USB-C-Anschlüsse werksseitig deaktiviert waren.

Jetzt wird der Lautlos-Modus seinem Namen gerecht, da die CPU nun auf 544 MHz gedrosselt wird und dadurch die Temperatur entsprechend niedrig ist.

Ein gravierendes Problem besteht aber weiterhin: Spielen unter Linux ist quasi unmöglich, da beim Start eines 3D-Spiels, egal ob nativ (z.B. Stellaris oder BattleTech) oder über Wine/Proton scheinbar immer in den Lautlos-Modus gewechselt wird, d.h. die CPU kommt nicht mehr über 1480 MHz hinaus, bei "hoher" Auslastung sogar nicht über 544 MHz (auf allen 16 Kernen!).

Ich habe seit einer Woche verschiedenstes probiert:
  • Manjaro, EndeavourOS, CachyOS, TuxedoOS, Kubuntu, KDE neon, Ubuntu, Linux Mint
  • Kernel 6.12, 6.13, 6.14
  • X11 und Wayland
  • Deaktivierung der iGPU im UEFI ("Discrete only")
  • Deaktivierung der dGPU über Tools wie envycontrol
  • Deaktivierung von SMT
  • Deaktivierung von AMD-V/Vi
  • nvidia-open- und nvidia-Kernelmodule (jeweils Treiberserie 570)
  • verschiedene Kernelparameter für amd_pstate: passive, active, guided
  • beide für die CPU mögliche CPU-Governor: powersave, performance
  • in KDE: alle drei Energieprofile: Power Saving, Balanced, Performance (die letztlich auch nur den Governor festlegen)
  • Vulkan über DXVK bzw. VKD3D scheint ebenfalls nicht das Problem zu sein, da auch OpenGL-Spiele betroffen sind, sogar native Linux-Spiele wie Stellaris und BattleTech (beide von GoG)
  • Rücksetzung der UEFI-Einstellungen (erst dadurch habe ich bemerkt, dass dies zumindest das kleinere Windows-Problem löst). Werksseitig sind das neues UEFI (1.07.03 RTR5) und die neueste EC-Firmware (1.09.05 tTR1) bereits vorinstalliert gewesen.
Wenn ich während eines solchen Spielversuchs einen Bench mit CPU-X auf allen 32 Threads starte, kommen die Kerne ebenfalls nicht über 544 MHz hinaus.

Keine dieser Maßnahmen hatte einen Effekt. Ich habe allerdings eine recht einfache Reproduktionsmöglichkeit gefunden, die aber leider nicht immer diesen Effekt zeigt. Man nehme dazu einen USB-Stick mit Ventoy und starte von diesem ein Image einer Distri, z.B. Manjaro. Nach dem Booten des Images installiert man CPU-X und GOverlay und starte beide. Noch bevor das eigentliche Fenster von GOverlay sichtbar ist, erhält man schon ein MangoHud-Vorschaufenster mit einem animierten Würfel. Hier kann man die anliegende CPU-Taktrate ablesen, die bei mir nur 1480 MHz Maximaltakt anzeigt. Führt man gleichzeitig einen CPU-X-Bench auf allen Kernen durch, sollten die Kerne sogar auf 544 MHz drosseln.

Das klappt wie gesagt nicht immer, manchmal wird die CPU durch die GOverlay-Vorschau nicht gedrosselt, allerdings kommen CPU-X-Benches auf allen Threads dann nur sekundenweise auf 3,3 GHz, meist schwankt der Takt dann um die 1-2 GHz. Ohne GOverlay-Vorschau bzw. ohne laufendes Spiel liegen aber dauerhaft um die 3-3,4 GHz an auf allen Kernen an. Bei echten Spielen ist es wie gesagt noch schlimmer. Installiere und starte ich die native Linux-Version von BattleTech von GoG und starte (mit mangohud) eine SinglePlayer-Skirmish-Partie, kommt die CPU nie über 544 MHz, das Spiel ruckelt extrem mit ca. 12 FPS. Ein CPU-X-Bench nebenbei ändert daran nichts.

An mangohud liegt es übrigens nicht. Es ruckelt auch ohne es installiert zu haben, den Takt lese ich dann über den KDE System Monitor ab (dazu muss man sich dort ein entsprechendes Widget anlegen, das den Takt jedes Kerns anzeigt).

Ich vermute hier ein Problem mit der Firmware bzw. der Kommunikation von Linux mit der Firmware, denn irgendwie scheint die Ausführung von 3D-Programmen den Lautlos-Modus zu triggern oder zumindest stärkere Energiesparmodi. Dafür spricht, dass es die verwendete Distri egal zu sein scheint. Ein Bekannter mit dem nahezu baugleichen Tuxedo Gemini 17 Gen3 (basiert auf dem gleichen Clevo-Barebone wie das XMG Apex 17 Max) hat das Problem übrigens nicht, weder mit dem originalen TuxedoOS, noch mit EndeavourOS.

Welche Lösungsansätze könnte es sonst noch geben? Ich bin mit meinem Latein jedenfalls am Ende.
 
  • Gefällt mir
Reaktionen: Hahnfruh
Locutus2002 schrieb:
Ich konnte das Problem auf sehr einfache Art lösen: ich habe im UEFI einmal die Standardeinstellungen geladen. Das war offensichtlich nicht gemacht worden, da u.A. die Webcam und die USB-C-Anschlüsse werksseitig deaktiviert waren.

Jetzt wird der Lautlos-Modus seinem Namen gerecht, da die CPU nun auf 544 MHz gedrosselt wird und dadurch die Temperatur entsprechend niedrig ist.

Vielen Dank für das Feedback. Wie per DM angesprochen, haben wir das intern weitergereicht. Normalerweise machen wir bei jedem Laptop ein BIOS-Update und anschließend ein BIOS-Reset (selbst dann, wenn das aktuelle BIOS schon drauf ist), bei deinem Exemplar scheint der BIOS-Reset aber wohl übersprungen worden zu sein. Wir werden hier noch einmal die Mitarbeiter verstärkt darauf hinweisen. Es gibt auf den Fertigungsaufträgen eine Checkliste, aber die wird in Punkto BIOS-Updates nur händisch ausgefüllt, nicht maschinell.

Locutus2002 schrieb:
Ein gravierendes Problem besteht aber weiterhin: Spielen unter Linux ist quasi unmöglich, da beim Start eines 3D-Spiels, egal ob nativ (z.B. Stellaris oder BattleTech) oder über Wine/Proton scheinbar immer in den Lautlos-Modus gewechselt wird, d.h. die CPU kommt nicht mehr über 1480 MHz hinaus, bei "hoher" Auslastung sogar nicht über 544 MHz (auf allen 16 Kernen!). [...]
Ich habe von TUXEDO hierzu noch kein spezifisches Feedback erhalten. Eine Möglichkeit wäre, den Auftrag zu widerrufen und das baugleiche Gemini 17 Gen3 zu bestellen. Falls du schon über die 14-tägige Widerrufsfrist hinaus bist, müssten wir prüfen, ob wir Kulanz walten lassen können. Allgemein gilt: Welche XMG-Laptops sind Linux-kompatibel?

VG,
Tom
 
Ich könnte das Linux-Problem nun lösen.

Da das Gerät wie schon erwähnt baugleich mit einem Tuxedo Gemini 17 Gen3 ist, habe ich versucht das Tuxedo-Treiberpaket für Linux zu installieren. Dieses besitzt aber einen Hersteller-Check, der umgangen werden muss.
Im Arch User Repository (AUR) konnte ich ein entsprechendes Paket namens "tuxedo-drivers-nocompatcheck-dkms" finden. Nach dessen Installation und einem Neustart war das Problem behoben. Ein netter Bonus ist, dass dadurch nun auch das Tuxedo Control Center auf dem Gerät ohne Einschränkungen nutzbar ist.
 
Zuletzt bearbeitet:
Zurück
Oben