* ttm dma allocator issue ?
@ 2011-12-10 2:25 Jerome Glisse
2011-12-12 16:21 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 4+ messages in thread
From: Jerome Glisse @ 2011-12-10 2:25 UTC (permalink / raw)
To: konrad.wilk; +Cc: dri-devel
Hi Konrad i stumble on this after a long period of test :
Dec 9 12:00:37 homer kernel: ------------[ cut here ]------------
Dec 9 12:00:37 homer kernel: WARNING: at lib/dma-debug.c:894
check_unmap+0x262/0x7e0()
Dec 9 12:00:37 homer kernel: Hardware name: GA-A75M-UD2H
Dec 9 12:00:37 homer kernel: radeon 0000:01:00.0: DMA-API: device
driver frees DMA memory with different CPU address [device address=0x00000002093f3000]
[size=4096 bytes]
[cpu alloc address=0x0000000213bf2000]
[cpu free address=0x00000002093f3000]
Dec 9 12:00:37 homer kernel: Modules linked in: radeon ttm
drm_kms_helper drm ip6t_REJECT ipt_REJECT nf_conntrack_ipv6
nf_conntrack_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack
ip6table_filter iptable_filter ip6_tables ip_tables dm_mirror
dm_region_hash dm_log dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device r8169
snd_pcm microcode serio_raw xhci_hcd mii hwmon i2c_piix4 i2c_algo_bit
snd_timer snd soundcore snd_page_alloc ipv6 ext4 mbcache jbd2
ata_generic pata_atiixp [last unloaded: drm]
Dec 9 12:00:37 homer kernel: Pid: 1158, comm: Heaven_x64 Not tainted 3.2.0-rc4+ #72
Dec 9 12:00:37 homer kernel: Call Trace:
Dec 9 12:00:37 homer kernel: [<ffffffff81043d0f>] warn_slowpath_common+0x7f/0xc0
Dec 9 12:00:37 homer kernel: [<ffffffff81043e06>] warn_slowpath_fmt+0x46/0x50
Dec 9 12:00:37 homer kernel: [<ffffffff81229382>] check_unmap+0x262/0x7e0
Dec 9 12:00:37 homer kernel: [<ffffffff81113977>] ?vm_unmap_aliases+0x77/0x1d0
Dec 9 12:00:37 homer kernel: [<ffffffff8122996d>] debug_dma_free_coherent+0x6d/0x80
Dec 9 12:00:37 homer kernel: [<ffffffff8104bb60>] ?__request_resource+0x60/0x60
Dec 9 12:00:37 homer kernel: [<ffffffffa03e7597>] __ttm_dma_free_page+0x67/0xd0 [ttm]
Dec 9 12:00:37 homer kernel: [<ffffffffa03e7f45>] ttm_dma_unpopulate+0x2c5/0x340 [ttm]
Dec 9 12:00:37 homer kernel: [<ffffffffa042a81f>] radeon_ttm_tt_unpopulate+0xdf/0xf0 [radeon]
Dec 9 12:00:37 homer kernel: [<ffffffffa03df151>] ttm_tt_destroy+0x31/0x70 [ttm]
Dec 9 12:00:37 homer kernel: [<ffffffffa03df703>] ttm_bo_cleanup_memtype_use+0x43/0xb0 [ttm]
Dec 9 12:00:37 homer kernel: [<ffffffffa03e0988>] ttm_bo_release+0x218/0x240 [ttm]
Dec 9 12:00:37 homer kernel: [<ffffffffa03e0770>] ?ttm_bo_delayed_workqueue+0x40/0x40 [ttm]
Dec 9 12:00:37 homer kernel: [<ffffffff8120df96>] kref_put+0x36/0x70
Dec 9 12:00:37 homer kernel: [<ffffffffa03dfa71>] ttm_bo_unref+0x41/0x60 [ttm]
Dec 9 12:00:37 homer kernel: [<ffffffffa042bb29>] radeon_bo_unref+0x49/0x80 [radeon]
Dec 9 12:00:37 homer kernel: [<ffffffffa038e4d0>] ?drm_gem_object_release_handle+0x90/0x90 [drm]
Dec 9 12:00:37 homer kernel: [<ffffffffa043cd16>] radeon_gem_object_free+0x26/0x30 [radeon]
Dec 9 12:00:37 homer kernel: [<ffffffffa038e4fa>] drm_gem_object_free+0x2a/0x30 [drm]
Dec 9 12:00:37 homer kernel: [<ffffffff8120df96>] kref_put+0x36/0x70
Dec 9 12:00:37 homer kernel: [<ffffffffa038e152>] drm_gem_handle_delete+0xc2/0x110 [drm]
Dec 9 12:00:37 homer kernel: [<ffffffffa038e7e8>] drm_gem_close_ioctl+0x28/0x30 [drm]
Dec 9 12:00:37 homer kernel: [<ffffffffa038c5d4>] drm_ioctl+0x444/0x510 [drm]
Dec 9 12:00:37 homer kernel: [<ffffffffa038e7c0>] ?drm_gem_destroy+0x60/0x60 [drm]
Dec 9 12:00:37 homer kernel: [<ffffffff811c4670>] ?inode_has_perm+0x30/0x40
Dec 9 12:00:37 homer kernel: [<ffffffff811c4d6c>] ?file_has_perm+0xdc/0xf0
Dec 9 12:00:37 homer kernel: [<ffffffff81146198>] do_vfs_ioctl+0x98/0x570
Dec 9 12:00:37 homer kernel: [<ffffffff81146701>] sys_ioctl+0x91/0xa0
Dec 9 12:00:37 homer kernel: [<ffffffff814bf42b>] system_call_fastpath+0x16/0x1b
Dec 9 12:00:37 homer kernel: ---[ end trace 8219ad8f7980f419 ]---
Dec 9 12:00:37 homer kernel: Mapped at:
Dec 9 12:00:37 homer kernel: [<ffffffff812282eb>] debug_dma_alloc_coherent+0x3b/0x90
Dec 9 12:00:37 homer kernel: [<ffffffffa03e84a0>] ttm_dma_populate+0x340/0xa30 [ttm]
Dec 9 12:00:37 homer kernel: [<ffffffffa042ae4f>] radeon_ttm_tt_populate+0x19f/0x280 [radeon]
Dec 9 12:00:37 homer kernel: [<ffffffffa03df0ae>] ttm_tt_bind+0x3e/0x70 [ttm]
Dec 9 12:00:37 homer kernel: [<ffffffffa03e0fcf>] ttm_bo_handle_move_mem+0x36f/0x3e0 [ttm]
Dec 9 12:01:29 homer kernel: DMA-API: debugging out of memory - disabling
Dec 9 19:16:54 homer kernel: [drm:radeon_dvi_detect] *ERROR* DVI-I-1:
probed a monitor but no|invalid EDID
Nothing else in the log. Quite frankly i dont this how this can happen.
Any ideas ?
Cheers,
Jerome
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: ttm dma allocator issue ? 2011-12-10 2:25 ttm dma allocator issue ? Jerome Glisse @ 2011-12-12 16:21 ` Konrad Rzeszutek Wilk 2011-12-12 17:37 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 4+ messages in thread From: Konrad Rzeszutek Wilk @ 2011-12-12 16:21 UTC (permalink / raw) To: Jerome Glisse; +Cc: dri-devel On Fri, Dec 09, 2011 at 09:25:43PM -0500, Jerome Glisse wrote: > Hi Konrad i stumble on this after a long period of test : > > Dec 9 12:00:37 homer kernel: ------------[ cut here ]------------ > Dec 9 12:00:37 homer kernel: WARNING: at lib/dma-debug.c:894 > check_unmap+0x262/0x7e0() > Dec 9 12:00:37 homer kernel: Hardware name: GA-A75M-UD2H > Dec 9 12:00:37 homer kernel: radeon 0000:01:00.0: DMA-API: device > driver frees DMA memory with different CPU address [device address=0x00000002093f3000] > [size=4096 bytes] > [cpu alloc address=0x0000000213bf2000] > [cpu free address=0x00000002093f3000] > Dec 9 12:00:37 homer kernel: Modules linked in: radeon ttm > drm_kms_helper drm ip6t_REJECT ipt_REJECT nf_conntrack_ipv6 > nf_conntrack_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack > ip6table_filter iptable_filter ip6_tables ip_tables dm_mirror > dm_region_hash dm_log dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek > snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device r8169 > snd_pcm microcode serio_raw xhci_hcd mii hwmon i2c_piix4 i2c_algo_bit > snd_timer snd soundcore snd_page_alloc ipv6 ext4 mbcache jbd2 > ata_generic pata_atiixp [last unloaded: drm] > Dec 9 12:00:37 homer kernel: Pid: 1158, comm: Heaven_x64 Not tainted 3.2.0-rc4+ #72 > Dec 9 12:00:37 homer kernel: Call Trace: > Dec 9 12:00:37 homer kernel: [<ffffffff81043d0f>] warn_slowpath_common+0x7f/0xc0 > Dec 9 12:00:37 homer kernel: [<ffffffff81043e06>] warn_slowpath_fmt+0x46/0x50 > Dec 9 12:00:37 homer kernel: [<ffffffff81229382>] check_unmap+0x262/0x7e0 > Dec 9 12:00:37 homer kernel: [<ffffffff81113977>] ?vm_unmap_aliases+0x77/0x1d0 > Dec 9 12:00:37 homer kernel: [<ffffffff8122996d>] debug_dma_free_coherent+0x6d/0x80 > Dec 9 12:00:37 homer kernel: [<ffffffff8104bb60>] ?__request_resource+0x60/0x60 > Dec 9 12:00:37 homer kernel: [<ffffffffa03e7597>] __ttm_dma_free_page+0x67/0xd0 [ttm] > Dec 9 12:00:37 homer kernel: [<ffffffffa03e7f45>] ttm_dma_unpopulate+0x2c5/0x340 [ttm] > Dec 9 12:00:37 homer kernel: [<ffffffffa042a81f>] radeon_ttm_tt_unpopulate+0xdf/0xf0 [radeon] .. snip.. > Dec 9 12:00:37 homer kernel: Mapped at: > Dec 9 12:00:37 homer kernel: [<ffffffff812282eb>] debug_dma_alloc_coherent+0x3b/0x90 > Dec 9 12:00:37 homer kernel: [<ffffffffa03e84a0>] ttm_dma_populate+0x340/0xa30 [ttm] > Dec 9 12:00:37 homer kernel: [<ffffffffa042ae4f>] radeon_ttm_tt_populate+0x19f/0x280 [radeon] > Dec 9 12:00:37 homer kernel: [<ffffffffa03df0ae>] ttm_tt_bind+0x3e/0x70 [ttm] > Dec 9 12:00:37 homer kernel: [<ffffffffa03e0fcf>] ttm_bo_handle_move_mem+0x36f/0x3e0 [ttm] > Dec 9 12:01:29 homer kernel: DMA-API: debugging out of memory - disabling > Dec 9 19:16:54 homer kernel: [drm:radeon_dvi_detect] *ERROR* DVI-I-1: > probed a monitor but no|invalid EDID > > Nothing else in the log. Quite frankly i dont this how this can happen. > Any ideas ? The only way to do that would be to modify the 'struct dma_page' vaddr and dma variables from what they had in __ttm_dma_alloc_page. But I am not seeing any willfull modifications. We do pass in to dma_free_coherent the _same_ values! Hm, it might be worth adding in the 'struct dma_page' a 'virt_to_phys' value (which is what the DMA debug API uses to check), and see we get inconsitent values _before_ we call the DMA debug API. This is rather to double check the DMA API debug API. I am going to try something like this (not compile tested at all): diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c index 6678abc..2dd7d6c 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c @@ -127,6 +127,7 @@ struct dma_page { void *vaddr; struct page *p; dma_addr_t dma; + void *phys; /* Based on virt_to_phys so not really bus addr */ }; /* @@ -330,6 +331,11 @@ static int ttm_set_pages_caching(struct dma_pool *pool, static void __ttm_dma_free_page(struct dma_pool *pool, struct dma_page *d_page) { dma_addr_t dma = d_page->dma; + + WARN_ON(virt_to_phys(d_page->vaddr) != d_page->virt, + "WTF: saved 0x%lx, but now we get 0x%lx!\n", + d_page->virt, virt_to_phys(d_page->vaddr)); + dma_free_coherent(pool->dev, pool->size, d_page->vaddr, dma); kfree(d_page); @@ -348,6 +354,7 @@ static struct dma_page *__ttm_dma_alloc_page(struct dma_pool *pool) pool->gfp_flags); if (d_page->vaddr) d_page->p = virt_to_page(d_page->vaddr); + d_page->virt = virt_to_phys(d_page->vaddr); else { kfree(d_page); d_page = NULL; ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: ttm dma allocator issue ? 2011-12-12 16:21 ` Konrad Rzeszutek Wilk @ 2011-12-12 17:37 ` Konrad Rzeszutek Wilk 2011-12-12 21:45 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 4+ messages in thread From: Konrad Rzeszutek Wilk @ 2011-12-12 17:37 UTC (permalink / raw) To: Jerome Glisse; +Cc: dri-devel > > Any ideas ? > > The only way to do that would be to modify the 'struct dma_page' vaddr and dma > variables from what they had in __ttm_dma_alloc_page. But I am not seeing any > willfull modifications. We do pass in to dma_free_coherent the _same_ values! > > > Hm, it might be worth adding in the 'struct dma_page' a 'virt_to_phys' value > (which is what the DMA debug API uses to check), and see we get inconsitent > values _before_ we call the DMA debug API. This is rather to double check > the DMA API debug API. I am going to try something like this (not compile tested at all): This one is compile tested :-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c index 6678abc..659b0ee 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c @@ -32,7 +32,7 @@ * - Tracks whether the page is UC, WB or cached (and reverts to WB * when freed). */ - +#define DEBUG 1 #include <linux/dma-mapping.h> #include <linux/list.h> #include <linux/seq_file.h> /* for seq_printf */ @@ -127,6 +127,7 @@ struct dma_page { void *vaddr; struct page *p; dma_addr_t dma; + void *phys; /* Based on virt_to_phys so not really bus addr */ }; /* @@ -330,6 +331,11 @@ static int ttm_set_pages_caching(struct dma_pool *pool, static void __ttm_dma_free_page(struct dma_pool *pool, struct dma_page *d_page) { dma_addr_t dma = d_page->dma; + + WARN(virt_to_phys(d_page->vaddr) != d_page->phys, + "We saved 0x%lx, but now we get 0x%lx!?\n", + (unsigned long)d_page->phys, (unsigned long)virt_to_phys(d_page->vaddr)); + dma_free_coherent(pool->dev, pool->size, d_page->vaddr, dma); kfree(d_page); @@ -346,8 +352,10 @@ static struct dma_page *__ttm_dma_alloc_page(struct dma_pool *pool) d_page->vaddr = dma_alloc_coherent(pool->dev, pool->size, &d_page->dma, pool->gfp_flags); - if (d_page->vaddr) + if (d_page->vaddr) { d_page->p = virt_to_page(d_page->vaddr); + d_page->phys = virt_to_phys(d_page->vaddr); + } else { kfree(d_page); d_page = NULL; ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: ttm dma allocator issue ? 2011-12-12 17:37 ` Konrad Rzeszutek Wilk @ 2011-12-12 21:45 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 4+ messages in thread From: Konrad Rzeszutek Wilk @ 2011-12-12 21:45 UTC (permalink / raw) To: Jerome Glisse; +Cc: dri-devel On Mon, Dec 12, 2011 at 12:37:43PM -0500, Konrad Rzeszutek Wilk wrote: > > > Any ideas ? > > > > The only way to do that would be to modify the 'struct dma_page' vaddr and dma > > variables from what they had in __ttm_dma_alloc_page. But I am not seeing any > > willfull modifications. We do pass in to dma_free_coherent the _same_ values! > > > > > > Hm, it might be worth adding in the 'struct dma_page' a 'virt_to_phys' value > > (which is what the DMA debug API uses to check), and see we get inconsitent > > values _before_ we call the DMA debug API. This is rather to double check > > the DMA API debug API. I am going to try something like this (not compile tested at all): > > This one is compile tested :-) > > diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > index 6678abc..659b0ee 100644 > --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > @@ -32,7 +32,7 @@ > * - Tracks whether the page is UC, WB or cached (and reverts to WB > * when freed). > */ > - And I think if you cherry-pick git commit 91ec37cc1015220965e39bf342fb846810d19e79 Author: Thomas Jarosch <thomas.jarosch@intra2net.com> Date: Thu Nov 17 20:31:02 2011 +0100 Fix comparison using wrong pointer variable in dma debug code which fixes the DMA debug API code, the error you are getting will go away. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-12-12 21:46 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-10 2:25 ttm dma allocator issue ? Jerome Glisse 2011-12-12 16:21 ` Konrad Rzeszutek Wilk 2011-12-12 17:37 ` Konrad Rzeszutek Wilk 2011-12-12 21:45 ` Konrad Rzeszutek Wilk
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.