For instance, Intel's 8th-gen has more than 150 listed errata that still remain, and those chips were launched in 2017. However, some errata always remain, even in shipping chips. These errata can encompass all types of bugs, from security holes to malfunctioning flags and cache tags that don't operate correctly, and the chipmakers do their best to stomp them out before launch. With billions of transistors in play, issues are inevitable: It isn't uncommon for a chip to have a thousand or more errata/bugs that are corrected in newer steppings of the chip or with firmware tweaks before launch. Modern CPUs are the most complex devices constructed by humankind, and they almost always come to market with numerous errata/bugs discovered either during or after the chips reach their final shipping revision (stepping). While this bug is interesting, it isn't a showstopper for the majority of users, and errata in chips are definitely not unusual. Also, servers for mission-critical applications often see extended uptime.
#Amd zen 4 genoa update#
The most realistic scenario would simply be those that use the Linux live patching feature or kexec to update without rebooting - that could certainly lead to the type of extended uptime that would trigger the bug. Sure, it matters, despite the fact that security updates and maintenance should be done in much, much shorter intervals. Now, while this 2.93-year core crashing bug is interesting, the question is if it really matters. The workaround is simple - either reboot before 1,044 days of uptime, which resets the CPU to restart your 1,044-day "timer," or disable the CC6 sleep state. The TSC ticks at 2800 MHz, and 2800 * 10**6 * 1042.5 days almost equals 0x380000000000000, which has too many zeros not to be a coincidence." Reddit user acid_migrain has a plausible theory about the exact timing of the core hangs, saying, "Despite what they say, the problem actually manifests at 1042 days and roughly 12 hours. The issue stems from the core failing to exit the CC6 sleep state, but AMD says the timing of the failure could vary based on the spread spectrum and REFCLK frequency, the latter of which is the reference clock that helps the chip keep track of time.
0 kommentar(er)
