Re: Testing requested for the next version of GNU Mach

[David Michael]

On Sun, Mar 13, 2016 at 9:06 AM, Richard Braun <rbraun@sceen.net> wrote:
> 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 ?

It was "panic: vm_page_grab_contig" in all cases.

>> 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.

I've been using it almost exclusively for the last three or four years
without DDE.  It works fine for me until I try to change the IP
address with fsysopts, then kernel panics ensue.

I've switched my QEMU commands to -device pcnet just in case.

>> 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) ?

I've encountered the failure with both GRUB beta2 and beta3.  They're
from last month and over two years ago, so I don't think the change
was too recent.

After poking around a bit more, it seems that the space is eaten by
debug info.  Appending -g0 to CFLAGS allowed gnumach to boot
successfully and resulted in this:

vm_page: DMA: pages: 4080 (15M), free: 2053 (8M)

The difference may be because GRUB apparently passes the multiboot ELF
info, while QEMU does not.  I'll just make sure to disable debug flags
when building gnumach for the time being.

Thanks.

David