A small CPU-table correction can matter without announcing new processors. The range identifies how Linux classifies model values, not a catalogue of eight upcoming products.
The exact boundary
The July 29 correction assigns Family 0x1a, models 0xd0-0xd7 to Zen 5. It splits the previous 0xc0-0xef Zen 6 interval into 0xc0-0xcf and 0xd8-0xef. The commit changes internal generation flags; it does not supply a list of commercial CPUs or quantify a performance effect.
Hexadecimal ranges are easy to misread
In decimal, Family 0x1a is 26 and models 0xd0-0xd7 are 208-215. Counting inclusively gives 215 − 208 + 1 = 8 identifiers. Our diagram shows the carved-out interval between the two remaining Zen 6 blocks.
Those eight values do not imply eight marketed processors. Several products can share a family/model identifier and differ in core count, frequency or configuration. Conversely, a familiar product-family name is not a substitute for the numeric fields a particular kernel check uses.
Diagnose the actual code path
The lscpu manual explains its CPU-information output and virtualization caveats. Record numeric family/model values and the running kernel when investigating a match. A brand string alone does not prove whether the relevant generation flag was set, especially inside a virtual machine with a presented CPU model.
Then connect the classification to the specific behaviour under investigation. A claim about scheduling, error handling or counters needs evidence from that consumer of the flag; it cannot be inferred merely because the table changed.
We removed the earlier categorical statement that no shipping CPU was affected because the cited commit does not establish it. The verified result is narrower and useful: the generation boundary is corrected. Nothing here is a measured speedup or a prediction of AMD’s product roadmap.
September 8: verify the exact Zen5 range fix and remove unsupported claims about affected shipping CPUs, generic model names and measured performance.