dmesg with your patches and vga_set_default_device commented out
(after "vgaarb: Boot video device...") as otherwise the system won't
boot.
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.
On Wed, Aug 20, 2014 at 9:11 AM, Bruno Prémont
<bonbons@xxxxxxxxxxxxxxxxx> 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.
>
>
>
> 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;
Attachment:
dmesg
Description: Binary data
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
