From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932071AbdBVDJM (ORCPT ); Tue, 21 Feb 2017 22:09:12 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:36453 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751271AbdBVDJC (ORCPT ); Tue, 21 Feb 2017 22:09:02 -0500 Date: Wed, 22 Feb 2017 04:08:58 +0100 From: Frederic Weisbecker To: Pavel Machek Cc: Thomas Gleixner , wanpeng.li@hotmail.com, Peter Zijlstra , Rik van Riel , Linux Kernel Mailing List 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 Message-ID: <20170222030857.GB2780@lerouge> References: <20170216181353.GB4357@lerouge> <20170216183421.GC4357@lerouge> <20170217140449.GA4521@lerouge> <20170217170508.GA20884@amd> <20170217184327.GD4521@lerouge> <20170218093917.GA4722@amd> <20170218102339.GA3544@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170218102339.GA3544@amd> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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!