I suppose it is for Broadwell EX(Expandable or Expensive, whichever you like).
The patch description is wrong!
Document 334165-010US describes erratum BDF90:
Loading Microcode Updates or Executing an Authenticated Code Module May Result
in a System Hang
I have not read such a bug in the past.
I suppose it is for Broadwell EX(Expandable or Expensive, whichever you like).
The patch description is wrong!
Document 334165-010US describes erratum BDF90:
Loading Microcode Updates or Executing an Authenticated Code Module May Result
in a System Hang
I have not read such a bug in the past.
Hello Borris, thank you both. It was about time... Thanks for your effort
though!
Ingo is right here any modification must be advertised.
The patch was sent on October but I didn't fell on it until...
yesterday when I saw that it was routed for 3.16!
[3.16,136/204] x86/cpu/AMD: Apply the
Hello Borris, thank you both. It was about time... Thanks for your effort
though!
Ingo is right here any modification must be advertised.
The patch was sent on October but I didn't fell on it until...
yesterday when I saw that it was routed for 3.16!
[3.16,136/204] x86/cpu/AMD: Apply the
Ok, Ubuntu 16.04.1 is running on the box now, no issues so far. Any
special workload I should run?
No, will simply crash without running something special! If you get no
issues then that is bad news. I get frequent and repeatable crashes. I
forgot to mention that all those crashes occur at
Ok, Ubuntu 16.04.1 is running on the box now, no issues so far. Any
special workload I should run?
No, will simply crash without running something special! If you get no
issues then that is bad news. I get frequent and repeatable crashes. I
forgot to mention that all those crashes occur at
Why not? It all depends on the load type, working set and the access
patterns. There's no strong correlation between the load of a machine
and the amount of branch misses...
Yes I did not say that there is a linear correlation but that does not
mean that those two numbers move opposite to each
Why not? It all depends on the load type, working set and the access
patterns. There's no strong correlation between the load of a machine
and the amount of branch misses...
Yes I did not say that there is a linear correlation but that does not
mean that those two numbers move opposite to each
so that doesn't tell me a whole lot.
It does to me! That cpu family is "broken" both on B0 and C0. I think
that a CPU at 30% load should not have >31% branch misses. For example
with 5% CPU usage you can't expect to get 10% branch-misses...
Well, Ontario is a small core and with the
so that doesn't tell me a whole lot.
It does to me! That cpu family is "broken" both on B0 and C0. I think
that a CPU at 30% load should not have >31% branch misses. For example
with 5% CPU usage you can't expect to get 10% branch-misses...
Well, Ontario is a small core and with the
Sure, give me the exact command you're executing so that I can do it
here.
No command needed, just type:
sudo perf stat -a
and immediately exit with ctrl+C. That will give you a glimpse. See "%
of all branches"
next open firefox, rerun the same command after firefox launches and
immediately
Sure, give me the exact command you're executing so that I can do it
here.
No command needed, just type:
sudo perf stat -a
and immediately exit with ctrl+C. That will give you a glimpse. See "%
of all branches"
next open firefox, rerun the same command after firefox launches and
immediately
Hmm, so did you apply the patch correctly?
Yes
The patch is not equivalent to the original. As a result it behaves
differently. To be specific, using dmesg I get the expected value from
the affected MSR with the original patch. With the latest patch,
patching of the MSR occurs after dmesg
Hmm, so did you apply the patch correctly?
Yes
The patch is not equivalent to the original. As a result it behaves
differently. To be specific, using dmesg I get the expected value from
the affected MSR with the original patch. With the latest patch,
patching of the MSR occurs after dmesg
In any case, I tested it on my ON-B0 box and it looked good.
Good to hear but something is still wrong on my laptop as nothing worked
as expected :(
Since I have a working custom kernel including the fix from my original
patch it was clear from boot that the last patched kernel did not
In any case, I tested it on my ON-B0 box and it looked good.
Good to hear but something is still wrong on my laptop as nothing worked
as expected :(
Since I have a working custom kernel including the fix from my original
patch it was clear from boot that the last patched kernel did not
Are you sure you did it right?
Yes and no.
I use the patchwork site and my brother uses an LKML mirror site. He
gets patches from there. This worked the with the first two patches but
the last one was a big one and that site truncated some bytes from a
line...Sorry for the trouble.
For
Are you sure you did it right?
Yes and no.
I use the patchwork site and my brother uses an LKML mirror site. He
gets patches from there. This worked the with the first two patches but
the last one was a big one and that site truncated some bytes from a
line...Sorry for the trouble.
For
Last night attempt failed as patch does not apply to 4.8. Neither 4.8.1
nor 4.8.4. Did you switch to 4.9? Please use 4.8 as we prefer to avoid
rc kernels as we had casualties in the past. Do you want to add changes
by hand?
Last night attempt failed as patch does not apply to 4.8. Neither 4.8.1
nor 4.8.4. Did you switch to 4.9? Please use 4.8 as we prefer to avoid
rc kernels as we had casualties in the past. Do you want to add changes
by hand?
Patch does not compile.
I tried to add pci.h but did nothing.
I converted pci_read_config to pci_read_config_dword but again nothing.
On 2016-10-22 02:01, Borislav Petkov wrote:
Do you have a way to trigger that one?
To be honest I can't say. My brother's machine(s) has random crashes
from
Patch does not compile.
I tried to add pci.h but did nothing.
I converted pci_read_config to pci_read_config_dword but again nothing.
On 2016-10-22 02:01, Borislav Petkov wrote:
Do you have a way to trigger that one?
To be honest I can't say. My brother's machine(s) has random crashes
from
Thank you for your time! I have chosen reply to list and all recipients,
it must work now.
My brother rejected the proposed patch because it does not provide
equivalent functionality with the original.
Our initial patch would fix 3 broken models and 1 working model. Your
patch will only
Thank you for your time! I have chosen reply to list and all recipients,
it must work now.
My brother rejected the proposed patch because it does not provide
equivalent functionality with the original.
Our initial patch would fix 3 broken models and 1 working model. Your
patch will only
Sorry for the late reply! This machine has caused nothing but trouble.
HP will not fix it and we will not choose their laptops anymore...
My brother told me that we apply a quirk to the last Ontario APUs that
do not need it but I did not think it would be an issue since they have
fixed the
Sorry for the late reply! This machine has caused nothing but trouble.
HP will not fix it and we will not choose their laptops anymore...
My brother told me that we apply a quirk to the last Ontario APUs that
do not need it but I did not think it would be an issue since they have
fixed the
AMD F14h machines have an erratum which can cause unpredictable program
behaviour under specific branch conditions. The workaround is to set
MSRC001_1021[14] and MSRC001_1021[3]. Both bits are reserved for this
MSR, so we trust AMD suggestions. Since there is no BIOS update
containing that
AMD F14h machines have an erratum which can cause unpredictable program
behaviour under specific branch conditions. The workaround is to set
MSRC001_1021[14] and MSRC001_1021[3]. Both bits are reserved for this
MSR, so we trust AMD suggestions. Since there is no BIOS update
containing that
28 matches
Mail list logo