Kubuntu 22.04 zawieszanie się systemu sprzętowe

Mam takie problem zainstalowałem sobie na początku grudnia kubuntu 22.04 mój laptop to ASUS R542UF-DM157
dwie karty graficzne nvidia geforce mx 130 i intel uhd grafik 620
i teraz do laptopa mam podpięty dysk twardy zewnętrzny na usb i jeszcze hub do którego są podpięte urządzenia usb np. czasami się ładuje telefon i teraz miałem taką sytuację, że podczas grania przez steam (dwa razy miałem taką sytuację) w gry system się zawiesza sprzętowo na nic nie reaguje dopiero muszę go wyłączyć w logach w dmesg nie ma żadnych błędów.
Ja sobie myślę, że to jest zawieszeni sprzętowe, a może być spowodowane tym, że jest za duży pobór prądu i zasilacz tego nie wytrzymuje bo w momencie grania to jest obciążona karta graficzna, ale tutaj jest jeszcze coś innego bo wcześniej miałem kubuntu 20.04 i czegoś takiego nie było, ale za to gry wolniej chodziły były większe lagi bo kubuntu 20.04 używał tylko nvidi, a nowe kubuntu używa intel i nvidii jednocześnie , a co wy o tym sądzicie ?

Ponoć Linux ma problemy z resetem kart graficznych, tzn. kiedyś przełączenie wirtualnego terminala powodowało reinicjację karty graficznej, czyli jej reset. Teraz prawie wszystko korzysta z mechanizmów jądra, więc i kod pewnie został zapomniany. Jak wspomniałem, ponoć kernel nie inicjuje ponownie GPU w przypadku jego zawieszenia, choć czytałem na phoronix, że AMD wysyła stosowane łatki.

Jak się Linux zawiesza, to:

  1. CTRL+ALT+F3 . Jeżeli konsola się nie pojawi po pewnym czasie, to CTRL+ALT+BACKSPACEx2, przełączasz się ponownie na terminal z interfejsem graficznym, po czym ponownie CTRL+ALT+BACKSPACEx2. Po każdym kroku warto poczekać, nawet z pół minuty
  2. Jeżeli powyższe nie przynosi efektów, to możesz nacisnąć ctrl+alt+del ponad osiem razy w ciągu dwóch sekund i poczekać na ponowny start systemu

Ja też czasem mam problem z podsystemem grafiki (OpenSUSE Tumbleweed z Plasmą5 na Waylandzie), i któreś z powyższych zawsze działało.

Problemem może być też wyczerpanie domyślnej pamięci. Podaj, ile masz dostępnego SWAP-a i ile masz ramu. Napisz też, w co grasz. W 6.1 chyba będzie MRLU (czy jakoś tak), czyli wynalazek Google mający ożywić system w przypadku braku pamięci (bo odzyskiwanie stron pamięci, w przypadku wyczerpania się puli dostępnej pamięci, w obecnej implementacji w Linuksie, może trwać nawet parę minut). Kernel 6.1 ma być dostępny już w sobotę-niedzielę, ale nie wiem, ile zajmie aktualizacja paczek,

To nie rozwiązuje twojego problemu, ale możesz korzystać z Magic SYSRQ, wtedy w wielu fatalnych sytuacjach, możesz miękko uruchomić ponownie system.

To znaczy myślę że sobie poradziłem problem był opisany tutaj

Bo ja w dmesg czasami miałem tego typu błędy i postąpiłem tak przełączyłem w nvidia-settings na nvidia (performance mode) czyli wyłączyłem kartę intela i teraz chyba jest dobrze.

Miło wiedzieć. W każdym razie, to moje rady może pomogą komuś innemu, jak bezpiecznie wyłączyć system w przypadku freeze. Chociaż i tak tracisz pracę, bo pewnie pechowiec pracował w sesji graficznej, to nie jest to twardy reset.

A więc sprawa wygląda tak, że prznisoełm się na nvidia (performance mode) i po przełączeniu się nie było awarii, ale za to tylko raz w przeciągu 3 tygodni pojawił się wpis w dmesg

i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A (start=1186099 end=1186100) time 432 us, min 1073, max 1079, scanline start 1072, end 1101

Ale awari żadnej nie było i uruchamiałem gry normalnie.
Dodam jeszcze, że te awarie w 80 % były na grze far cry 2 i far cry 3 .
postanowiłem przenieśc się na tryb nvidia (on deamod)
, ponieważ na nvidia (on deamod) lepiej wszystko działa i gry szybciej chodzą więc wyczytałem w internecie, że trzeba włączyć do opcji startowych w /etc/modprobe taki plik i915.conf i w nim taką linijkę

options i915 enable_psr=0

I to uczyniłem i po tej operacji włączyłem dwa razy grę far cry 2 i żadnych awarii poprzednio bez pliku i915.conf dwa razy uruchomiłem i dwa razy się wykrzaczyło i znowu pojawił się wpis w logach dmesg i następnie urochomiłem grę far cry 3 żeby ja przetestować i znowu to samo czy twardy reset
Dodałem w pliku i915.conf wczoraj linijkę

`options i915 enable_guc=2`

narazie się nie zawiesił
dodam, że zawsze jak mam takie linijki w dmesg

i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A (start=1186099 end=1186100) time 432 us, min 1073, max 1079, scanline start 1072, end 1101

to są również takie

[24047.267404] pcieport 0000:00:1c.5: AER: Corrected error received: 0000:00:1c.5
[24047.267429] pcieport 0000:00:1c.5: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[24047.267434] pcieport 0000:00:1c.5:   device [8086:9d15] error status/mask=00001000/00002000
[24047.267440] pcieport 0000:00:1c.5:    [12] Timeout               
[24299.688193] pcieport 0000:00:1c.5: AER: Corrected error received: 0000:00:1c.5
[24299.688223] pcieport 0000:00:1c.5: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[24299.688230] pcieport 0000:00:1c.5:   device [8086:9d15] error status/mask=00001000/00002000
[24299.688238] pcieport 0000:00:1c.5:    [12] Timeout               
[25127.385639] pcieport 0000:00:1c.5: AER: Corrected error received: 0000:00:1c.5
[25127.385663] pcieport 0000:00:1c.5: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[25127.385670] pcieport 0000:00:1c.5:   device [8086:9d15] error status/mask=00001000/00002000
[25127.385679] pcieport 0000:00:1c.5:    [12] Timeout               
[25174.796971] pcieport 0000:00:1c.5: AER: Corrected error received: 0000:00:1c.5
[25174.796980] pcieport 0000:00:1c.5: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[25174.796982] pcieport 0000:00:1c.5:   device [8086:9d15] error status/mask=00001000/00002000
[25174.796984] pcieport 0000:00:1c.5:    [12] Timeout               
[25739.429855] pcieport 0000:00:1c.5: AER: Corrected error received: 0000:00:1c.5
[25739.429884] pcieport 0000:00:1c.5: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[25739.429891] pcieport 0000:00:1c.5:   device [8086:9d15] error status/mask=00001000/00002000
[25739.429900] pcieport 0000:00:1c.5:    [12] Timeout               
[26259.523295] pcieport 0000:00:1c.5: AER: Corrected error received: 0000:00:1c.5
[26259.523326] pcieport 0000:00:1c.5: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[26259.523335] pcieport 0000:00:1c.5:   device [8086:9d15] error status/mask=00001000/00002000
[26259.523344] pcieport 0000:00:1c.5:    [12] Timeout               
[26942.326708] pcieport 0000:00:1c.5: AER: Corrected error received: 0000:00:1c.5
[26942.326735] pcieport 0000:00:1c.5: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[26942.326742] pcieport 0000:00:1c.5:   device [8086:9d15] error status/mask=00001000/00002000
[26942.326751] pcieport 0000:00:1c.5:    [12] Timeout   

W trybie nvidia (performance mode) jest dobrze, ale ja bym wołał tryb nvidfia + intel

https://wiki.archlinux.org/title/Intel_graphics

Tutaj wyczytałem, iż GUC odpowiada za zarządzanie energią, i zarządzania nią w sytuacji dwóch kart graficznych.

PS: Zastanawiam się, czemu wartość 2 rozwiązuje problem. Pewnie GUC jest układem jakoś autonomicznym i działa niezależnie od systemu, więc samo załadowanie firmware wystarczyło. To jednak jedynie moje gdybania. Próbowałeś może wartość 3?

Ja czytałem na zagranicznych forach taką wiadomośc


The problem seems to come from thermald.service I have deactivated it with systemctl disable thermald.service and removed the limitation of c-states

And for now I am not experiencing a problem, although I have configured the kernel with GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm=off nvidia-drm.modeset=1 enable_psr=0" in /etc/default/grub

Why have I read out there that it usually gives problems with laptops? and on firmware with integrated cooling systems

Maybe it has to do with the temperature error when reading the nvme?

Jak się dalej zawiesi to spróbuje ustawić taką opcję

GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm=off nvidia-drm.modeset=1 enable_psr=0" 

Ale ten użytkownik napisał, że wyłączenie servera systemctl disable thermald.service
rozwiąże problem, ale ten serwer jest odpowiedzialny za coś waznego w systemie i się boję go wyłączać.

Pakiet zarządza termiką. Nie jest niezbędny.
W Arch Linux jest w repozytorium community i jest opcjonalny.
Tu masz więcej, co ten pakiet robi:
https://man.archlinux.org/man/community/thermald/thermald.8.en

Ja zauwazyłem, że jak grałem dzisiaj w grę wrc 8 to temperatura karty graficznej była nawet 90 C i dodam, że gry mi chodzą na wyższych detalach niż powinny na tej karcie graficznej jaką mam, a mam nvidia mx 130.