Paravirtualized DRM

Upstream status (Linux 3.0 and higher)

[Updated on 26 Oct 2011]

3.0 kernel, works with all graphics cards - albeit there are some caveats: You need to make sure CONFIG_DMAR is set to have it working with Intel cards. The radeon and nouveau (and NVidia) work as well - except if the card is a 32-bit card (ATI ES1000 for example). In that case you the patches posted on dri-devel mailing list: [1] should solve the problem. It is also available in this git tree: git://oss.oracle.com/git/kwilk/xen.git devel/ttm.dma_pool.v2.1

The radeon or nouveau driver might also cause a wealth of:

WARNING: at arch/x86/xen/mmu.c:665 xen_make_pte+0x39/0xa2()

in which case pass in nopat on your Linux command line.

2.6.37 and 2.6.38 can be booted with Xen hypervisor. However the graphic subsystem does not work. In 2.6.39 patches were put that made them work, but sadly they broke PowerPC and ARM so were reverted.

Terminology

What is DRM?

DRM stands for Direct Rendering Manager http://dri.freedesktop.org/wiki/DRM which "deals with DMA, AGP memory management, resource locking, and secure hardware access" to graphics cards.

What is KMS?

Kernel Mode Setting http://en.wikipedia.org/wiki/Mode-setting and http://kerneltrap.org/node/8242 is a mechanism for the kernel to initialize the graphic card and when X Server, the graphic context is handed over without having to another initialization. Per Jesse Barnes: "modesetting and proper multihead support into the kernel ..." provides "... suspend/resume,debugging (e.g. panic), non-X uses and more reliable VT switch". KMS depends on DRM.

What is TTM?

Translation Table Maps http://lwn.net/Articles/257417/ is a mechanism for the graphics card drivers to have one uniform mechanism to allocate/get/de-allocate/manage the memory for the graphic card. This memory being either System RAM or the PCI/PCI-e/AGP card's memory. Many in-kernel KMS driver's utilize TTM.

Issues in 2.6.38

[This is obsolete, as the 2.6.38 branch is .. well old and not used anymore]

The devel/next-2.6.38 is a development branch. So it is not yet completely stable. Please report any problems on xen-devel mailing list.

Problems that are fixed in 2.6.38

[This is obsolete, as the 2.6.38 branch is .. well old and not used anymore]

NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated [device

This shows up if the CONFIG_DEBUG_DMA_API=y is compiled. The problem is actually not the one that is reported but rather of an accounting problem. When the TTM layer allocates DMA pages it passes in as a 'struct device' the NULL pointer (which is OK). The DMA API debug API during its reporting has a check whether the passed in DMA address matches a specific 'struct device' pointer and since the 'struct device' pointer is NULL it ends up reporting this.

The patches for this is #devel/ttm.pci-api.v5 and are also present in #devel/next-2.6.38.

• 7333019 ttm: Pass in 'struct device' to TTM so it can do DMA API on behalf of device.
• 02bbfba ttm: Include the 'struct dev' when using the DMA API.

Outstanding issues

Intel i915 does not work

Reports are that the screen prints out a checkerboard. The mouse cursor is visible. The kernel serial output is:

   17.468595] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung                                             
[   17.471533] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting 3 at 0, next 4)                        
[   17.998586] [drm:i915_reset] *ERROR* Failed to reset chip.     

Xorg fails with intel_uxa_prepare_access which looks to be a general fault for "I am out of memory" problem.

Patches for 2.6.32.x

All of the patches mentioned in this Wiki have been merged in Jeremy's PV-OPS tree.

Status for 2.6.32.x

[This is obsolete, as the 2.6.32 branch is .. well old and not used anymore] With those patches, you can get Kernel Mode Setting (KMS) and Xorg (1.7,1.8) working. The NVidia cards were not tested with earlier version of Xorg 1.7 since the the nouveau kernel driver + xorg driver were not yet available.

The tree I used for testing was: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git branch devel/next.drm. The tree is the same as jeremy's xen/stable-2.6.32.x except it has an version of DRM/KMS from 2.6.34 plucked in.

The 'X' means it was tested and worked (saw X boot up, moved the cursor, launched firefox/gnome-terminal). And also ran TuxRacer or OpenArena.

Card	FrameBuffer	KMS	XServer (<=1.6)	Xorg (1.7, 1.8)
RIVA TNT2 Pro	X		n/a	X
GeForce 1 256	X	X	n/a	X
GeForce 3 NV20	X	X	n/a	loop
GeForce 4 Ti 4200	X	X	n/a	X
GeForce 5 FX5200	X	X	n/a	X
GeForce 6150	X	X	n/a	X
GeForce 6200	-	-	-	-
GeForce 7300	-	-	-	-
GeForce 8600 GT	X	X	n/a	X
Radeon R100 QD (7200)	X	X	?	X
Radeon RV100QY (7000)	X	X	?	X
Radeon RV516 (X1300/X1550)	X	X	?	X
Radeon HD 3200	X	X	?	X
Radeon HD 3450	X	X	?	X
Radeon HD 4350	X	X	?	X
Radeon RV710 [Radeon HD 4350]	X	X	?	X
Radeon ES1000	X	X	?	X
ICH5 82865G	X	X	?	X
ICH7 82G33/G31G	X	X	?	X
ICH8 82Q963/Q965	X	X	?	X
Matrox G450	X	n/a	?	X
XGI Z7/Z9 (XG20 core)	X	n/a	?	X

Xen paravirt_ops KMS issues workaround for 2.6.32.x

[This is obsolete, as the 2.6.32 branch is .. well old and not used anymore] If you get bootup errors or you machine refuses to show graphics, add this to you kernel command line:

nomodeset

Xen paravirt_ops debugging

To aid us in debugging, add this to your kernel command line:

drm.debug=255

and provide the full serial output to us. For details on how to do so, refer to the Self:XenParavirtOps wiki

Xen paravirt_ops DRM/KMS/TTM/Xserver issues for 2.6.32.x

[This is obsolete, as the 2.6.32 branch is .. well old and not used anymore]

What about XServer? How does it fit in here? (2.6.32.x )

In the past (Fedora Core 11) XServer would load its X drivers which would make DRM calls and calls to the DRM-vendor specific drivers (radeon, nouvea, i915) to initialize the card, setup the graphic context, etc. With the introduction of KMS, the initialization part is done in kernel. X server probes DRM for the state and if it find that it has been initialized in the past with KMS it uses that graphic context.

Why those patches? (for 2.6.32.x)

Well, the pvops kernel has a couple of interesting memory management techniques that throw a wrench in DRM/KMS/TTM:

• The kernel idea of pages is an illusion. It thinks that the pages start at 0 and go up to the memory available. Hence the pv-ops kernel has a lookup mechanism where it can translate the page frame numbers (PFN) to machine frame numbers (MFN), and also vice-versa.
• Memory is not contiguous. Xen hypervisor allocates the memory from its pools of memory and your are not guaranteed that the PFN==MFN and PFN+1==MFN+1.
• Some of the PFNs are MFNs. Those are the pages that are _PAGE_IOMAP (VM_IO) and are used for PCI devices. Those are _only_ provided when the device driver uses the DMA API.

The problems are that the graphic drivers make certain assumptions where the PFN is used to come up with a physical address. That works correctly on baremetal, but under Xen the MFN must be used, not the PFN. Under Xen a DMA address is actually the MFN (machine frame number) which is bitshifted by twelve and an offset added.

            phys = (pte_mfn(*pte) << PAGE_SHIFT) + offset;

The 'phys' now has the physical address that PCI bus (and the video card) would utilize to request data to. Please keep in mind that the 'pte_mfn' is a special Xen function. Normally one would do 'pte'.

For pages that are being utilized for PCI devices (and that have _PAGE_IOMAP PTE flag set), the GPFN (PFN from Linux side, Guest Page Frame Number from Xen side) is actually the MFN, while for the rest (like the pages allocated by the mmap and then stitched up in the ttm_bo_fault handler), it is the PFN.

Distros (2.6.32.x)

Fedora Core 12 and above has KMS enabled with NVidia drivers (nouvea)

Lenny has Xorg 1.4.2. To run xen, one has to use the nv-DDX driver, and suffer console black-outs on console switching. The proprietary driver interfaces cannot be compiled for xen (domU or dom0)

Xorg 1.7.5 breaks the nv-DDX driver even on bare-boots - something about who is to set the default cmaps - nv or Xorg So one is left (very very luckily) with nouveau and backports of kernel and Xorg.

And fbdev crashes on Xorg-1.7.5 and xen (verified on dom0) saying something bogus about not being able to compile keymaps - really crashes in mode-setting I suspect. But fbdev is the only choice of DDX on pvfb domUs.

Problems that are fixed (for 2.6.32.x)

nouveau: NVidia 6-series and above (2.6.32.x)

• Update*: July 28 2010:

The patch titled: ttm: Only set VM_IO on regions which are backed by VRAM or SYSTEM_RAM, fixes

• GeForce 6200
• GeForce 7300
• GeForce 9400 GT
• Geforce FX5200

albeit it broke older AGP cards. However, if you these additionally patches:

• ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under and
• intel-agp: Use Xen back-door to get page's physical address for i8[1,3]0
• intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus addresses.
• agp-backend: Use Xen back-door to get bus address for scratch page.
• agp: If _GFP_DMA_32 flag is set enforce pages to be under 4GB under Xen.
• agp: Program the GART with the real physical address under Xen.
• agp: Use Xen back-door to get bus address for legacy code.

Then you are all set.

XServer (1.6 and older): radeon: [drm:r100_ring_test] *ERROR* radeon: ring test failed (2.6.32.x)

Fixes:

• ATI Radeon HD 3200
• Update*: fix is in xen/next. The two patches that fix this are:
  • drm: make sure page protections are updated after changing vm_flags.
  • drm: free vmalloc dma memory properly

The problem was the radeon driver doing a scratch buffer test. The fix is in xen/next and changes drm_vmalloc_dma to use dma_alloc_coherent instead of vmalloc_32 to get pages that when aliased still point to the proper MFNs.

But when KMS starts it was still a problem. However, the next section has the fix.

KMS: Radeon [drm:r600_ring_test] *ERROR* radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD) (2.6.32.x)

Fixes:

• ATI Radeon HD 3200
• Update*: patch titled:
• ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under

will fix this.

When using KMS this was appearing.

[   32.247954] [drm:r600_ring_test] *ERROR* radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD)

Analysis: The scratch buffer uses the command processor ring which appears to point to the wrong physical location of the GPU. What transpires is a set of steps where:

• radeon_driver registers with the TTM module: ttm_tt_create.
• then calls the TTM module to allocate a 1MB of pages (bunch of calls, ends in ttm_tt_bind)
• TTM does that by calling ttm_tt_populate, which calls ttm_tt_get_page 255 times. Each call to is actually a call to ttm_tt_alloc_page, which sets gfp_flags |= GFP_DMA32 and calls return alloc_page(gfp_flags);. This being under Xen, the GFP_DMA32 is ignored and the page returned might be above the 32-bit mark.
• ttm_tt_bind calls the radeon driver bind function (be->func->bind), which is radeon_ttm_backend_bind
• the radeon_ttm_backend_bind sets those pages physical addresses (DMA or bus addresses) in the GART - via radeon_gart_bind.
• radeon_gart_bind walks over all of the pages and calls:

 for (i = 0; i < pages; i++, p++) {
176                 /* we need to support large memory configurations */
177                 /* assume that unbind have already been call on the range */
178                 rdev->gart.pages_addr[p] = pci_map_page(rdev->pdev, pagelist[i],
179                                                         0, PAGE_SIZE,
180                                                         PCI_DMA_BIDIRECTIONAL);
.. snip ..
186                 rdev->gart.pages[p] = pagelist[i];
187                 page_base = rdev->gart.pages_addr[p];
188                 for (j = 0; j < (PAGE_SIZE / RADEON_GPU_PAGE_SIZE); j++, t++) {
189                         radeon_gart_set_page(rdev, t, page_base);
190                         page_base += RADEON_GPU_PAGE_SIZE;
191                 }

the "pci_map_page" takes the address of the "pagelist[i]" and figures out if the physical address (DMA) is within the bounds of what the device can do. The "pagelist[i]" is the set of 255 pages allocated via alloc_pages(...) which on baremetal would be under the 4GB, while on Xen might be above, it ends using the SWIOTLB for those pages above the 4GB mark. What ends up happening is this:

    rdev->gart.pages_addr[0] = 0x1e2000
    pfn_to_mfn(page_to_pfn(rdev->gart.pages[0])) = 0x205e74

And the GART gets the 0x1e2000 instead of the 0x205e74 programmed for the first page.

• When the r600_ring_test is executed, the operations on the cp_ring buffer are done, the result is copied by the GART to the SWIOTLB pages instead of the allocated pages via alloc_pages! All b/c the physical addresses in the GART are invalid.

Intel i915 (2.6.32.x)

• Update*: Fixed:
• CONFIG_DMAR is set and
• ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under.. patch is used.

If you do not have these patches it would crash with KMS. Interestingly, if only 2GB was passed to Dom0, the problem would disappear.

[    0.649801] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
... snip ..
[   23.720534] [drm] Initialized drm 1.1.0 20060810
[   23.798706] xen: registering gsi 16 triggering 0 polarity 1
[   23.798709] xen_allocate_pirq: returning irq 16 for gsi 16
[   23.798711] xen: --> irq=16
[   23.798713] Already setup the GSI :16
[   23.798717] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   23.798723] i915 0000:00:02.0: setting latency timer to 64
[   23.637546] mtrr: type mismatch for d0000000,10000000 old: write-back
new: write-combining
[   23.637553] [drm] MTRR allocation failed.  Graphics performance may
suffer.
[   23.637771]   alloc irq_desc for 1249 on node 0
[   23.637774]   alloc kstat_irqs on node 0
[   23.637817] [drm] set up 127M of stolen space
[   23.986808] BUG: unable to handle kernel paging request at
ffffc9000007c000
[   23.986815] IP: [<ffffffffa00dc0df>]
intel_i915_chipset_flush+0x11/0x14 [intel_agp]
[   23.986823] PGD 3f80c067 PUD 3f80d067 PMD 3f80e067 PTE 0
[   23.986828] Oops: 0002 [#1] SMP
[   23.986831] last sysfs file: /sys/module/agpgart/initstate
[   23.986833] CPU 3
[   23.986835] Modules linked in: i915(+) drm_kms_helper drm
i2c_algo_bit video output ppdev lp parport sco bnep rfcomm l2cap crc16
bluetooth rfkill battery cpufreq_stats cpufreq_userspace
cpufreq_conservative cpufreq_powersave fuse hwmon_vid k8temp eeprom
i2c_nforce2 firewire_sbp2 firewire_core crc_itu_t loop
snd_hda_codec_intelhdmi snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi
snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device
asus_atk0110 processor pcspkr i2c_i801 i2c_core evdev snd soundcore
snd_page_alloc ext3 jbd mbcache dm_mod raid1 md_mod sg usbhid hid sr_mod
cdrom sd_mod crc_t10dif ata_generic r8169 mii ata_piix pata_jmicron
intel_agp libata scsi_mod ehci_hcd ide_pci_generic ide_core button
usbcore nls_base agpgart thermal fan thermal_sys [last unloaded:
scsi_wait_scan]
[   23.986900] Pid: 2526, comm: modprobe Not tainted
2.6.32.10-pvops-dom0 #31 System Product Name
[   23.986902] RIP: e030:[<ffffffffa00dc0df>]  [<ffffffffa00dc0df>]
intel_i915_chipset_flush+0x11/0x14 [intel_agp]
[   23.986907] RSP: e02b:ffff88003fbefb10  EFLAGS: 00010286
[   23.986909] RAX: ffffc9000007c000 RBX: ffff88003d901c00 RCX:
0000000000001000
[   23.986911] RDX: 0000000000000001 RSI: 00000000000007e9 RDI:
ffff880002295c00
[   23.986913] RBP: ffff88003f352000 R08: ffff88003fbee000 R09:
ffff88003fbee000
[   23.986915] R10: 0000000000000040 R11: ffff8800016a3000 R12:
0000000000000001
[   23.986916] R13: ffff8800023df0c0 R14: 0000000000000001 R15:
0000000000000001
[   23.986922] FS:  00007fdbe68c36f0(0000) GS:ffff880003440000(0000)
knlGS:0000000000000000
[   23.986924] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[   23.986926] CR2: ffffc9000007c000 CR3: 000000000219f000 CR4:
0000000000002660
[   23.986928] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[   23.986930] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[   23.986932] Process modprobe (pid: 2526, threadinfo ffff88003fbee000,
task ffff880002a4f000)
[   23.986934] Stack:
[   23.986936]  ffffffffa03013e3 ffff88003d901c00 ffff88003d901c00
0000000000000000
[   23.986939] <0> ffffffffa0302971 ffff8800023df0c0 ffff88003f352000
0000000000000000
[   23.986943] <0> ffff88003f847000 ffff88003d901c00 0000000000000438
ffff8800023df0c0
[   23.986948] Call Trace:
[   23.986961]  [<ffffffffa03013e3>] ?
i915_gem_object_flush_cpu_write_domain+0x20/0x3e [i915]
[   23.986972]  [<ffffffffa0302971>] ?
i915_gem_object_set_to_gtt_domain+0x58/0x9a [i915]
[   23.986984]  [<ffffffffa031a649>] ? intelfb_create+0x1de/0x5c1 [i915]
[   23.986988]  [<ffffffffa02ecba4>] ?
drm_fb_helper_single_fb_probe+0x1c9/0x415 [drm_kms_helper]
[   23.986994]  [<ffffffff81036ca2>] ? check_events+0x12/0x20
[   23.987005]  [<ffffffffa031a46b>] ? intelfb_create+0x0/0x5c1 [i915]
[   23.987008]  [<ffffffff81036c8f>] ? xen_restore_fl_direct_end+0x0/0x1
[   23.987012]  [<ffffffffa02ef226>] ?
drm_helper_initial_config+0x56/0x5a [drm_kms_helper]
[   23.987021]  [<ffffffffa02faa93>] ? i915_driver_load+0xe65/0xf10 [i915]
[   23.987027]  [<ffffffffa02cfbf8>] ? drm_get_minor+0x226/0x27d [drm]
[   23.987032]  [<ffffffffa02cff6a>] ? drm_get_dev+0x31b/0x427 [drm]
[   23.987037]  [<ffffffff811bbed5>] ? local_pci_probe+0x12/0x16
[   23.987039]  [<ffffffff811bca9c>] ? pci_device_probe+0x58/0x84
[   23.987043]  [<ffffffff8123ae91>] ? driver_sysfs_add+0x42/0x69
[   23.987046]  [<ffffffff8123afc1>] ? driver_probe_device+0x9c/0x123
[   23.987049]  [<ffffffff8123b097>] ? __driver_attach+0x4f/0x6f
[   23.987052]  [<ffffffff8123b048>] ? __driver_attach+0x0/0x6f
[   23.987055]  [<ffffffff8123a690>] ? bus_for_each_dev+0x44/0x78
[   23.987058]  [<ffffffff8123aade>] ? bus_add_driver+0xa8/0x1f2
[   23.987061]  [<ffffffff8123b33c>] ? driver_register+0x8f/0xf7
[   23.987063]  [<ffffffff811bcccd>] ? __pci_register_driver+0x4e/0xbe
[   23.987072]  [<ffffffffa0337000>] ? i915_init+0x0/0x52 [i915]
[   23.987079]  [<ffffffffa0337000>] ? i915_init+0x0/0x52 [i915]
[   23.987083]  [<ffffffff8100a087>] ? do_one_initcall+0x63/0x191
[   23.987086]  [<ffffffff8109f9a6>] ? sys_init_module+0xc6/0x220
[   23.987090]  [<ffffffff81039c42>] ? system_call_fastpath+0x16/0x1b
[   23.987091] Code: 48 8b 4f 08 48 63 d2 48 89 f0 48 c1 e2 04 48 8b 49
20 48 0b 04 0a c3 31 c0 c3 48 8b 05 43 58 00 00 48 85 c0 74 07 ba 01 00
00 00 <89> 10 c3 48 8b 15 07 58 00 00 48 8b 8a e8 02 00 00 48 85 c9 75
[   23.987130] RIP  [<ffffffffa00dc0df>]
intel_i915_chipset_flush+0x11/0x14 [intel_agp]
[   23.987134]  RSP <ffff88003fbefb10>
[   23.987135] CR2: ffffc9000007c000
[   23.987138] ---[ end trace 92fec4cdf129d18d ]---
[   29.072420] eth0: no IPv6 routers present
[   28.872271] peth0: no IPv6 routers present

Excerpts from lspci:

00:02.0 VGA compatible controller: Intel Corporation Core Processor
Integrated Graphics Controller (rev 12) (prog-if 00 [VGA controller])
     Subsystem: ASUSTeK Computer Inc. Device 8383
     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
     Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
     Latency: 0
     Interrupt: pin A routed to IRQ 1249
     Region 0: Memory at fb800000 (64-bit, non-prefetchable) [size=4M]
     Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
     Region 4: I/O ports at cc00 [size=8]
     Expansion ROM at <unassigned> [disabled]
     Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
         Address: fee0200c  Data: 4151
     Capabilities: [d0] Power Management version 2
         Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
         Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
     Capabilities: [a4] PCI Advanced Features
         AFCap: TP+ FLR+
         AFCtrl: FLR-
         AFStatus: TP-
     Kernel driver in use: i915
...

Update May272010: This looks to be related to the intel-agp.c code. When the GART is initialized instead of using the PCI DMA it uses another, which can allocate pages above the 4GB. Setting CONFIG_DMAR in your .config will take care of that.

Intel i860 (2.6.32.x)

• Update*: KMS is fixed with this patch:
• intel-agp: Use Xen back-door to get page's physical..

These are a bit ancient chipsets. Problem is intel-agp.c code.

Radeon fencing (2.6.32.x)

• Update*: June 15 2010: No more.
• Update*: Jun 9th 2010: Haven't reverified with new patches.

I had gotten this on the devel SuperMicro X7DB8+:

[radeon_fence_wait] *ERROR* fence(ffff880003295880:0x00000001) 510ms timeout going to reset GPU

NVidia PCI/AGP cards (Xorg) (2.6.32.x)

• Update*: Fixed with this patch:
• ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set'
• intel-agp: Use Xen back-door to get page's physical address for i8[1,3]0
• intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus addresses.
• agp-backend: Use Xen back-door to get bus address for scratch page.
• agp: If _GFP_DMA_32 flag is set enforce pages to be under 4GB under Xen.
• agp: Program the GART with the real physical address under Xen.
• agp: Use Xen back-door to get bus address for legacy code.

When X starts it would have failed over with:

(XEN) mm.c:1747:d0 Bad L1 flags c00000
(XEN) mm.c:779:d0 Bad L1 flags c00000
(XEN) mm.c:4659:d0 ptwr_emulate: could not get_page_from_l1e()
[  123.222339] BUG: unable to handle kernel paging request at ffff8800747382f8
[  123.222339] IP: [<ffffffff8100e73a>] xen_set_pte+0x31/0x36
[  123.222339] PGD 1002067 PUD 2e4067 PMD 488067 PTE 10000074738065
[  123.222339] Oops: 0003 [#1] SMP
[  123.222339] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:02:0d.0/local_cpus
[  123.222339] CPU 0
[  123.222339] Modules linked in: skge dm_multipath nouveau ttm drm_kms_helper drm i2c_algo_bit [last unloaded: scsi_wait_scan]
[  123.222339] Pid: 2752, comm: Xorg Not tainted 2.6.32.12 #15 System Product Name
[  123.222339] RIP: e030:[<ffffffff8100e73a>]  [<ffffffff8100e73a>] xen_set_pte+0x31/0x36
[  123.222339] RSP: e02b:ffff880074a8bc78  EFLAGS: 00010246
[  123.222339] RAX: 0000000000000000 RBX: ffff8800747382f8 RCX: fffff7fffffff237
[  123.222339] RDX: 0000000000000000 RSI: fffff7fffffff237 RDI: ffff8800747382f8
[  123.222339] RBP: ffff880074a8bc88 R08: ffff880074a8bd60 R09: 0000000000000001
[  123.222339] R10: 0000000000000080 R11: 00007f14d055c6d0 R12: fffff7fffffff237
[  123.222339] R13: 00007f14d165f000 R14: 0000000000000037 R15: 00000000000ec024
[  123.222339] FS:  00007f14d16487a0(0000) GS:ffff880002e47000(0000) knlGS:0000000000000000
[  123.222339] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  123.222339] CR2: ffff8800747382f8 CR3: 0000000074b11000 CR4: 0000000000000660
[  123.222339] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  123.358632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  123.365824] Process Xorg (pid: 2752, threadinfo ffff880074a8a000, task ffff880074732620)
[  123.366090] Stack:
[  123.366090]  fffff7fffffff237 ffff8800747382f8 ffff880074a8bcd8 ffffffff8100e7e6
[  123.366090] <0> ffffffff8100c59d 00007f14d055c6d0 0000000000000080 0000000000000001
[  123.385710] <0> ffff880074a8bd60 00007f14d165f000 00000000fffffff0 ffff880074b70000
[  123.385710] Call Trace:
[  123.385710]  [<ffffffff8100e7e6>] xen_set_pte_at+0xa7/0xb2
[  123.385710]  [<ffffffff8100c59d>] ? __raw_callee_save_xen_make_pte+0x11/0x1e
[  123.385710]  [<ffffffff810cd303>] vm_insert_mixed+0x86/0xb0
[  123.385710]  [<ffffffffa003d68a>] ttm_bo_vm_fault+0x201/0x26c [ttm]
[  123.385710]  [<ffffffff810ce190>] __do_fault+0x4f/0x385
[  123.385710]  [<ffffffff8100c8e1>] ? xen_pud_val+0x9/0xb
[  123.385710]  [<ffffffff810cee6c>] handle_mm_fault+0x33e/0x730
[  123.385710]  [<ffffffff815547ea>] ? error_exit+0x2a/0x60
[  123.385710]  [<ffffffff8101249d>] ? retint_restore_args+0x5/0x6
[  123.385710]  [<ffffffff8100922a>] ? hypercall_page+0x22a/0x1006
[  123.385710]  [<ffffffff815566d6>] do_page_fault+0x2c2/0x2da
[  123.385710]  [<ffffffff815545b5>] page_fault+0x25/0x30
[  123.385710] Code: ec 10 f7 c6 00 04 00 00 74 0c ba f1 7f 00 00 e8 64 ff ff ff eb 18 48 89 75 f0 48 89 7d f8 e8 f6 f1 01 00 48 8b 75 f0 48 8b 7d f8 <48> 89 37 c9 c3 55 48 89 e5 41 55 49 89 f5 41 54 49 89 cc 53 48
[  123.385710] RIP  [<ffffffff8100e73a>] xen_set_pte+0x31/0x36
[  123.385710]  RSP <ffff880074a8bc78>
[  123.385710] CR2: ffff8800747382f8
[  123.385710] ---[ end trace ba4c552f83018d68 ]---

Hmm... I just verified that this patch fixes KMS/Nouveau issues in Xen on my two primary test boxes (GeForce 6200, GeForce 7300). However, on my really old machines (AGP GeForce2 MX200), this causes a new crash. These old boxes were actually working fine in Xen prior to this patch, just w/out 3d acceleration.

Now I get the following messages in dmesg:

[  129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
[  129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 1
[  129.643791] X: Corrupted page table at address 40412000
[  129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000
[  129.643856] Bad pagetable: 000f #1 SMP
[  129.643897] last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga
[  129.643916] Modules linked in: bridge stp ipv6 autofs4 sunrpc raid1 video output sbs sbshc pci_slot lp sg nouveau snd_intel8x0 snd_ac97_codec
[  129.644024]
[  129.644024] Pid: 3690, comm: X Not tainted (2.6.31.6-mdl5 #1) P4DC6
[  129.644024] EIP: 0073:[<40394596>] EFLAGS: 00210206 CPU: 0
[  129.644024] EIP is at 0x40394596
[  129.644024] EAX: 40412000 EBX: 40396cd8 ECX: 0909ee98 EDX: 00044000
[  129.644024] ESI: 00000034 EDI: 0909edd8 EBP: bfe7f798 ESP: bfe7f780
[  129.644024]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[  129.644024] Process X (pid: 3690, ti=ea1ce000 task=ea77f110 task.ti=ea1ce000)
[  129.644024]
[  129.644024] EIP: [<40394596>] 0x40394596 SS:ESP 007b:bfe7f780
[  129.644024] ---[ end trace 569eb18d737a8611 ]---
[  129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing fifo 1 And my X log ends abruptly after this line: (II) NOUVEAU(0): Opened GPU Channel 1

which patch mentioned in section titled Intel i860 fixes.

Analysis: Arvind wonders if the older cards support accelerated modes? Channel 1 is the console channel and unaccelerated X uses only that. AIGLX will start up channel 2, and if X is gallium-enabled, channel 3 will start. libGL apps will start new channels (upto what the card supports - which varies). I assume the patch does NOT affect unaccelerated X on the older cards?

Whats funny is that, in all my traces, X never opens channel 1 - it is already opened by the console and all X has to do (using ioctls) is to do is a kernel-modeset, if native console and X are in different modes (I've not been able to get the native console to a lower resolution (got very comfortable with the higher res. meanwhile!)). Xorg used to hang saying 'Opened Channel 2' and not 1.

• In another e-mail correspondence: >> Try with >> Option "ShadowFB" "true" >> in Device section of xorg.conf (turns off acceleration) to check. The > option >> also sets NoAccel on and X should use the FB device > > Tried this. GDM starts fine in Xen and I can log in, but wow slow. Now > there's no reference to any GPU channel being opened in my X log. > The problem may be due to the initial AGP-memory allocation setting up the wrong flags. And the older AGP cards seem to work differently

from the newer PCI/E ones.

Until someone resolves the agp issue, I guess your best choice is to remove the ShadowFB option in the conf file and not install the dri package (nouveau_dri.so and swrast_dri.so) in the AGP systems. That means you will have 2D-accel but no glx (3D-accel).

• Jeremy was wondering if this AGP chipset related. The box is an old Xeon SMP box. SuperMicro P4DC6+, which looks to be a Intel 860 AGP chipset http://www.supermicro.com/products/motherboard/Xeon/860/P4DC6_.cfm
• The end conclusion was that Jeremy was correct. The GART that was utilized was the i860 which did not properly program the physical address under Xen.

Reading of EDID (2.6.32.x)

• Update*: Jun 15 2010: No problems.

Radeon and i915 both have trouble reading the EDID information to determine what kind of monitor is plugged in. This is both done by DRM and X server.

Konrad found out that the baremetal logs look to have it too, so maybe this is a red-herring. baremetal:

[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA
[drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[drm]   Encoders:
[drm]     CRT1: INTERNAL_DAC1
[drm] Connector 1:
[drm]   DVI-D
[drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[drm]   Encoders:
[drm]     DFP2: INTERNAL_DVO1
i2c-adapter i2c-1: unable to read EDID block.
radeon 0000:11:04.0: DVI-D-1: no EDID data
[drm] fb mappable at 0xD8040000
[drm] vram apper at 0xD8000000
[drm] size 5242880
[drm] fb depth is 24
[drm]    pitch is 5120
[drm] DAC-5: set mode 1280x1024 1a

or Intel:

[   22.928572]   alloc kstat_irqs on node 0
[   22.930539] [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-C
[   22.977067] [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-D
[   23.244091] i2c-adapter i2c-2: unable to read EDID block.
[   23.244097] i915 0000:00:02.0: DVI-D-2: no EDID data

PV fbdev (Xen-fbfront) has mouse pointer updates issues (2.6.32.x)

• Update*: [2] Xen 4.0.1-rc4 with 2.6.32.16 has it fixed.

Notes:

The other problem I'd noticed is that on one of my hosts PV domains are always getting relative mouse pointer updates from pvfb, whereas HVM domains get nice absolute ones. But on another of my hosts it all works fine. I haven't done a detailed comparison yet, but I think there's probably a difference in kernel config, maybe? n-fbfront) has mouse pointer updates issues

Frame buffers (/dev/fb0 mmap and writing to it) (2.6.32.x)

• Update* July 28 2010. The patch titled:
  • fb: propagate VM_IO to VMA.

fixes it.

• Older update* [3]; this code snippet [4] demonstrates it working (you should see a green background with a white rectangle inside).

Analysis: Both i915 and nouveau horribly failed when they tried to allocate this. This looks to be the AGP code (drivers/char/agp/*) where the intel-agp.c had been fixed to use the PCI DMA to properly get the DMA address. The rest of the AGP drivers hadn't been touched, so it might be that this failure is b/c of that. (xen/dom0/agp branch has details). This looks to be DRM framebuffers subsystem, not the old framebuffer system.

In actuality it was the old drivers/video/fbmem.c driver that was utilized. When we setup up the VMA flags for the mmap flag (during the mmap call) and we end up using the fallback mmap functionality we set the vma->vm_flags |= VM_IO (which is correct). However we neglected to propagate the flag to the vma->vm_page_prot. The patch fixes that.

NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated [device (2.6.32.x)

• Update*: Aug-5-2010: I realized I saw this on Fedora 13, when it was in rawhide state. The version of

Xorg was 1.7.999.91 (1.8.0RC1). Retrying the same patches with a baked version of Fedora Core 13 (with Xorg 1.8) did not produce this anymore.

------------[ cut here ]------------
WARNING: at lib/dma-debug.c:802 check_unmap+0x18f/0x615()
Hardware name: X8DTN
NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x00000000b8bbe000] [size=4096 bytes]
Modules linked in: nfs lockd fscache nfs_acl auth_rpcgss sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_emu10k1_synth snd_]
Pid: 60, comm: events/9 Not tainted 2.6.32.12-clean4 #27
Call Trace:
 [<ffffffff81059d85>] warn_slowpath_common+0x7c/0x94
 [<ffffffff81059df4>] warn_slowpath_fmt+0x41/0x43
 [<ffffffff81252429>] ? check_unmap+0x100/0x615
 [<ffffffff8124f4fb>] ? xen_virt_to_bus+0x11/0x13
 [<ffffffff812524b8>] check_unmap+0x18f/0x615
 [<ffffffff8100f5a2>] ? check_events+0x12/0x20
 [<ffffffff8100ee11>] ? xen_force_evtchn_callback+0xd/0xf
 [<ffffffff8100f5a2>] ? check_events+0x12/0x20
 [<ffffffff812529aa>] debug_dma_free_coherent+0x6c/0x7a
 [<ffffffffa00441fc>] ttm_tt_free_alloced_pages+0x125/0x17c [ttm]
 [<ffffffffa004462a>] ttm_tt_destroy+0x51/0xa6 [ttm]
 [<ffffffffa0044cc0>] ttm_bo_release_list+0x96/0xd5 [ttm]
 [<ffffffffa0044c2a>] ? ttm_bo_release_list+0x0/0xd5 [ttm]
 [<ffffffff81241791>] kref_put+0x43/0x4d
 [<ffffffffa0045cd6>] ttm_bo_delayed_delete+0xa7/0xfe [ttm]
 [<ffffffffa0045d4c>] ttm_bo_delayed_workqueue+0x1f/0x34 [ttm]
 [<ffffffff810754a6>] worker_thread+0x257/0x350
 [<ffffffff8107544e>] ? worker_thread+0x1ff/0x350
 [<ffffffffa0045d2d>] ? ttm_bo_delayed_workqueue+0x0/0x34 [ttm]
 [<ffffffff81079f1a>] ? autoremove_wake_function+0x0/0x39
 [<ffffffff8107524f>] ? worker_thread+0x0/0x350
 [<ffffffff81079c48>] kthread+0x7f/0x87
 [<ffffffff81013dea>] child_rip+0xa/0x20
 [<ffffffff81013750>] ? restore_args+0x0/0x30
 [<ffffffff81013de0>] ? child_rip+0x0/0x20
---[ end trace 370920669967979c ]---

PSE PAT check warning (2.6.32.x)

• Update*: Aug 6th 2010: Found the problem. This patch in devel/pat fixes the problem:
• xen/pat: make pte_flags(x) a pvops function.
• Update*: July 28 2010: Was a problem.

The Radeon driver sets pages to WB, but during the process the _PAGE_PSE bit is set too (which is not proper as _PSE is for 2MB pages). The problem was that the radeon would ask TTM to set the pages to WB (writeback). TTM would call 'set_memory_wb' which ended up calling the CPA subsystem. That subsystem would would fetch the flags that are on the PTE and apply a clearing mask and a setting mask. All good, except that the fetching of the flags would utilize a 'native' call that would return non-filtered results. Meaning that if we had set _PAT flag on the PTE (which we need to do as Xen's understanding of PTE's flag is different from ours, and PAT==WC (in the Xen), while on Linux PAT==WB). Since we didn't have the filter in place for 'pte_flags(x)' we would get the raw data and try to set them which would trip up the MMU subsystem. The fix is to make 'pte_flags' call the filtered function 'pte_val' instead of 'native_pte_val' to retrieve the flags.

------------[ cut here ]------------
WARNING: at arch/x86/xen/mmu.c:665 xen_make_pte+0x39/0xa2()
Hardware name: System Product Name
Modules linked in: nfs lockd fscache nfs_acl auth_rpcgss sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd skge iTCO_wdt soundcore iTCO_vendor_support pcspkr snd_page_alloc shpchp dm_multipath radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: microcode]
Pid: 1719, comm: Xorg Not tainted 2.6.32.12-clean4 #27
Call Trace:
 [<ffffffff81059d85>] warn_slowpath_common+0x7c/0x94
 [<ffffffff81059db1>] warn_slowpath_null+0x14/0x16
 [<ffffffff8100db6f>] xen_make_pte+0x39/0xa2
 [<ffffffff8100c82d>] __raw_callee_save_xen_make_pte+0x11/0x1e
 [<ffffffff810388cd>] ? __change_page_attr_set_clr+0x174/0x85d
 [<ffffffff814993b8>] ? _spin_unlock+0x2b/0x30
 [<ffffffff811096e0>] ? __purge_vmap_area_lazy+0x1a1/0x1b0
 [<ffffffff8110a623>] ? vm_unmap_aliases+0x193/0x1a2
 [<ffffffff8100ee11>] ? xen_force_evtchn_callback+0xd/0xf
 [<ffffffff8103911f>] change_page_attr_set_clr+0x169/0x390
 [<ffffffff8100f5a2>] ? check_events+0x12/0x20
 [<ffffffff81039436>] change_page_attr_clear+0x2f/0x31
 [<ffffffff810395bb>] _set_memory_wb+0x21/0x23
 [<ffffffff810395d8>] set_memory_wb+0x1b/0x54
 [<ffffffff8103964f>] set_pages_wb+0x3e/0x40
 [<ffffffffa0043c7a>] ttm_tt_set_page_caching+0x21/0x81 [ttm]
 [<ffffffffa0044076>] ttm_tt_set_caching+0x69/0xca [ttm]
 [<ffffffff8108b951>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffffa0044110>] ttm_tt_free_alloced_pages+0x39/0x17c [ttm]
 [<ffffffffa004462a>] ttm_tt_destroy+0x51/0xa6 [ttm]
 [<ffffffffa0044cc0>] ttm_bo_release_list+0x96/0xd5 [ttm]
 [<ffffffffa0044c2a>] ? ttm_bo_release_list+0x0/0xd5 [ttm]
 [<ffffffff81241791>] kref_put+0x43/0x4d
 [<ffffffffa00474e8>] ttm_bo_release+0x6f/0x7c [ttm]
 [<ffffffffa0047479>] ? ttm_bo_release+0x0/0x7c [ttm]
 [<ffffffff81241791>] kref_put+0x43/0x4d
 [<ffffffffa0045d99>] ttm_bo_unref+0x38/0x45 [ttm]
 [<ffffffffa0076d0b>] radeon_bo_unref+0x2a/0x3f [radeon]
 [<ffffffffa0086ecf>] radeon_gem_object_free+0x33/0x35 [radeon]
 [<ffffffffa00129f9>] drm_gem_object_free_unlocked+0x5b/0x73 [drm]
 [<ffffffff8100f58f>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffffa001299e>] ? drm_gem_object_free_unlocked+0x0/0x73 [drm]
 [<ffffffff81241791>] kref_put+0x43/0x4d
 [<ffffffffa00128db>] drm_gem_object_handle_unreference_unlocked+0x35/0x39 [drm]
 [<ffffffffa0012b35>] drm_gem_close_ioctl+0x7c/0x87 [drm]
 [<ffffffffa0011666>] drm_ioctl+0x256/0x340 [drm]
 [<ffffffffa0012ab9>] ? drm_gem_close_ioctl+0x0/0x87 [drm]
 [<ffffffff8100f308>] ? xen_clocksource_read+0x21/0x23
 [<ffffffff8100f49e>] ? xen_sched_clock+0x14/0x8c
 [<ffffffff8113a2cd>] vfs_ioctl+0x22/0x87
 [<ffffffff8113a836>] do_vfs_ioctl+0x488/0x4ce
 [<ffffffff8113a8d2>] sys_ioctl+0x56/0x79
 [<ffffffff81012cb2>] system_call_fastpath+0x16/0x1b
---[ end trace 40a4caedde722a36 ]---
------------[ cut here ]------------

address=0x0000000071c7a000] [size=4096 bytes] == I think this is due to the patch: "ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under 4GB under Xen.".

Existing problems

xf86-video-fbdev (2.6.32.x)

July 28 2010: This fails under baremetal too.

Using xf86-video-fbdev as the driver in Xorg is a repeatable failure in most platforms. It mmaps the fb device during init - and I expected it to get to the ttm_fbdev_mmap code - but it does not (or instrumentation failed.

This suggests that in a shared mmapped area, some kind of reference-counting is happening, and driver->f_ops->mmap is not called, and the first mapper (the console driver, in this case) works because it accesses the area as a character device. Currently, fbdev_mmap seems to be dead code in working (non-xen) boots and (failing) xen-boots.

Note that domUs would mostly use the fbdev driver on top of the vfb for X.

This is what we get:

root@tst004 ~]# X -config ./xorg.conf.new 

This is a pre-release version of the X server from Fedora Project.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.

X.Org X Server 1.7.99.901 (1.8.0 RC 1)
Release Date: 2010-02-12
X Protocol Version 11, Revision 0
Build Operating System: x86-01 2.6.18-164.6.1.el5 
Current Operating System: Linux tst004.dumpdata.com 2.6.32.15-clean4 #28 SMP Wed Jun 16 03:11:15 EDT 2010 x86_64
Kernel command line: ro root=/dev/mapper/vg_tst004-lv_root rd_LVM_LV=vg_tst004/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us debug console=hvc0
Build Date: 23 February 2010  05:04:42AM
Build ID: xorg-x11-server 1.7.99.901-8.20100223.fc13 
Current version of pixman: 0.17.6
	Before reporting problems, check http://bodhi.fedoraproject.org/
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun 16 03:56:21 2010
(++) Using config file: "./xorg.conf.new"
(==) Using config directory: "/etc/xorg.conf.d"
(XEN) mm.c:1747:d0 Bad L1 flags 400000
(XEN) mm.c:1747:d0 Bad L1 flags 400000
(XEN) mm.c:1747:d0 Bad L1 flags 400000
...
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
------------[ cut here ]------------
WARNING: at arch/x86/mm/pat.c:872 track_pfn_vma_copy+0x55/0x8f()
Hardware name: G31M-ES2L
Modules linked in: nfs lockd fscache nfs_acl auth_rpcgss sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer ppdev snd parport_pc iTCO_wdt e1000 parport iTCO_vendor_support atl1c soundcore i2c_i801 pcspkr snd_page_alloc qla2xxx scsi_transport_fc scsi_tgt i915 drm_kms_helper drm i2c_algo_bit i2c_core video backlight output [last unloaded: microcode]
Pid: 1861, comm: X Tainted: G        W  2.6.32.15-clean4 #28
Call Trace:
 [<ffffffff81059db9>] warn_slowpath_common+0x7c/0x94
 [<ffffffff81059de5>] warn_slowpath_null+0x14/0x16
 [<ffffffff8103ac48>] track_pfn_vma_copy+0x55/0x8f
 [<ffffffff810fe5be>] copy_page_range+0x72/0x6ca
 [<ffffffff8100eded>] ? xen_force_evtchn_callback+0xd/0xf
 [<ffffffff8100f582>] ? check_events+0x12/0x20
 [<ffffffff8100eded>] ? xen_force_evtchn_callback+0xd/0xf
 [<ffffffff8100f582>] ? check_events+0x12/0x20
 [<ffffffff8100f56f>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff8108e10a>] ? lock_release+0x198/0x1a5
 [<ffffffff812438c8>] ? rb_insert_color+0xbc/0xe5
 [<ffffffff81057c88>] dup_mm+0x2e0/0x407
 [<ffffffff810589ed>] copy_process+0xbe9/0x13bf
 [<ffffffff81059336>] do_fork+0x173/0x355
 [<ffffffff8100f56f>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff8108e10a>] ? lock_release+0x198/0x1a5
 [<ffffffff8107dd13>] ? up_read+0x23/0x3c
 [<ffffffff81013735>] ? retint_swapgs+0x13/0x1b
 [<ffffffff81011489>] sys_clone+0x28/0x2a
 [<ffffffff81013053>] stub_clone+0x13/0x20
 [<ffffffff81012cb2>] ? system_call_fastpath+0x16/0x1b
---[ end trace 5a5d197966b56a31 ]---
(EE) XKB: Could not invoke xkbcomp
(EE) XKB: Couldn't compile keymap
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.

The interesting parts about Xorg.0.log file are:

[   194.553] 	ABI class: X.Org ANSI C Emulation, version 0.4
[   194.553] (==) Depth 24 pixmap format is 32 bpp
[   202.619] (==) FBDEV(0): Backing store disabled
[   202.620] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
[   202.625] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
[   202.629] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
..
[   203.612] (==) FBDEV(0): DPMS enabled
[   203.612] (==) RandR enabled
[   203.612] (II) Initializing built-in extension Generic Event Extension
[   203.612] (II) Initializing built-in extension SHAPE
[   203.612] (II) Initializing built-in extension MIT-SHM
[   203.612] (II) Initializing built-in extension XInputExtension
[   203.612] (II) Initializing built-in extension XTEST
[   203.612] (II) Initializing built-in extension BIG-REQUESTS
[   203.612] (II) Initializing built-in extension SYNC
[   203.612] (II) Initializing built-in extension XKEYBOARD
[   203.612] (II) Initializing built-in extension XC-MISC
[   203.613] (II) Initializing built-in extension XINERAMA
[   203.613] (II) Initializing built-in extension XFIXES
[   203.613] (II) Initializing built-in extension RENDER
[   203.613] (II) Initializing built-in extension RANDR
[   203.613] (II) Initializing built-in extension COMPOSITE
[   203.613] (II) Initializing built-in extension DAMAGE
[   203.617] (II) SELinux: Disabled by boolean
[   203.623] (II) AIGLX: Screen 0 is not DRI2 capable
[   203.623] (II) AIGLX: Screen 0 is not DRI capable
[   203.693] (II) AIGLX: Loaded and initialized /usr/lib64/dri/swrast_dri.so
[   203.693] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[   203.895] (EE) XKB: Could not invoke xkbcomp
[   203.899] (EE) XKB: Couldn't compile keymap
[   203.902] XKB: Failed to compile keymap
[   203.905] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
[   203.913] 
Fatal server error:
[   203.916] Failed to activate core devices.
[   203.919] 
Please consult the Fedora Project support 

Which looks as the screen is semi-initialized, but the keyboard failed.