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
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?
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
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
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
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
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
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
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
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
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
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
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
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.
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?
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
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
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
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
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
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
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
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
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
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
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
