Date: Mon, 23 Mar 2009 03:21:00 -0500 From: Robert Noland <rnoland@FreeBSD.org> To: Anonymous <swell.k@gmail.com> Cc: freebsd-x11 <freebsd-x11@freebsd.org> Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) Message-ID: <1237796460.2110.4.camel@balrog.2hip.net> In-Reply-To: <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> <86ljqwsp7o.fsf@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-6mTyHTy6bn1sxav0ZxLJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-03-23 at 09:55 +0300, Anonymous wrote: > Robert Noland <rnoland@FreeBSD.org> writes: >=20 > > On Mon, 2009-03-23 at 03:21 +0300, Anonymous wrote: > >> Robert Noland <rnoland@FreeBSD.org> writes: > >>=20 > >> > On Mon, 2009-03-23 at 00:15 +0300, Anonymous wrote: > >> >> Robert Noland <rnoland@FreeBSD.org> writes: > >> >>=20 > >> >> > 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 run= ning > >> >> > for Xv to work. That means xcompmgr, metacity with composite ena= bled, > >> >> > xfce (rumored to work as well, haven't tried). If your running G= nome > >> >> > with metacity, open gconf-editor and go to apps->metacity->genera= l and > >> >> > check the composite box. > >> >> [...] > >> >> > > >> >> > http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch > >> >> > > >> >> > robert. > >> >>=20 > >> >> - This error in Xorg.log is still present > >> >>=20 > >> >> (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. > >> > > >>=20 > >> Oops, looks like libdrm installed here wasn't latest. Updated and this > >> error is gone now. > >>=20 > >> >> Should I ignore it? > >> >>=20 > >> >>=20 > >> >> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERR= ORinfo: [drm] DMA_R_PROTECTIONinfo: [drm] , nStatus:info: [drm]=20 > >> >> info: [drm] PGRAPH_ERROR - Ch 2/2 Class 0x8297 Mthd 0x15e0 Da= ta 0x00000000:0x00000000 > >> >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* magic set = 1: > >> >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x0040890= 0: 0x80000000 > >> >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x0040890= 4: 0xfdb76b7b > >> >>=20 > >> >> Should I ignore them? > >>=20 > >> 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 yo= u > > know what you are doing to trigger it? I can't seem to make it occur > > here... >=20 > 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. I've seen this a couple of times, but never figured out what is triggering it yet. I'll look through the code some more and see if I can find it... > > > >> >>=20 > >> >> - Launching `xcompmgr -a' is tricky. Most of the time it just leave= s > >> >> 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. >=20 > 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. >=20 > Workaround is to set hw.drm.msi=3D0 once and next boot should work fine > without it with MSI enabled. Yeah, we are probably the only ones running with msi enabled... We are the only ones running msi on radeons and I did have to modify the interrupt handling a little to support it, but I had info from amd on how to do it... I need to poke around the registers and see if i see anything interesting... robert. > > > > robert. > > > >> rebuild kernel, libdrm, xf86-video-nouveau, xserver just in case and > >> reproduced the problem again > >> http://pastebin.com/m2be24e75 > >> http://pastebin.com/m6c80e1e --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD --=-6mTyHTy6bn1sxav0ZxLJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknHRmwACgkQM4TrQ4qfRONzYACfWY4lBw1KgBLRoUW+G7tV+2L9 cfEAnjWzrtWjLFbtxWgA7Q6muxtCzdHA =7fYy -----END PGP SIGNATURE----- --=-6mTyHTy6bn1sxav0ZxLJ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1237796460.2110.4.camel>