Comment 21 for bug 183456

Raymond wrote:
> you have to change max_buffer_size if you want to load a larger
> soundfont as default value is 128Mb
The issue is not with the size of the soundfont. The issue is that the
kernel tries to put them into the 16MB ISA
DMA zone, being short of memory below 2GB.

Here's the technical explanation:

The kernel first tries to allocate 32bit memory for the soundfont. It
then checks whether the allocated memory is
above the 2GB barrier. Having a hardware bug in the emu10k1, the
hardware can only support DMA from the lowest 2GB
of memory because it simply ignores bit 31 of the address. The memory
allocator then comes back with memory which is,
due to the memory allocation policy, *above* the 2GB barrier whenever
more than 2GB is installed in the system.
This, of course, won't work, and the kernel/emu10k1 driver notices this,
releases the memory and then tries next to take
the memory from the 16MB ISA zone. Of course, there isn't enough memory
available to load the soundfont, which then
fails.

There is a fix, namely shorten the kernel 32bit DMA zone to 2GB, namely
replace in arch/x86/include/asm.h the following
line:

#define MAX_DMA32_PFN ((2UL * 1024 * 1024 * 1024) >> PAGE_SHIFT)

here the 4UL has been replaced by a 2UL, which does the indicated
reduction of the 32bit DMA memory, and brings the
emu10k1 back to work. It has no other drawbacks, i.e. the machine is
working with correspondingly patched kernels
for over a year by now.

The true fix would be to make the memory allocation of the kernel a bit
more flexible than it is now.

Greetings,
    Thomas