[CFT] drm updates

[Coleman Kane]

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

-- 
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/20080817/790f267f/attachment.pgp