All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
	Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org
Subject: [v4.12-rc3] Early boot panic on Broadwell
Date: Thu, 1 Jun 2017 09:27:44 +0100	[thread overview]
Message-ID: <20170601082744.GD23936@nuc-i3427.alporthouse.com> (raw)

Hi guys,

I hit an early boot panic on a Broadwell laptop (xps13-9343) that I
bisected to:

commit cbed27cdf0e3f7ea3b2259e86b9e34df02be3fe4
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Apr 18 15:07:11 2017 -0400

    x86/PAT: Fix Xorg regression on CPUs that don't support PAT
    
    In the file arch/x86/mm/pat.c, there's a '__pat_enabled' variable. The
    variable is set to 1 by default and the function pat_init() sets
    __pat_enabled to 0 if the CPU doesn't support PAT.
    
    However, on AMD K6-3 CPUs, the processor initialization code never calls
    pat_init() and so __pat_enabled stays 1 and the function pat_enabled()
    returns true, even though the K6-3 CPU doesn't support PAT.
    
    The result of this bug is that a kernel warning is produced when attempting to
    start the Xserver and the Xserver doesn't start (fork() returns ENOMEM).
    Another symptom of this bug is that the framebuffer driver doesn't set the
    K6-3 MTRR registers:
    
      x86/PAT: Xorg:3891 map pfn expected mapping type uncached-minus for [mem 0xe4000000-0xe5ffffff], got write-combining
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 3891 at arch/x86/mm/pat.c:1020 untrack_pfn+0x5c/0x9f
      ...
      x86/PAT: Xorg:3891 map pfn expected mapping type uncached-minus for [mem 0xe4000000-0xe5ffffff], got write-combining
    
    To fix the bug change pat_enabled() so that it returns true only if PAT
    initialization was actually done.
    
    Also, I changed boot_cpu_has(X86_FEATURE_PAT) to
    this_cpu_has(X86_FEATURE_PAT) in pat_ap_init(), so that we check the PAT
    feature on the processor that is being initialized.

In my testing, I found that reverting the /boot_cpu_has/this_cpu_has/
change was enough to restore working behaviour:

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 83a59a6..c537bfb 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -234,7 +234,7 @@ static void pat_bsp_init(u64 pat)
 
 static void pat_ap_init(u64 pat)
 {
-       if (!this_cpu_has(X86_FEATURE_PAT)) {
+       if (!boot_cpu_has(X86_FEATURE_PAT)) {
                /*
                 * If this happens we are on a secondary CPU, but switched to
                 * PAT on the boot CPU. We have no way to undo PAT.

Seems scary enough that different cpus may have different features, but
that may just be a symptom of the boot phase?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

             reply	other threads:[~2017-06-01  8:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01  8:27 Chris Wilson [this message]
2017-06-01 17:12 ` [v4.12-rc3] Early boot panic on Broadwell Linus Torvalds
2017-06-02  5:28   ` Ingo Molnar

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=20170601082744.GD23936@nuc-i3427.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.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.