linux-kernel - Re: next_tick hang was Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170222030857.GB2780@lerouge>
Date:   Wed, 22 Feb 2017 04:08:58 +0100
From:   Frederic Weisbecker <fweisbec@...il.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Thomas Gleixner <tglx@...utronix.de>, wanpeng.li@...mail.com,
        Peter Zijlstra <peterz@...radead.org>,
        Rik van Riel <riel@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: next_tick hang was Re: v4.10-rc8 (-rc6) boot regression on Intel
 desktop, does not boot after cold boots, boots after reboot

On Sat, Feb 18, 2017 at 11:23:39AM +0100, Pavel Machek wrote:
> On Sat 2017-02-18 10:39:17, Pavel Machek wrote:
> > Hi!
> > 
> > [I droped some CCs here, you may want to check the CC list].
> > 
> > > > These are different bugs.
> > > > 
> > > > On x60, I see failures doing hotplug/unplug in a loop, or lot of
> > > > suspends. Someone seen it in v4.8-stable etc. Old bug. Rare to hit.
> > > > 
> > > > Desktop machine was failing to boot, and had some fun with
> > > > suspend/resume too. Boot hang was reproducible with right
> > > > procedure. (Hard poweroff, cold boot.). That one was introduced in
> > > > 4.10-rc cycle.
> > > 
> > > Pavel, is there any chance you could apply this patch on top of latest linus tree
> > > and send me your resulting dmesg log? This has the two reverted patches plus some
> > > debugging code. The amount of printk shouldn't be too big, I tested it home without
> > > issue.
> > > 
> > > If you can't manage to dump the dmesg, please try to take a picture of your screen
> > > so that I can see the last messages starting with "NEXT_TICK_READ".
> > > 
> > > Thanks!
> > 
> > I guess I can. But I'll only have one 80x25 screen to look at...
> 
> Ok, here it is.

Thanks, I haven't been able to deduce much though, except that the pending timer on CPU 0
looks quite far away.

Could you please add "initcall_debug" in your kernel parameters to identify if we are blocking in
a specific initcall? If so it should tell us which one.

Thanks!