EPYC 7002 CPUs may hang after 1042 days of uptime
old.reddit.com
EPYC 7002 CPUs may hang after 1042 days of uptime
1–10 of 109 posts
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#2A 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.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#3A 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.
Air gapped machines and kernel live patching both exist.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#4A 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.
Kernel bugs are rare. Most (almost every single) vulnerability can be patched without rebooting.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#5It seems a C6 state is an individual core sleeping. The intersection of people who don't reboot for 3 years and people who have sleep states enabled must be pretty small. It's an interesting bug though!
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#6A 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.
You don't need full system resets to get security updates. Kexec, live patching, userspace reboot.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#7A 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.
I dont understand opinons like this
Just because it would be dangerous for your nodejs web_app.exe running on ubuntu behind apache fully exposed on the internet
then there are billion other ways to use computers, like even air gapped systems.
So, dont try to justify obvious flaw
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#8It seems a C6 state is an individual core sleeping. The intersection of people who don't reboot for 3 years and people who have sleep states enabled must be pretty small. It's an interesting bug though!
I had a very similar issue with some AMD-based servers (bulldozer, I think) about ten years ago. There was a bug where Xen-based virtual machines could set a C-state on cores it was assigned, but for whatever reason it wasn't able to wake them up. It was fun trying to figure out what the heck was going on.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#9A 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.
1042 days ought to be enough for anybody
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#10A 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.
I dont understand opinons like this Just because it would be dangerous for your nodejs web_app.exe running on ubuntu behind apache fully exposed on the internet then there are billion other ways to use computers, like even air gapped systems. So, dont try to justify obvious flaw
I mean, hardware is cheap enough that any server of importance should be individually disposable.
Yeah, you can do stuff to maximize uptime but if it needs to stay up that badly you have to consider the case of the hardware needing to be turned off at some point.
> So, dont try to justify obvious flaw
I'm not, it's a bug and should be fixed. But I think if anything is powered for 3 years straight it's a bit concerning.
Otherwise you're liable to find things like that somebody started something by hand 2 years ago, and at a critical moment nobody quite remember what the command was.