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
>
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
48 matches
Mail list logo
