* 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.