public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Clarinet <clarinet@atlas.cz>
Cc: 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 15:34:13 -0800	[thread overview]
Message-ID: <1322609653.21423.46.camel@work-vm> (raw)
In-Reply-To: <4ED4CF7C.8020808@atlas.cz>

On Tue, 2011-11-29 at 13:26 +0100, Clarinet wrote:
> > 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.

Ok, this also confirms that the board had issues *before* any changes
were made to the RTC core. I'd push the board vendor to update the BIOS
to avoid this issue.

Even so, I'm curious as to what exactly trips it up. Maybe we can
provide a module option for the rtc-cmos driver to disable the alarm
functionality, so you can at least avoid the issue until the board
vendor fixes the problem (if ever).

Assuming its the alarm being set, could you try the following on a
current kernel and let me know if it still shows the problem? hwclock
might throw some odd messages with this test patch, but those can be
ignored.

thanks
-john

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 05beb6c..d9814aa 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -305,8 +305,8 @@ static void cmos_irq_enable(struct cmos_rtc *cmos, unsigned char mask)
 	cmos_checkintr(cmos, rtc_control);
 
 	rtc_control |= mask;
-	CMOS_WRITE(rtc_control, RTC_CONTROL);
-	hpet_set_rtc_irq_bit(mask);
+//	CMOS_WRITE(rtc_control, RTC_CONTROL);
+//	hpet_set_rtc_irq_bit(mask);
 
 	cmos_checkintr(cmos, rtc_control);
 }





  reply	other threads:[~2011-11-29 23:34 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
2011-11-29 23:34                             ` John Stultz [this message]
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=1322609653.21423.46.camel@work-vm \
    --to=john.stultz@linaro.org \
    --cc=647095@bugs.debian.org \
    --cc=ben@decadent.org.uk \
    --cc=clarinet@atlas.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox