From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933901AbdBVWt1 (ORCPT ); Wed, 22 Feb 2017 17:49:27 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:59693 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933051AbdBVWtU (ORCPT ); Wed, 22 Feb 2017 17:49:20 -0500 Date: Wed, 22 Feb 2017 23:47:55 +0100 From: Pavel Machek To: Josh Poimboeuf 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: <20170222224755.GA4310@amd> References: <20170221221418.GA6918@amd> <20170221231216.y56gb62vkn5ewgea@treble> <20170222210548.GC8467@amd> <20170222212103.tigzbw5sfrwd7uwh@treble> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20170222212103.tigzbw5sfrwd7uwh@treble> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > > > Thinkpad X220, in 32 bit mode... and I'm getting rather scary messa= ges > > > > from kernel during boot: > > > >=20 > > > > Git blame says that message comes from commit > > > >=20 > > > > commit 24d86f59093b0bcb3756cdf47f2db10ff4e90dbb > > > > Author: Josh Poimboeuf > > > > Date: Thu Oct 27 08:10:58 2016 -0500 > > > >=20 > > > > x86/unwind: Ensure stack grows down > > > >=20 > > > > Add a sanity check to ensure the stack only grows down, and pri= nt > > > > a > > > > warning if the check fails. > > > >=20 > > > > Any ideas? > > >=20 > > > I don't think I've seen this one. Any chance this came after resuming > > > from a hibernation or suspend? > >=20 > > No, it was during the boot. Notice the timestamps... >=20 > 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: >=20 > > > > [ 1.048429] f50cdf9c: 00000000c4000237 (startup_32_smp+0x16b/0x1= 6d) > > > > [ 1.048429] f50cdfa0: 0000000000200002 (0x200002) > > > > [ 1.048430] f50cdfa4: 0000000000000000 ... > > > > [ 1.048432] f50cdfa8: 00000000c4000237 (startup_32_smp+0x16b/0x1= 6d) > > > > [ 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 >=20 > 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? And .... startup_32_smp is kind of "interesting" function. Take a look... Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAliuFRsACgkQMOfwapXb+vJI1gCbB1m1qRG/hBJAW4jh6+FHMH3u CdEAoKwQbf7H4KOcli8LmhOsn/9vptfe =6zn+ -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4--