From: "Bruno Prémont" <bonbons@linux-vserver.org>
To: Andreas Noever <andreas.noever@gmail.com>,
Bjorn Helgaas <bhelgaas@google.com>
Cc: DRI mailing list <dri-devel@lists.freedesktop.org>,
Linux PCI <linux-pci@vger.kernel.org>,
Dave Airlie <airlied@linux.ie>,
Matthew Garrett <matthew.garrett@nebula.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
Date: Thu, 21 Aug 2014 23:34:35 +0200 [thread overview]
Message-ID: <20140821233435.19a9cffa@neptune.home> (raw)
In-Reply-To: <CAMxnaaUodONkqmdPWedN-Q1qheHiJAScFcG_XbX1--ZmiOQZDg@mail.gmail.com>
On Thu, 21 August 2014 Andreas Noever <andreas.noever@gmail.com> wrote:
> dmesg with your patches and vga_set_default_device commented out
> (after "vgaarb: Boot video device...") as otherwise the system won't
> boot.
Do you know more precisely where your system hangs when it does not boot?
That's the part I can't find in this thread.
Is it dead-locking/freezing or just booting without displaying anything
(though network coming up if connected, keyboard working (e.g. caps key).
Try blacklisting both i915 and nouveau modules (and each one individually)
an see how far your system gets. Also make sure your network comes up
automatically, so that even if display remains black you can check via
network if your system is alive and what it complains about.
> dmesg | grep vgaarb
> [ 1.340118] vgaarb: PCI:0000:00:02.0 PCI_COMMAND=0007
> [ 1.340119] vgaarb: Boot video device: PCI:0000:00:02.0
> [ 1.340120] vgaarb: device added:
> PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
> [ 1.340130] vgaarb: PCI:0000:01:00.0 PCI_COMMAND=0006
> [ 1.340132] vgaarb: PCI:0000:01:00.0, bridge PCI:0000:00:01.0
> PCI_BRIDGE_CONTROL=0000
> [ 1.340133] vgaarb: device added:
> PCI:0000:01:00.0,decodes=io+mem,owns=none,locks=none
> [ 1.340135] vgaarb: loaded
> [ 1.340136] vgaarb: bridge control possible 0000:01:00.0
> [ 1.340136] vgaarb: no bridge control possible 0000:00:02.0
> [ 3.798430] vgaarb: device changed decodes:
> PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
>
>
> If the line is not commented out then vgaarb simply declares the first
> (enabled) device to be the default one, which is incorrect. And the
> overwrite logic in pci_fixup_video is not triggered, since a default
> device has already been set.
The initial selection I am doing does match the PCI_COMMAND flags
as set for the devices (or masked by parent bridge), but probably none
of them has active legacy VGA I/O ports.
So the question would rather be how to determine which I/O port is active
for the Intel graphics and adjust vgaarb's "decodes"/owns interpretation
on that basis (there is no I/O active for the nvidia one).
I'm thinking about selecting only device that decodes the legacy VGA I/O
range and not those with any some other I/O range.
The short-term fix probably is to just unconditionally perform the
screen_info check in pci_fixup_video() while leaving vgaarb's initial
card selection alone for legacy hardware. Thus replicating efifb's
original behavior (and also get back incorrect ROM_SHADOW flagging).
Corresponding patch below (on top of both patches in this series, but
should apply without them as well). As mentioned in the patch this
papers over the real issue.
A second step would then be to tune vgaarb's initial selection.
Bjorn, is it possible to verify which I/O ports are decoded by a PCI
device at the time of adding it to vgaarb? If so, how? I would like to
check for legacy VGA I/O range (0x03B0-0x03DF) and only let vgaarb set
a device as default if that I/O range is decoded by the device.
Bruno
> On Wed, Aug 20, 2014 at 9:11 AM, Bruno Prémont wrote:
> > On Wed, 20 Aug 2014 07:55:08 +0200 Bruno Prémont wrote:
> >> On Tue, 19 Aug 2014 17:45:00 +0200 Andreas Noever wrote:
> >> > On Sat, Aug 16, 2014 at 7:21 PM, Bruno Prémont wrote:
> >> > > This series improves on commit 20cde694027e (x86, ia64: Move EFI_FB
> >> > > vga_default_device() initialization to pci_vga_fixup()):
> >> > > - cleanup remaining but always-true #ifndefs
> >> > > - fix boot regression on dual-GPU Macs
> >> > >
> >> > > Andreas, can you please test this series? It is a modification from
> >> > > previous testing patch that should still work fine for you.
> >> > > That testing patch would have been failing X startup on old BIOS systems
> >> > > booted with vga=normal (or otherwise in VGA text mode).
> >> > >
> >> > >
> >> > > Greg, in case you have scheduled above-mentioned commit for your next
> >> > > stable iteration, please hold it back in the queue until this follow-up
> >> > > has landed and can be included within the same stable update as alone
> >> > > that patch regresses for Macs with dual-GPU and using efifb.
> >> > >
> >> > > Bruno
> >> >
> >> > Fails again (with and without efifb).
> >> >
> >> > The vga_set_default_device in vga_arbiter_add_pci_device is at fault.
> >> > It sets the boot video device to intel. Removing it makes the system
> >> > bootable again.
> >>
> >> Could you provide your whole kernel log? I would like to understand
> >> how your vga devices are setup and why it starts the wrong way.
> >>
> >> If you can grab kernel log from both working and failing setups it
> >> would be even better. The failing one is interesting for where exactly it
> >> starts failing at boot.
> >
> > While collecting debug logs, please apply following patch to get
> > PCI command and bridge control registers as configured when vgaarb looks
> > at them.
From: Bruno Prémont <bonbons@linux-vserver.org>
Subject: [PATCH] x86: Force selection of vga_default_device on screen_info
Apple dual-GPU systems get the wrong GPU choosen by vgaarb because the
built-in Intel GPU has I/O ports active and no bridge in front that
would block legacy VGA I/O ports. (though no legacy VGA is setup)
The wrong initial selection prevents system from booting properly.
The proper solution would be to improve vgaarb's initial device
selection. Until that has been done return to behavior that efifb
implemented before the move to pci_fixup_video.
The draw-back of this old operation mode is that a wrong device
gets the IORESOURCE_ROM_SHADOW flag set.
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
CC: Matthew Garrett <matthew.garrett@nebula.com>
CC: stable@vger.kernel.org # v3.5+
---
arch/x86/pci/fixup.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 5b392d2..fc509d5 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -326,7 +326,10 @@ static void pci_fixup_video(struct pci_dev *pdev)
struct pci_bus *bus;
u16 config;
- if (!vga_default_device()) {
+ if (!vga_default_device() || 1) {
+ /* The `|| 1` condition papers over vgaarb initial GPU selection limitation
+ * on Apple dual-GPU systems using EFI.
+ */
resource_size_t start, end;
int i;
--
1.8.5.5
next prev parent reply other threads:[~2014-08-21 21:34 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 20:43 [Patch] x86, ia64, efifb: Move boot_vga fixup from pci to vgaarb Bruno Prémont
2014-05-27 23:42 ` Bjorn Helgaas
2014-06-02 18:16 ` Bruno Prémont
2014-06-02 18:19 ` [PATCH 2/2] x86, ia64: Merge common vga fixup code Bruno Prémont
2014-06-02 18:19 ` [PATCH 1/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() Bruno Prémont
2014-06-17 22:35 ` Bjorn Helgaas
2014-06-18 6:09 ` Bruno Prémont
2014-06-24 20:41 ` Bruno Prémont
2014-06-24 22:55 ` [PATCH 1/2 v2] " Bruno Prémont
2014-06-24 22:58 ` [PATCH 2/2 v2] x86, ia64: Merge common vga fixup code Bruno Prémont
2014-06-24 23:02 ` [PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() Matthew Garrett
2014-07-05 17:15 ` Bjorn Helgaas
2014-08-10 0:21 ` Andreas Noever
2014-08-10 0:36 ` Andreas Noever
2014-08-10 9:26 ` Bruno Prémont
2014-08-10 9:56 ` Andreas Noever
2014-08-10 16:34 ` Bruno Prémont
2014-08-14 0:40 ` Andreas Noever
2014-08-16 17:21 ` [PATCH 0/2] " Bruno Prémont
2014-08-16 17:25 ` [PATCH 1/2] vgaarb: Drop obsolete #ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE Bruno Prémont
2014-08-16 17:30 ` [PATCH 2/2] x86, ia64: Don't default to first video device Bruno Prémont
2014-08-19 15:45 ` [PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() Andreas Noever
2014-08-20 5:55 ` Bruno Prémont
2014-08-20 7:11 ` Bruno Prémont
[not found] ` <CAMxnaaUodONkqmdPWedN-Q1qheHiJAScFcG_XbX1--ZmiOQZDg@mail.gmail.com>
2014-08-21 21:34 ` Bruno Prémont [this message]
2014-08-22 4:39 ` Bjorn Helgaas
2014-08-22 6:23 ` Bruno Prémont
[not found] ` <CAMxnaaU9EiMcne-aQjS1sY1Orn6xGbVHEnd057ogcZ77p74Y=Q@mail.gmail.com>
2014-08-23 11:06 ` Bruno Prémont
2014-08-24 21:09 ` [PATCH 1/2 v2] vgaarb: Don't default exclusively to first video device with mem+io Bruno Prémont
2014-08-26 15:32 ` Andreas Noever
2014-08-28 20:47 ` Bruno Prémont
2014-09-12 11:19 ` Bruno Prémont
2014-09-12 14:28 ` Bjorn Helgaas
2014-09-18 23:26 ` Dave Airlie
2014-09-19 5:18 ` Bjorn Helgaas
2014-08-24 21:13 ` [PATCH 2/2 v2] vgaarb: Drop obsolete #ifndef Bruno Prémont
2014-08-25 12:16 ` [PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() Daniel Vetter
2014-08-25 12:39 ` Bruno Prémont
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=20140821233435.19a9cffa@neptune.home \
--to=bonbons@linux-vserver.org \
--cc=airlied@linux.ie \
--cc=andreas.noever@gmail.com \
--cc=bhelgaas@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew.garrett@nebula.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).