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

[Arvind R <arvino55@xxxxxxxxx>]

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?

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@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