On 7/31/2015 3:48 PM, Andrew Cooper wrote:
So, the patch id values have only been obtained empirically.
The Linux patch provides the bug reference for
this:https://bugzilla.suse.com/show_bug.cgi?id=913996
(It's a fairly long thread but the gist of it is that people
predominantly seem to be expe
On 31/07/2015 21:45, Aravind Gopalakrishnan wrote:
> On 7/30/2015 12:01 PM, Andrew Cooper wrote:
>> On 30/07/15 17:23, Aravind Gopalakrishnan wrote:
>>> Some of older[Fam10h] systems require that the microcode versions
>>> that it comes up with should not be updated by the microcode driver.
>>> Oth
On 7/30/2015 12:01 PM, Andrew Cooper wrote:
On 30/07/15 17:23, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that the microcode versions
that it comes up with should not be updated by the microcode driver.
Otherwise, system hangs are known to occur.
In this patch, we check
On 30/07/15 17:23, Aravind Gopalakrishnan wrote:
> Some of older[Fam10h] systems require that the microcode versions
> that it comes up with should not be updated by the microcode driver.
> Otherwise, system hangs are known to occur.
>
> In this patch, we check for those microcode versions and abor
On 07/30/2015 12:23 PM, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that the microcode versions
that it comes up with should not be updated by the microcode driver.
Otherwise, system hangs are known to occur.
In this patch, we check for those microcode versions and abort
Some of older[Fam10h] systems require that the microcode versions
that it comes up with should not be updated by the microcode driver.
Otherwise, system hangs are known to occur.
In this patch, we check for those microcode versions and abort the
update process if existing microcode level is alread
