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: Thu, 17 Nov 2011 12:32:26 -0800 [thread overview]
Message-ID: <1321561946.25715.16.camel@work-vm> (raw)
In-Reply-To: <4EC43DF7.4010902@atlas.cz>
On Wed, 2011-11-16 at 23:49 +0100, Clarinet wrote:
> Hi all,
>
> >> Result of bisecting: v2.6.38-rc1 exhibits the problem. v2.6.37 and
> >> many of the topic branches merged in the 2.6.38 merge window work ok.
> >> Some other topic branches do not boot at all.
> >>
> >> Jiri: if you have gitk installed, then "git bisect visualize" can help
> >> get a sense of what's in the middle of the regression range.
> >> "gitk --bisect --first-parent v2.6.37..v2.6.38-rc1" might be a good way
> >> to find mainline commits to test before finding a topic branch to delve
> >> into.
> >
> > I have been able to narrow the interval manually a little bit from the
> > "top" (the bad side) and I will go on from the bottom now. However,
> > there seems to be a large area where kernels are unbootable for me -
> > they mostly stop when init is called and I do not know why.
>
> 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
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?
Could you also send your .config to me?
thanks
-john
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 5856167..d049344 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -497,13 +497,13 @@ static int cmos_procfs(struct device *dev, struct seq_file *seq)
static const struct rtc_class_ops cmos_rtc_ops = {
.read_time = cmos_read_time,
.set_time = cmos_set_time,
- .read_alarm = cmos_read_alarm,
- .set_alarm = cmos_set_alarm,
- .proc = cmos_procfs,
- .irq_set_freq = cmos_irq_set_freq,
- .irq_set_state = cmos_irq_set_state,
- .alarm_irq_enable = cmos_alarm_irq_enable,
- .update_irq_enable = cmos_update_irq_enable,
+// .read_alarm = cmos_read_alarm,
+// .set_alarm = cmos_set_alarm,
+// .proc = cmos_procfs,
+// .irq_set_freq = cmos_irq_set_freq,
+// .irq_set_state = cmos_irq_set_state,
+// .alarm_irq_enable = cmos_alarm_irq_enable,
+// .update_irq_enable = cmos_update_irq_enable,
};
/*----------------------------------------------------------------*/
next prev parent reply other threads:[~2011-11-17 20:33 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 [this message]
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
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=1321561946.25715.16.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;
as well as URLs for NNTP newsgroup(s).