Hello fellow hackers, I am maintaining a kernel for an embedded product. We have an FPGA acquisition device interfaced through PCI-e on different intel platforms. The acquisition device needs an extra large physically contiguous memory area to autonomously dump acquired data into. In a previous product, VT-d was available and I made use of it to allocate 128MB+ using vmalloc, then mapping it so it forms a contiguous address chunk from the device side. We are doing another incarnation of the product on an Atom E6xx which has no such IOMMU and am looking into ways of allocating a huge chunk of ram. Kind of like integrated gfx chips do with RAM, but I don't have the assistance of the BIOS. Based on suggestions to try using alloc_bootmem, I have started looking into it by first making a platform (under arch/x86/platform) built-in module using "pure_initcall" to get an early hook to allocate this memory. This approach failed because the call would happen after SLUB init. I then proceeded to hack "mm_init()" in init/main.c so that I do the alloc_bootmem call after "mem_init()" but before "kmem_cache_init()". I successfully get the huge chunk I request, and test that it is really physically contiguous. My joy was not long lived, it was too easy. Once fully booted, I load a module which tests a patter I wrote in memory to see if the memory got touched since the early init moment, and it did. A crude test, but right away tells me the allocation was not respected. Any thoughts on how to achieve this? We are targeting v3.1 64 or 32 bits, testing with 3.2-rc1 on x84_64. I noticed this means "nobootmem.c" is used. Thanks /jfd -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href