Re: drm + 4GB RAM + swiotlb = drm craps out

[David Miller <davem@davemloft.net>]

From: "Dave Airlie" <airlied@gmail.com>
Date: Mon, 2 Apr 2007 14:08:13 +1000

> > >
> > > So when swiotlb happens, as you can guess it all falls apart as the
> > > drm never calls sync functions at any stage...
> >
> > You would have hit this on any platform that does caching
> > in the PCI controller as well.
> 
> We must not have a great intersect of radeon and such systems..

It might explain why my machine hung when I tried to use
radeon with DRM on my sparc64 workstation :-)  I have
investigating that on my todo list.

> It currently is required to be in a big 8MB chunk as it gets chopped
> up by the X server not the kernel, so kernel needs to allocate pages
> to back it when X inits, yes this is ugly, no it can't be fixed
> without time-travelling and fixing deployed X servers...
>
> Really we probably only need the ring buffer to be in coherent memory,
> the rest of the stuff is used for DMA buffers which are mainly filled
> by the CPU and read by the GPU. However I cannot change this without
> breaking X, the solution is really to use TTM for this sort of
> stuff.... I'm a bit worried as the AGP driver now uses vmalloc_32
> which really is a meaningless interface on 64-bit systems..

I don't know what to recommend to you, getting 8MB of linear memory
really just isn't practical.

Perhaps we'll have to create something ugly like vmalloc_nobounce().

Remind me again why you're ending up with swiotlb'd pages?
vmalloc_32() uses GFP_KERNEL which should use entirely lowmem and thus
RAM below 4GB and not anything which should need bounce buffering.

You should only get swiotlb'd pages if __GFP_HIGHMEM were set in
the gfp flags.

Are you expecting to be able to virtually remap these pages in
PCI space as one huge 8MB chunk too and that's how swiotlb gets
involved?  That won't work, sorry...