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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
