From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934031AbdBVXTh (ORCPT ); Wed, 22 Feb 2017 18:19:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41050 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933793AbdBVXTa (ORCPT ); Wed, 22 Feb 2017 18:19:30 -0500 Date: Wed, 22 Feb 2017 17:18:08 -0600 From: Josh Poimboeuf To: Pavel Machek Cc: kernel list , mingo@kernel.org, luto@kernel.org, bp@alien8.de, brgerst@gmail.com, dvlasenk@redhat.com, hpa@zytor.com, torvalds@linux-foundation.org, peterz@infradead.org, tglx@linutronix.de Subject: Re: v4.10: kernel stack frame pointer .. has bad value (null) Message-ID: <20170222231808.hmr6ulbvfnrg2at7@treble> References: <20170221221418.GA6918@amd> <20170221231216.y56gb62vkn5ewgea@treble> <20170222210548.GC8467@amd> <20170222212103.tigzbw5sfrwd7uwh@treble> <20170222224755.GA4310@amd> <20170222225614.4z4z24uz6l2iz6qm@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170222225614.4z4z24uz6l2iz6qm@treble> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 22 Feb 2017 23:18:11 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 22, 2017 at 04:56:14PM -0600, Josh Poimboeuf wrote: > On Wed, Feb 22, 2017 at 11:47:55PM +0100, Pavel Machek wrote: > > Hi! > > > > > > > > Thinkpad X220, in 32 bit mode... and I'm getting rather scary messages > > > > > > from kernel during boot: > > > > > > > > > > > > Git blame says that message comes from commit > > > > > > > > > > > > commit 24d86f59093b0bcb3756cdf47f2db10ff4e90dbb > > > > > > Author: Josh Poimboeuf > > > > > > Date: Thu Oct 27 08:10:58 2016 -0500 > > > > > > > > > > > > x86/unwind: Ensure stack grows down > > > > > > > > > > > > Add a sanity check to ensure the stack only grows down, and print > > > > > > a > > > > > > warning if the check fails. > > > > > > > > > > > > Any ideas? > > > > > > > > > > I don't think I've seen this one. Any chance this came after resuming > > > > > from a hibernation or suspend? > > > > > > > > No, it was during the boot. Notice the timestamps... > > > > > > Right, but doesn't waking from hibernation initially start with a > > > timestamp of zero? > > > > Aha, ok, I guess so. Anyway... no hibernation was involved. > > > > > The reason I asked is because of the following part of the stack > > > dump: > > > > > > > > > > > [ 1.048429] f50cdf9c: 00000000c4000237 (startup_32_smp+0x16b/0x16d) > > > > > > [ 1.048429] f50cdfa0: 0000000000200002 (0x200002) > > > > > > [ 1.048430] f50cdfa4: 0000000000000000 ... > > > > > > [ 1.048432] f50cdfa8: 00000000c4000237 (startup_32_smp+0x16b/0x16d) > > > > > > [ 1.048432] f50cdfac: 0000000000000000 ... > > > > > > [ 1.048433] f50cdff4: 0000000000000100 (0x100) > > > > > > [ 1.048434] f50cdff8: 0000000000000200 (0x200) > > > > > > [ 1.048435] f50cdffc: 0000000000000000 ... > > > > > > [ 1.060368] [drm] Supports vblank timestamp caching Rev 2 > > > > > > Somehow, startup_32_smp() is on the stack twice. The stack unwind led > > > to the startup_32_smp() frame at 0xf50cdf9c rather than the one at > > > 0xf50cdfa8 (which is where it should normally be). So the question is > > > how startup_32_smp() got executed the second time, with the wrong stack > > > offset. > > > > Not much idea... but this is stack dump, right? Just because some > > value is on the stack does not mean it is a return address, no? > > Right, but the one at 0xf50cdfa8 is where the startup_32_smp() is > *supposed* to be. If the unwinder had unwinded to that one, it wouldn't > have complained. So it looks to me like the CPU somehow booted twice: > the first time at the right stack address, and the second time it > somehow ended up with a different stack address. > > > And .... startup_32_smp is kind of "interesting" function. Take a > > look... > > Yes, it's used in bringing up the CPU. Can you share your .config? -- Josh