Dator fryser fast

Började få problem för lite mer än en vecka sen, då min dator frös om jag inte körde ett program som krävde fullskärm. Kvittade om det hade fokus eller om jag var nertabbad. De senaste dagarna är problemet signifikant värre och nu fryser datorn hela tiden inom sekunder eller minuter efter boot. Den fryser överallt, förutom i BIOS och i GRUB, samt i memtest86+ via GRUB. När den fryser kräver den avstängning via strömknappen.

Har tittat på väldigt många liknande trådar här och på andra forum, men hittar tyvärr inte någon helt jämförbar. Antingen fryser de andras dator även i BIOS, eller så saknar tråden tydligt avslut, eller så har de andra problem som min dator ej har nu.

Har gjort en hel del tester den senaste veckan. Har försökt att dokumentera allt så bra som möjligt. För att inte översvämma forumet med detaljer så tar jag inte med allt, men säg till om något saknas. Dessutom är nog inte alla tester relevanta längre.

Min huvudsakliga uppsättning är

• OS Ubuntu 24.04.

• CPU AMD Ryzen 9 5900X 12-Core Processor

• CPU-kylare NH-D15 chromax black

• GPU Gigabyte GeForce RTX 4070 12 GB Windforce OC V2

• MEM 4x 8GB DDR4-3466 XMP Kingston

• DISK WD Black SN850 intern NVMe SSD

• PSU be quiet! system power 9 CM ATX12V 2.4/EPPS12V - 80 PLUS Bronze - AC 100-240 V - 600 W

• Moderkort ASUS ROG STRIX B550-F GAMING

• Chassi Cooler Master SL600M

• Chassi-fläktar 2x Noctua NF-A20 PWM Premium 200mm

• Skärm 27" S2721DGFA IPS QHD HDR 165 Hz.

Har även provat Fedora42 och EndeavourOS Nvidia utan framgång. Har provat att ansluta min GPU både med DP och HDMI-kabel. Har bytt ut den mot en Nvidia GeForce GTX 1050 2 GB kopplad med HDMI. Har plockat bort min SSD och bara kört med live ISO via USB. Internet och mus är borttagna. Alla kablar är kontrollerade att de sitter åt. Har provat att byta ut strömkabeln till 4070 GPU.

När datorn fryser fortsätter samtliga fläktar att snurra. Alla LED-lampor fortsätter att lysa och indikatorljuset vid frampanelen för USB på chassit fungerar fortfarande (det lyser upp när man är nära det).

Att trycka alt + prt scn + R E I S U B fungerar inte. Även om jag ändrar

kernel.sysrq = 176

till

kernel.sysrq = 244

i /etc/sysctl.d/10-magic-sysrq.conf

Mitt nuvarande antagande är att felet är hos PSU, moderkort, CPU eller drivrutin. Men jag vet inte hur jag finner en slutsats längre.

Datorn är fint rengjord flera gånger och inga höga temperaturer har observerats.

Har stresstestat min CPU flera gånger i Ubuntu med stress-ng enligt

stress-ng --class cpu --sequential 0 -t 60 -v

och det har märkligt nog fått köra klart trots instabiliteten. Men dator har fryst direkt efter.

Har kört memtest86 via GRUB flera gånger. Både med alla fyra RAM kort ikopplade och bara med ett. Inga fel rapporterade där.

Inne i Ubuntu har jag ändrat /etc/default/grub i olika varianter:

GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX_DEFAULT="nomodeset"
GRUB_CMDLINE_LINUX_DEFAULT="nomodeset modprobe.blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm"
GRUB_CMDLINE_LINUX_DEFAULT="nomodeset modprobe.blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm,nouveau"
GRUB_CMDLINE_LINUX_DEFAULT="quiet nvidia-drm.modeset=1 rd.driver.blacklist=nouveau"
GRUB_CMDLINE_LINUX_DEFAULT="quiet nvidia-drm.modeset=0 rd.driver.blacklist=nouveau"

Har uppdaterat BIOS till v 3621 x64

Min tanke är att om min PSU är för svag för mitt system borde jag sett problem mycket tidigare och det borde blivit bättre när jag använt svagare och färre komponenter. Vet att Nvidia och Linux inte direkt är gifta, men har använt detta system länge utan problem. Hade en 3070 tidigare som även den fungerade bra länge.

För cirka 1 år sen råkade jag peta av 3 pinnar i hörnet på min CPU. Dessa lyckades dock en reparatör fixa och har kunnat använda den utan problem sen dess (fram till nu då). Är absolut öppen för möjligheten att det är denna som är orsaken, men vill hitta ett sätt att bekräfta det i så fall. Har tyvärr ingen annan CPU av samma socket att prova med. Om det nu är min CPU som är felande förstår jag inte varför den klarar av stresstesterna.

Vad kan jag prova härnäst, utöver att byta ut delar? Vad är annars mest troliga komponenten att byta ut? Finns det någon klar tanke med att den inte fryser i BIOS eller GRUB?

Inne i BIOS har jag utfört de fyra möjliga varianterna på självtest av min NVMe SSD med bara 1 RAM inkopplad.

Jag kan ha gjort stress-ng test med bara 1 sticka, inte hundra dock. Har försökt att köra min installation av Ubuntu på SSD, ny installation av både Ubuntu och EndeavourOS via USB med bara 1 sticka. Något spec du tänkte på som jag kan testa med 1x RAM?

När jag byggde ihop datorn, då förvisso för en 3070 GPU och inte 4070, kollade jag på sidor för strömförbrukning. Då blev jag rekommenderad ett 500 W PSU, och jag tog ett 600 W. Tror jag även gjort samma koll med mitt 4070. Ser dock nu på Inets hemsida att rekommenderade PSUn är 650 W, lol. Men det talar ju inte om helheten, i min förståelse.

Men om PSUn nu vore underdimensionerad, varför har jag inte sett problem tidigare, särskilt när jag bytte upp från 3070 till 4070? Dessutom borde ju problemet minskat när jag kopplade bort en del komponenter och ersatte GPUn med en GTX 1050?

Tror jag förstod bättre vad du skrev efter jag skrivit detta. Men funderingarna kvarstår nog ändå. Har tyvärr ingen kraftigare PSU tillhands. Har kanske kvar min gamla, men den är på 500 W.

Nej, har hittills inte testat i Windows men ska göra det härnäst.
OCCT har en Linux build. Ska testa den.

RAM testerna i memtest86+ v 7.00 startar direkt när jag öppnat dem via GRUB. Eller menar du profilen från BIOS? Hm, enligt mina anteckningar har jag inte laddat om till optimised default settings i BIOS när jag kört dem. Så har det på att göra listan också då.

Nej, har ej provat AIDA64. Ska se om jag kan få tag på deras program i Windows eller Linux.

Ja, osäkerheten är rätt seg och detta tar rätt mycket tid av en. Hoppas finna en lösning att skriva här, så nästa med liknande problem enklare hittar hjälp...

Jag fattar inte vad det är som orsakar felen, men de kommer väldigt snabbt nu. Knappt att jag hinner starta terminalen efter att ha loggat in utan att datorn fastnar.

Har då inte hunnit köra memtest med standardinställningarna på RAM vad jag vet, men har kört med dem inställningarna och t ex fått datorn att frysa efter inloggning. Så RAM-profilen är åtminstone enda boven här.

memtest med 4x RAM med DOCP inställningar

memtest med 4x RAM med grundinställningar

inga konstigheter här.

Märkte här att ubuntu 24.04 ISO kör med memtest v 7.00 medan EndeavourOS kör med v 7.20.

Ja, det är en framtida möjlighet. Ska på resa om ett tag så blir efter det då, om lösningen inte är hittad innan dess.

Moderkortet är på misstänkt listan, men vet inte hur jag ska testa den. Har inte sett några skador på den. Har fått statisk elektricitet på ett moderkort tidigare och det tvärdog av mina händer.

Har då provat att ominstallera operativsystemet flera gånger och flera olika operativsystem där på. Verkar inte vara felet (eventuell om det är nåt Linux-specifikt fel).

Igår provade jag att köra EndeavourOS x86_64 Fallback (nomodeset) via USB ISO. Stängde ner installatören, öppnade terminalen med watch sensors och öppnade systemövervakaren. Sen stod datorn så, utan att hänga sig, i cirka 1.5 h. Tycker det är märkligt och det pekar väl på PSU eller GPU fel? Körde med 4x RAM, utan ethernet, utan SSD, 4070 GPU. Systemövervakaren visade att CPU knappt användes medan sensors visade låga temperaturer.

Idag, samma uppsättning, men EndeavourOS x86_64 UEFI Default istället. Alltså normala OS-varianten. Samma startprocedur som innan. Men nu hänge sig datorn efter 5 min.

Provar nomodeset OS igen. Datorn frös inom 40 min från start, när jag var AFK. Hoppades hitta något stabilt att köra testerna på men icke.

Windows 10. Typiskt att det inte verkar finnas live ISO som med Linux. Installatören fastnade inte på 10 min, men behövde starta om för att sätta i SSD.

Med SSD tillbaka.. Installation av Windows 10 Home x64. Krasch under val av installationsplats.
Han se något om ERROR SOCKET under (automatisk) omstart. In i Ubuntu. Terminal:

$ sudo dmidecode -s bios-version

3621

$ journalctl -k --grep=mce

- kernel: mce: [Hardware Error]: Machine check events logged
- kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 27: baa000000000080b
- kernel: mce: [Hardware Error]: TSC 0 MISC d0130fff00000000 SYND 5d000000 IPID 1002e00000500
- kernel: mce: [Hardware Error]: PROCESSOR 2:a20f10 TIME 1745236051 SOCKET 0 APIC 0 microcode a201030
- kernel: MCE: In-kernel MCE decoding enabled.

Kanske är CPUn som är orsaken trots allt?

anslöt ethernet. laddar ner OCCT.

OCCT Power test: default. 1h. inga problem och ingen krasch.

CPU test. 1h. Mode: Extreme. Load type: variable. Startcycle 1. Instruction set auto. Thread setting = auto. Inga fel, ingen krasch efter heller. Har haft datorn igång nu över 2h utan krasch eller frysning.

Att testa:

Nedgradera BIOS
Windows 10 igen?
Stänga av strömspar i UEFI/BIOS
AIDA64
Ny CPU
Ny PSU

Hm, är verkligen ingen expert. Men min uppfattning är att avslutade kommandon inte drar kraft längre. Men inte helt hundra på vad du frågar.

Har faktiskt uppe exakt den tråden på en av mina flikar just nu haha. Har sett det om c-states innan, men då i trådar där problembilden inte var likadan (och oftast utan avslut). Är i färd med att testa BIOS just nu.

Tänkte mest dumpa lite anteckningar här. Ingen lösning är funnen ännu.

Fixar med format av USB för BIOS flashback inne i Ubuntu. Krasch. Gör om och lyckas. Till BIOS: ominstallation av v 3621.

$ sudo dmidecode -s bios-version
3621

Testar stabilitet i Ubuntu. Körde htop (systemövervakning) i 26 min utan att något hände. Efter ytterligare ca 15 min vid skrivbordet frös datorn. Tycker det verkar som att ju mindre datorn används desto högre är sannolikheten att den fryser.

Nedgraderade BIOS till 3611. Uppfattat detta som samma sak som att nedgradera linux-firmware. Belys mig gärna annars. Efter cirka 5 min, med terminalen i bakgrunden (den användes ej aktivt och inget var igång i den) så frös datorn. Antingen så är BIOS-versionen inte felet, eller så behövs en ännu äldre version.

Min uppfattning är att AMD Ryzen 9 5900X får sin microcode uppdaterad automatiskt när BIOS uppdateras. Vet inte om jag kan göra något här (eller om jag ens borde det).
$ sudo dmesg | grep microcode
[ 1.125412] microcode: Current revision: 0x0a20102b

Håller på att testa cstates just nu. Blandades resultat.

Att begränsa cstates verkar vara lösningen.

Jag har AMD CPU så:
$ sudo nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet processor.max_cstate=1"
$ sudo update-grub
$ reboot
bekräfta att ändringen är gjord:
$ sudo cat /sys/module/processor/parameters/max_cstate
1

quiet är nog inte avgörande här, utan smaksak. Efter ovanstående ändring och omstart av datorn, inloggning och sen AFK till utloggning gick det flertalet timmar utan bekymmer.
Provade att ändra max_cstate till 2, men systemet verkar ha fryst ett tag efter det. Ska testa fler cstates i framtiden.

Har man Intel CPU gör man istället (lärde mig detta i min förvirring):
$ sudo nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1"
$ sudo update-grub
$ reboot
bekräfta att ändringen är gjord:
$ cat /sys/module/intel_idle/parameters/max_cstate
1

Båda ovanstående parametrarna ska representera samma sak i min uppfattning, men bara en av dem används av systemet, vilket beror på vilken CPU man har.

Detta var alltså lösningen för mig ser det ut som! *ta i trä*. Gäller alltså både för Debiansystem, eftersom det fungerade för mig, och Arch-system, eftersom det fungerade för individen i länken ovan.

Uppdaterar denna tråd om jag finner något nytt.