Re: [Alsa-user] sb live dma buffer alloc failure?

Re: [Alsa-user] sb live dma buffer alloc failure?

[Takashi Iwai]

At Wed, 05 Feb 2003 02:15:27 -0500,
Brian J. Tarricone <bjt23@ece.cornell.edu> wrote:
> 
> forgive me for cross-posting, but i've found references to this problem 
> on both lists, so...
 
this should go to alsa-devel, not alsa-users...

> 
> so then i noticed rc7, and tried that (unpatched, fresh from the website).
> 
> things are somewhat worse.  i load up xmms, and start playing mp3s.  
> things seem fine, playing for hours until i get bored of some songs, put 
> it on random play, and keep hitting "next song" until i find something i 
> feel like listening to.  if i press 'next' roughly once per second, 
> after about 15-20 songs xmms locks up hard and jumps to using 100% cpu.  
> kill -9 doesn't work, and any other app that tries to use the pcm device 
> locks as well.  i have to reboot to fix it.

which kernel version are you using?

the new code on rc7 simply tries allocation via vmalloc().
if it fails, it means that the system resource is really exhausted.
or, there might be memory leak or so...


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [Alsa-user] sb live dma buffer alloc failure?

[Takashi Iwai]

At Wed, 05 Feb 2003 16:42:48 +0000,
laurent.ml@linuxfr.org wrote:
> 
> 
> Hi,
> 
> I have exactly the same problem, I was considering posting here.
> My config is 2.4.21pre4 (HIGHMEM) alsa 0.9.0rc7 , my system has 1GB memory.
> (the prb was the same with 2.4.21pre3 and 0.9.0rc6)

did you have the exactly same behavionr rc6?
i mean the machine stalls, not telling you back the no-memory error.


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [Alsa-user] sb live dma buffer alloc failure?

[Brian J. Tarricone]

Takashi Iwai wrote:

>which kernel version are you using?
>
2.4.20 - it's a heavily patched one, tho (out of gentoo's portage).  
should i try a vanilla kernel?

>the new code on rc7 simply tries allocation via vmalloc().
>if it fails, it means that the system resource is really exhausted.
>or, there might be memory leak or so...
>  
>
hmm...  well, rc7 has locked for me very shortly after system startup, 
top reports plenty (>200mb) free, so this shouldn't be a free resource 
issue.  it seems to only occur if i try to rapidly open and close the 
device (when i say 'rapidly' i mean about once per second for about 
10-25 seconds).

it's sub-ideal, but i'm using esd for now (with a really high timeout 
for releasing the pcm device) to avoid the excessive reopening behaviour.

thanks for your help - please let me know of any other ways i can try to 
gather information.

    -brian



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Re: [Alsa-user] sb live dma buffer alloc failure?

[laurent.ml]

"Brian J. Tarricone" <bjt23@ece.cornell.edu> writes:

Hi,

I made some tests.
The config was:
- HIGHMEM kernel 2.4.21pre4
- amd athlon xp+ 1800, RAM=1Go
- alsa drv rc7
- alsa lib rc7
- alsa utils rc6 (rc7 utils don't compile here)
- xmms 1.2.7 (debian sid)
- alsa-xmms (ALSA 0.9 output plugin for XMMS) 0.9.8 (debian sid)

I couldn't reproduce the problem from a fresh reboot, so I tried to simulate
a high memory usage.

the tests were:
sh -c 'a=1; while true; do echo $a; a=$(($a+1)); aplay ~/empty.wav ; done' and
sh -c 'a=1; while true; do echo $a; a=$(($a+1)); xmms ~/empty.wav ; done'

empty.wav is a ~200ms silence file.

the xmms test was done 2 times, the first time with Oss driver output, and
the second time with Alsa 0.9 driver output.
I didn't mention it before, but I was using xmms + alsa 0.9 driver output
when I got the problem. What about you Brian ?

I was not able to reproduce the problem with both aplay and xmms(oss driver)
loops. Both of them were able to run in these memory usages:
Mem:   1033824k total,   808256k used,   225568k free,    21428k buffers
Swap:   530104k total,   527296k used,     2808k free,    85520k cached

Mem:   1033824k total,  1017000k used,    16824k free,     3068k buffers
Swap:   530104k total,   529276k used,      828k free,    26752k cached

whereas the xmms(alsa drv) loop gave:
ALSA lib pcm_hw.c:297:(snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS failed: Cannot allocate memory
2.4.21pre4 don't produce kernel error, whereas 2.4.21pre4aa1 gives
"kernel: __alloc_pages: 0-order allocation failed (gfp=0x21/0)" kind of error.

After the xmms(alsa output) problem, I was able to rmmod alsa modules, then
reload them.

-- 
Laurent


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Re: [Alsa-user] sb live dma buffer alloc failure?

[Takashi Iwai]

At Sat, 08 Feb 2003 17:10:02 +0000,
laurent.ml@linuxfr.org wrote:
> 
> "Brian J. Tarricone" <bjt23@ece.cornell.edu> writes:
> 
> whereas the xmms(alsa drv) loop gave:
> ALSA lib pcm_hw.c:297:(snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS failed: Cannot allocate memory
> 2.4.21pre4 don't produce kernel error, whereas 2.4.21pre4aa1 gives
> "kernel: __alloc_pages: 0-order allocation failed (gfp=0x21/0)" kind of error.

it's weird.  the gfp mask has no GFP_WAIT bit.
could you check which call triggers this?
or did it come from 0.9.0rc6 driver?  then i understand the reason...

> After the xmms(alsa output) problem, I was able to rmmod alsa modules, then
> reload them.

the new code on cvs will do pre-allocation, so this problem should no
longer appear, anyway.


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [Alsa-user] sb live dma buffer alloc failure?

[Brian J. Tarricone]

just a quick update - i installed yesterday's cvs of alsa-driver, and i 
haven't had any problems (no alloc failures or apps locking up) since 
then.  i've tried to stress test it a bit (filling up ram, opening and 
closing the pcm device rapidly), and i'm pleased to say no problems.  i 
looked at the cvs logs, quite a bit has been done in sg_buf.c since rc7, 
perhaps something there had an impact?

even if this is just a side-effect of other work, thanks for the fix, 
guys ^_^

    -brian

Takashi Iwai wrote:

>At Wed, 05 Feb 2003 02:15:27 -0500,
>Brian J. Tarricone <bjt23@ece.cornell.edu> wrote:
>  
>
>>forgive me for cross-posting, but i've found references to this problem 
>>on both lists, so...
>>    
>>
> 
>this should go to alsa-devel, not alsa-users...
>
>  
>
>>so then i noticed rc7, and tried that (unpatched, fresh from the website).
>>
>>things are somewhat worse.  i load up xmms, and start playing mp3s.  
>>things seem fine, playing for hours until i get bored of some songs, put 
>>it on random play, and keep hitting "next song" until i find something i 
>>feel like listening to.  if i press 'next' roughly once per second, 
>>after about 15-20 songs xmms locks up hard and jumps to using 100% cpu.  
>>kill -9 doesn't work, and any other app that tries to use the pcm device 
>>locks as well.  i have to reboot to fix it.
>>    
>>
>
>which kernel version are you using?
>
>the new code on rc7 simply tries allocation via vmalloc().
>if it fails, it means that the system resource is really exhausted.
>or, there might be memory leak or so...
>
>
>Takashi
>
>  
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [Alsa-user] sb live dma buffer alloc failure?

[Takashi Iwai]

At Wed, 12 Feb 2003 18:00:29 -0500,
Brian J. Tarricone <bjt23@ece.cornell.edu> wrote:
> 
> just a quick update - i installed yesterday's cvs of alsa-driver, and i 
> haven't had any problems (no alloc failures or apps locking up) since 
> then.  i've tried to stress test it a bit (filling up ram, opening and 
> closing the pcm device rapidly), and i'm pleased to say no problems.  i 
> looked at the cvs logs, quite a bit has been done in sg_buf.c since rc7, 
> perhaps something there had an impact?
>  
> even if this is just a side-effect of other work, thanks for the fix, 
> guys ^_^

thanks for your report.

in the cvs version, sg-buffer handler pre-allocates the buffer and
keep it as other buffer types, so that  the buffer re-allocation
wouldn't happen rarely.   so, it's not a side effect :)


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf