lkml.org 
[lkml]   [1998]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: leak.. (es1370 driver)
On Wed, 16 Sep 1998, Jeff Lightfoot wrote:

> Michael L. Galbraith wrote:
> > Could you please add your configuration to this with a blurb concerning
> > what you've done to confirm that the es1370 driver triggers this to refresh
> > peoples memories?
>
> very stripped kernel config. Verified on Redhat 5.0/1. Only extra items are
> sound support and es1370.
>
> This is using kernels since es1370 was added.
>
> Every usage of sound will drop at least 64K.
>

I've been thinking some more about this..

You would think that it would _have_ to be dma memory, but the diagnostic
printk's that were put in indicated that that was being freed. The only
way that I know of that it wouldn't be _really_ freed is if it's map->count
wasn't 1 or the pages were reserved at free time. If that were the case,
something with the tests in free_pages() called before the real free_pages()
call in dealloc_dmabuf() should show it.

void grumble(unsigned long addr, unsigned long order)
{
unsigned long map_nr = MAP_NR(addr);

if (map_nr < max_mapnr) {
mem_map_t * map = mem_map + map_nr;
if (PageReserved(map)) {
printk(KERN_WARNING "es1370: darn! buffer is still reserved\n");
if (atomic_read(&map->count) > 1) {
printk(KERN_WARNING "es1370: darn! buffer is still in use\n");
}
}

It seems to me that this would put the final nail in the 'it's gotta be
the dang driver' idea if the printk's don't happen, and show that the
driver is triggering something else.

-Mike


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.057 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site