Back then intel were pressured into a recall, today we seem too willing to put up with being sold broken stuff.
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.
Seems comparably problematic to me.
This one is interesting because its preconditions are so trivial, and it will affect many more people than usual.
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 or change a single BIOS setting, what makes you think they’d be interested in tearing down their servers, physically replacing the CPU, and reassembling all of them with the associated downtime and inevitable accidental damage to some units? Nothing about that makes sense from a business perspective.
Good lord, can you imagine how long just a few of those would take in a data center?
Also, as a direct user of the CPU, if the fdiv bug would impact you it would affect you often rather than once every three years which is the impact frequency of this fault.
Another matter that affected the fdiv bug is that the Pentium line was the first time a CPU had been aggressively marketed directly at the general public in quite the way it was. Prior to that only manufacturers and techies would have known about it and they were used to errata for hardware components. The public more generally had an impression that hardware (at least undamaged hardware) was reliable and only software had bugs, and the fdiv bug invalidated that view of reality causing a bit of a panic.
There are definitely cases where hardware should be exchanged with fixed chips, particularly the small business/consumer/hobbyist range where exchanging CPUs is worth the time and effort. The RDRAND problem with Ryzen chips was much worse because it actually happened all the time and there is still no microcode fix available for some motherboards (though AMD already makes the fix available so it's more of an issue about a lack of motherboard support than broken hardware).
i remember reading that when hard disks just came into the mass market they were so expensive that having some bad sectors was not such a big deal... and so hard disk would usually come with a sheet of paper listing the known broken sectors (detected at QA stage, i guess).
maybe someone older than me (i guess somebody in their 50ies or 60ies) could confirm that.
I'm not sure if that ever went away, though... I think the IDE firmware in more modern hard disks knew how to redirect bad sectors to good sectors, so the end user never even noticed.
Again, this is secondhand but from people who worked directly in the industry at the time.
Please note, that we are not talking about a core sleeping for three years. We are talking about a core going to deep sleep, when the system has been up for three years or longer.
https://www.anandtech.com/show/11110/semi-critical-intel-ato...
https://www.servethehome.com/intel-atom-c2000-series-bug-qui...
for AMD Ryzen 7 3700X
https://bugzilla.kernel.org/show_bug.cgi?id=217257
Might this be potentially related?
Not sure if this is applicable to EPYC CPUs, probably not. But I would expect that it's possible to disable C6 in some similar way on EPYC CPUs without rebooting the system. (If you are actually at risk of running into this issue, you likely don't want to reboot the system…)
At least Cisco told us about it themselves. We just fail-over rebooted until they fixed it.
https://news.ycombinator.com/item?id=28340101 Watch Windows 95 crash live as it exceeds 49.7 days uptime [video]
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.
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
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.
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
[1] https://www.youtube.com/watch?v=LZTaXjt2Ggk
[2] https://www.drax.com/electrification/4-of-the-longest-runnin...
BUT this doesn't mean you need to have downtime, in the same way a train unit in a railway system going through maintenance doesn't mean your railway system has downtime.
Redundancy is a must have feature for reliable systems and that means you system must be able to cope with random hardware failure or rebooting a server unit.
And both planned and unplanned maintenance of components are important normal business which in a well desingned reliable system should not lead to downtime.
Similar testing failure cases is important and should be done.
so either you don't run a high reliably system (and likely don't run into this bug ever), or you run a proper reliable system (and it's not a big deal), or you run a badly desingned or operated system pretending to be high reliably but but really being that... which is irresponsible (if you are aware)
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.
You don't need to reboot a machine to update ssh.
You only need to reboot the machine to update the kernel; for everything else, you just have to restart the corresponding user-space processes (and even PID1 can re-exec itself). Most kernel vulnerabilities are not remotely exploitable, so as long as you can trust your user-space processes (and keep them updated), it should be safe enough.
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 on running the vulnerable version of the services that use them.
At that point you might as well reboot.
Modern Fedora has a very Windows-like mechanism where you reboot to update. You reboot, the system installs updates, then reboots again.