3 ms·
> For your claims on Xeon's bugs, just wondering when was the last time Intel had to patch the microcode to fix bugs that can continuously crashing day to day w
by jmgao 9y ago
> For your claims on Xeon's bugs, just wondering when was the last time Intel had to patch the microcode to fix bugs that can continuously crashing day to day workloads such as compiling some linux packages?
Intel had an even worse one in 2014: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
Glibc merged a patch to use Intel's shiny new TSX transactional memory extensions when available to do hardware lock elision, except TSX was completely busted, and any time a process used pthread_mutex_lock, there was a chance that it would immediately crash, or corrupt memory silently. (In practice, this would happen all the time.)
Their solution was to release microcode that just turned off TSX entirely.
- smilekzs 9y agoTSX has been an experimental new feature --- disable it and all is good again, since there is no production-quality software targeting it. On the other hand, to me it seems that Ryzen segfault bug cannot be simply eliminated. Disabling ucode cache might help. Disabling ASLR "pretty reliably" (per grandparent) resolves it. But I would imagine "pretty reliable", sans official investigation report from AMD, not reliable enough for those operating server farms, which jeopardizes the main value proposition of EPYC. By no means am I bashing AMD's new tech though --- it's just CPUs are so critical that you want strong guarantees on "from this ucode patch onwards, you won't get hit by this particular problem, at least 99.9999% of the time".