Created attachment 117251 [details]
+++ This bug was initially created as a clone of Bug #90037 +++
When I use Linux >= 3.19 as the dom0 kernel of Xen, screen becomes unreadable after i915 driver is loaded. The screenshot is already posted as an attachment of another bug: https://bugs.freedesktop.org/attachment.cgi?id=115079. This screenshot is obtained when the system is in single user mode.
If it continues to boot into graphical mode, a lot of error messages are showed when the display manager is started. Screen output becomes more broken and the system crashes after several minutes.
VT-d is automatically enabled by Xen. If VT-d is manually disabled, there is no graphics problem and the system can run normally.
The bad commit showed by git bisect is https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47591df
Please see the attached Xen dmesg, Linux dmesg and GPU crash dump.
CPU and GPU:
Intel Core i5 CPU 650 @ 3.20GHz
Intel Ironlake Desktop
ASUSTeK Computer INC. P7H55D-M EVO
GNOME Shell 3.16.3
This problem was initially reported as here:
I sent a message to xen-devel and they thought it should be an i915 problem:
As I don't know how to fix the problem, I made a workaround in Xen:
They also said it is an i915 problem:
A silimar problem also happens on Linux >= 3.7 without using Xen:
It was partially fixed in Linux 4.2-rc2:
It seems there are some common messages showed by Xen and Linux:
Messages showed by Xen with Linux 4.2-rc3 dom0:
(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr 73fbff000, iommu reg = ffff82c000203000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
Messages showed by Linux 4.2-rc2 when not using Xen:
DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr fde7c000
DMAR:[fault reason 05] PTE Write access is not set
Created attachment 117252 [details]
Why is this not a dupe of bug 90037? Same bisect result and all.
No updates for a long time. Is this still an issue?
(In reply to Ileana from comment #3)
> No updates for a long time. Is this still an issue?
Yes, I still have to use the workaround I added to Xen 4.6 (iommu=no-igfx) to avoid this issue.
This bug was opened because I was afraid that the reopened bug would be ignored. As the original bug report got response, I am closing this bug as duplicate now.
*** This bug has been marked as a duplicate of bug 90037 ***