[BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[Ting-Wei Lan]

When using Linux >= 3.19 as the dom0 kernel, characters on the screen 
become broken after the graphic driver is loaded. The commit that breaks 
it is (found by git bisect):

 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47591df


Screenshot when the system run in single user mode:

   https://bugs.freedesktop.org/attachment.cgi?id=115079


If it continues booting, the dom0 can crash after GDM tries to start 
Xorg. Some messages are showed when Xorg is running:

   [   80.636446] [drm] stuck on render ring
   [   80.640041] [drm] GPU HANG: ecode 5:0:0x7fbfff08, in Xwayland 
[2112], reason: Ring hung, action: reset


I cannot run 'dmesg' and 'xl dmesg' because the dom0 is unusable after 
Xorg runs, so I attach the serial console log instead. It was tested on 
Xen 4.5.1-rc2 and Linux 4.1-rc7:

   https://gist.github.com/lantw44/715160f1a53967a1627b


This problem was reported to DRM/Intel, but they think it is not their 
bug. I also reported it to kernel bugzilla, but there is no response:

   https://bugs.freedesktop.org/show_bug.cgi?id=90037
   https://bugzilla.kernel.org/show_bug.cgi?id=97421


This problem only happens when VT-d is enabled. If I add 'iommu=off' to 
Xen boot arguments, there will be no problem. It seems it only happens 
on specific hardware. Two machines are listed below, one with the 
problem and one without the problem.


The machine that has this problem:

(Software)
Xen 4.4.2, 4.5.0, 4.5.1-rc2
Linux 3.19.2, 3.19.3, 3.19.4, 4.0, 4.0.3, 4.0.4, 4.1-rc7

(CPU and GPU)
Intel Core i5 CPU 650 @ 3.20GHz
Intel Ironlake Desktop

(Motherboard)
ASUSTeK Computer INC. P7H55D-M EVO

(lspci output)
00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller 
(rev 12)
00:01.0 PCI bridge: Intel Corporation Core Processor PCI Express x16 
Root Port (rev 12)
00:02.0 VGA compatible controller: Intel Corporation Core Processor 
Integrated Graphics Controller (rev 12)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series 
Chipset HECI Controller (rev 06)
00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset 
USB2 Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset 
High Definition Audio (rev 06)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 1 (rev 06)
00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 2 (rev 06)
00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 3 (rev 06)
00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 4 (rev 06)
00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 5 (rev 06)
00:1c.5 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 6 (rev 06)
00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset 
USB2 Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface 
Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 
6 port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus 
Controller (rev 06)
01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host 
Controller (rev 03)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II / 
PATA Controller (rev b2)
05:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series 
Firewire Controller
06:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host 
Controller (rev 02)
3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath 
Architecture Generic Non-core Registers (rev 02)
3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath 
Architecture System Address Decoder (rev 02)
3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
3f:02.1 Host bridge: Intel Corporation 1st Generation Core i3/5/7 
Processor QPI Physical 0 (rev 02)
3f:02.2 Host bridge: Intel Corporation 1st Generation Core i3/5/7 
Processor Reserved (rev 02)
3f:02.3 Host bridge: Intel Corporation 1st Generation Core i3/5/7 
Processor Reserved (rev 02)


The machine that works fine:

(Software)
Xen 4.4.1, 4.4.2
Linux 3.19.1, 3.19.2, 3.19.3, 3.19.7, 4.0.4

(CPU and GPU)
Intel Core i7-2600 CPU @ 3.40GHz
Intel Sandybridge Desktop

(Motherboard)
ASUSTeK Computer INC. P8Z68-M PRO

(lspci output)
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor 
Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core 
Processor Family PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series 
Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset 
Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Port 1 (rev b5)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Port 5 (rev b5)
00:1c.5 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5)
00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Port 7 (rev b5)
00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Port 8 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation Z68 Express Chipset Family LPC 
Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset 
Family SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family 
SMBus Controller (rev 05)
01:00.0 VGA compatible controller: NVIDIA Corporation G96 [GeForce 9400 
GT] (rev a1)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI 
Bridge (rev 01)
06:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA 
Controller (rev 01)
07:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB 
Host Controller


I still remember that there was a similar problem found two years ago on 
the same hardware with similar broken screen output and it also crashed 
after Xorg was started, but I cannot confirm that they are the same 
problems. I don't know whether error messages are simliar.

The old problem happens on Linux 3.7 ~ 3.10 with VT-d enabled. It only 
happened when not using Xen, so I added 'intel_iommu=off' to Linux boot 
arguments to workaround it.

The problem I report here happens on Linux >= 3.19 with VT-d enabled. It 
only happens when using Xen, so I add 'iommu=off' to Xen boot arguments 
to workaround it.

Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[Konrad Rzeszutek Wilk]

On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan wrote:
> When using Linux >= 3.19 as the dom0 kernel, characters on the screen become
> broken after the graphic driver is loaded. The commit that breaks it is
> (found by git bisect):
> 
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47591df

Lets CC Juergen
> 
> 
> Screenshot when the system run in single user mode:
> 
>   https://bugs.freedesktop.org/attachment.cgi?id=115079
> 
> 
> If it continues booting, the dom0 can crash after GDM tries to start Xorg.
> Some messages are showed when Xorg is running:
> 
>   [   80.636446] [drm] stuck on render ring
>   [   80.640041] [drm] GPU HANG: ecode 5:0:0x7fbfff08, in Xwayland [2112],
> reason: Ring hung, action: reset
> 
> 
> I cannot run 'dmesg' and 'xl dmesg' because the dom0 is unusable after Xorg
> runs, so I attach the serial console log instead. It was tested on Xen
> 4.5.1-rc2 and Linux 4.1-rc7:
> 
>   https://gist.github.com/lantw44/715160f1a53967a1627b
> 
> 
> This problem was reported to DRM/Intel, but they think it is not their bug.
> I also reported it to kernel bugzilla, but there is no response:
> 
>   https://bugs.freedesktop.org/show_bug.cgi?id=90037
>   https://bugzilla.kernel.org/show_bug.cgi?id=97421
> 
> 
> This problem only happens when VT-d is enabled. If I add 'iommu=off' to Xen
> boot arguments, there will be no problem. It seems it only happens on
> specific hardware. Two machines are listed below, one with the problem and
> one without the problem.

Could you also include your .config file please?

> 
> 
> The machine that has this problem:
> 
> (Software)
> Xen 4.4.2, 4.5.0, 4.5.1-rc2
> Linux 3.19.2, 3.19.3, 3.19.4, 4.0, 4.0.3, 4.0.4, 4.1-rc7
> 
> (CPU and GPU)
> Intel Core i5 CPU 650 @ 3.20GHz
> Intel Ironlake Desktop
> 
> (Motherboard)
> ASUSTeK Computer INC. P7H55D-M EVO
> 
> (lspci output)
> 00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev
> 12)
> 00:01.0 PCI bridge: Intel Corporation Core Processor PCI Express x16 Root
> Port (rev 12)
> 00:02.0 VGA compatible controller: Intel Corporation Core Processor
> Integrated Graphics Controller (rev 12)
> 00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series
> Chipset HECI Controller (rev 06)
> 00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2
> Enhanced Host Controller (rev 06)
> 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High
> Definition Audio (rev 06)
> 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
> Express Root Port 1 (rev 06)
> 00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
> Express Root Port 2 (rev 06)
> 00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
> Express Root Port 3 (rev 06)
> 00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
> Express Root Port 4 (rev 06)
> 00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
> Express Root Port 5 (rev 06)
> 00:1c.5 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
> Express Root Port 6 (rev 06)
> 00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2
> Enhanced Host Controller (rev 06)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
> 00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface
> Controller (rev 06)
> 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6
> port SATA AHCI Controller (rev 06)
> 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus
> Controller (rev 06)
> 01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller
> (rev 03)
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
> 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II / PATA
> Controller (rev b2)
> 05:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire
> Controller
> 06:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host
> Controller (rev 02)
> 3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture
> Generic Non-core Registers (rev 02)
> 3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture
> System Address Decoder (rev 02)
> 3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
> 3f:02.1 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor
> QPI Physical 0 (rev 02)
> 3f:02.2 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor
> Reserved (rev 02)
> 3f:02.3 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor
> Reserved (rev 02)
> 
> 
> The machine that works fine:
> 
> (Software)
> Xen 4.4.1, 4.4.2
> Linux 3.19.1, 3.19.2, 3.19.3, 3.19.7, 4.0.4
> 
> (CPU and GPU)
> Intel Core i7-2600 CPU @ 3.40GHz
> Intel Sandybridge Desktop
> 
> (Motherboard)
> ASUSTeK Computer INC. P8Z68-M PRO
> 
> (lspci output)
> 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family
> DRAM Controller (rev 09)
> 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core
> Processor Family PCI Express Root Port (rev 09)
> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
> Processor Family Integrated Graphics Controller (rev 09)
> 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series
> Chipset Family MEI Controller #1 (rev 04)
> 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
> Family USB Enhanced Host Controller #2 (rev 05)
> 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family
> High Definition Audio Controller (rev 05)
> 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
> PCI Express Root Port 1 (rev b5)
> 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
> PCI Express Root Port 5 (rev b5)
> 00:1c.5 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5)
> 00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
> PCI Express Root Port 7 (rev b5)
> 00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
> PCI Express Root Port 8 (rev b5)
> 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
> Family USB Enhanced Host Controller #1 (rev 05)
> 00:1f.0 ISA bridge: Intel Corporation Z68 Express Chipset Family LPC
> Controller (rev 05)
> 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset
> Family SATA AHCI Controller (rev 05)
> 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus
> Controller (rev 05)
> 01:00.0 VGA compatible controller: NVIDIA Corporation G96 [GeForce 9400 GT]
> (rev a1)
> 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
> 04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge
> (rev 01)
> 06:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA
> Controller (rev 01)
> 07:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host
> Controller
> 
> 
> I still remember that there was a similar problem found two years ago on the
> same hardware with similar broken screen output and it also crashed after
> Xorg was started, but I cannot confirm that they are the same problems. I
> don't know whether error messages are simliar.
> 
> The old problem happens on Linux 3.7 ~ 3.10 with VT-d enabled. It only
> happened when not using Xen, so I added 'intel_iommu=off' to Linux boot
> arguments to workaround it.
> 
> The problem I report here happens on Linux >= 3.19 with VT-d enabled. It
> only happens when using Xen, so I add 'iommu=off' to Xen boot arguments to
> workaround it.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[Ting-Wei Lan]

於 一，2015-06-15 於 14:55 -0400，Konrad Rzeszutek Wilk 提到：
> On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan wrote:
> > When using Linux >= 3.19 as the dom0 kernel, characters on the 
> > screen become
> > broken after the graphic driver is loaded. The commit that breaks 
> > it is
> > (found by git bisect):
> > 
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
> > mit/?id=47591df
> 
> Lets CC Juergen
> > 
> > 
> > Screenshot when the system run in single user mode:
> > 
> >   https://bugs.freedesktop.org/attachment.cgi?id=115079
> > 
> > 
> > If it continues booting, the dom0 can crash after GDM tries to 
> > start Xorg.
> > Some messages are showed when Xorg is running:
> > 
> >   [   80.636446] [drm] stuck on render ring
> >   [   80.640041] [drm] GPU HANG: ecode 5:0:0x7fbfff08, in Xwayland 
> > [2112],
> > reason: Ring hung, action: reset
> > 
> > 
> > I cannot run 'dmesg' and 'xl dmesg' because the dom0 is unusable 
> > after Xorg
> > runs, so I attach the serial console log instead. It was tested on 
> > Xen
> > 4.5.1-rc2 and Linux 4.1-rc7:
> > 
> >   https://gist.github.com/lantw44/715160f1a53967a1627b
> > 
> > 
> > This problem was reported to DRM/Intel, but they think it is not 
> > their bug.
> > I also reported it to kernel bugzilla, but there is no response:
> > 
> >   https://bugs.freedesktop.org/show_bug.cgi?id=90037
> >   https://bugzilla.kernel.org/show_bug.cgi?id=97421
> > 
> > 
> > This problem only happens when VT-d is enabled. If I add 
> > 'iommu=off' to Xen
> > boot arguments, there will be no problem. It seems it only happens 
> > on
> > specific hardware. Two machines are listed below, one with the 
> > problem and
> > one without the problem.
> 
> Could you also include your .config file please?
> 

My .config for Linux 4.0.4

https://gist.github.com/lantw44/5cbfc6e6052423bec910


It should be the same as the kernel provided by Fedora 22 except for
CONFIG_XEN_PVH=y.

> > 
> > 
> > The machine that has this problem:
> > 
> > (Software)
> > Xen 4.4.2, 4.5.0, 4.5.1-rc2
> > Linux 3.19.2, 3.19.3, 3.19.4, 4.0, 4.0.3, 4.0.4, 4.1-rc7
> > 
> > (CPU and GPU)
> > Intel Core i5 CPU 650 @ 3.20GHz
> > Intel Ironlake Desktop
> > 
> > (Motherboard)
> > ASUSTeK Computer INC. P7H55D-M EVO
> > 
> > (lspci output)
> > 00:00.0 Host bridge: Intel Corporation Core Processor DRAM 
> > Controller (rev
> > 12)
> > 00:01.0 PCI bridge: Intel Corporation Core Processor PCI Express 
> > x16 Root
> > Port (rev 12)
> > 00:02.0 VGA compatible controller: Intel Corporation Core Processor
> > Integrated Graphics Controller (rev 12)
> > 00:16.0 Communication controller: Intel Corporation 5 Series/3400 
> > Series
> > Chipset HECI Controller (rev 06)
> > 00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series 
> > Chipset USB2
> > Enhanced Host Controller (rev 06)
> > 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series 
> > Chipset High
> > Definition Audio (rev 06)
> > 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset 
> > PCI
> > Express Root Port 1 (rev 06)
> > 00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset 
> > PCI
> > Express Root Port 2 (rev 06)
> > 00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset 
> > PCI
> > Express Root Port 3 (rev 06)
> > 00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset 
> > PCI
> > Express Root Port 4 (rev 06)
> > 00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset 
> > PCI
> > Express Root Port 5 (rev 06)
> > 00:1c.5 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset 
> > PCI
> > Express Root Port 6 (rev 06)
> > 00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series 
> > Chipset USB2
> > Enhanced Host Controller (rev 06)
> > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
> > 00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC 
> > Interface
> > Controller (rev 06)
> > 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series 
> > Chipset 6
> > port SATA AHCI Controller (rev 06)
> > 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus
> > Controller (rev 06)
> > 01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host 
> > Controller
> > (rev 03)
> > 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
> > 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA 
> > II / PATA
> > Controller (rev b2)
> > 05:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series 
> > Firewire
> > Controller
> > 06:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 
> > Host
> > Controller (rev 02)
> > 3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath 
> > Architecture
> > Generic Non-core Registers (rev 02)
> > 3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath 
> > Architecture
> > System Address Decoder (rev 02)
> > 3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 
> > (rev 02)
> > 3f:02.1 Host bridge: Intel Corporation 1st Generation Core i3/5/7 
> > Processor
> > QPI Physical 0 (rev 02)
> > 3f:02.2 Host bridge: Intel Corporation 1st Generation Core i3/5/7 
> > Processor
> > Reserved (rev 02)
> > 3f:02.3 Host bridge: Intel Corporation 1st Generation Core i3/5/7 
> > Processor
> > Reserved (rev 02)
> > 
> > 
> > The machine that works fine:
> > 
> > (Software)
> > Xen 4.4.1, 4.4.2
> > Linux 3.19.1, 3.19.2, 3.19.3, 3.19.7, 4.0.4
> > 
> > (CPU and GPU)
> > Intel Core i7-2600 CPU @ 3.40GHz
> > Intel Sandybridge Desktop
> > 
> > (Motherboard)
> > ASUSTeK Computer INC. P8Z68-M PRO
> > 
> > (lspci output)
> > 00:00.0 Host bridge: Intel Corporation 2nd Generation Core 
> > Processor Family
> > DRAM Controller (rev 09)
> > 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation 
> > Core
> > Processor Family PCI Express Root Port (rev 09)
> > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation 
> > Core
> > Processor Family Integrated Graphics Controller (rev 09)
> > 00:16.0 Communication controller: Intel Corporation 6 Series/C200 
> > Series
> > Chipset Family MEI Controller #1 (rev 04)
> > 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series 
> > Chipset
> > Family USB Enhanced Host Controller #2 (rev 05)
> > 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series 
> > Chipset Family
> > High Definition Audio Controller (rev 05)
> > 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset 
> > Family
> > PCI Express Root Port 1 (rev b5)
> > 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset 
> > Family
> > PCI Express Root Port 5 (rev b5)
> > 00:1c.5 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5)
> > 00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset 
> > Family
> > PCI Express Root Port 7 (rev b5)
> > 00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset 
> > Family
> > PCI Express Root Port 8 (rev b5)
> > 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series 
> > Chipset
> > Family USB Enhanced Host Controller #1 (rev 05)
> > 00:1f.0 ISA bridge: Intel Corporation Z68 Express Chipset Family 
> > LPC
> > Controller (rev 05)
> > 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series 
> > Chipset
> > Family SATA AHCI Controller (rev 05)
> > 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset 
> > Family SMBus
> > Controller (rev 05)
> > 01:00.0 VGA compatible controller: NVIDIA Corporation G96 [GeForce 
> > 9400 GT]
> > (rev a1)
> > 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
> > 04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to 
> > PCI Bridge
> > (rev 01)
> > 06:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA
> > Controller (rev 01)
> > 07:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed 
> > USB Host
> > Controller
> > 
> > 
> > I still remember that there was a similar problem found two years 
> > ago on the
> > same hardware with similar broken screen output and it also crashed 
> > after
> > Xorg was started, but I cannot confirm that they are the same 
> > problems. I
> > don't know whether error messages are simliar.
> > 
> > The old problem happens on Linux 3.7 ~ 3.10 with VT-d enabled. It 
> > only
> > happened when not using Xen, so I added 'intel_iommu=off' to Linux 
> > boot
> > arguments to workaround it.
> > 
> > The problem I report here happens on Linux >= 3.19 with VT-d 
> > enabled. It
> > only happens when using Xen, so I add 'iommu=off' to Xen boot 
> > arguments to
> > workaround it.
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[Juergen Gross]

On 06/15/2015 09:03 PM, Ting-Wei Lan wrote:
> 於 一，2015-06-15 於 14:55 -0400，Konrad Rzeszutek Wilk 提到：
>> On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan wrote:
>>> When using Linux >= 3.19 as the dom0 kernel, characters on the
>>> screen become
>>> broken after the graphic driver is loaded. The commit that breaks
>>> it is
>>> (found by git bisect):
>>>
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
>>> mit/?id=47591df
>>
>> Lets CC Juergen
>>>
>>>
>>> Screenshot when the system run in single user mode:
>>>
>>>    https://bugs.freedesktop.org/attachment.cgi?id=115079

Are those messages to be expected:

(XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs
(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr 
b61eef000, iommu reg = ffff82c000203000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
(XEN) 
..................................................................done.

I'm not familiar with VT-D internals, but seeing these messages for the
video device during RAM scrubbing makes wonder if everything is correct
regarding the VT-D and memory setup...

>>>
>>>
>>> I still remember that there was a similar problem found two years
>>> ago on the
>>> same hardware with similar broken screen output and it also crashed
>>> after
>>> Xorg was started, but I cannot confirm that they are the same
>>> problems. I
>>> don't know whether error messages are simliar.
>>>
>>> The old problem happens on Linux 3.7 ~ 3.10 with VT-d enabled. It
>>> only
>>> happened when not using Xen, so I added 'intel_iommu=off' to Linux
>>> boot
>>> arguments to workaround it.

Hmm, do you see any chance in finding the commit which made it working
again? Perhaps there was some workaround for this hardware which is
missing in Xen now...


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[Ting-Wei Lan]

Juergen Gross 於 西元2015年06月16日 12:30 寫道:
> On 06/15/2015 09:03 PM, Ting-Wei Lan wrote:
>> 於 一，2015-06-15 於 14:55 -0400，Konrad Rzeszutek Wilk 提到：
>>> On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan wrote:
>>>> When using Linux >= 3.19 as the dom0 kernel, characters on the
>>>> screen become
>>>> broken after the graphic driver is loaded. The commit that breaks
>>>> it is
>>>> (found by git bisect):
>>>>
>>>>
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
>>>> mit/?id=47591df
>>>
>>> Lets CC Juergen
>>>>
>>>>
>>>> Screenshot when the system run in single user mode:
>>>>
>>>>    https://bugs.freedesktop.org/attachment.cgi?id=115079
>
> Are those messages to be expected:
>
> (XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs
> (XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr
> b61eef000, iommu reg = ffff82c000203000
> (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
> (XEN)
> ..................................................................done.
>
> I'm not familiar with VT-D internals, but seeing these messages for the
> video device during RAM scrubbing makes wonder if everything is correct
> regarding the VT-D and memory setup...

I got more VT-D messages by using iommu=verbose:

Loading Xen 4.5.1-rc2 ...
Loading Linux 4.0.5-300.fc22.x86_64 ...
Loading initial ramdisk ...
  Xen 4.5.1-rc2
(XEN) Xen version 4.5.1-rc2 (nobody@[unknown]) (gcc (GCC) 4.9.2 20150212 
(Red Hat 4.9.2-6)) debug=n Thu Jun 11 02:48:49 EDT 2015
(XEN) Latest ChangeSet: Wed Jun 3 09:10:15 2015 +0200 git:0f4362b
(XEN) Bootloader: GRUB 2.02~beta2
(XEN) Command line: placeholder com1=115200,8n1 console=vga,com1 
conswitch=a loglvl=all guest_loglvl=all iommu=verbose
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009c800 (usable)
(XEN)  000000000009c800 - 00000000000a0000 (reserved)
(XEN)  00000000000e4000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000d7a70000 (usable)
(XEN)  00000000d7a70000 - 00000000d7a88000 (ACPI data)
(XEN)  00000000d7a88000 - 00000000d7adc000 (ACPI NVS)
(XEN)  00000000d7adc000 - 00000000e0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 00000003fc000000 (usable)
(XEN)  00000003fc000000 - 0000000400000000 (reserved)
(XEN)  0000000400000000 - 0000000420000000 (usable)
(XEN) ACPI: RSDP 000FB9E0, 0014 (r0 ACPIAM)
(XEN) ACPI: RSDT D7A70000, 0048 (r1 072210 RSDT1556 20100722 MSFT       97)
(XEN) ACPI: FACP D7A70200, 0084 (r1 072210 FACP1556 20100722 MSFT       97)
(XEN) ACPI: DSDT D7A704A0, D67C (r1  A1471 A1471001        1 INTL 20060113)
(XEN) ACPI: FACS D7A88000, 0040
(XEN) ACPI: APIC D7A70390, 00CC (r1 072210 APIC1556 20100722 MSFT       97)
(XEN) ACPI: MCFG D7A70460, 003C (r1 072210 OEMMCFG  20100722 MSFT       97)
(XEN) ACPI: OEMB D7A88040, 0072 (r1 072210 OEMB1556 20100722 MSFT       97)
(XEN) ACPI: HPET D7A7DB20, 0038 (r1 072210 OEMHPET  20100722 MSFT       97)
(XEN) ACPI: GSCI D7A880C0, 2024 (r1 072210 GMCHSCI  20100722 MSFT       97)
(XEN) ACPI: DMAR D7A8A0F0, 00E0 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: OSFR D7A7DB60, 00B0 (r1 072210 OEMOSFR  20100722 MSFT       97)
(XEN) ACPI: SSDT D7A8BC00, 0363 (r1 DpgPmm    CpuPm       12 INTL 20060113)
(XEN) System RAM: 16186MB (16574512kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000420000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000ff780
(XEN) DMI 2.6 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:804,1:0], pm1x_evt[1:800,1:0]
(XEN) ACPI:             wakeup_vec[d7a8800c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:5 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 6:5 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
(XEN) Processor #1 6:5 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x05] enabled)
(XEN) Processor #5 6:5 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x8c] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x8d] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x8e] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x8f] disabled)
(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D]dmar.c:788: Host address width 36
(XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:472:   dmaru->address = fed90000
(XEN) [VT-D]iommu.c:1150: drhd->address = fed90000 iommu->reg = 
ffff82c000201000
(XEN) [VT-D]iommu.c:1152: cap = c9008020e30272 ecap = 1000
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1b.0
(XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:472:   dmaru->address = fed91000
(XEN) [VT-D]iommu.c:1150: drhd->address = fed91000 iommu->reg = 
ffff82c000203000
(XEN) [VT-D]iommu.c:1152: cap = c0000020230272 ecap = 1000
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:02.0
(XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:472:   dmaru->address = fed93000
(XEN) [VT-D]iommu.c:1150: drhd->address = fed93000 iommu->reg = 
ffff82c000205000
(XEN) [VT-D]iommu.c:1152: cap = c9008020630272 ecap = 1000
(XEN) [VT-D]dmar.c:486:   flags: INCLUDE_ALL
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr e4000 end_address e7fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:02.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr d7c00000 end_address 
dfffffff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr d7aec000 end_address 
d7afffff
(XEN) ERST table was not found
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 16 CPUs (12 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3201.937 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) alt table ffff82d0802bcb10 -> ffff82d0802bdc68
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f
(XEN) PCI: Not using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d iommu 1 supported page sizes: 4kB.
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB.
(XEN) Intel VT-d iommu 2 supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation not enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping disabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 32 KiB.
(XEN) mwait-idle: MWAIT substates: 0x1120
(XEN) mwait-idle: v0.4 model 0x25
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB
(XEN) Brought up 4 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) Dom0 has maximum 600 PIRQs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2044000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000040c000000->0000000410000000 (4034216 pages 
to be allocated)
(XEN)  Init. ramdisk: 000000041ed30000->000000041ffffe42
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82044000
(XEN)  Init. ramdisk: 0000000000000000->0000000000000000
(XEN)  Phys-Mach map: ffffffff82044000->ffffffff83f34bc0
(XEN)  Start info:    ffffffff83f35000->ffffffff83f354b4
(XEN)  Page tables:   ffffffff83f36000->ffffffff83f59000
(XEN)  Boot stack:    ffffffff83f59000->ffffffff83f5a000
(XEN)  TOTAL:         ffffffff80000000->ffffffff84000000
(XEN)  ENTRY ADDRESS: ffffffff81d381f0
(XEN) Dom0 has maximum 4 VCPUs
(XEN) [VT-D]iommu.c:1434: d0:Hostbridge: skip 0000:00:00.0 map
(XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0
(XEN) [VT-D]iommu.c:1460: d0:PCI: map 0000:00:02.0
(XEN) [VT-D]iommu.c:1460: d0:PCI: map 0000:00:16.0
(XEN) [VT-D]iommu.c:1460: d0:PCI: map 0000:00:1a.0
(XEN) [VT-D]iommu.c:1448: d0:PCIe: map 0000:00:1b.0
(XEN) [VT-D]iommu.c:1460: d0:PCI: map 0000:00:1d.0
(XEN) [VT-D]iommu.c:1460: d0:PCI: map 0000:00:1f.0
(XEN) [VT-D]iommu.c:1460: d0:PCI: map 0000:00:1f.2
(XEN) [VT-D]iommu.c:1460: d0:PCI: map 0000:00:1f.3
(XEN) [VT-D]iommu.c:1448: d0:PCIe: map 0000:01:00.0
(XEN) [VT-D]iommu.c:1448: d0:PCIe: map 0000:02:00.0
(XEN) [VT-D]iommu.c:1448: d0:PCIe: map 0000:03:00.0
(XEN) [VT-D]iommu.c:1448: d0:PCIe: map 0000:05:00.0
(XEN) [VT-D]iommu.c:1448: d0:PCIe: map 0000:06:00.0
(XEN) [VT-D]iommu.c:1434: d0:Hostbridge: skip 0000:3f:00.0 map
(XEN) [VT-D]iommu.c:1434: d0:Hostbridge: skip 0000:3f:00.1 map
(XEN) [VT-D]iommu.c:1434: d0:Hostbridge: skip 0000:3f:02.0 map
(XEN) [VT-D]iommu.c:1434: d0:Hostbridge: skip 0000:3f:02.1 map
(XEN) [VT-D]iommu.c:1434: d0:Hostbridge: skip 0000:3f:02.2 map
(XEN) [VT-D]iommu.c:1434: d0:Hostbridge: skip 0000:3f:02.3 map
(XEN) [VT-D]iommu.c:729: iommu_enable_translation: iommu->reg = 
ffff82c000203000
(XEN) [VT-D]iommu.c:729: iommu_enable_translation: iommu->reg = 
ffff82c000201000
(XEN) [VT-D]iommu.c:729: iommu_enable_translation: iommu->reg = 
ffff82c000205000
(XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs
(XEN) 
..................................................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch 
input to Xen)
(XEN) Freed 284kB init memory.
mapping kernel into physical memory
about to get started...
(XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000081 from 
0xe023e00800000000 to 0x0023001000000000.
(XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000082 from 
0xffff82d0802c3000 to 0xffffffff8178aad0.
(XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000083 from 
0xffff82d0802c3080 to 0xffffffff8178cf00.
(XEN) traps.c:2589:d0v0 Domain attempted WRMSR 0000000000000174 from 
0x000000000000e008 to 0x0000000000000010.
(XEN) traps.c:2589:d0v0 Domain attempted WRMSR 0000000000000175 from 
0xffff82d0802c7fc0 to 0x0000000000000000.
(XEN) traps.c:2589:d0v0 Domain attempted WRMSR 0000000000000176 from 
0xffff82d080225ee0 to 0xffffffff8178d210.
(XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000083 from 
0xffff82d0802c3080 to 0xffffffff8178d450.
(XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000084 from 
0x0000000000074700 to 0x0000000000047700.


>
>>>>
>>>>
>>>> I still remember that there was a similar problem found two years
>>>> ago on the
>>>> same hardware with similar broken screen output and it also crashed
>>>> after
>>>> Xorg was started, but I cannot confirm that they are the same
>>>> problems. I
>>>> don't know whether error messages are simliar.
>>>>
>>>> The old problem happens on Linux 3.7 ~ 3.10 with VT-d enabled. It
>>>> only
>>>> happened when not using Xen, so I added 'intel_iommu=off' to Linux
>>>> boot
>>>> arguments to workaround it.
>
> Hmm, do you see any chance in finding the commit which made it working
> again? Perhaps there was some workaround for this hardware which is
> missing in Xen now...

After some tests, I found the information I provided before was 
incorrect. It seems the problem happens on all Linux >= 3.7, including 
Linux 4.0.5, so the old problem was never fixed. Here are some 'dmesg | 
grep -i iommu' outputs.

Linux 3.6.11 with intel_iommu=on works fine.
[  +0.000000] Intel-IOMMU: enabled
[  +0.005366] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap 
c9008020e30272 ecap 1000
[  +0.005360] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap 
c0000020230272 ecap 1000
[  +0.005359] dmar: IOMMU 2: reg_base_addr fed93000 ver 1:0 cap 
c9008020630272 ecap 1000
[  +0.003267] IOMMU 0 0xfed90000: using Register based invalidation
[  +0.006143] IOMMU 2 0xfed93000: using Register based invalidation
[  +0.006141] IOMMU: Setting RMRR:
[  +0.003298] IOMMU: Setting identity map for device 0000:00:1d.0 
[0xd7aec000 - 0xd7afffff]
[  +0.008310] IOMMU: Setting identity map for device 0000:00:1a.0 
[0xd7aec000 - 0xd7afffff]
[  +0.008269] IOMMU: Setting identity map for device 0000:00:1d.0 
[0xe4000 - 0xe7fff]
[  +0.007753] IOMMU: Setting identity map for device 0000:00:1a.0 
[0xe4000 - 0xe7fff]
[  +0.007753] IOMMU: Prepare 0-16MiB unity mapping for LPC
[  +0.005376] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 
0xffffff]


Linux >= 3.7 without any intel_iommu argument works fine.
[  +0.005391] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap 
c9008020e30272 ecap 1000
[  +0.005385] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap 
c0000020230272 ecap 1000
[  +0.005384] dmar: IOMMU 2: reg_base_addr fed93000 ver 1:0 cap 
c9008020630272 ecap 1000


Linux >= 3.7 with intel_iommu=on causes grahpics problems.
[  +0.000000] Intel-IOMMU: enabled
[  +0.005391] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap 
c9008020e30272 ecap 1000
[  +0.005382] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap 
c0000020230272 ecap 1000
[  +0.005383] dmar: IOMMU 2: reg_base_addr fed93000 ver 1:0 cap 
c9008020630272 ecap 1000
[  +0.003430] IOMMU: dmar1 using Register based invalidation
[  +0.005553] IOMMU: dmar0 using Register based invalidation
[  +0.005559] IOMMU: dmar2 using Register based invalidation
[  +0.005560] IOMMU: Setting RMRR:
[  +0.003314] IOMMU: Setting identity map for device 0000:00:1a.0 
[0xd7aec000 - 0xd7afffff]
[  +0.008341] IOMMU: Setting identity map for device 0000:00:1d.0 
[0xd7aec000 - 0xd7afffff]
[  +0.008334] IOMMU: Setting identity map for device 0000:00:02.0 
[0xd7c00000 - 0xdfffffff]
[  +0.009797] IOMMU: Setting identity map for device 0000:00:1a.0 
[0xe4000 - 0xe7fff]
[  +0.007795] IOMMU: Setting identity map for device 0000:00:1d.0 
[0xe4000 - 0xe7fff]
[  +0.007798] IOMMU: Prepare 0-16MiB unity mapping for LPC
[  +0.005398] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 
0xffffff]


Linux >= 3.7 with intel_iommu=igfx_off works fine.
[  +0.000000] Intel-IOMMU: disable GFX device mapping
[  +0.005388] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap 
c9008020e30272 ecap 1000
[  +0.005385] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap 
c0000020230272 ecap 1000
[  +0.005383] dmar: IOMMU 2: reg_base_addr fed93000 ver 1:0 cap 
c9008020630272 ecap 1000


Linux >= 3.7 with both intel_iommu=on and intel_iommu=igfx_off also 
works fine.
[    0.000000] Intel-IOMMU: disable GFX device mapping
[    0.000000] Intel-IOMMU: enabled
[    0.205011] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap 
c9008020e30272 ecap 1000
[    0.218432] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap 
c0000020230272 ecap 1000
[    0.231848] dmar: IOMMU 2: reg_base_addr fed93000 ver 1:0 cap 
c9008020630272 ecap 1000
[    1.873199] IOMMU: dmar0 using Register based invalidation
[    1.878757] IOMMU: dmar2 using Register based invalidation
[    1.884315] IOMMU: Setting RMRR:
[    1.887631] IOMMU: Setting identity map for device 0000:00:1a.0 
[0xd7aec000 - 0xd7afffff]
[    1.895972] IOMMU: Setting identity map for device 0000:00:1d.0 
[0xd7aec000 - 0xd7afffff]
[    1.904285] IOMMU: Setting identity map for device 0000:00:1a.0 
[0xe4000 - 0xe7fff]
[    1.912079] IOMMU: Setting identity map for device 0000:00:1d.0 
[0xe4000 - 0xe7fff]
[    1.919871] IOMMU: Prepare 0-16MiB unity mapping for LPC
[    1.925268] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 
- 0xffffff]


The message 'IOMMU: Setting identity map for device 0000:00:02.0 
[0xd7c00000 - 0xdfffffff]' was added in Linux 3.7 with intel_iommu=on. 
0000:00:02.0 is the integrated graphics controller on my computer.

>
>
> Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[Juergen Gross]

On 06/16/2015 10:55 AM, Ting-Wei Lan wrote:
> Juergen Gross 於 西元2015年06月16日 12:30 寫道:
>> On 06/15/2015 09:03 PM, Ting-Wei Lan wrote:
>>> 於 一，2015-06-15 於 14:55 -0400，Konrad Rzeszutek Wilk 提到：
>>>> On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan wrote:
>>>>> When using Linux >= 3.19 as the dom0 kernel, characters on the
>>>>> screen become
>>>>> broken after the graphic driver is loaded. The commit that breaks
>>>>> it is
>>>>> (found by git bisect):
>>>>>
>>>>>
>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
>>>>> mit/?id=47591df
>>>>
>>>> Lets CC Juergen
>>>>>
>>>>>
>>>>> Screenshot when the system run in single user mode:
>>>>>
>>>>>    https://bugs.freedesktop.org/attachment.cgi?id=115079
>>
>> Are those messages to be expected:
>>
>> (XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs
>> (XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr
>> b61eef000, iommu reg = ffff82c000203000
>> (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
>> (XEN)
>> ..................................................................done.
>>
>> I'm not familiar with VT-D internals, but seeing these messages for the
>> video device during RAM scrubbing makes wonder if everything is correct
>> regarding the VT-D and memory setup...
...
>>>>> I still remember that there was a similar problem found two years
>>>>> ago on the
>>>>> same hardware with similar broken screen output and it also crashed
>>>>> after
>>>>> Xorg was started, but I cannot confirm that they are the same
>>>>> problems. I
>>>>> don't know whether error messages are simliar.
>>>>>
>>>>> The old problem happens on Linux 3.7 ~ 3.10 with VT-d enabled. It
>>>>> only
>>>>> happened when not using Xen, so I added 'intel_iommu=off' to Linux
>>>>> boot
>>>>> arguments to workaround it.
>>
>> Hmm, do you see any chance in finding the commit which made it working
>> again? Perhaps there was some workaround for this hardware which is
>> missing in Xen now...
>
> After some tests, I found the information I provided before was
> incorrect. It seems the problem happens on all Linux >= 3.7, including
> Linux 4.0.5, so the old problem was never fixed. Here are some 'dmesg |
> grep -i iommu' outputs.

So a Xen-specific error is rather improbable, correct?

I'd continue with sending the new information to the Intel graphics
team.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[藍挺瑋]

於 二，2015-06-16 於 11:06 +0200，Juergen Gross 提到：
> On 06/16/2015 10:55 AM, Ting-Wei Lan wrote:
> > Juergen Gross 於 西元2015年06月16日 12:30 寫道:
> > > On 06/15/2015 09:03 PM, Ting-Wei Lan wrote:
> > > > 於 一，2015-06-15 於 14:55 -0400，Konrad Rzeszutek Wilk 提到：
> > > > > On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan wrote:
> > > > > > When using Linux >= 3.19 as the dom0 kernel, characters on 
> > > > > > the
> > > > > > screen become
> > > > > > broken after the graphic driver is loaded. The commit that 
> > > > > > breaks
> > > > > > it is
> > > > > > (found by git bisect):
> > > > > > 
> > > > > > 
> > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux
> > > > > > .git/com
> > > > > > mit/?id=47591df
> > > > > 
> > > > > Lets CC Juergen
> > > > > > 
> > > > > > 
> > > > > > Screenshot when the system run in single user mode:
> > > > > > 
> > > > > >    https://bugs.freedesktop.org/attachment.cgi?id=115079
> > > 
> > > Are those messages to be expected:
> > > 
> > > (XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs
> > > (XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault 
> > > addr
> > > b61eef000, iommu reg = ffff82c000203000
> > > (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
> > > (XEN)
> > > .................................................................
> > > .done.
> > > 
> > > I'm not familiar with VT-D internals, but seeing these messages 
> > > for the
> > > video device during RAM scrubbing makes wonder if everything is 
> > > correct
> > > regarding the VT-D and memory setup...
> ...
> > > > > > I still remember that there was a similar problem found two 
> > > > > > years
> > > > > > ago on the
> > > > > > same hardware with similar broken screen output and it also 
> > > > > > crashed
> > > > > > after
> > > > > > Xorg was started, but I cannot confirm that they are the 
> > > > > > same
> > > > > > problems. I
> > > > > > don't know whether error messages are simliar.
> > > > > > 
> > > > > > The old problem happens on Linux 3.7 ~ 3.10 with VT-d 
> > > > > > enabled. It
> > > > > > only
> > > > > > happened when not using Xen, so I added 'intel_iommu=off' 
> > > > > > to Linux
> > > > > > boot
> > > > > > arguments to workaround it.
> > > 
> > > Hmm, do you see any chance in finding the commit which made it 
> > > working
> > > again? Perhaps there was some workaround for this hardware which 
> > > is
> > > missing in Xen now...
> > 
> > After some tests, I found the information I provided before was
> > incorrect. It seems the problem happens on all Linux >= 3.7, 
> > including
> > Linux 4.0.5, so the old problem was never fixed. Here are some 
> > 'dmesg |
> > grep -i iommu' outputs.
> 
> So a Xen-specific error is rather improbable, correct?

But Linux provides 'intel_iommu=igfx_off' to workaround the problem.
Does Xen provide similar things?

> 
> I'd continue with sending the new information to the Intel graphics
> team.

I am going to reopen DRM/Intel bug 90037 on freedesktop bugzilla.

> 
> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[Juergen Gross]

On 06/16/2015 11:32 AM, 藍挺瑋 wrote:
> 於 二，2015-06-16 於 11:06 +0200，Juergen Gross 提到：
>> On 06/16/2015 10:55 AM, Ting-Wei Lan wrote:
>>> Juergen Gross 於 西元2015年06月16日 12:30 寫道:
>>>> On 06/15/2015 09:03 PM, Ting-Wei Lan wrote:
>>>>> 於 一，2015-06-15 於 14:55 -0400，Konrad Rzeszutek Wilk 提到：
>>>>>> On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan wrote:
>>>>>>> When using Linux >= 3.19 as the dom0 kernel, characters on
>>>>>>> the
>>>>>>> screen become
>>>>>>> broken after the graphic driver is loaded. The commit that
>>>>>>> breaks
>>>>>>> it is
>>>>>>> (found by git bisect):
>>>>>>>
>>>>>>>
>>>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux
>>>>>>> .git/com
>>>>>>> mit/?id=47591df
>>>>>>
>>>>>> Lets CC Juergen
>>>>>>>
>>>>>>>
>>>>>>> Screenshot when the system run in single user mode:
>>>>>>>
>>>>>>>     https://bugs.freedesktop.org/attachment.cgi?id=115079
>>>>
>>>> Are those messages to be expected:
>>>>
>>>> (XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs
>>>> (XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault
>>>> addr
>>>> b61eef000, iommu reg = ffff82c000203000
>>>> (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
>>>> (XEN)
>>>> .................................................................
>>>> .done.
>>>>
>>>> I'm not familiar with VT-D internals, but seeing these messages
>>>> for the
>>>> video device during RAM scrubbing makes wonder if everything is
>>>> correct
>>>> regarding the VT-D and memory setup...
>> ...
>>>>>>> I still remember that there was a similar problem found two
>>>>>>> years
>>>>>>> ago on the
>>>>>>> same hardware with similar broken screen output and it also
>>>>>>> crashed
>>>>>>> after
>>>>>>> Xorg was started, but I cannot confirm that they are the
>>>>>>> same
>>>>>>> problems. I
>>>>>>> don't know whether error messages are simliar.
>>>>>>>
>>>>>>> The old problem happens on Linux 3.7 ~ 3.10 with VT-d
>>>>>>> enabled. It
>>>>>>> only
>>>>>>> happened when not using Xen, so I added 'intel_iommu=off'
>>>>>>> to Linux
>>>>>>> boot
>>>>>>> arguments to workaround it.
>>>>
>>>> Hmm, do you see any chance in finding the commit which made it
>>>> working
>>>> again? Perhaps there was some workaround for this hardware which
>>>> is
>>>> missing in Xen now...
>>>
>>> After some tests, I found the information I provided before was
>>> incorrect. It seems the problem happens on all Linux >= 3.7,
>>> including
>>> Linux 4.0.5, so the old problem was never fixed. Here are some
>>> 'dmesg |
>>> grep -i iommu' outputs.
>>
>> So a Xen-specific error is rather improbable, correct?
>
> But Linux provides 'intel_iommu=igfx_off' to workaround the problem.
> Does Xen provide similar things?

Not that I know of. The question is whether you really need VT-d, and if
yes, why. You could still switch the iommu off for dom0 by setting
iommu=dom0-passthrough in the Xen command line (your hardware might not
support it, though).


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[Ting-Wei Lan]

於 二，2015-06-16 於 11:58 +0200，Juergen Gross 提到：
> On 06/16/2015 11:32 AM, 藍挺瑋 wrote:
> > 於 二，2015-06-16 於 11:06 +0200，Juergen Gross 提到：
> > > On 06/16/2015 10:55 AM, Ting-Wei Lan wrote:
> > > > Juergen Gross 於 西元2015年06月16日 12:30 寫道:
> > > > > On 06/15/2015 09:03 PM, Ting-Wei Lan wrote:
> > > > > > 於 一，2015-06-15 於 14:55 -0400，Konrad Rzeszutek Wilk 提到：
> > > > > > > On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan 
> > > > > > > wrote:
> > > > > > > > When using Linux >= 3.19 as the dom0 kernel, characters 
> > > > > > > > on
> > > > > > > > the
> > > > > > > > screen become
> > > > > > > > broken after the graphic driver is loaded. The commit 
> > > > > > > > that
> > > > > > > > breaks
> > > > > > > > it is
> > > > > > > > (found by git bisect):
> > > > > > > > 
> > > > > > > > 
> > > > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/l
> > > > > > > > inux
> > > > > > > > .git/com
> > > > > > > > mit/?id=47591df
> > > > > > > 
> > > > > > > Lets CC Juergen
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Screenshot when the system run in single user mode:
> > > > > > > > 
> > > > > > > >     
> > > > > > > > https://bugs.freedesktop.org/attachment.cgi?id=115079
> > > > > 
> > > > > Are those messages to be expected:
> > > > > 
> > > > > (XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs
> > > > > (XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] 
> > > > > fault
> > > > > addr
> > > > > b61eef000, iommu reg = ffff82c000203000
> > > > > (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
> > > > > (XEN)
> > > > > .............................................................
> > > > > ....
> > > > > .done.
> > > > > 
> > > > > I'm not familiar with VT-D internals, but seeing these 
> > > > > messages
> > > > > for the
> > > > > video device during RAM scrubbing makes wonder if everything 
> > > > > is
> > > > > correct
> > > > > regarding the VT-D and memory setup...
> > > ...
> > > > > > > > I still remember that there was a similar problem found 
> > > > > > > > two
> > > > > > > > years
> > > > > > > > ago on the
> > > > > > > > same hardware with similar broken screen output and it 
> > > > > > > > also
> > > > > > > > crashed
> > > > > > > > after
> > > > > > > > Xorg was started, but I cannot confirm that they are 
> > > > > > > > the
> > > > > > > > same
> > > > > > > > problems. I
> > > > > > > > don't know whether error messages are simliar.
> > > > > > > > 
> > > > > > > > The old problem happens on Linux 3.7 ~ 3.10 with VT-d
> > > > > > > > enabled. It
> > > > > > > > only
> > > > > > > > happened when not using Xen, so I added 
> > > > > > > > 'intel_iommu=off'
> > > > > > > > to Linux
> > > > > > > > boot
> > > > > > > > arguments to workaround it.
> > > > > 
> > > > > Hmm, do you see any chance in finding the commit which made 
> > > > > it
> > > > > working
> > > > > again? Perhaps there was some workaround for this hardware 
> > > > > which
> > > > > is
> > > > > missing in Xen now...
> > > > 
> > > > After some tests, I found the information I provided before was
> > > > incorrect. It seems the problem happens on all Linux >= 3.7,
> > > > including
> > > > Linux 4.0.5, so the old problem was never fixed. Here are some
> > > > 'dmesg |
> > > > grep -i iommu' outputs.
> > > 
> > > So a Xen-specific error is rather improbable, correct?
> > 
> > But Linux provides 'intel_iommu=igfx_off' to workaround the 
> > problem.
> > Does Xen provide similar things?
> 
> Not that I know of. The question is whether you really need VT-d, and 
> if
> yes, why. You could still switch the iommu off for dom0 by setting
> iommu=dom0-passthrough in the Xen command line (your hardware might 
> not
> support it, though).

iommu=dom0-passthrough doesn't work on my hardware.

I found a workaround for my hardware:

diff --git a/xen/drivers/passthrough/vtd/quirks.c
b/xen/drivers/passthrough/vtd/quirks.c
index 69d29ab..b937ad0 100644
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -74,6 +74,7 @@ int is_igd_vt_enabled_quirk(void)
 
     if ( !IS_ILK(ioh_id) )
         return 1;
+    return 0;
 
     /* integrated graphics on Intel platforms is located at 0:2.0 */
     ggc = pci_conf_read16(0, 0, IGD_DEV, 0, GGC);


This workaround is silimar to intel_iommu=igfx_off in Linux. I found
silimar code in function quirk_calpella_no_shadow_gtt in
drivers/iommu/intel-iommu.c.


I reported the graphics corruption problems on Linux >= 3.7 here:
https://bugs.freedesktop.org/show_bug.cgi?id=91127

And here is the bug link of Xen and Linux >= 3.19 (the bug we are
discussing here):
https://bugs.freedesktop.org/show_bug.cgi?id=90037

I hope we can get a real fix.


> 
> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Work-arounds in Xen code for Intel GFX?Re: Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[Konrad Rzeszutek Wilk]

On Sun, Jun 28, 2015 at 05:15:28AM +0800, Ting-Wei Lan wrote:
> 於 二，2015-06-16 於 11:58 +0200，Juergen Gross 提到：
> > On 06/16/2015 11:32 AM, 藍挺瑋 wrote:
> > > 於 二，2015-06-16 於 11:06 +0200，Juergen Gross 提到：
> > > > On 06/16/2015 10:55 AM, Ting-Wei Lan wrote:
> > > > > Juergen Gross 於 西元2015年06月16日 12:30 寫道:
> > > > > > On 06/15/2015 09:03 PM, Ting-Wei Lan wrote:
> > > > > > > 於 一，2015-06-15 於 14:55 -0400，Konrad Rzeszutek Wilk 提到：
> > > > > > > > On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan 
> > > > > > > > wrote:
> > > > > > > > > When using Linux >= 3.19 as the dom0 kernel, characters 
> > > > > > > > > on
> > > > > > > > > the
> > > > > > > > > screen become
> > > > > > > > > broken after the graphic driver is loaded. The commit 
> > > > > > > > > that
> > > > > > > > > breaks
> > > > > > > > > it is
> > > > > > > > > (found by git bisect):
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/l
> > > > > > > > > inux
> > > > > > > > > .git/com
> > > > > > > > > mit/?id=47591df
> > > > > > > > 
> > > > > > > > Lets CC Juergen
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Screenshot when the system run in single user mode:
> > > > > > > > > 
> > > > > > > > >     
> > > > > > > > > https://bugs.freedesktop.org/attachment.cgi?id=115079
> > > > > > 
> > > > > > Are those messages to be expected:
> > > > > > 
> > > > > > (XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs
> > > > > > (XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] 
> > > > > > fault
> > > > > > addr
> > > > > > b61eef000, iommu reg = ffff82c000203000
> > > > > > (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
> > > > > > (XEN)
> > > > > > .............................................................
> > > > > > ....
> > > > > > .done.
> > > > > > 
> > > > > > I'm not familiar with VT-D internals, but seeing these 
> > > > > > messages
> > > > > > for the
> > > > > > video device during RAM scrubbing makes wonder if everything 
> > > > > > is
> > > > > > correct
> > > > > > regarding the VT-D and memory setup...
> > > > ...
> > > > > > > > > I still remember that there was a similar problem found 
> > > > > > > > > two
> > > > > > > > > years
> > > > > > > > > ago on the
> > > > > > > > > same hardware with similar broken screen output and it 
> > > > > > > > > also
> > > > > > > > > crashed
> > > > > > > > > after
> > > > > > > > > Xorg was started, but I cannot confirm that they are 
> > > > > > > > > the
> > > > > > > > > same
> > > > > > > > > problems. I
> > > > > > > > > don't know whether error messages are simliar.
> > > > > > > > > 
> > > > > > > > > The old problem happens on Linux 3.7 ~ 3.10 with VT-d
> > > > > > > > > enabled. It
> > > > > > > > > only
> > > > > > > > > happened when not using Xen, so I added 
> > > > > > > > > 'intel_iommu=off'
> > > > > > > > > to Linux
> > > > > > > > > boot
> > > > > > > > > arguments to workaround it.
> > > > > > 
> > > > > > Hmm, do you see any chance in finding the commit which made 
> > > > > > it
> > > > > > working
> > > > > > again? Perhaps there was some workaround for this hardware 
> > > > > > which
> > > > > > is
> > > > > > missing in Xen now...
> > > > > 
> > > > > After some tests, I found the information I provided before was
> > > > > incorrect. It seems the problem happens on all Linux >= 3.7,
> > > > > including
> > > > > Linux 4.0.5, so the old problem was never fixed. Here are some
> > > > > 'dmesg |
> > > > > grep -i iommu' outputs.
> > > > 
> > > > So a Xen-specific error is rather improbable, correct?
> > > 
> > > But Linux provides 'intel_iommu=igfx_off' to workaround the 
> > > problem.
> > > Does Xen provide similar things?
> > 
> > Not that I know of. The question is whether you really need VT-d, and 
> > if
> > yes, why. You could still switch the iommu off for dom0 by setting
> > iommu=dom0-passthrough in the Xen command line (your hardware might 
> > not
> > support it, though).
> 
> iommu=dom0-passthrough doesn't work on my hardware.
> 
> I found a workaround for my hardware:
> 
> diff --git a/xen/drivers/passthrough/vtd/quirks.c
> b/xen/drivers/passthrough/vtd/quirks.c
> index 69d29ab..b937ad0 100644
> --- a/xen/drivers/passthrough/vtd/quirks.c
> +++ b/xen/drivers/passthrough/vtd/quirks.c
> @@ -74,6 +74,7 @@ int is_igd_vt_enabled_quirk(void)
>  
>      if ( !IS_ILK(ioh_id) )
>          return 1;
> +    return 0;
>  
>      /* integrated graphics on Intel platforms is located at 0:2.0 */
>      ggc = pci_conf_read16(0, 0, IGD_DEV, 0, GGC);

Lets CC the maintaners of said code.
> 
> 
> This workaround is silimar to intel_iommu=igfx_off in Linux. I found
> silimar code in function quirk_calpella_no_shadow_gtt in
> drivers/iommu/intel-iommu.c.
> 
> 
> I reported the graphics corruption problems on Linux >= 3.7 here:
> https://bugs.freedesktop.org/show_bug.cgi?id=91127
> 
> And here is the bug link of Xen and Linux >= 3.19 (the bug we are
> discussing here):
> https://bugs.freedesktop.org/show_bug.cgi?id=90037
> 
> I hope we can get a real fix.
> 
> 
> > 
> > 
> > Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Work-arounds in Xen code for Intel GFX?Re: Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[Ting-Wei Lan]

> > > > But Linux provides 'intel_iommu=igfx_off' to workaround the 
> > > > problem.
> > > > Does Xen provide similar things?
> > > 
> > > Not that I know of. The question is whether you really need VT-d, 
> > > and 
> > > if
> > > yes, why. You could still switch the iommu off for dom0 by 
> > > setting
> > > iommu=dom0-passthrough in the Xen command line (your hardware 
> > > might 
> > > not
> > > support it, though).
> > 
> > iommu=dom0-passthrough doesn't work on my hardware.
> > 
> > I found a workaround for my hardware:
> > 
> > diff --git a/xen/drivers/passthrough/vtd/quirks.c
> > b/xen/drivers/passthrough/vtd/quirks.c
> > index 69d29ab..b937ad0 100644
> > --- a/xen/drivers/passthrough/vtd/quirks.c
> > +++ b/xen/drivers/passthrough/vtd/quirks.c
> > @@ -74,6 +74,7 @@ int is_igd_vt_enabled_quirk(void)
> >  
> >      if ( !IS_ILK(ioh_id) )
> >          return 1;
> > +    return 0;
> >  
> >      /* integrated graphics on Intel platforms is located at 0:2.0 
> > */
> >      ggc = pci_conf_read16(0, 0, IGD_DEV, 0, GGC);
> 
> Lets CC the maintaners of said code.
> > 
> > 
> > This workaround is silimar to intel_iommu=igfx_off in Linux. I 
> > found
> > silimar code in function quirk_calpella_no_shadow_gtt in
> > drivers/iommu/intel-iommu.c.

As I don't know how to properly fix the problem, I made a patch to add
iommu=igfx_off option to workaround the issue in Xen.

https://gist.github.com/lantw44/9f8a94d2eeb846889a5a

Is this patch acceptable, or we should wait for a fix instead?


> > 
> > 
> > I reported the graphics corruption problems on Linux >= 3.7 here:
> > https://bugs.freedesktop.org/show_bug.cgi?id=91127

It was partially fixed by this commit (available in Linux 4.2-rc2):
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
?id=8b572a4

But it seems it cannot be ported to Xen.


> > 
> > And here is the bug link of Xen and Linux >= 3.19 (the bug we are
> > discussing here):
> > https://bugs.freedesktop.org/show_bug.cgi?id=90037
> > 
> > I hope we can get a real fix.
> > 
> > 
> > > 
> > > 
> > > Juergen

Re: Work-arounds in Xen code for Intel GFX?Re: Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled

[Konrad Rzeszutek Wilk]

On Thu, Jul 16, 2015 at 11:35:34PM +0800, Ting-Wei Lan wrote:
> > > > > But Linux provides 'intel_iommu=igfx_off' to workaround the 
> > > > > problem.
> > > > > Does Xen provide similar things?
> > > > 
> > > > Not that I know of. The question is whether you really need VT-d, 
> > > > and 
> > > > if
> > > > yes, why. You could still switch the iommu off for dom0 by 
> > > > setting
> > > > iommu=dom0-passthrough in the Xen command line (your hardware 
> > > > might 
> > > > not
> > > > support it, though).
> > > 
> > > iommu=dom0-passthrough doesn't work on my hardware.
> > > 
> > > I found a workaround for my hardware:
> > > 
> > > diff --git a/xen/drivers/passthrough/vtd/quirks.c
> > > b/xen/drivers/passthrough/vtd/quirks.c
> > > index 69d29ab..b937ad0 100644
> > > --- a/xen/drivers/passthrough/vtd/quirks.c
> > > +++ b/xen/drivers/passthrough/vtd/quirks.c
> > > @@ -74,6 +74,7 @@ int is_igd_vt_enabled_quirk(void)
> > >  
> > >      if ( !IS_ILK(ioh_id) )
> > >          return 1;
> > > +    return 0;
> > >  
> > >      /* integrated graphics on Intel platforms is located at 0:2.0 
> > > */
> > >      ggc = pci_conf_read16(0, 0, IGD_DEV, 0, GGC);
> > 
> > Lets CC the maintaners of said code.
> > > 
> > > 
> > > This workaround is silimar to intel_iommu=igfx_off in Linux. I 
> > > found
> > > silimar code in function quirk_calpella_no_shadow_gtt in
> > > drivers/iommu/intel-iommu.c.
> 
> As I don't know how to properly fix the problem, I made a patch to add
> iommu=igfx_off option to workaround the issue in Xen.
> 
> https://gist.github.com/lantw44/9f8a94d2eeb846889a5a
> 
> Is this patch acceptable, or we should wait for a fix instead?

This would be the Intel VMX maintainers call. But I would just post
the patch with your Signed off By and make sure to CC xen-devel &
the VMX maintainers and see what they say.
> 
> 
> > > 
> > > 
> > > I reported the graphics corruption problems on Linux >= 3.7 here:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=91127
> 
> It was partially fixed by this commit (available in Linux 4.2-rc2):
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=8b572a4
> 
> But it seems it cannot be ported to Xen.
> 
> 
> > > 
> > > And here is the bug link of Xen and Linux >= 3.19 (the bug we are
> > > discussing here):
> > > https://bugs.freedesktop.org/show_bug.cgi?id=90037
> > > 
> > > I hope we can get a real fix.
> > > 
> > > 
> > > > 
> > > > 
> > > > Juergen