lkml.org 
[lkml]   [2001]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Recent kernels sound crash solution found?
Date
"  Alan Cox wrote:"
>
> > * comment to point 2: very rare circumcistances includes
> > that some time should pass to fragment memory
>
> The alloc_dmap code returns -ENOMEM when the allocation fails. That causes
> the open_dmap call to return -ENOMEM which in turn causes DMAbuf_open
> to return -ENOMEM which causes audio_openb to return -ENOMEM, which gets
> back to userspace.
>
> I don't see a problem.
>
> [sound btw also supports a module option to keep the dmabuffers allocated
> once and hang onto them]
>
Alan, actually i wanted to tell you about other place:
from dmabuf.c:
/*
* Now loop until we get a free buffer. Try to get smaller buffer if
* it fails. Don't accept smaller than 8k buffer for performance
* reasons.
*/
===> _here_ is a dead-loop <===
while (start_addr == NULL && dmap->buffsize > PAGE_SIZE) {
for (sz = 0, size = PAGE_SIZE; size < dmap->buffsize; sz++, size dmap->buffsize = PAGE_SIZE * (1 << sz);
start_addr = (char *) __get_free_pages(GFP_ATOMIC|GFP_DMA, sz);
if (start_addr == NULL)
dmap->buffsize /= 2;
}

Solutions:
1. make it accept 0-order allocations
2. make CONFIG_SOUND_DMAP not a config, but the only option


cheers, Sam

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

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