Messages in this thread |  | | From | Samium Gromoff <> | Subject | Re: Recent kernels sound crash solution found? | Date | Fri, 7 Sep 2001 20:09:01 +0000 (UTC) |
| |
" 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/
|  |