Bender and GRUB1 "legacy"

[Valery V. Sedletski]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20180304/301acec7/attachment.html>