Discussion:
Problem: Pattern with vertical colored lines on the dom0 screen
(too old to reply)
Dietmar Hahn
2010-09-17 13:20:11 UTC
Permalink
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.56,382,1280700000"; d="scan'208";a="50931480"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
by dgate10u.abg.fsc.net with ESMTP; 17 Sep 2010 15:20:14 +0200
X-IronPort-AV: E=Sophos;i="4.56,382,1280700000"; d="scan'208";a="99310800"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
by abgdgate30u.abg.fsc.net with ESMTP; 17 Sep 2010 15:20:13 +0200
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
by sanpedro.mch.fsc.net (Postfix) with SMTP id 3C1AC75287A
for <Xen-***@lists.xensource.com>;
Fri, 17 Sep 2010 15:20:13 +0200 (CEST)
X-ASG-Orig-Subj: Problem: Pattern with vertical colored lines on the dom0
screen
User-Agent: KMail/1.13.5 (Linux/2.6.34-12-xen; KDE/4.4.4; x86_64; ; )
X-Barracuda-Connect: dgate10.ts.fujitsu.com[80.70.172.49]
X-Barracuda-Start-Time: 1284729616
X-Barracuda-Encrypted: RC4-SHA
X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at xensource.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5
QUARANTINE_LEVEL=6.0 KILL_LEVEL=1000.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.41088
Rule breakdown below
pts rule name description
---- ----------------------
--------------------------------------------------
X-BeenThere: xen-***@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
<mailto:xen-devel-***@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-***@lists.xensource.com>
List-Help: <mailto:xen-devel-***@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
<mailto:xen-devel-***@lists.xensource.com?subject=subscribe>
Sender: xen-devel-***@lists.xensource.com
Errors-To: xen-devel-***@lists.xensource.com
Archived-At: <http://permalink.gmane.org/gmane.comp.emulators.xen.devel/90352>

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=***@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
Konrad Rzeszutek Wilk
2010-09-20 20:59:26 UTC
Permalink
Post by Dietmar Hahn
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?
Post by Dietmar Hahn
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?
Dietmar Hahn
2010-09-21 07:19:51 UTC
Permalink
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
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!
Post by Konrad Rzeszutek Wilk
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.
Post by Konrad Rzeszutek Wilk
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.
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
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
Konrad Rzeszutek Wilk
2010-09-21 14:42:50 UTC
Permalink
Post by Dietmar Hahn
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
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?
Post by Dietmar Hahn
Post by Konrad Rzeszutek Wilk
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.
Post by Konrad Rzeszutek Wilk
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.
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
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.
[ 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.
Post by Dietmar Hahn
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
http://lists.xensource.com/xen-devel
Dietmar Hahn
2010-09-22 13:06:14 UTC
Permalink
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
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.
Post by Konrad Rzeszutek Wilk
Just curious, but why did you try the 'vga=mode' option?
The vga option gets set somewhere in the installation procedure.
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
Post by Konrad Rzeszutek Wilk
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.
Post by Konrad Rzeszutek Wilk
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.
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
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.
[ 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!
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
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
Konrad Rzeszutek Wilk
2010-09-22 13:56:59 UTC
Permalink
Post by Dietmar Hahn
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
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 ..
Post by Dietmar Hahn
Post by Konrad Rzeszutek Wilk
Post by Dietmar Hahn
booting the hypervisor and before dom0 starts.
[ 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?
Dietmar Hahn
2010-09-23 11:53:34 UTC
Permalink
Hi Konrad,

first thanks for trying to help, but it seems I didn't explain the problem not
clear enough.
Post by 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 ;-)
Post by Konrad Rzeszutek Wilk
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.
Post by Konrad Rzeszutek Wilk
With staring at the console I could see that the switch to the screen pattern is
(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
Dietmar Hahn
2010-09-24 09:50:38 UTC
Permalink
Post by 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
Jan Beulich
2010-09-22 14:23:22 UTC
Permalink
Post by Dietmar Hahn
Post by Konrad Rzeszutek Wilk
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
Dietmar Hahn
2010-09-23 11:53:29 UTC
Permalink
Post by Jan Beulich
Post by Dietmar Hahn
Post by Konrad Rzeszutek Wilk
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.
Post by Jan Beulich
Jan
--
Company details: http://ts.fujitsu.com/imprint.html
Jean Guyader
2010-09-24 10:19:08 UTC
Permalink
Hi,

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

Jean
Post by Dietmar Hahn
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.
#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)
 \ \/ /___ _ __
 \  // _ \ '_ \
 /  \  __/ | | |
 /_/\_\___|_| |_|
 _  _    _   _     ____  _  _   _  _     _  _  _       _   ____
 | || |  / _ \ / _ \   |___ \/ |/ _ \ / _ \/ |   / _ \| || |     / _ \ |___ \
 | || |_| | | | | | |    __) | | | | | (_) | |  | | | | || |_ __| | | |  __) |
 |__   _| |_| | |_| |   / __/| | |_| |\__, | |  | |_| |__   _|__| |_| | / __/ _
   |_|(_)___(_)___/___|_____|_|\___/   /_/|_|___\___/   |_|     \___(_)_____(_)
                 |_____|                   |_____|
  __
 / /_
 | '_ \
 | (_) |
 \___/
(XEN) Latest ChangeSet: 21091
(XEN) Console output is synchronous.
(XEN)  VGA is graphics mode 800x600, 16 bpp
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(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:398:   dmaru->address = fed90000
(XEN) [VT-D]dmar.c:334:   endpoint: 0:1b.0
(XEN) [VT-D]dmar.c:398:   dmaru->address = fed91000
(XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
(XEN) [VT-D]dmar.c:398:   dmaru->address = fed93000
(XEN) [VT-D]dmar.c:411:   flags: INCLUDE_ALL
(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: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)  - 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)  Dom0 alloc.:   0000000132000000->0000000134000000 (874416 pages to be allocated)
(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
(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
http://lists.xensource.com/xen-devel
Dietmar Hahn
2010-09-24 11:10:18 UTC
Permalink
Post by Jean Guyader
Hi,
Is it a Lenovo (T410, T510) by any chance?
No, it's a Fujitsu Lifebook S760, same problem with S710.

Dietmar.
Post by Jean Guyader
Jean
Post by Dietmar Hahn
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.
#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)
\ \/ /___ _ __
\ // _ \ '_ \
/ \ __/ | | |
/_/\_\___|_| |_|
_ _ _ _ ____ _ _ _ _ _ _ _ _ ____
| || | / _ \ / _ \ |___ \/ |/ _ \ / _ \/ | / _ \| || | / _ \ |___ \
| || |_| | | | | | | __) | | | | | (_) | | | | | | || |_ __| | | | __) |
|__ _| |_| | |_| | / __/| | |_| |\__, | | | |_| |__ _|__| |_| | / __/ _
|_|(_)___(_)___/___|_____|_|\___/ /_/|_|___\___/ |_| \___(_)_____(_)
|_____| |_____|
__
/ /_
| '_ \
| (_) |
\___/
(XEN) Latest ChangeSet: 21091
(XEN) Console output is synchronous.
(XEN) VGA is graphics mode 800x600, 16 bpp
(XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Found 2 MBR signatures
(XEN) Found 2 EDD information structures
(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:398: dmaru->address = fed90000
(XEN) [VT-D]dmar.c:334: endpoint: 0:1b.0
(XEN) [VT-D]dmar.c:398: dmaru->address = fed91000
(XEN) [VT-D]dmar.c:334: endpoint: 0:2.0
(XEN) [VT-D]dmar.c:398: dmaru->address = fed93000
(XEN) [VT-D]dmar.c:411: flags: INCLUDE_ALL
(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: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) - 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) Dom0 alloc.: 0000000132000000->0000000134000000 (874416 pages to be allocated)
(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
(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
Jean Guyader
2010-09-24 11:23:19 UTC
Permalink
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
Post by Dietmar Hahn
Post by Jean Guyader
Hi,
Is it a Lenovo (T410, T510) by any chance?
No, it's a Fujitsu Lifebook S760, same problem with S710.
Dietmar.
Post by Jean Guyader
Jean
Post by Dietmar Hahn
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.
#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)
 \ \/ /___ _ __
 \  // _ \ '_ \
 /  \  __/ | | |
 /_/\_\___|_| |_|
 _  _    _   _     ____  _  _   _  _     _  _  _       _   ____
 | || |  / _ \ / _ \   |___ \/ |/ _ \ / _ \/ |   / _ \| || |     / _ \ |___ \
 | || |_| | | | | | |    __) | | | | | (_) | |  | | | | || |_ __| | | |  __) |
 |__   _| |_| | |_| |   / __/| | |_| |\__, | |  | |_| |__   _|__| |_| | / __/ _
   |_|(_)___(_)___/___|_____|_|\___/   /_/|_|___\___/   |_|     \___(_)_____(_)
                 |_____|                   |_____|
  __
 / /_
 | '_ \
 | (_) |
 \___/
(XEN) Latest ChangeSet: 21091
(XEN) Console output is synchronous.
(XEN)  VGA is graphics mode 800x600, 16 bpp
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(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:398:   dmaru->address = fed90000
(XEN) [VT-D]dmar.c:334:   endpoint: 0:1b.0
(XEN) [VT-D]dmar.c:398:   dmaru->address = fed91000
(XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
(XEN) [VT-D]dmar.c:398:   dmaru->address = fed93000
(XEN) [VT-D]dmar.c:411:   flags: INCLUDE_ALL
(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: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)  - 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)  Dom0 alloc.:   0000000132000000->0000000134000000 (874416 pages to be allocated)
(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
(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
Dietmar Hahn
2010-09-27 12:06:26 UTC
Permalink
Hi Jean,

many thanks for this hint! This saved me a lot of time searching through
the specs.
Post by 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 :-(
Post by Jean Guyader
The vertical stripes means GTT fault.
Jean
Many thanks!
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
Konrad Rzeszutek Wilk
2010-09-27 16:47:06 UTC
Permalink
Post by Dietmar Hahn
Hi Jean,
many thanks for this hint! This saved me a lot of time searching through
the specs.
Post by 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
Post by Dietmar Hahn
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?
Post by Dietmar Hahn
Post by Jean Guyader
The vertical stripes means GTT fault.
Jean
Many thanks!
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
http://lists.xensource.com/xen-devel
Kay, Allen M
2010-09-28 23:54:05 UTC
Permalink
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:***@oracle.com]
Sent: Monday, September 27, 2010 9:47 AM
To: Dietmar Hahn; Han, Weidong; Kay, Allen M
Cc: Jean Guyader; xen-***@lists.xensource.com
Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
Post by Dietmar Hahn
Hi Jean,
many thanks for this hint! This saved me a lot of time searching through
the specs.
Post by 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
Post by Dietmar Hahn
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?
Post by Dietmar Hahn
Post by Jean Guyader
The vertical stripes means GTT fault.
Jean
Many thanks!
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-09-29 06:04:56 UTC
Permalink
Post by Kay, Allen M
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
Post by Kay, Allen M
Allen
-----Original Message-----
Sent: Monday, September 27, 2010 9:47 AM
To: Dietmar Hahn; Han, Weidong; Kay, Allen M
Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
Post by Dietmar Hahn
Hi Jean,
many thanks for this hint! This saved me a lot of time searching through
the specs.
Post by 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
check_tylersburg_isoch
Post by Dietmar Hahn
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?
Post by Dietmar Hahn
Post by Jean Guyader
The vertical stripes means GTT fault.
Jean
Many thanks!
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
http://lists.xensource.com/xen-devel
Kay, Allen M
2010-09-29 16:14:44 UTC
Permalink
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:***@iki.fi]
Sent: Tuesday, September 28, 2010 11:05 PM
To: Kay, Allen M
Cc: Konrad Rzeszutek Wilk; Dietmar Hahn; Han, Weidong; xen-***@lists.xensource.com; Jean Guyader
Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
Post by Kay, Allen M
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
Post by Kay, Allen M
Allen
-----Original Message-----
Sent: Monday, September 27, 2010 9:47 AM
To: Dietmar Hahn; Han, Weidong; Kay, Allen M
Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
Post by Dietmar Hahn
Hi Jean,
many thanks for this hint! This saved me a lot of time searching through
the specs.
Post by 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
check_tylersburg_isoch
Post by Dietmar Hahn
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?
Post by Dietmar Hahn
Post by Jean Guyader
The vertical stripes means GTT fault.
Jean
Many thanks!
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-09-29 19:17:47 UTC
Permalink
Post by Kay, Allen M
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
Post by Kay, Allen M
Allen
-----Original Message-----
Sent: Tuesday, September 28, 2010 11:05 PM
To: Kay, Allen M
Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
Post by Kay, Allen M
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
Post by Kay, Allen M
Allen
-----Original Message-----
Sent: Monday, September 27, 2010 9:47 AM
To: Dietmar Hahn; Han, Weidong; Kay, Allen M
Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
Post by Dietmar Hahn
Hi Jean,
many thanks for this hint! This saved me a lot of time searching through
the specs.
Post by 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
check_tylersburg_isoch
Post by Dietmar Hahn
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?
Post by Dietmar Hahn
Post by Jean Guyader
The vertical stripes means GTT fault.
Jean
Many thanks!
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
http://lists.xensource.com/xen-devel
Kay, Allen M
2010-09-29 23:14:06 UTC
Permalink
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 ***@intel.com

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:***@oracle.com]
Sent: Monday, September 27, 2010 9:47 AM
To: Dietmar Hahn; Han, Weidong; Kay, Allen M
Cc: Jean Guyader; xen-***@lists.xensource.com
Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
Post by Dietmar Hahn
Hi Jean,
many thanks for this hint! This saved me a lot of time searching through
the specs.
Post by 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
Post by Dietmar Hahn
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?
Post by Dietmar Hahn
Post by Jean Guyader
The vertical stripes means GTT fault.
Jean
Many thanks!
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
http://lists.xensource.com/xen-devel
Dietmar Hahn
2010-09-30 07:58:25 UTC
Permalink
Hi Allen,
Post by 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.
Post by Kay, Allen M
-----Original Message-----
Sent: Monday, September 27, 2010 9:47 AM
To: Dietmar Hahn; Han, Weidong; Kay, Allen M
Subject: Re: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
Post by Dietmar Hahn
Hi Jean,
many thanks for this hint! This saved me a lot of time searching through
the specs.
Post by 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
check_tylersburg_isoch
Post by Dietmar Hahn
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?
Post by Dietmar Hahn
Post by Jean Guyader
The vertical stripes means GTT fault.
Jean
Many thanks!
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
Jan Beulich
2010-10-04 08:23:47 UTC
Permalink
Post by 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().
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.
Post by Kay, Allen M
@@ -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;
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.
Post by Kay, Allen M
@@ -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.
Post by Kay, Allen M
+}
+
+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.
Post by Kay, Allen M
+ {
+ 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
Kay, Allen M
2010-10-04 15:11:14 UTC
Permalink
Post by Jan Beulich
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.
Post by Jan Beulich
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.
Post by Jan Beulich
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.
Post by Jan Beulich
Post by Kay, Allen M
+}
+
+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
Jan Beulich
2010-10-04 15:24:01 UTC
Permalink
Post by Kay, Allen M
Post by Jan Beulich
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.
Post by Kay, Allen M
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?
Post by Kay, Allen M
Post by Jan Beulich
Post by Kay, Allen M
+ 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
Kay, Allen M
2010-10-04 18:15:14 UTC
Permalink
Post by Jan Beulich
Yes, and vendor/class check would seem reasonable here.
How do you differentiate Intel IGD and discrete graphics with this method?
Post by Jan Beulich
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
Jan Beulich
2010-10-05 06:51:48 UTC
Permalink
Post by Kay, Allen M
Post by Jan Beulich
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
Kay, Allen M
2010-10-05 23:20:38 UTC
Permalink
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:***@novell.com]
Sent: Monday, October 04, 2010 11:52 PM
To: Kay, Allen M
Cc: Keir Fraser; Jean Guyader; Han, Weidong; xen-***@lists.xensource.com; KonradRzeszutek Wilk; Dietmar Hahn
Subject: RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
Post by Kay, Allen M
Post by Jan Beulich
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
Eric Riser
2010-10-08 20:33:16 UTC
Permalink
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
* 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.
* *
* *
* -----Original Message-----*
* Sent: Monday, September 27, 2010 9:47 AM*
* To: Dietmar Hahn; Han, Weidong; Kay, Allen M*
* 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
Loading...