#Sometimes a sudden stop of updating screen (& game crash) while playing some games. Post 2
1 messages · Page 1 of 1 (latest)
How much ram do you have, what CPU and motherboard do you have and what ram do you have
Is your bios up to date
How long was it not updated
So hopefully the Intel oxidation and stability issues are not the issue here
Is your laptop out of warrenty
i'll catch up after lunch. had high schol today lol
well thats good
that is good. perhaps one of the more reassuring options to suggest the errors are your gentoo build having eaten it's own foot
i've not played cyberpunk at all
if there was a game related bug i wouldnt be familiar with it
when's the last time you attempted a windows 11 clean reinstall?
that was my chore yesterday lol
make a disk image windows backup with acronis bootable or something similar, make a new windows 11 install usb
the 23h2 to 24h2 windows upgrade broke some windows installs
mostly older preexisting installs
1 day old and so far been fine
couldnt be arsed to go on a fishing expedition for my legit windows xp pro key so just used massgrave activation lol
another phrase i have too many years experince reflecting on is "windows reliability oxymoron"
eventually every windows install goes sour. it's just a matter of time until they do
Unfortunately this looks like the Intel CPU issue
The crashes usually occur during short, heavy loads (like when games load they decompress textures or whatever), but can still be stable under a full load generated by a stress test. I ran IPT for 8 hours with no issues. It also gets worse over time. I looked at systemd logs and found that most crashes happen on one cpu core and turning that core of would help
you also need to update bios to have new cpu microcode. It does not fix a broken cpu, but stops future degradation
your system log should have a log that tells you:
kernel: emerge[269695]: segfault at a9 ip 00007f2572d8b018 sp 00007ffcaf818c48 error 4 in libpython3.12.so.1.0[7f2572bc2000+23a000] likely on CPU 10 (core 20, socket 0)
also your case could be completely different
❯ curl -s https://paste.gentoo.zip/TXmt5U6m | grep -o -P "likely on CPU \d+" | awk '{arr[$0] += 1} END{ for(i in arr) { printf "%d: %s\n", arr[i], i} }' | sort -r
82: likely on CPU 8
61: likely on CPU 12
55: likely on CPU 13
50: likely on CPU 21
46: likely on CPU 23
44: likely on CPU 14
43: likely on CPU 9
42: likely on CPU 3
42: likely on CPU 20
38: likely on CPU 6
38: likely on CPU 2
35: likely on CPU 18
35: likely on CPU 16
34: likely on CPU 4
34: likely on CPU 15
34: likely on CPU 0
33: likely on CPU 5
33: likely on CPU 22
30: likely on CPU 19
29: likely on CPU 10
26: likely on CPU 1
24: likely on CPU 11
21: likely on CPU 17
17: likely on CPU 7
you have a lot of crashes
yeah you'd probably have to remove those somehow
I don't use that feature
do you use those high level compiler optimizations or something?
ah, well that makes everything more difficult as a lot of those could be legit bugs
I just have -march=native -O2 -pipe which is already more than binary distributions have
well binary distributions have to build for a more generic x86 than the cpu you have for it to run on more hardware
well it took me months to figure out it was specific cpu cores for my case and I thought that was good enough to say it's the CPU and not some other issue
for me the crashes were rare, but sort of clustered. It would work fine for a month then crash a couple of times in a day
Avoiding using max nproc for emerge builds moving forward may preserve the remaining cpu reliability
Beyond -j10 to -j16 with portage is unnecessary
There's a gentoo wiki page that has or had a warning regarding never defining or using makeopts and emerge default opts --jobs at the same time
I can't find it rn on my phone
The result is emerge task multiplication of both values
Great option to burn down a cpu
Gentoo wiki should have focused more on recommendations for sane and safe build job volume than even mentioning nproc as realistic
With the intel 13th 14th gen defects your laptop won't be the only casualty
someone may have removed the warning. irresponsible
check the commit history
and creates another
horrific compiler latency
impulsive solutions dont solve complcations :)
it was only a matter of time until the absurd recommendation of using every cpu thread for compile jobs damaged something
you havent been the first nor willl be the last
one of the main reasons reasonable gentoo users were amused by this decades ago
if your main and only focus of using gentoo is performance you've been mislead
do you use undervolting? i had just the same issues with a by vendor undervolted laptop until i ran over that issue walking through every bios option where i found they had set their default option to "slightly agressive" as of undervolting.
Resulted in mce (machine check events) events reaching from cannot access cache lines to invalid instruction during compilation and more rare core dumps.
You could check for mce events with an mce logger
Bios settings look fine to me