> https://software.intel.com/security-software-guidance/insights/microcode-update-guidance
Thanks, interesting reading.
I think in my case the ucode update is done via the FIT method, though, as the
latest microcode (0xA0E) is included in the re-packaged BIOS, and re-flashed
into ROM along with
> So I think you probably encountered another Windows sleep bug
Quite possibly... The microcode version in the registry looks okay after
wake-up from hibernate, though (but that subsumes the system POST and clean
boot).
> 0 - ucode loading supported by CPU - update available and successfully
On 2020-07-16 13:46, Brian Inglis wrote:
> On 2020-07-16 08:56, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> It may be possible that Windows executes a CPUID instruction, and then reads
> MSR
Intel states CPUID of leaf EAX = 1, so not reading that leaf may not update MSR.
> 8BH IA32_
On 2020-07-16 08:56, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>> 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 check
> 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 as
On 2020-06-10 15:45, Brian Inglis wrote:
> On 2020-06-10 14:23, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>>> I'll have to recheck how Linux handles these
>>
>> JFYI I was in correspondence with the cpuid utility team lately, and they
>> told me that Linux uses vendor-specific MSRs to
On 2020-06-10 14:23, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>> I'll have to recheck how Linux handles these
>
> JFYI I was in correspondence with the cpuid utility team lately, and they
> told me that Linux uses vendor-specific MSRs to pull that info out:
>
>> Check out:
>>
>>
On 2020-06-10 09:34, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>> also have to look for Update Signature
>
> It's Windows 7 here (Windows 10 uses newer registry key names, with the word
> "Revision" in them, instead).
>
>> Could you please run:
>
> $ head /proc/version
> CYGWIN_NT-
> I'll have to recheck how Linux handles these
JFYI I was in correspondence with the cpuid utility team lately, and they told
me that Linux uses vendor-specific MSRs to pull that info out:
> Check out:
>
>MSR_IA32_UCODE_REV
>MSR_AMD64_PATCH_LEVEL
>
> Both reference MSR 0x8b.
--
Proble
> also have to look for Update Signature
It's Windows 7 here (Windows 10 uses newer registry key names, with the word
"Revision" in them, instead).
> Could you please run:
$ head /proc/version
CYGWIN_NT-6.1-7601 version 3.1.4-340.x86_64 (corinna@calimero) (gcc version
7.4.0 20181206 (Fedora Cy
On 2020-05-31 09:07, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> In the updated Cygwin (3.1.4), /proc/cpuinfo still reports the microcode
version wrong.
> Compare:
>
> Cygwin:
> $ uname -a
> CYGWIN_NT-6.1 xxx 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
>
> $ cat /proc/cpuinfo
> p
Hi All,
In the updated Cygwin (3.1.4), /proc/cpuinfo still reports the microcode
version wrong.
Compare:
Cygwin:
$ uname -a
CYGWIN_NT-6.1 xxx 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model
12 matches
Mail list logo
