Package: ntp
Version: 1:4.2.8p4+dfsg-3
File: /etc/ntp.conf
The addition of `limited' to the default ntp.conf in 1:4.2.8p3+dfsg-1
( https://anonscm.debian.org/viewvc/pkg-ntp?view=revision=406 )
results in the check_ntp_time plugin from the monitoring-plugins-basic
package (2.1.2-2~bpo8+1)
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 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 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 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 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 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 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 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
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
12 matches
Mail list logo
