On Wed, Feb 22, 2017 at 10:05:48PM +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 <jpoim...@redhat.com> > > > 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? > > > > Hi Pavel, > > > > 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? 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. -- Josh
