Am 22.02.2018 um 09:37 schrieb Bas Vermeulen: > On Wed, Feb 21, 2018 at 6:22 PM, Alex Deucher <alexdeucher at gmail.com > <mailto:alexdeucher at gmail.com>> wrote: > > On Wed, Feb 21, 2018 at 7:43 AM, Christian König > [SNIP] > > Apart from that I don't have any good idea any more why that > shouldn't work. > > Does your platform properly handle DMA masks? Most radeon hw only > supports a 40 bit DMA mask. If there are relevant bits in the upper > bits of the address, they will be lost when the hw tries to use the > address. On at least some powerpc hw, I believe there is some memory > routing related info in the high bits. > > > On 4.1 (without the hashing algorithm when printing pointers), The > rings are placed thus: > > [  11.002673] radeon 0002:01:00.0: fence driver on ring 0 use gpu > addr 0x0000000080000c00 and cpu addr 0xc00000007c0c8c00 > [  11.012165] radeon 0002:01:00.0: fence driver on ring 1 use gpu > addr 0x0000000080000c04 and cpu addr 0xc00000007c0c8c04 > [  11.021657] radeon 0002:01:00.0: fence driver on ring 2 use gpu > addr 0x0000000080000c08 and cpu addr 0xc00000007c0c8c08 > [  11.031152] radeon 0002:01:00.0: fence driver on ring 3 use gpu > addr 0x0000000080000c0c and cpu addr 0xc00000007c0c8c0c > [  11.040644] radeon 0002:01:00.0: fence driver on ring 4 use gpu > addr 0x0000000080000c10 and cpu addr 0xc00000007c0c8c10 > [  11.051919] radeon 0002:01:00.0: fence driver on ring 5 use gpu > addr 0x0000000000075a18 and cpu addr 0x8000080088db5a18 > > It's also using bit 63 & 62. So this might be something to look into. No, that is just the virtual address of the buffer in kernel space and perfectly ok. What you could try is to force the need_dma32 flag to true, see drivers/gpu/drm/radeon/radeon_ttm.c and search for need_dma32. Regards, Christian. > > Bas Vermeulen > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180222/455553df/attachment-0001.html>
