Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EPYC 7002 CPUs may hang after 1042 days of uptime

old.reddit.com

Post reply on HN
Print view View original

71–80 of 109 posts

Re: EPYC 7002 CPUs may hang after 1042 days of uptime

#71

Post by [deleted] »

ly3xqhl8g9 wrote: post #64
dale_glass wrote: post #2

A 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.

3 years is irresponsible? To quote Logan Roy, you, software developers, "are not serious people" [1]. Just out of curiosity looked for a list of longest running electrical devices [2]: 1840 - The Oxford Electric Bell 1871 – Souter Lighthouse in South Shields, UK 1896 – The Isle of Man’s Manx Electric Railway 1902 – The Centennial Bulb Apparently, "The Centennial Bulb has seen just two interruptions: for a week in 193…

[deleted]

Re: EPYC 7002 CPUs may hang after 1042 days of uptime

#72

Post by justinclift »

dale_glass wrote: post #16
kuratkull wrote: post #12

Earlier quoted context omitted.

Are you perhaps a Windows user? In the Linux world updates don't necessarily require reboots.

Actually as of late, Linux has been moving towards rebooting for update. Yeah, you technically can replace on-disk files while services are running. In practice this can cause trouble if an application wants to read an updated file at the wrong time, and library dependencies can require restarting a lot of stuff. For ages people would install an update containing a security fix in glibc or libz or something, and keep…

> Actually as of late, Linux has been moving ...

That's a pretty broad generalisation. Which distro's are you meaning?

Re: EPYC 7002 CPUs may hang after 1042 days of uptime

#73

Post by shrimp_emoji »

dale_glass wrote: post #16
kuratkull wrote: post #12

Earlier quoted context omitted.

Are you perhaps a Windows user? In the Linux world updates don't necessarily require reboots.

Actually as of late, Linux has been moving towards rebooting for update. Yeah, you technically can replace on-disk files while services are running. In practice this can cause trouble if an application wants to read an updated file at the wrong time, and library dependencies can require restarting a lot of stuff. For ages people would install an update containing a security fix in glibc or libz or something, and keep…

I reboot after update just superstitiously.

Also out of superstition, I avoid hibernate -- when I walk away, it's either on and locked or shutdown. (I also did this on Windows; a mixed state just seemed off-puttingly and worryingly complex to me.)

Given what you said, and because I hear hibernation is notoriously buggy on Linux, both superstitions have rewarded me. :D

Re: EPYC 7002 CPUs may hang after 1042 days of uptime

#74

Post by xp84 »

PragmaticPulp wrote: post #61
RobotToaster wrote: post #18

I 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.

> Back then intel were pressured into a recall, today we seem too willing to put up with being sold broken stuff. This bug only applies to servers that haven’t been rebooted for 3 years and have the CC6 sleep state enabled. It can be worked around by disabling CC6 sleep state or rebooting once every 3 years. If you think operators of these servers can’t be bothered to update and reboot their machines once in 3 years…

I’m picturing a long 50’ aisle filled with racks and a guy with a huge box marked “replacement CPUs” and a screwdriver.

Good lord, can you imagine how long just a few of those would take in a data center?

Re: EPYC 7002 CPUs may hang after 1042 days of uptime

#76

Post by mhuffman »

shpx wrote: post #9
dale_glass wrote: post #2

A 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

Spoken like a true AWS user!

Re: EPYC 7002 CPUs may hang after 1042 days of uptime

#77

Post by allenrb »

bioemerl wrote: post #54
arp242 wrote: post #34

Earlier 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.

They’ve improved by three decimal orders of magnitude since then. How much more can we ask of them?

Re: EPYC 7002 CPUs may hang after 1042 days of uptime

#78

Post by __alexs »

bee_rider wrote: post #38
Waterluvian wrote: post #32

Earlier quoted context omitted.

I’d prefer a bug that crashes a program than one that quietly inserts wrong data and keeps going.

It probably depends on your workload, which is a bigger deal. The fdiv bug was pretty bad, but at least fixable in software (at some cost). Anyway, recall is the right decision in either case (unless there’s a good enough workaround).

If every CPU with an errata that needed software workarounds was recalled there would be no CPUs to use.

Re: EPYC 7002 CPUs may hang after 1042 days of uptime

#79

Post by dale_glass »

ly3xqhl8g9 wrote: post #64
dale_glass wrote: post #2

A 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.

3 years is irresponsible? To quote Logan Roy, you, software developers, "are not serious people" [1]. Just out of curiosity looked for a list of longest running electrical devices [2]: 1840 - The Oxford Electric Bell 1871 – Souter Lighthouse in South Shields, UK 1896 – The Isle of Man’s Manx Electric Railway 1902 – The Centennial Bulb Apparently, "The Centennial Bulb has seen just two interruptions: for a week in 193…

Those are completely trivial complexity-wise compared to a modern server, and many don't have a real function, and mostly are artificially maintained as a curiosity.

I mean, the centennial bulb barely glows, that's why it still works. The hotter the filament gets the faster it evaporates, so a light bulb that barely makes any light can stay working forever.

Re: EPYC 7002 CPUs may hang after 1042 days of uptime

#80

Post by lanstin »

nielsole wrote: post #48
foobiekr wrote: post #47

Earlier quoted context omitted.

Which CSPs do live migration?

https://cloud.google.com/compute/docs/instances/live-migrati... Not sure about others

And it works miraculously well. I have seen a very large Oracle DB with many reads and many updates migrate with no effects outside of a big spike in sql execution times for the few hundred milliseconds it takes between the source pause and the destination resume. Seen various GCP bugs, mostly VPN and pub sun, but never anything from migration. They migrate about all the instances every two weeks, so it is an often exercised path.
Post reply on HN