Re: [PATCH] platform/x86: handle Intel CPUs falsely reporting as GenuineIotel

[Christian Ludloff]

On Sat, Jul 4, 2026 at 8:20 PM Evalyn Goemer <git@xxxxxxxxxxxxxxxx> wrote:
> > Beyond that one, there are those sole SNB and IVB reports... but
> > those lack details... and the same single bit flip on 3 uarch gens...
> > is rather unusual... and I've seen quite a few things in my x86 life.
>
> I did end up looking through the site you found the partial reports on and
> found 5 other reports that have a bunch of haswell chips reporting this.
>
> https://valid.x86.fr/i75p6c
> https://valid.x86.fr/gq5kl4
> https://valid.x86.fr/84i82r
> https://valid.x86.fr/fqwjgq
> https://valid.x86.fr/vh4mjs
>
> As well as probably one of the stranger sources of this being a random post on
> a Chinese message board where when expanding the full question it shows a
> "GenuineIotel" on their hardware listing. While it could be a typo it also
> happens to be a haswell series xeon which matches up exactly with other
> reports.
>
> https://web.archive.org/web/20260704102753/https://zhidao.baidu.com/question/373506097973561924.html

Thanks for digging these up.

Alas, no PPINs back then...

> > Overall, it's an outlier, and I'd flag such systems, not placate them.
>
> Yeah it's a very strange thing I have found and thought could be worth
> handling. I ended up making the patch this way since this is the only case of
> this I could see as well other codebases online handled it similarly. The
> other reason I did it this way was to keep it simpler since it used existing
> mechanisms and not need something much bigger if it wasn't needed.
>
> What do you think is a better way of handling these kinds of quirks? Maybe a
> quirks table of known bugged vendor strings that resolve to the correct vendor
> and print a log noting that its specifically bugged and assuming the proper one
> versus it just saying it's fully unknown and not detecting proper.
>
> I would be glad to make a proper v2 patch that did proper handling of this if
> you have suggestions on how that should be done.

I'd flag the machines as broken.

And then root-cause bad CPU, bad RAM, bad what-not, from there.

> > Fwiw, I also question the existence of "AMDisbetter!", reported for
> > early AMD K5 samples – I have FMS=500h parts, and they report
> > the "AuthenticAMD" string, as expected. If anyone got proof to the
> > contrary, let's see it please.  :-)
>
> There are a lot of things reportedly found in CPUID that could have not been
> real or just have been something else including things like the "AMD prank
> leaf" being at "0x8FFF_FFFF" according to sandpile.org which has a similar
> issue of not many sources elsewhere.

I can assure you that the prank leaves listed there are real.  :)

> It would be nice to be able to find more of these CPUs to test them across a
> wide set of boards to see what triggers these and if they can even be
> reproduced at all. Maybe even better find out how these started out being
> spread online.

The "AMDisbetter!" claims all seem to trace back here:

https://web.archive.org/web/19970524043213/http://grafi.ii.pw.edu.pl/gbm/x86/cpuid.html

My K5 FMS=500h, plus the verbiage used there, makes me say "it's a myth".

--
C.