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) > (norb...@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
signature.asc
Description: This is a digitally signed message part
