All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.