There was no arbitrary concatenation at all - this was the entirety of the log as it was transmitted across the serial port from the moment the Genode boot started with the NOVA kernel.  If any concat was done, it was due to the unmodified code provided with the source.

The 32 bit scenario was intended but next time around I will also try on the 64 bit just to compare logs.

I am unclear as to why this would be even attempting to use more than 4 GB.  Yes, the PC has more than 4 and I have made no modifications to even attempt to use more than 4 GB.  Again, if this is unintentional, it was not by my design and how can we force it to use only up to the 4 GB boundary?

The run recipe I am using is virtualbox.run.  In this recipe there is no indications that the ACPI has any configurable components.  These capabilities must be set in another file that this recipe is calling - please tell me where these would be found so that I can adjust the caps on acpi.



On Tue, Jul 25, 2017 at 5:55 AM, Christian Helmuth <christian.helmuth@...1...> wrote:
Hello Chris,

your log is very hard to read as it seems to arbitrarily concatenate
several logs or multiple copies of the same log. I suggest you store
one log file per boot of the test machine and attach the resulting
file to your email in the future.

I'll add some comments about what I read in your log in the following
(interleaved with the original/cleaned up log text).

On Mon, Jul 24, 2017 at 08:43:51PM -0400, Chris Rothrock wrote:
> NOVA Microhypervisor v7-8bcd6fc (x86_32): Jul 21 2017 10:14:19 [gcc 6.3.0]

You seem to run a 32-bit build of NOVA, which may not interfere with
your scenario but may not be what you intended to do.

> [ 0] TSC:3408373 kHz BUS:0 kHz
> [ 0] CORE:0:0:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> [ 1] CORE:0:1:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> [ 3] CORE:0:3:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> [ 2] CORE:0:2:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> [ 0] disabling super pages for DMAR
> Hypervisor features VMX
> Hypervisor reports 4x1 CPUs
> CPU ID (genode->kernel:package:core:thread) remapping
>  remap (0->0:0:0:0) boot cpu
>  remap (1->1:0:1:0)
>  remap (2->2:0:2:0)
>  remap (3->3:0:3:0)
> Hypervisor info page contains 24 memory descriptors:
> core     image  [00100000,029b9000)
> binaries region [00228000,029b9000) free for reuse
> detected physical memory: 0x00000000 - size: 0x0008ec00
> use      physical memory: 0x00000000 - size: 0x0008e000
> detected physical memory: 0x00100000 - size: 0xb2bfb000
> use      physical memory: 0x00100000 - size: 0xb2bfb000
> detected physical memory: 0xb3aff000 - size: 0x00001000
> use      physical memory: 0xb3aff000 - size: 0x00001000
> detected physical memory: 0x00000000 - size: 0x3f800000

NOVA detects some unusable RAM above 4 GiB.

> :virt_alloc: Allocator 0x1f5f84 dump:
>  Block: [00002000,00003000) size=4K avail=0 max_avail=0
>  Block: [00003000,00004000) size=4K avail=0 max_avail=0
>  Block: [00004000,00005000) size=4K avail=0 max_avail=0
>  Block: [00005000,00006000) size=4K avail=0 max_avail=0
>  Block: [00006000,00007000) size=4K avail=0 max_avail=0
>  Block: [00007000,00008000) size=4K avail=0 max_avail=0
>  Block: [00008000,00009000) size=4K avail=0 max_avail=0
>  Block: [00009000,0000a000) size=4K avail=0 max_avail=0
>  Block: [0000a000,0000b000) size=4K avail=0 max_avail=0
>  Block: [0000b000,0000c000) size=4K avail=0 max_avail=0
>  Block: [0000c000,0000d000) size=4K avail=0 max_avail=0
>  Block: [0000d000,0000e000) size=4K avail=0 max_avail=0
>  Block: [0000e000,0000f000) size=4K avail=0 max_avail=0
>  Block: [0000f000,00010000) size=4K avail=0 max_avail=0
>  Block: [00010000,00011000) size=4K avail=0 max_avail=0
>  Block: [00011000,00012000) size=4K avail=0 max_avail=0
>  Block: [00012000,00013000) size=4K avail=0 max_avail=0
>  Block: [00013000,00014000) size=4K avail=0 max_avail=2619220K
>  Block: [00014000,00015000) size=4K avail=0 max_avail=0
>  Block: [00015000,00016000) size=4K avail=0 max_avail=0
>  Block: [00016000,00017000) size=4K avail=0 max_avail=0
>  Block: [00017000,00018000) size=4K avail=0 max_avail=0
>  Block: [00018000,00019000) size=4K avail=0 max_avail=0
>  Block: [00019000,0001a000) size=4K avail=0 max_avail=908K
>  Block: [0001a000,0001b000) size=4K avail=0 max_avail=0
>  Block: [0001b000,0001c000) size=4K avail=0 max_avail=908K
>  Block: [0001c000,0001d000) size=4K avail=0 max_avail=0
>  Block: [0001d000,00100000) size=908K avail=908K max_avail=908K
>  Block: [00228000,00229000) size=4K avail=0 max_avail=0
>  Block: [00229000,0022a000) size=4K avail=0 max_avail=2619220K
>  Block: [0022a000,0022b000) size=4K avail=0 max_avail=0
>  Block: [0022b000,a0000000) size=2619220K avail=2619220K max_avail=2619220K
>  Block: [b0000000,bfeff000) size=261116K avail=261116K max_avail=2619220K
>  Block: [bff04000,bfffd000) size=996K avail=996K max_avail=996K
>  => mem_size=2951536640 (2814 MB) / mem_avail=2951413760 (2814 MB)
>
> :phys_alloc: Allocator 0x1f4f18 dump:
>  Block: [00001000,00002000) size=4K avail=0 max_avail=0
>  Block: [00002000,00003000) size=4K avail=0 max_avail=0
>  Block: [00003000,00004000) size=4K avail=0 max_avail=0
>  Block: [00004000,00005000) size=4K avail=0 max_avail=0
>  Block: [00005000,00006000) size=4K avail=0 max_avail=0
>  Block: [00006000,00007000) size=4K avail=0 max_avail=0
>  Block: [00007000,00008000) size=4K avail=0 max_avail=0
>  Block: [00008000,00009000) size=4K avail=0 max_avail=0
>  Block: [00009000,0000a000) size=4K avail=0 max_avail=0
>  Block: [0000a000,0000b000) size=4K avail=0 max_avail=0
>  Block: [0000b000,0000c000) size=4K avail=0 max_avail=0
>  Block: [0000c000,0000d000) size=4K avail=0 max_avail=2014484K
>  Block: [0000d000,0000e000) size=4K avail=0 max_avail=0
>  Block: [0000e000,0000f000) size=4K avail=0 max_avail=0
>  Block: [0000f000,00010000) size=4K avail=0 max_avail=0
>  Block: [00010000,00011000) size=4K avail=0 max_avail=0
>  Block: [00011000,00012000) size=4K avail=0 max_avail=0
>  Block: [00012000,00013000) size=4K avail=0 max_avail=0
>  Block: [00013000,00014000) size=4K avail=0 max_avail=0
>  Block: [00014000,00015000) size=4K avail=0 max_avail=0
>  Block: [00015000,00016000) size=4K avail=0 max_avail=0
>  Block: [00016000,00017000) size=4K avail=0 max_avail=0
>  Block: [00017000,00018000) size=4K avail=0 max_avail=0
>  Block: [00018000,00019000) size=4K avail=0 max_avail=2014484K
>  Block: [00019000,0001a000) size=4K avail=0 max_avail=0
>  Block: [0001a000,0001b000) size=4K avail=0 max_avail=452K
>  Block: [0001b000,0001c000) size=4K avail=0 max_avail=0
>  Block: [0001c000,0001d000) size=4K avail=0 max_avail=452K
>  Block: [0001d000,0008e000) size=452K avail=452K max_avail=452K
>  Block: [00100000,00101000) size=4K avail=0 max_avail=2014484K
>  Block: [00101000,00102000) size=4K avail=0 max_avail=0
>  Block: [00102000,00400000) size=3064K avail=3064K max_avail=3064K
>  Block: [02800000,02801000) size=4K avail=0 max_avail=2014484K
>  Block: [02801000,7d746000) size=2014484K avail=2014484K max_avail=2014484K
>  Block: [80001000,b2cfb000) size=832488K avail=832488K max_avail=2014484K
>  Block: [b3aff000,b3b00000) size=4K avail=4K max_avail=4K
>  => mem_size=2919030784 (2783 MB) / mem_avail=2918903808 (2783 MB)

Only the available RAM below 4 GiB is used in the 32-bit scenario.

> :io_mem_alloc: Allocator 0x1f6ffc dump:
>  Block: [00000000,00001000) size=4K avail=4K max_avail=4K
>  Block: [0008e000,00100000) size=456K avail=456K max_avail=456K
>  Block: [b2cfb000,b3aff000) size=14352K avail=14352K max_avail=1250300K
>  Block: [b3b00000,fffff000) size=1250300K avail=1250300K max_avail=1250300K
>  => mem_size=1295474688 (1235 MB) / mem_avail=1295474688 (1235 MB)
>
> :rom_fs: ROM modules:
>  ROM: [7fd20000,7fd34158) acpi_drv
>  ROM: [7da08000,7da09dab) config
>  ROM: [7fadc000,7fd15948) core.o
>  ROM: [7f873000,7f8f9960) device_pd
>  ROM: [7feb3000,7fefd99c) fb_drv
>  ROM: [0001b000,0001c000) hypervisor_info_page
>  ROM: [7e803000,7e841010) init
>  ROM: [7da0a000,7dab69b4) ld.lib.so
>  ROM: [7d86f000,7d996220) libc.lib.so
>  ROM: [7d9d8000,7d9dec5c) libc_pipe.lib.so
>  ROM: [7f9cc000,7f9d957c) libc_terminal.lib.so
>  ROM: [7f9da000,7fabe4e4) libiconv.lib.so
>  ROM: [7f960000,7f98696c) libm.lib.so
>  ROM: [7d9f9000,7da07de0) log_terminal
>  ROM: [7f987000,7f9cb2d0) nic_drv
>  ROM: [7d9df000,7d9f8d80) nit_fb
>  ROM: [7d997000,7d9d7ed0) nitpicker
>  ROM: [7f920000,7f95fce4) platform_drv
>  ROM: [7f842000,7f85cef4) ps2_drv
>  ROM: [7fd16000,7fd1f250) pthread.lib.so
>  ROM: [7f8fa000,7f91fc6c) qemu-usb.lib.so
>  ROM: [7e7ea000,7e802bd0) report_rom
>  ROM: [7fd35000,7fd4631c) rtc_drv
>  ROM: [7fd49000,7feb22fc) stdcxx.lib.so
>  ROM: [7e842000,7f842000) test.iso
>  ROM: [7fd47000,7fd48b36) test.vbox
>  ROM: [7f85d000,7f872ddc) timer
>  ROM: [7fefe000,7ffff60c) usb_drv
>  ROM: [7fabf000,7fadb898) vbox_pointer
>  ROM: [7dab7000,7e7e9480) virtualbox5-nova
>
> Genode 17.05 <local changes>
> 2783 MiB RAM and 63830 caps assigned to init
> [init] child "timer" announces service "Timer"
> [init] child "report_rom" announces service "Report"
> [init] child "report_rom" announces service "ROM"
> [init] child "log_terminal" announces service "Terminal"
> [init -> nic_drv] --- iPXE NIC driver started ---
> [init -> nic_drv] -- init iPXE NIC
> [init] child "acpi_report_rom" announces service "Report"
> [init] child "acpi_report_rom" announces service "ROM"
> [init -> acpi_drv] Found MADT
> [init -> acpi_drv] MADT IRQ 0 -> GSI 2 flags: 0
> [init -> acpi_drv] MADT IRQ 9 -> GSI 9 flags: 13
> [init -> acpi_drv] Found MCFG
> [init -> acpi_drv] MCFG BASE 0xe0000000 seg 0x0 bus 0x0-0xff
> Warning: PD (init -> acpi_drv) cap limit (used=19, limit=19) exceeded
> during transfer_quota(3)
> [init -> acpi_drv] resource_request: cap_quota=3
> [init -> acpi_drv] used before freeing emergency=1400K
> [init -> acpi_drv] used after freeing emergency=1384K
> [init] child "acpi_drv" requests resources: cap_quota=3

The acpi_drv runs out of capabilities, which renders it
non-functional. Please increase the number of caps available for the
component in your scenario.

> [init] child "rtc_drv" announces service "Rtc"
> [init -> vbox1] using the pipe libc plugin
> [init -> vbox2] using the pipe libc plugin
> [init -> vbox1] Warning: _sigaction: _sigaction not implemented
> [init -> vbox2] Warning: _sigaction: _sigaction not implemented
> [init -> vbox1] Warning: issetugid called, not yet implemented, returning 1
> [init -> vbox1] Warning: issetugid called, not yet implemented, returning 1
> [init -> vbox2] Warning: issetugid called, not yet implemented, returning 1
> [init -> vbox2] Warning: issetugid called, not yet implemented, returning 1
> [init -> vbox1] Error: fcntl(): command 2 not supported
> [init -> vbox1] Log created: 2017-07-24T20:00:00.000000000Z
> [init -> vbox1] main     Executable: /virtualbox
> [init -> vbox1] Error: SystemPropertiesWrap : Cannot determine default
> Guest Additions ISO location. Most likely they are not available
> [init -> vbox2] Error: fcntl(): command 2 not supported
> [init -> vbox2] Log created: 2017-07-24T20:00:00.000000000Z
> [init -> vbox2] main     Executable: /virtualbox
> [init -> vbox2] Error: SystemPropertiesWrap : Cannot determine default
> Guest Additions ISO location. Most likely they are not available
> [init -> vbox1] Warning: _sigaction: _sigaction not implemented
> [init -> vbox1] i_saveSettings skipped
> [init -> vbox2] Warning: _sigaction: _sigaction not implemented
> [init -> vbox2] i_saveSettings skipped
> [ 0] DMAR:0xc002a060 FRR:0 FR:0x5 BDF:0:14:0 FI:0xb3575000
> [ 0] DMAR:0xc002a060 FRR:0 FR:0x5 BDF:0:14:0 FI:0xb3575000
> [ 0] DMAR:0xc002a060 FRR:0 FR:0x6 BDF:0:14:0 FI:0xb3575000

I expect PCI device 0:14:0 to be your NIC which still finished some
DMA transactions after network boot. Is that correct?

As the ACPI driver does not finish its initialization the platform
driver and all other drivers cannot start. If you fix the cap shortage
your scenario will proceed further.

Greets
--
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
genode-main@...172...net
https://lists.sourceforge.net/lists/listinfo/genode-main



--


Thank You,

Chris Rothrock
Senior System Administrator
(315) 308-1637