On Thu, Jan 28, 2010 at 01:46:17PM -0500, Michael Breuer wrote:This is with the pci_unmap_len patch as well as the dma-debug patch. I'm not getting any warnings - but dma-debug num-free-entries drops until zero and then debugging is disabled. I started with 8,000,000 about three hours ago - without load I'm already down to less than half that. Again - only looking at sky2. Looks like the dma-debug hash table is reducing one entry for every packet, but never increasing the num_entries (no unmap perhaps).
On 1/28/2010 12:08 PM, Stephen Hemminger wrote:Do you mean it's after this patch or earlier too? I think you might
--- a/lib/dma-debug.c 2010-01-20 15:22:55.919519883 -0800Ok - applied. Noise gone... however I'm not sure whether I'll be
+++ b/lib/dma-debug.c 2010-01-20 15:26:31.648895638 -0800
@@ -285,11 +285,9 @@ static struct dma_debug_entry *hash_buck
}
/*
- * If we have multiple matches but no perfect-fit, just return
- * NULL.
+ * If we have multiple matches but no perfect-fit
+ * return best value and let caller deal with it.
*/
- ret = (matches == 1) ? ret : NULL;
-
return ret;
}
able to keep dma-debug going long enough to catch anything.
num_free_entries keeps dropping... looks like entries are not freed.
I'm running with a huge number for now& sky2 as the driver filter.
Is there a reason that entries wouldn't be unmapped, or is
dma-debug.c just not processing the unmap correctly?
use my sky2/receive_copy/pci_unmap_len patch instead to get rid of
this warning.
Btw, since 1000 was too much, maybe you could try copybreak=256 yet,
plus additional ping or some other source of shorter packets. And how
about trying this new switch?
Jarek P.