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

[Arvind R <arvino55@xxxxxxxxx>]

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

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel