From: John Stultz <john.stultz@linaro.org>
To: Jiri Polach <jiri.polach@seznam.cz>
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: Mon, 21 Nov 2011 12:02:08 -0800 [thread overview]
Message-ID: <1321905728.6445.2.camel@work-vm> (raw)
In-Reply-To: <4ECA51B9.3010707@seznam.cz>
On Mon, 2011-11-21 at 14:27 +0100, Jiri Polach wrote:
> >>>> Finally! After another 50+ compilations a have it! It took some time as
> >>>> first I had to find a reason why some revisions did not boot (almost 2/3
> >>>> were unbootable and the first bad commit was among them). Having this
> >>>> solved I have been able to bisect without "skipping". The result is
> >>>> surprising (at least for me) - believe it or not, the first bad commit
> >>>> is 6610e089 "RTC: Rework RTC code to use timerqueue for events" from
> >>>> John Stultz (I am sending him a copy of this message).
> >>>>
> >>>> I would never expect this would be a problem, but my understanding of
> >>>> this commit is very limited, so I am certainly missing the point.
> >>>> However, I have tried to compile 2.6.38 (which was "bad") with "Real
> >>>> Time Clock" configuration option turned off and it behaves "normally"
> >>>> then (= is "good").
> >>>
> >>> Huh. That's *very* odd. Is your system doing anything in-particular
> >>> with the RTC? I don't have a clue right off, so probably the next step
> >>
> >> Yes, it is very odd. The system does not do anything special with RTC.
> >> It is a diskless computational workstation.
> >>
> >>> is doing a bit of instrumentation to try to figure out where exactly we
> >>> trigger the behavior. Could you checkout commit 6610e089 and apply the
> >>> patch below to see if we can't narrow it down?
> >>
> >> With the patch applied the system does not show the strange behavior (=
> >> is "good").
> >>
> >>> Could you also send your .config to me?
> >>
> >> Sure. It is attached. I have found that if I turn CONFIG_RTC_DRV_CMOS
> >> off, the system behaves normally (= is "good") too.
> >
> > Yea. My rough guess is that the BIOS is somehow sensitive to how the
> > CMOS RTC is touched.
> >
> > Does disabling CONFIG_HPET_EMULATE_RTC change the behavior?
>
> But how do I do it? :-)
>
> I have not found a way to disable it in "menuconfig". If I comment it
> out manually in .config, it is automatically set back to "y" as soon as
> compilation starts ...
Good point. I forgot on x86_64 you can't disable HPET_TIMER.
Could you then use the following patch (and run make oldconfig before
building).
thanks
-john
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cb9a104..77b5273 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -640,7 +640,7 @@ config HPET_TIMER
Choose N to continue using the legacy 8254 timer.
config HPET_EMULATE_RTC
- def_bool y
+ def_bool n
depends on HPET_TIMER && (RTC=y || RTC=m || RTC_DRV_CMOS=m || RTC_DRV_CMOS=y)
config APB_TIMER
next prev parent reply other threads:[~2011-11-21 20:03 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 [this message]
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
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=1321905728.6445.2.camel@work-vm \
--to=john.stultz@linaro.org \
--cc=647095@bugs.debian.org \
--cc=ben@decadent.org.uk \
--cc=clarinet@atlas.cz \
--cc=jiri.polach@seznam.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 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.