users

users@lists.genode.org

1 participants
2322 discussions

fs_rom closing and re-opening watches
by Pirmin Duss 04 Nov '20

04 Nov '20

Hello Genodians While debugging an error int the watch implementation of lx_fs, I observed, that fs_rom often closes and re-opens the watch handles. Whenever the file is read, the watch is closed and then re-opened. This also happens, when the read was triggered by a watch notification from the file system. Is there a special reason for that? Or is this an oversight? In https://github.com/genodelabs/genode/issues/3897 Norman already stated, that fs_rom will probably undergo a rework to clean up some design issues he has spotted. If this is an oversight, I think it would be best to fix this when the rework is done. Best regards, Pirmin

2 2

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

Hello from aarch64/linux
by Michael Grunditz 03 Nov '20

03 Nov '20

[init -> hello] Hello world Problems was two.. I accidental put Genode:log instead of Genode:raw in syscall headers. Seccomp call does crash. Still doesn't start from make run. Michael

2 3

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users