3 ms·

I am a Ryzen user, actually built my Ryzen system on its release day. For your claims on Xeon's bugs, just wondering when was the last time Intel had to patch t

I am a Ryzen user, actually built my Ryzen system on its release day. 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? In case you don't fully understand the situation - when Ryzen was released, it doesn't work with many memory modules on the consumer market, as of today, for pretty high probability, you still don't get the top speed of RAM you paid for, it crashes on day to day compilation jobs, the AMD GPIO linux module maintained/contributed by AMD is too buggy to run on Gigabytes motherboards, oh, let's don't forget the FMA3 bug. Downplaying the issues causing troubles for Ryzen users do not get Ryzen better.

sliken 9y ago
How about the intel fdiv bug? My understanding is that BIOS updates have improved the speed, stability, and clock speeds available. This is far from unusual, read newegg for any new intel socket/chip and the reviews are full of dimms XYZ didn't work with motherboard ABC. Every motherboard manufacturer posts a list of compatible DIMMS they test with, unfortunately they are rarely the dimms available to consumers to buy in quantity 2-4. Thus the market opportunity for crucial that does their own testing and has a generous replacement policy.
deleted 9y ago
[deleted]
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 ago
  TSX 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".

sliken 9y ago

How about the intel fdiv bug? My understanding is that BIOS updates have improved the speed, stability, and clock speeds available. This is far from unusual, read newegg for any new intel socket/chip and the reviews are full of dimms XYZ didn't work with motherboard ABC. Every motherboard manufacturer posts a list of compatible DIMMS they test with, unfortunately they are rarely the dimms available to consumers to buy in quantity 2-4. Thus the market opportunity for crucial that does their own testing and has a generous replacement policy.

deleted 9y ago

[deleted]

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 ago
TSX 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".