Date: Mon, 18 Aug 2008 22:40:08 -0700 From: vehemens <vehemens@verizon.net> To: Coleman Kane <cokane@freebsd.org> Cc: freebsd-x11@freebsd.org Subject: Re: [CFT] drm updates Message-ID: <200808182240.08874.vehemens@verizon.net> In-Reply-To: <1219011377.1960.4.camel@localhost> References: <200808142307.32015.vehemens@verizon.net> <1219006437.21310.12.camel@localhost> <1219011377.1960.4.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
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 work > > > > > > > > with my RS690. Right now my GPU is unusable for EXA or DRI > > > > > > > > using xf86-video-ati (intermittently works) or > > > > > > > > xf86-video-radeonhd (never works, displays artifacts, then > > > > > > > > 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 are in > > > > > > > the official FreeBSD src/ports trees. > > > > > > > > > > > > > > I'll send you a xf86-video-radeonhd tarball that I just created > > > > > > > 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 well. > > > > > > > > > > > > I've been tracking the following masters from fd.o git: > > > > > > > > > > > > mesa/drm dri2proto fontsproto glproto inputproto kbproto libX11 > > > > > > libXdamage libXfont libXtst libxcb libxtrans mesa/mesa > > > > > > xorg-server x11proto randrproto xcb-proto xextproto xf86driproto > > > > > > xproto libXext libXi libXrandr libpciaccess libxkbfile libxkbui > > > > > > 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 that > > > > > much. > > > > > > > > > > When you update mesa, do you update both the dri and libGL ports? > > > > > 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 tracking > > > > 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 system > > when I try to use EXA. When I use EXA+DRI in the radeonhd driver, I get > > 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 image > > of the text console to the root window, the one I would see before the > > 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 to > > begin to load, then changes the video mode and blanks the screen. Once > > the screen has been cleared, the server freezes and no loading proceeds. > > 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 more > > 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 to > > 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 works > > 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 where > > 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 the > 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: WARNING > 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: WARNING > 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: WARNING > 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: WARNING > 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: WARNING > 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: WARNING > 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... Upgrading my M2A-VM bios to version 1603 was the trick to getting rid of a nasty flicker problem. Now to repeat the various driver combinations again to see what other effects the update had. On a side note, I haven't been able to run any of the recent xservers without getting a segmentation violation in the mouse driver at startup. Are you seeing this problem as well? works: 2008-07-04 00:04:19 d78bebb20a00e8519788c75c90b467a5750c78be broken: 2008-07-08 02:39:00 66fb253082ea42179180303393e48846208987fa
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808182240.08874.vehemens>