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 > /sys/devices/system/cpu/intel_pstate/min_perf_pct:36 > This is the same on both old and new microcodes, both degraded and not. 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 E5-v3 processor erratum HSE106, and that you need a new BIOS/UEFI with up-to-date microcode AND the fix for HSE106. Make sure to stress the fact that you're willing to try a beta BIOS/UEFI with the fix, or it could take months. Refer to http://www.intel.com/content/www/us/en/processors/xeon/xeon-e5-v3-spec-update.html for details on HSE106. Meanwhile, we shall continue trying to locate what triggers the bad behavior (it could be something else than HSE106 after all... or something we can work around). But it doesn't look like something Debian userspace is *changing* (like thermald does), which is a bad sign. Well, please enable back intel_rapl.ko, and if you need it for anything useful, msr.ko. Can you please take a look on the thermal limit stuff, and power capping (requires intel_rapl.ko) stuff? $ rgrep . /sys/devices/virtual/powercap $ rgrep . /sys/devices/virtual/thermal $ rgrep . /sys/devices/uncore* That might give us some sort of hint. > One thing I've now seen a couple of times with the new microcode, is a > down-clocking state around ~900MHz (lower than the old microcode ever > went). From this frequency, full performance *is* recoverable by > increasing load. That behavior sure looks like it is operating mostly correctly, but perhaps it is doing so with no longer current tables (or MSRs). I will need to study how this thing really works down to the bit-scrubbing level *and* ask for help... Please attach the output of dmidecode and acpidump (gzip compressed is ok). Do ensure you blank any UUIDs and serial number fields from the dmidecode output! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org>
