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.000000] microcode: CPU0 microcode updated early to revision 0x1f,
date = 2016-04-01
[ 0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256
nr_cpu_ids:4 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 33 pages/cpu @ffff88041ea00000 s98008
r8192 d28968 u524288
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4.
[ 0.018030] CPU: Physical Processor ID: 0
[ 0.018031] CPU: Processor Core ID: 0
[ 0.018917] mce: CPU supports 7 MCE banks
[ 0.018927] CPU0: Thermal monitoring enabled (TM1)
[ 0.077818] smpboot: CPU0: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz
(family: 0x6, model: 0x45, stepping: 0x1)
[ 0.078534] .... node #0, CPUs: #1
[ 0.079816] microcode: CPU1 microcode updated early to revision 0x1f,
date = 2016-04-01
[ 0.082840] NMI watchdog: enabled on all CPUs, permanently consumes
one hw-PMU counter.
[ 0.089543] x86: Booted up 1 node, 4 CPUs
[ 0.717632] ledtrig-cpu: registered to indicate activity on CPUs
[ 0.718311] microcode: CPU0 sig=0x40651, pf=0x40, revision=0x1f
[ 0.718316] microcode: CPU1 sig=0x40651, pf=0x40, revision=0x1f
[ 0.718324] microcode: CPU2 sig=0x40651, pf=0x40, revision=0x1f
[ 0.718331] microcode: CPU3 sig=0x40651, pf=0x40, revision=0x1f
is it possible that the problem was fixed for only some CPUs?
Best,
On Fri, 26 Aug 2016 14:27:12 -0300 Henrique de Moraes Holschuh
<h...@debian.org> wrote:
> 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 alike, with the cores at much higher initial
frequencies (later
> > settling to 1200MHz).
>
> This matches the behavior described in
> https://communities.intel.com/thread/105416
> for the Haswell-E i7-5820K.
>
> So, I'd say it is indeed the same microcode defect.
>
> > Using the 0x38 microcode I have not yet had any 400MHz occurrences
BUT the
> > time 0x38 has been on test is much less.
> >
> > So, in summary, the initial signs are good that 0x38 may fix the 0x36
> > performance regression, but I think a couple more weeks' use would
make me
> > more certain of that.
>
> Stuart, thank you very much for doing all this testing.
>
> I am actually pretty sure that microcode 0x38 indeed fixed the
> regression, based on the behavior you described and the report for the
> Haswell-E i7-5820K.
>
> I will tag this issue as fixed, but I will not close the bug report yet.
> Should you notice the regression still exists, please send a note to the
> bug report...
>
> --
> Henrique Holschuh
>
>
