Also, the new microcode that is uploaded to the CPU, doesn't get "saved", that's why you have to add microcode_ctl as a service, so it can upload the microcode to the CPU every boot.
To confirm that everything went fine after run the init script run this command:

Code:

dmesg | tail

If you have something like this in the result everything is fine and you have the new microcode running:

Code:

microcode: CPU0 updated from revision 0x17 to 0x18, date = 10172004

... and I got this on my pentium-m 1200mhz :

Code:

microcode: CPU0 updated from revision 0x5 to 0x7, date = 11092004

Post yours, if you would... I'm idly curious._________________"Mr Thomas Edison has been up on the two previous nights discovering 'a bug' in his phonograph." --Pall Mall Gazette (1889)
Are we THERE yet?

so from the mini-howto I've read that microcode is something like a firmware for the CPU...though there isn't any changelog so we have to use it on our own risk...did you notice any improvement with your CPU?? could you share with us your observations overall if any?? thanks in advance...

Hmm, everything works fine so far... I don't notice any difference...
Well, at leasts, it's kind of cool, to update the microcode of your own cpu... Yeah, ok, to be honest, I think this was a waste of time, the only thing i learnd here, is what a microcode is and what it is for.

Here's the line from an article written for linux-mag.com by one of the authors of the driver:

Quote:

The Linux Microcode Update Driver
Gearheads

Written by Tigran Aivazian
Thursday, 15 February 2001

Some of the recent Intel microprocessors have the capability of correcting specific hardware bugs by loading a sequence of bits called a "microcode update" into the CPU. This feature is available on all processors in the Intel P6 family, including Pentium Pro, Celeron, Pentium II, Pentium III, Pentium II Xeon, Pentium III Xeon, and the newly released Pentium 4. This feature is applicable to both single-processor and multi-processor (SMP) systems.

The loading of a microcode update is usually delegated to the BIOS but can also be performed by the operating system without needing to run in a special mode or reboot after the update is done. It is also possible (and quite common) to have the BIOS apply a microcode update to some revision level and later have the OS upgrade it to a newer revision.

The support for microcode update for the P6 family processors was added to the Linux kernel in February 2000 as of version 2.3.46. Support for the Pentium 4 microcode updates was added to Linux 2.4.0-test12 in December of the same year.

Presumably there is something in the official Intel literature as well, since it is referenced at the end of the article. Browsing around the Intel website turns up Intel® Pentium® 4 Processor Technical Documents. If you look at the "Specification Update" document, it has a whole table of things that "don't work as expected"; some software, some hardware. Some are 'fixed' others will never be fixed, presumably because they don't expect it to cause problems. Most of the 'bugs' are way out on the fringes where most code will never go.

To me it looks like these 'microcode updates' are not performance related but rather fixes for weird bugs. And I suspect that the microcode update files get bigger mostly because Intel brings out new processors. Notice that the update is a 'one-size-fits-all' sort of thing; Pentium Pro right up to P4! So installing it may not make your machine or code run faster, just more reliably!

But does anyone remember how slow Intel was to admit that there was a problem with the math in some versions of the Pentium Pro? (Thats the fdiv_bug referenced in code in some of the previous posts)

Microcode is something that is generally used in CISC designes to tell a processor exactly how to execute an instruction, which may or may not take more than one clock cycle to achieve the desired results. For example the complexity of a multiplication instruction is controlled by the microcode which controls the ALU (arithmatic logic unit). In a way the microcode behaves like the code you might use to control a FPGA (field programmable gate array) in order to get the gates (logical building blocks) to work in a certain way to achieve a desired result.

RISC systems, on the other hand, seek to improve performance by reducing the number of clock cycles required to perform tasks. They have small sets of simplified instructions, doing away with microcode altogether in most cases. While this means that tasks require more instructions, instructions are all of the same length and usually require only one clock cycle to complete. Because of this, RISC systems are capable of processing instructions in parallel in a process called pipelining. The CPU works on more than one instruction at once by starting the second instruction before it completes the first one. This greatly increases throughput and makes RISC systems substantially faster than their CISC counterparts.

Anyways this is by no means the end all and be all of microcode, but perhaps it might shine a light on the subject.

consider this a calculated but totally unproved guess: Would Apple's switch to Intel processors have anything to do with it?

nyet, zero, zilch, nada, wouldn't make any sense whatsoever_________________"Mr Thomas Edison has been up on the two previous nights discovering 'a bug' in his phonograph." --Pall Mall Gazette (1889)
Are we THERE yet?