On 01.03.2018 11:25, Norman Feske wrote:
Hi Valery,
[init] [31mError: RAM preservation exceeds available memory[0m[0m [init] [34mWarning: runtime: assigned RAM exceeds available RAM[0m[0m ... [init] [34mWarning: specified quota exceeds available quota, proceeding with a quota of 3424667716[0m[0m [init] [34mWarning: runtime: assigned caps (50000) exceed available caps (1381)[0m[0m
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] [34mWarning: abort called - thread: ep[0m[0m [init -> drivers] child "driver_manager" exited with exit value 1[0m[0m
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] [31mError: Could not open ROM session for "platform_info"[0m[0m [init -> drivers -> driver_manager] [31mError: Uncaught exception of type 'Genode::Rom_connection::Rom_connection_failed'[0m[0m
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