[Bug 73834] Launch of Qemu VM (with kvm/vfio/iommu/pci-stub) causes [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Feb 4 14:12:07 PST 2014


https://bugs.freedesktop.org/show_bug.cgi?id=73834

--- Comment #8 from Dave Jopson <duggum at gmail.com> ---
(In reply to comment #7)
> VGA arbitration. Shudder. I tried to come up with a way to make it work
> somehow, and I apparently failed. I'm not going to try again any time soon.
> 
> Here's what Daniel had to say when he reverted a bunch of VGA arbiter
> changes from the driver. You can follow the link to my stop_machine hack.
> 
> commit ebff5fa9d545574324095d9c6a3cb80c9157abc5
> Author: Dave Airlie <airlied at redhat.com>
> Date:   Fri Oct 11 15:12:04 2013 +1000
> 
>     Revert "i915: Update VGA arbiter support for newer devices"
>     
>     This reverts commit 81b5c7bc8de3e6f63419139c2fc91bf81dea8a7d.
>     
>     Adding drm/i915 into the vga arbiter chain means that X (in a piece of
>     well-meant paranoia) will do a get/put on the vga decoding around
>     _every_ accel call down into the ddx. Which results in some nice
>     performance disasters [1]. This really breaks userspace, by disabling
>     DRI for everyone, and stops OpenGL from working, this isn't limited
>     to just the i915 but both the integrated and discrete GPUs on
>     multi-gpu systems, in other words this causes untold worlds of pain,
>     
>     Ville tried to come up with a Great Hack to fiddle the required VGA
>     I/O ops behind everyone's back using stop_machine, but that didn't
>     really work out [2]. Given that we're fairly late in the -rc stage for
>     such games let's just revert this all.
>     
>     One thing we might want to keep is to delay the disabling of the vga
>     decoding until the fbdev emulation and the fbcon screen is set up. If
>     we kill vga mem decoding beforehand fbcon can end up with a white
>     square in the top-left corner it tried to save from the vga memory for
>     a seamless transition. And we have bug reports on older platforms
>     which seem to match these symptoms.
>     
>     But again that's something to play around with in -next.
>     
>     References: [1]
> http://lists.x.org/archives/xorg-devel/2013-September/037763.html
>     References: [2] http://www.spinics.net/lists/intel-gfx/msg34062.html
>     Cc: Alex Williamson <alex.williamson at redhat.com>
>     Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
>     Cc: Chris Wilson <chris at chris-wilson.co.uk>
>     Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>     Signed-off-by: Dave Airlie <airlied at redhat.com>

Yeah, this issue seems to be a head-scratcher for you developer types, and I am
not going to pretend to understand any of it. I just wanted something to work
and it didn't, so I thought I would throw it out there for you guys to look at.

Oddly enough, I decided to switch to Arch Linux, and following the guidance
found here:

https://bbs.archlinux.org/viewtopic.php?id=162768

I was able to get this to work flawlessly. On both Linux Mint and Arch I built
the 3.13 kernel with the same patches (i915 & acs), and the same configuration
file. Qemu and Seabios were built from git as well. On Arch it works fine. I
can fully launch my Windows VM using the discreet nvidia card, and my onboard
intel keeps my main desktop running with full hardware acceleration. The same
setup in Linux Mint failed to deliver.

Thanks for the reply, and maybe sometime down the road you guys will crack this
nut. Good luck!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20140204/1110b88a/attachment-0001.html>


More information about the intel-gfx-bugs mailing list