Date: Mon, 23 Mar 2009 09:55:23 +0300 From: Anonymous <swell.k@gmail.com> To: Robert Noland <rnoland@FreeBSD.org> Cc: freebsd-x11 <freebsd-x11@freebsd.org> Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) Message-ID: <86ljqwsp7o.fsf@gmail.com> References: <1237680263.1938.10.camel@balrog.2hip.net> <86r60pp8c0.fsf@gmail.com> <1237763230.1694.0.camel@balrog.2hip.net> <86ab7dxf5c.fsf@gmail.com> <1237768535.1712.3.camel@balrog.2hip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Noland <rnoland@FreeBSD.org> writes: > On Mon, 2009-03-23 at 03:21 +0300, Anonymous wrote: >> Robert Noland <rnoland@FreeBSD.org> writes: >> >> > On Mon, 2009-03-23 at 00:15 +0300, Anonymous wrote: >> >> Robert Noland <rnoland@FreeBSD.org> writes: >> >> >> >> > Ok, this patch should work on NV50 chips also. >> >> > >> >> > What you get is EXA and Xv. >> >> > >> >> > You still need: >> >> > >> >> > A recent -CURRENT or -STABLE. >> >> > >> >> > git master of libdrm and xf86-video-nouveau. >> >> > >> >> > This patch. >> >> > >> >> > Things I've figured out since the last patch... >> >> > >> >> > On NV50 class hardware you need to have a compositing manager running >> >> > for Xv to work. That means xcompmgr, metacity with composite enabled, >> >> > xfce (rumored to work as well, haven't tried). If your running Gnome >> >> > with metacity, open gconf-editor and go to apps->metacity->general and >> >> > check the composite box. >> >> [...] >> >> > >> >> > http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch >> >> > >> >> > robert. >> >> >> >> - This error in Xorg.log is still present >> >> >> >> (II) NOUVEAU(0): [DRI] installation complete >> >> (EE) NOUVEAU(0): [dri] unable to reference front buffer: -19 >> > >> > Ok, update your libdrm... this was fixed in the last few days. >> > >> > robert. >> > >> >> Oops, looks like libdrm installed here wasn't latest. Updated and this >> error is gone now. >> >> >> Should I ignore it? >> >> >> >> >> >> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo: [drm] DMA_R_PROTECTIONinfo: [drm] , nStatus:info: [drm] >> >> info: [drm] PGRAPH_ERROR - Ch 2/2 Class 0x8297 Mthd 0x15e0 Data 0x00000000:0x00000000 >> >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* magic set 1: >> >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x80000000 >> >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xfdb76b7b >> >> >> >> Should I ignore them? >> >> Looks like this one is not fixed in r190296M. Look into logs below. > > This is a fencing issue, I haven't ported the drm fence manager. Do you > know what you are doing to trigger it? I can't seem to make it occur > here... I can reproduce it on xserver-1.6 just by `X -config test.conf', where test.conf contains nothing but Device section which specifies to use nouveau ddx. I guess it's related to the problem with xcompmgr. They usually appear together. > >> >> >> >> - Launching `xcompmgr -a' is tricky. Most of the time it just leaves >> >> screen in unusable state, it's not possible to switch to console or >> >> move pointer. I want to help debug this one. Here are logs: >> >> http://pastebin.com/m1ca3fc2f >> >> http://pastebin.com/m579d358e > > FWIW, I don't seem to have any trouble enabling / disabling composite, > so this may be a bug in git xserver or libraries. It's same for xserver-1.6. I guess it's because I usually try to use vt switch when Xserver hangs on restart and then reboot. After reboot xcompmgr doesn't work fine and leaves screen unusable. Workaround is to set hw.drm.msi=0 once and next boot should work fine without it with MSI enabled. > > robert. > >> rebuild kernel, libdrm, xf86-video-nouveau, xserver just in case and >> reproduced the problem again >> http://pastebin.com/m2be24e75 >> http://pastebin.com/m6c80e1e
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86ljqwsp7o.fsf>