CR2 wasn’t referring to any of the register values – wasn’t even close to any of them – so we guessed it might be a general protection fault, i.e. a memory access to a non-canonical address. The report included a screenshot that, albeit truncated and lacking the beginning of the Oops message, still contained the register and code dump and the failing RIP. Older steppings and different CPU models worked just fine.
Strangely enough, the issue occurred only on the newest stepping of that very CPU model. It was a kernel panic when running a seemingly harmless workload. A Weird Bug Reportīack in September 2020, our attention was brought to an interesting issue one of our customers had on one of their platforms, an “Intel(R) Atom(TM) Processor E3950 1.60GHz”. The “recent” rise and public mentioning of similar issues here, here and here and the lost hope in waiting for Intel to comment on the matter was the final momentum that led to finishing this blog to contribute our findings on Intel CPU bugs to the wider community.Įnjoy a highly technical article peppered with lots of crash dumps and disassembly listings, doubling as a case study on the lengths our team goes to to support our customers, even if an issue lies with another vendor.
None of the processor’s publicly exported (and publicly documented) interfaces shed light on were the root cause could be found. The bug hunting journey was equally educational and frustrating, since the debuggability of the underlying issue was highly limited by the CPU simply misbehaving at an architectural level. This blog article highlights some technical details of a CPU bug we observed on a specific Intel Atom CPU.
0 kommentar(er)
