WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops k

To: Arvind R <arvino55@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel
From: Michael D Labriola <mlabriol@xxxxxxxx>
Date: Mon, 22 Mar 2010 17:14:16 -0400
Cc: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Mon, 22 Mar 2010 14:15:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <d799c4761003192301p327cf432rd2f52f93bc06f3d4@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/20/2010 02:01:54 AM:

> On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola <mlabriol@xxxxxxxx> 
wrote:
> > 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
> >
>  - 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@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

<Prev in Thread] Current Thread [Next in Thread>