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_single() (with PCI_DMA_TODEVICE, which is probably wrong...) with every page from the vmalloc mapping and puts the bus addresses of the pages into the PCI GART table on the GPU. So when swiotlb happens, as you can guess it all falls apart as the drm never calls sync functions at any stage... The main problem is the ring buffer and scratch write back, these values are read/write from both the CPU and GPU quite a lot, so this leads me to think I should really just be using dma_alloc_coherent for the whole lot, however this is an 8MB mapping and possibly could be getting larger in the future and dynamic as we do dynamic PCIEGART support for the radeons... So I suppose I'm asking for ideas on the "correct" way to do this, and perhaps any quick way to patch up the problem I'm seeing now by making swiotlb not get involved .... Regards, Dave. -
| David Miller | Re: Slow DOWN, please!!! |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Greg KH | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Josip Rodin | bnx2_poll panicking kernel |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
