> > > 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home