lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Tue, 14 Sep 2010 16:22:41 +0200
From:	Thomas Richter <thor@...h.tu-berlin.de>
To:	linux-kernel@...r.kernel.org
Subject: ALSA: Midi on emu10k1 broken for more than 2GB memory

Hi folks, (please forward replies to thor@...h.tu-berlin.de - thanks)

the following is a question and a quick dirty fix for midi problems on 
the emu10k1 (Soundblaster) cards for 64 bit systems
with more than 2GB memory. Problem of this card is, as the alsa team is 
definitely aware of, that the card can only DMA into
the lowest 2GB of memory, PCI DMA seems to use only 31 bit of the 
available 32 bit. The current emu10k1 driver is aware of
this problem and uses the following strategy to allocate DMA memory for 
the card:

i) Get regular memory,
- if the result has bits 31 or above set,
ii) fall back to the ISA (16MB) memory zone.

Unfortunately, the ISA memory zone runs out of memory pretty early - 
this means that it is for typical configurations not
possible to load soundfonts, they simply won't fit. As a result, midi 
output is broken.

Many linux distributions work around this by offering a timidity based 
midi-server, but this is in so far unsatisfactory as it causes
additional CPU load, besides the problem lies a bit deeper in the kernel 
memory management and its unability to allocate
memory for such broken hardware flexible enough.

A possible quick workaround would be a kernel option (probably under 
"kernel hacking") to make the 32bit DMA zone a 31bit DMA
zone, i.e. in

arch/x86/include/asm/dma.h

make this line

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

configurable. I'm currently running a custom-patched 2.6.32.21 with this 
configuration active, and run the same modification on
several kernels before without observing any major drawback from that, 
the system runs stable (and of course, with emu10k1 midi).

I'm not really competent enough to provide a patch that would integrate 
nicely into the configuration mechanism, but it seems easy
enough to do until a better memory management becomes available.

The system here is a Asus M2N with 6GB memory and an 
emu10k1/soundblaster card, though the board shouldn't really matter, it
is a emu10k1 problem that appears whenever more than 2GB are in the system.

Comments, suggestions, activities?

Thanks,

Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ