From: Ben Hutchings <ben@decadent.org.uk>
To: Jiri Polach <clarinet@atlas.cz>, 647095@bugs.debian.org
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: CPU hyperthreading turned on after soft power-cycle
Date: Sun, 30 Oct 2011 15:25:29 +0000 [thread overview]
Message-ID: <1319988329.6759.88.camel@deadeye> (raw)
In-Reply-To: <20111030110543.5872.61279.reportbug@supermicro.uochb.cas.cz>
[-- Attachment #1: Type: text/plain, Size: 4259 bytes --]
On Sun, 2011-10-30 at 07:05 -0400, Jiri Polach wrote:
> Package: linux-2.6
> Version: 2.6.39-3~bpo60+1
> Severity: normal
>
>
> When the computer is turned off using "shutdown -h" or "halt" command,
> the hypertherading BIOS setting is changed - even if hypertherading is
> disabled in BIOS, the kernel detects twice as many "processors" on
> next boot as if hyperthreading was enabled. Please see details below.
>
> I have observed the problem on several Supermicro platforms with
> various Intel Xeon processors. The particular case I report was
> observed on Supermicro X8DTT-F mainboard with two Intel Xeon E5645
> processors (6core). The problem can be reproduced the following way:
By my understanding of how hyperthreading is controlled, this has to be
a BIOS bug, as you seem to have suspected. But if the BIOS behaviour is
kernel version-dependent, then presumably there is something the kernel
can do to work around it.
> 1. Turn on the computer, go to BIOS setup and turn "Simultaneous
> multithreading" to "Disabled". Boot Debian.
>
> 2. Check with "cat /proc/cpuinfo" that the system reports 12 CPUs (2 x
> six-core processor).
>
> 3. (optionally) Reboot the system (shutdown -r) and check that there
> are still 12 CPUs detected and reported.
>
> 4. Halt the system using "shutdown -h" or "halt", turn it on again,
> and boot Debian.
I assume from this that shutdown -h is configured to turn the system
off.
> 5. Check the number of CPUs reported - it will show you that there are
> 24 CPUs as if hyperthreading was enabled.
>
> 6. Reboot and go to BIOS setup - it still shows that "Simultaneous
> multithreading" is set to "Disabled". Do not change anythig, just
> select "Save and Exit". Boot Debian and check the number of CPUs - it
> now shows 12 CPUs again.
>
> I have tested several kernel versions and it seems that this behavior
> appeared for the first time somewhere between 2.6.35.7 and 2.6.38.6
> versions (ok = does not show the decribed behavior, not ok = does
> show):
>
> * linux-image-2.6.32-5-amd64 official Debian - ok
> * linux-image-2.6.39-bpo.2-amd64 official Debian from backports - not
> ok
>
> * linux 2.6.35.7 - custom compiled from source - ok
> * linux 2.6.38.6 - custom compiled from source - not ok
> * linux 2.6.39.4 - custom compiled from source - not ok
> * linux 3.0.4 - custom compiled from source - not ok
That might be too large a range for developers to consider. Can you
test some versions between 2.6.35.7 and 2.6.38.6 (bisection)?
Ben.
> I have exchnged many e-mails with Supermicro distributor who
> apparently is in direct contact with Supermicro technicians. They more
> or less deny any responsibility for this problem and repeatedly point
> to the fact that some (older) kernels do not exhibit this behavior so
> it must be a kernel problem. Their representative writes:
>
> "I discussed this with supermicro and they informed me that the Kernel
> itself is causing the issue, that it may be sending the hyperthreading
> command code to the BIOS."
>
> Although I do not completely agree with their arguments, my knowledge
> is not deep enough to recognize where exactly the core of the problem
> is so I report this as a bug in a hope that someone will know what
> happens when a kernel turns a computer off and what has changed in
> kernel somewhere between the versions I mention above. I have asked
> Supermicro distributor for more information on what they think happens
> there and what exactly they mean by "hyperhreading command code" and I
> am waiting for their response.
>
> -- Package-specific info:
> ** Version:
> Linux version 2.6.39-bpo.2-amd64 (Debian 2.6.39-3~bpo60+1) (norbert@tretkowski.de) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Tue Jul 26 10:35:23 UTC 2011
[...]
> ** Model information
> sys_vendor: Supermicro
> product_name: X8DTT
> product_version: 1234567890
> chassis_vendor: Supermicro
> chassis_version: 1234567890
> bios_vendor: American Megatrends Inc.
> bios_version: 080016
> board_vendor: Supermicro
> board_name: X8DTT
> board_version: 2.0
[...]
--
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next parent reply other threads:[~2011-10-30 15:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20111030110543.5872.61279.reportbug@supermicro.uochb.cas.cz>
2011-10-30 15:25 ` Ben Hutchings [this message]
2011-10-31 13:06 ` CPU hyperthreading turned on after soft power-cycle Clarinet
2011-11-08 12:33 ` Jiri Polach
2011-11-10 1:52 ` Jonathan Nieder
2011-11-11 13:50 ` Clarinet
2011-11-16 22:49 ` Clarinet
2011-11-17 20:32 ` John Stultz
2011-11-17 23:42 ` Jiri Polach
2011-11-17 23:53 ` John Stultz
2011-11-21 13:27 ` Jiri Polach
2011-11-21 20:02 ` John Stultz
2011-11-21 21:31 ` Jiri Polach
2011-11-29 2:31 ` John Stultz
2011-11-29 12:26 ` Clarinet
2011-11-29 23:34 ` John Stultz
2011-12-02 10:44 ` Clarinet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1319988329.6759.88.camel@deadeye \
--to=ben@decadent.org.uk \
--cc=647095@bugs.debian.org \
--cc=clarinet@atlas.cz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox