xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/18/2010 02:09:08 AM:
> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola <mlabriol@xxxxxxxx>
wrote:
> > Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 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@xxxxxxxx
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home