[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled



I did get to test the 3.15 kernel over the weekend. There' definitely some improvement. as hdparm -t now reports 25-30MB/s for my hard drive instead of 6-7MB/s. The stutter in audio playback is less pronounced and almost unnoticeable. At this point the dn2800mt board is largely useable with hyperthreading enabled. I'll delve more deeply into this as time allows.

On 5/14/2014 4:05 PM, Henrique de Moraes Holschuh wrote:
On Wed, 14 May 2014, Paul Ausbeck wrote:
While examining the kernel log for another reason, I came across
evidence that acpi_idle, and not intel_idle, is being used on my
dn2800mt system, see below. In fact, it seems that intel_idle cannot
be used. Is there some sort of binary blob involved here?
Well, I just did a quick hunting for when support was added...

commit acead1b0fac5b10d0ae3f1cc5f7820b9f9f924f5
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Sat Jan 25 22:24:22 2014 +0100

     intel_idle: Add CPU model 54 (Atom N2000 series)
Add CPU ID for Atom N2600/N2800 processors. Datasheets indicate support
     for this, detailed information about potential quirks or limitations are
     missing, though. So we just reuse the definition for the previous ATOM
     series. Tests on N2800 systems showed that this addition is fine an can
     reduce power consumption by about 0.25 W (personally confirmed on Intel
     DN2800MT).
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
     Signed-off-by: Len Brown <len.brown@intel.com>


The bad news is that this commit is present only on kernel 3.15-rc.

It should be trivial to backport it to older kernels (it really just adds a
single line to the table of supported processors), but I didn't check if the
atom code in intel-idle received any fixes lately.

It might be worthwhile to test it, or to test the latest development 3.15
kernel (get it directly from Linus' git tree).  If you're going to test
3.15, do be aware that there's always increased risk of issues when testing
a non-released kernel, so the risks and the procedures I gave you for safe
testing of bissected kernels DO apply.

BTW, it is actually weird that acpi-idle would malfunction _or_ interact
badly with firmware, as it usually the more tested and stable idle driver
since it operates more closely to that other OS does than intel-idle :-)


Hmm, come to think of it, here's something you can try:

http://biosbits.org/

It is an official Intel testsuite for the BIOS/EFI.  And I *believe* you can
actually get it to boot Debian with replacement firmware it provides (my
best guess is that it overrides acpi tables and reprograms the processor and
chipset).



Reply to: