Earlier quoted context omitted.
It feels a little bit different. One creates uncertainty in all floating point results, given you don’t know when it happens. The other requires you to reboot maybe every ~3 years and you know exactly when it happens. I’m not saying we should tolerate a defect, but it doesn’t feel nearly as problematic.
It means anyone launching amd powered virtual machines on cloud providers can experience this now, at any point, and you don't know when it will happen, given this type of CPU could have been bought, booted or rebooted anytime in the past three years. Seems comparably problematic to me.
EPYC 7002 CPUs may hang after 1042 days of uptime
51–60 of 109 posts
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#52Earlier quoted context omitted.
It means anyone launching amd powered virtual machines on cloud providers can experience this now, at any point, and you don't know when it will happen, given this type of CPU could have been bought, booted or rebooted anytime in the past three years. Seems comparably problematic to me.
I’d prefer a bug that crashes a program than one that quietly inserts wrong data and keeps going.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#53Earlier quoted context omitted.
It means anyone launching amd powered virtual machines on cloud providers can experience this now, at any point, and you don't know when it will happen, given this type of CPU could have been bought, booted or rebooted anytime in the past three years. Seems comparably problematic to me.
Google already does preemptive VMs where an instance can go down if it's needed elsewhere. It's something you can design your services to handle easily, if you aren't already doing so. Why wouldn't cloud providers be aware of how long a specific CPU has been up and plan around it? Also, do cloud providers generally never reboot their systems?
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#54Earlier quoted context omitted.
It feels a little bit different. One creates uncertainty in all floating point results, given you don’t know when it happens. The other requires you to reboot maybe every ~3 years and you know exactly when it happens. I’m not saying we should tolerate a defect, but it doesn’t feel nearly as problematic.
It also has a fairly easy solution: disable the CC6 sleep state. The practical effects from that will most likely be minimal or non-existent for most users of these CPUs.
This is now the second time AMD has screwed up the C6 state. Ryzen first gen would hang daily for me when due to a similar bug.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#55Earlier quoted context omitted.
It means anyone launching amd powered virtual machines on cloud providers can experience this now, at any point, and you don't know when it will happen, given this type of CPU could have been bought, booted or rebooted anytime in the past three years. Seems comparably problematic to me.
> amd powered virtual machines on cloud providers Cloud providers are very unlikely to use sleep states. I mean, is possible... but I'd bet against it.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#56Earlier quoted context omitted.
It feels a little bit different. One creates uncertainty in all floating point results, given you don’t know when it happens. The other requires you to reboot maybe every ~3 years and you know exactly when it happens. I’m not saying we should tolerate a defect, but it doesn’t feel nearly as problematic.
It means anyone launching amd powered virtual machines on cloud providers can experience this now, at any point, and you don't know when it will happen, given this type of CPU could have been bought, booted or rebooted anytime in the past three years. Seems comparably problematic to me.
So no, it’s not going to start randomly hitting people.
> Seems comparably problematic to me.
Not even close. The FDIV bug hit common operations that could be issued millions of times per second. This bug only applies to specific configurations that haven’t been rebooted for 3 years and has a clear workaround.
They’re not even close to comparable in impact and ability to work around. Literally many orders of magnitude different.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#57Earlier quoted context omitted.
It means anyone launching amd powered virtual machines on cloud providers can experience this now, at any point, and you don't know when it will happen, given this type of CPU could have been bought, booted or rebooted anytime in the past three years. Seems comparably problematic to me.
The cloud providers now know of this bug. They will live migrate you to a different machine or shutdown reboot. Only on-premise will have this issue.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#58I feel like some of the comments here are missing the point. Yes it's only likely to effect a small number of users, so did the intel fdiv bug, both are defective products. Back then intel were pressured into a recall, today we seem too willing to put up with being sold broken stuff.
Again, this is secondhand but from people who worked directly in the industry at the time.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#59Earlier quoted context omitted.
It also has a fairly easy solution: disable the CC6 sleep state. The practical effects from that will most likely be minimal or non-existent for most users of these CPUs.
> disable the CC6 sleep state. This is now the second time AMD has screwed up the C6 state. Ryzen first gen would hang daily for me when due to a similar bug.
A motherboard update from MSI applied something from AMD and that fixed the issue.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#60A machine staying up for almost 3 years is irresponsible in this day and age. Yeah, I remember people having uptime competitions on Slashdot and the like some decades back, but you only need to look at the ssh logs of a 5 minutes old machine to realize this is a terrible idea in modern times.
Are you perhaps a Windows user? In the Linux world updates don't necessarily require reboots.