users October 2020

users@lists.genode.org

16 participants
14 discussions

Start a nNew thread

Network issue
by Dima Sokolov 01 Feb '21

01 Feb '21

3 3

mmap implementation for ANON mapping with desired address
by Alexander Tormasov 21 Dec '20

21 Dec '20

I am trying to implement not-yet supported (as mentioned by nfeske@ in mailing list) option for mmap() related to anonymous mapping with pre-defined (desired) address. Like libc function with desired address out_addr. void *Libc::Mem_alloc_impl::alloc_at(void *out_addr, size_t size) I use a couple of useful function in avl allocator. Anyway, I found that straight - forward implementation do not work because of allocation gaps filled together with main allocation. In particular, if we want to allocate e.g. 0x10000 from address 0x500000 then we typically allocate 0x13000 bytes, including ones for avl metadata/etc stored in the same space, and receive virtual address range used, e.g. 0x500000 - 0x513000: /* * Calculate block size of needed backing store. The block must hold the * requested 'size' with the requested alignment, a new Dataspace structure * and space for AVL-node slab blocks if the allocation above failed. * Finally, we align the size to a 4K page. */ size_t request_size = size + max((1 << align_log2), 1024) + Allocator_avl::slab_block_size() + sizeof(Dataspace); Software I used (golang runtime) sometimes try to expand previous allocation, e.g. it can request allocation of 0x8000 bytes before previous range, like 0x4f8000 - 0x500000. In that case I can’t perform the operation - because it will try to allocate 0xa000 bytes from desired address 0x4f8000 - and it obviously fail due to Range_conflict. So, I split allocation to 2 parts - one for this gap by standard alloc() and random placement and second one by my own alloc_at() with size exactly correspond to the requested one. Implementation available as a patch to 20.05 at https://github.com/tor-m6/genode/commit/78fc751bea8acc2b515e04bec9f3a883461… Problem I see here is a free operation: it just free the block with requested address, and do not touch others, gap-related blocks. For me it is not obvious that they need to be free, because in the code (e.g. by unmap()) I do not see explicit free of other allocated structures, in particular, dataspace extension or related block metadata. Question: should I make additional efforts to trace and delete something else - except what standard free does here: /* forward request to our local allocator */ _alloc.free(addr); Like for dataspace structure or address ranges for second «auxiliary» allocation? PS Another potential problem is a probability to overlap of first «random address» allocation with desired address. This happens with first attempt to implement allocator - it allocates address from desired range, and immediately put here 0x18 bytes of Dataspace structure, and then fail because requested address is already busy by this structure! Anyway, I consider such a probability relatively small with proposed approach and ignore it (may be I am wrong)

4 23

SYS_ioperm aarch64
by Michael Grunditz 03 Nov '20

03 Nov '20

Hi! I am trying to bringup Genode/Linux on aarch64. I have ported the syscall*.S files. But many of the SYS_ defines areen't defined, SYS_ioperm for example. I checked with x86_64 and it built. In both x86_64 and aarch64 it isn't defined in toolchain or Genode. In system includes both platforms has a #Ifdef __NR_ etc. But neither of the systems define that. I am all confused! Michael

2 4

Sculpt Falkon browser package update
by Christian Prochaska 30 Oct '20

30 Oct '20

Hello, an updated Falkon browser package is available now in the 'cproc' depot for Sculpt 20.08 and 20.09 (staging), which fixes some memory leaks and reduces the maximum number of open sockets to lower the chance of file descriptor exhaustion. Christian

1 1

RPCEmu on Genode
by Michael Grunditz 21 Oct '20

21 Oct '20

Hi I am working on getting the RPCEmu (RiscPC emulator) to run on Genode. I have a some problems , and will list some of them, 1) Graphics doesn't update without exposing it. I have used testnit as a base and uses blit function to push out pixels to screen. How can I make it redraw? 2) When trying ro use the JIT version Genode complains about non executable memory. Any idea what that might be? I use base hw on x86_64. Screenshot: https://twitter.com/QtARM/status/1316535724959727620 (real hw) Best regards Michael Grunditz

3 12

running virtualbox5 on genode
by fixed-term.peter.jacobi＠sojus-software.de 20 Oct '20

20 Oct '20

Greetings. My name is Peter new to Genode and just trying to run the vbox5_win10_64.run script, btw. any of the scripts in genode/repos/ports/run/ are giving me the same result. It seems that the building works fine but I get no kind of output. A help and some indication on my wrong'ings would be much apreciated. My execution command: make run/vbox5_win10_64 KERNEL=nova BOARD=x86_64 My "build.conf" file and the building output called "out" are attached. My work operating system is Linux Ubuntu 20.04. My goal, create an mikrokernel with genode-framework starting 2 linux Virtualbox applications creating a simple communication between them. Best regards, Peter

2 1

Suggestions for contributing
by Mihail Feraru 16 Oct '20

16 Oct '20

Hello everyone, I've recently asked my Operating Systems professor about an interesting project to contribute to, and he recommended Genode. After a glimpse of the docs and playing a little bit with the tutorial repo, it really got my interest. It would be great if any of you would like to guide me a little bit about how I could be useful to the project. Maybe there are good issues for a new contributor or any feature testing to be done, anything that you consider relevant. About me, I have a little bit of experience with kernel development as I've worked on a hobby kernel project. Regards, Mihail PS. I've seen this strange output message after running hello_tutorial: "17592186044415 MiB RAM and 8997 caps assigned to init" and it feels pretty wrong, maybe it's a bug.

3 3

C++ exceptions handing deadlock with gcc unwind code in dynamic library
by Alexander Tormasov 13 Oct '20

13 Oct '20

What I found is a deadlock of recursive Linker::mutex call. - If we have an exception in some code (e.g. code which call NOVA syscall, in my case this is attach_at() RPC call) then it somehow processed in caller. In particular, during processing it call the following stack from injected by gcc function _Unwind_Resume - pay attention to function dl_iterate_phdr(): #0 Linker::mutex () at /home/tor/gen/20.08/repos/base/src/lib/ldso/main.cc:68 #1 0x0000000000124997 in dl_iterate_phdr (callback=0x119e7a0 <_Unwind_IteratePhdrCallback>, data=0x403fdde0) at /home/tor/gen/20.08/repos/base/src/lib/ldso/exception.cc:41 #2 0x000000000119fa0f in _Unwind_Find_FDE (pc=0x119dc76 <_Unwind_Resume+54>, bases=bases@entry=0x403fe128) at /home/tor/gen/20.08/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind-dw2-fde-dip.c:469 #3 0x000000000119bfc3 in uw_frame_state_for (context=context@entry=0x403fe080, fs=fs@entry=0x403fdec0) at /home/tor/gen/20.08/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind-dw2.c:1257 #4 0x000000000119cfe0 in uw_init_context_1 (context=context@entry=0x403fe080, outer_cfa=outer_cfa@entry=0x403fe2b0, outer_ra=0x1000bcd <Genode::Region_map::attach_at(Genode::Capability<Genode::Dataspace>, unsigned long, unsigned long, long)+259>) at /home/tor/gen/20.08/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind-dw2.c:1586 #5 0x000000000119dc77 in _Unwind_Resume (exc=0x1b41a8 <Genode::init_cxx_heap(Genode::Env&)::initial_block+5256>) at /home/tor/gen/20.08/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind.inc:235 #6 0x0000000001000bcd in Genode::Region_map::attach_at (this=0x1304068 <vm_reg0+8648>, ds=..., local_addr=0x80000000, size=0x40000, offset=0x0) at /home/tor/gen/20.08/repos/base/include/region_map/region_map.h:127 The code of dl_iterate_phdr(): extern "C" int dl_iterate_phdr(int (*callback) (Phdr_info *info, size_t size, void *data), void *data) { int err = 0; Phdr_info info; Mutex::Guard guard(mutex()); for (Object *e = obj_list_head();e; e = e->next_obj()) { info.addr = e->reloc_base(); info.name = e->name(); info.phdr = e->file()->phdr.phdr; info.phnum = e->file()->phdr.count; if (verbose_exception) log(e->name(), " reloc ", Hex(e->reloc_base())); if ((err = callback(&info, sizeof(Phdr_info), data))) break; } return err; } Py attention that it take Linker::_mutex object (lock). Inside, it call the callback() function for main C++ code which resolved to _Unwind_IteratePhdrCallback from contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind-dw2-fde-dip.c which internally call get_fde_encoding() and get_cie_encoding() which contain very simple line /home/tor/gen/20.08/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind-dw2-fde.c:300 p = aug + strlen ((const char *)aug) + 1; /* Skip the augmentation string. */ strlen() is not inlined/instantiated here. In machine code it call strlen@plt which mean that strlen assumed in the shared library, and typically it should be processed by linker relocation code. To find the code it call jmp_slot@PLT and, in turn, call from src/lib/ldso/main.cc:294 function Elf::Addr Ld::jmp_slot(Dependency const &dep, Elf::Size index) { Mutex::Guard guard(mutex()); if (verbose_relocation) … Pay attention that it call the same Linker::_mutex object (lock) Voila! we have recursive call of the same linker mutex and deadlock in exception processing. definitely key problem here is in the usage of linker mutex in Genode implementation of dl_iterate_phdr() So, question: how to fix this? May be we need different mutexes for Ld::jmp_slot and for dl_iterate_phdr? Sincerely, Alexander

2 1

driver_manager RAM quota for boot_fb_drv
by Colin Parker 13 Oct '20

13 Oct '20

Hello, I just upgraded to the 20.08 version of Sculpt. There seems to be a problem with the boot_fb_drv component, from what I can guess the changes to this component because of the graphics refactor make it need more RAM, but the driver_manager computes the ram as "_pitch * _height + 512*1024". Changing this to "2 * _pitch * _height + 512*1024" (i.e. doubling the framebuffer part) fixed it for me. Is there a smarter way to understand how much RAM is actually needed here, rather than using blunt tools like "double until it works"? Does this problem only affect me for some reason? This is in qemu which gives a very large screen, but it used to work in the old version (20.02 I think). Regards, Colin

3 2

iMX8 not all cores starting
by Duss Pirmin 07 Oct '20

07 Oct '20

Hi Genodians As mentioned in an earlier mail I'm currently enabling base-hw on the IoT gateway of CompuLab [1]. The used SoC is a iMX8mm, which is a bit different from the iMX8mq used on the EVK [2]. On a running Linux I used `memtool` to read register values. In `src/bootstrap/spec/iot_gateway/platform.cc` I have changed the following things: - the values for the `regulator` registers - the register offsets and values for the ARM_PLL registers - the values of the IOMUX configuration Now the code bootstrap finishes and the kernel begins to run. By adding some `Genode::raw()`s to `void kernel_init()` I'm able to see, that the initialization for kernel waits for all CPUs to start at `while (!pool_ready) { ; }`. If change `NR_OF_CPUS` to 1, I'm able to run the log run script. log output of IoT gateway [1]: ``` Kernel: Board() :: 324 Kernel: Board() :: 342 Kernel: wake_up_all_cpus() :: 352 --- 1 Kernel: wake_up_all_cpus() :: 352 --- 2 Kernel: wake_up_all_cpus() :: 352 --- 3 Kernel: kernel_init() :: 56 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 0 Kernel: initialize() :: 188 --- 0 initialized=4 ``` log output from EVK [2]: ``` Kernel: kernel_init() :: 56 Kernel: initialize() :: 186 --- 0 Kernel: initialize() :: 188 --- 0 initialized=4 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 3 Kernel: initialize() :: 188 --- 3 initialized=3 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 2 Kernel: initialize() :: 188 --- 2 initialized=2 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 1 Kernel: initialize() :: 188 --- 1 initialized=1 kernel initialized ``` Has anybody an idea what registers could have an influence on the start up of the CPUs? [1] https://www.compulab.com/products/iot-gateways/iot-gate-imx8-industrial-arm… [2] https://www.nxp.com/design/development-boards/i-mx-evaluation-and-developme… Best regards, Pirmin

4 12

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users October 2020