* [Patch RFC] nouveau accelerated on Xen pv-ops kernel
@ 2010-03-10 13:21 Arvind R
[not found] ` <d799c4761003100521h663c82eepda85f3f0309828c2-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 39+ messages in thread
From: Arvind R @ 2010-03-10 13:21 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Cc: xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR
Hi,
Following is a simple patch that is needed in nouveau to get
accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's
2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is
almost the mainline merge), was substituted into the kernel-tree.
All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) used
of the same day.
Patch:
diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c
--- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27
10:19:28.000000000 +0530
+++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10
17:28:59.000000000 +0530
@@ -271,7 +271,10 @@
*/
vma->vm_private_data = bo;
- vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND;
+ vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND;
+ if (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT))
+ vma->vm_flags |= VM_IO;
+ vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags);
return 0;
out_unref:
ttm_bo_unref(&bo);
This patch is necessary because, in Xen, PFN of a page is virtualised.
So physical addresses
for DMA programming needs to use the MFN. Xen transparently does the
correct translation
using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, then Xen
assumes that the backing
memory is in the IOMEM space, and PFN equals MFN. If not set,
page_to_pfn() returns MFN.
The patch enables the ttm_bo_vm_fault() handler to behave correctly
under Xen, and has no
side-effects on normal (not under Xen) operations. The use of
TTM_PL_FLAG_TT in the
check assumes that all other placements are backed by device memory or
IO. If there are
any other placements that use system memory, that flag has to be OR'ed
into the check.
The above patch has no implications on a normal kernel or a Xen pv_ops
kernel booted without
the Xen hypervisor. My testing is on a debian-lenny environment on a
Core2 processor with
nVidia GeForce 9400 GT.
^ permalink raw reply [flat|nested] 39+ messages in thread[parent not found: <d799c4761003100521h663c82eepda85f3f0309828c2-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel [not found] ` <d799c4761003100521h663c82eepda85f3f0309828c2-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-03-11 11:02 ` Pekka Paalanen 2010-03-12 5:27 ` Arvind R 2010-03-12 12:45 ` Arvind R 0 siblings, 2 replies; 39+ messages in thread From: Pekka Paalanen @ 2010-03-11 11:02 UTC (permalink / raw) To: dri-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR I'm adding dri-devel@ to CC, since this suggested patch touches TTM code, and none of the Nouveau code. TTM patches go via dri-devel@. Thanks. On Wed, 10 Mar 2010 18:51:21 +0530 Arvind R <arvino55-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > Hi, > Following is a simple patch that is needed in nouveau to get > accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's > 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is > almost the mainline merge), was substituted into the kernel-tree. > All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) > used of the same day. > > Patch: > diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c > nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c > --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 > 10:19:28.000000000 +0530 > +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 > 17:28:59.000000000 +0530 > @@ -271,7 +271,10 @@ > */ > > vma->vm_private_data = bo; > - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | > VM_DONTEXPAND; > + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | > VM_DONTEXPAND; > + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & > TTM_PL_FLAG_TT)) > + vma->vm_flags |= VM_IO; > + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); > return 0; > out_unref: > ttm_bo_unref(&bo); > > This patch is necessary because, in Xen, PFN of a page is > virtualised. So physical addresses > for DMA programming needs to use the MFN. Xen transparently does > the correct translation > using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, > then Xen assumes that the backing > memory is in the IOMEM space, and PFN equals MFN. If not set, > page_to_pfn() returns MFN. > > The patch enables the ttm_bo_vm_fault() handler to behave > correctly under Xen, and has no > side-effects on normal (not under Xen) operations. The use of > TTM_PL_FLAG_TT in the > check assumes that all other placements are backed by device > memory or IO. If there are > any other placements that use system memory, that flag has to be > OR'ed into the check. > > The above patch has no implications on a normal kernel or a Xen > pv_ops kernel booted without > the Xen hypervisor. My testing is on a debian-lenny environment > on a Core2 processor with > nVidia GeForce 9400 GT. -- Pekka Paalanen http://www.iki.fi/pq/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-11 11:02 ` [Patch RFC] ttm: " Pekka Paalanen @ 2010-03-12 5:27 ` Arvind R 2010-03-28 10:20 ` Joanna Rutkowska 2010-03-12 12:45 ` Arvind R 1 sibling, 1 reply; 39+ messages in thread From: Arvind R @ 2010-03-12 5:27 UTC (permalink / raw) To: Pekka Paalanen; +Cc: xen-devel On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@iki.fi> wrote: > I'm adding dri-devel@ to CC, since this suggested patch touches > TTM code, and none of the Nouveau code. TTM patches go via > dri-devel@. > > Thanks. > > > On Wed, 10 Mar 2010 18:51:21 +0530 > Arvind R <arvino55@gmail.com> wrote: > >> Hi, >> Following is a simple patch that is needed in nouveau to get >> accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's >> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is >> almost the mainline merge), was substituted into the kernel-tree. >> All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) >> used of the same day. >> >> Patch: >> diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c >> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c >> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 >> 10:19:28.000000000 +0530 >> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 >> 17:28:59.000000000 +0530 >> @@ -271,7 +271,10 @@ >> */ >> >> vma->vm_private_data = bo; >> - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | >> VM_DONTEXPAND; >> + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | >> VM_DONTEXPAND; >> + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & >> TTM_PL_FLAG_TT)) >> + vma->vm_flags |= VM_IO; >> + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); >> return 0; >> out_unref: >> ttm_bo_unref(&bo); >> Sorry for the typo: in the last added line, vma_get_vm_prot(vma->vm_flags) should be vma->vm_get_page_prot(vma->vm_flags) Arvind ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-12 5:27 ` Arvind R @ 2010-03-28 10:20 ` Joanna Rutkowska 2010-03-30 5:50 ` Arvind R 0 siblings, 1 reply; 39+ messages in thread From: Joanna Rutkowska @ 2010-03-28 10:20 UTC (permalink / raw) To: Arvind R; +Cc: xen-devel, Pekka Paalanen [-- Attachment #1.1: Type: text/plain, Size: 4174 bytes --] On 03/12/2010 06:27 AM, Arvind R wrote: > On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@iki.fi> wrote: >> I'm adding dri-devel@ to CC, since this suggested patch touches TTM >> code, and none of the Nouveau code. TTM patches go via dri-devel@. >> >> Thanks. >> >> >> On Wed, 10 Mar 2010 18:51:21 +0530 Arvind R <arvino55@gmail.com> >> wrote: >> >>> Hi, Following is a simple patch that is needed in nouveau to get >>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is >>> jeremy's 2.6.31.6 as of 20100222. The whole gpu tree of nouveau >>> (which is almost the mainline merge), was substituted into the >>> kernel-tree. All components of X (mesa, Xorg-server-7.5, >>> xf86-nouveau, libdrm) used of the same day. >>> >>> Patch: diff -Naur >>> nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c >>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c --- >>> nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 >>> 10:19:28.000000000 +0530 +++ >>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 >>> 17:28:59.000000000 +0530 @@ -271,7 +271,10 @@ */ >>> >>> vma->vm_private_data = bo; - vma->vm_flags |= VM_RESERVED | >>> VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; + vma->vm_flags |= >>> VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; + if >>> (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT)) + >>> vma->vm_flags |= VM_IO; + vma->vm_page_prot = >>> vma_get_vm_prot(vma->vm_flags); return 0; out_unref: >>> ttm_bo_unref(&bo); >>> > Sorry for the typo: in the last added line, > vma_get_vm_prot(vma->vm_flags) should be > vma->vm_get_page_prot(vma->vm_flags) > Arvind, I've just tried your patch (with the above correction applied). I tried it against the latest pvops0 kernel from xen/stable-2.6.32.x with back-ported nouveau code. Xen 3.4.3-rc4 hypervisor. The actual kernel is based on Fedora 2.6.32.10.x kernel SRPM, more specifically on the Michael Young's SRPM (that integrates pvops patches): http://fedorapeople.org/~myoung/dom0/src/kernel-2.6.32.10-1.2.92.xendom0.fc12.src.rpm With your patch I can get my nouveau X driver now working *without* NoAccel or ShadowFB settings in the xorg.conf, which was not possible before. I have enabled desktop composition using XRender in KDE (that runs in Dom0), but I see a very high "latency" in how e.g. Windows react to me wanting to move them on screen, or before the KDE's "Strat" menu appears, or when I activate the "Expose effect" (Ctrl-F8), etc. It looks like if the composition buffers were still kept in host memory and transferred to the video memory only when I want to do something with an object (e.g. move the window). So, e.g. after this delay at the beginning (e.g. after pressing Ctrl-F8) I can get smooth graphics effects (e.g. Expose effect), but this initial delay, that manifests itself before pretty much any action I take, makes the system practically unusable... I'm using the latest KDE 4.4. I've been wondering if you, or any other of xen-devel readers, have: 1) Tried the patch with some composting X Window manager in Dom0? 2) Got similar results? FWIW, when I enable ShadowFB in xorg.conf the effect no longer occurs. But ShadowFB disables H/W acceleration, so even though I can get rid of the "latency", I'm not getting smooth visual effects anymore (no smooth Expose effect :( Thanks, joanna. BTW, this is the patch I used for the recent pvops0 xen/stable-2.6.32.x: diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 3dc8d6b..0f57125 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -271,7 +271,9 @@ int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma, */ vma->vm_private_data = bo; - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT)) + vma->vm_flags |= VM_IO; vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); return 0; out_unref: [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 226 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply related [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-28 10:20 ` Joanna Rutkowska @ 2010-03-30 5:50 ` Arvind R 0 siblings, 0 replies; 39+ messages in thread From: Arvind R @ 2010-03-30 5:50 UTC (permalink / raw) To: Joanna Rutkowska; +Cc: xen-devel, Pekka Paalanen On Sun, Mar 28, 2010 at 3:50 PM, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote: > On 03/12/2010 06:27 AM, Arvind R wrote: >> On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@iki.fi> wrote: >>> I'm adding dri-devel@ to CC, since this suggested patch touches TTM >>> code, and none of the Nouveau code. TTM patches go via dri-devel@. >>> >>> Thanks. >>> >>> >>> On Wed, 10 Mar 2010 18:51:21 +0530 Arvind R <arvino55@gmail.com> >>> wrote: >>> >>>> Hi, Following is a simple patch that is needed in nouveau to get >>>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is >>>> jeremy's 2.6.31.6 as of 20100222. The whole gpu tree of nouveau >>>> (which is almost the mainline merge), was substituted into the >>>> kernel-tree. All components of X (mesa, Xorg-server-7.5, >>>> xf86-nouveau, libdrm) used of the same day. >>>> >>>> Patch: diff -Naur >>>> nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c >>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c --- >>>> nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 >>>> 10:19:28.000000000 +0530 +++ >>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 >>>> 17:28:59.000000000 +0530 @@ -271,7 +271,10 @@ */ >>>> >>>> vma->vm_private_data = bo; - vma->vm_flags |= VM_RESERVED | >>>> VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; + vma->vm_flags |= >>>> VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; + if >>>> (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT)) + >>>> vma->vm_flags |= VM_IO; + vma->vm_page_prot = >>>> vma_get_vm_prot(vma->vm_flags); return 0; out_unref: >>>> ttm_bo_unref(&bo); >>>> >> Sorry for the typo: in the last added line, >> vma_get_vm_prot(vma->vm_flags) should be >> vma->vm_get_page_prot(vma->vm_flags) >> > Arvind, > > I've just tried your patch (with the above correction applied). I tried > it against the latest pvops0 kernel from xen/stable-2.6.32.x with > back-ported nouveau code. Xen 3.4.3-rc4 hypervisor. The actual kernel is > based on Fedora 2.6.32.10.x kernel SRPM, more specifically on the > Michael Young's SRPM (that integrates pvops patches): > > http://fedorapeople.org/~myoung/dom0/src/kernel-2.6.32.10-1.2.92.xendom0.fc12.src.rpm > > With your patch I can get my nouveau X driver now working *without* > NoAccel or ShadowFB settings in the xorg.conf, which was not possible > before. > > I have enabled desktop composition using XRender in KDE (that runs in > Dom0), but I see a very high "latency" in how e.g. Windows react to me > wanting to move them on screen, or before the KDE's "Strat" menu > appears, or when I activate the "Expose effect" (Ctrl-F8), etc. It looks > like if the composition buffers were still kept in host memory and > transferred to the video memory only when I want to do something with an > object (e.g. move the window). So, e.g. after this delay at the > beginning (e.g. after pressing Ctrl-F8) I can get smooth graphics > effects (e.g. Expose effect), but this initial delay, that manifests > itself before pretty much any action I take, makes the system > practically unusable... I'm using the latest KDE 4.4. > > I've been wondering if you, or any other of xen-devel readers, have: > 1) Tried the patch with some composting X Window manager in Dom0? using ecomp (compiz port for enlightenment) on e17-git. Enabled composite. Works with software-engine but not with xrender-engine. > 2) Got similar results? Works fine - no latencies I can notice - though I've tried only the default effects settings The sluggish/jerky keyboard/mouse in domU (SDL) consoles have also vanished with accel-enabled X. Keypress-repeat does not work in domU. > FWIW, when I enable ShadowFB in xorg.conf the effect no longer occurs. > But ShadowFB disables H/W acceleration, so even though I can get rid of > the "latency", I'm not getting smooth visual effects anymore (no smooth > Expose effect :( > > Thanks, > joanna. > > BTW, this is the patch I used for the recent pvops0 xen/stable-2.6.32.x: > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c > b/drivers/gpu/drm/ttm/ttm_bo_vm.c > index 3dc8d6b..0f57125 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c > @@ -271,7 +271,9 @@ int ttm_bo_mmap(struct file *filp, struct > vm_area_struct *vma, > */ > > vma->vm_private_data = bo; > - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; > + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; > + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT)) > + vma->vm_flags |= VM_IO; > vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); > return 0; > out_unref: > > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-11 11:02 ` [Patch RFC] ttm: " Pekka Paalanen 2010-03-12 5:27 ` Arvind R @ 2010-03-12 12:45 ` Arvind R 2010-03-12 13:20 ` Michael D Labriola ` (2 more replies) 1 sibling, 3 replies; 39+ messages in thread From: Arvind R @ 2010-03-12 12:45 UTC (permalink / raw) To: dri-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq-X3B1VOXEql0@public.gmane.org> wrote: > I'm adding dri-devel@ to CC, since this suggested patch touches > TTM code, and none of the Nouveau code. TTM patches go via > dri-devel@. > > Thanks. > > > On Wed, 10 Mar 2010 18:51:21 +0530 > Arvind R <arvino55-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> Hi, >> Following is a simple patch that is needed in nouveau to get >> accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's >> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is >> almost the mainline merge), was substituted into the kernel-tree. >> All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) >> used of the same day. >> >> Patch: >> diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c >> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c >> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 >> 10:19:28.000000000 +0530 >> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 >> 17:28:59.000000000 +0530 >> @@ -271,7 +271,10 @@ >> */ >> >> vma->vm_private_data = bo; >> - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | >> VM_DONTEXPAND; >> + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | >> VM_DONTEXPAND; >> + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & >> TTM_PL_FLAG_TT)) >> + vma->vm_flags |= VM_IO; >> + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); >> return 0; >> out_unref: >> ttm_bo_unref(&bo); >> sorry for the typo and other procedural errors. the last added line should be + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags) >> This patch is necessary because, in Xen, PFN of a page is >> virtualised. So physical addresses >> for DMA programming needs to use the MFN. Xen transparently does >> the correct translation >> using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, >> then Xen assumes that the backing >> memory is in the IOMEM space, and PFN equals MFN. If not set, >> page_to_pfn() returns MFN. >> >> The patch enables the ttm_bo_vm_fault() handler to behave >> correctly under Xen, and has no >> side-effects on normal (not under Xen) operations. The use of >> TTM_PL_FLAG_TT in the >> check assumes that all other placements are backed by device >> memory or IO. If there are >> any other placements that use system memory, that flag has to be >> OR'ed into the check. >> >> The above patch has no implications on a normal kernel or a Xen >> pv_ops kernel booted without >> the Xen hypervisor. My testing is on a debian-lenny environment >> on a Core2 processor with >> nVidia GeForce 9400 GT. > Efficacy of patch: successful flightgear run on dom0 AND bareboot! Arvind R. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-12 12:45 ` Arvind R @ 2010-03-12 13:20 ` Michael D Labriola 2010-03-13 22:03 ` Joanna Rutkowska [not found] ` <d799c4761003120445h57ab1373m31eb0add242ef74c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2 siblings, 0 replies; 39+ messages in thread From: Michael D Labriola @ 2010-03-12 13:20 UTC (permalink / raw) To: Arvind R; +Cc: nouveau, dri-devel, xen-devel, xen-devel-bounces xen-devel-bounces@lists.xensource.com wrote on 03/12/2010 07:45:57 AM: > On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@iki.fi> wrote: *snip* > Efficacy of patch: > successful flightgear run on dom0 AND bareboot! > > Arvind R. > If you boot your system up w/out a monitor plugged in, then plug one in, do you ever get signal? I've been playing with nouveau (just bare-metal up until now!) for a few weeks as well, and my biggest problem with it is that if you have a bunch of PCs on a cheap KVM, they all have to have the monitor/keyboard/mouse at boot or you never get any TTY or X logins... Maybe I'm just doing something wrong? -Mike --- Michael D Labriola Electric Boat mlabriol@gdeb.com 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-12 12:45 ` Arvind R 2010-03-12 13:20 ` Michael D Labriola @ 2010-03-13 22:03 ` Joanna Rutkowska 2010-03-15 14:44 ` Michael D Labriola [not found] ` <d799c4761003120445h57ab1373m31eb0add242ef74c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2 siblings, 1 reply; 39+ messages in thread From: Joanna Rutkowska @ 2010-03-13 22:03 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Arvind R, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 2999 bytes --] On 03/12/2010 01:45 PM, Arvind R wrote: > On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@iki.fi> wrote: >> I'm adding dri-devel@ to CC, since this suggested patch touches >> TTM code, and none of the Nouveau code. TTM patches go via >> dri-devel@. >> >> Thanks. >> >> >> On Wed, 10 Mar 2010 18:51:21 +0530 >> Arvind R <arvino55@gmail.com> wrote: >> >>> Hi, >>> Following is a simple patch that is needed in nouveau to get >>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's >>> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is >>> almost the mainline merge), was substituted into the kernel-tree. >>> All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) >>> used of the same day. >>> >>> Patch: >>> diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c >>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c >>> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 >>> 10:19:28.000000000 +0530 >>> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 >>> 17:28:59.000000000 +0530 >>> @@ -271,7 +271,10 @@ >>> */ >>> >>> vma->vm_private_data = bo; >>> - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | >>> VM_DONTEXPAND; >>> + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | >>> VM_DONTEXPAND; >>> + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & >>> TTM_PL_FLAG_TT)) >>> + vma->vm_flags |= VM_IO; >>> + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); >>> return 0; >>> out_unref: >>> ttm_bo_unref(&bo); >>> > sorry for the typo and other procedural errors. > the last added line should be > + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags) > >>> This patch is necessary because, in Xen, PFN of a page is >>> virtualised. So physical addresses >>> for DMA programming needs to use the MFN. Xen transparently does >>> the correct translation >>> using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, >>> then Xen assumes that the backing >>> memory is in the IOMEM space, and PFN equals MFN. If not set, >>> page_to_pfn() returns MFN. >>> >>> The patch enables the ttm_bo_vm_fault() handler to behave >>> correctly under Xen, and has no >>> side-effects on normal (not under Xen) operations. The use of >>> TTM_PL_FLAG_TT in the >>> check assumes that all other placements are backed by device >>> memory or IO. If there are >>> any other placements that use system memory, that flag has to be >>> OR'ed into the check. >>> >>> The above patch has no implications on a normal kernel or a Xen >>> pv_ops kernel booted without >>> the Xen hypervisor. My testing is on a debian-lenny environment >>> on a Core2 processor with >>> nVidia GeForce 9400 GT. >> > Efficacy of patch: > successful flightgear run on dom0 AND bareboot! > Jeremy, will you be merging this patch into any of the xen/stable-* branches any time soon? Thanks, joanna. [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 226 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-13 22:03 ` Joanna Rutkowska @ 2010-03-15 14:44 ` Michael D Labriola 2010-03-15 23:13 ` Jeremy Fitzhardinge ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Michael D Labriola @ 2010-03-15 14:44 UTC (permalink / raw) To: Joanna Rutkowska Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Konrad Rzeszutek Wilk, xen-devel-bounces xen-devel-bounces@lists.xensource.com wrote on 03/13/2010 05:03:22 PM: > On 03/12/2010 01:45 PM, Arvind R wrote: > > On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@iki.fi> wrote: > >> I'm adding dri-devel@ to CC, since this suggested patch touches > >> TTM code, and none of the Nouveau code. TTM patches go via > >> dri-devel@. > >> > >> Thanks. > >> > >> > >> On Wed, 10 Mar 2010 18:51:21 +0530 > >> Arvind R <arvino55@gmail.com> wrote: > >> > >>> Hi, > >>> Following is a simple patch that is needed in nouveau to get > >>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's > >>> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is > >>> almost the mainline merge), was substituted into the kernel-tree. > >>> All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) > >>> used of the same day. > >>> > >>> Patch: > >>> diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c > >>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c > >>> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 > >>> 10:19:28.000000000 +0530 > >>> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 > >>> 17:28:59.000000000 +0530 > >>> @@ -271,7 +271,10 @@ > >>> */ > >>> > >>> vma->vm_private_data = bo; > >>> - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | > >>> VM_DONTEXPAND; > >>> + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | > >>> VM_DONTEXPAND; > >>> + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & > >>> TTM_PL_FLAG_TT)) > >>> + vma->vm_flags |= VM_IO; > >>> + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); > >>> return 0; > >>> out_unref: > >>> ttm_bo_unref(&bo); > >>> > > sorry for the typo and other procedural errors. > > the last added line should be > > + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags) > > > >>> This patch is necessary because, in Xen, PFN of a page is > >>> virtualised. So physical addresses > >>> for DMA programming needs to use the MFN. Xen transparently does > >>> the correct translation > >>> using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, > >>> then Xen assumes that the backing > >>> memory is in the IOMEM space, and PFN equals MFN. If not set, > >>> page_to_pfn() returns MFN. > >>> > >>> The patch enables the ttm_bo_vm_fault() handler to behave > >>> correctly under Xen, and has no > >>> side-effects on normal (not under Xen) operations. The use of > >>> TTM_PL_FLAG_TT in the > >>> check assumes that all other placements are backed by device > >>> memory or IO. If there are > >>> any other placements that use system memory, that flag has to be > >>> OR'ed into the check. > >>> > >>> The above patch has no implications on a normal kernel or a Xen > >>> pv_ops kernel booted without > >>> the Xen hypervisor. My testing is on a debian-lenny environment > >>> on a Core2 processor with > >>> nVidia GeForce 9400 GT. > >> > > Efficacy of patch: > > successful flightgear run on dom0 AND bareboot! > > > Jeremy, will you be merging this patch into any of the xen/stable-* > branches any time soon? > > Thanks, > joanna. 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 ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore i82860_edac snd_page_alloc pata_acpi edac_core parport_pc floppy parport dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod [ 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 Any ideas? -Mike --- Michael D Labriola Electric Boat mlabriol@gdeb.com 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-15 14:44 ` Michael D Labriola @ 2010-03-15 23:13 ` Jeremy Fitzhardinge 2010-03-16 7:18 ` Arvind R 2010-03-16 16:40 ` Michael D Labriola 2010-03-25 7:18 ` Jeremy Fitzhardinge 2010-06-09 17:43 ` Konrad Rzeszutek Wilk 2 siblings, 2 replies; 39+ messages in thread From: Jeremy Fitzhardinge @ 2010-03-15 23:13 UTC (permalink / raw) To: Michael D Labriola Cc: Arvind R, Konrad Rzeszutek Wilk, xen-devel, Joanna Rutkowska, xen-devel-bounces On 03/15/2010 07:44 AM, Michael D Labriola wrote: > 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 > ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss > snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device > snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer > ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore i82860_edac > snd_page_alloc pata_acpi edac_core parport_pc floppy parport dm_snapshot > dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd > aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod > [ 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 > > Any ideas? > Well, this is generally the symptom that someone is confusing mfns and pfns, and therefore ends up incorrectly setting the _PAGE_IO flag in some pte. If you run it under strace, can you identify which mapping the fault is happening in? J ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-15 23:13 ` Jeremy Fitzhardinge @ 2010-03-16 7:18 ` Arvind R 2010-03-16 16:48 ` Michael D Labriola 2010-03-16 16:40 ` Michael D Labriola 1 sibling, 1 reply; 39+ messages in thread From: Arvind R @ 2010-03-16 7:18 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: Konrad Rzeszutek Wilk, xen-devel, Michael D Labriola, Joanna Rutkowska, xen-devel-bounces On Tue, Mar 16, 2010 at 4:43 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > On 03/15/2010 07:44 AM, Michael D Labriola wrote: >> >> 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 >> ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss >> snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device >> snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer >> ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore i82860_edac >> snd_page_alloc pata_acpi edac_core parport_pc floppy parport dm_snapshot >> dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd >> aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod >> [ 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 >> >> Any ideas? >> > > Well, this is generally the symptom that someone is confusing mfns and pfns, > and therefore ends up incorrectly setting the _PAGE_IO flag in some pte. If > you run it under strace, can you identify which mapping the fault is > happening in? > > J > Just wanted to emphasise that not updating vma->vm_page_prot after updating the flags correctly failed to provide the solution. Maybe forcing this update in all places will show up new failures. Also, maybe the final solution needs to 'or' TTM_PL_SYSTEM also into the conditional. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-16 7:18 ` Arvind R @ 2010-03-16 16:48 ` Michael D Labriola 0 siblings, 0 replies; 39+ messages in thread From: Michael D Labriola @ 2010-03-16 16:48 UTC (permalink / raw) To: Arvind R Cc: xen-devel-bounces, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Konrad Rzeszutek Wilk xen-devel-bounces@lists.xensource.com wrote on 03/16/2010 03:18:01 AM: > On Tue, Mar 16, 2010 at 4:43 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > On 03/15/2010 07:44 AM, Michael D Labriola wrote: > >> > >> 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 > >> ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss > >> snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device > >> snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer > >> ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore i82860_edac > >> snd_page_alloc pata_acpi edac_core parport_pc floppy parport dm_snapshot > >> dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd > >> aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod > >> [ 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 > >> > >> Any ideas? > >> > > > > Well, this is generally the symptom that someone is confusing mfnsand pfns, > > and therefore ends up incorrectly setting the _PAGE_IO flag in some pte. If > > you run it under strace, can you identify which mapping the fault is > > happening in? > > > > J > > > Just wanted to emphasise that not updating vma->vm_page_prot after updating > the flags correctly failed to provide the solution. Maybe forcing > this update in > all places will show up new failures. I'm not sure I follow, as I've gotten in a little over my head here. > Also, maybe the final solution needs to 'or' TTM_PL_SYSTEM also into > the conditional. I'll kick off a compile with TTM_PL_SYSTEM orred into the conditional and see which of my boxes are functional afterwards. -Mike --- Michael D Labriola Electric Boat mlabriol@gdeb.com 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-15 23:13 ` Jeremy Fitzhardinge 2010-03-16 7:18 ` Arvind R @ 2010-03-16 16:40 ` Michael D Labriola 2010-03-16 17:21 ` Konrad Rzeszutek Wilk 1 sibling, 1 reply; 39+ messages in thread From: Michael D Labriola @ 2010-03-16 16:40 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: Arvind R, xen-devel-bounces, xen-devel, Joanna Rutkowska, Konrad Rzeszutek Wilk [-- Attachment #1: Type: text/plain, Size: 3079 bytes --] xen-devel-bounces@lists.xensource.com wrote on 03/15/2010 07:13:20 PM: > On 03/15/2010 07:44 AM, Michael D Labriola wrote: > > 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 > > ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss > > snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device > > snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer > > ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore i82860_edac > > snd_page_alloc pata_acpi edac_core parport_pc floppy parport dm_snapshot > > dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd > > aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod > > [ 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 > > > > Any ideas? > > > > Well, this is generally the symptom that someone is confusing mfns and > pfns, and therefore ends up incorrectly setting the _PAGE_IO flag in > some pte. If you run it under strace, can you identify which mapping > the fault is happening in? I've attached the output of 'strace -o strace-Xorg Xorg'. Figuring out which mapping the fault is happening in is a little over my head, I'm afraid. If you need different arguments to strace, let me know and I'll do it again. Thanks! -Mike --- Michael D Labriola Electric Boat mlabriol@gdeb.com 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) [-- Attachment #2: strace-Xorg --] [-- Type: application/octet-stream, Size: 130101 bytes --] execve("/usr/local/bin/Xorg", ["Xorg"], [/* 28 vars */]) = 0 brk(0) = 0x92df000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40001000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=50556, ...}) = 0 mmap2(NULL, 50556, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40002000 close(3) = 0 open("/usr/local/lib/libpciaccess.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\32\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=96848, ...}) = 0 mmap2(NULL, 31856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4000f000 mmap2(0x40016000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0x40016000 close(3) = 0 open("/usr/local/lib/libXfont.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0]\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=584163, ...}) = 0 mmap2(NULL, 214784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40017000 mmap2(0x4004a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x33) = 0x4004a000 close(3) = 0 open("/usr/local/lib/libfreetype.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300o\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=589411, ...}) = 0 mmap2(NULL, 543000, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4004c000 mmap2(0x400cd000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x80) = 0x400cd000 close(3) = 0 open("/usr/local/lib/libfontenc.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\f\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=41147, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x400d1000 mmap2(NULL, 20192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x400d2000 mmap2(0x400d6000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4) = 0x400d6000 close(3) = 0 open("/usr/lib/libz.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\3471L"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=75632, ...}) = 0 mmap2(0x4c31d000, 77008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4c31d000 mmap2(0x4c32f000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11) = 0x4c32f000 close(3) = 0 open("/usr/local/lib/libXau.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\t\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=26273, ...}) = 0 mmap2(NULL, 10396, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x400d7000 mmap2(0x400d9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x400d9000 close(3) = 0 open("/usr/local/lib/libpixman-1.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 B\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=909843, ...}) = 0 mmap2(NULL, 431876, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x400da000 mmap2(0x40142000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x68) = 0x40142000 close(3) = 0 open("/usr/local/lib/libhal.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\'\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=69617, ...}) = 0 mmap2(NULL, 63076, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40144000 mmap2(0x40153000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe) = 0x40153000 close(3) = 0 open("/usr/local/lib/libdbus-1.so.3", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320O\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=285106, ...}) = 0 mmap2(NULL, 235436, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40154000 mmap2(0x4018c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x37) = 0x4018c000 close(3) = 0 open("/usr/local/lib/libXdmcp.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\r\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=53692, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4018e000 mmap2(NULL, 19624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4018f000 mmap2(0x40193000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0x40193000 close(3) = 0 open("/usr/local/lib/libssl.so.0.9.8", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\263\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0555, st_size=288866, ...}) = 0 mmap2(NULL, 258864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40194000 mmap2(0x401d0000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3b) = 0x401d0000 close(3) = 0 open("/usr/local/lib/libcrypto.so.0.9.8", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0c\3\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0555, st_size=1466863, ...}) = 0 mmap2(NULL, 1289528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x401d4000 mmap2(0x402f7000, 86016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x123) = 0x402f7000 mmap2(0x4030c000, 11576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4030c000 mprotect(0xbfd2a000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0 close(3) = 0 open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\374\""..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=16436, ...}) = 0 mmap2(0x4c22f000, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4c22f000 mmap2(0x4c231000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x4c231000 close(3) = 0 open("/lib/libm.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\223)L"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=199788, ...}) = 0 mmap2(0x4c296000, 147568, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4c296000 mmap2(0x4c2b9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22) = 0x4c2b9000 close(3) = 0 open("/lib/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\254"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=43932, ...}) = 0 mmap2(0x4c2e9000, 29260, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4c2e9000 mmap2(0x4c2ef000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0x4c2ef000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\n\366\20"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1532528, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4030f000 mmap2(0x4c0fa000, 1254812, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4c0fa000 mmap2(0x4c227000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12d) = 0x4c227000 mmap2(0x4c22a000, 9628, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4c22a000 close(3) = 0 open("/lib/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\32"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=112148, ...}) = 0 mmap2(0x4c2bd000, 78268, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4c2bd000 mmap2(0x4c2cd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0x4c2cd000 mmap2(0x4c2cf000, 4540, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4c2cf000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40310000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40311000 set_thread_area({entry_number:-1 -> 6, base_addr:0x40310b50, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0x4c2cd000, 4096, PROT_READ) = 0 mprotect(0x4c227000, 8192, PROT_READ) = 0 mprotect(0x4c2ef000, 4096, PROT_READ) = 0 mprotect(0x4c2b9000, 4096, PROT_READ) = 0 mprotect(0x4c231000, 4096, PROT_READ) = 0 mprotect(0x4018c000, 4096, PROT_READ) = 0 mprotect(0x4c0f6000, 4096, PROT_READ) = 0 munmap(0x40002000, 50556) = 0 set_tid_address(0x40310b98) = 3748 set_robust_list(0x40310ba0, 0xc) = 0 rt_sigaction(SIGRTMIN, {0x4c2c166b, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x4c2c15a0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbfd2a1a0, 35, (nil), 0}) = 0 geteuid32() = 0 getuid32() = 0 geteuid32() = 0 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 brk(0) = 0x92df000 brk(0x9300000) = 0x9300000 rt_sigaction(SIGSEGV, {0x80ade10, [], SA_SIGINFO}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, {0x80ade10, [], SA_SIGINFO}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGILL, {0x80ade10, [], SA_SIGINFO}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGFPE, {0x80ade10, [], SA_SIGINFO}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGBUS, {0x80ade10, [], SA_SIGINFO}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGSYS, {0x80ade10, [], SA_SIGINFO}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGXCPU, {0x80ade10, [], SA_SIGINFO}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGXFSZ, {0x80ade10, [], SA_SIGINFO}, {SIG_DFL}, 8) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=50556, ...}) = 0 mmap2(NULL, 50556, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40002000 close(3) = 0 open("/usr/local/lib/libgcc_s.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\23"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=165062, ...}) = 0 mmap2(NULL, 33672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40312000 mmap2(0x4031a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7) = 0x4031a000 close(3) = 0 munmap(0x40002000, 50556) = 0 futex(0x4c22ba14, FUTEX_WAKE, 2147483647) = 0 futex(0x4031a34c, FUTEX_WAKE, 2147483647) = 0 close(0) = 0 close(1) = 0 write(2, "", 0) = 0 getpgrp() = 3747 open("/tmp/.tX0-lock", O_WRONLY|O_CREAT|O_EXCL, 0644) = 0 write(0, " 3748\n", 11) = 11 chmod("/tmp/.tX0-lock", 0444) = 0 close(0) = 0 link("/tmp/.tX0-lock", "/tmp/.X0-lock") = 0 unlink("/tmp/.tX0-lock") = 0 rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0 umask(022) = 022 stat64("/usr/local/var/log/Xorg.0.log", {st_mode=S_IFREG|0644, st_size=12164, ...}) = 0 rename("/usr/local/var/log/Xorg.0.log", "/usr/local/var/log/Xorg.0.log.old") = 0 open("/usr/local/var/log/Xorg.0.log", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 0 rt_sigaction(SIGALRM, {0x80b0330, [ALRM], 0}, NULL, 8) = 0 clock_gettime(CLOCK_MONOTONIC, {237, 260627439}) = 0 uname({sys="Linux", node="smaug", ...}) = 0 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 1 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 setsockopt(1, SOL_TCP, TCP_NODELAY, [1], 4) = 0 setsockopt(1, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(1, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0 bind(1, {sa_family=AF_INET6, sin6_port=htons(6000), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 setsockopt(1, SOL_SOCKET, SO_LINGER, {onoff=0, linger=0}, 8) = 0 listen(1, 128) = 0 getsockname(1, {sa_family=AF_INET6, sin6_port=htons(6000), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 uname({sys="Linux", node="smaug", ...}) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(6000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 setsockopt(3, SOL_SOCKET, SO_LINGER, {onoff=0, linger=0}, 8) = 0 listen(3, 128) = 0 getsockname(3, {sa_family=AF_INET, sin_port=htons(6000), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0 uname({sys="Linux", node="smaug", ...}) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 4 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 umask(0) = 022 bind(4, {sa_family=AF_FILE, path=@/tmp/.X11-unix/X0}, 20) = 0 listen(4, 128) = 0 umask(022) = 0 uname({sys="Linux", node="smaug", ...}) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 5 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 umask(0) = 022 lstat64("/tmp/.X11-unix", 0xbfd29ea0) = -1 ENOENT (No such file or directory) geteuid32() = 0 mkdir("/tmp/.X11-unix", 01777) = 0 chmod("/tmp/.X11-unix", 01777) = 0 unlink("/tmp/.X11-unix/X0") = -1 ENOENT (No such file or directory) bind(5, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 19) = 0 listen(5, 128) = 0 umask(022) = 0 socket(PF_NETLINK, SOCK_RAW, 0) = 6 bind(6, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(6, {sa_family=AF_NETLINK, pid=3748, groups=00000000}, [12]) = 0 time(NULL) = 1268757079 sendto(6, "\24\0\0\0\22\0\1\3W\262\237K\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\354\0\0\0\20\0\2\0W\262\237K\244\16\0\0\0\0\4\3\1\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 960 recvmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0W\262\237K\244\16\0\0\0\0\0\0\1\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 sendto(6, "\24\0\0\0\26\0\1\3X\262\237K\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\0\0\0\24\0\2\0X\262\237K\244\16\0\0\2\10\200\376\1\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 108 recvmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0X\262\237K\244\16\0\0\n\200\200\376\1\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 192 recvmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0X\262\237K\244\16\0\0\0\0\0\0\1\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 close(6) = 0 socket(PF_NETLINK, SOCK_RAW, 0) = 6 bind(6, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(6, {sa_family=AF_NETLINK, pid=3748, groups=00000000}, [12]) = 0 time(NULL) = 1268757079 sendto(6, "\24\0\0\0\22\0\1\3W\262\237K\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\354\0\0\0\20\0\2\0W\262\237K\244\16\0\0\0\0\4\3\1\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 960 recvmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0W\262\237K\244\16\0\0\0\0\0\0\1\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 sendto(6, "\24\0\0\0\26\0\1\3X\262\237K\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\0\0\0\24\0\2\0X\262\237K\244\16\0\0\2\10\200\376\1\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 108 recvmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0X\262\237K\244\16\0\0\n\200\200\376\1\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 192 recvmsg(6, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0X\262\237K\244\16\0\0\0\0\0\0\1\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 close(6) = 0 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGHUP, {0x80ae870, [HUP], 0}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, {0x80ae8c0, [INT], 0}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x80ae8c0, [TERM], 0}, {SIG_DFL}, 8) = 0 open("/etc/X0.hosts", O_RDONLY) = -1 ENOENT (No such file or directory) rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGUSR1, {SIG_DFL}, {SIG_IGN}, 8) = 0 getppid() = 3747 clock_gettime(CLOCK_MONOTONIC, {237, 318235173}) = 0 open("/usr/local/lib/xorg/protocol.txt", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0644, st_size=31246, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40002000 _llseek(6, 0, [0], SEEK_SET) = 0 read(6, "# Registry of protocol names use"..., 4096) = 4096 read(6, "reateContext\nR004 GLX:DestroyCon"..., 4096) = 4096 read(6, "ANDR:GetCrtcGammaSize\nR023 RANDR"..., 4096) = 4096 read(6, "X11:ChangeWindowAttributes\nR003 "..., 4096) = 4096 read(6, "etDefinedIndices\nR010 X3D-PEX:Ge"..., 4096) = 4096 read(6, "e\nR024 XFIXES:GetCursorName\nR025"..., 4096) = 4096 read(6, "teImmediate\nR017 XIE:CreatePhoto"..., 4096) = 4096 read(6, "ARD:SetNamedIndicator\nR017 XKEYB"..., 4096) = 2574 read(6, "", 4096) = 0 write(2, "\nX.Org X Server 1.7.5", 21) = 21 write(0, "\nX.Org X Server 1.7.5", 21) = 21 write(2, "\nRelease Date: 2010-02-16\n", 26) = 26 write(0, "\nRelease Date: 2010-02-16\n", 26) = 26 write(2, "X Protocol Version 11, Revision "..., 34) = 34 write(0, "X Protocol Version 11, Revision "..., 34) = 34 write(2, "Build Operating System: Linux 2."..., 50) = 50 write(0, "Build Operating System: Linux 2."..., 50) = 50 uname({sys="Linux", node="smaug", ...}) = 0 write(2, "Current Operating System: Linux "..., 93) = 93 write(0, "Current Operating System: Linux "..., 93) = 93 open("/proc/cmdline", O_RDONLY) = 7 write(2, "Kernel command line: ", 21) = 21 write(0, "Kernel command line: ", 21) = 21 read(7, "ro root=/dev/VolGroup00/LogVol00"..., 80) = 41 write(2, "ro root=/dev/VolGroup00/LogVol00"..., 41) = 41 write(0, "ro root=/dev/VolGroup00/LogVol00"..., 41) = 41 read(7, "", 80) = 0 close(7) = 0 open("/etc/localtime", O_RDONLY) = 7 fstat64(7, {st_mode=S_IFREG|0644, st_size=56, ...}) = 0 fstat64(7, {st_mode=S_IFREG|0644, st_size=56, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40003000 read(7, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0"..., 4096) = 56 close(7) = 0 munmap(0x40003000, 4096) = 0 write(2, "Build Date: 16 March 2010 02:12"..., 38) = 38 write(0, "Build Date: 16 March 2010 02:12"..., 38) = 38 write(2, " \n", 2) = 2 write(0, " \n", 2) = 2 write(2, "Current version of pixman: 0.16."..., 34) = 34 write(0, "Current version of pixman: 0.16."..., 34) = 34 write(2, "\tBefore reporting problems, chec"..., 100) = 100 write(0, "\tBefore reporting problems, chec"..., 100) = 100 write(2, "Markers: ", 9) = 9 write(0, "Markers: ", 9) = 9 write(2, "(--) probed, ", 13) = 13 write(0, "(--) probed, ", 13) = 13 write(2, "(**) from config file, ", 23) = 23 write(0, "(**) from config file, ", 23) = 23 write(2, "(==) default setting,\n\t", 23) = 23 write(0, "(==) default setting,\n\t", 23) = 23 write(2, "(++) from command line, ", 24) = 24 write(0, "(++) from command line, ", 24) = 24 write(2, "(!!) notice, ", 13) = 13 write(0, "(!!) notice, ", 13) = 13 write(2, "(II) informational,\n\t", 21) = 21 write(0, "(II) informational,\n\t", 21) = 21 write(2, "(WW) warning, ", 14) = 14 write(0, "(WW) warning, ", 14) = 14 write(2, "(EE) error, ", 12) = 12 write(0, "(EE) error, ", 12) = 12 write(2, "(NI) not implemented, ", 22) = 22 write(0, "(NI) not implemented, ", 22) = 22 write(2, "(??) unknown.\n", 14) = 14 write(0, "(??) unknown.\n", 14) = 14 time(NULL) = 1268757080 write(2, "(==) Log file: \"/usr/local/var/l"..., 79) = 79 write(0, "(==) Log file: \"/usr/local/var/l"..., 79) = 79 getuid32() = 0 open("/etc/X11/xorg.conf-4", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/X11/xorg.conf", O_RDONLY) = 7 write(2, "(==) Using config file: \"/etc/X1"..., 45) = 45 write(0, "(==) Using config file: \"/etc/X1"..., 45) = 45 fstat64(7, {st_mode=S_IFREG|0644, st_size=179, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40003000 read(7, "#Section \"ServerFlags\"\n# Option"..., 4096) = 179 read(7, "", 4096) = 0 close(7) = 0 munmap(0x40003000, 4096) = 0 write(0, "(==) No Layout section. Using t"..., 57) = 57 write(0, "(==) No screen section available"..., 50) = 50 write(0, "(**) |-->Screen \"Default Screen "..., 45) = 45 write(0, "(**) | |-->Monitor \"<default m"..., 41) = 41 write(0, "(==) No device specified for scr"..., 102) = 102 write(0, "(**) | |-->Device \"asdf\"\n", 27) = 27 write(0, "(==) No monitor specified for sc"..., 103) = 103 write(0, "(==) Automatically adding device"..., 34) = 34 write(0, "(==) Automatically enabling devi"..., 36) = 36 open("/dev/mem", O_RDONLY) = 7 mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 7, 0xf8) = 0x40003000 munmap(0x40003000, 4096) = 0 close(7) = 0 stat64("/usr/local/share/fonts/X11/misc/", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 stat64("/usr/local/share/fonts/X11/misc//fonts.dir", {st_mode=S_IFREG|0644, st_size=32637, ...}) = 0 stat64("/usr/local/share/fonts/X11/TTF/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat64("/usr/local/share/fonts/X11/TTF//fonts.dir", {st_mode=S_IFREG|0644, st_size=6345, ...}) = 0 stat64("/usr/local/share/fonts/X11/OTF/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat64("/usr/local/share/fonts/X11/OTF//fonts.dir", {st_mode=S_IFREG|0644, st_size=2000, ...}) = 0 stat64("/usr/local/share/fonts/X11/Type1/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat64("/usr/local/share/fonts/X11/Type1//fonts.dir", {st_mode=S_IFREG|0644, st_size=6867, ...}) = 0 stat64("/usr/local/share/fonts/X11/75dpi/", {st_mode=S_IFDIR|0755, st_size=65536, ...}) = 0 stat64("/usr/local/share/fonts/X11/75dpi//fonts.dir", {st_mode=S_IFREG|0644, st_size=165343, ...}) = 0 stat64("/usr/local/share/fonts/X11/100dpi/", {st_mode=S_IFDIR|0755, st_size=65536, ...}) = 0 stat64("/usr/local/share/fonts/X11/100dpi//fonts.dir", {st_mode=S_IFREG|0644, st_size=169851, ...}) = 0 write(0, "(==) FontPath set to:\n\t/usr/loca"..., 233) = 233 write(0, "(==) ModulePath set to \"/usr/loc"..., 53) = 53 write(0, "(II) Cannot locate a core pointe"..., 42) = 42 write(0, "(II) Cannot locate a core keyboa"..., 43) = 43 write(0, "(II) The server relies on HAL to"..., 144) = 144 write(0, "(II) Loader magic: 0x81eb240\n", 29) = 29 write(0, "(II) Module ABI versions:\n", 26) = 26 write(0, "\tX.Org ANSI C Emulation: 0.4\n", 29) = 29 write(0, "\tX.Org Video Driver: 6.0\n", 25) = 25 write(0, "\tX.Org XInput driver : 7.0\n", 27) = 27 write(0, "\tX.Org Server Extension : 2.0\n", 30) = 30 open("/dev/tty0", O_WRONLY) = 7 ioctl(7, VIDIOC_QUERYCAP or VT_OPENQRY, 0x81e96a4) = 0 close(7) = 0 write(0, "(--) using VT number 7\n\n", 24) = 24 getppid() = 3747 getpgid(0xea3) = 3747 setpgid(0, 3747) = 0 setsid() = 3748 open("/dev/vc/7", O_RDWR|O_NONBLOCK) = -1 ENOENT (No such file or directory) open("/dev/tty7", O_RDWR|O_NONBLOCK) = 7 stat64("/dev/tty0", {st_mode=S_IFCHR|0660, st_rdev=makedev(4, 0), ...}) = 0 stat64("/dev/tty7", {st_mode=S_IFCHR|0660, st_rdev=makedev(4, 7), ...}) = 0 geteuid32() = 0 getgid32() = 0 getuid32() = 0 chown32("/dev/tty7", 0, 0) = 0 getgid32() = 0 getuid32() = 0 chown32("/dev/tty0", 0, 0) = 0 ioctl(7, VT_GETSTATE, 0xbfd2a330) = 0 ioctl(7, VIDIOC_G_COMP or VT_ACTIVATE, 0x7) = 0 ioctl(7, VIDIOC_S_COMP or VT_WAITACTIVE, 0x7) = 0 ioctl(7, VIDIOC_RESERVED or VT_GETMODE, 0xbfd2a268) = 0 rt_sigaction(SIGUSR1, {0x8168e30, [USR1], SA_RESTART}, {SIG_DFL}, 8) = 0 ioctl(7, VIDIOC_ENUM_FMT or VT_SETMODE, 0xbfd2a268) = 0 ioctl(7, KDSETMODE, 0x1) = 0 ioctl(7, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(7, KDGKBMODE, 0x81f64fc) = 0 ioctl(7, KDSKBMODE, 0) = 0 ioctl(7, SNDCTL_TMR_START or TCSETS, {B0 -opost -isig -icanon -echo ...}) = 0 ioctl(7, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0 stat64("/sys/bus/pci/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 open("/proc/mtrr", O_WRONLY) = 8 open("/sys/bus/pci/devices", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 9 fstat64(9, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 getdents(9, /* 20 entries */, 4096) = 464 getdents(9, /* 0 entries */, 4096) = 0 close(9) = 0 open("/sys/bus/pci/devices/0000:00:00.0/config", O_RDONLY) = 9 pread64(9, "\206\2001%\6\0\220\240\4\0\0\6\0\0\0\0\10\0\0\330\0\0\0"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:00:01.0/config", O_RDONLY) = 9 pread64(9, "\206\2002%\7\1\240\0\4\0\4\6\0@\1\0\0\0\0\0\0\0\0\0\0\1"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:00:02.0/config", O_RDONLY) = 9 pread64(9, "\206\2003%\7\1\240\0\4\0\4\6\0 \1\0\0\0\0\0\0\0\0\0\0\2"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:00:1e.0/config", O_RDONLY) = 9 pread64(9, "\206\200N$\7\1\200\0\4\0\4\6\0\0\1\0\0\0\0\0\0\0\0\0\0"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:00:1f.0/config", O_RDONLY) = 9 pread64(9, "\206\200@$\17\0\200\2\4\0\1\6\0\0\200\0\0\0\0\0\0\0\0\0"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:00:1f.1/config", O_RDONLY) = 9 pread64(9, "\206\200K$\5\0\200\2\4\200\1\1\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:00:1f.2/config", O_RDONLY) = 9 pread64(9, "\206\200B$\5\0\200\2\4\0\3\f\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:00:1f.3/config", O_RDONLY) = 9 pread64(9, "\206\200C$\1\0\200\2\4\0\5\f\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:00:1f.4/config", O_RDONLY) = 9 pread64(9, "\206\200D$\5\0\200\2\4\0\3\f\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:00:1f.5/config", O_RDONLY) = 9 pread64(9, "\206\200E$\0\0\200\2\4\0\1\4\0\0\0\0\1\20\0\0\1\24\0\0"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:01:00.0/config", O_RDONLY) = 9 pread64(9, "\336\20\21\1\7\0\260\2\262\0\0\3\0 \0\0\0\0\0\334\10\0"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:02:1f.0/config", O_RDONLY) = 9 pread64(9, "\206\200`\23\7\1 \0\3\0\4\6\0\0\1\0\0\0\0\0\0\0\0\0\2\3"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:03:00.0/config", O_RDONLY) = 9 pread64(9, "\206\200a\21\0\0\0\0\1 \0\10\0\0\200\0\0000\0\337\0\0\0"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:03:02.0/config", O_RDONLY) = 9 pread64(9, "\267Z\3\0\7\0\200\2\1\0\200\7\10 \0\0\0\0\0\337\1\220\0"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:03:04.0/config", O_RDONLY) = 9 pread64(9, "\5\220\317\0\6\0\260\2\1\0\0\1\10 \200\200\1\230\0\0\4"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:03:04.1/config", O_RDONLY) = 9 pread64(9, "\5\220\317\0\6\0\260\2\1\0\0\1\10 \200\200\1\234\0\0\4"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:04:04.0/config", O_RDONLY) = 9 pread64(9, "\206\200)\22\7\0\220\2\10\0\0\2\10 \0\0\0\20\22\341\1\240"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:04:07.0/config", O_RDONLY) = 9 pread64(9, "\206\200)\22\7\0\220\2\f\0\0\2\10 \0\0\0\0\22\341\1\244"..., 48, 0) = 48 close(9) = 0 open("/sys/bus/pci/devices/0000:01:00.0/config", O_RDONLY) = 9 pread64(9, "\336\20\21\1\7\0\260\2\262\0\0\3\0 \0\0\0\0\0\334\10\0"..., 256, 0) = 256 close(9) = 0 open("/sys/bus/pci/devices/0000:01:00.0/resource", O_RDONLY) = 9 read(9, "0x00000000dc000000 0x00000000dcf"..., 512) = 399 close(9) = 0 open("/sys/bus/pci/devices/0000:01:00.0/boot_vga", O_RDONLY) = 9 read(9, "1", 1) = 1 close(9) = 0 open("/usr/share/hwdata/pci.ids", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/hwdata/pci.ids", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) write(0, "(--) PCI:*(0:1:0:0) 10de:0111:00"..., 40) = 40 write(0, "rev 178", 7) = 7 write(0, ", Mem @ ", 8) = 8 write(0, "0xdc000000/16777216", 19) = 19 write(0, ", ", 2) = 2 write(0, "0xd0000000/134217728", 20) = 20 write(0, ", BIOS @ 0x????????/65536", 25) = 25 write(0, "\n", 1) = 1 socket(PF_FILE, SOCK_STREAM, 0) = 9 connect(9, {sa_family=AF_FILE, path="/var/run/acpid.socket"}, 110) = 0 write(0, "(II) Open ACPI successful (/var/"..., 50) = 50 write(0, "(II) LoadModule: \"extmod\"", 25) = 25 write(0, "\n", 1) = 1 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd28100) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd28100) = -1 ENOTDIR (Not a directory) getdents(10, /* 0 entries */, 4096) = 0 close(10) = 0 open("/usr/local/lib/xorg/modules/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 29 entries */, 4096) = 676 stat64("/usr/local/lib/xorg/modules/extensions/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/extensions/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 12 entries */, 4096) = 272 stat64("/usr/local/lib/xorg/modules/extensions/libdbe.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdbe.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) close(11) = 0 close(10) = 0 write(0, "(II) Loading /usr/local/lib/xorg"..., 65) = 65 futex(0x4c23206c, FUTEX_WAKE, 2147483647) = 0 open("/usr/local/lib/xorg/modules/extensions/libextmod.so", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\00008\0\000"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0755, st_size=312971, ...}) = 0 mmap2(NULL, 87976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0x4031b000 mmap2(0x40330000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x15) = 0x40330000 close(10) = 0 write(0, "(II) Module extmod: vendor=\"X.Or"..., 46) = 46 write(0, "\tcompiled for 1.7.5", 19) = 19 write(0, ", module version = 1.0.0\n", 25) = 25 write(0, "\tModule class: X.Org Server Exte"..., 38) = 38 write(0, "\tABI class: X.Org Server Extensi"..., 48) = 48 write(0, "(II) Loading extension MIT-SCREE"..., 40) = 40 write(0, "(II) Loading extension XFree86-V"..., 48) = 48 write(0, "(II) Loading extension XFree86-D"..., 35) = 35 write(0, "(II) Loading extension DPMS\n", 28) = 28 write(0, "(II) Loading extension XVideo\n", 30) = 30 write(0, "(II) Loading extension XVideo-Mo"..., 49) = 49 write(0, "(II) Loading extension X-Resourc"..., 34) = 34 write(0, "(II) LoadModule: \"dbe\"", 22) = 22 write(0, "\n", 1) = 1 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd28100) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd28100) = -1 ENOTDIR (Not a directory) getdents(10, /* 0 entries */, 4096) = 0 close(10) = 0 open("/usr/local/lib/xorg/modules/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 29 entries */, 4096) = 676 stat64("/usr/local/lib/xorg/modules/extensions/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/extensions/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 12 entries */, 4096) = 272 stat64("/usr/local/lib/xorg/modules/extensions/libdbe.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdbe.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) close(11) = 0 close(10) = 0 write(0, "(II) Loading /usr/local/lib/xorg"..., 62) = 62 open("/usr/local/lib/xorg/modules/extensions/libdbe.so", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \f\0\000"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0755, st_size=74009, ...}) = 0 mmap2(NULL, 17576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0x40003000 mmap2(0x40007000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x3) = 0x40007000 close(10) = 0 write(0, "(II) Module dbe: vendor=\"X.Org F"..., 43) = 43 write(0, "\tcompiled for 1.7.5", 19) = 19 write(0, ", module version = 1.0.0\n", 25) = 25 write(0, "\tModule class: X.Org Server Exte"..., 38) = 38 write(0, "\tABI class: X.Org Server Extensi"..., 48) = 48 write(0, "(II) Loading extension DOUBLE-BU"..., 37) = 37 write(0, "(II) LoadModule: \"glx\"", 22) = 22 write(0, "\n", 1) = 1 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd28100) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd28100) = -1 ENOTDIR (Not a directory) getdents(10, /* 0 entries */, 4096) = 0 close(10) = 0 open("/usr/local/lib/xorg/modules/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 29 entries */, 4096) = 676 stat64("/usr/local/lib/xorg/modules/extensions/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/extensions/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 12 entries */, 4096) = 272 stat64("/usr/local/lib/xorg/modules/extensions/libdbe.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdbe.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libglx.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libglx.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) close(11) = 0 close(10) = 0 write(0, "(II) Loading /usr/local/lib/xorg"..., 62) = 62 open("/usr/local/lib/xorg/modules/extensions/libglx.so", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@z\0\000"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0755, st_size=1581617, ...}) = 0 mmap2(NULL, 366840, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0x40331000 mmap2(0x40386000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x54) = 0x40386000 mmap2(0x4038a000, 2296, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4038a000 close(10) = 0 write(0, "(II) Module glx: vendor=\"X.Org F"..., 43) = 43 write(0, "\tcompiled for 1.7.5", 19) = 19 write(0, ", module version = 1.0.0\n", 25) = 25 write(0, "\tABI class: X.Org Server Extensi"..., 48) = 48 write(0, "(==) AIGLX enabled\n", 19) = 19 write(0, "(II) Loading extension GLX\n", 27) = 27 write(0, "(II) LoadModule: \"dri\"", 22) = 22 write(0, "\n", 1) = 1 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd28100) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd28100) = -1 ENOTDIR (Not a directory) getdents(10, /* 0 entries */, 4096) = 0 close(10) = 0 open("/usr/local/lib/xorg/modules/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 29 entries */, 4096) = 676 stat64("/usr/local/lib/xorg/modules/extensions/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/extensions/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 12 entries */, 4096) = 272 stat64("/usr/local/lib/xorg/modules/extensions/libdbe.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdbe.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) close(11) = 0 close(10) = 0 write(0, "(II) Loading /usr/local/lib/xorg"..., 62) = 62 open("/usr/local/lib/xorg/modules/extensions/libdri.so", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 $\0\000"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0755, st_size=124857, ...}) = 0 mmap2(NULL, 36816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0x4038b000 mmap2(0x40393000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x7) = 0x40393000 close(10) = 0 open("/etc/ld.so.cache", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=50556, ...}) = 0 mmap2(NULL, 50556, PROT_READ, MAP_PRIVATE, 10, 0) = 0x40394000 close(10) = 0 open("/usr/local/lib/libdrm.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@$\0\000"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0755, st_size=93616, ...}) = 0 mmap2(NULL, 38884, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0x403a1000 mmap2(0x403aa000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x8) = 0x403aa000 close(10) = 0 munmap(0x40394000, 50556) = 0 write(0, "(II) Module dri: vendor=\"X.Org F"..., 43) = 43 write(0, "\tcompiled for 1.7.5", 19) = 19 write(0, ", module version = 1.0.0\n", 25) = 25 write(0, "\tABI class: X.Org Server Extensi"..., 48) = 48 write(0, "(II) Loading extension XFree86-D"..., 35) = 35 write(0, "(II) LoadModule: \"dri2\"", 23) = 23 write(0, "\n", 1) = 1 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd28100) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd28100) = -1 ENOTDIR (Not a directory) getdents(10, /* 0 entries */, 4096) = 0 close(10) = 0 open("/usr/local/lib/xorg/modules/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 29 entries */, 4096) = 676 stat64("/usr/local/lib/xorg/modules/extensions/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/extensions/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 12 entries */, 4096) = 272 stat64("/usr/local/lib/xorg/modules/extensions/libdbe.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdbe.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) close(11) = 0 close(10) = 0 write(0, "(II) Loading /usr/local/lib/xorg"..., 63) = 63 open("/usr/local/lib/xorg/modules/extensions/libdri2.so", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\v\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0755, st_size=50319, ...}) = 0 mmap2(NULL, 8784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0x40008000 mmap2(0x4000a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x2) = 0x4000a000 close(10) = 0 write(0, "(II) Module dri2: vendor=\"X.Org "..., 44) = 44 write(0, "\tcompiled for 1.7.5", 19) = 19 write(0, ", module version = 1.1.0\n", 25) = 25 write(0, "\tABI class: X.Org Server Extensi"..., 48) = 48 write(0, "(II) Loading extension DRI2\n", 28) = 28 write(0, "(II) LoadModule: \"nouveau\"", 26) = 26 write(0, "\n", 1) = 1 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd28100) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd28100) = -1 ENOTDIR (Not a directory) getdents(10, /* 0 entries */, 4096) = 0 close(10) = 0 open("/usr/local/lib/xorg/modules/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 29 entries */, 4096) = 676 stat64("/usr/local/lib/xorg/modules/extensions/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/extensions/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 12 entries */, 4096) = 272 stat64("/usr/local/lib/xorg/modules/extensions/libdbe.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdbe.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libglx.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libglx.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) getdents(11, /* 0 entries */, 4096) = 0 close(11) = 0 stat64("/usr/local/lib/xorg/modules/linux/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) getdents(11, /* 0 entries */, 4096) = 0 close(11) = 0 stat64("/usr/local/lib/xorg/modules/multimedia/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/multimedia/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 22 entries */, 4096) = 608 stat64("/usr/local/lib/xorg/modules/multimedia/bt829_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/bt829_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/fi1236_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/fi1236_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/msp3430_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/msp3430_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda8425_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda8425_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9850_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9850_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9885_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9885_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/uda1380_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/uda1380_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre200_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre200_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_detect_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_detect_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) getdents(11, /* 0 entries */, 4096) = 0 close(11) = 0 stat64("/usr/local/lib/xorg/modules/input/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/input/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 20 entries */, 4096) = 504 stat64("/usr/local/lib/xorg/modules/input/aiptek_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/aiptek_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/evdev_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/evdev_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/joystick_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/joystick_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/vmmouse_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/vmmouse_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/acecad_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/acecad_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/kbd_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/kbd_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/mouse_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/mouse_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/synaptics_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/synaptics_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/void_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/void_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) getdents(11, /* 0 entries */, 4096) = 0 close(11) = 0 stat64("/usr/local/lib/xorg/modules/drivers/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/drivers/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 75 entries */, 4096) = 1916 stat64("/usr/local/lib/xorg/modules/drivers/v4l_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/v4l_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i740_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i740_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/apm_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/apm_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ark_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ark_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ast_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ast_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ati_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ati_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeon_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeon_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/chips_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/chips_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_alpine.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_alpine.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_laguna.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_laguna.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/dummy_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/dummy_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/fbdev_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/fbdev_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/geode_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/geode_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ztv_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ztv_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/glint_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/glint_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i128_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i128_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mach64_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mach64_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mga_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mga_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/neomagic_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/neomagic_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nv_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nv_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeonhd_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeonhd_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/rendition_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/rendition_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/r128_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/r128_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3virge_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3virge_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/savage_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/savage_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/siliconmotion_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/siliconmotion_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tdfx_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tdfx_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tga_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tga_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/trident_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/trident_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tseng_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tseng_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/vesa_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/vesa_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/voodoo_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/voodoo_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nouveau_drv.la/", 0xbfd27050) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nouveau_drv.so/", 0xbfd27050) = -1 ENOTDIR (Not a directory) close(11) = 0 close(10) = 0 write(0, "(II) Loading /usr/local/lib/xorg"..., 64) = 64 open("/usr/local/lib/xorg/modules/drivers/nouveau_drv.so", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`O\0\000"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0755, st_size=1117231, ...}) = 0 mmap2(NULL, 192020, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0x403ab000 mmap2(0x403d5000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x29) = 0x403d5000 close(10) = 0 open("/etc/ld.so.cache", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=50556, ...}) = 0 mmap2(NULL, 50556, PROT_READ, MAP_PRIVATE, 10, 0) = 0x40394000 close(10) = 0 open("/usr/local/lib/libdrm_nouveau.so.1", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\22\0\000"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0755, st_size=57762, ...}) = 0 mmap2(NULL, 19676, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0x403da000 mmap2(0x403de000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x3) = 0x403de000 close(10) = 0 munmap(0x40394000, 50556) = 0 write(0, "(II) Module nouveau: vendor=\"X.O"..., 47) = 47 write(0, "\tcompiled for 1.7.5", 19) = 19 write(0, ", module version = 0.0.15\n", 26) = 26 write(0, "\tModule class: X.Org Video Drive"..., 34) = 34 write(0, "\tABI class: X.Org Video Driver, "..., 44) = 44 write(0, "(II) NOUVEAU driver Date: Wed "..., 59) = 59 write(0, "(II) NOUVEAU driver for NVIDIA c"..., 50) = 50 write(0, "\tRIVA TNT", 9) = 9 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, "(NV04)\n", 7) = 7 write(0, "\tRIVA TNT2", 10) = 10 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, "(NV05)\n", 7) = 7 write(0, "\tGeForce 256", 12) = 12 write(0, " ", 1) = 1 write(0, "(NV10)\n", 7) = 7 write(0, "\tGeForce 2", 10) = 10 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, "(NV11, NV15)\n", 13) = 13 write(0, "\tGeForce 4MX", 12) = 12 write(0, " ", 1) = 1 write(0, "(NV17, NV18)\n", 13) = 13 write(0, "\tGeForce 3", 10) = 10 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, "(NV20)\n", 7) = 7 write(0, "\tGeForce 4Ti", 12) = 12 write(0, " ", 1) = 1 write(0, "(NV25, NV28)\n", 13) = 13 write(0, "\tGeForce FX", 11) = 11 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, "(NV3x)\n", 7) = 7 write(0, "\tGeForce 6", 10) = 10 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, "(NV4x)\n", 7) = 7 write(0, "\tGeForce 7", 10) = 10 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, "(G7x)\n", 6) = 6 write(0, "\tGeForce 8", 10) = 10 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, " ", 1) = 1 write(0, "(G8x)\n", 6) = 6 ioperm(0, 0x400, 0x1) = 0 iopl(0x3) = 0 ioperm(0x40, 0x4, 0) = 0 ioperm(0x60, 0x4, 0) = 0 write(0, "(II) Primary Device is: PCI 01@0"..., 39) = 39 geteuid32() = 0 write(0, "drmOpenDevice: node name is /dev"..., 43) = 43 stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 stat64("/dev/dri/card0", {st_mode=S_IFCHR|0600, st_rdev=makedev(226, 0), ...}) = 0 chown32("/dev/dri/card0", 0, -1) = 0 chmod("/dev/dri/card0", 0660) = 0 open("/dev/dri/card0", O_RDWR|O_LARGEFILE) = 10 write(0, "drmOpenDevice: open result is 10"..., 39) = 39 ioctl(10, DEVFSDIOC_GET_PROTO_REV, 0x92efeb8) = 0 ioctl(10, DEVFSDIOC_GET_PROTO_REV, 0x92efeb8) = 0 close(10) = 0 write(0, "drmOpenByBusid: Searching for Bu"..., 53) = 53 geteuid32() = 0 write(0, "drmOpenDevice: node name is /dev"..., 43) = 43 stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 stat64("/dev/dri/card0", {st_mode=S_IFCHR|0660, st_rdev=makedev(226, 0), ...}) = 0 chown32("/dev/dri/card0", 0, -1) = 0 chmod("/dev/dri/card0", 0660) = 0 open("/dev/dri/card0", O_RDWR|O_LARGEFILE) = 10 write(0, "drmOpenDevice: open result is 10"..., 39) = 39 write(0, "drmOpenByBusid: drmOpenMinor ret"..., 40) = 40 ioctl(10, DECODER_SET_PICTURE, 0xbfd29ee0) = 0 ioctl(10, DECODER_GET_CAPABILITIES, 0xbfd29ef0) = 0 ioctl(10, DECODER_GET_CAPABILITIES, 0xbfd29ef0) = 0 write(0, "drmOpenByBusid: drmGetBusid repo"..., 53) = 53 ioctl(10, 0xc0086420, 0xbfd2a218) = 0 ioctl(10, DEVFSDIOC_GET_PROTO_REV, 0x92eff48) = 0 ioctl(10, DEVFSDIOC_GET_PROTO_REV, 0x92eff48) = 0 ioctl(10, 0xc0106440, 0xbfd2a1d0) = 0 ioctl(10, 0xc0106440, 0xbfd2a1d0) = 0 ioctl(10, 0xc0106440, 0xbfd2a1d0) = 0 ioctl(10, 0xc0106440, 0xbfd2a1d0) = 0 ioctl(10, DEVFSDIOC_GET_PROTO_REV, 0x92efeb8) = 0 ioctl(10, DEVFSDIOC_GET_PROTO_REV, 0x92efeb8) = 0 write(0, "(II) [drm] nouveau interface ver"..., 45) = 45 ioctl(10, 0xc0086421, 0xbfd2a228) = 0 fstat64(10, {st_mode=S_IFCHR|0660, st_rdev=makedev(226, 0), ...}) = 0 fstat64(10, {st_mode=S_IFCHR|0660, st_rdev=makedev(226, 0), ...}) = 0 close(10) = 0 open("/sys/bus/pci/devices/0000:01:00.0/drm", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or directory) open("/sys/bus/pci/devices/0000:01:00.0/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 fstat64(10, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 getdents(10, /* 33 entries */, 4096) = 736 close(10) = 0 open("/dev/vga_arbiter", O_RDWR) = 10 read(10, "count:1,PCI:0000:01:00.0,decodes"..., 64) = 64 write(10, "target PCI:0000:01:00.0", 23) = 23 read(10, "count:1,PCI:0000:01:00.0,decodes"..., 64) = 64 write(0, "(II) Loading sub module \"dri\"\n", 30) = 30 write(0, "(II) LoadModule: \"dri\"", 22) = 22 write(0, "\n", 1) = 1 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd28060) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd28060) = -1 ENOTDIR (Not a directory) getdents(11, /* 0 entries */, 4096) = 0 close(11) = 0 open("/usr/local/lib/xorg/modules/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11 fstat64(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getdents(11, /* 29 entries */, 4096) = 676 stat64("/usr/local/lib/xorg/modules/extensions/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/extensions/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 12 fstat64(12, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(12, F_SETFD, FD_CLOEXEC) = 0 getdents(12, /* 12 entries */, 4096) = 272 stat64("/usr/local/lib/xorg/modules/extensions/libdbe.la/", 0xbfd26fb0) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdbe.so/", 0xbfd26fb0) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.la/", 0xbfd26fb0) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.so/", 0xbfd26fb0) = -1 ENOTDIR (Not a directory) close(12) = 0 close(11) = 0 write(0, "(II) Reloading /usr/local/lib/xo"..., 64) = 64 write(0, "(II) NOUVEAU(0): Loaded DRI modu"..., 35) = 35 geteuid32() = 0 write(0, "drmOpenDevice: node name is /dev"..., 43) = 43 stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 stat64("/dev/dri/card0", {st_mode=S_IFCHR|0660, st_rdev=makedev(226, 0), ...}) = 0 chown32("/dev/dri/card0", 0, -1) = 0 chmod("/dev/dri/card0", 0660) = 0 open("/dev/dri/card0", O_RDWR|O_LARGEFILE) = 11 write(0, "drmOpenDevice: open result is 11"..., 39) = 39 ioctl(11, DEVFSDIOC_GET_PROTO_REV, 0x92f0ed8) = 0 ioctl(11, DEVFSDIOC_GET_PROTO_REV, 0x92f0ed8) = 0 close(11) = 0 geteuid32() = 0 write(0, "drmOpenDevice: node name is /dev"..., 43) = 43 stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 stat64("/dev/dri/card0", {st_mode=S_IFCHR|0660, st_rdev=makedev(226, 0), ...}) = 0 chown32("/dev/dri/card0", 0, -1) = 0 chmod("/dev/dri/card0", 0660) = 0 open("/dev/dri/card0", O_RDWR|O_LARGEFILE) = 11 write(0, "drmOpenDevice: open result is 11"..., 39) = 39 ioctl(11, DEVFSDIOC_GET_PROTO_REV, 0x92f0f20) = 0 ioctl(11, DEVFSDIOC_GET_PROTO_REV, 0x92f0f20) = 0 close(11) = 0 write(0, "drmOpenByBusid: Searching for Bu"..., 53) = 53 geteuid32() = 0 write(0, "drmOpenDevice: node name is /dev"..., 43) = 43 stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 stat64("/dev/dri/card0", {st_mode=S_IFCHR|0660, st_rdev=makedev(226, 0), ...}) = 0 chown32("/dev/dri/card0", 0, -1) = 0 chmod("/dev/dri/card0", 0660) = 0 open("/dev/dri/card0", O_RDWR|O_LARGEFILE) = 11 write(0, "drmOpenDevice: open result is 11"..., 39) = 39 write(0, "drmOpenByBusid: drmOpenMinor ret"..., 40) = 40 ioctl(11, DECODER_SET_PICTURE, 0xbfd29ec0) = 0 ioctl(11, DECODER_GET_CAPABILITIES, 0xbfd29ed0) = 0 ioctl(11, DECODER_GET_CAPABILITIES, 0xbfd29ed0) = 0 write(0, "drmOpenByBusid: drmGetBusid repo"..., 53) = 53 ioctl(11, DECODER_SET_PICTURE, 0xbfd2a1e0) = 0 write(0, "(II) [drm] DRM interface version"..., 37) = 37 ioctl(11, 0xc0186415, 0xbfd2a1e0) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 11, 0xedc0b) = 0x4000b000 write(0, "(II) [drm] DRM open master succe"..., 38) = 38 ioctl(11, DEVFSDIOC_GET_PROTO_REV, 0x92f0ed8) = 0 ioctl(11, DEVFSDIOC_GET_PROTO_REV, 0x92f0ed8) = 0 ioctl(11, 0xc0106440, 0xbfd2a250) = 0 ioctl(11, 0xc0106440, 0xbfd2a250) = 0 ioctl(11, 0xc0106440, 0xbfd2a250) = 0 ioctl(11, 0xc0106440, 0xbfd2a250) = 0 fstat64(11, {st_mode=S_IFCHR|0660, st_rdev=makedev(226, 0), ...}) = 0 stat64("/dev/dri/card0", {st_mode=S_IFCHR|0660, st_rdev=makedev(226, 0), ...}) = 0 write(0, "(--) NOUVEAU(0): Chipset: \"NVIDI"..., 40) = 40 write(0, "(II) NOUVEAU(0): Creating defaul"..., 119) = 119 write(0, "(==) NOUVEAU(0): Depth 24, ", 27) = 27 write(0, "(--) framebuffer bpp 32\n", 24) = 24 write(0, "(==) NOUVEAU(0): RGB weight 888\n", 32) = 32 write(0, "(==) NOUVEAU(0): Default visual "..., 45) = 45 write(0, "(==) NOUVEAU(0): Using HW cursor"..., 33) = 33 ioctl(11, 0xc04064a0, 0xbfd2a1b0) = 0 ioctl(11, 0xc04064a0, 0xbfd2a1b0) = 0 ioctl(11, 0xc06864a1, 0xbfd2a190) = 0 ioctl(11, 0xc0306480, 0xbfd2a170) = 0 ioctl(11, 0xc06864a1, 0xbfd2a190) = 0 ioctl(11, 0xc0306480, 0xbfd2a170) = 0 ioctl(11, 0xc04c64a7, 0xbfd2a1a0) = 0 ioctl(11, 0xc04c64a7, 0xbfd2a1a0) = 0 ioctl(11, 0xc01464a6, 0xbfd2a1e0) = 0 write(0, "(II) NOUVEAU(0): Output VGA-1 ha"..., 53) = 53 ioctl(11, 0xc04c64a7, 0xbfd2a1a0) = 0 ioctl(11, 0xc04c64a7, 0xbfd2a1a0) = 0 ioctl(11, 0xc01464a6, 0xbfd2a1e0) = 0 write(0, "(II) NOUVEAU(0): Output DVI-D-1 "..., 55) = 55 ioctl(11, 0xc04c64a7, 0xbfd29e50) = 0 ioctl(11, 0xc04c64a7, 0xbfd29e50) = 0 ioctl(11, 0xc04064aa, 0xbfd29e30) = 0 ioctl(11, 0xc04064aa, 0xbfd29e30) = 0 ioctl(11, 0xc01064ac, 0xbfd29e60) = 0 ioctl(11, 0xc01064ac, 0xbfd29e60) = 0 ioctl(11, 0xc04064aa, 0xbfd29e30) = 0 ioctl(11, 0xc04064aa, 0xbfd29e30) = 0 write(0, "(II) NOUVEAU(0): EDID vendor \"BN"..., 50) = 50 write(0, "(II) NOUVEAU(0): Using EDID rang"..., 59) = 59 write(0, "(II) NOUVEAU(0): Using EDID rang"..., 60) = 60 write(0, "(II) NOUVEAU(0): Printing DDC ga"..., 50) = 50 write(0, "(II) NOUVEAU(0): Modeline \"1680x"..., 117) = 117 write(0, "(II) NOUVEAU(0): Modeline \"640x3"..., 107) = 107 write(0, "(II) NOUVEAU(0): Modeline \"800x6"..., 108) = 108 write(0, "(II) NOUVEAU(0): Modeline \"640x4"..., 107) = 107 write(0, "(II) NOUVEAU(0): Modeline \"640x4"..., 107) = 107 write(0, "(II) NOUVEAU(0): Modeline \"720x4"..., 107) = 107 write(0, "(II) NOUVEAU(0): Modeline \"1280x"..., 117) = 117 write(0, "(II) NOUVEAU(0): Modeline \"1024x"..., 112) = 112 write(0, "(II) NOUVEAU(0): Modeline \"1024x"..., 112) = 112 write(0, "(II) NOUVEAU(0): Modeline \"1024x"..., 112) = 112 write(0, "(II) NOUVEAU(0): Modeline \"832x6"..., 108) = 108 write(0, "(II) NOUVEAU(0): Modeline \"800x6"..., 108) = 108 write(0, "(II) NOUVEAU(0): Modeline \"1152x"..., 112) = 112 write(0, "(II) NOUVEAU(0): Modeline \"1280x"..., 113) = 113 write(0, "(II) NOUVEAU(0): Modeline \"1280x"..., 117) = 117 ioctl(11, 0xc04c64a7, 0xbfd29e50) = 0 ioctl(11, 0xc04c64a7, 0xbfd29e50) = 0 write(0, "(II) NOUVEAU(0): Output VGA-1 co"..., 40) = 40 write(0, "(II) NOUVEAU(0): Output DVI-D-1 "..., 45) = 45 write(0, "(II) NOUVEAU(0): Using exact siz"..., 53) = 53 write(0, "(II) NOUVEAU(0): Output VGA-1 us"..., 59) = 59 write(0, "(II) NOUVEAU(0): Using default g"..., 81) = 81 write(0, "(--) NOUVEAU(0): Virtual size is"..., 56) = 56 write(0, "(**) NOUVEAU(0): Driver mode \"1"..., 94) = 94 write(0, "(II) NOUVEAU(0): Modeline \"1680x"..., 118) = 118 write(0, "(**) NOUVEAU(0): Driver mode \"1"..., 94) = 94 write(0, "(II) NOUVEAU(0): Modeline \"1280x"..., 118) = 118 write(0, "(**) NOUVEAU(0): Driver mode \"1"..., 94) = 94 write(0, "(II) NOUVEAU(0): Modeline \"1280x"..., 118) = 118 write(0, "(**) NOUVEAU(0): Driver mode \"1"..., 93) = 93 write(0, "(II) NOUVEAU(0): Modeline \"1280x"..., 114) = 114 write(0, "(**) NOUVEAU(0): Driver mode \"1"..., 93) = 93 write(0, "(II) NOUVEAU(0): Modeline \"1152x"..., 113) = 113 write(0, "(**) NOUVEAU(0): Driver mode \"1"..., 92) = 92 write(0, "(II) NOUVEAU(0): Modeline \"1024x"..., 113) = 113 write(0, "(**) NOUVEAU(0): Driver mode \"1"..., 92) = 92 write(0, "(II) NOUVEAU(0): Modeline \"1024x"..., 113) = 113 write(0, "(**) NOUVEAU(0): Driver mode \"1"..., 92) = 92 write(0, "(II) NOUVEAU(0): Modeline \"1024x"..., 113) = 113 write(0, "(**) NOUVEAU(0): Driver mode \"1"..., 92) = 92 write(0, "(II) NOUVEAU(0): Modeline \"1024x"..., 113) = 113 write(0, "(**) NOUVEAU(0): Driver mode \"8"..., 91) = 91 write(0, "(II) NOUVEAU(0): Modeline \"832x6"..., 109) = 109 write(0, "(**) NOUVEAU(0): Driver mode \"8"..., 91) = 91 write(0, "(II) NOUVEAU(0): Modeline \"800x6"..., 109) = 109 write(0, "(**) NOUVEAU(0): Driver mode \"8"..., 91) = 91 write(0, "(II) NOUVEAU(0): Modeline \"800x6"..., 109) = 109 write(0, "(**) NOUVEAU(0): Driver mode \"6"..., 91) = 91 write(0, "(II) NOUVEAU(0): Modeline \"640x4"..., 108) = 108 write(0, "(**) NOUVEAU(0): Driver mode \"6"..., 91) = 91 write(0, "(II) NOUVEAU(0): Modeline \"640x4"..., 108) = 108 write(0, "(**) NOUVEAU(0): Driver mode \"7"..., 91) = 91 write(0, "(II) NOUVEAU(0): Modeline \"720x4"..., 108) = 108 write(0, "(**) NOUVEAU(0): Driver mode \"6"..., 91) = 91 write(0, "(II) NOUVEAU(0): Modeline \"640x3"..., 108) = 108 write(0, "(**) NOUVEAU(0): Display dimensi"..., 51) = 51 write(0, "(**) NOUVEAU(0): DPI set to (99,"..., 37) = 37 write(0, "(II) Loading sub module \"fb\"\n", 29) = 29 write(0, "(II) LoadModule: \"fb\"", 21) = 21 write(0, "\n", 1) = 1 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 12 fstat64(12, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(12, F_SETFD, FD_CLOEXEC) = 0 getdents(12, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd28020) = -1 ENOTDIR (Not a directory) getdents(12, /* 0 entries */, 4096) = 0 close(12) = 0 open("/usr/local/lib/xorg/modules/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 12 fstat64(12, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(12, F_SETFD, FD_CLOEXEC) = 0 getdents(12, /* 29 entries */, 4096) = 676 stat64("/usr/local/lib/xorg/modules/extensions/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/extensions/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 12 entries */, 4096) = 272 stat64("/usr/local/lib/xorg/modules/extensions/libdbe.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdbe.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libglx.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libglx.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/linux/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/multimedia/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/multimedia/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 22 entries */, 4096) = 608 stat64("/usr/local/lib/xorg/modules/multimedia/bt829_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/bt829_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/fi1236_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/fi1236_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/msp3430_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/msp3430_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda8425_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda8425_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9850_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9850_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9885_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9885_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/uda1380_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/uda1380_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre200_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre200_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_detect_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_detect_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/input/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/input/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 20 entries */, 4096) = 504 stat64("/usr/local/lib/xorg/modules/input/aiptek_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/aiptek_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/evdev_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/evdev_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/joystick_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/joystick_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/vmmouse_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/vmmouse_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/acecad_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/acecad_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/kbd_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/kbd_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/mouse_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/mouse_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/synaptics_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/synaptics_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/void_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/void_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/drivers/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/drivers/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 75 entries */, 4096) = 1916 stat64("/usr/local/lib/xorg/modules/drivers/v4l_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/v4l_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i740_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i740_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/apm_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/apm_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ark_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ark_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ast_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ast_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ati_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ati_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeon_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeon_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/chips_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/chips_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_alpine.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_alpine.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_laguna.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_laguna.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/dummy_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/dummy_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/fbdev_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/fbdev_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/geode_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/geode_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ztv_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ztv_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/glint_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/glint_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i128_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i128_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mach64_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mach64_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mga_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mga_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/neomagic_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/neomagic_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nv_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nv_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeonhd_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeonhd_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/rendition_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/rendition_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/r128_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/r128_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3virge_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3virge_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/savage_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/savage_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/siliconmotion_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/siliconmotion_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tdfx_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tdfx_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tga_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tga_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/trident_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/trident_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tseng_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tseng_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/vesa_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/vesa_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/voodoo_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/voodoo_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nouveau_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nouveau_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i965g_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/modesetting_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeong_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/libexa.la/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libexa.so/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libfb.la/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libfb.so/", 0xbfd28020) = -1 ENOTDIR (Not a directory) close(12) = 0 write(0, "(II) Loading /usr/local/lib/xorg"..., 50) = 50 open("/usr/local/lib/xorg/modules/libfb.so", O_RDONLY) = 12 read(12, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340<\0"..., 512) = 512 fstat64(12, {st_mode=S_IFREG|0755, st_size=510340, ...}) = 0 mmap2(NULL, 117212, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 12, 0) = 0x403df000 mmap2(0x403fb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 12, 0x1b) = 0x403fb000 close(12) = 0 write(0, "(II) Module fb: vendor=\"X.Org Fo"..., 42) = 42 write(0, "\tcompiled for 1.7.5", 19) = 19 write(0, ", module version = 1.0.0\n", 25) = 25 write(0, "\tABI class: X.Org ANSI C Emulati"..., 48) = 48 write(0, "(II) Loading sub module \"exa\"\n", 30) = 30 write(0, "(II) LoadModule: \"exa\"", 22) = 22 write(0, "\n", 1) = 1 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 12 fstat64(12, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(12, F_SETFD, FD_CLOEXEC) = 0 getdents(12, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd28020) = -1 ENOTDIR (Not a directory) getdents(12, /* 0 entries */, 4096) = 0 close(12) = 0 open("/usr/local/lib/xorg/modules/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 12 fstat64(12, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(12, F_SETFD, FD_CLOEXEC) = 0 getdents(12, /* 29 entries */, 4096) = 676 stat64("/usr/local/lib/xorg/modules/extensions/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/extensions/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 12 entries */, 4096) = 272 stat64("/usr/local/lib/xorg/modules/extensions/libdbe.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdbe.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libglx.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libglx.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/linux/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/multimedia/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/multimedia/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 22 entries */, 4096) = 608 stat64("/usr/local/lib/xorg/modules/multimedia/bt829_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/bt829_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/fi1236_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/fi1236_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/msp3430_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/msp3430_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda8425_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda8425_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9850_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9850_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9885_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9885_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/uda1380_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/uda1380_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre200_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre200_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_detect_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_detect_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/input/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/input/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 20 entries */, 4096) = 504 stat64("/usr/local/lib/xorg/modules/input/aiptek_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/aiptek_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/evdev_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/evdev_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/joystick_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/joystick_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/vmmouse_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/vmmouse_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/acecad_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/acecad_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/kbd_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/kbd_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/mouse_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/mouse_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/synaptics_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/synaptics_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/void_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/void_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/drivers/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/drivers/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 75 entries */, 4096) = 1916 stat64("/usr/local/lib/xorg/modules/drivers/v4l_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/v4l_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i740_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i740_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/apm_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/apm_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ark_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ark_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ast_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ast_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ati_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ati_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeon_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeon_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/chips_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/chips_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_alpine.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_alpine.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_laguna.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_laguna.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/dummy_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/dummy_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/fbdev_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/fbdev_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/geode_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/geode_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ztv_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ztv_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/glint_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/glint_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i128_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i128_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mach64_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mach64_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mga_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mga_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/neomagic_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/neomagic_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nv_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nv_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeonhd_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeonhd_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/rendition_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/rendition_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/r128_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/r128_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3virge_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3virge_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/savage_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/savage_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/siliconmotion_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/siliconmotion_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tdfx_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tdfx_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tga_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tga_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/trident_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/trident_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tseng_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tseng_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/vesa_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/vesa_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/voodoo_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/voodoo_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nouveau_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nouveau_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i965g_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/modesetting_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeong_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/libexa.la/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libexa.so/", 0xbfd28020) = -1 ENOTDIR (Not a directory) close(12) = 0 write(0, "(II) Loading /usr/local/lib/xorg"..., 51) = 51 open("/usr/local/lib/xorg/modules/libexa.so", O_RDONLY) = 12 read(12, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200+\0"..., 512) = 512 fstat64(12, {st_mode=S_IFREG|0755, st_size=387628, ...}) = 0 mmap2(NULL, 77408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 12, 0) = 0x403fc000 mmap2(0x4040e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 12, 0x11) = 0x4040e000 close(12) = 0 write(0, "(II) Module exa: vendor=\"X.Org F"..., 43) = 43 write(0, "\tcompiled for 1.7.5", 19) = 19 write(0, ", module version = 2.5.0\n", 25) = 25 write(0, "\tABI class: X.Org Video Driver, "..., 44) = 44 write(0, "(II) Loading sub module \"shadowf"..., 35) = 35 write(0, "(II) LoadModule: \"shadowfb\"", 27) = 27 write(0, "\n", 1) = 1 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 12 fstat64(12, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(12, F_SETFD, FD_CLOEXEC) = 0 getdents(12, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd28020) = -1 ENOTDIR (Not a directory) getdents(12, /* 0 entries */, 4096) = 0 close(12) = 0 open("/usr/local/lib/xorg/modules/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 12 fstat64(12, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(12, F_SETFD, FD_CLOEXEC) = 0 getdents(12, /* 29 entries */, 4096) = 676 stat64("/usr/local/lib/xorg/modules/extensions/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/extensions/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 12 entries */, 4096) = 272 stat64("/usr/local/lib/xorg/modules/extensions/libdbe.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdbe.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libdri2.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libextmod.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libglx.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/extensions/libglx.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/linux/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 4 entries */, 4096) = 88 stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/linux/libfbdevhw.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/multimedia/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/multimedia/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 22 entries */, 4096) = 608 stat64("/usr/local/lib/xorg/modules/multimedia/bt829_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/bt829_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/fi1236_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/fi1236_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/msp3430_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/msp3430_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda8425_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda8425_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9850_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9850_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9885_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/tda9885_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/uda1380_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/uda1380_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre200_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre200_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_detect_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_detect_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/multimedia/theatre_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/input/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/input/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 20 entries */, 4096) = 504 stat64("/usr/local/lib/xorg/modules/input/aiptek_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/aiptek_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/evdev_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/evdev_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/joystick_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/joystick_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/vmmouse_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/vmmouse_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/acecad_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/acecad_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/kbd_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/kbd_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/mouse_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/mouse_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/synaptics_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/synaptics_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/void_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/input/void_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/drivers/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/usr/local/lib/xorg/modules/drivers/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13 fstat64(13, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 getdents(13, /* 75 entries */, 4096) = 1916 stat64("/usr/local/lib/xorg/modules/drivers/v4l_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/v4l_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i740_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i740_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/apm_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/apm_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ark_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ark_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ast_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ast_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ati_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ati_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeon_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeon_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/chips_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/chips_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_alpine.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_alpine.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_laguna.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/cirrus_laguna.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/dummy_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/dummy_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/fbdev_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/fbdev_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/geode_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/geode_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ztv_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/ztv_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/glint_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/glint_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i128_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i128_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mach64_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mach64_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mga_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/mga_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/neomagic_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/neomagic_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nv_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nv_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeonhd_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeonhd_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/rendition_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/rendition_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/r128_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/r128_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3virge_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/s3virge_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/savage_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/savage_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/siliconmotion_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/siliconmotion_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tdfx_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tdfx_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tga_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tga_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/trident_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/trident_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tseng_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/tseng_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/vesa_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/vesa_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/voodoo_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/voodoo_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nouveau_drv.la/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/nouveau_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/i965g_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/modesetting_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/drivers/radeong_drv.so/", 0xbfd26f70) = -1 ENOTDIR (Not a directory) getdents(13, /* 0 entries */, 4096) = 0 close(13) = 0 stat64("/usr/local/lib/xorg/modules/libexa.la/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libexa.so/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libfb.la/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libfb.so/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libint10.la/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libint10.so/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libshadow.la/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libshadow.so/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libshadowfb.la/", 0xbfd28020) = -1 ENOTDIR (Not a directory) stat64("/usr/local/lib/xorg/modules/libshadowfb.so/", 0xbfd28020) = -1 ENOTDIR (Not a directory) close(12) = 0 write(0, "(II) Loading /usr/local/lib/xorg"..., 56) = 56 open("/usr/local/lib/xorg/modules/libshadowfb.so", O_RDONLY) = 12 read(12, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\7\0"..., 512) = 512 fstat64(12, {st_mode=S_IFREG|0755, st_size=81710, ...}) = 0 mmap2(NULL, 26964, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 12, 0) = 0x40394000 mmap2(0x4039a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 12, 0x5) = 0x4039a000 close(12) = 0 write(0, "(II) Module shadowfb: vendor=\"X."..., 48) = 48 write(0, "\tcompiled for 1.7.5", 19) = 19 write(0, ", module version = 1.0.0\n", 25) = 25 write(0, "\tABI class: X.Org ANSI C Emulati"..., 48) = 48 write(0, "(--) Depth 24 pixmap format is 3"..., 38) = 38 write(10, "target PCI:0000:01:00.0", 23) = 23 read(10, "count:1,PCI:0000:01:00.0,decodes"..., 64) = 64 ioctl(11, 0xc0586442, 0x92f65b4) = 0 ioctl(11, 0xc0286484, 0xbfd2a210) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 11, 0x10075d) = 0x4000d000 ioctl(11, 0x40086482, 0xbfd2a1d0) = 0 ioctl(11, 0x400c6444, 0xbfd2a230) = 0 ioctl(11, 0xc0406481, 0xbfd2a200) = 0 ioctl(11, 0xc0306480, 0xbfd2a120) = 0 ioctl(11, 0xc0306480, 0xbfd2a120) = 0 ioctl(11, 0xc0306480, 0xbfd2a120) = 0 ioctl(11, 0xc0306480, 0xbfd2a120) = 0 mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_SHARED, 11, 0x100762) = 0x4039b000 ioctl(11, 0x40086482, 0xbfd2a100) = 0 ioctl(11, 0x40046483, 0xbfd2a17c) = 0 brk(0x9324000) = 0x9324000 write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 ioctl(11, 0xc0106445, 0x930a908) = 0 ioctl(11, 0x400c6444, 0xbfd2a210) = 0 +++ killed by SIGKILL +++ [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-16 16:40 ` Michael D Labriola @ 2010-03-16 17:21 ` Konrad Rzeszutek Wilk 2010-03-16 19:39 ` Michael D Labriola 0 siblings, 1 reply; 39+ messages in thread From: Konrad Rzeszutek Wilk @ 2010-03-16 17:21 UTC (permalink / raw) To: Michael D Labriola Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, xen-devel-bounces > > > And my X log ends abruptly after this line: > > > (II) NOUVEAU(0): Opened GPU Channel 1 > > > > > > Any ideas? > > > > > > > Well, this is generally the symptom that someone is confusing mfns and > > pfns, and therefore ends up incorrectly setting the _PAGE_IO flag in > > some pte. If you run it under strace, can you identify which mapping > > the fault is happening in? > > I've attached the output of 'strace -o strace-Xorg Xorg'. Figuring out > which mapping the fault is happening in is a little over my head, I'm > afraid. If you need different arguments to strace, let me know and I'll > do it again. So just to be sure, you took the 2.6.32 (xen/next or xen/stable-2.6.32.x), copied the include and nouveu directory from ..? 2.6.33? and then ran this. Did you have to edit your xorg.conf file or it ran just fine? Was this Fedora 13 or Fedora 12? Arvind explanation about the Nvidia driver pointed out that the NVidia driver (drm/nouvue) can operate on different channels. Where channel 1 is the framebuffer, and the other are for well, KMS, and other applications. I belive I was looking at the wrong section of the drivers (not the drivers/video/gpu ones)- this certainly looks to be the issues the Jeremy mentioned. Also I would suggest you load drm with the debug variable set to the 255 to get most of what his happening. Based on your strace, the last call is: 4000) = 0x9324000 write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 ioctl(11, 0xc0106445, 0x930a908) = 0 ioctl(11, 0x400c6444, 0xbfd2a210) = 0 +++ killed by SIGKILL +++ I cannot find what 0x45 is in the upstream Linux, so you must be using a different nouv* driver than that. The 0x44 is: DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, DRM_AUTH), Which looks to be pretty harmless. I presume it is the next thing (using the address returned) that the X driver tries to do that makes it go boom. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-16 17:21 ` Konrad Rzeszutek Wilk @ 2010-03-16 19:39 ` Michael D Labriola 2010-03-16 19:41 ` Konrad Rzeszutek Wilk 2010-03-18 6:09 ` Arvind R 0 siblings, 2 replies; 39+ messages in thread From: Michael D Labriola @ 2010-03-16 19:39 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, xen-devel-bounces Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on 03/16/2010 01:21:35 PM: > > > > And my X log ends abruptly after this line: > > > > (II) NOUVEAU(0): Opened GPU Channel 1 > > > > > > > > Any ideas? > > > > > > > > > > Well, this is generally the symptom that someone is confusing mfns and > > > pfns, and therefore ends up incorrectly setting the _PAGE_IO flag in > > > some pte. If you run it under strace, can you identify which mapping > > > the fault is happening in? > > > > I've attached the output of 'strace -o strace-Xorg Xorg'. Figuring out > > which mapping the fault is happening in is a little over my head, I'm > > afraid. If you need different arguments to strace, let me know and I'll > > do it again. > > So just to be sure, you took the 2.6.32 (xen/next or > xen/stable-2.6.32.x), copied the include and nouveu directory from ..? > 2.6.33? and then ran this. I actually took a slightly more sadistic route than Arvind... ;-) A while back, I backported the important stuff from the Nouveau kernel git tree back to v2.6.31. Basically guessed at which commits were important, wrote a script to cherry pick each and every one, and spent an entire day reading commit logs, resolving conflicts, and figuring out which other non-drm commits I needed. Sounds retarded, I know, but it was a pretty interesting way to get myself up to speed with the code base. The resulting 2.6.31-nouveau kernel runs like a champ on all my hardware. Then I merged that into my clone of Jeremy's xen/master which I use with Xen 3.4.2. Since then, I've been periodically cherry picking all new commits off the nouveau tree. Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, new libdrm, mesa, and xf86-video-nouveau all from their respective git trees as of yesterday. (drm and xf86-video-nouveau are on their master branches, mesa is on the 7.8 branch) This all works great using xen/master bare metal. It used to work fine on my old GeForce2 MX based systems in Xen. Arvind's patch made it work on my nice new systems in Xen, but broke it on the old ones. Everything still works fine bare metal. > Did you have to edit your xorg.conf file or > it ran just fine? Well, I had to create an xorg.conf that looks like this: Section "Device" Identifier "foo" Driver "nouveau" EndSection Otherwise it uses the 'nv' driver... and I haven't stumbled onto how to get nouveau to automatically get used (aside from uninstalling the nv driver). > Was this Fedora 13 or Fedora 12? This is all being done on a custom 32bit Linux distro that we use for our tightly configuration controlled system deliveries. It was fedora based a looooooooong time ago (FC5), but is completely unrecognizable now. > Arvind explanation about the Nvidia driver pointed out that the NVidia > driver (drm/nouvue) can operate on different channels. Where channel 1 > is the framebuffer, and the other are for well, KMS, and other > applications. > > I belive I was looking at the wrong section of the drivers (not the > drivers/video/gpu ones)- this certainly looks to be the issues the > Jeremy mentioned. > > Also I would suggest you load drm with the debug variable set to the 255 > to get most of what his happening. I'll try that. > Based on your strace, the last call is: > 4000) = 0x9324000 > write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 > ioctl(11, 0xc0106445, 0x930a908) = 0 > ioctl(11, 0x400c6444, 0xbfd2a210) = 0 > +++ killed by SIGKILL +++ > > I cannot find what 0x45 is in the upstream Linux, so you must be using a > different nouv* driver than that. The 0x44 is: > > DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, DRM_AUTH), > > Which looks to be pretty harmless. I presume it is the next thing (using > the address returned) that the X driver tries to do that makes it go boom. I've never used strace before... how do you map between the ioctl definitions and the hex addresses? --- Michael D Labriola Electric Boat mlabriol@gdeb.com 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-16 19:39 ` Michael D Labriola @ 2010-03-16 19:41 ` Konrad Rzeszutek Wilk 2010-03-17 1:01 ` Konrad Rzeszutek Wilk 2010-03-18 6:09 ` Arvind R 1 sibling, 1 reply; 39+ messages in thread From: Konrad Rzeszutek Wilk @ 2010-03-16 19:41 UTC (permalink / raw) To: Michael D Labriola Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, xen-devel-bounces > > So just to be sure, you took the 2.6.32 (xen/next or > > xen/stable-2.6.32.x), copied the include and nouveu directory from ..? > > 2.6.33? and then ran this. > > I actually took a slightly more sadistic route than Arvind... ;-) A while > back, I backported the important stuff from the Nouveau kernel git tree > back to v2.6.31. Basically guessed at which commits were important, wrote > a script to cherry pick each and every one, and spent an entire day > reading commit logs, resolving conflicts, and figuring out which other > non-drm commits I needed. Sounds retarded, I know, but it was a pretty > interesting way to get myself up to speed with the code base. The > resulting 2.6.31-nouveau kernel runs like a champ on all my hardware. That is ambitious. > > Then I merged that into my clone of Jeremy's xen/master which I use with > Xen 3.4.2. > > Since then, I've been periodically cherry picking all new commits off the > nouveau tree. Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, new > libdrm, mesa, and xf86-video-nouveau all from their respective git trees > as of yesterday. (drm and xf86-video-nouveau are on their master > branches, mesa is on the 7.8 branch) > > This all works great using xen/master bare metal. It used to work fine on > my old GeForce2 MX based systems in Xen. Arvind's patch made it work on > my nice new systems in Xen, but broke it on the old ones. Everything > still works fine bare metal. > > > Did you have to edit your xorg.conf file or > > it ran just fine? > > Well, I had to create an xorg.conf that looks like this: > > Section "Device" > Identifier "foo" > Driver "nouveau" > EndSection > > Otherwise it uses the 'nv' driver... and I haven't stumbled onto how to > get nouveau to automatically get used (aside from uninstalling the nv > driver). > > > > Was this Fedora 13 or Fedora 12? > > This is all being done on a custom 32bit Linux distro that we use for our > tightly configuration controlled system deliveries. It was fedora based a > looooooooong time ago (FC5), but is completely unrecognizable now. Ah, so it is 32-bit, not 64-bit. > > > > Arvind explanation about the Nvidia driver pointed out that the NVidia > > driver (drm/nouvue) can operate on different channels. Where channel 1 > > is the framebuffer, and the other are for well, KMS, and other > > applications. > > > > I belive I was looking at the wrong section of the drivers (not the > > drivers/video/gpu ones)- this certainly looks to be the issues the > > Jeremy mentioned. > > > > Also I would suggest you load drm with the debug variable set to the 255 > > to get most of what his happening. > > I'll try that. > > > > Based on your strace, the last call is: > > 4000) = 0x9324000 > > write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 > > ioctl(11, 0xc0106445, 0x930a908) = 0 > > ioctl(11, 0x400c6444, 0xbfd2a210) = 0 > > +++ killed by SIGKILL +++ > > > > I cannot find what 0x45 is in the upstream Linux, so you must be using a > > different nouv* driver than that. The 0x44 is: > > > > DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, DRM_AUTH), > > > > Which looks to be pretty harmless. I presume it is the next thing (using > > the address returned) that the X driver tries to do that makes it go > boom. > > I've never used strace before... how do you map between the ioctl > definitions and the hex addresses? The IOCTL numbers are generated by this macro: #define DRM_IOCTL_BASE 'd' #define DRM_IO(nr) _IO(DRM_IOCTL_BASE,nr) #define _IOC(dir,type,nr,size) \ (((dir) << _IOC_DIRSHIFT) | \ ((type) << _IOC_TYPESHIFT) | \ ((nr) << _IOC_NRSHIFT) | \ ((size) << _IOC_SIZESHIFT)) #define _IO(type,nr) _IOC(_IOC_NONE,(type),(nr),0) and the values are: _IOC_NRSHIFT = 0 _IOC_TYPESHIFT = 8 _IOC_SIZESHIFT = 16 _IOC_DIRSHIFT = 30 Which basically translates that the 0 through 8 bits are the 'nr' (0x44), 8 throught 16 are the 'type' (which is the letter 'd'), and the 16 through 30 is the size of the structure, and the last two bits are for direction, which in this case is the value '0'. At least that is what I think it translates too. Now I am not certain anymore.. > > > --- > Michael D Labriola > Electric Boat > mlabriol@gdeb.com > 401-848-8871 (desk) > 401-848-8513 (lab) > 401-316-9844 (cell) > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-16 19:41 ` Konrad Rzeszutek Wilk @ 2010-03-17 1:01 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 39+ messages in thread From: Konrad Rzeszutek Wilk @ 2010-03-17 1:01 UTC (permalink / raw) To: Michael D Labriola Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, xen-devel-bounces [-- Attachment #1: Type: text/plain, Size: 306 bytes --] > > > Also I would suggest you load drm with the debug variable set to the 255 > > > to get most of what his happening. > > > > I'll try that. > > You can also use the attached debug patch and re-jigger it to be in the nouveau functions that cause this failure. It isn't compile tested so be careful. [-- Attachment #2: debug-print-pte-ttm-2.patch --] [-- Type: text/plain, Size: 4393 bytes --] diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 668dbe8..d62b72e 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -35,6 +35,10 @@ #include <linux/rbtree.h> #include <linux/module.h> #include <linux/uaccess.h> +#include <asm/page.h> +#include <asm/pgtable_types.h> +#include <asm/xen/page.h> + #define TTM_BO_VM_NUM_PREFAULT 16 @@ -69,6 +73,142 @@ static struct ttm_buffer_object *ttm_bo_vm_lookup_rb(struct ttm_bo_device *bdev, return best_bo; } +void print_pte(struct vm_area_struct *vma, char *what, struct page *page, unsigned int pfn, unsigned long address) +{ + static const char * const level_name[] = + { "NONE", "4K", "2M", "1G", "NUM" }; + unsigned long addr = 0; + pte_t *pte = NULL; + pteval_t val = (pteval_t)0; + unsigned int level = 0; + unsigned offset; + unsigned long phys; + pgprotval_t prot; + char buf[90]; + char *str; + + str = buf; + // Figure out if the address is pagetable. + if (address == 0 && !page && pfn>0) { + page = pfn_to_page(pfn); + } + if (address == 0 && page) + addr = (u64)page_address(page); + + if (address && !page) + addr = address; + + if (address && page) { + addr = (u64)page_address(page); + if (address != addr) { + if (addr == 0) { + str += sprintf(str, "addr(page)==0"); + addr = address; + } + } + } + + if (pfn != 0 && page) { + if (pfn != page_to_pfn(page)) // Gosh!? + str += sprintf(str, "pfn!=pfn(page)"); + } + if (pfn != 0 && addr != 0) { + if (pfn != virt_to_pfn(addr)) + str += sprintf(str,"pfn(addr)!=pfn"); + } + pte = lookup_address(addr, &level); + if (!pte) { + str += sprintf(str,"!pte(addr)"); + goto print; + } + offset = addr & ~PAGE_MASK; + + if (xen_domain()) { + phys = (pte_mfn(*pte) << PAGE_SHIFT) + offset; + val = pte_val_ma(*pte); + + if (pfn > 0) { + if (pte_mfn(*pte) == pfn) { + if (vma->vm_flags && VM_IO) + str += sprintf(str,"PHYS"); + else + str += sprintf(str,"BUG: VM_IO not set!"); + } + /* It is a pseudo page ... and the VM_IO flag is set */ + if (pte_mfn(*pte) != pfn) { + if (vma->vm_flags && VM_IO) + str += sprintf(str,"BUG: VM_IO flag set!"); + else + str += sprintf(str, "PSEUDO"); + } + } else { + str += sprintf(str,"pfn==0"); + } + + } else { + phys = (pte_pfn(*pte) << PAGE_SHIFT) + offset; + val = pte_val(*pte); + } + prot = pgprot_val(pte_pgprot(*pte)); + + if (!prot) + str += sprintf(str, "Not present."); + else { + if (prot & _PAGE_USER) + str += sprintf(str, "USR "); + else + str += sprintf(str, " "); + if (prot & _PAGE_RW) + str += sprintf(str, "RW "); + else + str += sprintf(str, "ro "); + if (prot & _PAGE_PWT) + str += sprintf(str, "PWT "); + else + str += sprintf(str, " "); + if (prot & _PAGE_PCD) + str += sprintf(str, "PCD "); + else + str += sprintf(str, " "); + + /* Bit 9 has a different meaning on level 3 vs 4 */ + if (level <= 3) { + if (prot & _PAGE_PSE) + str += sprintf(str, "PSE "); + else + str += sprintf(str, " "); + } else { + if (prot & _PAGE_PAT) + str += sprintf(str, "pat "); + else + str += sprintf(str, " "); + } + if (prot & _PAGE_GLOBAL) + str += sprintf(str, "GLB "); + else + str += sprintf(str, " "); + if (prot & _PAGE_NX) + str += sprintf(str, "NX "); + else + str += sprintf(str, "x "); +#ifdef _PAGE_IOMEM + if (prot & _PAGE_IOMEM) + str += sprintf(str, "IO "); + else + str += sprintf(str, " "); +#endif + + } + +print: + printk(KERN_INFO "[%16s]PFN: 0x%lx PTE: 0x%lx (val:%lx): [%s] [%s]\n", + what, + (unsigned long)pfn, + (pte) ? (unsigned long)(pte->pte) : 0, + (unsigned long)val, + buf, + level_name[level]); +} static int ttm_bo_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf) { struct ttm_buffer_object *bo = (struct ttm_buffer_object *) @@ -183,10 +323,12 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf) } else if (unlikely(!page)) { break; } - pfn = page_to_pfn(page); + pfn = page_to_pfn(page, pfn, 0); } - + printk(KERN_INFO "iomem?:%d\n", iomem); + print_pte(vma, "before", page, pfn, 0); ret = vm_insert_mixed(vma, address, pfn); + print_pte(vma, "after", page, pfn, address); /* * Somebody beat us to this PTE or prefaulting to * an already populated PTE, or prefaulting error. [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply related [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-16 19:39 ` Michael D Labriola 2010-03-16 19:41 ` Konrad Rzeszutek Wilk @ 2010-03-18 6:09 ` Arvind R 2010-03-19 15:29 ` Michael D Labriola 1 sibling, 1 reply; 39+ messages in thread From: Arvind R @ 2010-03-18 6:09 UTC (permalink / raw) To: Michael D Labriola Cc: xen-devel-bounces, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Konrad Rzeszutek Wilk On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola <mlabriol@gdeb.com> wrote: > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on 03/16/2010 > 01:21:35 PM: > >> > > > And my X log ends abruptly after this line: >> > > > (II) NOUVEAU(0): Opened GPU Channel 1 >> > > > >> > > > Any ideas? >> > > > >> > > >> > > Well, this is generally the symptom that someone is confusing mfns > and >> > > pfns, and therefore ends up incorrectly setting the _PAGE_IO flag in > >> > > some pte. If you run it under strace, can you identify which > mapping >> > > the fault is happening in? >> > >> > I've attached the output of 'strace -o strace-Xorg Xorg'. Figuring > out >> > which mapping the fault is happening in is a little over my head, I'm >> > afraid. If you need different arguments to strace, let me know and > I'll >> > do it again. >> >> So just to be sure, you took the 2.6.32 (xen/next or >> xen/stable-2.6.32.x), copied the include and nouveu directory from ..? >> 2.6.33? and then ran this. > > I actually took a slightly more sadistic route than Arvind... ;-) A while > back, I backported the important stuff from the Nouveau kernel git tree > back to v2.6.31. Basically guessed at which commits were important, wrote > a script to cherry pick each and every one, and spent an entire day > reading commit logs, resolving conflicts, and figuring out which other > non-drm commits I needed. Sounds retarded, I know, but it was a pretty > interesting way to get myself up to speed with the code base. The > resulting 2.6.31-nouveau kernel runs like a champ on all my hardware. > > Then I merged that into my clone of Jeremy's xen/master which I use with > Xen 3.4.2. > > Since then, I've been periodically cherry picking all new commits off the > nouveau tree. Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, new > libdrm, mesa, and xf86-video-nouveau all from their respective git trees > as of yesterday. (drm and xf86-video-nouveau are on their master > branches, mesa is on the 7.8 branch) > > This all works great using xen/master bare metal. It used to work fine on > my old GeForce2 MX based systems in Xen. Arvind's patch made it work on > my nice new systems in Xen, but broke it on the old ones. Everything > still works fine bare metal. > >> Did you have to edit your xorg.conf file or >> it ran just fine? > > Well, I had to create an xorg.conf that looks like this: > > Section "Device" > Identifier "foo" > Driver "nouveau" > EndSection > > Otherwise it uses the 'nv' driver... and I haven't stumbled onto how to > get nouveau to automatically get used (aside from uninstalling the nv > driver). > > >> Was this Fedora 13 or Fedora 12? > > This is all being done on a custom 32bit Linux distro that we use for our > tightly configuration controlled system deliveries. It was fedora based a > looooooooong time ago (FC5), but is completely unrecognizable now. > > >> Arvind explanation about the Nvidia driver pointed out that the NVidia >> driver (drm/nouvue) can operate on different channels. Where channel 1 >> is the framebuffer, and the other are for well, KMS, and other >> applications. >> >> I belive I was looking at the wrong section of the drivers (not the >> drivers/video/gpu ones)- this certainly looks to be the issues the >> Jeremy mentioned. >> >> Also I would suggest you load drm with the debug variable set to the 255 >> to get most of what his happening. > > I'll try that. > > >> Based on your strace, the last call is: >> 4000) = 0x9324000 >> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 >> ioctl(11, 0xc0106445, 0x930a908) = 0 >> ioctl(11, 0x400c6444, 0xbfd2a210) = 0 >> +++ killed by SIGKILL +++ >> >> I cannot find what 0x45 is in the upstream Linux, so you must be using a >> different nouv* driver than that. The 0x44 is: >> >> DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, DRM_AUTH), >> >> Which looks to be pretty harmless. I presume it is the next thing (using >> the address returned) that the X driver tries to do that makes it go > boom. > I suspect that the ioctl is prior to a modeset operation. And the mode-setting is 'booming'. My kernel config has VGA console built-in fbcon as a module and I do a switch to nouveaufb at runlevel 2. Also note that the default modeset parameter is -1 and if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver initialisation - which maybe the problem. Do you have modeset=1 as module parameter? As to the implications of Thomas' remark on the possibility of placement migration 'tween mmap and fault; and the over-loading of VM_IO semantics; (points 1 and 2), - that seems to be a problem to be resolved. VM_MIXEDMAP would not be a problem if VM_IO semantics were consistent with Xen, I suspect. > I've never used strace before... how do you map between the ioctl > definitions and the hex addresses? > > > --- > Michael D Labriola > Electric Boat > mlabriol@gdeb.com > 401-848-8871 (desk) > 401-848-8513 (lab) > 401-316-9844 (cell) > > > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-18 6:09 ` Arvind R @ 2010-03-19 15:29 ` Michael D Labriola 2010-03-20 6:01 ` Arvind R 0 siblings, 1 reply; 39+ messages in thread From: Michael D Labriola @ 2010-03-19 15:29 UTC (permalink / raw) To: Arvind R Cc: xen-devel-bounces, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Konrad Rzeszutek Wilk xen-devel-bounces@lists.xensource.com wrote on 03/18/2010 02:09:08 AM: > On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola <mlabriol@gdeb.com> wrote: > > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on 03/16/2010 > > 01:21:35 PM: > > > >> > > > And my X log ends abruptly after this line: > >> > > > (II) NOUVEAU(0): Opened GPU Channel 1 > >> > > > > >> > > > Any ideas? > >> > > > > >> > > > >> > > Well, this is generally the symptom that someone is confusing mfns > > and > >> > > pfns, and therefore ends up incorrectly setting the _PAGE_IO flag in > > > >> > > some pte. If you run it under strace, can you identify which > > mapping > >> > > the fault is happening in? > >> > > >> > I've attached the output of 'strace -o strace-Xorg Xorg'. Figuring > > out > >> > which mapping the fault is happening in is a little over my head, I'm > >> > afraid. If you need different arguments to strace, let me know and > > I'll > >> > do it again. > >> > >> So just to be sure, you took the 2.6.32 (xen/next or > >> xen/stable-2.6.32.x), copied the include and nouveu directory from ..? > >> 2.6.33? and then ran this. > > > > I actually took a slightly more sadistic route than Arvind... ;-) A while > > back, I backported the important stuff from the Nouveau kernel git tree > > back to v2.6.31. Basically guessed at which commits were important, wrote > > a script to cherry pick each and every one, and spent an entire day > > reading commit logs, resolving conflicts, and figuring out which other > > non-drm commits I needed. Sounds retarded, I know, but it was a pretty > > interesting way to get myself up to speed with the code base. The > > resulting 2.6.31-nouveau kernel runs like a champ on all my hardware. > > > > Then I merged that into my clone of Jeremy's xen/master which I use with > > Xen 3.4.2. > > > > Since then, I've been periodically cherry picking all new commits off the > > nouveau tree. Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, new > > libdrm, mesa, and xf86-video-nouveau all from their respective git trees > > as of yesterday. (drm and xf86-video-nouveau are on their master > > branches, mesa is on the 7.8 branch) > > > > This all works great using xen/master bare metal. It used to work fine on > > my old GeForce2 MX based systems in Xen. Arvind's patch made it work on > > my nice new systems in Xen, but broke it on the old ones. Everything > > still works fine bare metal. > > > >> Did you have to edit your xorg.conf file or > >> it ran just fine? > > > > Well, I had to create an xorg.conf that looks like this: > > > > Section "Device" > > Identifier "foo" > > Driver "nouveau" > > EndSection > > > > Otherwise it uses the 'nv' driver... and I haven't stumbled onto how to > > get nouveau to automatically get used (aside from uninstalling the nv > > driver). > > > > > >> Was this Fedora 13 or Fedora 12? > > > > This is all being done on a custom 32bit Linux distro that we use for our > > tightly configuration controlled system deliveries. It was fedora based a > > looooooooong time ago (FC5), but is completely unrecognizable now. > > > > > >> Arvind explanation about the Nvidia driver pointed out that the NVidia > >> driver (drm/nouvue) can operate on different channels. Where channel 1 > >> is the framebuffer, and the other are for well, KMS, and other > >> applications. > >> > >> I belive I was looking at the wrong section of the drivers (not the > >> drivers/video/gpu ones)- this certainly looks to be the issues the > >> Jeremy mentioned. > >> > >> Also I would suggest you load drm with the debug variable set to the 255 > >> to get most of what his happening. > > > > I'll try that. > > > > > >> Based on your strace, the last call is: > >> 4000) = 0x9324000 > >> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 > >> ioctl(11, 0xc0106445, 0x930a908) = 0 > >> ioctl(11, 0x400c6444, 0xbfd2a210) = 0 > >> +++ killed by SIGKILL +++ > >> > >> I cannot find what 0x45 is in the upstream Linux, so you must be using a > >> different nouv* driver than that. The 0x44 is: > >> > >> DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, DRM_AUTH), > >> > >> Which looks to be pretty harmless. I presume it is the next thing (using > >> the address returned) that the X driver tries to do that makes it go > > boom. > > > I suspect that the ioctl is prior to a modeset operation. And the > mode-setting is 'booming'. > My kernel config has VGA console built-in fbcon as a module and I do > a switch to > nouveaufb at runlevel 2. Also note that the default modeset > parameter is -1 and > if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver > initialisation > - which maybe the problem. Do you have modeset=1 as module parameter? I wasn't setting any module params for nouveau. Adding 'options nouveau modeset=1' to modprobe.conf didn't seem to make any difference. I've got the following in my .config: CONFIG_VGA_CONSOLE=y CONFIG_FB=y CONFIG_FB_VGA16=m CONFIG_FB_VESA=y CONFIG_FB_EFI=y CONFIG_FB_NVIDIA=m CONFIG_FB_NVIDIA_I2C=y CONFIG_FB_NVIDIA_BACKLIGHT=y Gonna go comb through the config options and see if anything else looks relevant. How do you force the nouveaufb switch at runlevel 2? My screen obviously switches into KMS mode while udev is starting up. -Mike --- Michael D Labriola Electric Boat mlabriol@gdeb.com 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-19 15:29 ` Michael D Labriola @ 2010-03-20 6:01 ` Arvind R 2010-03-22 21:14 ` Michael D Labriola 0 siblings, 1 reply; 39+ messages in thread From: Arvind R @ 2010-03-20 6:01 UTC (permalink / raw) To: Michael D Labriola Cc: xen-devel-bounces, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Konrad Rzeszutek Wilk On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola <mlabriol@gdeb.com> wrote: > xen-devel-bounces@lists.xensource.com wrote on 03/18/2010 02:09:08 AM: > >> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola <mlabriol@gdeb.com> > wrote: >> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on 03/16/2010 >> > 01:21:35 PM: >> > >> >> > > > And my X log ends abruptly after this line: >> >> > > > (II) NOUVEAU(0): Opened GPU Channel 1 >> >> > > > >> >> > > > Any ideas? >> >> > > > >> >> > > >> >> > > Well, this is generally the symptom that someone is confusing > mfns >> > and >> >> > > pfns, and therefore ends up incorrectly setting the _PAGE_IO flag > in >> > >> >> > > some pte. If you run it under strace, can you identify which >> > mapping >> >> > > the fault is happening in? >> >> > >> >> > I've attached the output of 'strace -o strace-Xorg Xorg'. Figuring >> > out >> >> > which mapping the fault is happening in is a little over my head, > I'm >> >> > afraid. If you need different arguments to strace, let me know and >> > I'll >> >> > do it again. >> >> >> >> So just to be sure, you took the 2.6.32 (xen/next or >> >> xen/stable-2.6.32.x), copied the include and nouveu directory from > ..? >> >> 2.6.33? and then ran this. >> > >> > I actually took a slightly more sadistic route than Arvind... ;-) A > while >> > back, I backported the important stuff from the Nouveau kernel git > tree >> > back to v2.6.31. Basically guessed at which commits were important, > wrote >> > a script to cherry pick each and every one, and spent an entire day >> > reading commit logs, resolving conflicts, and figuring out which other >> > non-drm commits I needed. Sounds retarded, I know, but it was a > pretty >> > interesting way to get myself up to speed with the code base. The >> > resulting 2.6.31-nouveau kernel runs like a champ on all my hardware. >> > >> > Then I merged that into my clone of Jeremy's xen/master which I use > with >> > Xen 3.4.2. >> > >> > Since then, I've been periodically cherry picking all new commits off > the >> > nouveau tree. Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, > new >> > libdrm, mesa, and xf86-video-nouveau all from their respective git > trees >> > as of yesterday. (drm and xf86-video-nouveau are on their master >> > branches, mesa is on the 7.8 branch) >> > >> > This all works great using xen/master bare metal. It used to work > fine on >> > my old GeForce2 MX based systems in Xen. Arvind's patch made it work > on >> > my nice new systems in Xen, but broke it on the old ones. Everything >> > still works fine bare metal. >> > >> >> Did you have to edit your xorg.conf file or >> >> it ran just fine? >> > >> > Well, I had to create an xorg.conf that looks like this: >> > >> > Section "Device" >> > Identifier "foo" >> > Driver "nouveau" >> > EndSection >> > >> > Otherwise it uses the 'nv' driver... and I haven't stumbled onto how > to >> > get nouveau to automatically get used (aside from uninstalling the nv >> > driver). >> > >> > >> >> Was this Fedora 13 or Fedora 12? >> > >> > This is all being done on a custom 32bit Linux distro that we use for > our >> > tightly configuration controlled system deliveries. It was fedora > based a >> > looooooooong time ago (FC5), but is completely unrecognizable now. >> > >> > >> >> Arvind explanation about the Nvidia driver pointed out that the > NVidia >> >> driver (drm/nouvue) can operate on different channels. Where channel > 1 >> >> is the framebuffer, and the other are for well, KMS, and other >> >> applications. >> >> >> >> I belive I was looking at the wrong section of the drivers (not the >> >> drivers/video/gpu ones)- this certainly looks to be the issues the >> >> Jeremy mentioned. >> >> >> >> Also I would suggest you load drm with the debug variable set to the > 255 >> >> to get most of what his happening. >> > >> > I'll try that. >> > >> > >> >> Based on your strace, the last call is: >> >> 4000) = 0x9324000 >> >> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 >> >> ioctl(11, 0xc0106445, 0x930a908) = 0 >> >> ioctl(11, 0x400c6444, 0xbfd2a210) = 0 >> >> +++ killed by SIGKILL +++ >> >> >> >> I cannot find what 0x45 is in the upstream Linux, so you must be > using a >> >> different nouv* driver than that. The 0x44 is: >> >> >> >> DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, > DRM_AUTH), >> >> >> >> Which looks to be pretty harmless. I presume it is the next thing > (using >> >> the address returned) that the X driver tries to do that makes it go >> > boom. >> > >> I suspect that the ioctl is prior to a modeset operation. And the >> mode-setting is 'booming'. >> My kernel config has VGA console built-in fbcon as a module and I do >> a switch to >> nouveaufb at runlevel 2. Also note that the default modeset >> parameter is -1 and >> if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver >> initialisation >> - which maybe the problem. Do you have modeset=1 as module parameter? > > I wasn't setting any module params for nouveau. Adding 'options nouveau > modeset=1' to modprobe.conf didn't seem to make any difference. > > I've got the following in my .config: > > CONFIG_VGA_CONSOLE=y > CONFIG_FB=y > CONFIG_FB_VGA16=m > CONFIG_FB_VESA=y > CONFIG_FB_EFI=y > CONFIG_FB_NVIDIA=m > CONFIG_FB_NVIDIA_I2C=y > CONFIG_FB_NVIDIA_BACKLIGHT=y > - EMBEDDED - this will enable VGA_CONSOLE selection. Set sub-menu choices as needed - VGA_CONSOLE builtin - FB as module - FRAMEBUFFER_CONSOLE as a module. Enables late loading of nouveau * Foll. required to avoid cfb_copyarea, cfb_fillrectangle, cfb_imageblit linking problems with out-of-tree nouveau builds - FB_VGA16 as module - supported by all nVidia cards. or - FB_NVIDIA as module - only works for older cards. For out-of-tree nouveau builds, DO NOT select ANY accelerated drivers - that would enable the old in-tree DRM. New TTM / DRM modulesare in the new driver/gpu tree. For in-tree builds, if nouveau is NOT in the initrd-image, system will boot on vga console > > How do you force the nouveaufb switch at runlevel 2? My screen obviously > switches into KMS mode while udev is starting up. You can switch to the accelerated framebuffer console by modprobe nouveau modprobe fbcon fbcon will take-over console from the built-in VGA. See Documenation/fb/fbcon.txt If multiple fb loaded, echo 0/1 to /sys/devices/virtual/vtconsole/vtconX/bind to unbind/bind fbs and switch - if it is possible (or leave you without a console) If the old nvidiafb is loaded, nouveau cannot install (and vice-versa) BTW, are you sure 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. Late switching will maybe enable you to get traces ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-20 6:01 ` Arvind R @ 2010-03-22 21:14 ` Michael D Labriola 2010-03-23 6:21 ` Arvind R 0 siblings, 1 reply; 39+ messages in thread From: Michael D Labriola @ 2010-03-22 21:14 UTC (permalink / raw) To: Arvind R Cc: xen-devel-bounces, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Konrad Rzeszutek Wilk xen-devel-bounces@lists.xensource.com wrote on 03/20/2010 02:01:54 AM: > On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola <mlabriol@gdeb.com> wrote: > > xen-devel-bounces@lists.xensource.com wrote on 03/18/2010 02:09:08 AM: > > > >> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola <mlabriol@gdeb.com> > > wrote: > >> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on 03/16/2010 > >> > 01:21:35 PM: > >> > > >> >> > > > And my X log ends abruptly after this line: > >> >> > > > (II) NOUVEAU(0): Opened GPU Channel 1 > >> >> > > > > >> >> > > > Any ideas? > >> >> > > > > >> >> > > > >> >> > > Well, this is generally the symptom that someone is confusing > > mfns > >> > and > >> >> > > pfns, and therefore ends up incorrectly setting the _PAGE_IO flag > > in > >> > > >> >> > > some pte. If you run it under strace, can you identify which > >> > mapping > >> >> > > the fault is happening in? > >> >> > > >> >> > I've attached the output of 'strace -o strace-Xorg Xorg'. Figuring > >> > out > >> >> > which mapping the fault is happening in is a little over my head, > > I'm > >> >> > afraid. If you need different arguments to strace, let me know and > >> > I'll > >> >> > do it again. > >> >> > >> >> So just to be sure, you took the 2.6.32 (xen/next or > >> >> xen/stable-2.6.32.x), copied the include and nouveu directory from > > ..? > >> >> 2.6.33? and then ran this. > >> > > >> > I actually took a slightly more sadistic route than Arvind... ;-) A > > while > >> > back, I backported the important stuff from the Nouveau kernel git > > tree > >> > back to v2.6.31. Basically guessed at which commits were important, > > wrote > >> > a script to cherry pick each and every one, and spent an entire day > >> > reading commit logs, resolving conflicts, and figuring out which other > >> > non-drm commits I needed. Sounds retarded, I know, but it was a > > pretty > >> > interesting way to get myself up to speed with the code base. The > >> > resulting 2.6.31-nouveau kernel runs like a champ on all my hardware. > >> > > >> > Then I merged that into my clone of Jeremy's xen/master which I use > > with > >> > Xen 3.4.2. > >> > > >> > Since then, I've been periodically cherry picking all new commits off > > the > >> > nouveau tree. Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, > > new > >> > libdrm, mesa, and xf86-video-nouveau all from their respective git > > trees > >> > as of yesterday. (drm and xf86-video-nouveau are on their master > >> > branches, mesa is on the 7.8 branch) > >> > > >> > This all works great using xen/master bare metal. It used to work > > fine on > >> > my old GeForce2 MX based systems in Xen. Arvind's patch made it work > > on > >> > my nice new systems in Xen, but broke it on the old ones. Everything > >> > still works fine bare metal. > >> > > >> >> Did you have to edit your xorg.conf file or > >> >> it ran just fine? > >> > > >> > Well, I had to create an xorg.conf that looks like this: > >> > > >> > Section "Device" > >> > Identifier "foo" > >> > Driver "nouveau" > >> > EndSection > >> > > >> > Otherwise it uses the 'nv' driver... and I haven't stumbled onto how > > to > >> > get nouveau to automatically get used (aside from uninstalling the nv > >> > driver). > >> > > >> > > >> >> Was this Fedora 13 or Fedora 12? > >> > > >> > This is all being done on a custom 32bit Linux distro that we use for > > our > >> > tightly configuration controlled system deliveries. It was fedora > > based a > >> > looooooooong time ago (FC5), but is completely unrecognizable now. > >> > > >> > > >> >> Arvind explanation about the Nvidia driver pointed out that the > > NVidia > >> >> driver (drm/nouvue) can operate on different channels. Where channel > > 1 > >> >> is the framebuffer, and the other are for well, KMS, and other > >> >> applications. > >> >> > >> >> I belive I was looking at the wrong section of the drivers (not the > >> >> drivers/video/gpu ones)- this certainly looks to be the issues the > >> >> Jeremy mentioned. > >> >> > >> >> Also I would suggest you load drm with the debug variable set to the > > 255 > >> >> to get most of what his happening. > >> > > >> > I'll try that. > >> > > >> > > >> >> Based on your strace, the last call is: > >> >> 4000) = 0x9324000 > >> >> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 > >> >> ioctl(11, 0xc0106445, 0x930a908) = 0 > >> >> ioctl(11, 0x400c6444, 0xbfd2a210) = 0 > >> >> +++ killed by SIGKILL +++ > >> >> > >> >> I cannot find what 0x45 is in the upstream Linux, so you must be > > using a > >> >> different nouv* driver than that. The 0x44 is: > >> >> > >> >> DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, > > DRM_AUTH), > >> >> > >> >> Which looks to be pretty harmless. I presume it is the next thing > > (using > >> >> the address returned) that the X driver tries to do that makes it go > >> > boom. > >> > > >> I suspect that the ioctl is prior to a modeset operation. And the > >> mode-setting is 'booming'. > >> My kernel config has VGA console built-in fbcon as a module and I do > >> a switch to > >> nouveaufb at runlevel 2. Also note that the default modeset > >> parameter is -1 and > >> if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver > >> initialisation > >> - which maybe the problem. Do you have modeset=1 as module parameter? > > > > I wasn't setting any module params for nouveau. Adding 'options nouveau > > modeset=1' to modprobe.conf didn't seem to make any difference. > > > > I've got the following in my .config: > > > > CONFIG_VGA_CONSOLE=y > > CONFIG_FB=y > > CONFIG_FB_VGA16=m > > CONFIG_FB_VESA=y > > CONFIG_FB_EFI=y > > CONFIG_FB_NVIDIA=m > > CONFIG_FB_NVIDIA_I2C=y > > CONFIG_FB_NVIDIA_BACKLIGHT=y > > > - EMBEDDED - this will enable VGA_CONSOLE selection. Set sub-menu > choices as needed > - VGA_CONSOLE builtin > - FB as module > - FRAMEBUFFER_CONSOLE as a module. Enables late loading of nouveau > * Foll. required to avoid cfb_copyarea, cfb_fillrectangle, > cfb_imageblit linking problems with > out-of-tree nouveau builds > - FB_VGA16 as module - supported by all nVidia cards. > or > - FB_NVIDIA as module - only works for older cards. > > For out-of-tree nouveau builds, DO NOT select ANY accelerated drivers > - that would enable > the old in-tree DRM. New TTM / DRM modulesare in the new driver/gpu tree. > > For in-tree builds, if nouveau is NOT in the initrd-image, system will > boot on vga console > > > > How do you force the nouveaufb switch at runlevel 2? My screen obviously > > switches into KMS mode while udev is starting up. > You can switch to the accelerated framebuffer console by > modprobe nouveau > modprobe fbcon > fbcon will take-over console from the built-in VGA. See > Documenation/fb/fbcon.txt Ok, thanks. Now I've got everything compiled as modules and can load them post-boot to switch to the nouveau framebuffer console. That actually didn't change the X behavior at all, though. I still get the exact same "X: Corrupted page table" messages in dmesg and my Xorg.log is just ending with "NOUVEAU(0): Opened GPU channel 1". > If multiple fb loaded, echo 0/1 to /sys/devices/virtual/vtconsole/vtconX/bind > to unbind/bind fbs and switch - if it is possible (or leave you > without a console) > > If the old nvidiafb is loaded, nouveau cannot install (and vice-versa) Well, everything seems to load just fine. I get a nice teeny font and dmesg messages saying I'm using nouveaufb. > BTW, are you sure 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? Which accelerated modes are you refering to? My understanding was that the old GeForce2 cards should work for nouveaufb, the 2d xf86-nouveau driver, and gallium's swrast_dri stuff (via AIGLX), but not gallium's new dri_nouveau stuff. > 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. Now that's strange. Every single one of my boxes says Opened Channel 1, with now reference to channel 2 at all. > Late switching will maybe enable you to get traces After switching post-boot, Xorg.log is still just ending. I get errors in dmesg, but nothing at all in Xorg.log. Same exact behavior as before. --- Michael D Labriola Electric Boat mlabriol@gdeb.com 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-22 21:14 ` Michael D Labriola @ 2010-03-23 6:21 ` Arvind R 2010-03-23 12:45 ` Michael D Labriola 2010-03-23 13:27 ` Michael D Labriola 0 siblings, 2 replies; 39+ messages in thread From: Arvind R @ 2010-03-23 6:21 UTC (permalink / raw) To: Michael D Labriola Cc: xen-devel-bounces, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Konrad Rzeszutek Wilk [-- Attachment #1: Type: text/plain, Size: 10487 bytes --] On Tue, Mar 23, 2010 at 2:44 AM, Michael D Labriola <mlabriol@gdeb.com> wrote: > xen-devel-bounces@lists.xensource.com wrote on 03/20/2010 02:01:54 AM: > >> On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola <mlabriol@gdeb.com> > wrote: >> > xen-devel-bounces@lists.xensource.com wrote on 03/18/2010 02:09:08 AM: >> > >> >> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola > <mlabriol@gdeb.com> >> > wrote: >> >> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on 03/16/2010 >> >> > 01:21:35 PM: >> >> > >> >> >> > > > And my X log ends abruptly after this line: >> >> >> > > > (II) NOUVEAU(0): Opened GPU Channel 1 >> >> >> > > > >> >> >> > > > Any ideas? >> >> >> > > > >> >> >> > > >> >> >> > > Well, this is generally the symptom that someone is confusing >> > mfns >> >> > and >> >> >> > > pfns, and therefore ends up incorrectly setting the _PAGE_IO > flag >> > in >> >> > >> >> >> > > some pte. If you run it under strace, can you identify which >> >> > mapping >> >> >> > > the fault is happening in? >> >> >> > >> >> >> > I've attached the output of 'strace -o strace-Xorg Xorg'. > Figuring >> >> > out >> >> >> > which mapping the fault is happening in is a little over my > head, >> > I'm >> >> >> > afraid. If you need different arguments to strace, let me know > and >> >> > I'll >> >> >> > do it again. >> >> >> >> >> >> So just to be sure, you took the 2.6.32 (xen/next or >> >> >> xen/stable-2.6.32.x), copied the include and nouveu directory from >> > ..? >> >> >> 2.6.33? and then ran this. >> >> > >> >> > I actually took a slightly more sadistic route than Arvind... ;-) > A >> > while >> >> > back, I backported the important stuff from the Nouveau kernel git >> > tree >> >> > back to v2.6.31. Basically guessed at which commits were > important, >> > wrote >> >> > a script to cherry pick each and every one, and spent an entire day >> >> > reading commit logs, resolving conflicts, and figuring out which > other >> >> > non-drm commits I needed. Sounds retarded, I know, but it was a >> > pretty >> >> > interesting way to get myself up to speed with the code base. The >> >> > resulting 2.6.31-nouveau kernel runs like a champ on all my > hardware. >> >> > >> >> > Then I merged that into my clone of Jeremy's xen/master which I use >> > with >> >> > Xen 3.4.2. >> >> > >> >> > Since then, I've been periodically cherry picking all new commits > off >> > the >> >> > nouveau tree. Also had to rebuild Xorg 7.5 to use xorg-server > 1.7.5, >> > new >> >> > libdrm, mesa, and xf86-video-nouveau all from their respective git >> > trees >> >> > as of yesterday. (drm and xf86-video-nouveau are on their master >> >> > branches, mesa is on the 7.8 branch) >> >> > >> >> > This all works great using xen/master bare metal. It used to work >> > fine on >> >> > my old GeForce2 MX based systems in Xen. Arvind's patch made it > work >> > on >> >> > my nice new systems in Xen, but broke it on the old ones. > Everything >> >> > still works fine bare metal. >> >> > >> >> >> Did you have to edit your xorg.conf file or >> >> >> it ran just fine? >> >> > >> >> > Well, I had to create an xorg.conf that looks like this: >> >> > >> >> > Section "Device" >> >> > Identifier "foo" >> >> > Driver "nouveau" >> >> > EndSection >> >> > >> >> > Otherwise it uses the 'nv' driver... and I haven't stumbled onto > how >> > to >> >> > get nouveau to automatically get used (aside from uninstalling the > nv >> >> > driver). >> >> > >> >> > >> >> >> Was this Fedora 13 or Fedora 12? >> >> > >> >> > This is all being done on a custom 32bit Linux distro that we use > for >> > our >> >> > tightly configuration controlled system deliveries. It was fedora >> > based a >> >> > looooooooong time ago (FC5), but is completely unrecognizable now. >> >> > >> >> > >> >> >> Arvind explanation about the Nvidia driver pointed out that the >> > NVidia >> >> >> driver (drm/nouvue) can operate on different channels. Where > channel >> > 1 >> >> >> is the framebuffer, and the other are for well, KMS, and other >> >> >> applications. >> >> >> >> >> >> I belive I was looking at the wrong section of the drivers (not > the >> >> >> drivers/video/gpu ones)- this certainly looks to be the issues the >> >> >> Jeremy mentioned. >> >> >> >> >> >> Also I would suggest you load drm with the debug variable set to > the >> > 255 >> >> >> to get most of what his happening. >> >> > >> >> > I'll try that. >> >> > >> >> > >> >> >> Based on your strace, the last call is: >> >> >> 4000) = 0x9324000 >> >> >> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 >> >> >> ioctl(11, 0xc0106445, 0x930a908) = 0 >> >> >> ioctl(11, 0x400c6444, 0xbfd2a210) = 0 >> >> >> +++ killed by SIGKILL +++ >> >> >> >> >> >> I cannot find what 0x45 is in the upstream Linux, so you must be >> > using a >> >> >> different nouv* driver than that. The 0x44 is: >> >> >> >> >> >> DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, >> > DRM_AUTH), >> >> >> >> >> >> Which looks to be pretty harmless. I presume it is the next thing >> > (using >> >> >> the address returned) that the X driver tries to do that makes it > go >> >> > boom. >> >> > >> >> I suspect that the ioctl is prior to a modeset operation. And the >> >> mode-setting is 'booming'. >> >> My kernel config has VGA console built-in fbcon as a module and I do >> >> a switch to >> >> nouveaufb at runlevel 2. Also note that the default modeset >> >> parameter is -1 and >> >> if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver >> >> initialisation >> >> - which maybe the problem. Do you have modeset=1 as module parameter? >> > >> > I wasn't setting any module params for nouveau. Adding 'options > nouveau >> > modeset=1' to modprobe.conf didn't seem to make any difference. >> > >> > I've got the following in my .config: >> > >> > CONFIG_VGA_CONSOLE=y >> > CONFIG_FB=y >> > CONFIG_FB_VGA16=m >> > CONFIG_FB_VESA=y >> > CONFIG_FB_EFI=y >> > CONFIG_FB_NVIDIA=m >> > CONFIG_FB_NVIDIA_I2C=y >> > CONFIG_FB_NVIDIA_BACKLIGHT=y >> > >> - EMBEDDED - this will enable VGA_CONSOLE selection. Set sub-menu >> choices as needed >> - VGA_CONSOLE builtin >> - FB as module >> - FRAMEBUFFER_CONSOLE as a module. Enables late loading of nouveau >> * Foll. required to avoid cfb_copyarea, cfb_fillrectangle, >> cfb_imageblit linking problems with >> out-of-tree nouveau builds >> - FB_VGA16 as module - supported by all nVidia cards. >> or >> - FB_NVIDIA as module - only works for older cards. >> >> For out-of-tree nouveau builds, DO NOT select ANY accelerated drivers >> - that would enable >> the old in-tree DRM. New TTM / DRM modulesare in the new driver/gpu > tree. >> >> For in-tree builds, if nouveau is NOT in the initrd-image, system will >> boot on vga console >> > >> > How do you force the nouveaufb switch at runlevel 2? My screen > obviously >> > switches into KMS mode while udev is starting up. >> You can switch to the accelerated framebuffer console by >> modprobe nouveau >> modprobe fbcon >> fbcon will take-over console from the built-in VGA. See >> Documenation/fb/fbcon.txt > > Ok, thanks. Now I've got everything compiled as modules and can load them > post-boot to switch to the nouveau framebuffer console. That actually > didn't change the X behavior at all, though. I still get the exact same > "X: Corrupted page table" messages in dmesg and my Xorg.log is just ending > with "NOUVEAU(0): Opened GPU channel 1". This is strange - channel 1 is the console channel. This appears in dmesg on nouveaufb initialisation before EDID probe to find connected outputs. Start X manually to avoid confusion of logs. Have attached ttm_xen.patch which updates vm_page_prot after changing flags. This is not done in the mainline drm-tree. But in the xen (old) drm-tree this is done in BOTH ttm_bo_mmap AND ttm_fbdev_mmap - and the attached patch does both, along with the conditional VM_IO in bo_mmap. And the second vm_page_prot update is for fbdev_mmap which corresponds to channel 1. Cross fingers and try! > If the old nvidiafb is loaded, nouveau cannot install (and vice-versa) > > Well, everything seems to load just fine. I get a nice teeny font and > dmesg messages saying I'm using nouveaufb. You should have got it earlier too - didn't you? >> does NOT affect unaccelerated X on the older cards? > > Which accelerated modes are you refering to? My understanding was that > the old GeForce2 cards should work for nouveaufb, the 2d xf86-nouveau > driver, and gallium's swrast_dri stuff (via AIGLX), but not gallium's new > dri_nouveau stuff. Right. But gallium's swrast_dri AND dri_nouveau are still 'unsupported', to be tried at own risk. nouveau_dri was working enough to run fgfs with mesa-7.7, but now with mesa-7.9, glxgears works not fgfs - segfaults in libdrm_nouveau. >> Xorg used to hang saying 'Opened Channel 2' and not 1. > > Now that's strange. Every single one of my boxes says Opened Channel 1, > with now reference to channel 2 at all. Channel 1 in dmesg/syslog; Xorg.log snippet: (II) LoadModule: "shadowfb" (II) Loading /usr/lib/xorg/modules/libshadowfb.so (II) Module shadowfb: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (--) Depth 24 pixmap format is 32 bpp (II) NOUVEAU(0): Opened GPU channel 2 <initial hang point> (II) NOUVEAU(0): [DRI2] Setup complete <after patch> (II) NOUVEAU(0): GART: 512MiB available (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer (II) EXA(0): Driver allocated offscreen pixmaps (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (II) UploadToScreen (II) DownloadFromScreen (==) NOUVEAU(0): Backing store disabled (==) NOUVEAU(0): Silken mouse enabled (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video. (II) NOUVEAU(0): [XvMC] Extension initialized. 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 So the cards that don't work are AGP cards? [-- Attachment #2: ttm_xen.patch --] [-- Type: text/x-diff, Size: 876 bytes --] --- nouveau-kernel-0.0.1+git20100322.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-02-11 12:38:42.000000000 +0530 +++ nouveau-kernel-0.0.1+git20100322/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-22 13:48:11.000000000 +0530 @@ -271,7 +271,11 @@ */ vma->vm_private_data = bo; - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT)) + vma->vm_flags |= VM_IO; + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); + return 0; out_unref: ttm_bo_unref(&bo); @@ -287,6 +291,7 @@ vma->vm_ops = &ttm_bo_vm_ops; vma->vm_private_data = ttm_bo_reference(bo); vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); return 0; } EXPORT_SYMBOL(ttm_fbdev_mmap); [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-23 6:21 ` Arvind R @ 2010-03-23 12:45 ` Michael D Labriola 2010-03-23 13:27 ` Michael D Labriola 1 sibling, 0 replies; 39+ messages in thread From: Michael D Labriola @ 2010-03-23 12:45 UTC (permalink / raw) To: Arvind R Cc: xen-devel-bounces, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Konrad Rzeszutek Wilk xen-devel-bounces@lists.xensource.com wrote on 03/23/2010 02:21:31 AM: > On Tue, Mar 23, 2010 at 2:44 AM, Michael D Labriola <mlabriol@gdeb.com> wrote: > > xen-devel-bounces@lists.xensource.com wrote on 03/20/2010 02:01:54 AM: > > > >> On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola <mlabriol@gdeb.com> > > wrote: > >> > xen-devel-bounces@lists.xensource.com wrote on 03/18/2010 02:09:08 AM: > >> > > >> >> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola > > <mlabriol@gdeb.com> > >> > wrote: > >> >> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on 03/16/2010 > >> >> > 01:21:35 PM: > >> >> > > >> >> >> > > > And my X log ends abruptly after this line: > >> >> >> > > > (II) NOUVEAU(0): Opened GPU Channel 1 > >> >> >> > > > > >> >> >> > > > Any ideas? > >> >> >> > > > > >> >> >> > > > >> >> >> > > Well, this is generally the symptom that someone is confusing > >> > mfns > >> >> > and > >> >> >> > > pfns, and therefore ends up incorrectly setting the _PAGE_IO > > flag > >> > in > >> >> > > >> >> >> > > some pte. If you run it under strace, can you identify which > >> >> > mapping > >> >> >> > > the fault is happening in? > >> >> >> > > >> >> >> > I've attached the output of 'strace -o strace-Xorg Xorg'. > > Figuring > >> >> > out > >> >> >> > which mapping the fault is happening in is a little over my > > head, > >> > I'm > >> >> >> > afraid. If you need different arguments to strace, let me know > > and > >> >> > I'll > >> >> >> > do it again. > >> >> >> > >> >> >> So just to be sure, you took the 2.6.32 (xen/next or > >> >> >> xen/stable-2.6.32.x), copied the include and nouveu directory from > >> > ..? > >> >> >> 2.6.33? and then ran this. > >> >> > > >> >> > I actually took a slightly more sadistic route than Arvind... ;-) > > A > >> > while > >> >> > back, I backported the important stuff from the Nouveau kernel git > >> > tree > >> >> > back to v2.6.31. Basically guessed at which commits were > > important, > >> > wrote > >> >> > a script to cherry pick each and every one, and spent an entire day > >> >> > reading commit logs, resolving conflicts, and figuring out which > > other > >> >> > non-drm commits I needed. Sounds retarded, I know, but it was a > >> > pretty > >> >> > interesting way to get myself up to speed with the code base. The > >> >> > resulting 2.6.31-nouveau kernel runs like a champ on all my > > hardware. > >> >> > > >> >> > Then I merged that into my clone of Jeremy's xen/master which I use > >> > with > >> >> > Xen 3.4.2. > >> >> > > >> >> > Since then, I've been periodically cherry picking all new commits > > off > >> > the > >> >> > nouveau tree. Also had to rebuild Xorg 7.5 to use xorg-server > > 1.7.5, > >> > new > >> >> > libdrm, mesa, and xf86-video-nouveau all from their respective git > >> > trees > >> >> > as of yesterday. (drm and xf86-video-nouveau are on their master > >> >> > branches, mesa is on the 7.8 branch) > >> >> > > >> >> > This all works great using xen/master bare metal. It used to work > >> > fine on > >> >> > my old GeForce2 MX based systems in Xen. Arvind's patch made it > > work > >> > on > >> >> > my nice new systems in Xen, but broke it on the old ones. > > Everything > >> >> > still works fine bare metal. > >> >> > > >> >> >> Did you have to edit your xorg.conf file or > >> >> >> it ran just fine? > >> >> > > >> >> > Well, I had to create an xorg.conf that looks like this: > >> >> > > >> >> > Section "Device" > >> >> > Identifier "foo" > >> >> > Driver "nouveau" > >> >> > EndSection > >> >> > > >> >> > Otherwise it uses the 'nv' driver... and I haven't stumbled onto > > how > >> > to > >> >> > get nouveau to automatically get used (aside from uninstalling the > > nv > >> >> > driver). > >> >> > > >> >> > > >> >> >> Was this Fedora 13 or Fedora 12? > >> >> > > >> >> > This is all being done on a custom 32bit Linux distro that we use > > for > >> > our > >> >> > tightly configuration controlled system deliveries. It was fedora > >> > based a > >> >> > looooooooong time ago (FC5), but is completely unrecognizable now. > >> >> > > >> >> > > >> >> >> Arvind explanation about the Nvidia driver pointed out that the > >> > NVidia > >> >> >> driver (drm/nouvue) can operate on different channels. Where > > channel > >> > 1 > >> >> >> is the framebuffer, and the other are for well, KMS, and other > >> >> >> applications. > >> >> >> > >> >> >> I belive I was looking at the wrong section of the drivers (not > > the > >> >> >> drivers/video/gpu ones)- this certainly looks to be the issues the > >> >> >> Jeremy mentioned. > >> >> >> > >> >> >> Also I would suggest you load drm with the debug variable set to > > the > >> > 255 > >> >> >> to get most of what his happening. > >> >> > > >> >> > I'll try that. > >> >> > > >> >> > > >> >> >> Based on your strace, the last call is: > >> >> >> 4000) = 0x9324000 > >> >> >> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 > >> >> >> ioctl(11, 0xc0106445, 0x930a908) = 0 > >> >> >> ioctl(11, 0x400c6444, 0xbfd2a210) = 0 > >> >> >> +++ killed by SIGKILL +++ > >> >> >> > >> >> >> I cannot find what 0x45 is in the upstream Linux, so you must be > >> > using a > >> >> >> different nouv* driver than that. The 0x44 is: > >> >> >> > >> >> >> DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, > >> > DRM_AUTH), > >> >> >> > >> >> >> Which looks to be pretty harmless. I presume it is the next thing > >> > (using > >> >> >> the address returned) that the X driver tries to do that makes it > > go > >> >> > boom. > >> >> > > >> >> I suspect that the ioctl is prior to a modeset operation. And the > >> >> mode-setting is 'booming'. > >> >> My kernel config has VGA console built-in fbcon as a module and I do > >> >> a switch to > >> >> nouveaufb at runlevel 2. Also note that the default modeset > >> >> parameter is -1 and > >> >> if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver > >> >> initialisation > >> >> - which maybe the problem. Do you have modeset=1 as module parameter? > >> > > >> > I wasn't setting any module params for nouveau. Adding 'options > > nouveau > >> > modeset=1' to modprobe.conf didn't seem to make any difference. > >> > > >> > I've got the following in my .config: > >> > > >> > CONFIG_VGA_CONSOLE=y > >> > CONFIG_FB=y > >> > CONFIG_FB_VGA16=m > >> > CONFIG_FB_VESA=y > >> > CONFIG_FB_EFI=y > >> > CONFIG_FB_NVIDIA=m > >> > CONFIG_FB_NVIDIA_I2C=y > >> > CONFIG_FB_NVIDIA_BACKLIGHT=y > >> > > >> - EMBEDDED - this will enable VGA_CONSOLE selection. Set sub-menu > >> choices as needed > >> - VGA_CONSOLE builtin > >> - FB as module > >> - FRAMEBUFFER_CONSOLE as a module. Enables late loading of nouveau > >> * Foll. required to avoid cfb_copyarea, cfb_fillrectangle, > >> cfb_imageblit linking problems with > >> out-of-tree nouveau builds > >> - FB_VGA16 as module - supported by all nVidia cards. > >> or > >> - FB_NVIDIA as module - only works for older cards. > >> > >> For out-of-tree nouveau builds, DO NOT select ANY accelerated drivers > >> - that would enable > >> the old in-tree DRM. New TTM / DRM modulesare in the new driver/gpu > > tree. > >> > >> For in-tree builds, if nouveau is NOT in the initrd-image, system will > >> boot on vga console > >> > > >> > How do you force the nouveaufb switch at runlevel 2? My screen > > obviously > >> > switches into KMS mode while udev is starting up. > >> You can switch to the accelerated framebuffer console by > >> modprobe nouveau > >> modprobe fbcon > >> fbcon will take-over console from the built-in VGA. See > >> Documenation/fb/fbcon.txt > > > > Ok, thanks. Now I've got everything compiled as modules and can load them > > post-boot to switch to the nouveau framebuffer console. That actually > > didn't change the X behavior at all, though. I still get the exact same > > "X: Corrupted page table" messages in dmesg and my Xorg.log is just ending > > with "NOUVEAU(0): Opened GPU channel 1". > This is strange - channel 1 is the console channel. This appears in dmesg on > nouveaufb initialisation before EDID probe to find connected outputs. > Start X manually to avoid confusion of logs. I've been testing this by booting to runlevel 3 and starting gdm. I'll double check that I get the same results running Xorg by hand, although gdm does something to give me my console back after the X crash... > Have attached ttm_xen.patch which updates vm_page_prot after changing flags. > This is not done in the mainline drm-tree. But in the xen (old) > drm-tree this is done in > BOTH ttm_bo_mmap AND ttm_fbdev_mmap - and the attached patch does both, > along with the conditional VM_IO in bo_mmap. And the second vm_page_prot > update is for fbdev_mmap which corresponds to channel 1. Cross > fingers and try! I'll go try that. > > If the old nvidiafb is loaded, nouveau cannot install (and vice-versa) > > > > Well, everything seems to load just fine. I get a nice teeny font and > > dmesg messages saying I'm using nouveaufb. > You should have got it earlier too - didn't you? Yeah, I had that before. > >> does NOT affect unaccelerated X on the older cards? > > > > Which accelerated modes are you refering to? My understanding was that > > the old GeForce2 cards should work for nouveaufb, the 2d xf86-nouveau > > driver, and gallium's swrast_dri stuff (via AIGLX), but not gallium's new > > dri_nouveau stuff. > Right. But gallium's swrast_dri AND dri_nouveau are still 'unsupported', > to be tried at own risk. nouveau_dri was working enough to run fgfs with > mesa-7.7, but now with mesa-7.9, glxgears works not fgfs - segfaults in > libdrm_nouveau. Correct. I've been having rather good luck with it until this. I can recompile mesa and leave out the nouveau and swrast stuff to see if that helps, but my impression was that this is crashing before any of that code even gets used. And it does work bare-metal and did work in xen prior to that last patch. What's the fallback if both gallium's nouveau and swrast libs are missing, anyway? > >> Xorg used to hang saying 'Opened Channel 2' and not 1. > > > > Now that's strange. Every single one of my boxes says Opened Channel 1, > > with now reference to channel 2 at all. > Channel 1 in dmesg/syslog; Xorg.log snippet: > (II) LoadModule: "shadowfb" > (II) Loading /usr/lib/xorg/modules/libshadowfb.so > (II) Module shadowfb: vendor="X.Org Foundation" > compiled for 1.7.5, module version = 1.0.0 > ABI class: X.Org ANSI C Emulation, version 0.4 > (--) Depth 24 pixmap format is 32 bpp > (II) NOUVEAU(0): Opened GPU channel 2 <initial hang point> > (II) NOUVEAU(0): [DRI2] Setup complete <after patch> > (II) NOUVEAU(0): GART: 512MiB available > (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer > (II) EXA(0): Driver allocated offscreen pixmaps > (II) EXA(0): Driver registered support for the following operations: > (II) Solid > (II) Copy > (II) Composite (RENDER acceleration) > (II) UploadToScreen > (II) DownloadFromScreen > (==) NOUVEAU(0): Backing store disabled > (==) NOUVEAU(0): Silken mouse enabled > (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video. > (II) NOUVEAU(0): [XvMC] Extension initialized. > > > 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 Which should make it mind-bogglingly slow, right? I'll try this as well. > > So the cards that don't work are AGP cards? Yes. GeForce2 MX200 AGP. --- Michael D Labriola Electric Boat mlabriol@gdeb.com 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-23 6:21 ` Arvind R 2010-03-23 12:45 ` Michael D Labriola @ 2010-03-23 13:27 ` Michael D Labriola 2010-03-25 7:05 ` Arvind R 1 sibling, 1 reply; 39+ messages in thread From: Michael D Labriola @ 2010-03-23 13:27 UTC (permalink / raw) To: Arvind R Cc: xen-devel-bounces, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Konrad Rzeszutek Wilk xen-devel-bounces@lists.xensource.com wrote on 03/23/2010 02:21:31 AM: *snip* > > with "NOUVEAU(0): Opened GPU channel 1". > This is strange - channel 1 is the console channel. This appears in dmesg on > nouveaufb initialisation before EDID probe to find connected outputs. > Start X manually to avoid confusion of logs. > > Have attached ttm_xen.patch which updates vm_page_prot after changing flags. > This is not done in the mainline drm-tree. But in the xen (old) > drm-tree this is done in > BOTH ttm_bo_mmap AND ttm_fbdev_mmap - and the attached patch does both, > along with the conditional VM_IO in bo_mmap. And the second vm_page_prot > update is for fbdev_mmap which corresponds to channel 1. Cross > fingers and try! Actually, both hunks of that patch are already applied in my tree. The git tree from git://anongit.freedesktop.org/nouveau/linux-2.6 appears to already be doing the vm_page_prot update in both places. Maybe the official nouveau dev tree is hosed? Odd that it would work fine bare-metal... *snip* > >> Xorg used to hang saying 'Opened Channel 2' and not 1. > > > > Now that's strange. Every single one of my boxes says Opened Channel 1, > > with now reference to channel 2 at all. > Channel 1 in dmesg/syslog; Xorg.log snippet: > (II) LoadModule: "shadowfb" > (II) Loading /usr/lib/xorg/modules/libshadowfb.so > (II) Module shadowfb: vendor="X.Org Foundation" > compiled for 1.7.5, module version = 1.0.0 > ABI class: X.Org ANSI C Emulation, version 0.4 > (--) Depth 24 pixmap format is 32 bpp > (II) NOUVEAU(0): Opened GPU channel 2 <initial hang point> > (II) NOUVEAU(0): [DRI2] Setup complete <after patch> > (II) NOUVEAU(0): GART: 512MiB available > (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer > (II) EXA(0): Driver allocated offscreen pixmaps > (II) EXA(0): Driver registered support for the following operations: > (II) Solid > (II) Copy > (II) Composite (RENDER acceleration) > (II) UploadToScreen > (II) DownloadFromScreen > (==) NOUVEAU(0): Backing store disabled > (==) NOUVEAU(0): Silken mouse enabled > (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video. > (II) NOUVEAU(0): [XvMC] Extension initialized. > > > 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. --- Michael D Labriola Electric Boat mlabriol@gdeb.com 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-23 13:27 ` Michael D Labriola @ 2010-03-25 7:05 ` Arvind R 0 siblings, 0 replies; 39+ messages in thread From: Arvind R @ 2010-03-25 7:05 UTC (permalink / raw) To: Michael D Labriola Cc: xen-devel-bounces, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Konrad Rzeszutek Wilk On Tue, Mar 23, 2010 at 6:57 PM, Michael D Labriola <mlabriol@gdeb.com> wrote: > xen-devel-bounces@lists.xensource.com wrote on 03/23/2010 02:21:31 AM: > > *snip* >> > with "NOUVEAU(0): Opened GPU channel 1". >> This is strange - channel 1 is the console channel. This appears in > dmesg on >> nouveaufb initialisation before EDID probe to find connected outputs. >> Start X manually to avoid confusion of logs. >> >> Have attached ttm_xen.patch which updates vm_page_prot after changing > flags. >> This is not done in the mainline drm-tree. But in the xen (old) >> drm-tree this is done in >> BOTH ttm_bo_mmap AND ttm_fbdev_mmap - and the attached patch does both, >> along with the conditional VM_IO in bo_mmap. And the second vm_page_prot >> update is for fbdev_mmap which corresponds to channel 1. Cross >> fingers and try! > > Actually, both hunks of that patch are already applied in my tree. The > git tree from git://anongit.freedesktop.org/nouveau/linux-2.6 appears to > already be doing the vm_page_prot update in both places. Maybe the > official nouveau dev tree is hosed? Odd that it would work fine > bare-metal... It always did work on bare-metal and on Xen without acceleration. The patch just enables acceleration on Xen - it seems only on PCI/E cards. > *snip* >> >> Xorg used to hang saying 'Opened Channel 2' and not 1. >> > >> > Now that's strange. Every single one of my boxes says Opened Channel > 1, >> > with now reference to channel 2 at all. >> 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). ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-15 14:44 ` Michael D Labriola 2010-03-15 23:13 ` Jeremy Fitzhardinge @ 2010-03-25 7:18 ` Jeremy Fitzhardinge 2010-03-29 14:42 ` Michael D Labriola 2010-06-09 17:43 ` Konrad Rzeszutek Wilk 2 siblings, 1 reply; 39+ messages in thread From: Jeremy Fitzhardinge @ 2010-03-25 7:18 UTC (permalink / raw) To: Michael D Labriola Cc: Arvind R, Konrad Rzeszutek Wilk, xen-devel, Joanna Rutkowska, xen-devel-bounces On 03/15/2010 07:44 AM, Michael D Labriola wrote: > xen-devel-bounces@lists.xensource.com wrote on 03/13/2010 05:03:22 PM: > > >> On 03/12/2010 01:45 PM, Arvind R wrote: >> >>> On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen<pq@iki.fi> wrote: >>> >>>> I'm adding dri-devel@ to CC, since this suggested patch touches >>>> TTM code, and none of the Nouveau code. TTM patches go via >>>> dri-devel@. >>>> >>>> Thanks. >>>> >>>> >>>> On Wed, 10 Mar 2010 18:51:21 +0530 >>>> Arvind R<arvino55@gmail.com> wrote: >>>> >>>> >>>>> Hi, >>>>> Following is a simple patch that is needed in nouveau to get >>>>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's >>>>> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is >>>>> almost the mainline merge), was substituted into the kernel-tree. >>>>> All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) >>>>> used of the same day. >>>>> >>>>> Patch: >>>>> diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c >>>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c >>>>> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 >>>>> 10:19:28.000000000 +0530 >>>>> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 >>>>> 17:28:59.000000000 +0530 >>>>> @@ -271,7 +271,10 @@ >>>>> */ >>>>> >>>>> vma->vm_private_data = bo; >>>>> - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | >>>>> VM_DONTEXPAND; >>>>> + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | >>>>> VM_DONTEXPAND; >>>>> + if (!((bo->mem.placement& TTM_PL_MASK_MEM)& >>>>> TTM_PL_FLAG_TT)) >>>>> + vma->vm_flags |= VM_IO; >>>>> + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); >>>>> return 0; >>>>> out_unref: >>>>> ttm_bo_unref(&bo); >>>>> >>>>> >>> sorry for the typo and other procedural errors. >>> the last added line should be >>> + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags) >>> >>> >>>>> This patch is necessary because, in Xen, PFN of a page is >>>>> virtualised. So physical addresses >>>>> for DMA programming needs to use the MFN. Xen transparently does >>>>> the correct translation >>>>> using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, >>>>> then Xen assumes that the backing >>>>> memory is in the IOMEM space, and PFN equals MFN. If not set, >>>>> page_to_pfn() returns MFN. >>>>> >>>>> The patch enables the ttm_bo_vm_fault() handler to behave >>>>> correctly under Xen, and has no >>>>> side-effects on normal (not under Xen) operations. The use of >>>>> TTM_PL_FLAG_TT in the >>>>> check assumes that all other placements are backed by device >>>>> memory or IO. If there are >>>>> any other placements that use system memory, that flag has to be >>>>> OR'ed into the check. >>>>> >>>>> The above patch has no implications on a normal kernel or a Xen >>>>> pv_ops kernel booted without >>>>> the Xen hypervisor. My testing is on a debian-lenny environment >>>>> on a Core2 processor with >>>>> nVidia GeForce 9400 GT. >>>>> >>>> >>> Efficacy of patch: >>> successful flightgear run on dom0 AND bareboot! >>> >>> >> Jeremy, will you be merging this patch into any of the xen/stable-* >> branches any time soon? >> >> Thanks, >> joanna. >> > 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 > ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss > snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device > snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer > ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore i82860_edac > snd_page_alloc pata_acpi edac_core parport_pc floppy parport dm_snapshot > dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd > aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod > [ 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 > > Any ideas? > BTW, what chipset does this machine have? Is it Intel? AMD? Other? J ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-25 7:18 ` Jeremy Fitzhardinge @ 2010-03-29 14:42 ` Michael D Labriola 0 siblings, 0 replies; 39+ messages in thread From: Michael D Labriola @ 2010-03-29 14:42 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: Arvind R, xen-devel-bounces, xen-devel, Joanna Rutkowska, Konrad Rzeszutek Wilk xen-devel-bounces@lists.xensource.com wrote on 03/25/2010 03:18:42 AM: > On 03/15/2010 07:44 AM, Michael D Labriola wrote: > > xen-devel-bounces@lists.xensource.com wrote on 03/13/2010 05:03:22 PM: > > > > > >> On 03/12/2010 01:45 PM, Arvind R wrote: > >> > >>> On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen<pq@iki.fi> wrote: > >>> > >>>> I'm adding dri-devel@ to CC, since this suggested patch touches > >>>> TTM code, and none of the Nouveau code. TTM patches go via > >>>> dri-devel@. > >>>> > >>>> Thanks. > >>>> > >>>> > >>>> On Wed, 10 Mar 2010 18:51:21 +0530 > >>>> Arvind R<arvino55@gmail.com> wrote: > >>>> > >>>> > >>>>> Hi, > >>>>> Following is a simple patch that is needed in nouveau to get > >>>>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's > >>>>> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is > >>>>> almost the mainline merge), was substituted into the kernel-tree. > >>>>> All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) > >>>>> used of the same day. > >>>>> > >>>>> Patch: > >>>>> diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c > >>>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c > >>>>> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 > >>>>> 10:19:28.000000000 +0530 > >>>>> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 > >>>>> 17:28:59.000000000 +0530 > >>>>> @@ -271,7 +271,10 @@ > >>>>> */ > >>>>> > >>>>> vma->vm_private_data = bo; > >>>>> - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | > >>>>> VM_DONTEXPAND; > >>>>> + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | > >>>>> VM_DONTEXPAND; > >>>>> + if (!((bo->mem.placement& TTM_PL_MASK_MEM)& > >>>>> TTM_PL_FLAG_TT)) > >>>>> + vma->vm_flags |= VM_IO; > >>>>> + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); > >>>>> return 0; > >>>>> out_unref: > >>>>> ttm_bo_unref(&bo); > >>>>> > >>>>> > >>> sorry for the typo and other procedural errors. > >>> the last added line should be > >>> + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags) > >>> > >>> > >>>>> This patch is necessary because, in Xen, PFN of a page is > >>>>> virtualised. So physical addresses > >>>>> for DMA programming needs to use the MFN. Xen transparently does > >>>>> the correct translation > >>>>> using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, > >>>>> then Xen assumes that the backing > >>>>> memory is in the IOMEM space, and PFN equals MFN. If not set, > >>>>> page_to_pfn() returns MFN. > >>>>> > >>>>> The patch enables the ttm_bo_vm_fault() handler to behave > >>>>> correctly under Xen, and has no > >>>>> side-effects on normal (not under Xen) operations. The use of > >>>>> TTM_PL_FLAG_TT in the > >>>>> check assumes that all other placements are backed by device > >>>>> memory or IO. If there are > >>>>> any other placements that use system memory, that flag has to be > >>>>> OR'ed into the check. > >>>>> > >>>>> The above patch has no implications on a normal kernel or a Xen > >>>>> pv_ops kernel booted without > >>>>> the Xen hypervisor. My testing is on a debian-lenny environment > >>>>> on a Core2 processor with > >>>>> nVidia GeForce 9400 GT. > >>>>> > >>>> > >>> Efficacy of patch: > >>> successful flightgear run on dom0 AND bareboot! > >>> > >>> > >> Jeremy, will you be merging this patch into any of the xen/stable-* > >> branches any time soon? > >> > >> Thanks, > >> joanna. > >> > > 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 > > ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss > > snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device > > snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer > > ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore i82860_edac > > snd_page_alloc pata_acpi edac_core parport_pc floppy parport dm_snapshot > > dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd > > aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod > > [ 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 > > > > Any ideas? > > > > BTW, what chipset does this machine have? Is it Intel? AMD? Other? > > J It's a really old Intel Xeon SMP box. SuperMicro P4DC6+ motherboard. --- Michael D Labriola Electric Boat mlabriol@gdeb.com 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-03-15 14:44 ` Michael D Labriola 2010-03-15 23:13 ` Jeremy Fitzhardinge 2010-03-25 7:18 ` Jeremy Fitzhardinge @ 2010-06-09 17:43 ` Konrad Rzeszutek Wilk 2010-06-09 18:39 ` Pasi Kärkkäinen 2010-06-17 17:51 ` Konrad Rzeszutek Wilk 2 siblings, 2 replies; 39+ messages in thread From: Konrad Rzeszutek Wilk @ 2010-06-09 17:43 UTC (permalink / raw) To: Michael D Labriola Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, xen-devel-bounces > > >>> vma->vm_private_data = bo; > > >>> - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | > > >>> VM_DONTEXPAND; > > >>> + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | > > >>> VM_DONTEXPAND; > > >>> + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & > > >>> TTM_PL_FLAG_TT)) > > >>> + vma->vm_flags |= VM_IO; > > >>> + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); > > >>> return 0; > > >>> out_unref: > > >>> ttm_bo_unref(&bo); > > >>> .. snip. > > >>> nVidia GeForce 9400 GT. ..snip.. > > 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 .. snip.. > [ 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 So, I've spent the last two weeks trying to get this to work. What I found out was that the majority of the problems were with the Linux AGP code (drivers/char/agp/*). Now I can get Kernel Modesetting working under Radeon HD3200 (PCI-e), NVidia GeForce FX5200 (AGP), and I think other ones too (hadn't tested yet). However, I am still failing at the same spot as Michael: the dreaded Opened GPU Channel 1... Anyhow.. if you want the patches: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/kms-fixes (and the "devel/drm.backport" which is a drop of drm/* from 2.6.34-rc7 in 2.6.32 universe). The explanation: 1). Newer boxes with PCI-e cards with more than 4GB allocated to dom0. Those cards have their own IOMMU built in on the cards and use the PCI DMA. The problem is that some of those cards set the DMA mask to 32-bit, meaning they are only comfortable allocating pages under the 4GB mark. The Xen-SWIOTLB kicks in and happily gives a bounce buffer for pages that are above the 32-bit mark, which are then programmed to the IOMMU. Except that the graphic drivers do not sync the bounce buffer so the result ends up stored in the bounce buffer and not in the buffer the graphic drivers expect (oops). That however should not have happend as any pages allocated from the TTM library use the 'alloc_page' with _GFP_DMA32 flag, which means that all of those pages WILL be under 4GB under baremetal. However under Xen that flag is useless and the page can be very well allocated above the 4GB mark (and is if you are using the debug Xen hypervisor). The patch titled "ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under" fixes that by replacing the PFNs with ones under the 4GB. It makes my Radeon HD3200 work, and I believe other PCI-e cards too. 2). i915 cards: The earlier cards (before PCI-e) depend on the AGP to the virtual to physical address translations. The old AGP code is safe for specific controllers: say i915 - and only if you have CONFIG_DMAR enabled. So there is a patch if you don't have that enabled: intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus addresses. 3) i915 and before. For older ones, such as the ICH5 (which has an i860 chipset), the Linux code blindly uses the virt_to_phys and page_to_phys which are not Xen-safe. For this fancy NV30 card (which is AGP) I've gotten to the point of the framebuffer displaying properly. The patches that fix this are: intel-agp: Use Xen back-door to get page's physical address for i8[1,3]0 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. 4). I did check out the AGP code for the other chipsets, so added experimental support for AMD64 chipset. Haven't tested it at all. Summary: Most of those patches are not upstream materials. Right now I am just trying to get those bugs fixed and then later on revisit them with a more comprehensive patch. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-06-09 17:43 ` Konrad Rzeszutek Wilk @ 2010-06-09 18:39 ` Pasi Kärkkäinen 2010-06-09 19:31 ` Konrad Rzeszutek Wilk 2010-06-17 17:51 ` Konrad Rzeszutek Wilk 1 sibling, 1 reply; 39+ messages in thread From: Pasi Kärkkäinen @ 2010-06-09 18:39 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Michael D Labriola, xen-devel-bounces On Wed, Jun 09, 2010 at 01:43:42PM -0400, Konrad Rzeszutek Wilk wrote: > > > >>> vma->vm_private_data = bo; > > > >>> - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | > > > >>> VM_DONTEXPAND; > > > >>> + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | > > > >>> VM_DONTEXPAND; > > > >>> + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & > > > >>> TTM_PL_FLAG_TT)) > > > >>> + vma->vm_flags |= VM_IO; > > > >>> + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); > > > >>> return 0; > > > >>> out_unref: > > > >>> ttm_bo_unref(&bo); > > > >>> > .. snip. > > > >>> nVidia GeForce 9400 GT. > > ..snip.. > > > > 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 > .. snip.. > > [ 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 > > > So, I've spent the last two weeks trying to get this to work. > > What I found out was that the majority of the problems were with the Linux AGP code > (drivers/char/agp/*). Now I can get Kernel Modesetting > working under Radeon HD3200 (PCI-e), NVidia GeForce FX5200 (AGP), and I think > other ones too (hadn't tested yet). However, I am still failing at the same > spot as Michael: the dreaded Opened GPU Channel 1... > > Anyhow.. if you want the patches: > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/kms-fixes > > (and the "devel/drm.backport" which is a drop of drm/* from 2.6.34-rc7 in > 2.6.32 universe). > > The explanation: > > 1). Newer boxes with PCI-e cards with more than 4GB allocated to dom0. > Those cards have their own IOMMU built in on the cards and use the PCI > DMA. The problem is that some of those cards set the DMA mask to 32-bit, > meaning they are only comfortable allocating pages under the 4GB mark. > The Xen-SWIOTLB kicks in and happily gives a bounce buffer for pages > that are above the 32-bit mark, which are then programmed to the IOMMU. > Except that the graphic drivers do not sync the bounce buffer so the > result ends up stored in the bounce buffer and not in the buffer the > graphic drivers expect (oops). That however should not have happend > as any pages allocated from the TTM library use the 'alloc_page' with > _GFP_DMA32 flag, which means that all of those pages WILL be under > 4GB under baremetal. However under Xen that flag is useless and the page > can be very well allocated above the 4GB mark (and is if you are using > the debug Xen hypervisor). The patch titled > "ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under" fixes that by > replacing the PFNs with ones under the 4GB. > > It makes my Radeon HD3200 work, and I believe other PCI-e cards too. > > 2). i915 cards: > The earlier cards (before PCI-e) depend on the AGP to the virtual to > physical address translations. The old AGP code is safe for specific > controllers: say i915 - and only if you have CONFIG_DMAR enabled. So > there is a patch if you don't have that enabled: > > intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus addresses. > > 3) i915 and before. > For older ones, such as the ICH5 (which has an i860 chipset), the Linux > code blindly uses the virt_to_phys and page_to_phys which are not > Xen-safe. For this fancy NV30 card (which is AGP) I've gotten to the > point of the framebuffer displaying properly. The patches that fix this > are: > intel-agp: Use Xen back-door to get page's physical address for i8[1,3]0 > 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. > > > 4). I did check out the AGP code for the other chipsets, so added > experimental support for AMD64 chipset. Haven't tested it at all. > > Summary: > Most of those patches are not upstream materials. Right now I am > just trying to get those bugs fixed and then later on revisit them with > a more comprehensive patch. > Wow. Impressive work! Hopefully the "Opened GPU channel 1" -thing gets beaten sooner than later too.. unfortunately I don't have Nvidia GPU at the moment so I can't really help with that.. -- Pasi ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-06-09 18:39 ` Pasi Kärkkäinen @ 2010-06-09 19:31 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 39+ messages in thread From: Konrad Rzeszutek Wilk @ 2010-06-09 19:31 UTC (permalink / raw) To: Pasi Kärkkäinen Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Michael D Labriola, xen-devel-bounces > > Wow. Impressive work! Thank you. > > Hopefully the "Opened GPU channel 1" -thing gets beaten sooner than later too.. > unfortunately I don't have Nvidia GPU at the moment so I can't really help with that.. That is OK. One of the patches in that git tree also fixes ATI Radeon cards issues (wherein if you had 4GB or more in Dom0, the ATI Radeon cards would not work, or if you booted Dom0 with a debug enabled Xen it would fail). ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-06-09 17:43 ` Konrad Rzeszutek Wilk 2010-06-09 18:39 ` Pasi Kärkkäinen @ 2010-06-17 17:51 ` Konrad Rzeszutek Wilk 2010-06-22 22:32 ` Joanna Rutkowska 1 sibling, 1 reply; 39+ messages in thread From: Konrad Rzeszutek Wilk @ 2010-06-17 17:51 UTC (permalink / raw) To: Michael D Labriola Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, xen-devel-bounces > > And my X log ends abruptly after this line: > > (II) NOUVEAU(0): Opened GPU Channel 1 > > > So, I've spent the last two weeks trying to get this to work. > .. > other ones too (hadn't tested yet). However, I am still failing at the same > spot as Michael: the dreaded Opened GPU Channel 1... Fixed! Plus I've tested it on: GeForce 1 256 GeForce 3 NV20 GeForce 4 Ti 4200 GeForce 8600 GT ICH5 82865G ICH7 82G33/G31G ICH8 82Q963/Q965 Matrox G450 Radeon ES1000 Radeon HD 3200 Radeon R100 QD (7200) Radeon RV100QY (7000) Radeon RV710 [Radeon HD 4350] RIVA TNT2 Pro Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM There are two bugs that are creeping up. One of the can be disabled by 'nopat' on the command line. The other, well the other is only seen during shutdown. > > Anyhow.. if you want the patches: > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/kms-fixes I rebased the branch and it is now devel/kms.fixes-0.3 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-06-17 17:51 ` Konrad Rzeszutek Wilk @ 2010-06-22 22:32 ` Joanna Rutkowska 2010-06-23 12:54 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 39+ messages in thread From: Joanna Rutkowska @ 2010-06-22 22:32 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Michael D Labriola, xen-devel-bounces [-- Attachment #1.1: Type: text/plain, Size: 1572 bytes --] On 06/17/10 19:51, Konrad Rzeszutek Wilk wrote: >>> And my X log ends abruptly after this line: >>> (II) NOUVEAU(0): Opened GPU Channel 1 >> >> >> So, I've spent the last two weeks trying to get this to work. >> > .. >> other ones too (hadn't tested yet). However, I am still failing at the same >> spot as Michael: the dreaded Opened GPU Channel 1... > > Fixed! Plus I've tested it on: > > GeForce 1 256 > GeForce 3 NV20 > GeForce 4 Ti 4200 > GeForce 8600 GT > ICH5 82865G > ICH7 82G33/G31G > ICH8 82Q963/Q965 > Matrox G450 > Radeon ES1000 > Radeon HD 3200 > Radeon R100 QD (7200) > Radeon RV100QY (7000) > Radeon RV710 [Radeon HD 4350] > RIVA TNT2 Pro > > Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM > There are two bugs that are creeping up. One of the can be disabled by > 'nopat' on the command line. The other, well the other is only seen > during shutdown. > >> >> Anyhow.. if you want the patches: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/kms-fixes > > I rebased the branch and it is now devel/kms.fixes-0.3 > Which stable branch have you rebased it for (.31, .32, .33?)? Have you tested it with some composting Window Manager (e.g. in KDE or Gnome with enables desktop effects)? Have you also tested it with Xorg 1.8.0? This is now default in F13, and it used new nouveau driver interface 0.16 (previous Xorgs exprected version 0.15). Finally, have you tested S3 sleep? (Has anybody actually got pvops0 .31 or .32 support S3 sleep?). Thanks, joanna. [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 226 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-06-22 22:32 ` Joanna Rutkowska @ 2010-06-23 12:54 ` Konrad Rzeszutek Wilk 2010-06-23 13:21 ` Joanna Rutkowska 2010-06-24 19:55 ` Pasi Kärkkäinen 0 siblings, 2 replies; 39+ messages in thread From: Konrad Rzeszutek Wilk @ 2010-06-23 12:54 UTC (permalink / raw) To: Joanna Rutkowska Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Michael D Labriola, xen-devel-bounces On Wed, Jun 23, 2010 at 12:32:57AM +0200, Joanna Rutkowska wrote: > On 06/17/10 19:51, Konrad Rzeszutek Wilk wrote: > >>> And my X log ends abruptly after this line: > >>> (II) NOUVEAU(0): Opened GPU Channel 1 > >> > >> > >> So, I've spent the last two weeks trying to get this to work. > >> > > .. > >> other ones too (hadn't tested yet). However, I am still failing at the same > >> spot as Michael: the dreaded Opened GPU Channel 1... > > > > Fixed! Plus I've tested it on: > > > > GeForce 1 256 > > GeForce 3 NV20 > > GeForce 4 Ti 4200 > > GeForce 8600 GT > > ICH5 82865G > > ICH7 82G33/G31G > > ICH8 82Q963/Q965 > > Matrox G450 > > Radeon ES1000 > > Radeon HD 3200 > > Radeon R100 QD (7200) > > Radeon RV100QY (7000) > > Radeon RV710 [Radeon HD 4350] > > RIVA TNT2 Pro > > > > Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM > > There are two bugs that are creeping up. One of the can be disabled by > > 'nopat' on the command line. The other, well the other is only seen > > during shutdown. > > > >> > >> Anyhow.. if you want the patches: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/kms-fixes > > > > I rebased the branch and it is now devel/kms.fixes-0.3 > > > Which stable branch have you rebased it for (.31, .32, .33?)? .32. and then I backported the DRM/TTM/KMS from 2.6.34 to be able to test the nouveau driver. > > Have you tested it with some composting Window Manager (e.g. in KDE or > Gnome with enables desktop effects)? Yes. I think so (isn't that the default thing?). Played some tuxracer when testing it on Radeon and I think the i915, so the OpenGL components worked OK. I know that 3D don't work on the nouveau driver so hadn't tried that. > > Have you also tested it with Xorg 1.8.0? This is now default in F13, and > it used new nouveau driver interface 0.16 (previous Xorgs exprected > version 0.15). Yes. I used for initial testing with whatever was in F13 Alpha drop?. After all of that testing I switched my main desktop machine to use F13 with the using xorg-x11-server 1.8.0-12.fc13 and with a GeForce 8600 GT. It works - thought I keep on getting those PSE warnings whenever an application has been killed (http://wiki.xensource.com/xenwiki/XenPVOPSDRM, look for Status). > > Finally, have you tested S3 sleep? (Has anybody actually got pvops0 .31 > or .32 support S3 sleep?). HA! Working on that and S5 right now. Jeremy mentioned he did get S3 working, but hadn't tried other modes. S5, S3, and S1 on my SuperMicro XF8TN just don't work. Not sure if I have the Xen ACPI hypercalls thought in the code base. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-06-23 12:54 ` Konrad Rzeszutek Wilk @ 2010-06-23 13:21 ` Joanna Rutkowska 2010-06-23 14:38 ` Konrad Rzeszutek Wilk 2010-06-24 19:55 ` Pasi Kärkkäinen 1 sibling, 1 reply; 39+ messages in thread From: Joanna Rutkowska @ 2010-06-23 13:21 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Michael D Labriola, xen-devel-bounces [-- Attachment #1.1: Type: text/plain, Size: 3851 bytes --] On 06/23/10 14:54, Konrad Rzeszutek Wilk wrote: > On Wed, Jun 23, 2010 at 12:32:57AM +0200, Joanna Rutkowska wrote: >> On 06/17/10 19:51, Konrad Rzeszutek Wilk wrote: >>>>> And my X log ends abruptly after this line: >>>>> (II) NOUVEAU(0): Opened GPU Channel 1 >>>> >>>> >>>> So, I've spent the last two weeks trying to get this to work. >>>> >>> .. >>>> other ones too (hadn't tested yet). However, I am still failing at the same >>>> spot as Michael: the dreaded Opened GPU Channel 1... >>> >>> Fixed! Plus I've tested it on: >>> >>> GeForce 1 256 >>> GeForce 3 NV20 >>> GeForce 4 Ti 4200 >>> GeForce 8600 GT >>> ICH5 82865G >>> ICH7 82G33/G31G >>> ICH8 82Q963/Q965 >>> Matrox G450 >>> Radeon ES1000 >>> Radeon HD 3200 >>> Radeon R100 QD (7200) >>> Radeon RV100QY (7000) >>> Radeon RV710 [Radeon HD 4350] >>> RIVA TNT2 Pro >>> >>> Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM >>> There are two bugs that are creeping up. One of the can be disabled by >>> 'nopat' on the command line. The other, well the other is only seen >>> during shutdown. >>> >>>> >>>> Anyhow.. if you want the patches: >>>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/kms-fixes >>> >>> I rebased the branch and it is now devel/kms.fixes-0.3 >>> >> Which stable branch have you rebased it for (.31, .32, .33?)? > > .32. > > and then I backported the DRM/TTM/KMS from 2.6.34 to be able to test the > nouveau driver. >> >> Have you tested it with some composting Window Manager (e.g. in KDE or >> Gnome with enables desktop effects)? > > Yes. I think so (isn't that the default thing?). No, both KDE and GNOME have composition disabled by default. On KDE, you need to go to Computer/System Settings/Desktop and then "Enable Desktop Eff3cts". You might need to click on the "Advanced" tab, and choose XRender instead of Open GL (and maybe also tick "Disable Functionality checks"). > Played some tuxracer when testing it on Radeon and I think the i915, i915 is the Intel card, right? So, it's not served by the nouveau code, is it? > so the OpenGL components worked OK. Hmmm, that's interesting. I think I never got Open GL working on nouveau, even on baremetal (I tested via KDE -- see above). > I know that 3D don't work on the nouveau driver so hadn't > tried that. > No worries, 3D desktop effects are overrated ;) All I want is "Expose" :) >> >> Have you also tested it with Xorg 1.8.0? This is now default in F13, and >> it used new nouveau driver interface 0.16 (previous Xorgs exprected >> version 0.15). > > Yes. I used for initial testing with whatever was in F13 Alpha drop?. After > all of that testing I switched my main desktop machine to use F13 > with the using xorg-x11-server 1.8.0-12.fc13 and with a GeForce 8600 GT. > > It works - thought I keep on getting those PSE warnings whenever an application > has been killed (http://wiki.xensource.com/xenwiki/XenPVOPSDRM, look for > Status). > I know it's offtopic, but anybody tried Xorg 1.8.0 on Intel HD? I crashes every 5 minutes or so, when one enables composition in KDE. And this happens on baremetal F13 too! >> Finally, have you tested S3 sleep? (Has anybody actually got pvops0 .31 >> or .32 support S3 sleep?). > > HA! Working on that and S5 right now. Jeremy mentioned he did get S3 > working, but hadn't tried other modes. S5, S3, and S1 on my SuperMicro > XF8TN just don't work. Not sure if I have the Xen ACPI hypercalls > thought in the code base. What is the fundamental difference in S3 sleep support between pvops0 vs. xenlinux, which seems to support S3 sleep quite well. At least the 2.6.34-xenlinux, the one from OpenSUSE? Or is it just the .34 kernel, that apparently is said to have lots of S3 sleep improvements? joanna. [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 226 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-06-23 13:21 ` Joanna Rutkowska @ 2010-06-23 14:38 ` Konrad Rzeszutek Wilk 2010-06-23 15:08 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 39+ messages in thread From: Konrad Rzeszutek Wilk @ 2010-06-23 14:38 UTC (permalink / raw) To: Joanna Rutkowska Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Michael D Labriola, xen-devel-bounces > >>> I rebased the branch and it is now devel/kms.fixes-0.3 > >>> > >> Which stable branch have you rebased it for (.31, .32, .33?)? > > > > .32. > > > > and then I backported the DRM/TTM/KMS from 2.6.34 to be able to test the > > nouveau driver. > >> > >> Have you tested it with some composting Window Manager (e.g. in KDE or > >> Gnome with enables desktop effects)? > > > > Yes. I think so (isn't that the default thing?). > > No, both KDE and GNOME have composition disabled by default. On KDE, you > need to go to Computer/System Settings/Desktop and then "Enable Desktop > Eff3cts". You might need to click on the "Advanced" tab, and choose > XRender instead of Open GL (and maybe also tick "Disable Functionality > checks"). On my nouveau it just says: "Desktop effects required hardware 3D support." I will try with the Radeon and Intel graphics stuff next week. > > > Played some tuxracer when testing it on Radeon and I think the i915, > > i915 is the Intel card, right? So, it's not served by the nouveau code, > is it? Right... I don't think I actually tested the XRender code then. But I did test the OpenGL code on Radeon and the Intel chipsets that I had. > > > so the OpenGL components worked OK. > > Hmmm, that's interesting. I think I never got Open GL working on > nouveau, even on baremetal (I tested via KDE -- see above). Right. That is expected as the 3D components are not in the nouveau driver yet. Based on "http://nouveau.freedesktop.org/wiki/": "Any 3-D functionality that might exist is still unsupported. Do not ask for instructions to try it. But you can read GalliumHowto in case you are brave enough." > > > I know that 3D don't work on the nouveau driver so hadn't > > tried that. > > > > No worries, 3D desktop effects are overrated ;) All I want is "Expose" :) Based on this: http://en.wikipedia.org/wiki/Xlib and the little example code that comes with it I Expose events do work with Xen dom0 with Xorg 1.8 and with the nouveau driver. .. snip .. > >> Finally, have you tested S3 sleep? (Has anybody actually got pvops0 .31 > >> or .32 support S3 sleep?). > > > > HA! Working on that and S5 right now. Jeremy mentioned he did get S3 > > working, but hadn't tried other modes. S5, S3, and S1 on my SuperMicro > > XF8TN just don't work. Not sure if I have the Xen ACPI hypercalls > > thought in the code base. > > What is the fundamental difference in S3 sleep support between pvops0 > vs. xenlinux, which seems to support S3 sleep quite well. At least the > 2.6.34-xenlinux, the one from OpenSUSE? Or is it just the .34 kernel, > that apparently is said to have lots of S3 sleep improvements? <spreads his arms> Don't know yet. Jeremy just pinged me and said he got on his laptop S3 to suspend working quite well. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-06-23 14:38 ` Konrad Rzeszutek Wilk @ 2010-06-23 15:08 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 39+ messages in thread From: Konrad Rzeszutek Wilk @ 2010-06-23 15:08 UTC (permalink / raw) To: Joanna Rutkowska Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Michael D Labriola, xen-devel-bounces > > > so the OpenGL components worked OK. > > > > Hmmm, that's interesting. I think I never got Open GL working on > > nouveau, even on baremetal (I tested via KDE -- see above). > > Right. That is expected as the 3D components are not in the nouveau driver > yet. Based on "http://nouveau.freedesktop.org/wiki/": > "Any 3-D functionality that might exist is still unsupported. Do not ask > for instructions to try it. But you can read GalliumHowto in case you > are brave enough." And actually, I just tried it (the GalliumHowto) and played both OpenArena and TuxRacer on my Xen Dom0 with the NVidia card. Ok, so 3D effects do work. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-06-23 12:54 ` Konrad Rzeszutek Wilk 2010-06-23 13:21 ` Joanna Rutkowska @ 2010-06-24 19:55 ` Pasi Kärkkäinen 2010-06-24 21:00 ` Konrad Rzeszutek Wilk 1 sibling, 1 reply; 39+ messages in thread From: Pasi Kärkkäinen @ 2010-06-24 19:55 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Michael D Labriola, xen-devel-bounces On Wed, Jun 23, 2010 at 08:54:30AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Jun 23, 2010 at 12:32:57AM +0200, Joanna Rutkowska wrote: > > On 06/17/10 19:51, Konrad Rzeszutek Wilk wrote: > > >>> And my X log ends abruptly after this line: > > >>> (II) NOUVEAU(0): Opened GPU Channel 1 > > >> > > >> > > >> So, I've spent the last two weeks trying to get this to work. > > >> > > > .. > > >> other ones too (hadn't tested yet). However, I am still failing at the same > > >> spot as Michael: the dreaded Opened GPU Channel 1... > > > > > > Fixed! Plus I've tested it on: > > > > > > GeForce 1 256 > > > GeForce 3 NV20 > > > GeForce 4 Ti 4200 > > > GeForce 8600 GT > > > ICH5 82865G > > > ICH7 82G33/G31G > > > ICH8 82Q963/Q965 > > > Matrox G450 > > > Radeon ES1000 > > > Radeon HD 3200 > > > Radeon R100 QD (7200) > > > Radeon RV100QY (7000) > > > Radeon RV710 [Radeon HD 4350] > > > RIVA TNT2 Pro > > > > > > Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM > > > There are two bugs that are creeping up. One of the can be disabled by > > > 'nopat' on the command line. The other, well the other is only seen > > > during shutdown. > > > > > >> > > >> Anyhow.. if you want the patches: > > >> > > >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/kms-fixes > > > > > > I rebased the branch and it is now devel/kms.fixes-0.3 > > > > > Which stable branch have you rebased it for (.31, .32, .33?)? > > .32. > Hey, I just tried devel/kms.fixes-0.3: [root@f13 linux-2.6-xen]# git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-xen .. [root@f13 linux-2.6-xen]# cd linux-2.6-xen/ [root@f13 linux-2.6-xen]# git checkout -b xen/stable-2.6.32.x origin/xen/stable-2.6.32.x [root@f13 linux-2.6-xen]# git pull [root@f13 linux-2.6-xen]# git remote add -f konrad git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git [root@f13 linux-2.6-xen]# git pull Already up-to-date. [root@f13 linux-2.6-xen]# git merge konrad/devel/kms.fixes-0.3 Auto-merging drivers/char/agp/intel-agp.c Auto-merging drivers/gpu/drm/ttm/ttm_bo_vm.c CONFLICT (content): Merge conflict in drivers/gpu/drm/ttm/ttm_bo_vm.c Auto-merging drivers/gpu/drm/ttm/ttm_tt.c Automatic merge failed; fix conflicts and then commit the result. Does it merge ok for you with xen/stable-2.6.32.x? -- Pasi ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel 2010-06-24 19:55 ` Pasi Kärkkäinen @ 2010-06-24 21:00 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 39+ messages in thread From: Konrad Rzeszutek Wilk @ 2010-06-24 21:00 UTC (permalink / raw) To: Pasi Kärkkäinen Cc: Arvind R, Jeremy Fitzhardinge, xen-devel, Joanna Rutkowska, Michael D Labriola, xen-devel-bounces On Thu, Jun 24, 2010 at 10:55:54PM +0300, Pasi Kärkkäinen wrote: > On Wed, Jun 23, 2010 at 08:54:30AM -0400, Konrad Rzeszutek Wilk wrote: > > On Wed, Jun 23, 2010 at 12:32:57AM +0200, Joanna Rutkowska wrote: > > > On 06/17/10 19:51, Konrad Rzeszutek Wilk wrote: > > > >>> And my X log ends abruptly after this line: > > > >>> (II) NOUVEAU(0): Opened GPU Channel 1 > > > >> > > > >> > > > >> So, I've spent the last two weeks trying to get this to work. > > > >> > > > > .. > > > >> other ones too (hadn't tested yet). However, I am still failing at the same > > > >> spot as Michael: the dreaded Opened GPU Channel 1... > > > > > > > > Fixed! Plus I've tested it on: > > > > > > > > GeForce 1 256 > > > > GeForce 3 NV20 > > > > GeForce 4 Ti 4200 > > > > GeForce 8600 GT > > > > ICH5 82865G > > > > ICH7 82G33/G31G > > > > ICH8 82Q963/Q965 > > > > Matrox G450 > > > > Radeon ES1000 > > > > Radeon HD 3200 > > > > Radeon R100 QD (7200) > > > > Radeon RV100QY (7000) > > > > Radeon RV710 [Radeon HD 4350] > > > > RIVA TNT2 Pro > > > > > > > > Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM > > > > There are two bugs that are creeping up. One of the can be disabled by > > > > 'nopat' on the command line. The other, well the other is only seen > > > > during shutdown. > > > > > > > >> > > > >> Anyhow.. if you want the patches: > > > >> > > > >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/kms-fixes > > > > > > > > I rebased the branch and it is now devel/kms.fixes-0.3 > > > > > > > Which stable branch have you rebased it for (.31, .32, .33?)? > > > > .32. > > > > Hey, > > I just tried devel/kms.fixes-0.3: > > [root@f13 linux-2.6-xen]# git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-xen > .. > > [root@f13 linux-2.6-xen]# cd linux-2.6-xen/ > [root@f13 linux-2.6-xen]# git checkout -b xen/stable-2.6.32.x origin/xen/stable-2.6.32.x > [root@f13 linux-2.6-xen]# git pull > > [root@f13 linux-2.6-xen]# git remote add -f konrad git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > [root@f13 linux-2.6-xen]# git pull > Already up-to-date. > > [root@f13 linux-2.6-xen]# git merge konrad/devel/kms.fixes-0.3 > Auto-merging drivers/char/agp/intel-agp.c > Auto-merging drivers/gpu/drm/ttm/ttm_bo_vm.c > CONFLICT (content): Merge conflict in drivers/gpu/drm/ttm/ttm_bo_vm.c > Auto-merging drivers/gpu/drm/ttm/ttm_tt.c > Automatic merge failed; fix conflicts and then commit the result. > > > Does it merge ok for you with xen/stable-2.6.32.x? No. I get the same. The fault is that my patches assumes a bit different tree. What you need is to fixup to this: vma->vm_private_data = bo; - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; + man = &bdev->man[bo->mem.mem_type]; + if (man->flags & TTM_MEMTYPE_FLAG_NEEDS_IOREMAP) + vma->vm_flags |= VM_IO; vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); return 0; ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <d799c4761003120445h57ab1373m31eb0add242ef74c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel [not found] ` <d799c4761003120445h57ab1373m31eb0add242ef74c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-03-16 13:25 ` Thomas Hellstrom 0 siblings, 0 replies; 39+ messages in thread From: Thomas Hellstrom @ 2010-03-16 13:25 UTC (permalink / raw) To: Arvind R Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, dri-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR Arvind R wrote: > On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq-X3B1VOXEql0@public.gmane.org> wrote: > >> I'm adding dri-devel@ to CC, since this suggested patch touches >> TTM code, and none of the Nouveau code. TTM patches go via >> dri-devel@. >> >> Thanks. >> >> >> This is a NAK in its current form. First, At mmap() time, the placement may not be known, and even if it is known, the placement may change. Second, VM_IO is used to avoid including bos in core dumps, and make sure get_user_pages() isn't lazily called on BOs. That would cause the lock inversion prevention to fail. Third, I'm not sure the Xen strategy will work for VM_MIXEDMAP, which may contain both IO- and real pages? Thanks, Thomas >> On Wed, 10 Mar 2010 18:51:21 +0530 >> Arvind R <arvino55-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >> >>> Hi, >>> Following is a simple patch that is needed in nouveau to get >>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's >>> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is >>> almost the mainline merge), was substituted into the kernel-tree. >>> All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) >>> used of the same day. >>> >>> Patch: >>> diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c >>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c >>> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 >>> 10:19:28.000000000 +0530 >>> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 >>> 17:28:59.000000000 +0530 >>> @@ -271,7 +271,10 @@ >>> */ >>> >>> vma->vm_private_data = bo; >>> - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | >>> VM_DONTEXPAND; >>> + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | >>> VM_DONTEXPAND; >>> + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & >>> TTM_PL_FLAG_TT)) >>> + vma->vm_flags |= VM_IO; >>> + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); >>> return 0; >>> out_unref: >>> ttm_bo_unref(&bo); >>> >>> > sorry for the typo and other procedural errors. > the last added line should be > + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags) > > >>> This patch is necessary because, in Xen, PFN of a page is >>> virtualised. So physical addresses >>> for DMA programming needs to use the MFN. Xen transparently does >>> the correct translation >>> using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, >>> then Xen assumes that the backing >>> memory is in the IOMEM space, and PFN equals MFN. If not set, >>> page_to_pfn() returns MFN. >>> >>> The patch enables the ttm_bo_vm_fault() handler to behave >>> correctly under Xen, and has no >>> side-effects on normal (not under Xen) operations. The use of >>> TTM_PL_FLAG_TT in the >>> check assumes that all other placements are backed by device >>> memory or IO. If there are >>> any other placements that use system memory, that flag has to be >>> OR'ed into the check. >>> >>> The above patch has no implications on a normal kernel or a Xen >>> pv_ops kernel booted without >>> the Xen hypervisor. My testing is on a debian-lenny environment >>> on a Core2 processor with >>> nVidia GeForce 9400 GT. >>> > Efficacy of patch: > successful flightgear run on dom0 AND bareboot! > > Arvind R. > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/dri-devel > ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2010-06-24 21:00 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-10 13:21 [Patch RFC] nouveau accelerated on Xen pv-ops kernel Arvind R
[not found] ` <d799c4761003100521h663c82eepda85f3f0309828c2-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-11 11:02 ` [Patch RFC] ttm: " Pekka Paalanen
2010-03-12 5:27 ` Arvind R
2010-03-28 10:20 ` Joanna Rutkowska
2010-03-30 5:50 ` Arvind R
2010-03-12 12:45 ` Arvind R
2010-03-12 13:20 ` Michael D Labriola
2010-03-13 22:03 ` Joanna Rutkowska
2010-03-15 14:44 ` Michael D Labriola
2010-03-15 23:13 ` Jeremy Fitzhardinge
2010-03-16 7:18 ` Arvind R
2010-03-16 16:48 ` Michael D Labriola
2010-03-16 16:40 ` Michael D Labriola
2010-03-16 17:21 ` Konrad Rzeszutek Wilk
2010-03-16 19:39 ` Michael D Labriola
2010-03-16 19:41 ` Konrad Rzeszutek Wilk
2010-03-17 1:01 ` Konrad Rzeszutek Wilk
2010-03-18 6:09 ` Arvind R
2010-03-19 15:29 ` Michael D Labriola
2010-03-20 6:01 ` Arvind R
2010-03-22 21:14 ` Michael D Labriola
2010-03-23 6:21 ` Arvind R
2010-03-23 12:45 ` Michael D Labriola
2010-03-23 13:27 ` Michael D Labriola
2010-03-25 7:05 ` Arvind R
2010-03-25 7:18 ` Jeremy Fitzhardinge
2010-03-29 14:42 ` Michael D Labriola
2010-06-09 17:43 ` Konrad Rzeszutek Wilk
2010-06-09 18:39 ` Pasi Kärkkäinen
2010-06-09 19:31 ` Konrad Rzeszutek Wilk
2010-06-17 17:51 ` Konrad Rzeszutek Wilk
2010-06-22 22:32 ` Joanna Rutkowska
2010-06-23 12:54 ` Konrad Rzeszutek Wilk
2010-06-23 13:21 ` Joanna Rutkowska
2010-06-23 14:38 ` Konrad Rzeszutek Wilk
2010-06-23 15:08 ` Konrad Rzeszutek Wilk
2010-06-24 19:55 ` Pasi Kärkkäinen
2010-06-24 21:00 ` Konrad Rzeszutek Wilk
[not found] ` <d799c4761003120445h57ab1373m31eb0add242ef74c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-16 13:25 ` Thomas Hellstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).