From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arvind R Subject: Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel Date: Tue, 23 Mar 2010 11:51:31 +0530 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=0016e6d2607a1ede1b048271d38c Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Michael D Labriola Cc: xen-devel-bounces@lists.xensource.com, Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Joanna Rutkowska , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --0016e6d2607a1ede1b048271d38c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 23, 2010 at 2:44 AM, Michael D Labriola wro= te: > xen-devel-bounces@lists.xensource.com wrote on 03/20/2010 02:01:54 AM: > >> On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola > wrote: >> > xen-devel-bounces@lists.xensource.com wrote on 03/18/2010 02:09:08 AM: >> > >> >> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola > >> > wrote: >> >> > Konrad Rzeszutek Wilk 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. =A0If you run it under strace, can you identify whic= h >> >> > mapping >> >> >> > > the fault is happening in? >> >> >> > >> >> >> > I've attached the output of 'strace -o strace-Xorg Xorg'. > =A0Figuring >> >> > out >> >> >> > which mapping the fault is happening in is a little over my > head, >> > I'm >> >> >> > afraid. =A0If you need different arguments to strace, let me kno= w > 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... ;-) > =A0A >> > while >> >> > back, I backported the important stuff from the Nouveau kernel git >> > tree >> >> > back to v2.6.31. =A0Basically 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. =A0Sounds retarded, I know, but it was a >> > pretty >> >> > interesting way to get myself up to speed with the code base. =A0Th= e >> >> > 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. =A0Also 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. =A0(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. =A0It used to wor= k >> > fine on >> >> > my old GeForce2 MX based systems in Xen. =A0Arvind's patch made it > work >> > on >> >> > my nice new systems in Xen, but broke it on the old ones. > =A0Everything >> >> > 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" >> >> > =A0Identifier "foo" >> >> > =A0Driver "nouveau" >> >> > EndSection >> >> > >> >> > Otherwise it uses the 'nv' driver... =A0and 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. =A0It was fedor= a >> > 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) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D 0x932= 4000 >> >> >> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) =3D 38 >> >> >> ioctl(11, 0xc0106445, 0x930a908) =A0 =A0 =A0 =A0=3D 0 >> >> >> ioctl(11, 0x400c6444, 0xbfd2a210) =A0 =A0 =A0 =3D 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: >> >> >> >> >> >> =A0 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=3D1 as module paramete= r? >> > >> > I wasn't setting any module params for nouveau. =A0Adding 'options > nouveau >> > modeset=3D1' to modprobe.conf didn't seem to make any difference. >> > >> > I've got the following in my .config: >> > >> > CONFIG_VGA_CONSOLE=3Dy >> > CONFIG_FB=3Dy >> > CONFIG_FB_VGA16=3Dm >> > CONFIG_FB_VESA=3Dy >> > CONFIG_FB_EFI=3Dy >> > CONFIG_FB_NVIDIA=3Dm >> > CONFIG_FB_NVIDIA_I2C=3Dy >> > CONFIG_FB_NVIDIA_BACKLIGHT=3Dy >> > >> =A0- EMBEDDED =A0- this will enable VGA_CONSOLE selection. Set sub-menu >> choices as needed >> =A0- VGA_CONSOLE builtin >> =A0- FB as module >> =A0- FRAMEBUFFER_CONSOLE as a module. Enables late loading of nouveau >> =A0* Foll. required to avoid cfb_copyarea, cfb_fillrectangle, >> cfb_imageblit linking problems with >> =A0 =A0 out-of-tree nouveau builds >> =A0- FB_VGA16 as module - supported by all nVidia cards. >> =A0 =A0or >> =A0- 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? =A0My 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. =A0Now I've got everything compiled as modules and can load t= hem > post-boot to switch to the nouveau framebuffer console. =A0That actually > didn't change the X behavior at all, though. =A0I still get the exact sam= e > "X: Corrupted page table" messages in dmesg and my Xorg.log is just endin= g > with "NOUVEAU(0): Opened GPU channel 1". This is strange - channel 1 is the console channel. This appears in dmesg o= n nouveaufb initialisation before EDID probe to find connected outputs. Start X manually to avoid confusion of logs. Have attached ttm_xen.patch which updates vm_page_prot after changing flags= . This is not done in the mainline drm-tree. But in the xen (old) drm-tree this is done in BOTH ttm_bo_mmap AND ttm_fbdev_mmap - and the attached patch does both, along with the conditional VM_IO in bo_mmap. And the second vm_page_prot update is for fbdev_mmap which corresponds to channel 1. Cross fingers and = try! > If the old nvidiafb is loaded, nouveau cannot install (and vice-versa) > > Well, everything seems to load just fine. =A0I get a nice teeny font and > dmesg messages saying I'm using nouveaufb. You should have got it earlier too - didn't you? >> does NOT affect unaccelerated X on the older cards? > > Which accelerated modes are you refering to? =A0My 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. Right. But gallium's swrast_dri AND dri_nouveau are still 'unsupported', to be tried at own risk. nouveau_dri was working enough to run fgfs with mesa-7.7, but now with mesa-7.9, glxgears works not fgfs - segfaults in libdrm_nouveau. >> Xorg used to hang saying 'Opened Channel 2' and not 1. > > Now that's strange. =A0Every single one of my boxes says Opened Channel 1= , > with now reference to channel 2 at all. Channel 1 in dmesg/syslog; Xorg.log snippet: (II) LoadModule: "shadowfb" (II) Loading /usr/lib/xorg/modules/libshadowfb.so (II) Module shadowfb: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (--) Depth 24 pixmap format is 32 bpp (II) NOUVEAU(0): Opened GPU channel 2 (II) NOUVEAU(0): [DRI2] Setup complete (II) NOUVEAU(0): GART: 512MiB available (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer (II) EXA(0): Driver allocated offscreen pixmaps (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (II) UploadToScreen (II) DownloadFromScreen (=3D=3D) NOUVEAU(0): Backing store disabled (=3D=3D) NOUVEAU(0): Silken mouse enabled (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video. (II) NOUVEAU(0): [XvMC] Extension initialized. Try with Option "ShadowFB" "true" in Device section of xorg.conf (turns off acceleration) to check. The optio= n also sets NoAccel on and X should use the FB device So the cards that don't work are AGP cards? --0016e6d2607a1ede1b048271d38c Content-Type: text/x-diff; charset=US-ASCII; name="ttm_xen.patch" Content-Disposition: attachment; filename="ttm_xen.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g74aei6b0 LS0tIG5vdXZlYXUta2VybmVsLTAuMC4xK2dpdDIwMTAwMzIyLm9yaWcvZHJpdmVycy9ncHUvZHJt L3R0bS90dG1fYm9fdm0uYwkyMDEwLTAyLTExIDEyOjM4OjQyLjAwMDAwMDAwMCArMDUzMAorKysg bm91dmVhdS1rZXJuZWwtMC4wLjErZ2l0MjAxMDAzMjIvZHJpdmVycy9ncHUvZHJtL3R0bS90dG1f Ym9fdm0uYwkyMDEwLTAzLTIyIDEzOjQ4OjExLjAwMDAwMDAwMCArMDUzMApAQCAtMjcxLDcgKzI3 MSwxMSBAQAogCSAqLwogCiAJdm1hLT52bV9wcml2YXRlX2RhdGEgPSBibzsKLQl2bWEtPnZtX2Zs YWdzIHw9IFZNX1JFU0VSVkVEIHwgVk1fSU8gfCBWTV9NSVhFRE1BUCB8IFZNX0RPTlRFWFBBTkQ7 CisJdm1hLT52bV9mbGFncyB8PSBWTV9SRVNFUlZFRCB8IFZNX01JWEVETUFQIHwgVk1fRE9OVEVY UEFORDsKKwlpZiAoISgoYm8tPm1lbS5wbGFjZW1lbnQgJiBUVE1fUExfTUFTS19NRU0pICYgVFRN X1BMX0ZMQUdfVFQpKQorCQl2bWEtPnZtX2ZsYWdzIHw9IFZNX0lPOworICAgIHZtYS0+dm1fcGFn ZV9wcm90ID0gdm1fZ2V0X3BhZ2VfcHJvdCh2bWEtPnZtX2ZsYWdzKTsKKwogCXJldHVybiAwOwog b3V0X3VucmVmOgogCXR0bV9ib191bnJlZigmYm8pOwpAQCAtMjg3LDYgKzI5MSw3IEBACiAJdm1h LT52bV9vcHMgPSAmdHRtX2JvX3ZtX29wczsKIAl2bWEtPnZtX3ByaXZhdGVfZGF0YSA9IHR0bV9i b19yZWZlcmVuY2UoYm8pOwogCXZtYS0+dm1fZmxhZ3MgfD0gVk1fUkVTRVJWRUQgfCBWTV9JTyB8 IFZNX01JWEVETUFQIHwgVk1fRE9OVEVYUEFORDsKKyAgICB2bWEtPnZtX3BhZ2VfcHJvdCA9IHZt X2dldF9wYWdlX3Byb3Qodm1hLT52bV9mbGFncyk7CiAJcmV0dXJuIDA7CiB9CiBFWFBPUlRfU1lN Qk9MKHR0bV9mYmRldl9tbWFwKTsK --0016e6d2607a1ede1b048271d38c Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --0016e6d2607a1ede1b048271d38c--