From patchwork Wed Aug 20 07:11:52 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Bruno_Pr=C3=A9mont?= X-Patchwork-Id: 4747841 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 9785EC0338 for ; Wed, 20 Aug 2014 07:11:57 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0F5A52016C for ; Wed, 20 Aug 2014 07:11:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2901720155 for ; Wed, 20 Aug 2014 07:11:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750708AbaHTHLy (ORCPT ); Wed, 20 Aug 2014 03:11:54 -0400 Received: from smtprelay.restena.lu ([158.64.1.62]:40729 "EHLO smtprelay.restena.lu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750745AbaHTHLx convert rfc822-to-8bit (ORCPT ); Wed, 20 Aug 2014 03:11:53 -0400 Received: from pluto (pluto.restena.lu [IPv6:2001:a18:1:8::156]) by smtprelay.restena.lu (Postfix) with ESMTPS id 67E4043194; Wed, 20 Aug 2014 09:11:52 +0200 (CEST) Date: Wed, 20 Aug 2014 09:11:52 +0200 From: Bruno =?UTF-8?B?UHLDqW1vbnQ=?= To: Andreas Noever Cc: Bjorn Helgaas , DRI mailing list , Linux PCI , Dave Airlie , Matthew Garrett , Greg Kroah-Hartman Subject: Re: [PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() Message-ID: <20140820091152.76cd4e1a@pluto> In-Reply-To: <20140820075508.74f5b622@pluto> References: <20140514224339.7f8be3a9@neptune.home> <20140527234255.GJ11907@google.com> <20140602201650.35f0e936@neptune.home> <20140602201926.4d476818@neptune.home> <20140625005501.7ff7e982@neptune.home> <20140705171503.GC6247@google.com> <20140810112654.1bf684d6@neptune.home> <20140810183411.19370721@neptune.home> <20140816192135.34260115@neptune.home> <20140820075508.74f5b622@pluto> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.24; x86_64-pc-linux-gnu) Mime-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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. --- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c index af02597..8c8e7af 100644 --- a/drivers/gpu/vga/vgaarb.c +++ b/drivers/gpu/vga/vgaarb.c @@ -554,6 +554,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev) * clear that below if the bridge isn't forwarding */ pci_read_config_word(pdev, PCI_COMMAND, &cmd); + pr_info("vgaarb: PCI:%s PCI_COMMAND=%04x\n", pci_name(pdev), (unsigned int)cmd); if (cmd & PCI_COMMAND_IO) vgadev->owns |= VGA_RSRC_LEGACY_IO; if (cmd & PCI_COMMAND_MEMORY) @@ -567,6 +568,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev) u16 l; pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, &l); + pr_info("vgaarb: PCI:%s, bridge PCI:%s PCI_BRIDGE_CONTROL=%04x\n", pci_name(pdev), pci_name(bridge), (unsigned int)l); if (!(l & PCI_BRIDGE_CTL_VGA)) { vgadev->owns = 0; break;