users

users@lists.genode.org

4 participants
2327 discussions

minimizing physical memory budget
by Steven Harp 28 Jun '18

28 Jun '18

What are the main factors in estimating the minimum RAM quantum needed by a component? (Excluding for this discussion any dynamic allocation an application might perform.) The Genode Foundations book (18.05) suggests that if no quantum is specified, "init has a reasonable default of 160K (on 32 bit)". Experimentally, it seems like even the most modest components need more. For example the client side of the hello_tutorial, essentially 5 source lines and a 20K stripped ELF binary, seems to need about 500K on a 32-bit x86 system. At quantum="480K" for hello_client, one sees: Warning: PD (init -> hello_client) RAM limit (used=380K, limit=394587) exceeded during transfer_quota(6K) (and the test hangs.) At 425K, the result is: [init] child "hello_client" requests resources: ram_quota=69632 page fault, pd='init -> hello_client' thread='hello_client' cpu=0 ip=0xa2adc address=0xa00fde50 stack pointer=0x0 qualifiers=0x6 irUWp reason=1 At 300K, we see: [init] Error: allocation of read-write segment failed [init] Error: hello_client: out of RAM during ELF loading Is there a way to tweak component compilation/linking parameters to minimize physical RAM required? // Steve Harp

2 1

Fwd: problem with routing of reports/ROMs inside runtime
by Pirmin Duss 28 Jun '18

28 Jun '18

Hello Norman On 27.06.2018 15:15, Norman Feske wrote: > just as a shot in the dark, could it possibly be that the > "layout_controller" closes the report session right after submitting the > report, e.g., by using a 'Reporter' as a local variable that is > destructed when leaving its scope? Yes, this is the problem. It uses an Expanding_reporter inside the method that creates the configuration. Many thanks, Pirmin

1 0

problem with routing of reports/ROMs inside runtime
by Pirmin Duss 27 Jun '18

27 Jun '18

Hello list While testing the configuration update for the floating_window_layouter I encountered a problem. Inside the signal handler for the config update the configuration is always "<empty/>". In the log I see that layout_controller writes the report "layout_controller -> layouter_config" and that the layouter receives a signal. But after a config.update() the content of config.xml() is always empty. <config> ... <default-route> <any-service> <parent/> <any-child/> </any-service> </default-route> ... <start name="report_rom"> <resource name="RAM" quantum="4M"/> <provides> <service name="Report"/> <service name="ROM"/> </provides> <config verbose="yes"> <policy label="layouter -> window_list" report="wm -> window_list"/> <policy label="layouter -> focus_request" report="wm -> focus_request"/> ... <policy label="layouter -> config" report="layout_controller -> layouter_config"/> </config> </start> ... <start name="layout_controller"> <resource name="RAM" quantum="4M"/> <route> <service name="Report" label="layouter_config"> <child name="report_rom"/> </service> <any-service> <parent/> <any-child/> </any-service> </route> </start> ... <start name="layouter"> <binary name="floating_window_layouter"/> <resource name="RAM" quantum="4M"/> <route> <service name="ROM" label="config"> <child name="report_rom"/> </service> <service name="ROM" label="decorator_margins"> <child name="report_rom"/> </service> <service name="ROM" label="focus_request"> <child name="report_rom"/> </service> <service name="ROM" label="hover"> <child name="report_rom"/> </service> <service name="ROM" label="window_list"> <child name="report_rom"/> </service> <service name="Report"> <child name="report_rom"/> </service> <any-service> <child name="wm"/> <parent/> <any-child/> </any-service> </route> </start> ... </config> I also have tried to change the route and the policy as follows: <service name="ROM" label="config"> <child name="report_rom" label="layouter_config"/> </service> <policy label="layouter -> layouter_config" report="layout_controller -> layouter_config"/> But this also didn't help. LOG: [runtime -> wm -> layouter] config at startup: <empty/> [runtime -> wm -> report_rom] report 'layout_controller -> layouter_config' [runtime -> wm -> report_rom] <config> [runtime -> wm -> report_rom] ... [runtime -> wm -> report_rom] </config> [runtime -> wm -> layouter] config update signal [runtime -> wm -> layouter] new config: <empty/> Does anybody see the error, that my colleague an I weren't able to find? Best regards Pirmin

2 1

Doubts regarding IRQ capabilities in L4 fiasco and genode
by Harsha Sharma 27 Jun '18

27 Jun '18

Dear Genode Community, I have some doubts regarding handling IRQ capabilities in L4 fiasco microkernel and Genode. L4 kernel maps IRQs to IRQ kernel objects which are created using l4_factory_create_irq using factory object. In genode, we attach IRQ capabilites to entrypoint thread with l4_irq_attach in core component. Also, signal handler session returns signal context capabilities from core component and l4_irq_attach is also called in signal_source_client. What is the difference between signal context capabilities and IRQ capabilities? (Or IRQ capabilities are kernel space capabilities and signal context capabilities are genode cap map capabilities) Is it possible to attach entrypoint thread to IRQ object capability outside of core component ? Actually, I'm working on checkpoint/restore project in genode and L4 fiasco. And comparing the kernel cap space before checkpoint and restoring state, we find out that IRQ kernel object capabilities are not same. Signal context capabilities are checkpointed and restored correctly, but problem is (most probably), that while restoring, we don't attach it to entrypoint thread. One approach is to intercept, IRQ session and then attaching irq capability to entrypoint thread capability in restoring process. Please correct me if I am wrong somewhere and any suggestions on above approach will be really appreciated. Thanks a lot. Regards, Harsha Sharma [1]. https://sourceforge.net/p/genode/mailman/genode-main/thread/f64ed643-33a3-d…

1 0

update config of floating_window-layouter at runtime
by Pirmin Duss 27 Jun '18

27 Jun '18

Hello list We would like to change the configuration of the floating_window_layouter while it is running (change key shortcuts, set policies for some windows (only for newly created ones)). Unfortunately it only reads the configuration at startup. Is there a specific reason, why this is so, or is it only because there was no requirement for this? Otherwise I would volunteer to implement the corresponding changes and test them. best regards Pirmin

2 1

BUILD TOOLCHAIN FOR ARM
by athul vincent 25 Jun '18

25 Jun '18

HI, I wanted to build the tool chain for arm processor and to set up genode by qemu emulator. But when i build the genode tool chain for arm..it is asking for missing tools. athul@athul-HP-Pavilion-Notebook:~/genode/tool$ ./tool_chain Need to have GNAT installed and the GNAT version must match the GCC version (found GCC 7). tool_chain:155: *** Please install missing tools.. Stop. athul@athul-HP-Pavilion-Notebook:~/genode/tool$ I have installed the same versions for gcc and gnat. Can you help me?

2 1

Re: My experience with the official release of Sculpt TC
by Guido Witmond 22 Jun '18

22 Jun '18

On 06/22/2018 11:14 AM, Norman Feske wrote: > Hi Guido, > >> 1. I noticed that the debian iso-download on this 06-21 image was >> jittery, stopping the now-counter for a second every few MBs. Is that an >> effect of these patches? > > I don't think so. I suppose you were testing this with the RAM fs? If > yes, the jittery effect may be caused by the successive expansion of the > RAM file system. Each time it runs out of RAM quota, it blocks until the > sculpt manager explicitly increases the quota. The current quota is > displayed as capacity value of the 'ram' storage item. When it stops for > a moment, you'll most likely see the value increase shortly afterward, > before the download continues. I haven't seen the jitter with the RAM-fs, although I saw it expanding. I noticed it with the freshly expanded GENODE partition on my usb-2 stick. (the previously 'bad' one). Perhaps it's too much people watching netflix... >> 2. With the old (sculpt-tc) image, the debian download sometimes hang >> with what looked like a filesystem lockup. > No. We rarely (I have seen it only twice in the last two months) observe > instabilities of the rump-based file-system server. Once this happens, > you may try closing the inspect window (by disabling all 'inspect' > buttons), and then opening the inspect window for the ram fs (which > should not be affected). Then you can inspect the '/report/log' for > file-system-related error messages. > > It would be cool to secure the log should encounter the problem again. I'll try to replicate it. Wish me luck. Cheers, Guido.

1 0

Re: My experience with the official release of Sculpt TC
by Guido Witmond 22 Jun '18

22 Jun '18

I forgot to sent this to the list for everyone, not just the spooks who tapped the line ;-) On 06/21/2018 01:51 PM, Norman Feske wrote: > Hi Guido, > >>> thanks for the report and the log. I have a faint suspicion. >>> > > could you please give the following image a try? > > http://genode.org/files/nfeske/sculpt-2018-06-21.img Hi Norman, Your hunch was correct, this image runs the expand process correctly on my 'bad' stick. I ran it three times just to make sure, both in usb2 and usb3 sockets. All good. Other news: 1. I noticed that the debian iso-download on this 06-21 image was jittery, stopping the now-counter for a second every few MBs. Is that an effect of these patches? 2. With the old (sculpt-tc) image, the debian download sometimes hang with what looked like a filesystem lockup. I could not save the config/deploy, nor exit vim. Other processes seemed unaffected. Is that lockup to be expected from the old code? It could also have been a memory error I encountered with memtest. But that was transient. I could not pinpoint it to a single DIMM, nor did it occur any time after that. Perhaps this iron is getting old and flaky. Anyway, thanks for the patch. I've attached the log. Cheers, Guido.

2 1

*****SPAM***** Sculpt TC and multi core virtual machines
by Duss Pirmin 22 Jun '18

22 Jun '18

Spam detection software, running on the system "obelix.duss.local", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see root@localhost for details. Content preview: Hello list I have played around with the sculpt TC a lot recently, and like it. One thing that I'm curious about is if I do a parallel build inside my virtual machine, that is configured to have two cores, both [...] Content analysis details: (8.7 points, 5.5 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 CK_HELO_GENERIC Relay used name indicative of a Dynamic Pool or Generic rPTR 2.9 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split IP) 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [83.77.14.147 listed in dnsbl.sorbs.net] 3.6 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [83.77.14.147 listed in zen.spamhaus.org] 1.6 RCVD_IN_BRBL_LASTEXT RBL: No description available. [83.77.14.147 listed in bb.barracudacentral.org] 0.4 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS

1 0

My experience with the official release of Sculpt TC
by Guido Witmond 21 Jun '18

21 Jun '18

Hi Genodians, I tried this version too. It has some visual differences: - the network-section has these buttons: Off, Local, Wired. While the 18.05 version had Off, Wired, Wifi. There is no mention of Local in the Sculpt article. The Expand option of the GENODE-partition hang at first with an error: [runtime -> usb-1-2.part_blk] Error: Block-session creation failed (ram_quota=4208640, cap_quota=5, tx_buf_size=4194304, label="") [runtime -> usb-1-2.part_blk] Error: Uncaught exception of type 'Genode::Service_denied' When I plugged in a second USB-stick, the resize proces restarted and delivered a bootable resized stick. In case you're interested, I attached the LOG of that session. Cheers, Guido.

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users