HN Reader

The GenuineIotel thing fascinates me because I can't fully grasp how it could happen. I can imagine a physical defect causing a permanent wrong-bit in a specific piece of silicon, but it seems more widespread than that. Perhaps some kind of bug in the logic synthesis process?

I am reminded of the old AMD CPUs with "unlockable" extra cores, which would when unlocked change the model name to something unusual.

"GenuineIotel" is definitely odd, but difficult to research more about; I suspect these CPUs might actually end up being collector's items sometime in the future.

because inserting no-op instructions after them prevents the issue.

The early 386s were extremely buggy and needed the same workaround: https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11...

> the characters ’n’ and ‘o’ differ by only one bit; an unpredictable error that sets that bit could change GenuineIntel to GenuineIotel.

On a QWERTY keyboard, the O key is also next to the I key. It's also possible someone accidentally fat-fingered "GenuineIontel" , noticed something was off, and moved their cursor between the "o" and "n", and accidentally hit Delete instead of Backspace.

Maybe an unlikely set of circumstances, but I imagine a random bit flip caused at the hardware-level is rare since it might cause other problems, if something more important was bit-flipped.

My favourite one of this kind is the Rockchip RK808 RTC, where the engineers thought that November had 31 days, needing a Linux kernel patch to this day that translates between Gregorian and Rockchip calendars (which are gradually diverging over time).

Also one of my favourite kernel patch messages: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

>The workaround for this is to cripple the system

That is not the workaround in the documentation that was just linked.

  Workarounds:
  The solution to this problem is to put two instructions that do not require write back data after the mul instruction.

This seems reasonable for your compiler vendor to implement without getting rid of multiplication altogether.

I came across a CPU bug that prevented Linux from booting on 3rd gen i3/i5/i7 CPUs. Did a bunch of printf debugging until I was right before the freeze. Then found something relevant in the CPU errata. It could be "fixed" by passing in noapic. I had a decent writeup on the old CentOS forums, but they're gone, and I don't have a copy of my writeup anymore.

I had to deal with Intel Quark SoC X1000 on a Galileo board years ago, where the LOCK prefix instruction caused segfaults. Since the SoC is single threaded, the lock prefix could just be patched out from resulting binaries, before the compiler/build system was patched.

https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug

When you have a known hardware bug like needing a nop after every mul, compilers can do this. You don't need to turn off mul entirely.

> To me, this issue doesn’t seem as embarrassing as Intel’s wrong CPUIDs. Pipelined CPUs are hard to build

I disagree. Misspelling a name in the CPUID is kind of easy to do, somewhat awkward to test (in a non-tautological way), and pretty easy to work around.

Having `mul ...; lw ...;` fail show that they've done very little testing of the chip. Any basic randomised pipeline testing would hit that trivial case.

Essentially all CPUs are pipelined today. In-order pipelined CPU execution semantics are not particularly hard to test. Even some open source testing systems could detect this bug, e.g. TestRig or RISCV-DV.

Will someone register the Iotel trademark and sue Intel? That was the purpose of the Intel string in reverse!

Wasn't there also a Pentium division bug of some sort. I didn't pay much attention to microcomputers back then (being a mainframe programmer at the time), but I remember hearing about it from the mainstream news.

links to this entertainment: https://crackhead.technology/anjoy-ssc338q-libtools/

Writing software in embedded processor pipelines for bugs in the IT81202 CPU.

Microcode errata re-writes to GPR, compiling low level "mul," and "output," CPU RISC V to system archictecture.