On 11/17/2011 9:32 PM, John Stultz wrote:
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
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.
Thank you. Jiri Polach
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,
};
/*----------------------------------------------------------------*/
Attachment:
.config.gz
Description: application/gzip