Re: "Cannot allocate memory" problem with latest CVS

[Takashi Iwai <tiwai@suse.de>]

Hi,

At Sun, 27 Oct 2002 18:05:41 +0000 (GMT),
Chris Rankin wrote:
> 
> Hi,
> 
> The 'cannot allocate memory' problem has returned on
> my machine:
> 
(snip) 
> 
> $ free -t
>              total       used       free     shared   
> buffers     cached
> Mem:       1033544    1020348      13196          0   
>   30228     748684
> -/+ buffers/cache:     241436     792108
> Swap:       498004      10668     487336
> Total:     1531548    1031016     500532
> 
> 
> $ vmstat
>    procs                      memory      swap        
>  io     system      cpu
>  r  b  w   swpd   free   buff  cache   si   so    bi  
>  bo   in    cs us sy id
>  2  0  0  10668  13096  30284 748728    0    0     1  
>   3   10    14 97  3  0
> 
> 
> I am using the snd-emu10k1 driver with a SB-Live!
> card, on a 2.4.19-SMP box with 1 GB memory, so this
> out-of-memory error is a bit of a mystery. Are there
> any other statistics that would be useful? I expect
> (hope!) that this error will disappear soon, so I'd
> recommend a swift response, if required.

i guess actually your box has no free space "for the sb live card".
the emu10k1 chip requires the 29bit PCI DMA mask, and it cannot use
the whole 1GB memory.  hence, even if you have memory on the high-mem
region, still this problem may happen.

please note that the current emu10k1 driver allocates pages
dynamically at each pcm playback, while the older version grabbed the
large contiguous area at the module loading time.  this makes the
difference of behavior as you found before.

this problem could be solved by using get_free_page() with GFP_KERNEL
(without ATOMIC) like on 2.2 kernels, since pci_alloc_consistent()
uses always GFP_ATOMIC flag so that it can be called from interrupt
handlers.  but it would be really a hack...


Takashi


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