On Mon, Oct 31, 2016 at 11:54:44PM +0200, sonofa...@openmailbox.org wrote:
> 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 program launch. If the
> p
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 pro
On Mon, Oct 24, 2016 at 07:14:50PM +0200, Borislav Petkov wrote:
> > Yes, using Ubuntu 16.04 will just crash everything! For example I had
> > crashes with the software updater program. Moreover firefox would become
> > unresponsive even with one tab.
>
> Ok, lemme install 16.04 on that box and se
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
On Mon, Oct 24, 2016 at 11:39:47PM +0300, sonofa...@openmailbox.org wrote:
> 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...
Why not? It a
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 erratum
On Mon, Oct 24, 2016 at 04:13:25PM +0300, sonofa...@openmailbox.org wrote:
> 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"
$ ./perf stat -a --repeat 10 sleep 1s
Performance counter stats for 'system wide
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 e
On Mon, Oct 24, 2016 at 02:38:06PM +0300, sonofa...@openmailbox.org wrote:
> 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 th
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 p
On Mon, Oct 24, 2016 at 12:02:39AM +0300, sonofa...@openmailbox.org wrote:
> Good to hear but something is still wrong on my laptop as nothing worked as
> expected :(
Hmm, so did you apply the patch correctly?
Send me arch/x86/kernel/amd_nb.c after you've applied the patch.
Then, boot the kernel
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 touch
On Sun, Oct 23, 2016 at 08:06:44PM +0300, sonofa...@openmailbox.org wrote:
> 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...S
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 re
On Sun, Oct 23, 2016 at 12:39:37PM +0300, sonofa...@openmailbox.org wrote:
> 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
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?
On Sat, Oct 22, 2016 at 02:16:41PM +0300, sonofa...@openmailbox.org wrote:
> Patch does not compile.
Yeah, it needs more work.
Try the version below. It needs to be done differently because we need
PCI extended config space access to be enabled in order to check bit 2.
> To be honest I can't say
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 t
On Sat, Oct 22, 2016 at 12:51:32AM +0300, sonofa...@openmailbox.org wrote:
> Thank you for your time! I have chosen reply to list and all recipients, it
> must work now.
Yes, exactly what I had in mind.
> My brother rejected the proposed patch because it does not provide
> equivalent functionalit
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 wo
Hi Ioannis,
first of all, when you reply to a mail on lkml, please use the "reply-to-all"
functionality of your mail client - otherwise replies might get missed on such a
high volume mailing list.
On Fri, Oct 21, 2016 at 07:19:07PM +0300, sonofa...@openmailbox.org wrote:
> Sorry for the late repl
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 e
On Wed, Oct 19, 2016 at 04:58:08PM +0300, sonofa...@openmailbox.org wrote:
>
> 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,
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 wo
24 matches
Mail list logo