users

users@lists.genode.org

1 participants
2310 discussions

Repeated TCP connection cause stack problems
by Stefan Thöni 22 Nov '19

22 Nov '19

Hi Genodians, for our current project we would like to use the lwip stack. We discovered that repeated tcp connections cause a segfault or assert both under nova and linux. Then we switched to the lxip stack which fares better but gets stuck after 340 tcp connections both under nova and linux. I've uploaded a stress test run script named "tcp_stress_lwip" and "tcp_stress_lxip" respectively that shows this problem: https://github.com/throwException/genode/commits/tcp_stress_test Does anyone have any ideas on how to fix any of these problems? (If the problems get fixed it might be a good idea to integrate these stress tests into automated regression tests.) Kind regards Stefan -- Freundliche Grüsse Stefan Thöni Chairman of the Board Senior Security Architect +41 79 610 64 95 gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

1 0

Building "gdb_monitor_interactive" problem
by Marcin.Motylinski＠umlaut.com 22 Nov '19

22 Nov '19

Dear, I try to find a way to debug components under Genode. My target platform is Linux kernel that runs on x86_64 platform, but as it was stated in document https://genode.org/documentation/developer-resources/gdb one is not supported for now. Is it true? Can I expect any support in future? Anyway, I tried to build and run "gdb_monitor_interactive" example, using Fiasco.OC and x86_32 platform. For now, I'm facing following issue: ... Program lib/ld/foc/ld-foc make[1]: Leaving directory '/home/marcin/projects/genode/build/x86_32' genode build completed using 'core-foc-pc.o' as 'core.o' using 'gdbserver_platform-foc.lib.so' as 'gdbserver_platform.lib.so' error copying "bin/gdbserver_platform-foc.lib.so": no such file or directory while executing "file copy -force bin/[kernel_specific_binary $binary] [run_dir]/genode/$binary" (procedure "copy_genode_binaries_to_run_dir" line 4) invoked from within "copy_genode_binaries_to_run_dir $modules" (procedure "build_core_image" line 12) invoked from within "build_core_image $binaries" (procedure "run_boot_dir_x86" line 21) invoked from within "run_boot_dir_x86 $binaries" (procedure "run_boot_dir" line 3) invoked from within "run_boot_dir $binaries" (procedure "build_boot_image" line 34) invoked from within "build_boot_image $boot_modules" (file "/home/marcin/projects/genode/repos/ports/run/gdb_monitor_interactive.run" line 94) invoked from within "source $include_name" ("foreach" body line 6) invoked from within "foreach include_name [get_cmd_arg --include ""] { # first check if the include name is absolute if {[string first "/" $include_name] == 0} { puts ..." (file "/home/marcin/projects/genode/tool/run/run" line 1006) Makefile:323: recipe for target 'run/gdb_monitor_interactive' failed make: *** [run/gdb_monitor_interactive] Error 1 when I'm running 'make run/gdb_monitor_interactive KERNEL=foc' under x86_32 platform. There's no 'gdbserver_platform-foc.lib.so' in build folder tree, only 'gdbserver_platform.lib.so' exists. I'm using Genode 19.08. -- Marcin Motylinski umlaut marcin.motylinski(a)umlaut.com www.umlaut.com P3 eS GmbH legal disclaimer, mandatory information and the umlaut office addresses can be found at https://imprint.umlaut.com/SES

2 1

[ukvly-announce] CfP: FOSDEM 2020 - Microkernels and Component-based OS devroom (fwd)
by Christian Helmuth 15 Nov '19

15 Nov '19

-- Christian Helmuth Genode Labs https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

seL4/Genode on zynq7000; TTC Timer Component
by Alexander Weidinger 01 Nov '19

01 Nov '19

Hello Genodians, we adapted the zynq7000 target to run with Genode/seL4[4], which was done accordingly to the imx6 and imx7 targets already existing in Genode. Since we are in need for a timer component and the seL4 doesn't provide a "l4_ipc_sleep()" call, like it is used for the generic timer component in Fiasco.OC, we started implementing a timer[1,2] based on the TTC of the Zynq7000[0]. By now we have it up and running but with a high deviation the longer it runs (already 30 seconds deviation after only 2 minutes). This deviation originates from a few problems we have: - The timers in TTC only provide a 16 Bit width -> high number of IRQs when trying to achieve high precision - The input clock is 133MHz and can only be prescaled by a division of 2^(n+1) with 0 < n <= 16 -> hard to work with? Currently we implement it similar to the imx6 timer, by generating IRQs when a match in the MATCH0 register is acknowledged. I'm not very experienced in this topic and any help is appreciated on how to resolve the deviation issues or how to implement it in a better way - e.g. by using a different hardware timer which I didn't discover in the TRM. Additionally I'd like to know if there is an easy way to configure the maximum RAM of a platform in seL4/Genode apart from limiting it in 'contrib/sel4-*/src/kernel/sel4/include/plat/*/plat/machine/hardware.h'? Best regards, Alex PS: As Zynq7000 platform we use the Digilent Zybo[3]. [0]: https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TR… [1]: https://github.com/irgendwie/genode/blob/rtcr-19.08-ttc/repos/base/src/time… [2]: https://github.com/irgendwie/genode/blob/rtcr-19.08-ttc/repos/base/src/time… [3]: https://store.digilentinc.com/zybo-zynq-7000-arm-fpga-soc-trainer-board/ [4]: https://github.com/irgendwie/genode/commit/60ffef31b52d6566f481b3de87b4720f…

3 4

Gdb in Nova - Error: no plugin found for fstat(3)
by Alexander Tormasov 29 Oct '19

29 Oct '19

I am trying to run gdb test (gdb_monitor.run) on Nova/x64 Initially it give error «no memory on address»vin attempt to force breakpoint set : [init -> gdb_monitor] Warning: read: no memory at address 0x1000000 After enlarging memory quota in run script (twice each monitor and test image) it start working (too slow - like 20 sec per step typically, anyway it works). In the logI see during boot around 1000 lines of attempt to touch all available fd which failed (see in log below). [init -> gdb_monitor] Error: no plugin found for fstat(3) Can I do something with it? I run fresh qemu 4.1 from host, run script from repos without any changes. Command line qemu-system-x86_64 -no-kvm -cpu core2duo -nographic -serial mon:stdio -serial chardev:uart -chardev socket,id=uart,port=5555,host=10.211.55.2,server,nowait,ipv4 -m 512 -cdrom gdb_monitor.iso -machine q35 CPU ID (genode->kernel:package:core:thread) remapping remap (0->0:0:0:0) boot cpu Hypervisor info page contains 13 memory descriptors: core image [0000000000100000,0000000000cf1000) binaries region [000000000035a000,0000000000cf1000) free for reuse detected physical memory: 0x0000000000000000 - size: 0x000000000009fc00 use physical memory: 0x0000000000000000 - size: 0x000000000009f000 detected physical memory: 0x0000000000100000 - size: 0x000000001fedf000 use physical memory: 0x0000000000100000 - size: 0x000000001fedf000 detected res memory: 0x1f3ec000 - size: 0xbf22f0 type=-2 detected res memory: 0x9fc00 - size: 0x400 type=2 detected res memory: 0xf0000 - size: 0x10000 type=2 detected res memory: 0x1ffdf000 - size: 0x21000 type=2 detected res memory: 0xb0000000 - size: 0x10000000 type=2 detected res memory: 0xfed1c000 - size: 0x4000 type=2 detected res memory: 0xfffc0000 - size: 0x40000 type=2 detected res memory: 0xfd000000 - size: 0x2800001e00120 type=-5 detected res memory: 0x1000000 - size: 0x800000 type=-1 detected res memory: 0x1800000 - size: 0x1c00000 type=-1 detected res memory: 0x1ffe20d2 - size: 0x0 type=-3 ROM modules: ROM: [000000001f84d000,000000001f84d48a) config ROM: [000000000000f000,0000000000013000) core_log ROM: [000000001faa8000,000000001fbfd620) gdb_monitor ROM: [000000001fdb4000,000000001fdf62b8) gdbserver_platform.lib.so ROM: [000000001ff50000,000000001ffdde80) init ROM: [000000001fdf7000,000000001ff4fce8) ld.lib.so ROM: [000000001f84e000,000000001faa7540) libc.lib.so ROM: [000000001fbfe000,000000001fc0bec8) libc_pipe.lib.so ROM: [000000001fc36000,000000001fc82868) libm.lib.so ROM: [000000001fc86000,000000001fcbec58) pc_uart_drv ROM: [000000000000d000,000000000000e000) platform_info ROM: [000000001fda8000,000000001fdb38a8) posix.lib.so ROM: [000000001f647000,000000001f84ccb8) stdcxx.lib.so ROM: [000000001fc83000,000000001fc857c8) test-gdb_monitor ROM: [000000001fc0c000,000000001fc35e78) timer ROM: [000000001fcbf000,000000001fda7cc0) vfs.lib.so 36M kernel memory Genode 19.08 462 MiB RAM and 63254 caps assigned to init [init] parent provides [init] service "ROM" [init] service "IRQ" [init] service "IO_MEM" [init] service "IO_PORT" [init] service "PD" [init] service "RM" [init] service "CPU" [init] service "LOG" [init] child "timer" [init] RAM quota: 1800K [init] cap quota: 68 [init] ELF binary: timer [init] priority: 0 [init] provides service Timer [init] child "pc_uart_drv" [init] RAM quota: 1800K [init] cap quota: 68 [init] ELF binary: pc_uart_drv [init] priority: 0 [init] provides service Terminal [init] provides service Uart [init] child "gdb_monitor" [init] RAM quota: 7944K [init] cap quota: 168 [init] ELF binary: gdb_monitor [init] priority: 0 [init -> pc_uart_drv] --- UART driver started --- [init] child "pc_uart_drv" announces service "Uart" [init] child "pc_uart_drv" announces service "Terminal" [init] child "timer" announces service "Timer" [init -> pc_uart_drv] open IRQ 3 [init -> pc_uart_drv] [init -> pc_uart_drv] Warning: baud_rate 0 not supported, set to default [init -> pc_uart_drv] [init -> gdb_monitor] using the pipe libc plugin [init -> gdb_monitor] Error: no plugin found for fstat(3) ... [init -> gdb_monitor] Error: no plugin found for fstat(1023) [init -> gdb_monitor] Warning: unsupported ioctl (request=0x40047477) [init -> gdb_monitor] Warning: unsupported ioctl (request=0x80047476) [init -> gdb_monitor] Process target created; pid = 1 [init -> gdb_monitor] Remote debugging using /dev/terminal [init -> gdb_monitor] Error: fcntl(): command 6 not supported - vfs

2 1

Gdb in Nova - Error: no plugin found for fstat(3)
by Alexander Tormasov 29 Oct '19

29 Oct '19

1 0

Can't run runscript gdb_monitor_interactive
by Alexander Tormasov 25 Oct '19

25 Oct '19

hopting to have working gdb to debug apps inside gendode I try to compile gdb_monitor_interactive for nova kernel x64 I use 19.8 version, make -C build/x86_64/ VERBOSE= VERBOSE_MK= VERBOSE_DIR= MAKEFLAGS=--trace KERNEL=nova run/gdb_monitor_interactive I use symlinks to assemble genode dir (mounted inside build VM from host). In log I found genode build completed checking configuration syntax can't read "init_xsd_file": no such variable while executing "check_config init [run_dir]/genode/config $init_xsd_file init $xsd_files $xsd_inc 0" (procedure "build_boot_image" line 32) invoked from within "build_boot_image $boot_modules" (file "/genode.08/repos/ports/run/gdb_monitor_interactive.run" line 93) invoked from within "source $include_name" ("foreach" body line 6) invoked from within "foreach include_name [get_cmd_arg --include ""] { # first check if the include name is absolute if {[string first "/" $include_name] == 0} { puts ..." (file "genode/tool/run/run" line 1006) Makefile:323: recipe for target 'run/gdb_monitor_interactive' failed make: *** [run/gdb_monitor_interactive] Error 1 I check availability of file, it is accessible (at least less can open it from guest VM where I run script) ~/genode/build/x86_64/bin/init.xsd -> ~/genode/repos/os/src/init/config.xsd Probably this portion of run script fail: # determine which XSD file to use for the init config foreach xsd_file $xsd_files { set filename [file tail $xsd_file] if {$filename == "init.xsd"} { set init_xsd_file $xsd_file } } Any suggestions?

2 1

grpc server causes deadlock in libc
by Stefan Thöni 25 Oct '19

25 Oct '19

Hello Genodians We have ported google protocol buffers and the Google RPC (grpc) to genode and would like to contribute that to genode world. We encountered a problem with the port in which grpc server deadlocks when using the poll function of libc to poll sockets via the lwip or lxip plugin. We determined that poll calls Libc::suspend in task.cc which in term calls Pthreads::suspend_myself where the deadlock oocurs at myself.lock.lock();. Note that the grpc server uses several threads which apparantly are all waiting/suspended when the problem occurred. You can check out or working branch at https://github.com/trimpim/genode-world/commit/18da8122f805de0a137b778a6d83… and execute scenario using run/grpc runscript reproduce the problem. Does anyone has any idea why a deadlock might occur in that situation? Kind regards Stefan -- Freundliche Grüsse Stefan Thöni Chairman of the Board Senior Security Architect +41 79 610 64 95 gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

2 3

java applications and stdin
by Duss Pirmin 23 Oct '19

23 Oct '19

Hello Genodians I'm trying to use the stdin file descriptor in a java application to pass data through a terminal to the application. When the application tries to read from the file descriptor, I get the following error message: [init -> init -> java] Error: no plugin found for read(0) If is start a libc component instead of java, there is no error message and the component can read from stdio. In the <start> node of the java application I have the following <config> node: <config ld_verbose="no"> <arg value="/bin/java" />  <arg value="-Xint"/> <arg value="-jar"/> <arg value="app.jar"/> <libc stdin="/dev/terminal" stdout="/dev/terminal" stderr="/dev/log" rtc="/dev/rtc"/> <vfs rtc="/dev/rtc"> <dir name="dev"> <log/><null/><inline name="rtc">2000-01-01 00:00</inline> <terminal label="terminal"/> </dir> <dir name="bin"> <rom name="java"/> </dir> <dir name="lib"> <rom name="java.lib.so"/> <inline name="jvm.cfg">-server KNOWN -client IGNORE </inline> <dir name="server"> <rom name="jvm.lib.so"/> </dir> </dir> <dir name="modules"> <tar name="classes.tar"/> </dir> <tar name="app.tar"/> <rom name="zip.lib.so"/> <rom name="nio.lib.so"/> <rom name="net.lib.so"/> </vfs> </config> Can anybody help me getting this to work? Best regards, Pirmin

2 2

Depot autopilot vs base-linux with seccomp and per-session socket
by Stefan Thöni 10 Oct '19

10 Oct '19

Hello Genodians I ran into some trouble using seccomp and the base-linux per-session sockets with the depot autopilot. First the depot autopilot uses significantly more distinct syscalls and I dont quite understand why that is. The syscalls used above those used by the basic test-log are: clone, getpid, sigaltstack, rt_sigaction, gettimeofday, nanosleep Can anyone explain why these are nessecary? The other problem I couldn't solve up to now is that the depot autopilot seems to use many more sessions than the scenario itself. Even for the basic test-log scenario at least 512 sessions are used by a single process as it fails due to running out of socket descriptors when a socketpair per session is used. Can anyone explain this behavior? Might there be stale sessions (leak) in the depot autopilot? Best regards Stefan -- Freundliche Grüsse Stefan Thöni Chairman of the Board Senior Security Architect +41 79 610 64 95 gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users