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) > Then could you also try the attached patches against un-modified > v3.9.4 (using a config that boots with d96ac6f2 reverted): This is not quite possible since the changed Kconfig files for different configurations. I have used config3.9.4_broken2.gz which comes down to the same settings. > 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. > These two patches basically partially revert the d96ac6f2. The hope > is that by figuring out where things go wrong, we can hopefully > narrow down why its happening. > > Though given the strange config matrix of working/not working, I'm > starting to suspect that is has some sort of stranger issue about > code size rather then strictly the logic being enabled or disabled. I have been wondering about that or some timing issue as well. Best Regards, Jens
Attachment:
config3.9.4_broken2.gz
Description: Binary data