[CFT] drm updates

Tue Aug 19 14:14:33 UTC 2008

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 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

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.

-- 
Coleman Kane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080819/f4454abd/attachment.pgp