[vfio-users] UEFI GOP regression in kernel 4.1.13 onwards when sequestering GPU

[Jonathan Scruggs]

Did you post this to the Linux Kernel Mailing List? The people there can
help investigate it as it could be a deeper issue that is only made
apparent by the patch in question.

-Jon
On Jan 8, 2016 4:52 AM, "Joseph East" <eastyjr at gmail.com> wrote:

> Hi all,
>
> I've recently installed a kernel upgrade package to 4.1.13 which seems to
> have broken GOP output switching (and thus Xorg) when I sequester my PCI-E
> GPU during initrd. This happens using pci-stub or vfio-pci and seems to
> have carried on all the way through to at least kernel 4.4-rc7 (haven't
> tried later versions). I've managed to narrow down the kernel patch which
> caused the problem, but I'm wondering if anyone else has this issue before
> reporting upstream as the failmode likely only impacts vfio users.
>
> This is the patch in question
>
> https://github.com/torvalds/linux/commit/bd69119
>
> My normal boot sequence with kernel 4.1.12 or patch-less 4.1.13. Separate
> monitors are connected to integrated GPU and PCI-E GPU pre-boot.
> * POST appears on both monitors, PCI-E GPU first then iGPU (despite UEFI
> setting...)
> * GRUB appears on PCI-E GPU, linux kernel selected and loads initrd (iGPU
> blank at this point)
> * GRUB prompt freezes on PCI-E GPU, boot splash screen appears on iGPU
> output
> * KDE login appears on iGPU output, system acts as normal from this point
> * xorg log shows successful binding to i915, no mention of radeon or
> attempts to bind to radeon
> * dmesg indicates fbcon inteldrmfb is set as the primary device
>
> Broken boot sequence, as above but with 4.1.13+ as-is
> * POST appears on both monitors, PCI-E GPU first then iGPU (despite UEFI
> setting...)
> * GRUB appears on PCI-E GPU, loads initrd
> * PCI-E GPU goes blank, can see iGPU monitor light up but no output
> * After waiting, must SSH into box to do anything
> * xorg logs indicate trying to bind to radeon (sequestered), which is why
> it died
> * dmesg shows no indication of switching fbcon, fb0 bound to an arbitrary
> EFI VGA frame buffer device which can be anything?
>
> There are three work-arounds I've identified which restore functionality
> 1) Disconnect the monitor connected to the PCI-E GPU during boot, plug it
> in after the host has booted
> 2) Re-compile the kernel without the above patch (works on at least
> 4.1.13, haven't tried on others but there have been no commits to eboot.c
> since)
> 3) Custom xorg.conf to pin the primary monitor to the integrated GPU
>
> My platform:
>
> * Core i5 2500 w/ Intel HD2000
> * Gigabyte Z77X-UD5H w/ firmware F14, iGPU set as primary adapter, VT-d
> enabled etc.
> * Radeon 7750 used for PCI-E pass-through using vfio-pci
> * OpenSUSE 42.1 booting from UEFI
> * OpenSUSE KVM pattern (via YaST):
> -libvirt 1.2.18.1
> -virt-manager 1.2.1
> -QEMU 2.3.1
> * Kernel command line: "resume=/dev/system/swap splash=silent quiet
> showopts intel_iommu=on rd.driver.pre=vfio-pci"
> * pci-ids for HD7750 are static entries in conf file within modprobe.d
>
> There's also the possibility that my hardware is suspect, my motherboard
> hasn't had the best track record with regards to firmware quality and there
> are existing ACPI issues (auto reboot on shutdown for example), my GPU also
> uses a patched firmware in order to enable GOP. But with that said
> everything works as it should when the kernel patch is removed.
>
> Regards,
> Joseph
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/2e19fef1/attachment.htm>