On August 1, 2018 7:01:50 PM GMT+03:00, Oleksandr Natalenko
wrote:
>I don't mind doing the right thing at all. It is just to inform you
>that
>it was found to be useful.
I don't think it would've worked if you did a second microcode upgrade on the
system.
--
Sent from a small device:
On August 1, 2018 7:01:50 PM GMT+03:00, Oleksandr Natalenko
wrote:
>I don't mind doing the right thing at all. It is just to inform you
>that
>it was found to be useful.
I don't think it would've worked if you did a second microcode upgrade on the
system.
--
Sent from a small device:
Hi.
On 01.08.2018 17:59, Luck, Tony wrote:
There's no reliable way to get the old microcode revision which was
overwritten during the upgrade. If dmesg gets overwritten you lose,
like
in all the other gazillion cases where you lose information due to
that.
The primary requirement here is
Hi.
On 01.08.2018 17:59, Luck, Tony wrote:
There's no reliable way to get the old microcode revision which was
overwritten during the upgrade. If dmesg gets overwritten you lose,
like
in all the other gazillion cases where you lose information due to
that.
The primary requirement here is
> There's no reliable way to get the old microcode revision which was
> overwritten during the upgrade. If dmesg gets overwritten you lose, like
> in all the other gazillion cases where you lose information due to that.
The primary requirement here is that we report the version of the microcode
> There's no reliable way to get the old microcode revision which was
> overwritten during the upgrade. If dmesg gets overwritten you lose, like
> in all the other gazillion cases where you lose information due to that.
The primary requirement here is that we report the version of the microcode
On 08/01/2018 11:43 AM, Borislav Petkov wrote:
> (dropping stable@)
>
> On Tue, Jul 31, 2018 at 07:27:39AM -0400, Prarit Bhargava wrote:
>> I tested this on AMD Ryzen & Intel Broadwell system and dumped the
>> boot_cpu_data before and after a microcode update. On the Intel
>> system I also
On 08/01/2018 11:43 AM, Borislav Petkov wrote:
> (dropping stable@)
>
> On Tue, Jul 31, 2018 at 07:27:39AM -0400, Prarit Bhargava wrote:
>> I tested this on AMD Ryzen & Intel Broadwell system and dumped the
>> boot_cpu_data before and after a microcode update. On the Intel
>> system I also
(dropping stable@)
On Tue, Jul 31, 2018 at 07:27:39AM -0400, Prarit Bhargava wrote:
> I tested this on AMD Ryzen & Intel Broadwell system and dumped the
> boot_cpu_data before and after a microcode update. On the Intel
> system I also did a fatal MCE using mce-inject to confirm the output
> from
(dropping stable@)
On Tue, Jul 31, 2018 at 07:27:39AM -0400, Prarit Bhargava wrote:
> I tested this on AMD Ryzen & Intel Broadwell system and dumped the
> boot_cpu_data before and after a microcode update. On the Intel
> system I also did a fatal MCE using mce-inject to confirm the output
> from
(drop stable@ from CC)
On Wed, Aug 01, 2018 at 04:16:42PM +0200, Oleksandr Natalenko wrote:
> Once the kernel log does not contain a printout regarding updated microcode
> anymore (because the log buffer is limited in size and can be overwritten)
There's no reliable way to get the old microcode
(drop stable@ from CC)
On Wed, Aug 01, 2018 at 04:16:42PM +0200, Oleksandr Natalenko wrote:
> Once the kernel log does not contain a printout regarding updated microcode
> anymore (because the log buffer is limited in size and can be overwritten)
There's no reliable way to get the old microcode
Hi.
On 01.08.2018 13:38, Prarit Bhargava wrote:
After this patch, do we preserve an original microcode version
somewhere? If no,
why? Sometimes it is useful while debugging another crash because of
faulty
microcode.
Interesting, and thanks for bringing this up. Oleksandr, under what
Hi.
On 01.08.2018 13:38, Prarit Bhargava wrote:
After this patch, do we preserve an original microcode version
somewhere? If no,
why? Sometimes it is useful while debugging another crash because of
faulty
microcode.
Interesting, and thanks for bringing this up. Oleksandr, under what
On 08/01/2018 02:38 AM, Oleksandr Natalenko wrote:
> Hi.
>
>> I tested this on AMD Ryzen & Intel Broadwell system and dumped the
>> boot_cpu_data before and after a microcode update. On the Intel
>> system I also did a fatal MCE using mce-inject to confirm the output
>> from the mce handling
On 08/01/2018 02:38 AM, Oleksandr Natalenko wrote:
> Hi.
>
>> I tested this on AMD Ryzen & Intel Broadwell system and dumped the
>> boot_cpu_data before and after a microcode update. On the Intel
>> system I also did a fatal MCE using mce-inject to confirm the output
>> from the mce handling
Hi.
I tested this on AMD Ryzen & Intel Broadwell system and dumped the
boot_cpu_data before and after a microcode update. On the Intel
system I also did a fatal MCE using mce-inject to confirm the output
from the mce handling code.
P.
---8<---
On systems where a runtime microcode update has
Hi.
I tested this on AMD Ryzen & Intel Broadwell system and dumped the
boot_cpu_data before and after a microcode update. On the Intel
system I also did a fatal MCE using mce-inject to confirm the output
from the mce handling code.
P.
---8<---
On systems where a runtime microcode update has
> On 31. Jul 2018, at 15:00, Borislav Petkov wrote:
>
> On Tue, Jul 31, 2018 at 11:46:09AM +, Sironi, Filippo wrote:
>> There may be a chance of skipping this code, I think.
>>
>> If the microcode is loaded on the hyperthread sibling of the boot cpu
>> before being loaded on the boot cpu,
> On 31. Jul 2018, at 15:00, Borislav Petkov wrote:
>
> On Tue, Jul 31, 2018 at 11:46:09AM +, Sironi, Filippo wrote:
>> There may be a chance of skipping this code, I think.
>>
>> If the microcode is loaded on the hyperthread sibling of the boot cpu
>> before being loaded on the boot cpu,
On Tue, Jul 31, 2018 at 11:46:09AM +, Sironi, Filippo wrote:
> There may be a chance of skipping this code, I think.
>
> If the microcode is loaded on the hyperthread sibling of the boot cpu
> before being loaded on the boot cpu, the boot cpu will exit earlier
> from apply_microcode_intel() -
On Tue, Jul 31, 2018 at 11:46:09AM +, Sironi, Filippo wrote:
> There may be a chance of skipping this code, I think.
>
> If the microcode is loaded on the hyperthread sibling of the boot cpu
> before being loaded on the boot cpu, the boot cpu will exit earlier
> from apply_microcode_intel() -
> On 31. Jul 2018, at 13:27, Prarit Bhargava wrote:
>
> I tested this on AMD Ryzen & Intel Broadwell system and dumped the
> boot_cpu_data before and after a microcode update. On the Intel
> system I also did a fatal MCE using mce-inject to confirm the output
> from the mce handling code.
>
> On 31. Jul 2018, at 13:27, Prarit Bhargava wrote:
>
> I tested this on AMD Ryzen & Intel Broadwell system and dumped the
> boot_cpu_data before and after a microcode update. On the Intel
> system I also did a fatal MCE using mce-inject to confirm the output
> from the mce handling code.
>
I tested this on AMD Ryzen & Intel Broadwell system and dumped the
boot_cpu_data before and after a microcode update. On the Intel
system I also did a fatal MCE using mce-inject to confirm the output
from the mce handling code.
P.
---8<---
On systems where a runtime microcode update has
I tested this on AMD Ryzen & Intel Broadwell system and dumped the
boot_cpu_data before and after a microcode update. On the Intel
system I also did a fatal MCE using mce-inject to confirm the output
from the mce handling code.
P.
---8<---
On systems where a runtime microcode update has
26 matches
Mail list logo
