[Rozwiązano] Google Chrome 143.0.7499.169 na Debian 13 – segfault i błędy GCM przy streamingu wideo

dLogan napisał:

Cześć. Wszystkiego Dobrego w Nowym Roku.

Przychodzę z problemem. Odpaliłem sobie streaming na Chromie i notorycznie mam takie błędy jak niżej:
[84679.370765] ThreadPoolForeg[159163 ...

Bezpośrednia odpowiedź
- Bardziej prawdopodobny winowajca: konfiguracja jądra/ścieżka grafiki (i915 + VA‑API/kompozytor) niż sama pamięć RAM. Zmiana RT → Liquorix i ustabilizowanie obrazu to mocna poszlaka na warstwę kernel/driver.
- Błędy GCM (DEPRECATED_ENDPOINT/QUOTA_EXCEEDED) są uboczne i nie powodują „Kurzej twarzy”.
- RAM mimo wszystko trzeba zweryfikować testem – ale nie wymieniałbym go w ciemno.

Kluczowe punkty:
- Zostań na Liquorix albo stock PREEMPT_DYNAMIC; unikaj RT do zastosowań multimedialnych.
- Sprawdź i uporządkuj ścieżkę VA‑API/i915 (firmware, właściwy driver iHD, wyłączenie zbędnych opcji i915).
- Zrób testy A/B Chrome z włączoną/wyłączoną akceleracją GPU, Wayland vs X11.
- Przepuść długie testy pamięci; testuj kości osobno.

Zastrzeżenie: bez wyników testów nie da się w 100% wykluczyć RAM. Poniżej plan, który pozwoli rozstrzygnąć sprawę.

---

Co zrobić „od ręki” (kolejność ma znaczenie)
1. Zostań na Liquorix na 48–72 h i obserwuj. Jeśli stabilnie – nie wracaj do RT.
2. Chrome: wykonaj dwa testy A/B:
- A: uruchom bez GPU: `google-chrome --disable-gpu` – jeśli brak crashy, wina w ścieżce GPU.
- B: z GPU, ale bez VA‑API: `google-chrome --disable-features=VaapiVideoDecoder` – jeśli brak crashy, wina w VA‑API.
3. Upewnij się, że używasz sesji X11 lub Wayland – przetestuj obie:
- X11: `--ozone-platform=x11`
- Wayland: `--ozone-platform=wayland`
4. Odinstaluj stary sterownik X.org „intel”, jeśli jest: `sudo apt purge xserver-xorg-video-intel` (na Kaby/Coffee Lake zalecany jest „modesetting”).
5. Firmware i microcode:
- `sudo apt install firmware-misc-nonfree intel-microcode intel-media-va-driver vainfo`
- sprawdź `dmesg | grep -i -e microcode -e i915` (czy ładuje GuC/HuC, brak błędów).
6. Wyłącz znane „psujące” funkcje i915 (jako test, pojedynczo!):
- dopisz do GRUB: `i915.enable_psr=0 i915.enable_fbc=0`
- rozważ testy z GuC/HuC: `i915.enable_guc=0` lub `i915.enable_guc=3` (zależnie co działa stabilniej na Twojej platformie).
7. VA‑API porządek:
- `vainfo` powinno pokazać driver iHD. Jeśli nie, testowo: `LIBVA_DRIVER_NAME=iHD google-chrome ...`
- sprawdź mpv: `mpv --hwdec=vaapi <URL>` – jeżeli MPV jest stabilny, a Chrome nie, problem leży w Chromium/flags.
8. Wyłącz Vulkan w Chrome (czasem pomaga na iGPU Intela): `--disable-features=Vulkan` i wymuś GL: `--use-gl=desktop`.
9. Kompozytor środowiska: w KDE/Plasma ustaw renderowanie na OpenGL 3.1 i „Zapobieganie rozrywaniu” na „Pełne”, przetestuj też z wyłączonym kompozytorem (Alt+Shift+F12).
10. RAM: uruchom Memtest86+ min. 2 pełne przebiegi; jeśli OK – przetestuj każdą kość osobno w tych samych slotach. Dodatkowo w systemie: `memtester 4G 10` albo `stress-ng --vm 4 --vm-bytes 75% --timeout 1h`.

---

Szczegółowa analiza problemu

- Log kernela „segfault … error 4” oznacza błąd stronicowania przy odczycie w przestrzeni użytkownika (brakująca strona; tryb user). To typowy efekt:
- dereferencji nieprawidłowego wskaźnika w procesie (często po stronie biblioteki graficznej/medialnej),
- kaskady po GPU hang/resecie i „zgaszeniu” procesu renderera,
- rzadziej realnej usterki RAM (ta zwykle ujawnia się też poza wideo).
- Korelacja z wideo fullscreen i fakt, że RT powodował zakłócenia obrazu, wskazuje na i915/VA‑API/kompozytor, nie na RAM. Kernela RT nie poleca się do desktop/multimedia: PREEMPT_RT zmienia semantykę blokad/przerwań, co potrafi „rozjechać” i915 przy intensywnym dekodowaniu i page‑flipach.
- Liquorix (Zen scheduler, niski jitter, inne domyślne governory) bywa stabilniejszy dla multimediów. To, że „z miejsca” zniknęły zakłócenia obrazu po zmianie na Liquorix, jest bardzo wymowne.
- GCM „DEPRECATED_ENDPOINT/QUOTA_EXCEEDED” to logi usług sieciowych Chrome (push/telemetria). Nie korelują z crashami rendererów i możesz je pominąć diagnostycznie.

Przyczyny wg prawdopodobieństwa:
- konfiguracja jądra/sterownika i915/ścieżki VA‑API – wysokie,
- interakcja Chrome ↔ środowisko graficzne (Wayland/X11, kompozytor, Vulkan/GL) – średnie/wysokie,
- błąd konkretnej wersji Chrome/Widevine – średnie,
- pamięć RAM – niższe, ale do weryfikacji testem.

---

Procedura diagnostyczna (skrócona z komendami)
- Identyfikacja platformy GPU:
`lspci -nnk | grep -A3 VGA`
- Stan i915 i firmware:
`dmesg | grep -i i915`
`sudo grep -i -e guc -e huc /var/log/kern.log`
- VA‑API:
`vainfo` (sprawdź „Driver version: Intel iHD”)
- Chrome:
`chrome://gpu` (czy „Video Decode: Hardware accelerated”)
- Debug i915 po zawieszeniu wideo (opcjonalnie):
`sudo mount -t debugfs none /sys/kernel/debug`
`sudo cat /sys/kernel/debug/dri/0/i915_error_state`
- RAS/MCE (błędy kontrolera pamięci):
`sudo apt install rasdaemon && sudo systemctl enable --now rasdaemon`
`sudo journalctl -k | grep -i -e mce -e machine`

---

Wnioski praktyczne dla Ciebie
- Na Twoim miejscu zostałbym przy Liquorix i „dopieścił” i915 (PSR/FBC off, sprawdzenie GuC/HuC, właściwy driver iHD).
- Jeśli test „--disable-gpu” eliminuje problem – skup się na i915/VA‑API/kompozytorze, nie na RAM.
- RAM testuj, ale wymianę rozważ dopiero po twardych dowodach (błędy Memtesta lub RAS/MCE).

---

Pytania uzupełniające (pomogą zawęzić temat)
1. Wersja Chrome/Chromium i kanał (Stable/Beta): `google-chrome --version`.
2. Sesja graficzna (Wayland czy X11) i środowisko (Plasma/GNOME?).
3. Wynik `vainfo` i `chrome://gpu`.
4. Czy masz zainstalowany `xserver-xorg-video-intel` (jeśli tak – usuń i przetestuj).
5. Czy problem występuje także w Firefox (z VA‑API włączonym) lub w MPV z `--hwdec=vaapi`?

Daj znać po pierwszych testach A/B (GPU/VA‑API, Wayland/X11) i po memteście – wtedy doprecyzujemy kolejny krok.

dLogan napisał:

Podałem wyżej, czyli 143.0.7499.169, kanał Chrome'a to stable.

Od lat X11 i XFCE. Wersja Xorga to 7.7, XFCE to 4.20.

Firefox na Debianie oficjalnie nie ma dostępu do serwisów streamingowych, może ew YT, ale wymuszenie dostępu przez zmianę user agent i 'korzystanie' będzie jeszcze bardziej problematyczne. VLC z dekodowaniem sprzętowym vaapi nie sprawiał problemów, z mpv nie korzystam.

Mam ale jest tam tylko intel_drv z tego co pamiętam. A i915 (który jest w użyciu) siedzi w innym pakiecie. Sprawdzę, ale obstawiam że nic to nie da.

Obydwa wykonane na stockowym kernelu Debiana:

Do powyższego wrzucam plik tekstowy w załączniku z pełnym raportem.


@ElektrodaBot
Czy praca na stałym taktowaniu może mieć wpływ na działanie zintegrowanego GPU?
Pytam, bo mam i5-11400 który ciągle pracuje na 2,6, i takich problemów nie mam. Wcześniejszemu i5-8500T też zdarzały się wpadki, ale sporo rzadziej (było tam 6 rdzeni zamiast 4 w i5-7500T).
Sprawdzę stockowego kernela ale obstawiałbym problem w nie wyrabianiu się igpu poprzez skalowanie. Kiedyś od skalowania było cpufreq (do 3.11 jeszcze dało się ustawić na sztywno daną częstotliwość, potem już nie).
Wrzucam dodatkowe info. Niżej są wyniki cat /proc/cpuinfo | grep MHz .
W pierwszym przypadku wyłączone są opcje dotyczące oszczędzania energii w biosie, przez co i5-11400 cały czas pracuje jak niżej:
cpu MHz : 2600.000
cpu MHz : 2600.000
cpu MHz : 2600.000
cpu MHz : 2600.000
cpu MHz : 2600.000
cpu MHz : 2600.000
cpu MHz : 2600.407
cpu MHz : 2600.000
cpu MHz : 2600.000
cpu MHz : 2600.194
cpu MHz : 2600.000
cpu MHz : 2600.000
Liquorix HP i5-7500T:
cpu MHz : 2699.993
cpu MHz : 2700.007
cpu MHz : 2700.232
cpu MHz : 2700.000
Ten sam kernel co w przypadku i5-11400 ale na domyślnych ustawieniach biosu:
cpu MHz : 1036.180
cpu MHz : 1000.289
cpu MHz : 800.000
cpu MHz : 1030.625
Zanim zacznę zabawę z ustawieniami sterownika itd to skupiłbym się na wyodrębnieniu odpowiedniej opcji z liquorixa i dopisaniu jej do stockowego kernela Debiana.
Pytania:
Jak wyciągnąć konfigi kerneli żeby potem móc je porównać np diffem?
Czy można w bootloaderze dopisać dowolną opcję czy to raczej będzie kwestia rekompilacji?

Bezpośrednia odpowiedź
- Tak – stałe, wyższe taktowanie CPU i ograniczenie głębokich C‑states potrafi istotnie ustabilizować iGPU na Kaby Lake (i5‑7500T). To nie „brak mocy” iGPU, tylko latencje i wahania napięć/przejść energetycznych, które potrafią rozjechać i915 podczas fullekranowego wideo.
- Różnice między Liquorix a stockiem w Twoim przypadku da się w 90% odtworzyć parametrami startowymi (GRUB) i ustawieniami cpufreq/EPP – bez rekompilacji.
- Konfigi jąder porównasz wprost z plików /boot/config‑… lub /proc/config.gz (poniżej komendy).

---

Dlaczego stałe taktowanie pomaga (krótko technicznie)
- Kaby Lake (HD 630) ma własne zegary, ale CPU/iGPU współdzielą zasilanie i budżet mocy pakietu. Agresywne zejścia w C6/C7 i RC6/DC po stronie grafiki + nagłe skoki zapotrzebowania (fullscreen, zmiana strumienia/chronometrażu) = skoki napięcia/opóźnienia w memory path.
- To bywa wyzwalaczem GPU hang/reset → ubija proces renderera w Chrome (segfault/error 4), zwłaszcza pod X11 + kompozytor. Utrzymanie CPU „wyżej” i spłycenie C‑states stabilizuje zasilanie i timing.

---

Jak wyciągnąć konfigi kerneli i porównać
- Z działającego kernela:
- z /boot: cp /boot/config-$(uname -r) ~/config-running.txt
- jeśli dostępne: zcat /proc/config.gz > ~/config-running.txt
- Z drugiego kernela (bootnij w niego i powtórz) albo skopiuj odpowiedni /boot/config-… do osobnego pliku.
- Porównanie:
- diff -u ~/config-stock.txt ~/config-liquorix.txt | less
- lub czytelniej: apt source linux (lub źródła liquorix) i użyj scripts/diffconfig:
- scripts/diffconfig config-stock.txt config-liquorix.txt

Na potrzeby Twojego case’u kluczowe sekcje do przejrzenia: CONFIG_PREEMPT*, CONFIG_HZ_*, CONFIG_CPU_FREQ_*, CONFIG_INTEL_PSTATE, CONFIG_DRM_I915_*.

---

Co da się zrobić bez rekompilacji (GRUB + userspace)
1) Parametry GRUB (testuj pojedynczo lub małymi pakietami):
- iGPU/i915:
- i915.enable_psr=0
- i915.enable_fbc=0
- i915.enable_rc6=0 (tylko testowo; zwiększy pobór mocy, ale często stabilizuje)
- i915.enable_guc=0 (albo 3 – zależnie co stabilniejsze na Twoim sprzęcie)
- C‑states CPU (zmniejszenie latencji):
- intel_idle.max_cstate=1
- processor.max_cstate=1 (działa tylko, gdy używane jest acpi_idle; dodaj razem – jeden zadziała)
- Opcjonalnie, jeśli chcesz wykluczyć intel_pstate/HWP na czas testu:
- intel_pstate=disable (wtedy użyjesz acpi-cpufreq + governor performance)

Edytuj /etc/default/grub, dopisz ww. do GRUB_CMDLINE_LINUX_DEFAULT, potem sudo update-grub i reboot.

2) Ustawienia taktowania bez rekompilacji:
- Jeśli masz intel_pstate (HWP) – ustaw EPP na „performance” i podnieś minimum:
- sudo apt install linux-cpupower
- dla każdego policy: echo performance | sudo tee /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference
- opcjonalnie ustaw minimum (zapobiega spadkom do 800–1000 MHz):
- for p in /sys/devices/system/cpu/cpufreq/policy*; do sudo sh -c "cat $p/cpuinfo_min_freq > $p/scaling_min_freq"; done
- alternatywnie: sudo cpupower frequency-set -g performance
- Jeśli wyłączysz intel_pstate (intel_pstate=disable): zainstaluj cpufrequtils i ustaw globalnie performance:
- sudo apt install cpufrequtils
- /etc/default/cpufrequtils: GOVERNOR="performance"
- sudo systemctl enable --now cpufrequtils

3) Utrwalenie ustawień po starcie:
- Prosty unit systemd (np. /etc/systemd/system/cpu-perf.service):
- [Unit]
Description=CPU perf
- [Service]
Type=oneshot
ExecStart=/bin/sh -c 'for p in /sys/devices/system/cpu/cpufreq/policy*; do echo performance > $p/energy_performance_preference; done'
- [Install]
WantedBy=multi-user.target
- sudo systemctl enable --now cpu-perf

---

Dodatkowe kroki praktyczne dla Twojej konfiguracji (X11 + XFCE + Chrome 143)
- Sterownik Xorg:
- Na Kaby/Coffee Lake lepiej „modesetting” niż stary „intel”. Sprawdź w /var/log/Xorg.0.log co się ładuje.
- Jeśli jest xserver-xorg-video-intel – przetestuj jego usunięcie: sudo apt purge xserver-xorg-video-intel (Xorg użyje modesetting + glamor).
- XFCE kompozytor:
- Window Manager Tweaks → zakładka Compositor → testowo wyłącz compositor na czas odtwarzania lub włącz „Synchronize drawing to the vertical blank”.
- Chrome A/B, żeby potwierdzić, że sedno to ścieżka GPU:
- Bez GPU: google-chrome --disable-gpu
- Z GPU, bez VAAPI: google-chrome --disable-features=VaapiVideoDecoder
- Wyłącz Vulkan (często pomaga na iGPU Gen9 pod X11): --disable-features=Vulkan --use-gl=desktop
- VA‑API sanity check:
- sudo apt install intel-media-va-driver vainfo
- vainfo – sprawdź, czy ładuje iHD; jeśli nie, testowo: LIBVA_DRIVER_NAME=iHD google-chrome …
- Diagnostyka i915 po „Kurzej twarzy”:
- sudo mount -t debugfs none /sys/kernel/debug
- sudo cat /sys/kernel/debug/dri/0/i915_error_state | wc -c (jeśli >0, był GPU hang; można przejrzeć header błędu)

---

Co naprawdę warto porównać w configach Liquorix vs stock
- CONFIG_PREEMPT_* (Liquorix zwykle PREEMPT_DYNAMIC; RT miałeś – tego unikaj na desktop/multimedia)
- CONFIG_HZ=1000 (niskie opóźnienia – compile‑time; nie ustawisz z GRUB)
- CONFIG_INTEL_PSTATE / CONFIG_CPU_FREQ_* (ale i tak zachowanie ustawisz z userspace)
- CONFIG_DRM_I915_* (GuC/HuC jako „built‑in” vs moduł; runtime i tak możesz sterować i915.enable_guc=…)

W praktyce stabilność da Ci: ograniczenie C‑states + governor/EPP + wyłączenie PSR/FBC/RC6 (przynajmniej testowo). Kompilacja nie powinna być konieczna.

---

Proponowany, szybki plan testów na stockowym kernelu
1) GRUB: intel_idle.max_cstate=1 i915.enable_psr=0 i915.enable_fbc=0
2) Ustaw EPP=performance (patrz wyżej) i sprawdź, czy MHz trzyma ~2.7 GHz.
3) Jeśli dalej sypie: dodaj i915.enable_rc6=0 (albo alternatywnie i915.enable_guc=0).
4) Jeśli dalej: przełącz na modesetting (usuń xserver-xorg-video-intel) i wyłącz compositor w XFCE.
5) Jeżeli „--disable-gpu” w Chrome eliminuje problem – to 100% ścieżka GPU; wtedy zawężamy do i915/VA‑API/kompozytor.

---

Odpowiedzi na Twoje pytania wprost
- Czy praca na stałym taktowaniu może mieć wpływ na iGPU? Tak – najczęściej pozytywny (stabilizuje), bo ogranicza skoki napięć i latencje przy przejściach energetycznych. Różnice między i5‑11400 a i5‑7500T wynikają też z generacji i lepszej logiki zasilania w 11 gen.
- Jak wyciągnąć konfigi? Z /boot/config‑… lub /proc/config.gz (zcat) i porównać diffem; dla czytelności użyj scripts/diffconfig.
- Czy „dopisać w bootloaderze czy rekompilować”? Zdecydowaną większość potrzebnych zmian (C‑states, i915, even pstate off) zrobisz parametrami GRUB i userspace. Rekomplikacja nie jest wymagana, a różnice typu HZ=1000/tryb preempcji nie są krytyczne dla tego problemu.

Daj znać:
- co pokazuje Xorg.0.log (jaki DDX: modesetting czy intel),
- wynik A/B Chrome (–disable‑gpu i –disable‑features=VaapiVideoDecoder),
- czy po intel_idle.max_cstate=1 + EPP=performance „Kurza twarz” ustaje. Potem zawęzimy do minimalnego zestawu ustawień, by nie trzymać CPU „na sztywno” bardziej niż trzeba.

dLogan napisał:

Konfigi wyciągnąłem i rzeczywiście jest różnica pstate/cpufreq.

Błąd. Teraz jest linux-cpupower

Dodałem pierwszą opcję, zrobiłem usługę dla systemd z wykorzystaniem cpupower i póki co działa.

@ElektrodaBot
Jaki wpływ może mieć trzymanie procka na sztywno?
Na tą chwilę rozwiązaniem problemu okazało się... ustawienie na sztywno częstotliwości procka. Będę testował dalej, może któreś z powyższych informacji uda się wykorzystać.

Bezpośrednia odpowiedź
- Trzymanie CPU „na sztywno” stabilizuje zasilanie i timingi całego pakietu (CPU + iGPU), co u Ciebie eliminuje zawieszki i reset iGPU podczas streamingu. To normalne, że na Kaby Lake (i5‑7500T, HD630) takie ustawienie pomaga.
- Koszty: wyższy pobór mocy w idle, wyższa temperatura spoczynkowa i częściej pracujący wentylator; wydajność/żywotność CPU nie cierpi w praktyce, o ile temperatury są w normie.
- Da się to zoptymalizować tak, by zachować stabilność bez „betonowania” zegara na 2.7 GHz.

---

Szczegółowa analiza
Dlaczego „sztywny zegar” pomaga:
- CPU i iGPU współdzielą budżet mocy oraz ścieżkę do pamięci. Głębokie C‑states CPU (C6/C7) i skoki z 0.8→2.7 GHz powodują krótkie wahania napięcia/opóźnienia właśnie wtedy, gdy iGPU dekoduje klatki (fullscreen, zmiany strumienia). To bywa zapalnikiem GPU hang → reset i „Kurza twarz” w Chrome.
- Utrzymanie wyższego, stałego zegara redukuje te przejścia i stabilizuje i915.

Skutki uboczne „rigid clock”:
- Pobór mocy: w typowym mini‑PC różnica idle potrafi wzrosnąć o kilka–kilkanaście watów (zależnie od obudowy/chłodzenia).
- Termika/hałas: +5–10°C w spoczynku nie jest rzadkie; wentylator częściej wchodzi na wyższe obroty.
- Turbo: jeśli dodatkowo ustawisz niski limit max, możesz rzadziej widzieć 3.3 GHz (w praktyce nieistotne dla streamingu).
- Trwałość: kluczowa jest temperatura i napięcie, nie sam fakt „stałego 2.7 GHz”. Przy temperaturach <80°C i braku OC wpływ na żywotność jest pomijalny.

---

Jak to zoptymalizować (żeby było cicho i nadal stabilnie)
Zamiast „betonu” proponuję podejście: podnieść „podłogę”, zostawić skalowanie w górę i spłycić C‑states.

1) Jeśli masz aktywne intel_pstate/HWP (sprawdź: cat /sys/devices/system/cpu/intel_pstate/status → active):
- Ustaw preferencję energii na wydajność i podnieś minimum:

To utrzymuje CPU „wysoko”, ale pozwala mu płynnie rosnąć do turbo i lekko spadać, bez wpadania w 800–1000 MHz.

2) Jeśli używasz cpufreq (intel_pstate=disable lub brak HWP):
- Zamiast „sztywno”, ustaw podłogę i zostaw turbo:


3) Spłyć C‑states (główne źródło latencji) – delikatniej niż na „0/1”:
- W GRUB spróbuj najpierw: `intel_idle.max_cstate=2`
- Jeśli dopiero „1” daje spokój – zostań przy „1”, ale … patrz punkt 4.

4) i915 – wyłącz znane „oszczędzacze”, które często psują fullscreen:
- W GRUB: `i915.enable_psr=0 i915.enable_fbc=0`
- RC6 zostaw włączone; wyłącz (`i915.enable_rc6=0`) tylko jeśli mimo powyższego wróciłyby wieszki (koszt energetyczny RC6=0 jest zauważalny).

5) Xorg/XFCE:
- Upewnij się, że używasz DDX „modesetting”, nie starego `xserver-xorg-video-intel` (usuń pakiet, Xorg sam przełączy się na modesetting).
- W XFCE kompozytor: włącz VSync („Synchronizuj rysowanie z vblank”) albo testowo wyłącz kompozytor przy fullscreen.

6) Chrome (tylko jeśli jeszcze coś się zdarzy):
- Wyłącz Vulkan i wymuś GL: `--disable-features=Vulkan --use-gl=desktop`
- Test kontrolny: `--disable-features=VaapiVideoDecoder` (jeśli stabilne → problem w VA‑API/ścieżce GPU, nie RAM/CPU).

---

Propozycja konfiguracji „minimalnie inwazyjnej”
- GRUB:

- Usługa systemd (przykład pod HWP):

- Jeśli nie HWP: `cpupower frequency-set -g schedutil -d 2.2GHz -u 3.3GHz`.

To zwykle daje tę samą stabilność co „sztywny 2.7 GHz”, a znacząco obniża pobór i hałas.

---

Monitorowanie
- Pobór/idle: powertop (kolumny C‑states/Device stats), ewentualnie watomierz „z gniazdka”.
- GPU: `intel_gpu_top` (pakiet intel-gpu-tools) – sprawdzisz, czy iGPU nie zalicza „stalls”.
- Temperatury: `sensors` (lm-sensors). Trzymaj CPU <80°C pod długim stresem; w idle celuj w 35–50°C.

---

Podsumowanie
- „Sztywny zegar” to poprawne i bezpieczne obejście niestabilności DVFS/C‑states na Kaby Lake pod X11. Największą ceną są waty i hałas, nie „zużycie” CPU.
- Rekomenduję zejść z pełnego „betonu” do: podniesionego minimum (min_perf_pct ≈ 75–85%) + spłyconych C‑states + wyłączonego PSR/FBC. Zwykle daje identyczną stabilność bez istotnej kary energetycznej.
- Gdyby problem wrócił, wróć do „max_cstate=1” i daj znać – dobierzemy jeszcze delikatniej parametry i915 lub przełączymy DDX/kompozytor.