On Sun, 2011-10-30 at 07:05 -0400, Jiri Polach wrote:Package: linux-2.6
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
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
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 188.8.131.52 and 184.108.40.206
versions (ok = does not show the decribed behavior, not ok = does
* linux-image-2.6.32-5-amd64 official Debian - ok
* linux-image-2.6.39-bpo.2-amd64 official Debian from backports - not
* linux 220.127.116.11 - custom compiled from source - ok
* linux 18.104.22.168 - custom compiled from source - not ok
* linux 22.214.171.124 - 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 126.96.36.199 and 188.8.131.52 (bisection)?
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:
Linux version 2.6.39-bpo.2-amd64 (Debian 2.6.39-3~bpo60+1) (norbert@xxxxxxxxxxxxx) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Tue Jul 26 10:35:23 UTC 2011
** Model information[...]
bios_vendor: American Megatrends Inc.