[solved]Intel microcode necessary?

mcloaked · 2014-10-24 19:16:38

secretrice wrote:

@dice - please, hold your horses for a one more question :-) - about @dejavu post.
There are some dates: 2010-09-29 - which, I think, are in conflict with idea of new upgrade for intel CPU via intel-ucode package (older date), but other text indicates that microcode was upgraded correctly. What does it mean in this case? Is microcode upgraded succesfully or not?
Thank you in advance, and I'm sorry for refreshing solved subject.

The dates quoted for the revision when running dmesg|grep microcode, after the updated kernel and intel-ucode packages are installed and the system rebooted, are the Intel internal microcode update date for the particular CPU that you have. So different CPUs will have different dates in the output for that command for the latest Intel microcode. Some are still from May this year whilst others are from July this year and yet others are more recent still.

Last edited by mcloaked (2014-10-24 19:19:05)

mcloaked · 2014-10-24 19:22:23

forumache wrote:

Ha, ha, for someone who likes puzzles:
I have an Atom 330 processor (dual-core with hyperthreading), so it appears as 4 CPUs.
With the new intel-ucode.img in syslinux.cfg, this is what I get:
[    0.000000] CPU0 microcode updated early to revision 0x219, date = 2009-04-10
[    0.556420] microcode: CPU0 sig=0x106c2, pf=0x8, revision=0x219
[    0.556453] microcode: CPU1 sig=0x106c2, pf=0x8, revision=0x213
[    0.556481] microcode: CPU2 sig=0x106c2, pf=0x8, revision=0x219
[    0.556510] microcode: CPU3 sig=0x106c2, pf=0x8, revision=0x213
[    0.556808] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
So yeah, it applied the microcode (early) to just one core.
You can see above that CPU0 and CPU2 (same core) are 0x219, the other core (CPU1,CPU3) remained at 0x213.
Nice, isn't it?

What is the output of the command:

grep "processor\|core id" /proc/cpuinfo

?

That tells you the number of physical cores, and the number of hyperthreaded cores.

Then quote the full output of the command:

journalctl -b | grep microcode

when run as root (or was that the command that generated the list of microcode lines in your post?) - then it will be possible to see what is going on. However it does indeed seem from your output quoted already that something didn't work right! Also please confirm that you are using the stock arch kernel version 3.17.1-1-ARCH, and not an earlier kernel, as well as the current version of the intel-ucode package version intel-ucode 20140913-1 .

Last edited by mcloaked (2014-10-24 19:29:43)

forumache · 2014-10-24 19:59:05

@mcloacked, this is the output you requested. Previously I obtained the lines with dmesg|grep micro but it is the same.

[human@asrock ~]$ grep "processor\|core id" /proc/cpuinfo
processor	: 0
core id		: 0
processor	: 1
core id		: 1
processor	: 2
core id		: 0
processor	: 3
core id		: 1
[human@asrock ~]$ sudo journalctl -b | grep microcode
Oct 24 21:38:41 asrock kernel: CPU0 microcode updated early to revision 0x219, date = 2009-04-10
Oct 24 21:38:41 asrock kernel: microcode: CPU0 sig=0x106c2, pf=0x8, revision=0x219
Oct 24 21:38:41 asrock kernel: microcode: CPU1 sig=0x106c2, pf=0x8, revision=0x213
Oct 24 21:38:41 asrock kernel: microcode: CPU2 sig=0x106c2, pf=0x8, revision=0x219
Oct 24 21:38:41 asrock kernel: microcode: CPU3 sig=0x106c2, pf=0x8, revision=0x213
Oct 24 21:38:41 asrock kernel: microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[human@asrock ~]$ uname -a
Linux asrock 3.17.1-1-ARCH #1 SMP PREEMPT Wed Oct 15 15:36:07 CEST 2014 i686 GNU/Linux
[human@asrock ~]$ pacman -Q intel-ucode
intel-ucode 20140913-1

digitalone · 2014-10-24 20:01:39

Will this change be added in GRUB future upstream versions?
What should I modify in /etc/grub.d/10_linux to get it works while giving grub-mkconfig command?

stevenmw · 2014-10-24 20:14:51

I was going to post on https://bbs.archlinux.org/viewtopic.php?id=188859 but it was closed..

I really don't want to open a new thread..

I'm just straight up confused. I don't get it. I've read through the articles in the forums and I read the wiki a dozen times. I'm usign GRUB and the instrutions just aren't clear to me. I just don't know exactly what I literally need to do. I have an idea.. I mean go into my grub.cfg and make the first initrd the ucode one.. But I'm confused on exactly what to add .

The wiki says I can add

[...]
echo	'Loading initial ramdisk ...'
initrd	/intel-ucode.img /initramfs-linux.img
[...]

or I can add the following to my 10_linux file

   if test -n "${initrd}" ; then
+    if test -f "${dirname}/intel-ucode.img"; then
+        ucode="${rel_dirname}/intel-ucode.img "
+    else
+        ucode=
+    fi
     # TRANSLATORS: ramdisk isn't identifier. Should be translated.
     message="$(gettext_printf "Loading initial ramdisk ...")"
     sed "s/^/$submenu_indentation/" << EOF
 	echo	'$(echo "$message" | grub_quote)'
-	initrd	${rel_dirname}/${initrd}
+	initrd	${ucode}${rel_dirname}/${initrd}
 EOF

I tried the second method, but when running grub-mkconfig I get an error about line 137 have a problem the problem being the word 'then' in

+    if test -f "${dirname}/intel-ucode.img"; then

I'd like to do the first method, but I just can't follow it. I mean I understand that it needs to be the first initrd but what else do i need to add to it? I obviously cant just put

[...]
echo	'Loading initial ramdisk ...'
initrd	/intel-ucode.img /initramfs-linux.img
[...]

The wikie makes it sound like all you would need to do is copy and paste, but i know better.. I just don't know what exactly to add to the grub.cfg?

----------

And as a side question, is this a permanent thing? I mean will we always have to make these changes from now on? So whenever someone does a fresh install they will need to manually configure their bootloader for microcode?

Last edited by stevenmw (2014-10-24 20:24:55)

mcloaked · 2014-10-24 20:25:37

I think that the wiki implies that the lines marked with a "+" are added to the existing lines - so I guess you should not have the "+" in those lines? Can you quote what your file has for those lines in it after you made the changes?

Once the file is correct then it should not cause an error regenerating the grub config. Similarly for the first method did you just add the /intel-ucode.img to the initrd line just in front of the original initrd? The path will be relative to the path of the directory containing the original initrd file. So if your line has /initramfs-linux.img then the format quoted should work. I am presuming you made no other changes? It might be best to list the files so that people can see what is actually there to have a chance to know where the issue lies.

mcloaked · 2014-10-24 20:30:56

forumache wrote:

@mcloacked, this is the output you requested. Previously I obtained the lines with dmesg|grep micro but it is the same.

[human@asrock ~]$ grep "processor\|core id" /proc/cpuinfo
processor	: 0
core id		: 0
processor	: 1
core id		: 1
processor	: 2
core id		: 0
processor	: 3
core id		: 1
[human@asrock ~]$ sudo journalctl -b | grep microcode
Oct 24 21:38:41 asrock kernel: CPU0 microcode updated early to revision 0x219, date = 2009-04-10
Oct 24 21:38:41 asrock kernel: microcode: CPU0 sig=0x106c2, pf=0x8, revision=0x219
Oct 24 21:38:41 asrock kernel: microcode: CPU1 sig=0x106c2, pf=0x8, revision=0x213
Oct 24 21:38:41 asrock kernel: microcode: CPU2 sig=0x106c2, pf=0x8, revision=0x219
Oct 24 21:38:41 asrock kernel: microcode: CPU3 sig=0x106c2, pf=0x8, revision=0x213
Oct 24 21:38:41 asrock kernel: microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[human@asrock ~]$ uname -a
Linux asrock 3.17.1-1-ARCH #1 SMP PREEMPT Wed Oct 15 15:36:07 CEST 2014 i686 GNU/Linux
[human@asrock ~]$ pacman -Q intel-ucode
intel-ucode 20140913-1

Yes two physical cores should have two microcode revisions as you said. Also can you quote the output of "uname -r" and check that the kernel is fully up to date? If you are running version 3.17.1-1-ARCH then there is clearly a problem with the early microcode update and it needs more investigation. Presumably you already followed the advice to have the two initrd files as

Multiple initrd's can be separated by commas in the config file /boot/syslinux/syslinux.cfg.

paying attention to the path of each? I am not a syslinux expert so maybe someone more familiar with sysylinux could advise.

forumache · 2014-10-24 20:40:53

[human@asrock ~]$ uname -r
3.17.1-1-ARCH
[human@asrock ~]$ dmesg|grep initr
[    0.000000] Kernel command line: BOOT_IMAGE=../vmlinuz-linux root=/dev/sda1 rootflags=defaults,noatime,discard rw elevator=noop init=/usr/lib/systemd/systemd quiet initrd=../intel-ucode.img,../initramfs-linux.img

The syslinux.cfg is ok, otherwise the microcode would't have been loaded at all. I'll reboot. If the situations changes, I'll edit this post to say it was only a temporarily glitch.

stevenmw · 2014-10-24 20:53:31

mcloaked wrote:

I think that the wiki implies that the lines marked with a "+" are added to the existing lines - so I guess you should not have the "+" in those lines?

Pretty sure you're right. haha Thanks, but i'd still like to go with method 1.

mcloaked wrote:

Can you quote what your file has for those lines in it after you made the changes?

I just changed my 10_linux file, then i put it back to how it was. So right now, there are zero changes made, but I have installed the intel-ucode package.

Where exactly do I need to put

echo	'Loading initial ramdisk ...'
initrd	/intel-ucode.img /initramfs-linux.img

Last edited by stevenmw (2014-10-24 20:54:58)

mcloaked · 2014-10-24 21:16:47

stevenmw wrote:

mcloaked wrote:
I think that the wiki implies that the lines marked with a "+" are added to the existing lines - so I guess you should not have the "+" in those lines?
Pretty sure you're right. haha Thanks, but i'd still like to go with method 1.
mcloaked wrote:
Can you quote what your file has for those lines in it after you made the changes?
I just changed my 10_linux file, then i put it back to how it was. So right now, there are zero changes made, but I have installed the intel-ucode package.
Where exactly do I need to put
echo	'Loading initial ramdisk ...'
initrd	/intel-ucode.img /initramfs-linux.img

If you edit the file /boot/grub/grub.cfg (as root) and search for the word "initial" you should find lines such as:

        linux   /boot/vmlinuz-linux root=UUID=87d59fd7-646d-4604-a5a5-395d7e0495a7 rw  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initramfs-linux.img
}

Simply add in the microcode image as

        linux   /boot/vmlinuz-linux root=UUID=87d59fd7-646d-4604-a5a5-395d7e0495a7 rw  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /intel-ucode.img /boot/initramfs-linux.img
}

Save the file and reboot.... there will be multiple instances of similar lines - one for each type of boot such as graphical boot, multi-user, fallback etc and you will need to change each of them.

Last edited by mcloaked (2014-10-24 21:18:17)

forumache · 2014-10-24 21:25:51

mcloaked wrote:

If you edit the file /boot/grub/grub.cfg (as root) and search for the word "initial" you should find lines such as:
        linux   /boot/vmlinuz-linux root=UUID=87d59fd7-646d-4604-a5a5-395d7e0495a7 rw  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initramfs-linux.img
}
...
Save the file and reboot.... there will be multiple instances of similar lines - one for each type of boot such as graphical boot, multi-user, fallback etc and you will need to change each of them.

I think in GRUB2 the file you suggested to edit is generated and would be replaced by grub-mkconfig, thus all the changes will be lost.

mcloaked · 2014-10-24 21:27:30

forumache wrote:

mcloaked wrote:
If you edit the file /boot/grub/grub.cfg (as root) and search for the word "initial" you should find lines such as:
        linux   /boot/vmlinuz-linux root=UUID=87d59fd7-646d-4604-a5a5-395d7e0495a7 rw  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initramfs-linux.img
}
...
Save the file and reboot.... there will be multiple instances of similar lines - one for each type of boot such as graphical boot, multi-user, fallback etc and you will need to change each of them.
I think in GRUB2 the file you suggested to edit is generated and would be replaced by grub-mkconfig, thus all the changes will be lost.

True! But hopefully when the grub package is next updated by pacman hopefully it will have patches in to deal with the early microcode loading so that manual changes will not be needed then in the new config file?

stevenmw · 2014-10-24 21:42:27

@mcloaked Thank you so much for the clear answer! Worked perfectly. I ran dmesg | grep microcode before and after. Microcode showed up without errors!

forumache wrote:

I think in GRUB2 the file you suggested to edit is generated and would be replaced by grub-mkconfig, thus all the changes will be lost.

This is true, but I'd much rather go with this method because when an update comes along and they have it to where grub is configured automatically with a patch or whatever all I have to do is update. Plus if something else happens I can just run grub-mkconfig to revert.

mcloaked wrote:

True! But hopefully when the grub package is next updated by pacman hopefully it will have patches in to deal with the early microcode loading so that manual changes will not be needed then in the new config file?

I hope they make a post about this if it happens. This is exactly what I'm wondering is going to happe.

Last edited by stevenmw (2014-10-25 03:00:42)

orschiro · 2014-10-25 07:54:43

Does microcode support older Core2Duo processors?

Model name:            Intel(R) Core(TM)2 Duo CPU     L9400  @ 1.86GHz

I modified my GRUB entry according to the wiki but it does not update my firmware.

~ dmesg | grep microcode 
[    0.340061] microcode: CPU0 sig=0x10676, pf=0x80, revision=0x610
[    0.340070] microcode: CPU1 sig=0x10676, pf=0x80, revision=0x610
[    0.340128] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

jasonwryan · 2014-10-25 07:57:15

https://wiki.archlinux.org/index.php/Mi … Intel_CPUs

orschiro · 2014-10-25 08:21:03

Thank you!

So, I am running firmware 002 since pf mask 0x80 is the same in both command outputs:

# bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS - 
iucode_tool: system has processor(s) with signature 0x00010676
selected microcodes:
001: sig 0x00010676, pf mask 0x01, 2010-09-29, rev 0x060f, size 4096
002: sig 0x00010676, [b]pf mask 0x80[/b], 2010-09-29, rev 0x060f, size 4096
003: sig 0x00010676, pf mask 0x04, 2010-09-29, rev 0x060f, size 4096
004: sig 0x00010676, pf mask 0x40, 2010-09-29, rev 0x060f, size 4096
005: sig 0x00010676, pf mask 0x10, 2010-09-29, rev 0x060f, size 4096

~ dmesg | grep microcode                                         
[    0.340061] microcode: CPU0 sig=0x10676, [b]pf=0x80[/b], revision=0x610

I will need to find out why the 005 firmware is not applied despite having it added to grub.cfg.

# cat /boot/grub/grub.cfg
...
	echo	'Loading initial ramdisk ...'
	initrd	/boot/intel-ucode.img /boot/initramfs-linux-ck.img

Abroxa · 2014-10-25 13:26:53

I am using GRUB and have followed the instruction by using the second option (modifying /etc/grub.d/10_linux). I prefer this, because if I have to run mkconfig again for whatever reason, it will include the intel-ucode. I know I would forget this if I had just modified the generated grub.cfg. As soon as a new GRUB arrives, pacman should tell me that it created a pacnew for /etc/grub.d/10_linux and I will diff the contents and remember that there was something with the microcode stuff... Or they just included the lines which have been suggested and I can delete the pacnew.

However, the output of dmesg | grep microcode looks exactly the same before and after adding the intel-ucode.img. It does not state that anything was updated. That makes me believe, that my BIOS is up-to-date and already included the most recent firmware. Can anyone confirm my thoughts? Below some specs:

CPU: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz
BIOS: 8CET58WW (1.38 ) [LENOVO ThinkPad T420s]

Output of dmesg | grep microcode:
[ 0.332920] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x29
[ 0.332926] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x29
[ 0.332934] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x29
[ 0.332941] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x29
[ 0.332987] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

mcloaked · 2014-10-25 13:42:28

orschiro wrote:

Thank you!

~ dmesg | grep microcode                                         
[    0.340061] microcode: CPU0 sig=0x10676, [b]pf=0x80[/b], revision=0x610

I will need to find out why the 005 firmware is not applied despite having it added to grub.cfg.

# cat /boot/grub/grub.cfg
...
	echo	'Loading initial ramdisk ...'
	initrd	/boot/intel-ucode.img /boot/initramfs-linux-ck.img

Is linux-ck set up to apply early microcode updates? The stock kernel can only do so for version 3.17.1-1-ARCH onwards.

bstaletic · 2014-10-25 13:46:57

Linux-ck is capable of applying microcode early since 3.16.6 (Graysky's package).

kaptoxic · 2014-10-25 16:39:02

I am using GRUB on my Lenovo t420s; I updated my /etc/grub.d/10_linux as given in wiki,

...
EOF
  if test -n "${initrd}" ; then
    # added (automatic microcode update) -- https://wiki.archlinux.org/index.php/Microcode#Enabling_Intel_Microcode_Updates
    if test -f "${dirname}/intel-ucode.img"; then
        ucode="${rel_dirname}/intel-ucode.img "
    else
        ucode=
    fi
    # TRANSLATORS: ramdisk isn't identifier. Should be translated.
    message="$(gettext_printf "Loading initial ramdisk ...")"
    sed "s/^/$submenu_indentation/" << EOF
	echo	'$(echo "$message" | grub_quote)'
        # commented (see above)
	#initrd	${rel_dirname}/${initrd}
	initrd	${ucode}${rel_dirname}/${initrd}
EOF
...

recreated the grub config but after reboot when I run "dmesg | grep microcode", I get:

[    3.175964] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x28
[    3.175989] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x28
[    3.176004] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x28
[    3.176017] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x28
[    3.176071] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

So no "early update...". Am I doing something wrong? Is it the difference between relative path to boot partitions perhaps (/intel-ucode.img VS /boot/intel-ucode.img)?

Last edited by kaptoxic (2014-10-25 16:41:19)

mcloaked · 2014-10-25 16:50:54

I have been updating an old laptop with the new microcode package also. (Samsung Q35).

I checked the intel-ucode package for a microcode update for the cpu on this machine using as per the wiki:

# modprobe cpuid
# lsmod |grep cpuid
cpuid                  12583  0 
# bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS -
iucode_tool: system has processor(s) with signature 0x000006e8
selected microcodes:
001: sig 0x000006e8, pf mask 0x20, 2005-11-15, rev 0x0039, size 4096

So expecting to see 0x39 as an early update during boot. Yet after boot I see in the journal:

# journalctl -b | grep microcode
Oct 25 17:30:22 localhost kernel: microcode: CPU0 sig=0x6e8, pf=0x20, revision=0x39
Oct 25 17:30:22 localhost kernel: microcode: CPU1 sig=0x6e8, pf=0x20, revision=0x39
Oct 25 17:30:22 localhost kernel: microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

So I am seeing this also for this machine with no early microcode update listed. Perhaps some CPUs just don't need the early update or maybe I am not doing the early update correctly. This machine boots with grub via BIOS legacy, not EFI, and I applied the additional initrd=/intel-ucode.img file to the initrd line in /boot/grub/grub.cfg where /boot is a separate partition and /boot has the kernel and usual initrd img files and now the intel-ucode.img file as well.

My other machines which boot via refind in UEFI all show the early microcode updates without any problem. The microcode version is the same in the journal as it was with previous versions of the microcode and kernel packages.

One thing that would be useful to know is how to find what the microcode version is in BIOS? In this case the latest microcode is from 2005 so I am guessing that this is the version that the BIOS uses and so no further update is needed when the linux kernel loads.

Last edited by mcloaked (2014-10-25 17:09:44)

czubek · 2014-10-25 22:25:13

I installed intel-ucode and iucode-tool, modprobed cpuid and ran the same check as mcloaked and got what I believe to be an error. Can someone tell me what it means? My Acer Veriton is equipped with an Atom CPU.

[chris@N281G ~]$ grep "processor\|core id" /proc/cpuinfo
processor	: 0
core id		: 0
processor	: 1
core id		: 0
[chris@N281G ~]$ bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS -
iucode_tool: could not open cpuid devices, cannot scan system processor signatures
selected microcodes:

Last edited by czubek (2014-10-25 22:26:37)

orschiro · 2014-10-25 22:28:27

@czubek

Try running the command as root.

lucas7_ · 2014-10-25 23:00:29

I am so confused by this. I have no idea what the downsides are if I don't do this. I hadn't even heard of the package intel-ucode before this so I just went ahead and did it by adding /boot/intel-ucode.img to grub.cfg because fuck it might as well.

[    0.000000] CPU0 microcode updated early to revision 0xa0b, date = 2010-09-28
[    0.233586] microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa0b
[    0.233594] microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa07
[    0.233672] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

I'm guessing it went well.

Anyways can someone explain to me like I'm an idiot why this is necessary and what would happen if I didn't follow those instructions?.

Scimmia · 2014-10-25 23:05:58

Think of the microcode as the firmware of your processor. Normally this is part of your BIOS/UEFI and only gets updated when your motherboard manufacturer releases a new update and you flash your board. Linux has the ability to instead load a file at runtime for your processor to use, allowing you to update it whenever you want.

Arch Linux

#26 2014-10-24 19:16:38

Re: [solved]Intel microcode necessary?

#27 2014-10-24 19:22:23

Re: [solved]Intel microcode necessary?

#28 2014-10-24 19:59:05

Re: [solved]Intel microcode necessary?

#29 2014-10-24 20:01:39

Re: [solved]Intel microcode necessary?

#30 2014-10-24 20:14:51

Re: [solved]Intel microcode necessary?

#31 2014-10-24 20:25:37

Re: [solved]Intel microcode necessary?

#32 2014-10-24 20:30:56

Re: [solved]Intel microcode necessary?

#33 2014-10-24 20:40:53

Re: [solved]Intel microcode necessary?

#34 2014-10-24 20:53:31

Re: [solved]Intel microcode necessary?

#35 2014-10-24 21:16:47

Re: [solved]Intel microcode necessary?

#36 2014-10-24 21:25:51

Re: [solved]Intel microcode necessary?

#37 2014-10-24 21:27:30

Re: [solved]Intel microcode necessary?

#38 2014-10-24 21:42:27

Re: [solved]Intel microcode necessary?

#39 2014-10-25 07:54:43

Re: [solved]Intel microcode necessary?

#40 2014-10-25 07:57:15

Re: [solved]Intel microcode necessary?

#41 2014-10-25 08:21:03

Re: [solved]Intel microcode necessary?

#42 2014-10-25 13:26:53

Re: [solved]Intel microcode necessary?

#43 2014-10-25 13:42:28

Re: [solved]Intel microcode necessary?

#44 2014-10-25 13:46:57

Re: [solved]Intel microcode necessary?

#45 2014-10-25 16:39:02

Re: [solved]Intel microcode necessary?

#46 2014-10-25 16:50:54

Re: [solved]Intel microcode necessary?

#47 2014-10-25 22:25:13

Re: [solved]Intel microcode necessary?

#48 2014-10-25 22:28:27

Re: [solved]Intel microcode necessary?

#49 2014-10-25 23:00:29

Re: [solved]Intel microcode necessary?

#50 2014-10-25 23:05:58

Re: [solved]Intel microcode necessary?

Board footer