All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	sfr@canb.auug.org.au, kernel list <linux-kernel@vger.kernel.org>,
	mingo@redhat.com, bp@alien8.de, hpa@zytor.com, x86@kernel.org
Subject: Re: -next20181010,1011 regression: thinkpad x60 (32 bit) dies during boot.
Date: Fri, 12 Oct 2018 12:52:54 +0200	[thread overview]
Message-ID: <20181012105254.GA114888@gmail.com> (raw)
In-Reply-To: <20181012102459.GA4469@amd>


* Pavel Machek <pavel@ucw.cz> wrote:

> Hi!
> 
> > > > > I updated to todays next... and boot crashes with
> > > > > 
> > > > > ..
> > > > > Call Trace:
> > > > > kick_ilb
> > > > > trigger_load_balance
> > > > > ? active_load..
> > > > > scheduler_tick
> > > > > update_process_times
> > > > > tick_nohz_handler
> > > > > 
> > > > > -next20181005 worked ok.
> > > 
> > > Problem is still there in today's next.
> > 
> > So what came in between -next20181005 and the first bad one? kernel/sched/*
> > being the first place to look at.
> 
> kernel/sched does not seem to contain anything too scary.
> 
> I know that -next20181005 works ok, and I know -next20181010 is
> bad. Is there easy way to bisect using that information? I can do
> bisect between -next and mainline, but that's a lot of patches and
> thus not much fun :-(.
> 
> In the meantime, I reproduced the failure with T40p. Is there someone
> with working x86-32 in -next?

Does latest -tip fail too? If yes then I suspect bisection would be needed.

Thanks,

	Ingo

  reply	other threads:[~2018-10-12 10:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10 19:59 -next20181010 regression: thinkpad x60 (32 bit) dies during boot Pavel Machek
2018-10-10 20:03 ` Pavel Machek
2018-10-11 18:03   ` -next20181010,1011 " Pavel Machek
2018-10-11 20:09     ` Thomas Gleixner
2018-10-12 10:24       ` Pavel Machek
2018-10-12 10:52         ` Ingo Molnar [this message]
2018-10-12 12:35           ` Pavel Machek
2018-10-12 18:10           ` Avoid VLA in pgd_alloc kills boot on 32-bit machines was " Pavel Machek
2018-10-12 18:13             ` Borislav Petkov
2018-10-12 18:57               ` Pavel Machek
2018-10-12 18:22             ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181012105254.GA114888@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=sfr@canb.auug.org.au \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.