From: Clarinet <clarinet@atlas.cz>
To: John Stultz <john.stultz@linaro.org>
Cc: Jiri Polach <clarinet@atlas.cz>,
647095@bugs.debian.org, Jonathan Nieder <jrnieder@gmail.com>,
Ben Hutchings <ben@decadent.org.uk>,
LKML <linux-kernel@vger.kernel.org>,
x86@kernel.org
Subject: Re: CPU hyperthreading turned on after soft power-cycle
Date: Tue, 29 Nov 2011 13:26:36 +0100 [thread overview]
Message-ID: <4ED4CF7C.8020808@atlas.cz> (raw)
In-Reply-To: <1322533915.24090.69.camel@work-vm>
> Using an older "known-good" kernel, could you build and run the test
> case at the end of Documentation/rtc.txt a few times and see if it
> triggers the same problem?
>
> I'm suspicious that the setting the alarm is whats tripping the BIOS
> into enabling the HT bit. Because with older kernels, we used PIE mode
> irqs which hwclock usually uses at boot, but with newer kernels, we
> emulate PIE via AIE alarm mode. So if the BIOS was broken before, you
> wouldn't have noticed unless you tried to use AIE irqs.
>
> If this doesn't work, I'll get some patches to both 2.6.27 and 2.6.28
> kernels to debug the exact flow of how we're touching the hardware and
> then we can further narrow it down.
I ran the tests the following way:
- boot 2.6.37.6 - check /proc/cpuinfo - 12 processors
- halt
- boot 2.6.37.6 - check /proc/cpuinfo - 12 processors
- run rtctest
- reboot
- boot 2.6.37.6 - check /proc/cpuinfo - 12 processors
- halt
- boot 2.6.37.6 - check /proc/cpuinfo - 12 processors
- run rtctest
- halt
- boot 2.6.37.6 - check /proc/cpuinfo - 24 processors
So the conclusion is that only if rtctest is run and the machine is
halted, it triggers the HT problem. Reboot seems to "neutralize"
whatever rtctest did.
Jiri
next prev parent reply other threads:[~2011-11-29 12:26 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 ` CPU hyperthreading turned on after soft power-cycle Ben Hutchings
2011-10-31 13:06 ` 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 [this message]
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=4ED4CF7C.8020808@atlas.cz \
--to=clarinet@atlas.cz \
--cc=647095@bugs.debian.org \
--cc=ben@decadent.org.uk \
--cc=john.stultz@linaro.org \
--cc=jrnieder@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.