Messages in this thread | | | Date | Fri, 18 Nov 2011 00:42:06 +0100 | From | Jiri Polach <> | Subject | Re: CPU hyperthreading turned on after soft power-cycle |
| |
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, > }; > > /*----------------------------------------------------------------*/
[unhandled content-type:application/gzip] | |