Error unable to initialize cap quota of PD

[Norman Feske]

Hi Jörg,

thanks for the detailed description of the issue. Please find my
comments inline.

I must admit that the launcher.run scenario is outdated since I use it
very sporadically - only when working on one of the used components.
Whenever I use it for this purpose, I use to run it on base-linux. So
the current resource assignments are in general insufficient for other
base platforms. It would be a good idea to move such kinds of
"development-vehicle" scenarios to a dedicated place as discussed in [1]
to spare people like you such negative surprises.

[1] https://github.com/genodelabs/genode/issues/1372

> ...
> Warning: PD (init -> drivers) cap limit (used=44, limit=46) exceeded
> during transfer_quota(4)
> ...
> 
> I want to fix that and try to understand what is the root cause for this
> warning. I read the documentation, mainly 6.2.2. Resource assignment ->
> Capability budget.

When a client creates a new session, its tells its parent to transfer
some of the client's resources to the server. In this case, the client
is willing to lend 4 caps to the server. The common parent of the client
and server will try to decrease the limit of the client by 4 and
increase the limit of the server by the same value. However, since
client has only 2 unused caps on its account, this attempt fails.

This message points at a too scarce resource assignment for the
'drivers' subsystem. In the run script, there are merely 300 caps
assigned to the 'drivers'. The value suffices for the little driver
support needed for 'drivers_interactive-linux' but not for the much more
complex 'drivers_interactive-pc' subsystem (as selected on NOVA). When
setting the value to 1000 (as done in the wm.run script), the repeated
error messages disappear.

While giving the scenario a quick spin, I observed another cap-quota
issue, which is caused by the too low default value of 50 - the value
used for all <start> notes that lack an explicit 'caps' attribute. By
setting this value to 100, the scenario starts up with NOVA on Qemu
(tested on the current staging branch). However, apparently the launcher
component also needs a few quota adjustments. I just fixed the
corresponding parts in the commit [2] on the staging branch. May you
give it a try?

[2]
https://github.com/genodelabs/genode/commit/94ef138f223ce6d9ab4a2608bc7cc73a76463335

> But I'm not smart enough to understand this ;-), again I'm a newbie :-).
> Is there some other documentation or another chapter that I should read
> ? By the way, I read the hole old documentation 16.05 before.

The release notes for 17.05 may hopefully be helpful [3].

[3]
http://genode.org/documentation/release-notes/17.05#Assignment_and_trading_of_capability_quota

> First, I didn't found any <start> configuration for:
> - platform_drv
> - fb_drv
> - usb_drv
> - input_filter

These components come from the 'drivers' subsystem, which is
incorporated via the 'drivers_interactive-pc' depot package. The depot
mechanism is brand new and may admittedly still be a bit rough around
the edges. You can find its documentation at [4].

[4] http://genode.org/documentation/developer-resources/package_management

> I think the root cause is following Error:
> [init -> drivers] Error: acpi_drv: unable to initialize cap quota of PD
> I understand that the acpi_drv component need X caps to transfer to the
> drivers component. But how many caps ?

You are spot on. The best practices regarding the assignment of cap
quotas are still in flux. As a rule of thumb, I'd account 100 caps per
component. The 'drivers' subsystem [5] is an init instance with 7
children (as of now). Hence, assigning 1000 caps to the subsystem seems
to be reasonable.

[5] repos/os/recipes/raw/drivers_interactive-pc/drivers.config

> Then I try to understand the warning for example:
> [init -> drivers] Warning: ps2_drv: assigned caps (60) exceed available
> caps (0)
> What I understand after reading the documentation: ps2_drv try to give
> the drivers component 60 caps but they have only 0 caps left?

It is a subsequent error of the one discussed above. During the creation
of the 'drivers' children, the cap quota of the 'drivers' subsystem
exhausts so that no caps are left for the PS2 driver. The problem is
fixed with the increased quota of the 'drivers' subsystem.

> Also I try to understand the following warning:
> Warning: PD (init -> drivers) cap limit (used=44, limit=70) exceeded
> during transfer_quota(28)
> I understand:
> The drivers component used 44 caps. The component need additional caps
> of 28 but the limit of 70 caps is exceeded. (44 + 28 = 72 > 70)
> Why limit 70? In the start configuration we set for the drivers
> component 300 caps.

The limit of a component decreases each time it creates a session to a
service where it transfers some of its own quota limit to the server.

Initially, the limit of 'drivers' is 300. But as soon as 'drivers'
creates sessions to the outside, its limit decreases step by step. You
can think of the limit as the balance of a bank account. It you transfer
money to another account, the balance decreases. The "used" value is the
fraction of the quota that the component turned into actual resources
(like RPC objects, dataspaces, signal handlers). To stay with the
analogy, these are the purchased goods.

> PD (init -> drivers) consumed RPC cap (used=41, limit=280)
> ...
> After consumed RPC cap and using of 39 caps, there is additional
> consumed RPC with a used of 41 ? Why not 40 ?

The messages only cover the allocation and destruction of RPC
capabilities. But there are also dataspace capabilities and
signal-context capabilities, which not shown but still are accounted
for. The most likely case is that the component creates a signal handler
or a dataspace.

But even the creation of an RPC object may result in the consumption of
more than one capability: Whenever core needs to extend the backing
store for its book keeping (e.g., for keeping track of the RPC caps
created by a PD), core creates a new dataspace, which implicitly
requires a dataspace capability. All these meta-data costs are accounted
for.

> I'm really sure I missed something, but I don't know what. Maybe the root
> cause is somewhere else. Hopefully somebody give me a hint and/or
> explain me the log output of "caps" warning. I found the log in the
> source but even that, I'm not fully understand the purpose of the log.

I hope the above explanation sounds logical. Thanks for bringing up this
topic on the mailing list. You may not be the only one confused by the
messages. Finally, let me compliment you for using the "diag" feature
and for including all important details of your scenario at the start of
your posting.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

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