freebsd7 (and 8), radeon, xorg-server -> deadlock or so

[Robert Noland]

On Thu, 2010-02-11 at 08:49 +0100, Ulrich Spörlein wrote:
> On Wed, 10.02.2010 at 12:08:12 -0600, Robert Noland wrote:
> > On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote:
> > > On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote:
> > > > I have a strong suspicion that the issue is with bus_dma.  If this is a
> > > > pci based card, then it is trying to allocate 32MB of contiguous
> > > > physical ram when the drm device is opened.  This usually succeeds the
> > > > first time that the driver opens the device, but later, after memory has
> > > > become fragmented, this can become an issue.  As I have mentioned, I
> > > > have code that reworks this whole process and I'll try and make a patch
> > > > available soon, but my I don't have a lot of time now, so it might be
> > > > the weekend before I can rebase the code and get a clean patch.
> > > 
> > > No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without
> > > the recent Xorg update (haven't done that yet) I usually startx right after
> > > boot, and this usually works fine.
> > > 
> > > One time I had massive ZFS/git jobs running headless first and wanted to
> > > startx afterwards. X11 took quite some time to come up and although
> > > window "switching" was snappy, *moving* windows around was slow as hell,
> > > window contents were re-drawing at ~1FPS.
> > > 
> > > This also seems to always happen if I stop X11 and startx it again.
> > > So I made a diff from a regular Xorg startup against the slow one:
> > > 
> > > --- Xorg.0.log  2010-02-09 20:59:16.000000000 +0100
> > > +++ Xorg.slow.log       2010-01-31 11:04:08.000000000 +0100
> > > ...
> > > @@ -599,49 +599,22 @@
> > >  (II) RADEON(0): [drm] added 1 reserved context for kernel
> > >  (II) RADEON(0): X context handle = 0x1
> > >  (II) RADEON(0): [drm] installed DRM signal handler
> > > -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000
> > > -(II) RADEON(0): [pci] ring handle = 0xed1a5000
> > > -(II) RADEON(0): [pci] Ring mapped at 0x802aa0000
> > > -(II) RADEON(0): [pci] Ring contents 0x00000000
> > > -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000
> > > -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000
> > > -(II) RADEON(0): [pci] Ring read ptr contents 0x00000000
> > > -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000
> > > -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c00000
> > > -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000
> > > -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000
> > > -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000
> > > -(II) RADEON(0): [drm] register handle = 0xfe8e0000
> > > -(II) RADEON(0): [dri] Visual configs initialized
> > > +(EE) RADEON(0): [pci] Out of memory (-12)
> > 
> > Yes, drm failed to allocate the 32MB to back the GART, so drm was
> > disabled.  Hopefully, the new allocation strategy will resolve this
> > since it will just require 32MB of physical ram below 4GB without
> > needing it to be contiguous.
> 
> Hmm, given that today, 32MB isn't really that much, wouldn't it make
> more sense to have radeon(4) reserve those 32MB on load and never let
> go? I have radeon_load=YES set in loader.conf so it has a fair chance to
> always get it's 32MB contig. memory during startup. Given ZFS' memory
> hunger, there may not be enough free physical RAM below 4GB ...

Ok, I've put up a patch at:

http://people.freebsd.org/~rnoland/drm-radeon-test.patch

This is sort of a mega patch and includes:

Re-worked drm mapping code, that ensures that we don't end up
incorrectly mapping certain maps with overlapping offsets.  This
generally shows up as the ring buffer not being cleared (contents != 0
in xorg.log) which leads to corruption and other bad behavior.

Re-written scatter gather allocation code.  This interacts directly with
the VM system, rather than using bus_dma to allow us to grab
non-contiguous pages for the scatter gather backing of the GART.  It
also makes it easier to handle the caching mode of the backing pages.

Disable cache snooping on radeon cards, since we have write combining
set properly now.

I have at least done a test build on -CURRENT with this patch, but I
haven't had time to do much else without the rest of the code in my
tree.  I've been running most all of this code for a month or two now at
least, so it is mostly just a question of whether or not I got all of
the conflicts sorted out properly when I made this patch.

The re-mapping code has the most widespread impact and has been tested
on radeon r600 amd64, intel g45 i386 and mga amd64.

robert.

> But it's your call, you obviously know more about this than me anyway :)
> 
> Bye,
> Uli
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD