"Dave Airlie" <[EMAIL PROTECTED]> writes:
>
> On a 64-bit machine GFP_KERNEL can give me any memory... it all works
> fine on 32-bit highmem kernel as I don't get highmem... I really need
> __GFP_DMA32 memory but we don't have a generic allocator that gives
> this out that I can see..
__get_free_
> 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.
True, maybe the intersection is me + hw like that + radeon :-)
> I don't know what to recommend to you, getting 8MB of linear memory
> really ju
> >
> > On a 64-bit machine GFP_KERNEL can give me any memory... it all works
> > fine on 32-bit highmem kernel as I don't get highmem... I really need
> > __GFP_DMA32 memory but we don't have a generic allocator that gives
> > this out that I can see..
>
> __get_free_pages(..., __GFP_DMA32) on 64b
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 15:15:48 +1000
> > 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
> > RA
From: "Dave Airlie" <[EMAIL PROTECTED]>
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 control
> >
> > 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..
>
> Coheren
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 09:44:41 +1000
> Okay I've got a bug reported before and now again about > 4GB + radeon
> blows up the DRM... on Intel hw...
>
> What the drm currently does for the PCI GART table is it allocates a
> chunk of memory (8MB) with vmalloc_
Okay I've got a bug reported before and now again about > 4GB + radeon
blows up the DRM... on Intel hw...
What the drm currently does for the PCI GART table is it allocates a
chunk of memory (8MB) with vmalloc_32(), then when it decides to use
it it goes through every page of it calls pci_map_sing
