Re: [gentoo-user] Microcode update AMD
On Saturday 05 February 2011 15:28:22 Enrico Weigelt wrote: * Volker Armin Hemmann volkerar...@googlemail.com wrote: and that is all the intel stuff. For AMD all you have to do is: modprobe -r microcode modprobe microcode Is the microcode permanently flashed or loaded into some internal RAM ? loaded. microcode is never permanently changed on x86 derivates.
Re: [gentoo-user] Microcode update AMD
* Volker Armin Hemmann volkerar...@googlemail.com wrote: the CPU. All CPUs use microcode. For decades. Google, or go straight to wikipedia. http://en.wikipedia.org/wiki/Microcode Borroughs' large systems (b6500+) were designed as microcode machines from ground up, which essentially interpreted an algol bytecode (the whole OS was directly implemented in assembler, w/o any machine specific assembler code). Paired w/ their entirely stack-based architecture (there were no program-visible registers) they could easily do massive-multiprocessing (everything's reentrant by design), 24/7 uptime even w/ hw replacements/upgrades and cpu improvements w/o ever having to recompile. Their successors (now Unisys) are called emode machines - quite the same approach as nowadays w/ Java (interpreter/JIT). BTW: I'm currently designing an emode/microcode-base computer architecture built on an matrix of nanocores, they don't have a concept of main memory, instead a relatively large (linear addressable) register memory, part of the register space is shared with neighbours (multiport-RAMs). These are programmed by an horizontal microcode, which is decoded by an static demux, that directly connects registers to an micro-ALU (so there're no additional load+store cycles) ... cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-user] Microcode update AMD
* Volker Armin Hemmann volkerar...@googlemail.com wrote: and that is all the intel stuff. For AMD all you have to do is: modprobe -r microcode modprobe microcode Is the microcode permanently flashed or loaded into some internal RAM ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-user] Microcode update AMD
Enrico Weigelt weig...@metux.de [11-02-05 16:08]: * Volker Armin Hemmann volkerar...@googlemail.com wrote: and that is all the intel stuff. For AMD all you have to do is: modprobe -r microcode modprobe microcode Is the microcode permanently flashed or loaded into some internal RAM ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- You need a kernel module to load the microcode into the CPU (I dont know for sure what kind of memory holds it then) eacht time you boot the machine. Best regards mcc
Re: [gentoo-user] Microcode update AMD
On Saturday 05 February 2011 15:28:22 Enrico Weigelt wrote: * Volker Armin Hemmann volkerar...@googlemail.com wrote: and that is all the intel stuff. For AMD all you have to do is: modprobe -r microcode modprobe microcode Is the microcode permanently flashed or loaded into some internal RAM ? loaded. microcode is never permanently changed on x86 derivates.
Re: [gentoo-user] Microcode update AMD
Am 05.02.2011 14:34, schrieb Enrico Weigelt: BTW: I'm currently designing an emode/microcode-base computer architecture built on an matrix of nanocores, they don't have a concept of main memory, instead a relatively large (linear addressable) register memory, part of the register space is shared with neighbours (multiport-RAMs). These are programmed by an horizontal microcode, which is decoded by an static demux, that directly connects registers to an micro-ALU (so there're no additional load+store cycles) ... cu Interesting. Is there a paper on this? What's its intended purpose? Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Microcode update AMD
btw, very related: http://blog.flameeyes.eu/2011/01/17/microupdates-for-microcodes
Re: [gentoo-user] Microcode update AMD
On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy bi...@iinet.net.au wrote: The bios microcode update is likely an enable setting rather than the bios actually updating the cpu. You need to do some reading/asking of the manufacturers (not here) if it bothers you. Thanks for the links, I didn't realize they made the microcode data available separately. From Intel's download site for the microcode data: The microcode data file contains the latest microcode definitions for all Intel processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates. While the regular approach to getting this microcode update is via a BIOS upgrade, Intel realizes that this can be an administrative hassle. The Linux Operating System and VMware ESX products have a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system.
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy bi...@iinet.net.au wrote: The bios microcode update is likely an enable setting rather than the bios actually updating the cpu. You need to do some reading/asking of the manufacturers (not here) if it bothers you. Thanks for the links, I didn't realize they made the microcode data available separately. From Intel's download site for the microcode data: The microcode data file contains the latest microcode definitions for all Intel processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates. While the regular approach to getting this microcode update is via a BIOS upgrade, Intel realizes that this can be an administrative hassle. The Linux Operating System and VMware ESX products have a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system. Thanks for the info Paul. For kicks I tried it on an Intel DH55HC MB running an Core i5-661. 1) Created /etc/firmware 2) Downloaded the Intel microcode-20101123.tgz file 3) Enabled the /dev/cpu/microcode option under Processor Types and Features 4) Rebuilt the kernel and rebooted I see this in dmesg: mark@firefly ~ $ dmesg | grep micro [0.495337] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9 [0.495436] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9 [0.495535] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9 [0.495635] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9 [0.495751] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba mark@firefly ~ $ On this machine the message doesn't change whether the microcode file is located in /etc/firmware or not so I don't know how to tell if the process worked but the processor doesn't need any updates or whether it didn't work at all. - Mark
Re: [gentoo-user] Microcode update AMD
btw, very related: http://blog.flameeyes.eu/2011/01/17/microupdates-for-microcodes
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 8:16 AM, Mark Knecht markkne...@gmail.com wrote: On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy bi...@iinet.net.au wrote: The bios microcode update is likely an enable setting rather than the bios actually updating the cpu. You need to do some reading/asking of the manufacturers (not here) if it bothers you. Thanks for the links, I didn't realize they made the microcode data available separately. From Intel's download site for the microcode data: The microcode data file contains the latest microcode definitions for all Intel processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates. While the regular approach to getting this microcode update is via a BIOS upgrade, Intel realizes that this can be an administrative hassle. The Linux Operating System and VMware ESX products have a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system. Thanks for the info Paul. For kicks I tried it on an Intel DH55HC MB running an Core i5-661. 1) Created /etc/firmware 2) Downloaded the Intel microcode-20101123.tgz file 3) Enabled the /dev/cpu/microcode option under Processor Types and Features 4) Rebuilt the kernel and rebooted I see this in dmesg: mark@firefly ~ $ dmesg | grep micro [ 0.495337] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9 [ 0.495436] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9 [ 0.495535] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9 [ 0.495635] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9 [ 0.495751] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba mark@firefly ~ $ On this machine the message doesn't change whether the microcode file is located in /etc/firmware or not so I don't know how to tell if the process worked but the processor doesn't need any updates or whether it didn't work at all. - Mark OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. Add microcode_ctl to the boot level: rc-update add microcode_ctl boot 2) Unzip and untar the microcode file from Intel. 3) The above emerge placed the microcode.dat file in /lib/firmware, not /etc/firmware as suggested by the kernel, so I loaded the newer one from Intel by hand using microcode-ctl: firefly firmware # microcode_ctl -f /etc/firmware/microcode-20101123.dat microcode_ctl: writing microcode (length: 430080) microcode_ctl: microcode successfuly written to /dev/cpu/microcode firefly firmware # dmesg | grep micro [0.495755] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9 [0.495853] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9 [0.495952] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9 [0.496050] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9 [0.496168] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba [ 2647.731262] microcode: CPU0 updated to revision 0xc, date = 2010-06-10 [ 2647.731982] microcode: CPU1 updated to revision 0xc, date = 2010-06-10 [ 2647.732815] microcode: CPU2 updated to revision 0xc, date = 2010-06-10 [ 2647.733608] microcode: CPU3 updated to revision 0xc, date = 2010-06-10 firefly firmware # Now the microcode revision appears to be updated. I suspected that if I renamed the file in /etc/firmware to 'microcode.dat' maybe it would load automatically at boot time but it didn't so I moved it to lib/firmware where microcode_ctl does load it. NOTE: There is a /etc/conf.d/microcode_ctl config file but it doesn't see to include a path for microcode so I guess at this time I'm stuck overwriting the /lib/firmware directory until I learn more. Cheers, Mark
Re: [gentoo-user] Microcode update AMD
On Tuesday 18 January 2011 09:34:14 Mark Knecht wrote: On Tue, Jan 18, 2011 at 8:16 AM, Mark Knecht markkne...@gmail.com wrote: On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy bi...@iinet.net.au wrote: The bios microcode update is likely an enable setting rather than the bios actually updating the cpu. You need to do some reading/asking of the manufacturers (not here) if it bothers you. Thanks for the links, I didn't realize they made the microcode data available separately. From Intel's download site for the microcode data: The microcode data file contains the latest microcode definitions for all Intel processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates. While the regular approach to getting this microcode update is via a BIOS upgrade, Intel realizes that this can be an administrative hassle. The Linux Operating System and VMware ESX products have a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system. Thanks for the info Paul. For kicks I tried it on an Intel DH55HC MB running an Core i5-661. 1) Created /etc/firmware 2) Downloaded the Intel microcode-20101123.tgz file 3) Enabled the /dev/cpu/microcode option under Processor Types and Features 4) Rebuilt the kernel and rebooted I see this in dmesg: mark@firefly ~ $ dmesg | grep micro [0.495337] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9 [0.495436] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9 [0.495535] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9 [0.495635] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9 [0.495751] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba mark@firefly ~ $ On this machine the message doesn't change whether the microcode file is located in /etc/firmware or not so I don't know how to tell if the process worked but the processor doesn't need any updates or whether it didn't work at all. - Mark OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. Add microcode_ctl to the boot level: rc-update add microcode_ctl boot 2) Unzip and untar the microcode file from Intel. 3) The above emerge placed the microcode.dat file in /lib/firmware, not /etc/firmware as suggested by the kernel, so I loaded the newer one from Intel by hand using microcode-ctl: firefly firmware # microcode_ctl -f /etc/firmware/microcode-20101123.dat microcode_ctl: writing microcode (length: 430080) microcode_ctl: microcode successfuly written to /dev/cpu/microcode firefly firmware # dmesg | grep micro [0.495755] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9 [0.495853] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9 [0.495952] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9 [0.496050] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9 [0.496168] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba [ 2647.731262] microcode: CPU0 updated to revision 0xc, date = 2010-06-10 [ 2647.731982] microcode: CPU1 updated to revision 0xc, date = 2010-06-10 [ 2647.732815] microcode: CPU2 updated to revision 0xc, date = 2010-06-10 [ 2647.733608] microcode: CPU3 updated to revision 0xc, date = 2010-06-10 firefly firmware # Now the microcode revision appears to be updated. I suspected that if I renamed the file in /etc/firmware to 'microcode.dat' maybe it would load automatically at boot time but it didn't so I moved it to lib/firmware where microcode_ctl does load it. NOTE: There is a /etc/conf.d/microcode_ctl config file but it doesn't see to include a path for microcode so I guess at this time I'm stuck overwriting the /lib/firmware directory until I learn more. Cheers, Mark and that is all the intel stuff. For AMD all you have to do is: modprobe -r microcode modprobe microcode
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com wrote: OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. The ebuild for newer versions (including the latest 20101123) is in portage as ~amd64 and ~x86.
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com wrote: OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. The ebuild for newer versions (including the latest 20101123) is in portage as ~amd64 and ~x86. Thanks Paul. Also, it does seem to work, for Intel anyway, as a module or built into the kernel. I chose to build it in as I'm tired of how long lsmod is looking these days. Cheers, Mark
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht markkne...@gmail.com wrote: On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com wrote: OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. The ebuild for newer versions (including the latest 20101123) is in portage as ~amd64 and ~x86. Thanks Paul. Also, it does seem to work, for Intel anyway, as a module or built into the kernel. I chose to build it in as I'm tired of how long lsmod is looking these days. If you use the /etc/init.d/microcode_ctl runscript and have MICROCODE_UNLOAD=yes set in /etc/conf.d/microcode_ctl (which is the default), it will unload the module automatically after it runs, so you shouldn't see it in lsmod anyway, and saves a few kb of memory. But, quite honestly, 8kb of memory is probably inconsequential on a system where microcode_ctl is being used in the first place... :)
Re: [gentoo-user] Microcode update AMD
On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote: On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht markkne...@gmail.com wrote: On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com wrote: OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. The ebuild for newer versions (including the latest 20101123) is in portage as ~amd64 and ~x86. Thanks Paul. Also, it does seem to work, for Intel anyway, as a module or built into the kernel. I chose to build it in as I'm tired of how long lsmod is looking these days. If you use the /etc/init.d/microcode_ctl runscript and have MICROCODE_UNLOAD=yes set in /etc/conf.d/microcode_ctl (which is the default), it will unload the module automatically after it runs, so you shouldn't see it in lsmod anyway, and saves a few kb of memory. But, quite honestly, 8kb of memory is probably inconsequential on a system where microcode_ctl is being used in the first place... :) Is the /etc/microcode.dat path a bug, now that firmware is typically placed in /lib/firmware? Shall I create a symlink or raise a bug report? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 2:56 PM, Mick michaelkintz...@gmail.com wrote:
On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote:
On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht markkne...@gmail.com wrote:
On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
paul.hartman+gen...@gmail.com wrote:
On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com
wrote:
OK, I got it to load by hand:
1) emerge microcode-ctl
which also emerges microcode-data. Unfortunately microcode-data looks
to be out of date.
The ebuild for newer versions (including the latest 20101123) is in
portage as ~amd64 and ~x86.
Thanks Paul.
Also, it does seem to work, for Intel anyway, as a module or built
into the kernel. I chose to build it in as I'm tired of how long lsmod
is looking these days.
If you use the /etc/init.d/microcode_ctl runscript and have
MICROCODE_UNLOAD=yes set in /etc/conf.d/microcode_ctl (which is the
default), it will unload the module automatically after it runs, so
you shouldn't see it in lsmod anyway, and saves a few kb of memory.
But, quite honestly, 8kb of memory is probably inconsequential on a
system where microcode_ctl is being used in the first place... :)
Is the /etc/microcode.dat path a bug, now that firmware is typically placed in
/lib/firmware?
Shall I create a symlink or raise a bug report?
On my ~amd64 system, using microcode-ctl-1.17-r2 and
microcode-data-20101123 the data is installed to /lib/firmware and the
runscript does:
microcode_ctl -qu -f /lib/firmware/microcode.dat -d ${MICROCODE_DEV}
I think the gentoo packages are designed for you to use the installed
runscript which works when you use the microcode-data package from
portage since they both use the /lib/firmware location.
Based on this I would guess that it is not a bug, but that it is the
intended behavior.
Re: [gentoo-user] Microcode update AMD
On Tuesday 18 January 2011 21:13:49 Paul Hartman wrote:
On Tue, Jan 18, 2011 at 2:56 PM, Mick michaelkintz...@gmail.com wrote:
On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote:
On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht markkne...@gmail.com
wrote:
On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
paul.hartman+gen...@gmail.com wrote:
On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com
wrote:
OK, I got it to load by hand:
1) emerge microcode-ctl
which also emerges microcode-data. Unfortunately microcode-data
looks to be out of date.
The ebuild for newer versions (including the latest 20101123) is in
portage as ~amd64 and ~x86.
Thanks Paul.
Also, it does seem to work, for Intel anyway, as a module or built
into the kernel. I chose to build it in as I'm tired of how long lsmod
is looking these days.
If you use the /etc/init.d/microcode_ctl runscript and have
MICROCODE_UNLOAD=yes set in /etc/conf.d/microcode_ctl (which is the
default), it will unload the module automatically after it runs, so
you shouldn't see it in lsmod anyway, and saves a few kb of memory.
But, quite honestly, 8kb of memory is probably inconsequential on a
system where microcode_ctl is being used in the first place... :)
Is the /etc/microcode.dat path a bug, now that firmware is typically
placed in /lib/firmware?
Shall I create a symlink or raise a bug report?
On my ~amd64 system, using microcode-ctl-1.17-r2 and
microcode-data-20101123 the data is installed to /lib/firmware and the
runscript does:
microcode_ctl -qu -f /lib/firmware/microcode.dat -d ${MICROCODE_DEV}
I think the gentoo packages are designed for you to use the installed
runscript which works when you use the microcode-data package from
portage since they both use the /lib/firmware location.
Based on this I would guess that it is not a bug, but that it is the
intended behavior.
Yes Paul, you're right. In the days before /lib/firmware was made available I
recall that /etc/microcode.dat was the default location of the code. Now that
I just ran it by hand once, it complained that /etc/microcode.dat doesn't
exist.
However, following your prompt I looked at the /etc/init.d/microcode-ctl
script and it all makes sense.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 12:56 PM, Mick michaelkintz...@gmail.com wrote: SNIP Is the /etc/microcode.dat path a bug, now that firmware is typically placed in /lib/firmware? Shall I create a symlink or raise a bug report? -- Regards, Mick Mick, I don't think so. Seems to me Gentoo can put this where ever it wants as long as it matches the init script. - Mark
Re: [gentoo-user] Microcode update AMD
- Original Message I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module microcode ? (AMD Phenom X6 1090T) Not sure about BIOS, but the Linux Kernel you are running will certainly need support enabled too. 2) Does anyone know, what these microcodes do? They are fixes for... ...what? The Intel and AMD processors are more abstract than physical now. With i486 and earlier the processors were typically hard wired; hardware bug fixes could not be pushed out. Intel's Pentium (and I don't know which AMD) started using micro-code to program the processor. This enabled them to push out hardware bug fixes for the processors. So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to micro-code first, then it gets processed, and the result translated back to the expected instruction result - essentially, emulating the x86 instruction set in the processor. That's the simple version. So now when they discover a bug in the hardware they can push out a micro-code update to either fix the hardware (microcode) bug or work around a hardware (physical hardware) bug. Ben
Re: [gentoo-user] Microcode update AMD
BRM bm_witn...@yahoo.com [11-01-17 19:16]: - Original Message I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module microcode ? (AMD Phenom X6 1090T) Not sure about BIOS, but the Linux Kernel you are running will certainly need support enabled too. 2) Does anyone know, what these microcodes do? They are fixes for... ...what? The Intel and AMD processors are more abstract than physical now. With i486 and earlier the processors were typically hard wired; hardware bug fixes could not be pushed out. Intel's Pentium (and I don't know which AMD) started using micro-code to program the processor. This enabled them to push out hardware bug fixes for the processors. So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to micro-code first, then it gets processed, and the result translated back to the expected instruction result - essentially, emulating the x86 instruction set in the processor. That's the simple version. So now when they discover a bug in the hardware they can push out a micro-code update to either fix the hardware (microcode) bug or work around a hardware (physical hardware) bug. Ben Hi Ben, thanks for your explanation... I meant: What is fixed the uc-patches? Does mov only except 17 as argument...or... I searched AMD for a changelog or something like but I ound nothing... Best regards, mcc
Re: [gentoo-user] Microcode update AMD
On Mon, Jan 17, 2011 at 10:10 AM, BRM bm_witn...@yahoo.com wrote: - Original Message I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module microcode ? (AMD Phenom X6 1090T) Not sure about BIOS, but the Linux Kernel you are running will certainly need support enabled too. 2) Does anyone know, what these microcodes do? They are fixes for... ...what? The Intel and AMD processors are more abstract than physical now. With i486 and earlier the processors were typically hard wired; hardware bug fixes could not be pushed out. Intel's Pentium (and I don't know which AMD) started using micro-code to program the processor. This enabled them to push out hardware bug fixes for the processors. So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to micro-code first, then it gets processed, and the result translated back to the expected instruction result - essentially, emulating the x86 instruction set in the processor. That's the simple version. So now when they discover a bug in the hardware they can push out a micro-code update to either fix the hardware (microcode) bug or work around a hardware (physical hardware) bug. Ben Ben, Do you know how security on these updates is handled? Seems to me this is an area rife for exploitation so I've been very hesitant to use them until I understood more. Cheers, Mark
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: Hi, I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module microcode ? (AMD Phenom X6 1090T) you ALWAYS have to activate that! This way the bios updates the microcode with the latest version it is carrying around. Not activating that option is really, really stupid. For many reasons. It is also (almost) completely unrelated to that blob. That blob is for the OS so you can upload an even more recent version of microcode. In case your bios sucks. For example. 2) Does anyone know, what these microcodes do? They are fixes for... ...what? the CPU. All CPUs use microcode. For decades. Google, or go straight to wikipedia. http://en.wikipedia.org/wiki/Microcode
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 10:48:36 Mark Knecht wrote: On Mon, Jan 17, 2011 at 10:10 AM, BRM bm_witn...@yahoo.com wrote: - Original Message I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module microcode ? (AMD Phenom X6 1090T) Not sure about BIOS, but the Linux Kernel you are running will certainly need support enabled too. 2) Does anyone know, what these microcodes do? They are fixes for... ...what? The Intel and AMD processors are more abstract than physical now. With i486 and earlier the processors were typically hard wired; hardware bug fixes could not be pushed out. Intel's Pentium (and I don't know which AMD) started using micro-code to program the processor. This enabled them to push out hardware bug fixes for the processors. So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to micro-code first, then it gets processed, and the result translated back to the expected instruction result - essentially, emulating the x86 instruction set in the processor. That's the simple version. So now when they discover a bug in the hardware they can push out a micro-code update to either fix the hardware (microcode) bug or work around a hardware (physical hardware) bug. Ben Ben, Do you know how security on these updates is handled? Seems to me this is an area rife for exploitation so I've been very hesitant to use them until I understood more. you can not not use them because alsmost all bios load the microcode automatically.
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 19:34:08 meino.cra...@gmx.de wrote: BRM bm_witn...@yahoo.com [11-01-17 19:16]: - Original Message I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module microcode ? (AMD Phenom X6 1090T) Not sure about BIOS, but the Linux Kernel you are running will certainly need support enabled too. 2) Does anyone know, what these microcodes do? They are fixes for... ...what? The Intel and AMD processors are more abstract than physical now. With i486 and earlier the processors were typically hard wired; hardware bug fixes could not be pushed out. even the 68000 used microcode... Intel's Pentium (and I don't know which AMD) started using micro-code to program the processor. This enabled them to push out hardware bug fixes for the processors sure that microcode was not introduced to x86 a lot earlier? So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to micro-code first, then it gets processed, and the result translated back to the expected instruction result - essentially, emulating the x86 instruction set in the processor. That's the simple version. So now when they discover a bug in the hardware they can push out a micro-code update to either fix the hardware (microcode) bug or work around a hardware (physical hardware) bug. Ben Hi Ben, thanks for your explanation... I meant: What is fixed the uc-patches? Does mov only except 17 as argument...or... I searched AMD for a changelog or something like but I ound nothing... they never publish changelogs for microcode.
Re: [gentoo-user] Microcode update AMD
Volker Armin Hemmann volkerar...@googlemail.com [11-01-17 20:16]: On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: Hi, I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module microcode ? (AMD Phenom X6 1090T) you ALWAYS have to activate that! This way the bios updates the microcode with the latest version it is carrying around. Not activating that option is really, really stupid. For many reasons. It is also (almost) completely unrelated to that blob. That blob is for the OS so you can upload an even more recent version of microcode. In case your bios sucks. For example. 2) Does anyone know, what these microcodes do? They are fixes for... ...what? the CPU. All CPUs use microcode. For decades. Google, or go straight to wikipedia. http://en.wikipedia.org/wiki/Microcode Cool down. I know for waht microcodes are good for. My question means: What specific bugs/features of my CPU get fixed, when I use the microcde included in the recent microcode update???
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 20:19:04 meino.cra...@gmx.de wrote: Volker Armin Hemmann volkerar...@googlemail.com [11-01-17 20:16]: On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: Hi, I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module microcode ? (AMD Phenom X6 1090T) you ALWAYS have to activate that! This way the bios updates the microcode with the latest version it is carrying around. Not activating that option is really, really stupid. For many reasons. It is also (almost) completely unrelated to that blob. That blob is for the OS so you can upload an even more recent version of microcode. In case your bios sucks. For example. 2) Does anyone know, what these microcodes do? They are fixes for... ...what? the CPU. All CPUs use microcode. For decades. Google, or go straight to wikipedia. http://en.wikipedia.org/wiki/Microcode Cool down. I know for waht microcodes are good for. My question means: What specific bugs/features of my CPU get fixed, when I use the microcde included in the recent microcode update??? nobody knows.
Re: [gentoo-user] Microcode update AMD
Volker Armin Hemmann volkerar...@googlemail.com [11-01-17 20:52]: On Monday 17 January 2011 20:19:04 meino.cra...@gmx.de wrote: Volker Armin Hemmann volkerar...@googlemail.com [11-01-17 20:16]: On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: Hi, I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module microcode ? (AMD Phenom X6 1090T) you ALWAYS have to activate that! This way the bios updates the microcode with the latest version it is carrying around. Not activating that option is really, really stupid. For many reasons. It is also (almost) completely unrelated to that blob. That blob is for the OS so you can upload an even more recent version of microcode. In case your bios sucks. For example. 2) Does anyone know, what these microcodes do? They are fixes for... ...what? the CPU. All CPUs use microcode. For decades. Google, or go straight to wikipedia. http://en.wikipedia.org/wiki/Microcode Cool down. I know for waht microcodes are good for. My question means: What specific bugs/features of my CPU get fixed, when I use the microcde included in the recent microcode update??? nobody knows. So...why should I try unknown code patched into my CPU. It looks like install this virus from the security point of view, doesn't ist?
Re: [gentoo-user] Microcode update AMD
As he said in the previous message, there are almost never changelogs for microcode updates. I do, however, have to disagree with *never* disabling microcode updates. If I recall properly, the AMD Phenom II 720 was able to be unlocked to 4 cores via a misconfiguration that enabled it with ACC. AMD later corrected this issue with a microcode update. True, some motherboards worked around that fix a different way, but if you had a first gen board with ACC support you *had* to have the old microcode for it to work. The update killed your free core :) On Jan 17, 2011 3:06 PM, meino.cra...@gmx.de wrote: Volker Armin Hemmann volkerar...@googlemail.com [11-01-17 20:16]: On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: Hi, I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module microcode ? (AMD Phenom X6 1090T) you ALWAYS have to activate that! This way the bios updates the microcode with the latest version it is carrying around. Not activating that option is really, really stupid. For many reasons. It is also (almost) completely unrelated to that blob. That blob is for the OS so you can upload an even more recent version of microcode. In case your bios sucks. For example. 2) Does anyone know, what these microcodes do? They are fixes for... ...what? the CPU. All CPUs use microcode. For decades. Google, or go straight to wikipedia. http://en.wikipedia.org/wiki/Microcode Cool down. I know for waht microcodes are good for. My question means: What specific bugs/features of my CPU get fixed, when I use the microcde included in the recent microcode update???
Re: [gentoo-user] Microcode update AMD
On Mon, Jan 17, 2011 at 11:57 AM, meino.cra...@gmx.de wrote: SNIP So...why should I try unknown code patched into my CPU. It looks like install this virus from the security point of view, doesn't ist? That was my point. I think the idea Volker is suggesting is the micro-code updates go from AMD (who understands what the issue is with their processor) to the BIOS manufacturer (Phoenix or whoever did yous) and get incorporated in a secure way. They are 'known good' in the BIOS update we receive and write into a Flash drive. It's just a choice whether you want to use that part of BOIS or now. After all, _any_ BIOS update represents an opportunity for someone to really mess you machine up. Doesn't matter if it's micro-code or something else. That's my reading of this so far - Mark
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 15:13:54 Jason Weisberger wrote: As he said in the previous message, there are almost never changelogs for microcode updates. I do, however, have to disagree with *never* disabling microcode updates. If I recall properly, the AMD Phenom II 720 was able to be unlocked to 4 cores via a misconfiguration that enabled it with ACC. AMD later corrected this issue with a microcode update. True, some motherboards worked around that fix a different way, but if you had a first gen board with ACC support you *had* to have the old microcode for it to work. The update killed your free core :) a 'free core' that is probably broken in mysterious and hard to find but nonetheless very dangerous ways. Thanks.
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 12:12:08 Mark Knecht wrote: On Mon, Jan 17, 2011 at 11:57 AM, meino.cra...@gmx.de wrote: SNIP So...why should I try unknown code patched into my CPU. It looks like install this virus from the security point of view, doesn't ist? That was my point. I think the idea Volker is suggesting is the micro-code updates go from AMD (who understands what the issue is with their processor) to the BIOS manufacturer (Phoenix or whoever did yous) and get incorporated in a secure way. They are 'known good' in the BIOS update we receive and write into a Flash drive. It's just a choice whether you want to use that part of BOIS or now. After all, _any_ BIOS update represents an opportunity for someone to really mess you machine up. Doesn't matter if it's micro-code or something else. That's my reading of this so far - Mark also the microcode you download is from amd's servers. If you don't that stuff - you can't use CPUs because they might be loaded with 'hacked' microcode from the start. Or motherboards, because the bios might be hacked. Or the linux kernel because maybe somebody incorporated code into linux. gcc and binutils that looks innocent but combined will kill your machine. On the other hand, CPU bugs can result in miscalculations. Very, very expensive miscalculations. So what is worse - an instable, incorrect CPU or paranoia?
Re: [gentoo-user] Microcode update AMD
The word probably implies that you have no idea what the statistics were on getting a perfectly good core were or why they disabled entire batches of cores based on an error from one. You are just overdriving your point. If he doesn't want to enable updation of microcode, it won't hurt anything. If it was functioning fine before, it will also be fine without an update. There is nothing wrong with keeping the version of code that is stable for you. It isn't stupid, its a good rule of thumb. If it isn't broken, don't fix it. On Jan 17, 2011 4:15 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: On Monday 17 January 2011 15:13:54 Jason Weisberger wrote: As he said in the previous message, there are almost never changelogs for microcode updates. I do, however, have to disagree with *never* disabling microcode updates. If I recall properly, the AMD Phenom II 720 was able to be unlocked to 4 cores via a misconfiguration that enabled it with ACC. AMD later corrected this issue with a microcode update. True, some motherboards worked around that fix a different way, but if you had a first gen board with ACC support you *had* to have the old microcode for it to work. The update killed your free core :) a 'free core' that is probably broken in mysterious and hard to find but nonetheless very dangerous ways. Thanks.
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 16:59:26 Jason Weisberger wrote: The word probably implies that you have no idea what the statistics were on getting a perfectly good core were or why they disabled entire batches of cores based on an error from one. You are just overdriving your point. If he doesn't want to enable updation of microcode, it won't hurt anything. If it was functioning fine before, it will also be fine without an update. There is nothing wrong with keeping the version of code that is stable for you. It isn't stupid, its a good rule of thumb. If it isn't broken, don't fix it. the problem is: how do you know it is stable? Just might be lucky that fixed function was not hit by you so far. But will that be true tomorrow? Next week? With the next gcc version? Microcode updates are there for a reason. There are ZILCH reasons to turn it off in the bios. 'Oh, there are a lots of fine 4cores marketed as 3cores. I want that' is not a reason not to turn it on. It is a reason to buy a mobo who can unlock those cores without turning off microcode updates. Call me old fashioned, but I prefer computers as deterministic machines - and not very expensive random number generators (which is also the main reason why I don't overclock. 5% faster for 1% better chance of errors? 5% I will never ever able to 'feel'? No thank you).
Re: [gentoo-user] Microcode update AMD
On Mon, 2011-01-17 at 20:46 +0100, Volker Armin Hemmann wrote: On Monday 17 January 2011 20:19:04 meino.cra...@gmx.de wrote: Volker Armin Hemmann volkerar...@googlemail.com [11-01-17 20:16]: On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: Hi, I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module microcode ? (AMD Phenom X6 1090T) nobody knows. Not amd, but follow the links for some explanation. * sys-apps/microcode-ctl Latest version available: 1.17-r2 Latest version installed: [ Not Installed ] Size of downloaded files: 319 kB Homepage:http://www.urbanmyth.org/microcode Description: Intel processor microcode update utility License: GPL-2 * sys-apps/microcode-data Latest version available: 20100209 Latest version installed: [ Not Installed ] Size of downloaded files: 549 kB Homepage:http://urbanmyth.org/microcode/ Description: Intel IA32 microcode update data License: as-is I manually grabbed a later data set from Intel when the kernel would throw a message about needing a microcode update on my Intel Atom. There are a couple of kernel options that need setting as well as the above packages - loading is via an /etc/init.d/ script. There was a changelog there as well - AMD should be similar. Also, you could ask AMD what the update fixes? The bios microcode update is likely an enable setting rather than the bios actually updating the cpu. You need to do some reading/asking of the manufacturers (not here) if it bothers you. BillK -- William Kenworthy bi...@iinet.net.au Home in Perth!
