xfce4-session crashed with SIGSEGV in __strcat_avx2()
that's probably not a good sign
xfce4-session crashed with SIGSEGV in __strcat_avx2()
that's probably not a good sign
Actually it might just be a bad pointer bug, which is bad, obviously, but not as bad as "your cpu just randomly forgot how to do AVX2"
it crashed while trying to execute "lock vpmovmskb %ymm6, %ecx" which is a completely reasonable bit of x86-64 machine code I'm sure
strcatting 256 bits at a time seems scary. I'm sure that's not what broke, but it's still a lot.
back in my day we moved AT MOST 4 bytes at once, never 32 of them all willy-nilly!
the fun thing is that I have an Alder Lake processor, which means that SOME of my CPU cores have AVX-512 support, so I could in theory be moving 64 bytes at once.
But in reality, because of the fact that Alder Lake is "an Abomination of Asymmetric CPU Design" (technical term), the AVX-512 support is disabled to prevent problems when my processes get migrated and suddenly lose AVX-512 support
This particular CPU has 14 cores: 6 of them "performance" and 8 of them "efficiency" and they have different CPU instruction support. Since this would cause no end of problems, the CPUID is masked to only report the lowest common denominator of supported functions
A fun thing about this is that Intel had to develop something called the Intel Thread Director, aka the Enhanced Hardware Feedback Interface.
BASICLY it means the CPU will generate an interrupt to tell the OS which cores are a good idea to put threads on right now.
it can do this multiple times a second, and works by telling how much performance and energy efficiency each CPU core has at the moment, based on things like current temperature and battery/AC power.
@waffle_iron Atom is the single most important CPU design Intel ever made and they will never let it die
@foone It amuses me to no end how Intel is happy to let people forget that efficiency cores are evolutions of Atom cores.
don't worry though. by default, linux throttles Enhanced Hardware Feedback Interface updates to 250 a second
anyway reportedly the big problem which made the split-CPUID scheme an issue was DRM:
various programs monitor their CPUID so they can see if it ever changes, on the assumption that if it ever does, someone is doing something fucky with a VM or emulation, and refuse to work.
So intel had to modify the microcode to make Alder Lake cores always return the same CPUID, to avoid it breaking DRM
which is funny, because one of the other things they did with Adler Lake is INTENTIONALLY break DRM
They dropped support for Intel Software Guard Extensions, which is a way to set up enclaves on the CPU where all information is encrypted on the fly, so even the OS or a hypervisor can't spy on it.
and Intel SGX was required to playback Ultra HD Blu-ray discs on PCs
@badsynthesis it's supposed to be hidden from you by the OS and the CPU microcode. "supposed to" being the key words
@foone ...how is one supposed to develop for these abominations? CPU/core pinning so the instruction set doesn't change halfway for everything doesn't seem very scalable.
@glyph I believe so, yeah.
@foone …wait. does that mean that it's, like, physically impossible to play UHD discs on a mac
@Unixbigot the last time Intel designed a good CPU, it couldn't divide properly
@foone some companies should not be allowed to have architecture
GAH it crashed again
another segfault: it tried to read from address 0x10000 which wasn't readable.
having your fucking session manager crash is no fun, it means everything you have open dies
I may need to memtest this machine
076萌SNS is a social network, courtesy of 076. It runs on GNU social, version 2.0.2-beta0, available under the GNU Affero General Public License.
All 076萌SNS content and data are available under the Creative Commons Attribution 3.0 license.