v4.11-rc1 boot time regression

v4.11-rc1 boot time regression

[Andy Shevchenko]

+Cc: Felipe and missed LKML

On Tue, Mar 7, 2017 at 9:02 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> Hi!
>
> Frankly don't know whom to blame (maybe even me). That's why a list in
> To is kinda (semi-) random.
>
> I have two branches on my Github:
>
> https://github.com/andy-shev/linux/tree/eds-v4.10
> https://github.com/andy-shev/linux/tree/eds (previous one simple
> rebased to v4.11-rc1)
>
> First one boots nicely all over the time:
> (Important piece of dmesg):
> [ 0.815277] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [ 0.815449] initcall init_sunrpc+0x0/0x64 returned 0 after 1952 usecs
> [    0.815619] calling  pci_apply_final_quirks+0x0/0x107 @ 1
> [    1.166511] PCI: CLS 0 bytes, default 64
> [    1.166632] initcall pci_apply_final_quirks+0x0/0x107 returned 0
> after 318310 usecs
> [    1.166829] calling  acpi_reserve_resources+0x0/0xeb @ 1
> [    1.166973] initcall acpi_reserve_resources+0x0/0xeb returned 0 after 0 usecs
> [    1.167156] calling  populate_rootfs+0x0/0x108 @ 1
> [    1.168072] Unpacking initramfs...
> [   13.340003] Initramfs unpacking failed: junk in compressed archive
> [   13.357556] Freeing initrd memory: 20480K
>
> Second one is unstable (*), but in any case I got the following:
> [    0.639836] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    0.640008] initcall init_sunrpc+0x0/0x64 returned 0 after 0 usecs
> [    0.640173] calling  pci_apply_final_quirks+0x0/0x107 @ 1
> [   61.005995] PCI: CLS 0 bytes, default 64
> [   61.006126] initcall pci_apply_final_quirks+0x0/0x107 returned 0
> after 316 usecs
> [   61.006321] calling  acpi_reserve_resources+0x0/0xeb @ 1
> [   61.006464] initcall acpi_reserve_resources+0x0/0xeb returned 0 after 0 usecs
> [   61.006647] calling  populate_rootfs+0x0/0x10d @ 1
> [   61.007528] Unpacking initramfs...
> [   73.025201] Initramfs unpacking failed: junk in compressed archive
> [   73.041819] Freeing initrd memory: 20480K
>
> 60 seconds of wait for what exactly? I have no clue right now. Any suggestions?
>
> (*) It was a bit hard to get v4.11-rc1 eventually load (looks like
> boot time was long enough to get watchdog fired, i.e. 90+ seconds).
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
With Best Regards,
Andy Shevchenko

Re: v4.11-rc1 boot time regression

[Andy Shevchenko]

On Wed, Mar 8, 2017 at 10:26 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 7 Mar 2017, Andy Shevchenko wrote:
>> On Tue, Mar 7, 2017 at 9:21 PM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>> > On Tue, Mar 7, 2017 at 11:02 AM, Andy Shevchenko
>> > <andy.shevchenko@gmail.com> wrote:
>> >>
>> >> 60 seconds of wait for what exactly? I have no clue right now. Any suggestions?
>> >
>> > Ugh. If it is something that is actively sleeping, sysrq-t during the
>> > pause might give a hint.
>>
>> Unfortunately seems I can't do this. I managed to disable watchdog in
>> U-Boot, but seems console is not yet switched to the driver my blind
>> key presses went nowhere.
>>
>> > But it could be just a timer thing with nobody actively waiting for
>> > it, just a general init completion thing, and then it wouldn't show up
>> > as a thread with a backtrace. In that case you might need to bisect
>> > it..
>>
>> Looks like it's the only way if 60 seconds doesn't ring a bell to anyone...
>> Anyway, now (as you know :-) ) quite late in Hki, have to give my body
>> a bit of sleep.
>
> A shot in the dark:
>
> Could you try Linus head first, especially commit:
>
> fa3aa7a54fe6 ("jiffies: Revert bogus conversion of NSEC_PER_SEC to TICK_NSEC")
>
> which fixes: 93825f2ec736 ("jiffies: Reuse TICK_NSEC instead of NSEC_PER_JIFFY")

Thomas, you are cool! That is the one. Thanks!

-- 
With Best Regards,
Andy Shevchenko