On 01.03.2018 11:25, Norman Feske wrote:
Hi Valery,

[init] Error: RAM preservation exceeds available memory
[init] Warning: runtime: assigned RAM exceeds available RAM
...
[init] Warning: specified quota exceeds available quota, proceeding
with a quota of 3424667716
[init] Warning: runtime: assigned caps (50000) exceed available
caps (1381)
these messages are normal. Sculpt assigns all remaining memory and caps
to the runtime subsystem by specifying large amounts of quota to the
runtime start node (the real amount is not prior known). It is nothing
to worry about - we should definitely try to silence those messages in
the future.

You don't see any additional messages with Sculpt because the log of the
drivers subsystem is redirected to the report file system so that the
Sculpt user can inspect it once the system is up and running. Hence, the
drivers log is not routed to core's LOG service. For debugging, you may
remove the following routing rule from the "drivers" start node of the
sculpt.run script:

   <service name="LOG"> <child name="log"/> </service>

With this rule removed, the routing falls back to the parent. Now, with
the LOG session routed to core, you should be able to see what the
drivers are complaining about.

Cheers
Norman

Thanks for the hint! Ok, I commented the routing rule, and similar

routing rules for "runtime" and "leitzentrale" too, just in case. I got the following log: [1].

So, the problem is with this:

init -> drivers -> driver_manager] Warning: abort called - thread: ep
[init -> drivers] child "driver_manager" exited with exit value 1

Running sculpt_test.run in QEMU, I see exactly the same error! (The QEMU version I'm

using is 2.8.1 -- the version from Debian Stretch).

These messages:

[init -> drivers -> driver_manager] Error: Could not open ROM session for "platform_info"
[init -> drivers -> driver_manager] Error: Uncaught exception of type 'Genode::Rom_connection::Rom_connection_failed'

are strange, because "platform_info" seems to be optional. Previously, it failed too in different scenarios,
but it was not fatal.

PS: A good idea might be to "#ifdef" these routing rules in XML config somehow. If I correctly
remember, there are some conditional XML tags in "config" file syntax. So, probably it should
look like this: you specify a special parameter in "core" command line, and it gets passed to "init"
from "core". So, probably, "core" should create a new ROM module containing the variable list with
their values (probably, in XML syntax). So, if "init" sees this module, it gets varable names and
values from that module, and uses them like C preprocessor defines, so some "config" parts
can be #ifdef-ed. This way, for example, routing rules can be skipped, if some variable has
some special value. This allows to bypass the routing rules without the need to rebuild the
"core " image on each "config" change, for trouble-shooting purposes. So, specifying a special
command line parameter in "core" command line allows to redirect the log back to "core".
This might be impossible on ARM bootloaders, of course, but it takes advantage of some
GRUB-like loaders' features. So, this way some troubleshooting modes can be implemented,
without the need to alter the "core" image. What do you think?

[1] https://pastebin.mozilla.org/9078923 Sculpt on Genode/Fiasco.OC (Athlon 64 machine)

WBR,

valery