On Fri, May 31, 2013 at 05:16:49PM -0700, John Stultz wrote: > On 05/31/2013 04:42 PM, Jens Taprogge wrote: > >On Fri, May 31, 2013 at 02:14:47PM -0700, John Stultz wrote: > >>On 05/31/2013 05:06 AM, Jens Taprogge wrote: > >>>So, in the case of the reverted v3.9.4 with CONFIG_CPU_FREQ_STAT=y, > >>>CONFIG_X86_VERBOSE_BOOTUP makes a difference. To update the little > >>>table from above: > >>> > >>>With d96ac6f2 reverted: > >>> > >>> CONFIG_CPU_FREQ_STAT=n works > >>> CONFIG_CPU_FREQ_STAT=y and CONFIG_X86_VERBOSE_BOOTUP=y does not work > >>> CONFIG_CPU_FREQ_STAT=y and CONFIG_X86_VERBOSE_BOOTUP=n works > >>Ok. None of this is yet making any sense to me. (And I worry > >>enumerating all the mix and match of configs that work or don't only > >>blurs the issues). > >> > >>Few base questions: > >>1) What distro is this on? > >arch linux > > > >>2) What gcc version are you using? > >gcc (GCC) 4.8.0 20130502 (prerelease) > > (Sorry, I'm not very familiar with arch) Are you able to also > install a 4.7 gcc in parallel to try to build with? > > If so, you might want to try that. Your results are just weird > enough I want to just be sure we're not chasing compiler caused > ghosts. I will compile gcc4.6 and see if using that makes any difference. > > >>3) Apply persistent-clock-exists-true.patch, does it boot or hang? > >> > >>4) Apply has-persistent-clock-true.patch (on top of > >>persistent-clock-exists-true.patch), does it boot or hang? > >Either patch alone or both combined boot. From quick testin they seem > >to follow the same pattern as the reverted version. > > Hrmm.. That's strange too. I was guessing the first patch wouldn't > boot, but maybe that's a helpful clue. > > Attached is another patch that just provides debug info. > > If you'd apply it (jdb.patch) against v3.9.4 with no other > modifications, to verify that still doesn't boot. This does not boot. > > Then apply just persistent-clock-exists-true.patch, which should > boot, and send me the output of: > $ dmesg | grep JDB This does not boot either. Applying both patches in addition to the new one leads to a kernel that boots. I double checked and persistent-clock-exists-true.patch by itself still boots. The output with all three patches applied is: [ 0.000000] JDB: efi_runtime_init() done [ 0.000000] JDB: mach_get_cmos_time: 1370098547 [ 0.000000] JDB: timekeeping_init: Persistent clock time: 1370098547:0 > > > Thanks so much again for all the testing and help hunting this down! > Sorry for the trouble! > -john No worries. -jens -- 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