thr3ads.net - Xen devel - [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen [Sep 2010]

If this information is useful, please help other people find it:
Share via:

Dietmar Hahn

2010-Sep-17 13:20 UTC

[Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Hi list,

I have a problem with a new laptop (reproducable on other machines too) and the
xen hypervisor.
When the hypervisor gets booted with VESA mode 800x600 I see some messages and
then the screen contents is switched into a pattern of vertical colored lines
and never comes back.
In text mode all works well, but later the pattern appears when the X servers
starts.
I disabled VTd in the bios and now all went fine.
I saw this first with SLES11 SP1 but could reproduce it with the xen-unstable
hypervisor.

When I start the linux kernel native on the machine with or without VTd all
is running very well.

Following data:
cpu: Intel(R) Core(TM) i5 CPU  M 540  @ 2.53GHz with integrated graphics

#lspci
00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated
Graphics Controller (rev 02)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset
HECI Controller (rev 06)
00:16.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset PT IDER
Controller (rev 06)
00:16.3 Serial controller: Intel Corporation 5 Series/3400 Series Chipset KT
Controller (rev 06)
00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network
Connection (rev 05)
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2
Enhanced Host Controller (rev 05)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High
Definition Audio (rev 05)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express
Root Port 6 (rev 05)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2
Enhanced Host Controller (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface
Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port
SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller
(rev 05)
00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series
Chipset Thermal Subsystem (rev 05)
48:03.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 01)
48:03.1 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 01)
48:03.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 02)
48:03.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller (rev
02)
48:03.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 07)
ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture
Generic Non-core Registers (rev 02)
ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture
System Address Decoder (rev 02)
ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 02)
ff:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
ff:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 02)

I booted xen with VTd enabled and iommu=verbose an here are the messages:

 \ \/ /___ _ __  
  \  // _ \ ''_ \ 
  /  \  __/ | | |
 /_/\_\___|_| |_|
                 
  _  _    _   _     ____  _  _   _  _     _  _  _       _   ____    
 | || |  / _ \ / _ \   |___ \/ |/ _ \ / _ \/ |   / _ \| || |     / _ \ |___ \   
 | || |_| | | | | | |    __) | | | | | (_) | |  | | | | || |_ __| | | |  __) |  
 |__   _| |_| | |_| |   / __/| | |_| |\__, | |  | |_| |__   _|__| |_| | / __/ _ 
    |_|(_)___(_)___/___|_____|_|\___/   /_/|_|___\___/   |_|     \___(_)_____(_)
                  |_____|                   |_____|                             
   __   
  / /_  
 | ''_ \ 
 | (_) |
  \___/ 
        
(XEN) Xen version 4.0.0_21091_04-0.2.6 (abuild@) (gcc version 4.3.4
[gcc-4_3-branch revision 152973] (SUSE Linux) ) Thu May 20 11:44:41 UTC 2010
(XEN) Latest ChangeSet: 21091
(XEN) Console output is synchronous.
(XEN) Command line: vga=mode-0x314 console=com1,vga com1=38400 sync_console
debug=yes guest_loglvl=all iommu=verbose crashkernel=256M@16M
(XEN) Video information:
(XEN)  VGA is graphics mode 800x600, 16 bpp
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009bc00 (usable)
(XEN)  000000000009bc00 - 00000000000a0000 (reserved)
(XEN)  00000000000dc000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000ba95d000 (usable)
(XEN)  00000000ba95d000 - 00000000bac40000 (reserved)
(XEN)  00000000bac40000 - 00000000bb27c000 (usable)
(XEN)  00000000bb27c000 - 00000000bb282000 (reserved)
(XEN)  00000000bb282000 - 00000000bb3e0000 (usable)
(XEN)  00000000bb3e0000 - 00000000bb40f000 (reserved)
(XEN)  00000000bb40f000 - 00000000bb651000 (usable)
(XEN)  00000000bb651000 - 00000000bb652000 (reserved)
(XEN)  00000000bb652000 - 00000000bb6d3000 (ACPI NVS)
(XEN)  00000000bb6d3000 - 00000000bb70f000 (reserved)
(XEN)  00000000bb70f000 - 00000000bb717000 (usable)
(XEN)  00000000bb717000 - 00000000bb71f000 (reserved)
(XEN)  00000000bb71f000 - 00000000bb76f000 (usable)
(XEN)  00000000bb76f000 - 00000000bb79f000 (ACPI NVS)
(XEN)  00000000bb79f000 - 00000000bb7de000 (usable)
(XEN)  00000000bb7de000 - 00000000bb7ff000 (ACPI data)
(XEN)  00000000bb7ff000 - 00000000bb800000 (usable)
(XEN)  00000000bb800000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000f272c000 - 00000000f272d000 (reserved)
(XEN)  00000000feaff000 - 00000000feb00000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fed00000 - 00000000fed00400 (reserved)
(XEN)  00000000fed1c000 - 00000000fed90000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000138000000 (usable)
(XEN) Kdump: 256MB (262144kB) at 0x1000000
(XEN) ACPI: RSDP 000F5400, 0024 (r2 FUJ   )
(XEN) ACPI: XSDT BB7F29E3, 008C (r1 FSC    PC        1080000 FUJ       100)
(XEN) ACPI: FACP BB7E0000, 00F4 (r3 FSC    PC        1080000 FUJ       100)
(XEN) ACPI: DSDT BB7E1000, B8C7 (r2 FUJ    FJNB216   1080000 FUJ       100)
(XEN) ACPI: FACS BB78BFC0, 0040
(XEN) ACPI: SSDT BB7FE366, 00BA (r1 FUJ    FJNB216   1080000 FUJ       100)
(XEN) ACPI: HPET BB7FE514, 0038 (r1 FUJ    FJNB216   1080000 FUJ       100)
(XEN) ACPI: MCFG BB7FE54C, 003C (r1 FUJ    FJNB216   1080000 FUJ       100)
(XEN) ACPI: SSDT BB7FE588, 042F (r1 FUJ    FJNB216   1080000 FUJ       100)
(XEN) ACPI: SSDT BB7FE9B7, 02C3 (r1 FUJ    FJNB216   1080000 FUJ       100)
(XEN) ACPI: APIC BB7FEC7A, 0084 (r1 FUJ    FJNB216   1080000 FUJ       100)
(XEN) ACPI: SPCR BB7FECFE, 0050 (r1 FUJ    FJNB216   1080000 FUJ       100)
(XEN) ACPI: SLIC BB7FED4E, 0176 (r1 FSC    PC        1080000 FUJ       100)
(XEN) ACPI: BOOT BB7FEEC4, 0028 (r1 FUJ    FJNB216   1080000 FUJ       100)
(XEN) ACPI: ASF! BB7EE000, 00A0 (r16 FUJ    FJNB216   1080000 FUJ       100)
(XEN) ACPI: DMAR BB7ED000, 00B8 (r1 INTEL  CP_DALE         1 INTL        1)
(XEN) ACPI: SSDT BB7DF000, 0A50 (r1  PmRef    CpuPm     3000 INTL 20060912)
(XEN) System RAM: 3606MB (3692780kB)
(XEN) Domain heap initialised
(XEN) Processor #0 6:5 APIC version 21
(XEN) Processor #4 6:5 APIC version 21
(XEN) Processor #1 6:5 APIC version 21
(XEN) Processor #5 6:5 APIC version 21
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) [VT-D]dmar.c:679: Host address width 36
(XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:398:   dmaru->address = fed90000
(XEN) [VT-D]dmar.c:334:   endpoint: 0:1b.0
(XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:398:   dmaru->address = fed91000
(XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
(XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:398:   dmaru->address = fed93000
(XEN) [VT-D]dmar.c:411:   flags: INCLUDE_ALL
(XEN) [VT-D]dmar.c:699: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:334:   endpoint: 0:1d.0
(XEN) [VT-D]dmar.c:334:   endpoint: 0:1a.0
(XEN) [VT-D]dmar.c:571:   RMRR region: base_addr bb6e9000 end_address bb6fffff
(XEN) [VT-D]dmar.c:699: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
(XEN) [VT-D]dmar.c:571:   RMRR region: base_addr bde00000 end_address bfffffff
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2527.342 MHz processor.
(XEN) Initing memory sharing.
(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 detected.
(XEN) [VT-D]iommu.c:1078: drhd->address = fed91000 iommu->reg =
ffff82c3fff57000
(XEN) [VT-D]iommu.c:1080: cap = c0000020230272 ecap = 1000
(XEN) [VT-D]iommu.c:1078: drhd->address = fed90000 iommu->reg =
ffff82c3fff56000
(XEN) [VT-D]iommu.c:1080: cap = c9008020e30272 ecap = 1000
(XEN) [VT-D]iommu.c:1078: drhd->address = fed93000 iommu->reg =
ffff82c3fff55000
(XEN) [VT-D]iommu.c:1080: cap = c9008020630272 ecap = 1000
(XEN) Intel VT-d Snoop Control not supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation not supported.
(XEN) Intel VT-d Interrupt Remapping not supported.
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 16 KiB.
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) Brought up 4 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) Created cpupool 0 with scheduler SMP Credit Scheduler (credit)
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:0.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:2.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.2
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.3
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:19.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1a.0
(XEN) [VT-D]iommu.c:1325: d0:PCIe: map bdf = 0:1b.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1d.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.2
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.3
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.6
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.1
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.2
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.3
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.4
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.1
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.1
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.2
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.3
(XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff57000
(XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff56000
(XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff55000
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, lsb, paddr 0x2000 -> 0x765000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000132000000->0000000134000000 (874416 pages to be
allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff80002000->ffffffff80765000
(XEN)  Init. ramdisk: ffffffff80765000->ffffffff815b7600
(XEN)  Phys-Mach map: ffffea0000000000->ffffea00006bbd80
(XEN)  Start info:    ffffffff815b8000->ffffffff815b84b4
(XEN)  Page tables:   ffffffff815b9000->ffffffff815c8000
(XEN)  Boot stack:    ffffffff815c8000->ffffffff815c9000
(XEN)  TOTAL:         ffffffff80000000->ffffffff81800000
(XEN)  ENTRY ADDRESS: ffffffff80002000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1... 
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times
to switch input to Xen)
(XEN) Freed 184kB init memory.

With staring at the console I could see that the switch to the screen pattern is
around the following messages (but no guarantee):
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.1
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.0
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.1
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.2
(XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.3

I would say that this is a problem with the bios tables or with the
hypervisor not handle these right. Always the switching of the gfx card into
graphics mode seems to lead to the problem.
Any help would be very helpful.
Thanks.

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Konrad Rzeszutek Wilk

2010-Sep-20 20:59 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

On Fri, Sep 17, 2010 at 03:20:11PM +0200, Dietmar Hahn
wrote:> Hi list,
> 
> I have a problem with a new laptop (reproducable on other machines too) and
the
> xen hypervisor.
> When the hypervisor gets booted with VESA mode 800x600 I see some messages
and
> then the screen contents is switched into a pattern of vertical colored
lines
> and never comes back.
> In text mode all works well, but later the pattern appears when the X
servers
> starts.
> I disabled VTd in the bios and now all went fine.
So no VT-d and the you have no trouble even with VESA 800x600? Are there any
errors reported by Xen when you use VT-d? Can you ping the machine even
if the screen is showing vertical lines?> I saw this first with SLES11 SP1 but could reproduce it with the
xen-unstable
> hypervisor.
What about the Linux kernel? Is this happening when you use the PVOPS kernel?

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

Dietmar Hahn

2010-Sep-21 07:19 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Am 20.09.2010 schrieb Konrad Rzeszutek Wilk:> On Fri, Sep 17, 2010 at 03:20:11PM +0200, Dietmar Hahn wrote:
> > Hi list,
> > 
> > I have a problem with a new laptop (reproducable on other machines
too) and the
> > xen hypervisor.
> > When the hypervisor gets booted with VESA mode 800x600 I see some
messages and
> > then the screen contents is switched into a pattern of vertical
colored lines
> > and never comes back.
> 
> > In text mode all works well, but later the pattern appears when the X
servers
> > starts.
> > I disabled VTd in the bios and now all went fine.
> 
> So no VT-d and the you have no trouble even with VESA 800x600? Yes!
> Are there any
> errors reported by Xen when you use VT-d?In the original mail I sent the full hypervisor log from the error case (VT-d
switched on). I couldn''t spot an error message.
> Can you ping the machine even
> if the screen is showing vertical lines?Yes the machine runs well. I can work remotely. Only the console is affected.
> > I saw this first with SLES11 SP1 but could reproduce it with the
xen-unstable
> > hypervisor.
> 
> What about the Linux kernel? Is this happening when you use the PVOPS
kernel?
> I didn''t try this out because at the end I could reproduce this
behaviour while
booting the hypervisor and before dom0 starts.
Another thing is when starting the X server I see kernel messages in a loop:
[ 1193.549808] [drm:i915_hangcheck_elapsed] ERROR Hangcheck timer elapsed... GPU
hung
[ 1193.572464] render error detected, EIR: 0x00000000
[ 1193.586720] i915: Waking up sleeping processes
[ 1193.600679] [drm:i915_do_wait_request] ERROR i915_do_wait_request returns -5
(awaiting 1 at 0)
dom0 kernel is from SLES11 SP1 2.6.32.12-0.7-xen.
As in the orignal mail mentioned I would assume it''s a problem with the
bios
and maybe some access stuff due to the iommu. But I''am not familiar
enough with
this.
So I hoped anybody on the list could give me a hint while reading the logs in
my original mail ;-)
Thanks.

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Konrad Rzeszutek Wilk

2010-Sep-21 14:42 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

On Tue, Sep 21, 2010 at 09:19:51AM +0200, Dietmar Hahn
wrote:> Am 20.09.2010 schrieb Konrad Rzeszutek Wilk:
> > On Fri, Sep 17, 2010 at 03:20:11PM +0200, Dietmar Hahn wrote:
> > > Hi list,
> > > 
> > > I have a problem with a new laptop (reproducable on other
machines too) and the
> > > xen hypervisor.
> > > When the hypervisor gets booted with VESA mode 800x600 I see some
messages and
> > > then the screen contents is switched into a pattern of vertical
colored lines
> > > and never comes back.
> > 
> > > In text mode all works well, but later the pattern appears when
the X servers
> > > starts.
> > > I disabled VTd in the bios and now all went fine.
> > 
> > So no VT-d and the you have no trouble even with VESA 800x600? 
> Yes!
And if you have VT-d enabled and you don''t include the
"vga=mode-0x314" then
it works fine too?

Just curious, but why did you try the ''vga=mode''
option?> 
> > Are there any
> > errors reported by Xen when you use VT-d?
> In the original mail I sent the full hypervisor log from the error case
(VT-d
> switched on). I couldn''t spot an error message.
> 
> > Can you ping the machine even
> > if the screen is showing vertical lines?
> Yes the machine runs well. I can work remotely. Only the console is
affected.
> 
> > > I saw this first with SLES11 SP1 but could reproduce it with the
xen-unstable
> > > hypervisor.
> > 
> > What about the Linux kernel? Is this happening when you use the PVOPS
kernel?
> > 
> I didn''t try this out because at the end I could reproduce this
behaviour while
> booting the hypervisor and before dom0 starts.
> Another thing is when starting the X server I see kernel messages in a
loop:
> [ 1193.549808] [drm:i915_hangcheck_elapsed] ERROR Hangcheck timer
elapsed... GPU hung
> [ 1193.572464] render error detected, EIR: 0x00000000
> [ 1193.586720] i915: Waking up sleeping processes
> [ 1193.600679] [drm:i915_do_wait_request] ERROR i915_do_wait_request
returns -5 (awaiting 1 at 0)
Ugh, that looks nasty.> dom0 kernel is from SLES11 SP1 2.6.32.12-0.7-xen.
> As in the orignal mail mentioned I would assume it''s a problem
with the bios
> and maybe some access stuff due to the iommu. But I''am not
familiar enough with
> this.
> So I hoped anybody on the list could give me a hint while reading the logs
in
> my original mail ;-)
> Thanks.
> 
> Dietmar.
> 
> -- 
> Company details: http://ts.fujitsu.com/imprint.html
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Dietmar Hahn

2010-Sep-22 13:06 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Am 21.09.2010 schrieb Konrad Rzeszutek Wilk:> On Tue, Sep 21, 2010 at 09:19:51AM +0200, Dietmar Hahn wrote:
> > Am 20.09.2010 schrieb Konrad Rzeszutek Wilk:
> > > On Fri, Sep 17, 2010 at 03:20:11PM +0200, Dietmar Hahn wrote:
> > > > Hi list,
> > > > 
> > > > I have a problem with a new laptop (reproducable on other
machines too) and the
> > > > xen hypervisor.
> > > > When the hypervisor gets booted with VESA mode 800x600 I see
some messages and
> > > > then the screen contents is switched into a pattern of
vertical colored lines
> > > > and never comes back.
> > > 
> > > > In text mode all works well, but later the pattern appears
when the X servers
> > > > starts.
> > > > I disabled VTd in the bios and now all went fine.
> > > 
> > > So no VT-d and the you have no trouble even with VESA 800x600? 
> > Yes!
> 
> And if you have VT-d enabled and you don''t include the
"vga=mode-0x314" then
> it works fine too?
Yes but only the boot process (in default text mode) until the Xserver starts.
> 
> Just curious, but why did you try the ''vga=mode'' option?
The vga option gets set somewhere in the installation procedure.
> > 
> > > Are there any
> > > errors reported by Xen when you use VT-d?
> > In the original mail I sent the full hypervisor log from the error
case (VT-d
> > switched on). I couldn''t spot an error message.
> > 
> > > Can you ping the machine even
> > > if the screen is showing vertical lines?
> > Yes the machine runs well. I can work remotely. Only the console is
affected.
> > 
> > > > I saw this first with SLES11 SP1 but could reproduce it with
the xen-unstable
> > > > hypervisor.
> > > 
> > > What about the Linux kernel? Is this happening when you use the
PVOPS kernel?
> > > 
> > I didn''t try this out because at the end I could reproduce
this behaviour while
> > booting the hypervisor and before dom0 starts.
> > Another thing is when starting the X server I see kernel messages in a
loop:
> > [ 1193.549808] [drm:i915_hangcheck_elapsed] ERROR Hangcheck timer
elapsed... GPU hung
> > [ 1193.572464] render error detected, EIR: 0x00000000
> > [ 1193.586720] i915: Waking up sleeping processes
> > [ 1193.600679] [drm:i915_do_wait_request] ERROR i915_do_wait_request
returns -5 (awaiting 1 at 0)
> 
> Ugh, that looks nasty.
Yes!
> > dom0 kernel is from SLES11 SP1 2.6.32.12-0.7-xen.
> > As in the orignal mail mentioned I would assume it''s a
problem with the bios
> > and maybe some access stuff due to the iommu. But I''am not
familiar enough with
> > this.
> > So I hoped anybody on the list could give me a hint while reading the
logs in
> > my original mail ;-)
> > Thanks.
> > 
> > Dietmar.-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Konrad Rzeszutek Wilk

2010-Sep-22 13:56 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

On Wed, Sep 22, 2010 at 03:06:14PM +0200, Dietmar Hahn
wrote:> Am 21.09.2010 schrieb Konrad Rzeszutek Wilk:
> > On Tue, Sep 21, 2010 at 09:19:51AM +0200, Dietmar Hahn wrote:
> > > Am 20.09.2010 schrieb Konrad Rzeszutek Wilk:
> > > > On Fri, Sep 17, 2010 at 03:20:11PM +0200, Dietmar Hahn
wrote:
> > > > > Hi list,
> > > > > 
> > > > > I have a problem with a new laptop (reproducable on
other machines too) and the
> > > > > xen hypervisor.
> > > > > When the hypervisor gets booted with VESA mode 800x600
I see some messages and
> > > > > then the screen contents is switched into a pattern of
vertical colored lines
> > > > > and never comes back.
> > > > 
> > > > > In text mode all works well, but later the pattern
appears when the X servers
> > > > > starts.
> > > > > I disabled VTd in the bios and now all went fine.
> > > > 
> > > > So no VT-d and the you have no trouble even with VESA
800x600?
> > > Yes!
> > 
> > And if you have VT-d enabled and you don''t include the
"vga=mode-0x314" then
> > it works fine too?
> 
> Yes but only the boot process (in default text mode) until the Xserver
starts.
Aaaaah, so the VT-d is a red-herring - it does not matter.

.. snip ..> > > booting the hypervisor and before dom0 starts.
> > > Another thing is when starting the X server I see kernel messages
in a loop:
> > > [ 1193.549808] [drm:i915_hangcheck_elapsed] ERROR Hangcheck timer
elapsed... GPU hung
> > > [ 1193.572464] render error detected, EIR: 0x00000000
> > > [ 1193.586720] i915: Waking up sleeping processes
> > > [ 1193.600679] [drm:i915_do_wait_request] ERROR
i915_do_wait_request returns -5 (awaiting 1 at 0)
> > 
> > Ugh, that looks nasty.
> 
> Yes!
I don''t know much about the SLES11 kernel, but I know that I fixed a
lot of KMS/DRM
issues with the PVOPS kernel. It might be that some of those fixes
didn''t make it
in the SLES11 kernel.

The details are on http://wiki.xensource.com/xenwiki/XenPVOPSDRM

but you have an i915 and there weren''t much of changes in the area.
The big one for the PVOPS was that you had to have CONFIG_DMAR enabled
so that the code for programming the GART would use the PCI API.

My recommendation is to check the .config to see if CONFIG_DMAR
was enabled for your kernel. After that, take a whirl with the
PVOPS kernel: http://wiki.xensource.com/xenwiki/XenParavirtOps

Lastly, did a baremetal kernel work on this machine with X? That is
a kernel without the Xen hypervisor running alongside?

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

Jan Beulich

2010-Sep-22 14:23 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

>>> On 22.09.10 at 15:06, Dietmar Hahn
<dietmar.hahn@ts.fujitsu.com> wrote:
>> And if you have VT-d enabled and you don''t include the
"vga=mode-0x314" then
>> it works fine too?
> 
> Yes but only the boot process (in default text mode) until the Xserver 
> starts.
Did you ever try "mem=4G" on the Xen command line?

Jan


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

Dietmar Hahn

2010-Sep-23 11:53 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Am 22.09.2010 schrieb Jan Beulich:> >>> On 22.09.10 at 15:06, Dietmar Hahn
<dietmar.hahn@ts.fujitsu.com> wrote:
> >> And if you have VT-d enabled and you don''t include the
"vga=mode-0x314" then
> >> it works fine too?
> > 
> > Yes but only the boot process (in default text mode) until the Xserver
> > starts.
> 
> Did you ever try "mem=4G" on the Xen command line?
Yes I tried this, no success.
Dietmar.
> 
> Jan
-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Dietmar Hahn

2010-Sep-23 11:53 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Hi Konrad,

first thanks for trying to help, but it seems I didn''t explain the
problem not
clear enough.

Am 22.09.2010 schrieb Konrad Rzeszutek Wilk:
> I don''t know much about the SLES11 kernel, but I know that I fixed
a lot of KMS/DRM
> issues with the PVOPS kernel. It might be that some of those fixes
didn''t make it
> in the SLES11 kernel.
> 
> The details are on http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> 
> but you have an i915 and there weren''t much of changes in the
area.
> The big one for the PVOPS was that you had to have CONFIG_DMAR enabled
> so that the code for programming the GART would use the PCI API.
I will have a look on this to understand the behavior ;-)
> 
> My recommendation is to check the .config to see if CONFIG_DMAR
> was enabled for your kernel. After that, take a whirl with the
> PVOPS kernel: http://wiki.xensource.com/xenwiki/XenParavirtOps
> 
> Lastly, did a baremetal kernel work on this machine with X? That is
> a kernel without the Xen hypervisor running alongside?
Yes the SLES11 SP1 linux kernel with X11 works flawless.

In my original mail I wrote at the end:
> With staring at the console I could see that the switch to the screen
pattern is
> around the following messages (but no guarantee):
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.1
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.1
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.2
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.3
What I wanted to say is, I don''t need a linux kernel to reproduce the
problem!
With the argument vga=mode-0x314 on the Xen command line the screen gets
patterned while booting only the hypervisor.
As I have the test machine back again I will try to isolate the excat location
in the hypervisor where this effect gets triggered.
Thanks.

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Dietmar Hahn

2010-Sep-24 09:50 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Am 23.09.2010 schrieb Dietmar Hahn:> 
> What I wanted to say is, I don''t need a linux kernel to reproduce
the problem!
> With the argument vga=mode-0x314 on the Xen command line the screen gets
> patterned while booting only the hypervisor.
I added some tracer in the hypervisor and found that the screen gets patterned
when calling iommu_enable_translation() for the graphics device.

...
(XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:398:   dmaru->address = fed91000
(XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
...
(XEN) [VT-D]iommu.c:1097: drhd->address = fed91000 iommu->reg =
ffff82c3fff57000
...
(XEN) [VT-D]iommu.c:709: iommu_enable_translation: iommu->reg =
ffff82c3fff57000
  -> Here the screen gets patterned after setting the DMA_GCMD_TE bit.

My test machine is a laptop with a Intel cpu "i5 M540" and a
"Intel QM57"
chipset.
If anybody owns such a hardware and VT-d is working with the graphics device
then please set iommu=verbose on the Xen command line and send me the
(XEN)... logging of the serial console or "xm dmesg" output.
Thanks.

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Jean Guyader

2010-Sep-24 10:19 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Hi,

Is it a Lenovo (T410, T510) by any chance?

Jean

On 17 September 2010 14:20, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
wrote:> Hi list,
>
> I have a problem with a new laptop (reproducable on other machines too) and
the
> xen hypervisor.
> When the hypervisor gets booted with VESA mode 800x600 I see some messages
and
> then the screen contents is switched into a pattern of vertical colored
lines
> and never comes back.
> In text mode all works well, but later the pattern appears when the X
servers
> starts.
> I disabled VTd in the bios and now all went fine.
> I saw this first with SLES11 SP1 but could reproduce it with the
xen-unstable
> hypervisor.
>
> When I start the linux kernel native on the machine with or without VTd all
> is running very well.
>
> Following data:
> cpu: Intel(R) Core(TM) i5 CPU  M 540  @ 2.53GHz with integrated graphics
>
> #lspci
> 00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev
02)
> 00:02.0 VGA compatible controller: Intel Corporation Core Processor
Integrated Graphics Controller (rev 02)
> 00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series
Chipset HECI Controller (rev 06)
> 00:16.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset PT
IDER Controller (rev 06)
> 00:16.3 Serial controller: Intel Corporation 5 Series/3400 Series Chipset
KT Controller (rev 06)
> 00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network
Connection (rev 05)
> 00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2
Enhanced Host Controller (rev 05)
> 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High
Definition Audio (rev 05)
> 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 6 (rev 05)
> 00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2
Enhanced Host Controller (rev 05)
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a5)
> 00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface
Controller (rev 05)
> 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6
port SATA AHCI Controller (rev 05)
> 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus
Controller (rev 05)
> 00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400
Series Chipset Thermal Subsystem (rev 05)
> 48:03.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 01)
> 48:03.1 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 01)
> 48:03.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller
(rev 02)
> 48:03.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller
(rev 02)
> 48:03.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 07)
> ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath
Architecture Generic Non-core Registers (rev 02)
> ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath
Architecture System Address Decoder (rev 02)
> ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
> ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev
02)
> ff:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
> ff:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
>
> I booted xen with VTd enabled and iommu=verbose an here are the messages:
>
>  \ \/ /___ _ __
>  \  // _ \ ''_ \
>  /  \  __/ | | |
>  /_/\_\___|_| |_|
>
>  _  _    _   _     ____  _  _   _  _     _  _  _       _   ____
>  | || |  / _ \ / _ \   |___ \/ |/ _ \ / _ \/ |   / _ \| || |     / _ \ |___
\
>  | || |_| | | | | | |    __) | | | | | (_) | |  | | | | || |_ __| | | |
 __) |
>  |__   _| |_| | |_| |   / __/| | |_| |\__, | |  | |_| |__   _|__| |_| | /
__/ _
>    |_|(_)___(_)___/___|_____|_|\___/   /_/|_|___\___/   |_|    
\___(_)_____(_)
>                  |_____|                   |_____|
>   __
>  / /_
>  | ''_ \
>  | (_) |
>  \___/
>
> (XEN) Xen version 4.0.0_21091_04-0.2.6 (abuild@) (gcc version 4.3.4
[gcc-4_3-branch revision 152973] (SUSE Linux) ) Thu May 20 11:44:41 UTC 2010
> (XEN) Latest ChangeSet: 21091
> (XEN) Console output is synchronous.
> (XEN) Command line: vga=mode-0x314 console=com1,vga com1=38400 sync_console
debug=yes guest_loglvl=all iommu=verbose crashkernel=256M@16M
> (XEN) Video information:
> (XEN)  VGA is graphics mode 800x600, 16 bpp
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 2 MBR signatures
> (XEN)  Found 2 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009bc00 (usable)
> (XEN)  000000000009bc00 - 00000000000a0000 (reserved)
> (XEN)  00000000000dc000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 00000000ba95d000 (usable)
> (XEN)  00000000ba95d000 - 00000000bac40000 (reserved)
> (XEN)  00000000bac40000 - 00000000bb27c000 (usable)
> (XEN)  00000000bb27c000 - 00000000bb282000 (reserved)
> (XEN)  00000000bb282000 - 00000000bb3e0000 (usable)
> (XEN)  00000000bb3e0000 - 00000000bb40f000 (reserved)
> (XEN)  00000000bb40f000 - 00000000bb651000 (usable)
> (XEN)  00000000bb651000 - 00000000bb652000 (reserved)
> (XEN)  00000000bb652000 - 00000000bb6d3000 (ACPI NVS)
> (XEN)  00000000bb6d3000 - 00000000bb70f000 (reserved)
> (XEN)  00000000bb70f000 - 00000000bb717000 (usable)
> (XEN)  00000000bb717000 - 00000000bb71f000 (reserved)
> (XEN)  00000000bb71f000 - 00000000bb76f000 (usable)
> (XEN)  00000000bb76f000 - 00000000bb79f000 (ACPI NVS)
> (XEN)  00000000bb79f000 - 00000000bb7de000 (usable)
> (XEN)  00000000bb7de000 - 00000000bb7ff000 (ACPI data)
> (XEN)  00000000bb7ff000 - 00000000bb800000 (usable)
> (XEN)  00000000bb800000 - 00000000c0000000 (reserved)
> (XEN)  00000000e0000000 - 00000000f0000000 (reserved)
> (XEN)  00000000f272c000 - 00000000f272d000 (reserved)
> (XEN)  00000000feaff000 - 00000000feb00000 (reserved)
> (XEN)  00000000fec00000 - 00000000fec10000 (reserved)
> (XEN)  00000000fed00000 - 00000000fed00400 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed90000 (reserved)
> (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
> (XEN)  00000000ff000000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000000138000000 (usable)
> (XEN) Kdump: 256MB (262144kB) at 0x1000000
> (XEN) ACPI: RSDP 000F5400, 0024 (r2 FUJ   )
> (XEN) ACPI: XSDT BB7F29E3, 008C (r1 FSC    PC        1080000 FUJ       100)
> (XEN) ACPI: FACP BB7E0000, 00F4 (r3 FSC    PC        1080000 FUJ       100)
> (XEN) ACPI: DSDT BB7E1000, B8C7 (r2 FUJ    FJNB216   1080000 FUJ       100)
> (XEN) ACPI: FACS BB78BFC0, 0040
> (XEN) ACPI: SSDT BB7FE366, 00BA (r1 FUJ    FJNB216   1080000 FUJ       100)
> (XEN) ACPI: HPET BB7FE514, 0038 (r1 FUJ    FJNB216   1080000 FUJ       100)
> (XEN) ACPI: MCFG BB7FE54C, 003C (r1 FUJ    FJNB216   1080000 FUJ       100)
> (XEN) ACPI: SSDT BB7FE588, 042F (r1 FUJ    FJNB216   1080000 FUJ       100)
> (XEN) ACPI: SSDT BB7FE9B7, 02C3 (r1 FUJ    FJNB216   1080000 FUJ       100)
> (XEN) ACPI: APIC BB7FEC7A, 0084 (r1 FUJ    FJNB216   1080000 FUJ       100)
> (XEN) ACPI: SPCR BB7FECFE, 0050 (r1 FUJ    FJNB216   1080000 FUJ       100)
> (XEN) ACPI: SLIC BB7FED4E, 0176 (r1 FSC    PC        1080000 FUJ       100)
> (XEN) ACPI: BOOT BB7FEEC4, 0028 (r1 FUJ    FJNB216   1080000 FUJ       100)
> (XEN) ACPI: ASF! BB7EE000, 00A0 (r16 FUJ    FJNB216   1080000 FUJ      
100)
> (XEN) ACPI: DMAR BB7ED000, 00B8 (r1 INTEL  CP_DALE         1 INTL        1)
> (XEN) ACPI: SSDT BB7DF000, 0A50 (r1  PmRef    CpuPm     3000 INTL 20060912)
> (XEN) System RAM: 3606MB (3692780kB)
> (XEN) Domain heap initialised
> (XEN) Processor #0 6:5 APIC version 21
> (XEN) Processor #4 6:5 APIC version 21
> (XEN) Processor #1 6:5 APIC version 21
> (XEN) Processor #5 6:5 APIC version 21
> (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> (XEN) [VT-D]dmar.c:679: Host address width 36
> (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
> (XEN) [VT-D]dmar.c:398:   dmaru->address = fed90000
> (XEN) [VT-D]dmar.c:334:   endpoint: 0:1b.0
> (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
> (XEN) [VT-D]dmar.c:398:   dmaru->address = fed91000
> (XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
> (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
> (XEN) [VT-D]dmar.c:398:   dmaru->address = fed93000
> (XEN) [VT-D]dmar.c:411:   flags: INCLUDE_ALL
> (XEN) [VT-D]dmar.c:699: found ACPI_DMAR_RMRR:
> (XEN) [VT-D]dmar.c:334:   endpoint: 0:1d.0
> (XEN) [VT-D]dmar.c:334:   endpoint: 0:1a.0
> (XEN) [VT-D]dmar.c:571:   RMRR region: base_addr bb6e9000 end_address
bb6fffff
> (XEN) [VT-D]dmar.c:699: found ACPI_DMAR_RMRR:
> (XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
> (XEN) [VT-D]dmar.c:571:   RMRR region: base_addr bde00000 end_address
bfffffff
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2527.342 MHz processor.
> (XEN) Initing memory sharing.
> (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 detected.
> (XEN) [VT-D]iommu.c:1078: drhd->address = fed91000 iommu->reg =
ffff82c3fff57000
> (XEN) [VT-D]iommu.c:1080: cap = c0000020230272 ecap = 1000
> (XEN) [VT-D]iommu.c:1078: drhd->address = fed90000 iommu->reg =
ffff82c3fff56000
> (XEN) [VT-D]iommu.c:1080: cap = c9008020e30272 ecap = 1000
> (XEN) [VT-D]iommu.c:1078: drhd->address = fed93000 iommu->reg =
ffff82c3fff55000
> (XEN) [VT-D]iommu.c:1080: cap = c9008020630272 ecap = 1000
> (XEN) Intel VT-d Snoop Control not supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation not supported.
> (XEN) Intel VT-d Interrupt Remapping not supported.
> (XEN) I/O virtualisation enabled
> (XEN) I/O virtualisation for PV guests disabled
> (XEN) Enabled directed EOI with ioapic_ack_old on!
> (XEN) Total of 4 processors activated.
> (XEN) ENABLING IO-APIC IRQs
> (XEN)  -> Using old ACK method
> (XEN) TSC is reliable, synchronization unnecessary
> (XEN) Platform timer is 14.318MHz HPET
> (XEN) Allocated console ring of 16 KiB.
> (XEN) microcode.c:73:d32767 microcode: CPU1 resumed
> (XEN) microcode.c:73:d32767 microcode: CPU3 resumed
> (XEN) Brought up 4 CPUs
> (XEN) microcode.c:73:d32767 microcode: CPU2 resumed
> (XEN) Created cpupool 0 with scheduler SMP Credit Scheduler (credit)
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:0.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:2.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.2
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.3
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:19.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1a.0
> (XEN) [VT-D]iommu.c:1325: d0:PCIe: map bdf = 0:1b.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1d.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.2
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.3
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.6
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.1
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.2
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.3
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.4
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.1
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.1
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.2
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.3
> (XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff57000
> (XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff56000
> (XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff55000
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN)  Xen  kernel: 64-bit, lsb, compat32
> (XEN)  Dom0 kernel: 64-bit, lsb, paddr 0x2000 -> 0x765000
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN)  Dom0 alloc.:   0000000132000000->0000000134000000 (874416 pages
to be allocated)
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN)  Loaded kernel: ffffffff80002000->ffffffff80765000
> (XEN)  Init. ramdisk: ffffffff80765000->ffffffff815b7600
> (XEN)  Phys-Mach map: ffffea0000000000->ffffea00006bbd80
> (XEN)  Start info:    ffffffff815b8000->ffffffff815b84b4
> (XEN)  Page tables:   ffffffff815b9000->ffffffff815c8000
> (XEN)  Boot stack:    ffffffff815c8000->ffffffff815c9000
> (XEN)  TOTAL:         ffffffff80000000->ffffffff81800000
> (XEN)  ENTRY ADDRESS: ffffffff80002000
> (XEN) Dom0 has maximum 4 VCPUs
> (XEN) Scrubbing Free RAM: .done.
> (XEN) Xen trace buffers: disabled
> (XEN) Std. Loglevel: Errors and warnings
> (XEN) Guest Loglevel: All
> (XEN) **********************************************
> (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
> (XEN) ******* This option is intended to aid debugging of Xen by ensuring
> (XEN) ******* that all output is synchronously delivered on the serial
line.
> (XEN) ******* However it can introduce SIGNIFICANT latencies and affect
> (XEN) ******* timekeeping. It is NOT recommended for production use!
> (XEN) **********************************************
> (XEN) 3... 2... 1...
> (XEN) Xen is relinquishing VGA console.
> (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three
times to switch input to Xen)
> (XEN) Freed 184kB init memory.
>
> With staring at the console I could see that the switch to the screen
pattern is
> around the following messages (but no guarantee):
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.1
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.0
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.1
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.2
> (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.3
>
> I would say that this is a problem with the bios tables or with the
> hypervisor not handle these right. Always the switching of the gfx card
into
> graphics mode seems to lead to the problem.
> Any help would be very helpful.
> Thanks.
>
> Dietmar.
>
> --
> Company details: http://ts.fujitsu.com/imprint.html
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Dietmar Hahn

2010-Sep-24 11:10 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Am 24.09.2010 schrieb Jean Guyader:> Hi,
> 
> Is it a Lenovo (T410, T510) by any chance?
No, it''s a Fujitsu Lifebook S760, same problem with S710.

Dietmar.
> 
> Jean
> 
> On 17 September 2010 14:20, Dietmar Hahn
<dietmar.hahn@ts.fujitsu.com> wrote:
> > Hi list,
> >
> > I have a problem with a new laptop (reproducable on other machines
too) and the
> > xen hypervisor.
> > When the hypervisor gets booted with VESA mode 800x600 I see some
messages and
> > then the screen contents is switched into a pattern of vertical
colored lines
> > and never comes back.
> > In text mode all works well, but later the pattern appears when the X
servers
> > starts.
> > I disabled VTd in the bios and now all went fine.
> > I saw this first with SLES11 SP1 but could reproduce it with the
xen-unstable
> > hypervisor.
> >
> > When I start the linux kernel native on the machine with or without
VTd all
> > is running very well.
> >
> > Following data:
> > cpu: Intel(R) Core(TM) i5 CPU  M 540  @ 2.53GHz with integrated
graphics
> >
> > #lspci
> > 00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller
(rev 02)
> > 00:02.0 VGA compatible controller: Intel Corporation Core Processor
Integrated Graphics Controller (rev 02)
> > 00:16.0 Communication controller: Intel Corporation 5 Series/3400
Series Chipset HECI Controller (rev 06)
> > 00:16.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset
PT IDER Controller (rev 06)
> > 00:16.3 Serial controller: Intel Corporation 5 Series/3400 Series
Chipset KT Controller (rev 06)
> > 00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network
Connection (rev 05)
> > 00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)
> > 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset
High Definition Audio (rev 05)
> > 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 6 (rev 05)
> > 00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)
> > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a5)
> > 00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC
Interface Controller (rev 05)
> > 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series
Chipset 6 port SATA AHCI Controller (rev 05)
> > 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus
Controller (rev 05)
> > 00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400
Series Chipset Thermal Subsystem (rev 05)
> > 48:03.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 01)
> > 48:03.1 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 01)
> > 48:03.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD
Controller (rev 02)
> > 48:03.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD
Controller (rev 02)
> > 48:03.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev
07)
> > ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath
Architecture Generic Non-core Registers (rev 02)
> > ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath
Architecture System Address Decoder (rev 02)
> > ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev
02)
> > ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0
(rev 02)
> > ff:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev
02)
> > ff:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev
02)
> >
> > I booted xen with VTd enabled and iommu=verbose an here are the
messages:
> >
> >  \ \/ /___ _ __
> >  \  // _ \ ''_ \
> >  /  \  __/ | | |
> >  /_/\_\___|_| |_|
> >
> >  _  _    _   _     ____  _  _   _  _     _  _  _       _   ____
> >  | || |  / _ \ / _ \   |___ \/ |/ _ \ / _ \/ |   / _ \| || |     / _ \
|___ \
> >  | || |_| | | | | | |    __) | | | | | (_) | |  | | | | || |_ __| | |
|  __) |
> >  |__   _| |_| | |_| |   / __/| | |_| |\__, | |  | |_| |__   _|__| |_|
| / __/ _
> >    |_|(_)___(_)___/___|_____|_|\___/   /_/|_|___\___/   |_|    
\___(_)_____(_)
> >                  |_____|                   |_____|
> >   __
> >  / /_
> >  | ''_ \
> >  | (_) |
> >  \___/
> >
> > (XEN) Xen version 4.0.0_21091_04-0.2.6 (abuild@) (gcc version 4.3.4
[gcc-4_3-branch revision 152973] (SUSE Linux) ) Thu May 20 11:44:41 UTC 2010
> > (XEN) Latest ChangeSet: 21091
> > (XEN) Console output is synchronous.
> > (XEN) Command line: vga=mode-0x314 console=com1,vga com1=38400
sync_console debug=yes guest_loglvl=all iommu=verbose crashkernel=256M@16M
> > (XEN) Video information:
> > (XEN)  VGA is graphics mode 800x600, 16 bpp
> > (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> > (XEN) Disc information:
> > (XEN)  Found 2 MBR signatures
> > (XEN)  Found 2 EDD information structures
> > (XEN) Xen-e820 RAM map:
> > (XEN)  0000000000000000 - 000000000009bc00 (usable)
> > (XEN)  000000000009bc00 - 00000000000a0000 (reserved)
> > (XEN)  00000000000dc000 - 0000000000100000 (reserved)
> > (XEN)  0000000000100000 - 00000000ba95d000 (usable)
> > (XEN)  00000000ba95d000 - 00000000bac40000 (reserved)
> > (XEN)  00000000bac40000 - 00000000bb27c000 (usable)
> > (XEN)  00000000bb27c000 - 00000000bb282000 (reserved)
> > (XEN)  00000000bb282000 - 00000000bb3e0000 (usable)
> > (XEN)  00000000bb3e0000 - 00000000bb40f000 (reserved)
> > (XEN)  00000000bb40f000 - 00000000bb651000 (usable)
> > (XEN)  00000000bb651000 - 00000000bb652000 (reserved)
> > (XEN)  00000000bb652000 - 00000000bb6d3000 (ACPI NVS)
> > (XEN)  00000000bb6d3000 - 00000000bb70f000 (reserved)
> > (XEN)  00000000bb70f000 - 00000000bb717000 (usable)
> > (XEN)  00000000bb717000 - 00000000bb71f000 (reserved)
> > (XEN)  00000000bb71f000 - 00000000bb76f000 (usable)
> > (XEN)  00000000bb76f000 - 00000000bb79f000 (ACPI NVS)
> > (XEN)  00000000bb79f000 - 00000000bb7de000 (usable)
> > (XEN)  00000000bb7de000 - 00000000bb7ff000 (ACPI data)
> > (XEN)  00000000bb7ff000 - 00000000bb800000 (usable)
> > (XEN)  00000000bb800000 - 00000000c0000000 (reserved)
> > (XEN)  00000000e0000000 - 00000000f0000000 (reserved)
> > (XEN)  00000000f272c000 - 00000000f272d000 (reserved)
> > (XEN)  00000000feaff000 - 00000000feb00000 (reserved)
> > (XEN)  00000000fec00000 - 00000000fec10000 (reserved)
> > (XEN)  00000000fed00000 - 00000000fed00400 (reserved)
> > (XEN)  00000000fed1c000 - 00000000fed90000 (reserved)
> > (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
> > (XEN)  00000000ff000000 - 0000000100000000 (reserved)
> > (XEN)  0000000100000000 - 0000000138000000 (usable)
> > (XEN) Kdump: 256MB (262144kB) at 0x1000000
> > (XEN) ACPI: RSDP 000F5400, 0024 (r2 FUJ   )
> > (XEN) ACPI: XSDT BB7F29E3, 008C (r1 FSC    PC        1080000 FUJ      
100)
> > (XEN) ACPI: FACP BB7E0000, 00F4 (r3 FSC    PC        1080000 FUJ      
100)
> > (XEN) ACPI: DSDT BB7E1000, B8C7 (r2 FUJ    FJNB216   1080000 FUJ      
100)
> > (XEN) ACPI: FACS BB78BFC0, 0040
> > (XEN) ACPI: SSDT BB7FE366, 00BA (r1 FUJ    FJNB216   1080000 FUJ      
100)
> > (XEN) ACPI: HPET BB7FE514, 0038 (r1 FUJ    FJNB216   1080000 FUJ      
100)
> > (XEN) ACPI: MCFG BB7FE54C, 003C (r1 FUJ    FJNB216   1080000 FUJ      
100)
> > (XEN) ACPI: SSDT BB7FE588, 042F (r1 FUJ    FJNB216   1080000 FUJ      
100)
> > (XEN) ACPI: SSDT BB7FE9B7, 02C3 (r1 FUJ    FJNB216   1080000 FUJ      
100)
> > (XEN) ACPI: APIC BB7FEC7A, 0084 (r1 FUJ    FJNB216   1080000 FUJ      
100)
> > (XEN) ACPI: SPCR BB7FECFE, 0050 (r1 FUJ    FJNB216   1080000 FUJ      
100)
> > (XEN) ACPI: SLIC BB7FED4E, 0176 (r1 FSC    PC        1080000 FUJ      
100)
> > (XEN) ACPI: BOOT BB7FEEC4, 0028 (r1 FUJ    FJNB216   1080000 FUJ      
100)
> > (XEN) ACPI: ASF! BB7EE000, 00A0 (r16 FUJ    FJNB216   1080000 FUJ     
100)
> > (XEN) ACPI: DMAR BB7ED000, 00B8 (r1 INTEL  CP_DALE         1 INTL     
1)
> > (XEN) ACPI: SSDT BB7DF000, 0A50 (r1  PmRef    CpuPm     3000 INTL
20060912)
> > (XEN) System RAM: 3606MB (3692780kB)
> > (XEN) Domain heap initialised
> > (XEN) Processor #0 6:5 APIC version 21
> > (XEN) Processor #4 6:5 APIC version 21
> > (XEN) Processor #1 6:5 APIC version 21
> > (XEN) Processor #5 6:5 APIC version 21
> > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
> > (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> > (XEN) [VT-D]dmar.c:679: Host address width 36
> > (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
> > (XEN) [VT-D]dmar.c:398:   dmaru->address = fed90000
> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:1b.0
> > (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
> > (XEN) [VT-D]dmar.c:398:   dmaru->address = fed91000
> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
> > (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
> > (XEN) [VT-D]dmar.c:398:   dmaru->address = fed93000
> > (XEN) [VT-D]dmar.c:411:   flags: INCLUDE_ALL
> > (XEN) [VT-D]dmar.c:699: found ACPI_DMAR_RMRR:
> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:1d.0
> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:1a.0
> > (XEN) [VT-D]dmar.c:571:   RMRR region: base_addr bb6e9000 end_address
bb6fffff
> > (XEN) [VT-D]dmar.c:699: found ACPI_DMAR_RMRR:
> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
> > (XEN) [VT-D]dmar.c:571:   RMRR region: base_addr bde00000 end_address
bfffffff
> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > (XEN) Detected 2527.342 MHz processor.
> > (XEN) Initing memory sharing.
> > (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 detected.
> > (XEN) [VT-D]iommu.c:1078: drhd->address = fed91000 iommu->reg =
ffff82c3fff57000
> > (XEN) [VT-D]iommu.c:1080: cap = c0000020230272 ecap = 1000
> > (XEN) [VT-D]iommu.c:1078: drhd->address = fed90000 iommu->reg =
ffff82c3fff56000
> > (XEN) [VT-D]iommu.c:1080: cap = c9008020e30272 ecap = 1000
> > (XEN) [VT-D]iommu.c:1078: drhd->address = fed93000 iommu->reg =
ffff82c3fff55000
> > (XEN) [VT-D]iommu.c:1080: cap = c9008020630272 ecap = 1000
> > (XEN) Intel VT-d Snoop Control not supported.
> > (XEN) Intel VT-d DMA Passthrough not supported.
> > (XEN) Intel VT-d Queued Invalidation not supported.
> > (XEN) Intel VT-d Interrupt Remapping not supported.
> > (XEN) I/O virtualisation enabled
> > (XEN) I/O virtualisation for PV guests disabled
> > (XEN) Enabled directed EOI with ioapic_ack_old on!
> > (XEN) Total of 4 processors activated.
> > (XEN) ENABLING IO-APIC IRQs
> > (XEN)  -> Using old ACK method
> > (XEN) TSC is reliable, synchronization unnecessary
> > (XEN) Platform timer is 14.318MHz HPET
> > (XEN) Allocated console ring of 16 KiB.
> > (XEN) microcode.c:73:d32767 microcode: CPU1 resumed
> > (XEN) microcode.c:73:d32767 microcode: CPU3 resumed
> > (XEN) Brought up 4 CPUs
> > (XEN) microcode.c:73:d32767 microcode: CPU2 resumed
> > (XEN) Created cpupool 0 with scheduler SMP Credit Scheduler (credit)
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:0.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:2.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.2
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.3
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:19.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1a.0
> > (XEN) [VT-D]iommu.c:1325: d0:PCIe: map bdf = 0:1b.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1d.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.2
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.3
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.6
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.1
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.2
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.3
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.4
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.1
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.1
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.2
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.3
> > (XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff57000
> > (XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff56000
> > (XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff55000
> > (XEN) *** LOADING DOMAIN 0 ***
> > (XEN)  Xen  kernel: 64-bit, lsb, compat32
> > (XEN)  Dom0 kernel: 64-bit, lsb, paddr 0x2000 -> 0x765000
> > (XEN) PHYSICAL MEMORY ARRANGEMENT:
> > (XEN)  Dom0 alloc.:   0000000132000000->0000000134000000 (874416
pages to be allocated)
> > (XEN) VIRTUAL MEMORY ARRANGEMENT:
> > (XEN)  Loaded kernel: ffffffff80002000->ffffffff80765000
> > (XEN)  Init. ramdisk: ffffffff80765000->ffffffff815b7600
> > (XEN)  Phys-Mach map: ffffea0000000000->ffffea00006bbd80
> > (XEN)  Start info:    ffffffff815b8000->ffffffff815b84b4
> > (XEN)  Page tables:   ffffffff815b9000->ffffffff815c8000
> > (XEN)  Boot stack:    ffffffff815c8000->ffffffff815c9000
> > (XEN)  TOTAL:         ffffffff80000000->ffffffff81800000
> > (XEN)  ENTRY ADDRESS: ffffffff80002000
> > (XEN) Dom0 has maximum 4 VCPUs
> > (XEN) Scrubbing Free RAM: .done.
> > (XEN) Xen trace buffers: disabled
> > (XEN) Std. Loglevel: Errors and warnings
> > (XEN) Guest Loglevel: All
> > (XEN) **********************************************
> > (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
> > (XEN) ******* This option is intended to aid debugging of Xen by
ensuring
> > (XEN) ******* that all output is synchronously delivered on the serial
line.
> > (XEN) ******* However it can introduce SIGNIFICANT latencies and
affect
> > (XEN) ******* timekeeping. It is NOT recommended for production use!
> > (XEN) **********************************************
> > (XEN) 3... 2... 1...
> > (XEN) Xen is relinquishing VGA console.
> > (XEN) *** Serial input -> DOM0 (type ''CTRL-a''
three times to switch input to Xen)
> > (XEN) Freed 184kB init memory.
> >
> > With staring at the console I could see that the switch to the screen
pattern is
> > around the following messages (but no guarantee):
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.1
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.0
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.1
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.2
> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.3
> >
> > I would say that this is a problem with the bios tables or with the
> > hypervisor not handle these right. Always the switching of the gfx
card into
> > graphics mode seems to lead to the problem.
> > Any help would be very helpful.
> > Thanks.
> >
> > Dietmar.
> >
-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Jean Guyader

2010-Sep-24 11:23 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

The problem we saw with that the bit 10 of the GCC (offset 0x52 on the
PCH config space)
wasn''t set after the bios. This bit probably enable the shadow GTT
(created with the GTT + vt-d).

The vertical stripes means GTT fault.

Jean

On 24 September 2010 12:10, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
wrote:> Am 24.09.2010 schrieb Jean Guyader:
>> Hi,
>>
>> Is it a Lenovo (T410, T510) by any chance?
>
> No, it''s a Fujitsu Lifebook S760, same problem with S710.
>
> Dietmar.
>
>>
>> Jean
>>
>> On 17 September 2010 14:20, Dietmar Hahn
<dietmar.hahn@ts.fujitsu.com> wrote:
>> > Hi list,
>> >
>> > I have a problem with a new laptop (reproducable on other machines
too) and the
>> > xen hypervisor.
>> > When the hypervisor gets booted with VESA mode 800x600 I see some
messages and
>> > then the screen contents is switched into a pattern of vertical
colored lines
>> > and never comes back.
>> > In text mode all works well, but later the pattern appears when
the X servers
>> > starts.
>> > I disabled VTd in the bios and now all went fine.
>> > I saw this first with SLES11 SP1 but could reproduce it with the
xen-unstable
>> > hypervisor.
>> >
>> > When I start the linux kernel native on the machine with or
without VTd all
>> > is running very well.
>> >
>> > Following data:
>> > cpu: Intel(R) Core(TM) i5 CPU  M 540  @ 2.53GHz with integrated
graphics
>> >
>> > #lspci
>> > 00:00.0 Host bridge: Intel Corporation Core Processor DRAM
Controller (rev 02)
>> > 00:02.0 VGA compatible controller: Intel Corporation Core
Processor Integrated Graphics Controller (rev 02)
>> > 00:16.0 Communication controller: Intel Corporation 5 Series/3400
Series Chipset HECI Controller (rev 06)
>> > 00:16.2 IDE interface: Intel Corporation 5 Series/3400 Series
Chipset PT IDER Controller (rev 06)
>> > 00:16.3 Serial controller: Intel Corporation 5 Series/3400 Series
Chipset KT Controller (rev 06)
>> > 00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit
Network Connection (rev 05)
>> > 00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series
Chipset USB2 Enhanced Host Controller (rev 05)
>> > 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series
Chipset High Definition Audio (rev 05)
>> > 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset
PCI Express Root Port 6 (rev 05)
>> > 00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series
Chipset USB2 Enhanced Host Controller (rev 05)
>> > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev
a5)
>> > 00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC
Interface Controller (rev 05)
>> > 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series
Chipset 6 port SATA AHCI Controller (rev 05)
>> > 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset
SMBus Controller (rev 05)
>> > 00:1f.6 Signal processing controller: Intel Corporation 5
Series/3400 Series Chipset Thermal Subsystem (rev 05)
>> > 48:03.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 01)
>> > 48:03.1 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 01)
>> > 48:03.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD
Controller (rev 02)
>> > 48:03.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD
Controller (rev 02)
>> > 48:03.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394)
(rev 07)
>> > ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath
Architecture Generic Non-core Registers (rev 02)
>> > ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath
Architecture System Address Decoder (rev 02)
>> > ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0
(rev 02)
>> > ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical
0 (rev 02)
>> > ff:02.2 Host bridge: Intel Corporation Core Processor Reserved
(rev 02)
>> > ff:02.3 Host bridge: Intel Corporation Core Processor Reserved
(rev 02)
>> >
>> > I booted xen with VTd enabled and iommu=verbose an here are the
messages:
>> >
>> >  \ \/ /___ _ __
>> >  \  // _ \ ''_ \
>> >  /  \  __/ | | |
>> >  /_/\_\___|_| |_|
>> >
>> >  _  _    _   _     ____  _  _   _  _     _  _  _       _   ____
>> >  | || |  / _ \ / _ \   |___ \/ |/ _ \ / _ \/ |   / _ \| || |     /
_ \ |___ \
>> >  | || |_| | | | | | |    __) | | | | | (_) | |  | | | | || |_ __|
| | |  __) |
>> >  |__   _| |_| | |_| |   / __/| | |_| |\__, | |  | |_| |__   _|__|
|_| | / __/ _
>> >    |_|(_)___(_)___/___|_____|_|\___/   /_/|_|___\___/   |_|    
\___(_)_____(_)
>> >                  |_____|                   |_____|
>> >   __
>> >  / /_
>> >  | ''_ \
>> >  | (_) |
>> >  \___/
>> >
>> > (XEN) Xen version 4.0.0_21091_04-0.2.6 (abuild@) (gcc version
4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) Thu May 20 11:44:41 UTC
2010
>> > (XEN) Latest ChangeSet: 21091
>> > (XEN) Console output is synchronous.
>> > (XEN) Command line: vga=mode-0x314 console=com1,vga com1=38400
sync_console debug=yes guest_loglvl=all iommu=verbose crashkernel=256M@16M
>> > (XEN) Video information:
>> > (XEN)  VGA is graphics mode 800x600, 16 bpp
>> > (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
>> > (XEN) Disc information:
>> > (XEN)  Found 2 MBR signatures
>> > (XEN)  Found 2 EDD information structures
>> > (XEN) Xen-e820 RAM map:
>> > (XEN)  0000000000000000 - 000000000009bc00 (usable)
>> > (XEN)  000000000009bc00 - 00000000000a0000 (reserved)
>> > (XEN)  00000000000dc000 - 0000000000100000 (reserved)
>> > (XEN)  0000000000100000 - 00000000ba95d000 (usable)
>> > (XEN)  00000000ba95d000 - 00000000bac40000 (reserved)
>> > (XEN)  00000000bac40000 - 00000000bb27c000 (usable)
>> > (XEN)  00000000bb27c000 - 00000000bb282000 (reserved)
>> > (XEN)  00000000bb282000 - 00000000bb3e0000 (usable)
>> > (XEN)  00000000bb3e0000 - 00000000bb40f000 (reserved)
>> > (XEN)  00000000bb40f000 - 00000000bb651000 (usable)
>> > (XEN)  00000000bb651000 - 00000000bb652000 (reserved)
>> > (XEN)  00000000bb652000 - 00000000bb6d3000 (ACPI NVS)
>> > (XEN)  00000000bb6d3000 - 00000000bb70f000 (reserved)
>> > (XEN)  00000000bb70f000 - 00000000bb717000 (usable)
>> > (XEN)  00000000bb717000 - 00000000bb71f000 (reserved)
>> > (XEN)  00000000bb71f000 - 00000000bb76f000 (usable)
>> > (XEN)  00000000bb76f000 - 00000000bb79f000 (ACPI NVS)
>> > (XEN)  00000000bb79f000 - 00000000bb7de000 (usable)
>> > (XEN)  00000000bb7de000 - 00000000bb7ff000 (ACPI data)
>> > (XEN)  00000000bb7ff000 - 00000000bb800000 (usable)
>> > (XEN)  00000000bb800000 - 00000000c0000000 (reserved)
>> > (XEN)  00000000e0000000 - 00000000f0000000 (reserved)
>> > (XEN)  00000000f272c000 - 00000000f272d000 (reserved)
>> > (XEN)  00000000feaff000 - 00000000feb00000 (reserved)
>> > (XEN)  00000000fec00000 - 00000000fec10000 (reserved)
>> > (XEN)  00000000fed00000 - 00000000fed00400 (reserved)
>> > (XEN)  00000000fed1c000 - 00000000fed90000 (reserved)
>> > (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
>> > (XEN)  00000000ff000000 - 0000000100000000 (reserved)
>> > (XEN)  0000000100000000 - 0000000138000000 (usable)
>> > (XEN) Kdump: 256MB (262144kB) at 0x1000000
>> > (XEN) ACPI: RSDP 000F5400, 0024 (r2 FUJ   )
>> > (XEN) ACPI: XSDT BB7F29E3, 008C (r1 FSC    PC        1080000 FUJ  
    100)
>> > (XEN) ACPI: FACP BB7E0000, 00F4 (r3 FSC    PC        1080000 FUJ  
    100)
>> > (XEN) ACPI: DSDT BB7E1000, B8C7 (r2 FUJ    FJNB216   1080000 FUJ  
    100)
>> > (XEN) ACPI: FACS BB78BFC0, 0040
>> > (XEN) ACPI: SSDT BB7FE366, 00BA (r1 FUJ    FJNB216   1080000 FUJ  
    100)
>> > (XEN) ACPI: HPET BB7FE514, 0038 (r1 FUJ    FJNB216   1080000 FUJ  
    100)
>> > (XEN) ACPI: MCFG BB7FE54C, 003C (r1 FUJ    FJNB216   1080000 FUJ  
    100)
>> > (XEN) ACPI: SSDT BB7FE588, 042F (r1 FUJ    FJNB216   1080000 FUJ  
    100)
>> > (XEN) ACPI: SSDT BB7FE9B7, 02C3 (r1 FUJ    FJNB216   1080000 FUJ  
    100)
>> > (XEN) ACPI: APIC BB7FEC7A, 0084 (r1 FUJ    FJNB216   1080000 FUJ  
    100)
>> > (XEN) ACPI: SPCR BB7FECFE, 0050 (r1 FUJ    FJNB216   1080000 FUJ  
    100)
>> > (XEN) ACPI: SLIC BB7FED4E, 0176 (r1 FSC    PC        1080000 FUJ  
    100)
>> > (XEN) ACPI: BOOT BB7FEEC4, 0028 (r1 FUJ    FJNB216   1080000 FUJ  
    100)
>> > (XEN) ACPI: ASF! BB7EE000, 00A0 (r16 FUJ    FJNB216   1080000 FUJ
      100)
>> > (XEN) ACPI: DMAR BB7ED000, 00B8 (r1 INTEL  CP_DALE         1 INTL
       1)
>> > (XEN) ACPI: SSDT BB7DF000, 0A50 (r1  PmRef    CpuPm     3000 INTL
20060912)
>> > (XEN) System RAM: 3606MB (3692780kB)
>> > (XEN) Domain heap initialised
>> > (XEN) Processor #0 6:5 APIC version 21
>> > (XEN) Processor #4 6:5 APIC version 21
>> > (XEN) Processor #1 6:5 APIC version 21
>> > (XEN) Processor #5 6:5 APIC version 21
>> > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI
0-23
>> > (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
>> > (XEN) [VT-D]dmar.c:679: Host address width 36
>> > (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
>> > (XEN) [VT-D]dmar.c:398:   dmaru->address = fed90000
>> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:1b.0
>> > (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
>> > (XEN) [VT-D]dmar.c:398:   dmaru->address = fed91000
>> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
>> > (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
>> > (XEN) [VT-D]dmar.c:398:   dmaru->address = fed93000
>> > (XEN) [VT-D]dmar.c:411:   flags: INCLUDE_ALL
>> > (XEN) [VT-D]dmar.c:699: found ACPI_DMAR_RMRR:
>> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:1d.0
>> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:1a.0
>> > (XEN) [VT-D]dmar.c:571:   RMRR region: base_addr bb6e9000
end_address bb6fffff
>> > (XEN) [VT-D]dmar.c:699: found ACPI_DMAR_RMRR:
>> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
>> > (XEN) [VT-D]dmar.c:571:   RMRR region: base_addr bde00000
end_address bfffffff
>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> > (XEN) Detected 2527.342 MHz processor.
>> > (XEN) Initing memory sharing.
>> > (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 detected.
>> > (XEN) [VT-D]iommu.c:1078: drhd->address = fed91000
iommu->reg = ffff82c3fff57000
>> > (XEN) [VT-D]iommu.c:1080: cap = c0000020230272 ecap = 1000
>> > (XEN) [VT-D]iommu.c:1078: drhd->address = fed90000
iommu->reg = ffff82c3fff56000
>> > (XEN) [VT-D]iommu.c:1080: cap = c9008020e30272 ecap = 1000
>> > (XEN) [VT-D]iommu.c:1078: drhd->address = fed93000
iommu->reg = ffff82c3fff55000
>> > (XEN) [VT-D]iommu.c:1080: cap = c9008020630272 ecap = 1000
>> > (XEN) Intel VT-d Snoop Control not supported.
>> > (XEN) Intel VT-d DMA Passthrough not supported.
>> > (XEN) Intel VT-d Queued Invalidation not supported.
>> > (XEN) Intel VT-d Interrupt Remapping not supported.
>> > (XEN) I/O virtualisation enabled
>> > (XEN) I/O virtualisation for PV guests disabled
>> > (XEN) Enabled directed EOI with ioapic_ack_old on!
>> > (XEN) Total of 4 processors activated.
>> > (XEN) ENABLING IO-APIC IRQs
>> > (XEN)  -> Using old ACK method
>> > (XEN) TSC is reliable, synchronization unnecessary
>> > (XEN) Platform timer is 14.318MHz HPET
>> > (XEN) Allocated console ring of 16 KiB.
>> > (XEN) microcode.c:73:d32767 microcode: CPU1 resumed
>> > (XEN) microcode.c:73:d32767 microcode: CPU3 resumed
>> > (XEN) Brought up 4 CPUs
>> > (XEN) microcode.c:73:d32767 microcode: CPU2 resumed
>> > (XEN) Created cpupool 0 with scheduler SMP Credit Scheduler
(credit)
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:0.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:2.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.2
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:16.3
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:19.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1a.0
>> > (XEN) [VT-D]iommu.c:1325: d0:PCIe: map bdf = 0:1b.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1d.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.2
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.3
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 0:1f.6
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.1
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.2
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.3
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = 48:3.4
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.1
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.1
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.2
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.3
>> > (XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff57000
>> > (XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff56000
>> > (XEN) [VT-D]iommu.c:695: iommu_enable_translation: iommu->reg =
ffff82c3fff55000
>> > (XEN) *** LOADING DOMAIN 0 ***
>> > (XEN)  Xen  kernel: 64-bit, lsb, compat32
>> > (XEN)  Dom0 kernel: 64-bit, lsb, paddr 0x2000 -> 0x765000
>> > (XEN) PHYSICAL MEMORY ARRANGEMENT:
>> > (XEN)  Dom0 alloc.:   0000000132000000->0000000134000000
(874416 pages to be allocated)
>> > (XEN) VIRTUAL MEMORY ARRANGEMENT:
>> > (XEN)  Loaded kernel: ffffffff80002000->ffffffff80765000
>> > (XEN)  Init. ramdisk: ffffffff80765000->ffffffff815b7600
>> > (XEN)  Phys-Mach map: ffffea0000000000->ffffea00006bbd80
>> > (XEN)  Start info:    ffffffff815b8000->ffffffff815b84b4
>> > (XEN)  Page tables:   ffffffff815b9000->ffffffff815c8000
>> > (XEN)  Boot stack:    ffffffff815c8000->ffffffff815c9000
>> > (XEN)  TOTAL:         ffffffff80000000->ffffffff81800000
>> > (XEN)  ENTRY ADDRESS: ffffffff80002000
>> > (XEN) Dom0 has maximum 4 VCPUs
>> > (XEN) Scrubbing Free RAM: .done.
>> > (XEN) Xen trace buffers: disabled
>> > (XEN) Std. Loglevel: Errors and warnings
>> > (XEN) Guest Loglevel: All
>> > (XEN) **********************************************
>> > (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
>> > (XEN) ******* This option is intended to aid debugging of Xen by
ensuring
>> > (XEN) ******* that all output is synchronously delivered on the
serial line.
>> > (XEN) ******* However it can introduce SIGNIFICANT latencies and
affect
>> > (XEN) ******* timekeeping. It is NOT recommended for production
use!
>> > (XEN) **********************************************
>> > (XEN) 3... 2... 1...
>> > (XEN) Xen is relinquishing VGA console.
>> > (XEN) *** Serial input -> DOM0 (type ''CTRL-a''
three times to switch input to Xen)
>> > (XEN) Freed 184kB init memory.
>> >
>> > With staring at the console I could see that the switch to the
screen pattern is
>> > around the following messages (but no guarantee):
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:0.1
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.0
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.1
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.2
>> > (XEN) [VT-D]iommu.c:1332: d0:PCI: map bdf = ff:2.3
>> >
>> > I would say that this is a problem with the bios tables or with
the
>> > hypervisor not handle these right. Always the switching of the gfx
card into
>> > graphics mode seems to lead to the problem.
>> > Any help would be very helpful.
>> > Thanks.
>> >
>> > Dietmar.
>> >
>
> --
> Company details: http://ts.fujitsu.com/imprint.html
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Dietmar Hahn

2010-Sep-27 12:06 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Hi Jean,

many thanks for this hint! This saved me a lot of time searching through
the specs.

Am 24.09.2010 schrieb Jean Guyader:> The problem we saw with that the bit 10 of the GCC (offset 0x52 on the
> PCH config space)
> wasn''t set after the bios. This bit probably enable the shadow GTT
> (created with the GTT + vt-d).
Yes, the same problem here!
I found the following patch, maybe something similar would help here too?
https://patchwork.kernel.org/patch/132771

So I have to hit the bios development :-(
> The vertical stripes means GTT fault.
> 
> Jean
Many thanks!
Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Konrad Rzeszutek Wilk

2010-Sep-27 16:47 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

On Mon, Sep 27, 2010 at 02:06:26PM +0200, Dietmar Hahn
wrote:> Hi Jean,
> 
> many thanks for this hint! This saved me a lot of time searching through
> the specs.
> 
> Am 24.09.2010 schrieb Jean Guyader:
> > The problem we saw with that the bit 10 of the GCC (offset 0x52 on the
> > PCH config space)
> > wasn''t set after the bios. This bit probably enable the
shadow GTT
> > (created with the GTT + vt-d).
> 
> Yes, the same problem here!
> I found the following patch, maybe something similar would help here too?
> https://patchwork.kernel.org/patch/132771
There looks to be another in the upstream kernels:

check_tylersburg_isoch> 
> So I have to hit the bios development :-(
Well, we should probably provide a quirk check in the Xen code.

Copying the Intel folks to see if they any ideas on adding this in the Intel
VT-d
code paths. Or they might have already a patch ready for
this?> 
> > The vertical stripes means GTT fault.
> > 
> > Jean
> 
> Many thanks!
> Dietmar.
> 
> -- 
> Company details: http://ts.fujitsu.com/imprint.html
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Kay, Allen M

2010-Sep-28 23:54 UTC

head link

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Thanks Konrad.  I got hold of a T410 and able to duplicate the problem with the
2.6.36-rc5 kernel.

Currently, I''m encountering a problem with the latest xen/pvops kernel.
I''m getting "No root device found ... Boot has failed, sleep
forever."

If anyone knows how to fix this (i.e. which config to turn on), please let me
know.  My base OS is FC13.

Allen

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
Sent: Monday, September 27, 2010 9:47 AM
To: Dietmar Hahn; Han, Weidong; Kay, Allen M
Cc: Jean Guyader; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on the
dom0 screen

On Mon, Sep 27, 2010 at 02:06:26PM +0200, Dietmar Hahn
wrote:> Hi Jean,
> 
> many thanks for this hint! This saved me a lot of time searching through
> the specs.
> 
> Am 24.09.2010 schrieb Jean Guyader:
> > The problem we saw with that the bit 10 of the GCC (offset 0x52 on the
> > PCH config space)
> > wasn''t set after the bios. This bit probably enable the
shadow GTT
> > (created with the GTT + vt-d).
> 
> Yes, the same problem here!
> I found the following patch, maybe something similar would help here too?
> https://patchwork.kernel.org/patch/132771
There looks to be another in the upstream kernels:

check_tylersburg_isoch> 
> So I have to hit the bios development :-(
Well, we should probably provide a quirk check in the Xen code.

Copying the Intel folks to see if they any ideas on adding this in the Intel
VT-d
code paths. Or they might have already a patch ready for
this?> 
> > The vertical stripes means GTT fault.
> > 
> > Jean
> 
> Many thanks!
> Dietmar.
> 
> -- 
> Company details: http://ts.fujitsu.com/imprint.html
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2010-Sep-29 06:04 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

On Tue, Sep 28, 2010 at 04:54:05PM -0700, Kay, Allen M
wrote:> Thanks Konrad.  I got hold of a T410 and able to duplicate the problem with
the 2.6.36-rc5 kernel.
> 
> Currently, I''m encountering a problem with the latest xen/pvops
kernel.  I''m getting "No root device found ... Boot has failed,
sleep forever."
> 
> If anyone knows how to fix this (i.e. which config to turn on), please let
me know.  My base OS is FC13.
> 
Does your initrd image have/load the proper driver for your disk controller? 
Did you see: http://wiki.xensource.com/xenwiki/Fedora13Xen4Tutorial ?

Does that system have a serial port, or SOL (on a management chip) ?

-- Pasi
> Allen
> 
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
> Sent: Monday, September 27, 2010 9:47 AM
> To: Dietmar Hahn; Han, Weidong; Kay, Allen M
> Cc: Jean Guyader; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on
the dom0 screen
> 
> On Mon, Sep 27, 2010 at 02:06:26PM +0200, Dietmar Hahn wrote:
> > Hi Jean,
> > 
> > many thanks for this hint! This saved me a lot of time searching
through
> > the specs.
> > 
> > Am 24.09.2010 schrieb Jean Guyader:
> > > The problem we saw with that the bit 10 of the GCC (offset 0x52
on the
> > > PCH config space)
> > > wasn''t set after the bios. This bit probably enable the
shadow GTT
> > > (created with the GTT + vt-d).
> > 
> > Yes, the same problem here!
> > I found the following patch, maybe something similar would help here
too?
> > https://patchwork.kernel.org/patch/132771
> 
> There looks to be another in the upstream kernels:
> 
> check_tylersburg_isoch
> > 
> > So I have to hit the bios development :-(
> 
> Well, we should probably provide a quirk check in the Xen code.
> 
> Copying the Intel folks to see if they any ideas on adding this in the
Intel VT-d
> code paths. Or they might have already a patch ready for this?
> > 
> > > The vertical stripes means GTT fault.
> > > 
> > > Jean
> > 
> > Many thanks!
> > Dietmar.
> > 
> > -- 
> > Company details: http://ts.fujitsu.com/imprint.html
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Kay, Allen M

2010-Sep-29 16:14 UTC

head link

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Thanks Pasi.  I will take a look at the FC13 wiki.

This is a T410 system.  There is no serial port but my guess is it has SOL.  Do
you know of a good wiki on getting SOL working?

Allen

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
Sent: Tuesday, September 28, 2010 11:05 PM
To: Kay, Allen M
Cc: Konrad Rzeszutek Wilk; Dietmar Hahn; Han, Weidong;
xen-devel@lists.xensource.com; Jean Guyader
Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on the
dom0 screen

On Tue, Sep 28, 2010 at 04:54:05PM -0700, Kay, Allen M
wrote:> Thanks Konrad.  I got hold of a T410 and able to duplicate the problem with
the 2.6.36-rc5 kernel.
> 
> Currently, I''m encountering a problem with the latest xen/pvops
kernel.  I''m getting "No root device found ... Boot has failed,
sleep forever."
> 
> If anyone knows how to fix this (i.e. which config to turn on), please let
me know.  My base OS is FC13.
> 
Does your initrd image have/load the proper driver for your disk controller? 
Did you see: http://wiki.xensource.com/xenwiki/Fedora13Xen4Tutorial ?

Does that system have a serial port, or SOL (on a management chip) ?

-- Pasi
> Allen
> 
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
> Sent: Monday, September 27, 2010 9:47 AM
> To: Dietmar Hahn; Han, Weidong; Kay, Allen M
> Cc: Jean Guyader; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on
the dom0 screen
> 
> On Mon, Sep 27, 2010 at 02:06:26PM +0200, Dietmar Hahn wrote:
> > Hi Jean,
> > 
> > many thanks for this hint! This saved me a lot of time searching
through
> > the specs.
> > 
> > Am 24.09.2010 schrieb Jean Guyader:
> > > The problem we saw with that the bit 10 of the GCC (offset 0x52
on the
> > > PCH config space)
> > > wasn''t set after the bios. This bit probably enable the
shadow GTT
> > > (created with the GTT + vt-d).
> > 
> > Yes, the same problem here!
> > I found the following patch, maybe something similar would help here
too?
> > https://patchwork.kernel.org/patch/132771
> 
> There looks to be another in the upstream kernels:
> 
> check_tylersburg_isoch
> > 
> > So I have to hit the bios development :-(
> 
> Well, we should probably provide a quirk check in the Xen code.
> 
> Copying the Intel folks to see if they any ideas on adding this in the
Intel VT-d
> code paths. Or they might have already a patch ready for this?
> > 
> > > The vertical stripes means GTT fault.
> > > 
> > > Jean
> > 
> > Many thanks!
> > Dietmar.
> > 
> > -- 
> > Company details: http://ts.fujitsu.com/imprint.html
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Pasi Kärkkäinen

2010-Sep-29 19:17 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

On Wed, Sep 29, 2010 at 09:14:44AM -0700, Kay, Allen M
wrote:> Thanks Pasi.  I will take a look at the FC13 wiki.
> 
> This is a T410 system.  There is no serial port but my guess is it has SOL.
Do you know of a good wiki on getting SOL working?
> 
Try this one:
http://wiki.xensource.com/xenwiki/XenSerialConsole

-- Pasi
> Allen
> 
> -----Original Message-----
> From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
> Sent: Tuesday, September 28, 2010 11:05 PM
> To: Kay, Allen M
> Cc: Konrad Rzeszutek Wilk; Dietmar Hahn; Han, Weidong;
xen-devel@lists.xensource.com; Jean Guyader
> Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on
the dom0 screen
> 
> On Tue, Sep 28, 2010 at 04:54:05PM -0700, Kay, Allen M wrote:
> > Thanks Konrad.  I got hold of a T410 and able to duplicate the problem
with the 2.6.36-rc5 kernel.
> > 
> > Currently, I''m encountering a problem with the latest
xen/pvops kernel.  I''m getting "No root device found ... Boot has
failed, sleep forever."
> > 
> > If anyone knows how to fix this (i.e. which config to turn on), please
let me know.  My base OS is FC13.
> > 
> 
> Does your initrd image have/load the proper driver for your disk
controller?
> Did you see: http://wiki.xensource.com/xenwiki/Fedora13Xen4Tutorial ?
> 
> Does that system have a serial port, or SOL (on a management chip) ?
> 
> -- Pasi
> 
> > Allen
> > 
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
> > Sent: Monday, September 27, 2010 9:47 AM
> > To: Dietmar Hahn; Han, Weidong; Kay, Allen M
> > Cc: Jean Guyader; xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines
on the dom0 screen
> > 
> > On Mon, Sep 27, 2010 at 02:06:26PM +0200, Dietmar Hahn wrote:
> > > Hi Jean,
> > > 
> > > many thanks for this hint! This saved me a lot of time searching
through
> > > the specs.
> > > 
> > > Am 24.09.2010 schrieb Jean Guyader:
> > > > The problem we saw with that the bit 10 of the GCC (offset
0x52 on the
> > > > PCH config space)
> > > > wasn''t set after the bios. This bit probably enable
the shadow GTT
> > > > (created with the GTT + vt-d).
> > > 
> > > Yes, the same problem here!
> > > I found the following patch, maybe something similar would help
here too?
> > > https://patchwork.kernel.org/patch/132771
> > 
> > There looks to be another in the upstream kernels:
> > 
> > check_tylersburg_isoch
> > > 
> > > So I have to hit the bios development :-(
> > 
> > Well, we should probably provide a quirk check in the Xen code.
> > 
> > Copying the Intel folks to see if they any ideas on adding this in the
Intel VT-d
> > code paths. Or they might have already a patch ready for this?
> > > 
> > > > The vertical stripes means GTT fault.
> > > > 
> > > > Jean
> > > 
> > > Many thanks!
> > > Dietmar.
> > > 
> > > -- 
> > > Company details: http://ts.fujitsu.com/imprint.html
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Kay, Allen M

2010-Sep-29 23:14 UTC

head link

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Attached patch fixes dom0 graphics problem on Levnovo T410 when VT-d is enabled.
The patch is derived from a similar quirk in Linux kernel by David Woodhouse and
Adam Jackson.  It checks for VT enabling bit in IGD GGC register.  If VT is not
enabled correctly in the IGD, Xen does not enable VT-d translation for IGD VT-d
engine.  In case where iommu boot parameter is set to force, Xen calls panic().

Signed-off-by: Allen Kay allen.m.kay@intel.com

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
Sent: Monday, September 27, 2010 9:47 AM
To: Dietmar Hahn; Han, Weidong; Kay, Allen M
Cc: Jean Guyader; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on the
dom0 screen

On Mon, Sep 27, 2010 at 02:06:26PM +0200, Dietmar Hahn
wrote:> Hi Jean,
> 
> many thanks for this hint! This saved me a lot of time searching through
> the specs.
> 
> Am 24.09.2010 schrieb Jean Guyader:
> > The problem we saw with that the bit 10 of the GCC (offset 0x52 on the
> > PCH config space)
> > wasn''t set after the bios. This bit probably enable the
shadow GTT
> > (created with the GTT + vt-d).
> 
> Yes, the same problem here!
> I found the following patch, maybe something similar would help here too?
> https://patchwork.kernel.org/patch/132771
There looks to be another in the upstream kernels:

check_tylersburg_isoch> 
> So I have to hit the bios development :-(
Well, we should probably provide a quirk check in the Xen code.

Copying the Intel folks to see if they any ideas on adding this in the Intel
VT-d
code paths. Or they might have already a patch ready for
this?> 
> > The vertical stripes means GTT fault.
> > 
> > Jean
> 
> Many thanks!
> Dietmar.
> 
> -- 
> Company details: http://ts.fujitsu.com/imprint.html
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

Dietmar Hahn

2010-Sep-30 07:58 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Hi Allen,

Am 30.09.2010 schrieb Kay, Allen M:> Attached patch fixes dom0 graphics problem on Levnovo T410 when VT-d is
enabled.  The patch is derived from a similar quirk in Linux kernel by David
Woodhouse and Adam Jackson.  It checks for VT enabling bit in IGD GGC register. 
If VT is not enabled correctly in the IGD, Xen does not enable VT-d translation
for IGD VT-d engine.  In case where iommu boot parameter is set to force, Xen
calls panic().
This worked for my Fujitsu S760 too!
Thanks.
Dietmar.
> 
> Signed-off-by: Allen Kay allen.m.kay@intel.com
> 
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
> Sent: Monday, September 27, 2010 9:47 AM
> To: Dietmar Hahn; Han, Weidong; Kay, Allen M
> Cc: Jean Guyader; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on
the dom0 screen
> 
> On Mon, Sep 27, 2010 at 02:06:26PM +0200, Dietmar Hahn wrote:
> > Hi Jean,
> > 
> > many thanks for this hint! This saved me a lot of time searching
through
> > the specs.
> > 
> > Am 24.09.2010 schrieb Jean Guyader:
> > > The problem we saw with that the bit 10 of the GCC (offset 0x52
on the
> > > PCH config space)
> > > wasn''t set after the bios. This bit probably enable the
shadow GTT
> > > (created with the GTT + vt-d).
> > 
> > Yes, the same problem here!
> > I found the following patch, maybe something similar would help here
too?
> > https://patchwork.kernel.org/patch/132771
> 
> There looks to be another in the upstream kernels:
> 
> check_tylersburg_isoch
> > 
> > So I have to hit the bios development :-(
> 
> Well, we should probably provide a quirk check in the Xen code.
> 
> Copying the Intel folks to see if they any ideas on adding this in the
Intel VT-d
> code paths. Or they might have already a patch ready for this?
> > 
> > > The vertical stripes means GTT fault.
> > > 
> > > Jean
> > 
> > Many thanks!
> > Dietmar.
> > 
> -- 
Company details: http://ts.fujitsu.com/imprint.html

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

Jan Beulich

2010-Oct-04 08:23 UTC

head link

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

>>> On 30.09.10 at 01:14, "Kay, Allen M"
<allen.m.kay@intel.com> wrote:
> Attached patch fixes dom0 graphics problem on Levnovo T410 when VT-d is 
> enabled.  The patch is derived from a similar quirk in Linux kernel by
David
> Woodhouse and Adam Jackson.  It checks for VT enabling bit in IGD GGC 
> register.  If VT is not enabled correctly in the IGD, Xen does not enable
VT-d
> translation for IGD VT-d engine.  In case where iommu boot parameter is set
to
> force, Xen calls panic().
> 
> Signed-off-by: Allen Kay allen.m.kay@intel.com 
Hmm, I had hoped this patch wouldn''t get applied as-is, but I just
saw it''s in the staging tree already. It seems more like a hack than
a real (permanent) solution.
>@@ -333,6 +340,8 @@
>             if ( iommu_verbose )
>                 dprintk(VTDPREFIX, "  endpoint: %x:%x.%x\n",
>                         bus, path->dev, path->fn);
>+            if ( (bus == 0) && (path->dev == 2) &&
(path->fn == 0) )
>+                *igd = 1;
>             break;
> 
>         case ACPI_DEV_IOAPIC:
The use of magic numbers (0, 2, and 0) here looks like being
tailored to just a very limited set of systems. If it was really
known that all current and future systems are going to have this
arrangement, a comment saying so would be the minimum I''d
expect.

Also, if a check of igd against NULL or a check of type against
DMAR_TYPE was added here, the two call sites that don''t really
need this output could simply pass NULL instead of adding a new
local variable.
>@@ -689,10 +689,34 @@
>     return 0;
> }
> 
>-static void iommu_enable_translation(struct iommu *iommu)
>+#define GGC 0x52
>+#define GGC_MEMORY_VT_ENABLED  (0x8 << 8)
>+static int is_igd_vt_enabled(void)
>+{
>+    unsigned short ggc;
>+
>+    /* integrated graphics on Intel platforms is located at 0:2.0 */
>+    ggc = pci_conf_read16(0, 2, 0, GGC);
>+    return ( ggc & GGC_MEMORY_VT_ENABLED ? 1 : 0 );
Similarly here (a brief comment is there, but to me this doesn''t
mean it''s going to be that way forever).

Also, if this ever needs updating, matching the magic numbers
here and above is going to be a matter of luck. If they are to be
hard coded, they should be #define-s, so that locating all uses
is possible.
>+}
>+
>+static void iommu_enable_translation(struct acpi_drhd_unit *drhd)
> {
>     u32 sts;
>     unsigned long flags;
>+    struct iommu *iommu = drhd->iommu;
>+
>+    if ( !is_igd_vt_enabled() && is_igd_drhd(drhd) ) 
I would also have suggested switching the checks here: The first
involves a PCI config space read (and even unconditional upon
anything), while the second really just is a compare of two
variables.
>+    {
>+        if ( force_iommu )
>+            panic("BIOS did not enable IGD for VT properly, crash Xen
for security purpose!\n");
>+        else
>+        {
>+            dprintk(XENLOG_WARNING VTDPREFIX,
>+                    "BIOS did not enable IGD for VT properly. 
Disabling IGD VT-d engine.\n");
>+            return;
>+        }
>+    }
> 
>     if ( iommu_verbose )
>         dprintk(VTDPREFIX,
Jan


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

Kay, Allen M

2010-Oct-04 15:11 UTC

head link

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

> The use of magic numbers (0, 2, and 0) here looks like being
> tailored to just a very limited set of systems. If it was really
> known that all current and future systems are going to have this
> arrangement, a comment saying so would be the minimum I''d
> expect.
AFAIK, 0:2.0 has been IGD device for all modern Intel systems with integrated
graphics.  I can change to use #def.  Other than that, what are the alternatives
to looking for 0:2.0?  Checking for vendor ID and device CLASS?  That would
preclude any possible discrete graphics from Intel.
> Also, if a check of igd against NULL or a check of type against
> DMAR_TYPE was added here, the two call sites that don''t really
> need this output could simply pass NULL instead of adding a new
> local variable.
This I can do.  I''m working on a file that will consolidate all VT-d
and IGD related quirks.  I will incorporate it.
> Similarly here (a brief comment is there, but to me this doesn''t
> mean it''s going to be that way forever).
> 
> Also, if this ever needs updating, matching the magic numbers
> here and above is going to be a matter of luck. If they are to be
> hard coded, they should be #define-s, so that locating all uses
> is possible.
Unless you can offer other methods of detecting IGD, I will just change 0:2.0 to
hard coded IGD_BUS, IGD_DEV, IGD_FUNC defines as mentioned above.
>>+}
>>+
>>+static void iommu_enable_translation(struct acpi_drhd_unit *drhd)
>> {
>>     u32 sts;
>>     unsigned long flags;
>>+    struct iommu *iommu = drhd->iommu;
>>+
>>+    if ( !is_igd_vt_enabled() && is_igd_drhd(drhd) )
>>+    {
>>+        if ( force_iommu )
> 
>I would also have suggested switching the checks here: The first
>involves a PCI config space read (and even unconditional upon
>anything), while the second really just is a compare of two
>variables.
I''m not sure I''m convinced you suggestion will make it
clearer.  What is the rational for making this change?  To me current order
makes more sense.  First set of changes checks if anything needs to be done. The
second check for "force_iommu" decides whether to panic or disable IGD
VT-d.

Allen


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

Jan Beulich

2010-Oct-04 15:24 UTC

head link

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

>>> On 04.10.10 at 17:11, "Kay, Allen M"
<allen.m.kay@intel.com> wrote:
>>  The use of magic numbers (0, 2, and 0) here looks like being
>> tailored to just a very limited set of systems. If it was really
>> known that all current and future systems are going to have this
>> arrangement, a comment saying so would be the minimum I''d
>> expect.
> 
> AFAIK, 0:2.0 has been IGD device for all modern Intel systems with 
> integrated graphics.  I can change to use #def.  Other than that, what are 
> the alternatives to looking for 0:2.0?  Checking for vendor ID and device 
> CLASS?  That would preclude any possible discrete graphics from Intel.
Yes, and vendor/class check would seem reasonable here.
> Unless you can offer other methods of detecting IGD, I will just change 
> 0:2.0 to hard coded IGD_BUS, IGD_DEV, IGD_FUNC defines as mentioned above.
I would have thought doing it the other way around (looking for
a matching device [e.g. vendor:class] at all potential bus:dev.fn
tuples). Doesn''t Linux get away without hardcoded numbers?
>>>+    if ( !is_igd_vt_enabled() && is_igd_drhd(drhd) )
>>>+    {
>>>+        if ( force_iommu )
>> 
>>I would also have suggested switching the checks here: The first
>>involves a PCI config space read (and even unconditional upon
>>anything), while the second really just is a compare of two
>>variables.
> 
> I''m not sure I''m convinced you suggestion will make it
clearer.  What is the
> rational for making this change?  To me current order makes more sense.  
> First set of changes checks if anything needs to be done. The second check 
> for "force_iommu" decides whether to panic or disable IGD VT-d.
Perhaps I didn''t say clearly enough what I mean: I''d want the
first
if()''s constituents changed (i.e. to

    if ( is_igd_drhd(drhd) && !is_igd_vt_enabled() )

) so that the easy test gets executed first, and the PCI config
space access is avoided as much as possible. This would be less
of an issue if you knew that the device you''re trying to read
from is actually an IGD.

Jan


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

Kay, Allen M

2010-Oct-04 18:15 UTC

head link

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

> Yes, and vendor/class check would seem reasonable here.
How do you differentiate Intel IGD and discrete graphics with this method?

> Perhaps I didn''t say clearly enough what I mean: I''d want
the first
> if()''s constituents changed (i.e. to
> 
>    if ( is_igd_drhd(drhd) && !is_igd_vt_enabled() )
>
>) so that the easy test gets executed first, and the PCI config
>space access is avoided as much as possible. This would be less
>of an issue if you knew that the device you''re trying to read
>from is actually an IGD.
Sounds reasonable thing to do as a general rule.  By the way the code here is
only used during boot time. I will change it as part of the vt-d quirk
consolidation and cleanup.

allen

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

Jan Beulich

2010-Oct-05 06:51 UTC

head link

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

>>> On 04.10.10 at 20:15, "Kay, Allen M"
<allen.m.kay@intel.com> wrote:
>>  Yes, and vendor/class check would seem reasonable here.
> 
> How do you differentiate Intel IGD and discrete graphics with this method?
I don''t know. But again - how does Linux get around this problem?

Jan


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

Kay, Allen M

2010-Oct-05 23:20 UTC

head link

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Linux is keying off all possible Calpella device ID''s:

static void __devinit quirk_calpella_no_shadow_gtt(struct pci_dev *dev)
{
	unsigned short ggc;

	if (pci_read_config_word(dev, GGC, &ggc))
		return;

	if (!(ggc & GGC_MEMORY_VT_ENABLED)) {
		printk(KERN_INFO "DMAR: BIOS has allocated no shadow GTT; disabling IOMMU
for graphics\n");
		dmar_map_gfx = 0;
	}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0040,
quirk_calpella_no_shadow_gtt);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044,
quirk_calpella_no_shadow_gtt);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0062,
quirk_calpella_no_shadow_gtt);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x006a,
quirk_calpella_no_shadow_gtt);

Allen

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@novell.com] 
Sent: Monday, October 04, 2010 11:52 PM
To: Kay, Allen M
Cc: Keir Fraser; Jean Guyader; Han, Weidong; xen-devel@lists.xensource.com;
KonradRzeszutek Wilk; Dietmar Hahn
Subject: RE: [Xen-devel] Problem: Pattern with vertical colored lines on the
dom0 screen
>>> On 04.10.10 at 20:15, "Kay, Allen M"
<allen.m.kay@intel.com> wrote:
>>  Yes, and vendor/class check would seem reasonable here.
> 
> How do you differentiate Intel IGD and discrete graphics with this method?
I don''t know. But again - how does Linux get around this problem?

Jan


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

Eric Riser

2010-Oct-08 20:33 UTC

head link

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Hello,

I''m experiencing the exact same problem described in this thread,
except I''m having difficulty applying the patch provided. Can someone
please provide some feedback on the proper method?

http://lists.xensource.com/archives/html/xen-devel/2010-09/msg01743.html


Am 30.09.2010 schrieb Kay, Allen M:>* Attached patch fixes dom0 graphics problem on Levnovo T410 when VT-d is *
>* enabled.  The patch is derived from a similar quirk in Linux kernel by
David *
>* Woodhouse and Adam Jackson.  It checks for VT enabling bit in IGD GGC *
>* register.  If VT is not enabled correctly in the IGD, Xen does not enable
*
>* VT-d translation for IGD VT-d engine.  In case where iommu boot parameter
is *
>* set to force, Xen calls panic().*
This worked for my Fujitsu S760 too!
Thanks.
Dietmar.
>* *
>* Signed-off-by: Allen Kay allen.m.kay@xxxxxxxxx*
>* *
>* -----Original Message-----*
>* From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx
<konrad.wilk@xxxxxxxxxx>] *
>* Sent: Monday, September 27, 2010 9:47 AM*
>* To: Dietmar Hahn; Han, Weidong; Kay, Allen M*
>* Cc: Jean Guyader; xen-devel@xxxxxxxxxxxxxxxxxxx*
>* Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on
the *
>* dom0 screen*
>* *
>* On Mon, Sep 27, 2010 at 02:06:26PM +0200, Dietmar Hahn wrote:*
>* > Hi Jean,*
>* > *
>* > many thanks for this hint! This saved me a lot of time searching
through*
>* > the specs.*
>* > *
>* > Am 24.09.2010 schrieb Jean Guyader:*
>* > > The problem we saw with that the bit 10 of the GCC (offset 0x52
on the*
>* > > PCH config space)*
>* > > wasn''t set after the bios. This bit probably enable the
shadow GTT*
>* > > (created with the GTT + vt-d).*
>* > *
>* > Yes, the same problem here!*
>* > I found the following patch, maybe something similar would help here
too?*
>* > https://patchwork.kernel.org/patch/132771*
>* *
>* There looks to be another in the upstream kernels:*
>* *
>* check_tylersburg_isoch*
>* > *
>* > So I have to hit the bios development :-(*
>* *
>* Well, we should probably provide a quirk check in the Xen code.*
>* *
>* Copying the Intel folks to see if they any ideas on adding this in the
Intel *
>* VT-d*
>* code paths. Or they might have already a patch ready for this?*
>* > *
>* > > The vertical stripes means GTT fault.*
>* > > *
>* > > Jean*
>* > *
>* > Many thanks!*
>* > Dietmar.*
>* > *
>* *-- 
Company details: http://ts.fujitsu.com/imprint.html


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

Possibly Parallel Threads

Search for more reasonably related threads

Xen devel - Sep 2010 - Problem: Pattern with vertical colored lines on the dom0 screen

[Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen

Possibly Parallel Threads