On Tue, 06 Sep 2016, Jonas Zierer wrote:
> I'm running Ubuntu on my Dell E7440 (CPU: i7-4600U CPU @ 2.10GHz,
> sig=0x40651) and have exactly the same problem. I updated the microcode
It might be, or it might not be exactly the same problem.
Do you have *exactly* the same problem as the one
I'm running Ubuntu on my Dell E7440 (CPU: i7-4600U CPU @ 2.10GHz,
sig=0x40651) and have exactly the same problem. I updated the microcode
using iucode_tools to the most recent version (7/14/2016) but the
problem persists
dmesg:
[0.00] microcode: CPU0 microcode updated early to
On Fri, 26 Aug 2016, Stuart Bennett wrote:
> I reproducibly found that on initial booting, with no system load, 0x36 came
> up with processors clocked at 900MHz (below the cpufreq scaling_min_freq of
> 1200MHz), before then settling to 1200MHz after some time, whereas 0x32 and
> 0x38 behaved
On 19/08/16 15:17, Henrique de Moraes Holschuh wrote:
It means 0x36 can be safely upgraded to 0x38, and 0x36 is widely
available and used, so it is valuable info.
Ok, I must have misinterpreted your previous question. No matter.
I down-graded the BIOS, and spent a while alternating between
On Fri, 19 Aug 2016, Stuart Bennett wrote:
> On 19/08/16 13:49, Henrique de Moraes Holschuh wrote:
> >No need to downgrade the BIOS, it is enough if you go from microcode
> >0x36 to 0x38 by just installing intel-microcode and rebooting. It is
> >not a complete test, but a *lot* less painful :-)
>
On 19/08/16 13:49, Henrique de Moraes Holschuh wrote:
No need to downgrade the BIOS, it is enough if you go from microcode
0x36 to 0x38 by just installing intel-microcode and rebooting. It is
not a complete test, but a *lot* less painful :-)
That is certainly easy to do, but can you explain
On 19/08/16 13:10, Henrique de Moraes Holschuh wrote:
ping?
[snip]
This could indeed realistically be fixed in microcode 0x38. Please test
the intel-microcode packages in unstable/testing or stable-backports
when possible, and report back...
I shall be on-site with this server on Monday.
On Fri, 19 Aug 2016, Stuart Bennett wrote:
> On 19/08/16 13:10, Henrique de Moraes Holschuh wrote:
> a) downgrade the BIOS
> b) wait to verify that the performance bug returns
> c) install the 0x38 microcode
> d) wait for performance to regress (potentially)
> e) restore the BIOS
>
> I shall, but
On Fri, 22 Jul 2016, Henrique de Moraes Holschuh wrote:
> > On Mon, 28 Mar 2016, Stuart Bennett wrote:
> > > On 28/03/16 19:00, Henrique de Moraes Holschuh wrote:
> > > >That said, what microcode comes with this new BIOS? Is it 0x36 already,
> > > >or something earlier?
> > >
> > > It is indeed
> On Mon, 28 Mar 2016, Stuart Bennett wrote:
> > On 28/03/16 19:00, Henrique de Moraes Holschuh wrote:
> > >That said, what microcode comes with this new BIOS? Is it 0x36 already,
> > >or something earlier?
> >
> > It is indeed 0x36.
The intel-microcode upstream releases for 2016 have microcode
On Mon, 28 Mar 2016, Stuart Bennett wrote:
> On 28/03/16 19:00, Henrique de Moraes Holschuh wrote:
> >That said, what microcode comes with this new BIOS? Is it 0x36 already,
> >or something earlier?
>
> It is indeed 0x36.
Thank you for the information.
--
"One disk to rule them all, One
On 28/03/16 19:00, Henrique de Moraes Holschuh wrote:
That said, what microcode comes with this new BIOS? Is it 0x36 already,
or something earlier?
It is indeed 0x36.
Stuart
On Mon, Mar 28, 2016, at 09:44, Stuart Bennett wrote:
> On 16/03/16 17:34, Henrique de Moraes Holschuh wrote:
> > On Mon, Mar 7, 2016, at 14:28, Stuart Bennett wrote:
> >> As it happens there is a published update including microcode 0x36 and
> >> the management engine changelog mentions various
On 16/03/16 17:34, Henrique de Moraes Holschuh wrote:
On Mon, Mar 7, 2016, at 14:28, Stuart Bennett wrote:
As it happens there is a published update including microcode 0x36 and
the management engine changelog mentions various things relating to
power limiting. Before complaining to them
On 16/03/16 17:34, Henrique de Moraes Holschuh wrote:
On Mon, Mar 7, 2016, at 14:28, Stuart Bennett wrote:
As it happens there is a published update including microcode 0x36 and
the management engine changelog mentions various things relating to
power limiting. Before complaining to them
On Mon, Mar 7, 2016, at 14:28, Stuart Bennett wrote:
> On 03/03/16 14:48, Henrique de Moraes Holschuh wrote:
> > Argh. Is this a motherboard from a non-joke vendor ? If so, please
> > open a support case and tell them you are hitting a "severe performance
> > issue" that looks like the Xeon
On Thu, Mar 3, 2016, at 10:11, Stuart Bennett wrote:
> On 03/03/16 12:33, Henrique de Moraes Holschuh wrote:
> > Does it fix anything?
>
> Sadly not.
...
> /sys/devices/system/cpu/intel_pstate/max_perf_pct:100
> /sys/devices/system/cpu/intel_pstate/no_turbo:0
>
On 03/03/16 12:33, Henrique de Moraes Holschuh wrote:
please do away with
*both* the msr.ko and the intel_rapl.ko drivers, and reboot on the new
microcode...
Does it fix anything?
Sadly not.
If it doesn't, please run this:
rgrep . /sys/devices/system/cpu/intel_pstate
(that's a dot as the
On Thu, Mar 3, 2016, at 08:57, Stuart Bennett wrote:
> On 02/03/16 17:57, Henrique de Moraes Holschuh wrote:
> > This is exactly what happens when thermald messes with these Xeons, as
> > long as your MSR 0x1b0 is also reading "7".
> >
> > So, could you check the output of "rdmsr 0x1b0" ?
>
> MSR
On 02/03/16 17:57, Henrique de Moraes Holschuh wrote:
This is exactly what happens when thermald messes with these Xeons, as
long as your MSR 0x1b0 is also reading "7".
So, could you check the output of "rdmsr 0x1b0" ?
MSR 0x1b0 is MSR_IA32_ENERGY_PERF_BIAS, which is included in the
On Wed, Mar 2, 2016, at 11:51, Stuart Bennett wrote:
> On 27/02/16 22:36, Henrique de Moraes Holschuh wrote:
> > In the thermald bug report, you will see lots of posts asking for the values
> > of several MSRs, and also to run "turbostat" and attach its output.
> >
> > Can you repeat those tests,
On 27/02/16 22:36, Henrique de Moraes Holschuh wrote:
In the thermald bug report, you will see lots of posts asking for the values
of several MSRs, and also to run "turbostat" and attach its output.
Can you repeat those tests, and report the value of those MSRs in both the
"working" and "system
On Sat, 27 Feb 2016, Stuart Bennett wrote:
> Let me know if any other tests/information indicated in the other bug would
> be potentially relevant in this case.
In the thermald bug report, you will see lots of posts asking for the values
of several MSRs, and also to run "turbostat" and attach its
On 27/02/16 13:51, Henrique de Moraes Holschuh wrote:
On Fri, 26 Feb 2016, Stuart Bennett wrote:
Some time after booting, all cores of an Intel E5-2680 v3 get throttled to
around 400MHz. The intel_pstate cpufreq driver is in use, as is the
Are you using thermald?
I'm afraid not; a list of
On Fri, 26 Feb 2016, Stuart Bennett wrote:
> Some time after booting, all cores of an Intel E5-2680 v3 get throttled to
> around 400MHz. The intel_pstate cpufreq driver is in use, as is the
Are you using thermald?
If so, could you please try to remove it, **reboot** (with microcode 0x36),
and
Package: intel-microcode
Version: 3.20151106.1~deb8u1
Some time after booting, all cores of an Intel E5-2680 v3 get throttled
to around 400MHz. The intel_pstate cpufreq driver is in use, as is the
powersave governor, but neither swapping to the performance governor nor
increasing CPU load
26 matches
Mail list logo
