Hey there -
Tried the kernel mailing lists, but they blew me off; there’s no kernel forum, but this seems close.
Anyway, I use a SoundBlaster Live based on the emu10k1 chip; I’ve a stack of 'em so that I can continue to use this card 'til PCI goes away.
I prefer that my MIDI synth do precisely what I tell it to do, and Timidity, FluidSynth and so on don’t; hardware wavetable synthesis rawks.
Anyway, thanks to the DMA addressing scheme on this card using only 31 bits, ever since stepping into the 64-bit world every time an update includes a new kernel I must edit arch/x86/include/asm/dma.h to use 2GB of space rather than 4GB so as to be able to load large soundfonts - an ugly hack, but necessary; I then compile and install this slightly customised kernel. See comment by Thomas Richter at https://bugs.launchpad.net/ubuntu/+s...fx/+bug/183456 if you want details.
viz:
I change this:
/* 4GB broken PCI/AGP hardware bus master zone */
#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT)
to this:
/* 4GB broken PCI/AGP hardware bus master zone */
#define MAX_DMA32_PFN ((2UL * 1024 * 1024 * 1024) >> PAGE_SHIFT)
Seems counterintuitive, but it works - and has for over a decade. However, with 5.3.18-lp152.63 this no longer works; sfxload runs out of memory as though I’d not modified the kernel.
So… I’m running 5.3.18-lp152.60 because it still works, but I weep for the future.
Oh… Intel, dual-Xeon antique which stops bullets and whose drive array can withstand an angry Hulk; pre-UEFI, so that’s not an issue; standard awesfx 0.5.1e.
Someone mentioned a “kernel lockdown” which occurred with Leap 15.2, but the 5.3.18-lp152.60 which came with 15.2 was well-behaved once I “corrected” the 32-bit DMA pool size.
I’m now on 15.3 and it doesn’t work at all; the problem started under 15.2 so that’s how I’m posting it.
Who did this, why, and HOW…?!? That this beast can cheerily ignore compile-time directives worries me.
Ideas? Thanks.