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/94ef138f223ce6d9ab4a2608bc7cc73a...
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_o...
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