On Fri, Mar 11, 2016 at 05:38:06PM -0500, David Michael wrote: > I didn't get a chance to try with Debian yet, but after looking a bit > more, the failure I'm getting is from linux_kmem_init() allocating > memory. It panics in vm_page_grab_contig() when allocating the 29th > (i=28) chunk.
This means the allocator can't allocate 64k contiguous physical memory in the first 16M. > I tried reducing MEM_CHUNKS from 32 to 24, but it then panicked when > linux_init() tried to allocate more memory immediately after. After That doesn't make sense. Could you report the panic message ? > reducing it to 16, gnumach booted fine, and everything worked properly > (including rtl8139 devices). The realtek board shouldn't be working without DDE... Something looks wrong in your test setup. > The panics don't seem to be affected by configure options or device > drivers used. This is with the latest mostly pristine upstream code > from gnumach and GRUB, but I will try to see what Debian is doing > differently over the weekend. This is what I have when I boot : vm_page: DMA: pages: 4080 (15M), free: 1265 (4M) The amount of free memory is already quite low for some reason, but on your machine, it's even lower : vm_page: DMA: pages: 4080 (15M), free: 451 (1M) This explains why your test succeeds with 16 chunks (16*64k = 1M). But We have to understand why you have so little memory in the first place. It could be that newer versions of GRUB place more boot data, or align them differently, and that we neeed to do a better job at freeing boot data. I'm also not sure why my changes affect that... What's your versions of GRUB (please don't say "latest", always state the IDs explicitely) ? -- Richard Braun
