Date: Thu, 9 Feb 2006 14:56:59 +1100 From: Andrew Reilly <areilly@bigpond.net.au> To: freebsd-amd64@freebsd.org Subject: contigmalloc problem in SMP Message-ID: <20060209035659.GA2377@gurney.reilly.home>
next in thread | raw e-mail | index | archive | help
I reported, earlier, that I wasn't able to get the amd64 version of the (closed source) 4front-tech OSS driver to start: it was unable to allocate some contiguous memory (48k or so, at the time). I've been in e-mail contact with one of their developers, and he has released a new version of the driver that doesn't try to allocate so much memory (now about 28k) for me to try. This didn't work either. However: I've just tried re-booting with kern.smp.disabled="1" in /boot/loader.conf, and lo: it works. So: why might contigmalloc() be failing, in a two-processor situation? (Sorry, uname -a: FreeBSD duncan.reilly.home 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Thu Feb 2 16:39:13 EST 2006 root@duncan.reilly.home:/usr/obj/usr/src/sys/DUNCAN amd64 ) Further details: unlike most other uses of contigmalloc() that I've seen in the tree (which use PAGE_SIZE alignment), this particular sound card needs a 64k-aligned buffer, and (with a bit of disassembly) that's what the oss driver appears to be asking for. All of the other arguments look the same. Oh: while I was looking at /src/sys/vm/vm_contig.c to see if I could see any obvious causes, I noticed that there's a sysctl knob: vm.old_contigmalloc, which is defaulting to 0. I frobbed it to 1 (in loader.conf, and rebooted), and that didn't help (in two-processor SMP). Any thoughts on what new vs old contigmalloc entails? Cheers, -- Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060209035659.GA2377>