Ubuntu fryser slumpmässigt, Windows fungerar perfekt.

Jag har en äldre burk som jag vill köra Ubuntu på. Har försökt med några års mellanrum, men oavsett vilken version av Ubuntu jag kör, verkar den frysa slumpmässigt.
Kör jag Windows på maskinen tuggar den på hur bra som helst, inga problem att få flera dagars uptime, så hårdvaran verkar det inte vara något fel på.

Jag blir inte klok på när den fryser heller. T ex, jag kan starta den och köra Rocket League en halvtimme, men fem minuter efter jag avslutat så fryser den. En annan gång fryser den bara ett par minuter efter inloggning. Det verkar inte alls relaterat till last.

När den fryser, då menar jag helfryser. Går inte att nå via ssh, tangentbordet ger ingen respons, muspekaren går inte att flytta.

Hårdvara:
Gigabyte P55-USB3 - Har prövat att uppgradera till senaste bios utan skillnad.
Intel i5 760
Geforce GTX 670 2GB
4x4GB 1600MHz DDR3 - Inga fel i memtest
2x Samsung 830 - En till Windows, en till Ubuntu
IDE DVD/RW

Har försökt köra tail på kernel-loggen, dmesg-loggen och sysloggen utan att se något särskilt.
Hade så gärna felsökt vad det är som händer, men utan att se något i loggarna eller något sätt att trigga felet är det väldigt svårt att felsöka.

Finns det någon mer logg jag skulle kunna titta i? Något bättre sätt att debugga vad som händer?

Nej, har inte prövat med annan disk. Skulle så klart kunna pröva att köra live-usb och se vad som händer.

När jag körde smartmon-tools hittade jag ett intressant attribut, som är högre på disken med Linux.
"POR Recovery count" (Power Off Reset) alltså när disken plötsligt tappar ström, exempelvis genom att datorn stängs av vid strömavbrott.
Linuxdisken har 7011, medan Windowsdisken har mer normala 319.

Smart varnar inte, men över 7000 låter väldigt högt. O andra sidan har disken suttit i en väldigt välanvänd macbook i 5 år, så det skulle kunna vara från varje gång datorn öppnats och stängts. Jag får följa dessa värden över tid och se vad som händer. Är det så att Linuxdisken skenar iväg snabbare än Windowsdisken är det definitivt något skumt på gång där.

Edit:
Nej, det verkar inte vara det. Ett par hängningar senare så har båda diskarna ökat precis lika mycket i POR Recovery count.
För att provocera lite extra prövade jag att dra ut sata-kablarna under drift, det fick inte maskinen att hänga sig direkt heller.

Inte särskilt jobbigt att byta dist, det är en ren installation. Men det hade varit givande att hitta något bättre sätt att logga vad som händer.

Har börjat i änden med att utesluta hårdvara.

Kopplade ur dvd-enheten, samma sak.
Bytte från nvidia-driver till nouveau, samma sak.
Bytte nvidia-kortet till ett gammalt ati-kort, samma sak.
Hittade en tråd om att nätverkskortet frös systemet i äldre kernels, inaktiverade nätverkskortet, samma sak.

Nollställde bios och det verkar som den slutat hänga sig. Så jag håller på att gå igenom alla mina biosinställningar en och en nu, för att se när den börjar hänga sig igen. Förhoppningsvis är det något specifikt som får den att bete sig illa.

Ligger ett par gamla kraschloggar där, för gnome och gdm, men ingen av dagens 10 krascher.
Netconsole kanske är mer effektivt än att taila kernel-log över ssh

Ja, men väldigt lite. Original går turbo för CPUn till 3.33GHz, i Linux körde jag CPUn 3.6GHz. Oklockade ram-minnen. Cpun är god för 4.2GHz med hård last och många dagars uptime i Windows, så det borde finnas massor av marginal.

Det lurigaste är att den nästan aldrig hänger sig vid last, utan idlandes på skrivbordet.
Har provspelat Rocket League i 40 minuter vid 4GHz, men sen kan den hänga sig efter några minuter på skrivbordet.
De slumpmässiga hängningar verkar ske precis lika enkelt oavsett om den kör i 3.6GHz eller 4GHz. Så är den arg på något, verkar det inte vara kopplat till varken frekvens eller last, frågan är vad.

Med det sagt, var det mycket fler inställningar än bara överklockning som var ändrade från default. Så jag slår på en i taget och försöker få den att hänga sig igen.

Jag tror jag hittat felet!
Kollade /proc/cpuinfo och såg hur processorhastigheten rörde sig upp och ner, fastän C-states och turbo är inaktiverat från bios.

En sökning senare har jag lärt mig att i modernare kernlar finns det en drivrutin som heter intel_idle och den kör över vad bios/uefi har ställt för inställningar. Enligt kommentarer i källkoden ska detta både vara effektivare och säkrare mot ACPI-buggar. Det kan jag köpa, men det är frustrerande när man inte vet att detta sker. Detta är inte bara ett problem för överklockare, utan även för serverfarmar, där administratörer vill ha koll över hur processorerna beter sig.

Detta skulle förklara varför jag får problem vid idle men inte vid last. Och varför mina problem är de samma oavsett om jag kör 3.6 eller 4GHz, det är det ständiga hoppandet vid idle som ställer till det och detta sker inte från Windows.

För att kontrollera intel_idle-drivern får man skicka en kernelparameter, vilket jag gör genom /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1"

Efter detta så håller sig CPUn sig till den hastighet som är satt och nu har datorn stått och snurrat stabilt på skrivbordet ett par timmar.