Slashdot Mirror

You do realize that ever since the Intel Pentium FDIV fiasco that their processors allow you to patch the microcode, right? It would be silly to think that you couldn't do the same with an ARM chip, especially when it's tracking a moving target like the CLR.

The microcode needs to be updated every boot. It's volatile and resets when you turn off the system. See http://urbanmyth.org/microcode/

As far as I know, all OSes do this.

b) If you're running a Red Hat-derived distro, watch out for updates to the kernel-utils package, which provides microcode_ctl and /etc/firmware/microcode.dat. It might also be worth checking Tigran's site a bit more regularly. I note that his page includes a microcode.dat which is about 7 months newer than that currently provided by CentOS 4.5's kernel-utils package.

No update yet, but no doubt there will be shortly.

http://www.urbanmyth.org/microcode/

Well, Intel does release these every so often -- the fact that Intel released updated microcode is hardly news. How these patches work is that Intel releases the Microcode. OS suppliers then take that Microcode and incorporate it into their OS's microcode update facility -- it's already released for Linux for crying out loud! The odds are that Apple have included this Microcode update, it's just been rolled into one of the other updates that nobody's noticed yet.

These updates can also be loaded into your BIOS too so they're loaded prior to OS startup; it's just that it's usually a lot easier to update OS installations than reflashing lots of different BIOS variants. However, I suspect this is exactly what Apple have done -- they've incorporated this microcode update into their EFI updates and/or will include this version in the next round of updates.

About the only surprising thing is that Micosoft have actually wrapped it up and released it. Usually they don't bother unless they've actually had issues that are fixed by microcode updates.

they can have their microcode updated, but only with a dedicated bridged-bus eeprom burner ($15,000 or so).

Two months ago, Intel introduced microcode updates for all systems with an Intel® Core(TM) 2 Duo processor. According to an HP Tech Support Document:

While the implications of the issue are difficult to quantify, any of the following symptoms can occur:

* The system may stop responding to keyboard or mouse input.
* A system operating in a Microsoft Windows environment may generate a blue screen.
* A system operating in a Linux environment may generate a kernel panic.

This was the first I had heard of this; probably a good time to check for BIOS or microcode updates."

The HP link also indicates the nature of the problem, which should not be OS specific:

This Intel microcode update addresses an improper Translation Lookaside Buffer (TLB) invalidation that may result in unpredictable system behavior such as system hangs or incorrect data.

> Simply because microcode emulation isn't what they're talking
> about, and you damn well know it.

So when they say emulation, they're talking about software emulation of x86 and not about software emulation of x86?

> Microcode is not dependent on operating systems or a
> software virtual machine running inside another operation system,
> nor does it ever come into play for end-user licensing. [...]
> You can't turn it off or upgrade it

No? Here's a clue.

"Intel's typical means to mask processor bugs is microcode."

That's true. Every Intel CPU since the Pentium Pro can update its microcode. Many times, BIOS will contain microcode updates from Intel. Linux also has a microcode update driver.

"I'm sure that by saying they won't fix some bugs, they're saying that they won't respin the silicon but rather mask the bug in some other way."

I'm not sure about that. "Will fix" seems to imply the errata could be fixed in silicon or microcode, while "Will not fix" means it won't get fixed at all.

I was about to mod you insightful, but then I realized what the grandparent was probably talking about... the microcode. The microcode is a lot more important for recreating details. Pentium processors have a limited ability to fix silicon bugs in software. The microcode is in volatile memory, so it must be loaded on every boot by either the OS or the BIOS. It's top-secret, but access to this lower-level info might let you write a custom instruction (or not, I don't know how much the mechanism can change the operation)

An example microcode fix is for "High Temperature and Low Supply Voltage Operation May Result in Incorrect Processor Operation"

You can actually edit the microcode of your Intel Pentium CPU

You do have CPU microcode updates from Intel, and corresponding Linux code to facilitate uploading the code to the CPU : Microcode.

This microcode is not easily hackable (at least I hope so), and most certainly is not open source.

Microcode, my friend, microcode. It isn't much on the radar these days, but it was a big deal back in the 'frame days. IO devices ran themselves, instead of the CPU coordinating them, and the microcode did the hard work. Intel uses the microcode functionality in it's i686-class processors for some of it's errata, but nobody seems to notice.

Umm, no it's not, dude. :) A lot of processors (including, quite possibly, the CPU you're using right now) allow microcode updates. See here for information about the Linux microcode update driver for IA32. Now, I'm not sure how much can be updated, but it's clearly not completely "burned in", which returns us to the question the grandparent poster originally posited.

RISC designs tend to be far more straightforward and simple. Many computer engineering students implement the MIPS architecture as an exercise.

yep. Been there, done that. Well, almost. Computer Architecture was probably my favourite class in Uni. We didn't implement it ourselves, but that was about 90% of the class lecture and notes. Starting with simple logic gates, we went through how to build registers, latches, ALU's, register files, all the way to pipelining. Fascinating stuff if you can stick through it all and have a great lecturer! It really gives you an appreciation of how the stuff works.

Besides, the much-vaunted new feature of the PPro was the CISC->RISC translator, and it shouldn't take much to rejig that to handle 16-bit mode more effectively if the market (asses that they are) demands it.

I didn't know that. All I knew was that Intel was betting on M$ migrating everyone over to 32-bit software by the time it was released to market. Considering their close deals in the past, I'm sure this was based on information that M$ had given them.

To end this post on a non-anti-MS note, the CISC-RISC converter is software upgradeable. Recent Linux kernels provide a /dev/microcode device so that you can feed it a file (presumably) supplied by Intel. See http://www.urbanmyth.org/microcode/ for more information.

I know for sure that 2.4.0-test9 supports these microcode updates at boottime (there's an option now in the kernel configuration to do stuff with this). The thing is, microcode updates are erased each time you reboot. See http://www.urbanmyth.org/microcode.html" (I think that's the URL).

Thought I would mention that, since last summer, you can update the microcode of your P6 family chip under Linux. The utility is here. It's been in since 2.4.0-test1-ac10 and there's a backported patch to 2.2.18pre3 as well.

There's some updated microcodes up there too. Unfortunately there is basically no information at all as to what the updates fix/update/change... any such information would be appreciated.

Tom blames the problem on the motherboard/BIOS, saying it has the wrong microcode. This page has a utility that allows Linux to update the CPU's microcode (it works using /dev/microcode in the newest 2.4 kernels, see CONFIG_MICROCODE). He should get some new microcode and use this utility to update it (he'd have to compile a 2.4 kernel on another machine of course). At least then you'd know if that's the problem.