Thank you for your help! I managed to get rid of the quota error msg by inserting the upgrade() statement in another process at the beginning. However, I also tried your kernel debugger suggestion to see which thread was in "send" state while that msg was printed out. It actually contradicts what I expected. Let me describe my approach in more detail.
I have two major processes, P1 and P2. P2 will use P1's service every so often in the runtime. At first I only have upgrade() statement in P2, but I saw that error msg. Then I found out that right after that error msg, the next line printout is " [init->P1] upgrading quota donation for Env::RAM session ". Thus, I think it was P1 to blame. So I went ahead and added upgrade() to P1 too. After that, no error msg appeared and I thought I fixed the quota problem.
However, when I commented out the upgrade() statement in P1 and added an infinite loop in Genode core as you suggested, I saw in kernel debugger that P2 is in the "send" state as opposed to P1. This confused me because I had expected that P1 would be in "send" state. My only guess is that by increasing P1's quota, P2 also benefits from that. I'm not sure by default how much quota is assigned to each process in Genode initially. In my upgrade() statement, I give 32M to each process.
Any thought is greatly appreciated!
From: Norman Feske [mailto:norman.feske@...]
Sent: Monday, April 22, 2013 2:54 AM
Subject: Re: "Could not allocate metadata" error msg
> Can anyone give me a hint on how to get rid of the "Could not allocate
> metadata" error msg? Or, how can I effectively increase the quota for that?
your question too generic to give you a definite answer. Your complete LOG output and a way to reproduce the problem (i.e., a run script) would help.
However, let me try to guide you for finding the problem yourself. The message "Could not allocate metadata" is printed by core's RAM service when there is not enough session quota left for holding meta data about allocated/free memory blocks. Hence, your attempt to upgrade the session quota using 'parent()->upgrade()' was actually spot-on. However, since you report that the upgrade did not solve your problem, I suppose that the session that produced the error message is not the one represented by the 'env()->ram_session_cap()' argument you passed to the upgrade function.
Unfortunately, the message printed by core leaves little insight about the client that triggered the problem. To reveal a bit more information, you may find the patch "Debug: print session labels if quota exceeds" in the following branch useful:
Just cherry-pick the commit and adjust it as needed, e.g., you may enhance the error message with additional status information of the RAM session. Right now, it just appends the session label as additional information, which may already guide you to the right spot.
Another approach to find the troubling session it to let core block once the error condition occurs. I.e., just temporarily insert an infinite loop after the message is printed. This way, core will get stuck at that point and, consequently, not reply the RPC call that triggered the problem. Now, when the condition occurs, you can enter the Fiasco.OC kernel debugger and look up the thread that is currently doing an IPC call to core's entrypoint thread. Use the 'lp' command to list the threads and look at their respective states. Knowing the troubling thread will probably be helpful.
Good luck! If you manage to encircle the problem, I would greatly appreciate if you report the issue (and possibly your fix).
Dr.-Ing. Norman Feske
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
Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account!
Genode-main mailing list