Re: Recent kernels sound crash solution found?

Re: Recent kernels sound crash solution found?

[Alan Cox]

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

Re: Recent kernels sound crash solution found?

[Alan Cox]

>          * 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) {

It terminates when dmap->bufsise hits  page size
>                 start_addr = (char *) __get_free_pages(GFP_ATOMIC|GFP_DMA, sz);
>                 if (start_addr == NULL)
>                         dmap->buffsize /= 2;

I see no bug

Recent kernels sound crash solution found?

[Samium Gromoff]

         Hello folks, seems that i found the potential bug which
    led to the infinite trace i`ve described before.

   Facts:
       1. My host have 24M of RAM and on kernels 2.4.x;x>7 it  started
   to have n-order alloc failures.
       2. In very rare circumsistances under 2.4.8-ac12 i have
   1-order alloc failures.
       3. sound_alloc_dmap::dmabuf.c comments states it will loop
   until the buffer is alloced
       4. sound_alloc_dmap::dmabuf.c comments states it wont accept buffer
   lesser than 8k in size.

   Logic:
      3 + 4 => it loops forever when 1-order alloc fails
      1 + 2 + 3 + 4 => my host crashes

      * comment to point 2: very rare circumcistances includes
   that some time should pass to fragment memory

cheers, Sam 

Re: Recent kernels sound crash solution found?

[Samium Gromoff]

"  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

Re: Recent kernels sound crash solution found?

[Samium Gromoff]

"  Alan Cox wrote:"
> 
> >          * 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) {
> 
> It terminates when dmap->bufsise hits  page size
> >                 start_addr = (char *) __get_free_pages(GFP_ATOMIC|GFP_DMA, sz);
> >                 if (start_addr == NULL)
> >                         dmap->buffsize /= 2;
> 
> I see no bug
> 
     Ahh.. yes. Sorry for this one. Comment was so obvious.

regards, Sam