On 05/29/2013 01:41 PM, Jens Taprogge wrote:
On Tue, May 28, 2013 at 12:51:19PM -0700, John Stultz wrote:
On 05/26/2013 12:25 PM, Jens Taprogge wrote:
Hi all.
Linux 3.9.3 hangs early during boot on a Lenovo Thinkpad X1 Carbon (Ivy
Bridge). v3.9.2 works. I have bisected the hang to
d96ac6f2: time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons.
Reverting d96ac6f2 on top of v3.9.4 makes the kernel boot. I do not
have any additional information as the kernel hangs before anything is
displayed. The config of v3.9.4 with d96ac6f2 reverted is attached.
So with 3.9.4 (nothing reverted), what was the config you were using
to boot?
Does changing CONFIG_RTC_HCTOSYS change the behavior?
thanks
-john
Hello John,
turns out things behave quite differently with the patch reverted and
not reverted. Since there is no output, I can not tell whether I am
seeing one or two problems.
With vanilla 3.9.4:
CONFIG_RTC_HCTOSYS=y works
CONFIG_RTC_HCTOSYS=n does not work
Huh. Strange, I actually was expecting the opposite.
The odd thing is, commit d96ac6f2 *allows* HCTOSYS=y to be set. In other
words, without that patch, HCTOSYS is always N.
So its weird HCTOSYS=y works, but also reverting the patch (which forces
HCTOSYS=N) works.
Still stranger, option really shouldn't change much in early boot.
HCTOSYS driver triggers as a late_initcall, so I'd expect you'd get some
output before hitting trouble.
CONFIG_CPU_FREQ_STAT has no effect
With d96ac6f2 reverted:
CONFIG_CPU_FREQ_STAT=n works
CONFIG_CPU_FREQ_STAT=y does not work
Please see several configurations attached.
Hrm.. I do wonder if we're seeing something else going on here.
I'll keep digging here, and probably send you some debug patches tomorrow.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html