Date: Tue, 19 Aug 2008 10:13:41 -0400 From: Coleman Kane <cokane@FreeBSD.org> To: vehemens <vehemens@verizon.net> Cc: freebsd-x11@freebsd.org Subject: Re: [CFT] drm updates Message-ID: <1219155221.1801.3.camel@localhost> In-Reply-To: <200808182240.08874.vehemens@verizon.net> References: <200808142307.32015.vehemens@verizon.net> <1219006437.21310.12.camel@localhost> <1219011377.1960.4.camel@localhost> <200808182240.08874.vehemens@verizon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-ZbfhHssoBVI8pBbfcg09 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-08-18 at 22:40 -0700, vehemens wrote: > On Sunday 17 August 2008 03:16:17 pm Coleman Kane wrote: > > On Sun, 2008-08-17 at 16:53 -0400, Coleman Kane wrote: > > > On Sat, 2008-08-16 at 16:35 -0700, vehemens wrote: > > > > On Friday 15 August 2008 06:05:13 pm Coleman Kane wrote: > > > > > On Fri, 2008-08-15 at 17:05 -0700, vehemens wrote: > > > > > > On Friday 15 August 2008 04:13:31 pm Coleman Kane wrote: > > > > > > > On Fri, 2008-08-15 at 16:12 -0700, vehemens wrote: > > > > > > > > On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > > > > > > > > > ... > > > > > > > > > Do you host any of the patches publicly right now? I'd be > > > > > > > > > more than happy to test them out and see how well they wo= rk > > > > > > > > > with my RS690. Right now my GPU is unusable for EXA or DR= I > > > > > > > > > using xf86-video-ati (intermittently works) or > > > > > > > > > xf86-video-radeonhd (never works, displays artifacts, the= n > > > > > > > > > screeches to a halt). > > > > > > > > > ... > > > > > > > > > > > > > > > > After thinking about your stability problems a bit more, > > > > > > > > xserver has recently received a number of EXA improvements, > > > > > > > > R500 MESA/DRM support is fairly recent, and the drivers are= a > > > > > > > > moving target a well. Few (none?) of these improvements ar= e in > > > > > > > > the official FreeBSD src/ports trees. > > > > > > > > > > > > > > > > I'll send you a xf86-video-radeonhd tarball that I just cre= ated > > > > > > > > and tested with my HD 2660 PRO. It may help, but I suspect > > > > > > > > that other parts of the X tree will need to be updated as w= ell. > > > > > > > > > > > > > > I've been tracking the following masters from fd.o git: > > > > > > > > > > > > > > mesa/drm dri2proto fontsproto glproto inputproto kbproto libX= 11 > > > > > > > libXdamage libXfont libXtst libxcb libxtrans mesa/mesa > > > > > > > xorg-server x11proto randrproto xcb-proto xextproto xf86dripr= oto > > > > > > > xproto libXext libXi libXrandr libpciaccess libxkbfile libxkb= ui > > > > > > > xf86-video-ati xf86-video-radeonhd xf86-input-keyboard > > > > > > > xf86-input-mouse > > > > > > > > > > > > Interesting. The list is a bit shorter then mine. I don't see > > > > > > pixman as well as a few others. Not sure if it matters all tha= t > > > > > > much. > > > > > > > > > > > > When you update mesa, do you update both the dri and libGL port= s?=20 > > > > > > Ditto for libdrm and kernel drm? > > > > > > > > > > > > Guess I'll checkout my builds on a RS690 and see what happens. > > > > > > > > > > D'oh! Yeah, pixman should be included in that list too. I am trac= king > > > > > it as well. I can't get very far on the latest X.org without it! > > > > > > > > Almost all combinations of ddx/dri/drm drivers hangs my am64 box. > > > > > > > > Did get X running by using the radeonhd and dri swrast drivers, as = well > > > > as removing the other drivers. > > > > > > > > System reports it has dri, but compiz or glgears doesn't run. > > > > > > > > What combinations worked for you? > > > > > > Basically, I can use radeonhd or ati from git master without trouble = as > > > long as I am not using DRI. The radeonhd driver also freezes my syste= m > > > when I try to use EXA. When I use EXA+DRI in the radeonhd driver, I g= et > > > an X root window that has a bunch of artifacts displayed on it. > > > Interestingly enough, it seems like it dumps a bitmap of the last ima= ge > > > of the text console to the root window, the one I would see before th= e > > > video mode switched after running startx. The mouse cursor works for = a > > > little while, as it seems compiz is beginning to load from the > > > gnome-session manager. I never actually see any screen updates occur > > > while it is starting up. Then, at some point the system just freezes = and > > > I need to hard-power-off the laptop, by holding down the power button > > > until it is forced off. > > > > > > With the ati driver and DRI+EXA, running startx causes the X server t= o > > > begin to load, then changes the video mode and blanks the screen. Onc= e > > > the screen has been cleared, the server freezes and no loading procee= ds. > > > I can reset the system by doing an ALT-CTRL-DELETE or by doing > > > soft-power-off by pressing, then releasing the power button (which > > > FreeBSD-ACPI catches and gracefully shuts the machine down). The > > > shutdown process must be held up by something in bufdaemon or other > > > kernel service that typically counts down the "remaining" during a > > > normal shutdown, of course I can't see which with the X server owning > > > the display. Eventually the system is shutdown or restarted. > > > > > > At some point back in early June, it all started to work for me > > > sometimes. Robert Noland threw a bunch of patches my way that fixed > > > numerous locking issues in the kernel, which gradually made things mo= re > > > reliable for me. At some point in July, some commits to the sources > > > resulted in intermittent crashing in the EXA code, which I was able t= o > > > reproduce with/without DRI enabled (always with EXA), when browsing > > > various websites with firefox. > > > > > > Eventually, later on in July, I began to get the results that I > > > currently get with DRI enabled. That is to say, it no longer ever wor= ks > > > for me under the ati driver (freezes X server at startup). I've never > > > been able to get radeonhd to give me operational DRI support. If I am > > > not using EXA, but have DRI enabled, radeonhd will start up properly, > > > but will not display any DRI output (instead just displaying black wh= ere > > > the DRI stuff should be rendered). > > > > When I am using the xf86-video-ati driver, and I enable DRI, the server > > never finishes starting (video made changes, but the root window and th= e > > cursor is never displayed). The following message is spammed from the > > kernel (and ends up in /var/log/messages): > > > > info: [drm] wait for fifo failed status : 0x9001C100 0x00080000 > > > > For some reason, through a number of the failures I am now seeing the > > following spammed to messages as well, when the server fails: > > > > Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0106407 Aug 17 17:51:03 erwin kernel: WAR= NING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106401 = Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0106401 Aug 17 17:51:03 erwin kernel: WAR= NING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106407 = Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0286415 Aug 17 17:51:03 erwin kernel: WAR= NING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0286415 = Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0106426 Aug 17 17:51:03 erwin kernel: WAR= NING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106426 = Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0086420 Aug 17 17:51:03 erwin kernel: WAR= NING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffff80086422 = Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffff8008642a Aug 17 17:51:03 erwin kernel: WAR= NING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106438 = Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0286415 > > > > I took a glance, and the "cmd" field in drm_ioctl_desc is an "unsigned > > long", so I am now curious if perhaps this sign extension is resulting > > in the wrong "cmd" value being passed to the drm ioctl handler, in my > > amd64 case... >=20 > Upgrading my M2A-VM bios to version 1603 was the trick to getting rid of = a=20 > nasty flicker problem. Now to repeat the various driver combinations aga= in=20 > to see what other effects the update had. >=20 > On a side note, I haven't been able to run any of the recent xservers wit= hout=20 > getting a segmentation violation in the mouse driver at startup. Are you= =20 > seeing this problem as well? > works: > 2008-07-04 00:04:19 > d78bebb20a00e8519788c75c90b467a5750c78be > broken: > 2008-07-08 02:39:00 > 66fb253082ea42179180303393e48846208987fa Yeah, you'll need to update to the latest inputproto, libXi, and the xf86-input-mouse driver. The bsd-specific mouse bits gots moved around and ar no longer in the xserver. They are now part of the mouse driver code, iirc. I needed commit f3f0a5520ed7edac3867a97f5a001b91c870563e to xf86-input-mouse. The message that the server throws is highly unhelpful in this situation. --=20 Coleman Kane --=-ZbfhHssoBVI8pBbfcg09 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkiq1REACgkQcMSxQcXat5dQmQCeNGJ5UOhwl8QEvpAkSX4vJ/5f 42cAn1st6hXeJocw8S8SyNJ2atMizvi5 =Drbv -----END PGP SIGNATURE----- --=-ZbfhHssoBVI8pBbfcg09--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1219155221.1801.3.camel>