> Managed to get this tested and applied thanks to your help and it has landed > in > new Cygwin 3.1.6 so please post your results and any further comments when you > have a chance to upgrade and test.
I checked it out in the new Cygwin 3.1.6, and it shows microcode version correctly now, but assuming Windows was booted up from the initial power-on, i.e. after BIOS POST. There's another problem, though... After wakeup (from sleep), Windows reports microcode versions in the registry weirdly. Only the CPU0 (which in my case core 0) is reported with the same info that was reported for all cores after the initial boot-up, all other cores are reported with some old microcode version (I presume that's the microcode that Windows has on its own in one of its CPU driver DLLs). So for core 0 it is as it was (and for all of them after the boot-up): C:\Windows\system32>regtool list -v /proc/registry/HKEY_LOCAL_MACHINE/HARDWARE/DESCRIPTION/System/CentralProcessor/0/ Component Information (REG_BINARY) = 00 00 00 00 00 00 00 00 Identifier (REG_SZ) = "Intel64 Family 6 Model 23 Stepping 10" Configuration Data (REG_FULL_RESOURCE_DESCRIPTOR) = ? ProcessorNameString (REG_SZ) = "Intel(R) Xeon(R) CPU X5470 @ 3.33GHz" VendorIdentifier (REG_SZ) = "GenuineIntel" FeatureSet (REG_DWORD) = 0x215b3ffe (559628286) ~MHz (REG_DWORD) = 0x00000d04 (3332) Update Signature (REG_BINARY) = 00 00 00 00 0e 0a 00 00 Update Status (REG_DWORD) = 0x00000007 (7) Previous Update Signature (REG_BINARY) = 00 00 00 00 0e 0a 00 00 Platform ID (REG_DWORD) = 0x00000040 (64) For other cores (1-3), it's this (after wake-up; but after the boot-up it was the same as the above for core 0): C:\Windows\system32>regtool list -v /proc/registry/HKEY_LOCAL_MACHINE/HARDWARE/DESCRIPTION/System/CentralProcessor/1/ Component Information (REG_BINARY) = 00 00 00 00 00 00 00 00 Identifier (REG_SZ) = "Intel64 Family 6 Model 23 Stepping 10" Configuration Data (REG_FULL_RESOURCE_DESCRIPTOR) = ? ProcessorNameString (REG_SZ) = "Intel(R) Xeon(R) CPU X5470 @ 3.33GHz" VendorIdentifier (REG_SZ) = "GenuineIntel" FeatureSet (REG_DWORD) = 0x215b3ffe (559628286) ~MHz (REG_DWORD) = 0x00000d04 (3332) Update Signature (REG_BINARY) = 00 00 00 00 0b 0a 00 00 Update Status (REG_DWORD) = 0x00000000 (0) Previous Update Signature (REG_BINARY) = 00 00 00 00 00 00 00 00 Platform ID (REG_DWORD) = 0x00000040 (64) Note that there's no "Previous Update Signature" in the latter case, and "Update Status" is 0 (instead of 7, for core 0, and what it also was for these same cores 1-3 after the boot-up). I'm being repetitive to underscore the noted differences. So Cygwin reports these same values in its /proc/cpuinfo output (core0: 0xA0E, cores1-3: 0xA0B)... Meanwhile, Intel CPU ID utility keeps saying the CPU microcode version is still 0xA0E (they don't show "per-core" values, if that was the thing at all), and so does HWiNFO64 (again for the CPU as a whole). I'm not exactly sure how to read Window's registry values with cores on the same CPU having different microcode versions (is that even possible?) I tried to dig into what "Update Status" means, but I couldn't find any useful information, unfortunately. I suspect that "0" means a successful update, but that would also mean that Windows updated ucode in cores 1-3 from nothing to 0xA0B -- and I checked that that's the latest microcode that is shipped with this version of Windows, as a Windows Update, for this CPU. I found one post that said that "Update Status" 6 would mean no matching update found, but there is no 6 in my case. An interesting fact is that when I run Linux in VMWare on Windows woken up from sleep, allocating two CPUs for the VM, I can get a mix of one 0xA0E and one 0xA0B ucode reported in "/proc/cpuinfo" for the cores, or it can be two 0xA0Bs. But it looks like Linux knows exactly it is run virtualized on VMWare, and so may not be reporting from the actual values from the MSRs for that. I also noticed that it does not attempt to load any microcode in this case. When I use VirtualBox for the same, I get a completely different microcode version output (but so far consistent and same for both cores), 0x60B (which I don't think is a valid value at all, TBH). Yet the same, it does not looks like it attempts to load any on its own because it knows it is run virtualized (yet it does not state exactly the host OS VM software unlike it does with VMWare). So, apologies for the long post. I just tried to be thorough ;-) Thanks, Anton -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
