users

users@lists.genode.org

2285 discussions

TLS in Genode+Fiasco.OC
by Amadeo Cuadrado 08 Mar '11

08 Mar '11

Hello, Quick question: I am using Genode+Fiasco.OC, and I am trying to access the TLS of a particular thread. How can that be done? Where could I find an example on this? Thanks! Amadeo

2 2

Libports building problem with Genode 11.02 + Fiasco.OC
by Daniel Waddington - SISA 02 Mar '11

02 Mar '11

Hello, We're struggling to build Genode 11.02 + Fiasco.OC on x86. We are building using the genode GCC x86-ia32 binaries (gcc 4.4.5) running on a x86_64 Ubuntu box. When we add "libports" to the REPOSITORY we get: COMPILE readlink.o COMPILE rlimit.o COMPILE select.o COMPILE strcoll.o COMPILE strxfrm.o COMPILE sysctl.o COMPILE wcscoll.o COMPILE wcsxfrm.o MERGE libc.lib.so genode-x86-ld: /home/dwaddington/git/omnios/build/genode/var/libcache/cap_alloc/cap_all oc.lib.a(cap_sel_alloc.o): relocation R_386_GOTOFF against undefined symbol `__l4sys_invoke_indirect' can not be used when making a shared object genode-x86-ld: final link failed: Bad value make[2]: *** [libc.lib.so] Error 1 make[1]: *** [libc.lib] Error 2 make: *** [gen_deps_and_build_targets] Error 2 I have no idea how to fix this. Any clues? Thanks Daniel

3 2

SMP ia32 support with Pistachio
by Daniel Waddington - SISA 01 Mar '11

01 Mar '11

Hi, Has anyone managed to get Pistachio+Genode with SMP+ia32 running? We have managed to get Pistachio+Genode+ia32 without SMP working fine. As soon as we compile SMP it goes into an endless loop. Any ideas? Thanks Daniel Waddington

5 5

Announcement: Genode OS Framework version 11.02 released
by Norman Feske 24 Feb '11

24 Feb '11

We are happy to announce the release of the version 11.02 of the Genode OS Framework. The development is this version was primarily focused on further expanding the platform support of the framework. We are excited about the following three significant improvements in this area. First, we introduced support for the Fiasco.OC kernel, which is a modern capability-based microkernel developed at the Dresden University of Technology and published under GPLv2. Fiasco.OC provides a rich set of features, most notably kernel support for user-level object capabilities (hence the suffix "OC"), multi-processor support, and comprehensive support for the x86_32, x86_64, and ARM architectures. For more information on Fiasco.OC visit http://os.inf.tu-dresden.de/fiasco Second, we upgraded the support for the NOVA hypervisor to version 0.3, and thereby, promoted the NOVA version of Genode to cover the entire Genode API. So, NOVA can now be recommended as base platform for Genode without reservations. The project website of NOVA is: http://hypervisor.org Third, the Genode project reaches out to kernel land by adding a custom kernel platform for running Genode on the Xilinx MicroBlaze CPU architecture. Our design has a special twist that sets it apart from existing microkernels, namely that it is not a free-standing program but a part of Genode's core. By consolidating the kernel with the user-level core into one program, the TCB complexity of the Genode base systems gets quite dramatically reduced compared to the combination of a normal microkernel with core running as roottask. The most prominent functional addition introduced with the new release, is the Noux execution environment, which facilitates the use of GNU userland software on top of Genode without requiring much manual porting labour. Albeit being in an early stage, Noux is already able to run many commands of the GNU coreutils. In short, the release notes summary is: - Fiasco.OC as new base platform - Running Genode natively on MicroBlaze CPUs - Support for version 0.3 of the NOVA hypervisor - Noux execution environment for GNU userland software - Base framework - Core resource accounting using guarded allocators - Protocol enhancements for upgrading session quotas - Qt4 updated to version 4.7.1 - New tool for automated integration and testing Please find a more elaborative description of the changes accompanied with a lot of background information in the release notes of version 11.02: http://genode.org/documentation/release-notes/11.02 The new version is ready for download at our download page at Sourceforge and our public SVN repository: http://genode.org/download Best Regards -- Dr.-Ing. Norman Feske Genode Labs 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

1 0

Error On make hello/server
by prabhath bhathiya 14 Jan '11

14 Jan '11

Hi i'm new to Genode. I followed all the steps before this but i'm having a small making problem of hello_tutorial appication My error is bhathiya99@...55...:~/FinalYearProject/New_Test/genode-10.11/build$ make hello/server checking library dependencies for hello/server... Library slab Library avl_tree Library allocator_avl Library cxx Library ipc Library heap Library console Library log_console Library lock Library env Library thread Library server Library syscall Library startup Program hello/server/hello_server LINK hello_server /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/build/var/libcache/thread/thread.lib.a(thread_start.o): In function `Genode::Thread_base::_init_platform_thread()': /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/base/src/base/thread/thread_start.cc:38: multiple definition of `Genode::Thread_base::_init_platform_thread()' /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/build/var/libcache/thread/thread.lib.a(thread_linux.o):/home/bhathiya99/FinalYearProject/New_Test/genode-10.11/base-linux/src/base/thread/thread_linux.cc:48: first defined here /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/build/var/libcache/thread/thread.lib.a(thread_start.o): In function `Genode::Thread_base::cancel_blocking()': /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/base/src/base/thread/thread_start.cc:68: multiple definition of `Genode::Thread_base::cancel_blocking()' /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/build/var/libcache/thread/thread.lib.a(thread_linux.o):/home/bhathiya99/FinalYearProject/New_Test/genode-10.11/base-linux/src/base/thread/thread_linux.cc:112: first defined here /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/build/var/libcache/thread/thread.lib.a(thread_start.o): In function `Genode::Thread_base::_deinit_platform_thread()': /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/base/src/base/thread/thread_start.cc:41: multiple definition of `Genode::Thread_base::_deinit_platform_thread()' /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/build/var/libcache/thread/thread.lib.a(thread_linux.o):/home/bhathiya99/FinalYearProject/New_Test/genode-10.11/base-linux/src/base/thread/thread_linux.cc:51: first defined here /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/build/var/libcache/thread/thread.lib.a(thread_start.o): In function `Genode::Thread_base::start()': /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/base/src/base/thread/thread_start.cc:47: multiple definition of `Genode::Thread_base::start()' /home/bhathiya99/FinalYearProject/New_Test/genode-10.11/build/var/libcache/thread/thread.lib.a(thread_linux.o):/home/bhathiya99/FinalYearProject/New_Test/genode-10.11/base-linux/src/base/thread/thread_linux.cc:82: first defined here collect2: ld returned 1 exit status make[2]: *** [hello_server] Error 1 make[1]: *** [hello_server.prg] Error 2 make: *** [gen_deps_and_build_targets] Error 2 Please help me to overcome this problem thanks. Bhathiya.

2 1

x64 Compatible Tool Chain
by Sam Kerr 13 Jan '11

13 Jan '11

I am trying to work with Genode on Ubuntu 10.10 x64 edition and get the tool-chain set up. However, the tool-chain download is for x86 and I can't see any way to build it for x64. Is it possible to develop Genode on 64 bit Ubuntu, or do I simply need to use 32 bit instead? Thanks!

2 1

Announcement: Genode OS Framework version 10.11 released
by Christian Helmuth 30 Nov '10

30 Nov '10

We are pleased to announce the release 10.11 of the Genode OS Framework. This release focuses on new features presented on the Genode Live CD two weeks ago http://genode.org/download/live-cds and includes many improvements behind the scenes. Release-notes summary for version 10.11 --------------------------------------- * Base framework * Support for user-level dataspace managers * Operating-system services and libraries * Final transition to new init concept * Virtual network bridge (Proxy ARP) * Alpha blending and tinted views in Nitpicker GUI server * ISO9660 file-system server * Device drivers * Execution environment for gPXE drivers * Enhancements of audio-processing infrastructure * Revised GEM/DRM support * Improved integration of paravirtualized Linux with Genode components * Qt4 nitpicker-plugin widget * HTTP-based block device in new gems repository * Platform-specific refinements on OKL4, Pistachio, and Linux You can find the complete release notes for the version 10.11 here: http://genode.org/documentation/release-notes/10.11/ The new release is available to the project's subversion repository and at the Genode download page: http://genode.org/download/latest-release Regards -- Christian Helmuth Genode Labs 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

1 0

Genode Live CD 10.11 released
by Stefan Kalkowski 16 Nov '10

16 Nov '10

The Genode project proudly presents a bootable live CD representing the current state of the Genode OS Framework. Features like running Linux as browser plugin, 3D hardware acceleration, sound support, and a complete networking infrastructure are incorporated to form a single coherent setup. The live CD boots in less than 10 seconds (on VirtualBox) into a a fully functional GUI with a selection of five demo subsystems. Each subsystem highlights a different aspect of the framework. A paravirtualized Linux, seamlessly integrated into Genode's native Nitpicker GUI, can be found right next to native Qt4/Webkit applications. The port of the Arora web browser stands out for featuring a plugin that can execute arbitrary Genode subsystems in a secure way. This tech demo features multiple browser-embedded application including a complete Linux system, streaming a disk image live over HTTP from a web server. Another subsystem runs the famous gears OpenGL demo via the native port of Gallium3D/Mesa, offering hardware support on Intel GMA GPUs. Furthermore the CD executes a range of new drivers and features not present in the last releases. As kernel OKL4 v2 was chosen. Check out the ISO image at: http://genode.org/download/live-cds -- Stefan Kalkowski Genode Labs 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

1 0

Genode: Thread Stack Allocation
by Frank Kaiser 26 Oct '10

26 Oct '10

Hello In a recent project (using Genode on top of OKL4 v2.1 on an ARM platform) I ran into the problem that in one protection domain (PD) occasionally the exception Stack_alloc_failed was thrown. Tracing this back it came out that this was a Region_conflict exception thrown by the RM session client code due to the return value given by core's RM session server. In that particular PD the main() function and the first started thread both created subthreads independently of each other. The exception occurred because an ATTACH command for the same thread stack address area was sent to core twice. The thread stack allocation is done by the constructor Thread_base::Thread_base() with its 2nd initializer element _context(_alloc_context(stack_size)). The method Thread_base::_alloc_context() handles the address assignment of a thread stack locally within a PD, which is done by the call _context_allocator()->alloc(this). Beginning from virtual address 0x4000.0000 for each new stack a segment of 1 MB is reserved at which end the stack area with the requested size is allocated. To find out whether a stack area is already in use, the so-called Context_allocator provides the method Thread_base::Context_allocator::_is_in_use(). The thread's context is maintained in structure Thread_base::Context, which is written at the top of each allocated stack. The class Thread_base owns the member _context to point to this data. The Context_allocator itself is a static object instantiated on the first call to function _context_allocator(). It provides a chained list (member _threads) of all created threads. The method _is_in_use() walks through the thread list and determines whether any of the existing threads points to the context address of the stack area in question (thread member _context equal to the context address at the top of stack area under consideration) and returns true, if this is the case. The method Thread_base::Context_allocator::alloc() iterates through the stack segments until it finds an unused stack area. It inserts the new thread into the chained list (call _threads.insert(&thread_base->_list_element);) and returns the stack's Context address to the caller Thread_base::_alloc_context(). The problem is that at this point a decision about a new stack allocation is made which is not yet visible in the chained list of threads, because the new thread is already in the list, but its member _context is not yet set. This happens on the return of Thread_base::_alloc_context() to the constructor, but before that an IPC is made to core to register the new stack allocation. On OKL4 each IPC invokes the scheduler, and what happens in the failure case, is that another process is scheduled which starts instantiating a further new thread. In this situation the method Thread_base::Context_allocator::_is_in_use() does not find the stack area of the previously created stack as occupied, and the caller tries to allocate the stack area another time. However, core detects the double allocation and returns a bad result code on the 2nd ATTACH command. To fix the problem a lock is required to cover the whole sequence from beginning the search for a free stack area up to the assignment of Thread_base::_context. The existing lock Thread_base::Context_allocator::_threads_lock, used in Thread_base::Context_allocator::alloc(), is not sufficient for this purpose. For a quick fix I inserted the following two lines at the beginning of Thread_base::_alloc_context(): static Lock alloc_lock; Lock::Guard _lock_guard(alloc_lock); However, this solution is not perfect, since the lock is released before the assignment to Thread_base::_context, which leaves a gap of a few machine instructions, where a preemptive scheduling still could trigger the exception. Practically it worked for my case. During analyzing this problem I began wondering about the overall design of the thread stack allocation. Obtaining the stack area is done by the call env_context_area_rm_session()->attach_at(ds_cap, attach_addr, ds_size) within the method Thread_base::_alloc_context(). The parameter attach_addr is not the complete stack address base (for instance 0x400f.c000), but the offset to the PD's stack area base address (for instance 0xf.c000). On the other hand the function env_context_area_rm_session() instantiates a PD_wide RM session which attaches the whole address area of 256 MB at 0x4000.0000 for the PD. Doesn't that instruct the pager to provide memory on a page fault of any address between 0x4000.0000 and 0x4fff.ffff, this way making the system unable to detect any stack over- and underflow? Additionally memory mappings are created for the stack offset addresses which are not really used. Maybe I missed something. If so, please let me know. Regards Frank

2 1

Many Start/Stops in Launchpad cause crash with little core memory
by Matthias Gerlach 24 Sep '10

24 Sep '10

Dear All, after playing around with the demo scenario and launchpad a bit, Genode exited with an error message: "virtual bool Genode::Sliced_heap::alloc(Genode::size_t, void**): Could not allocate dataspace with size 4096". More details on the setup below. The more memory is "left for core" (see comment before the lines in main.cc), the later this error message occurs. Is there any other possibility to avoid this behavior than increasing memory "left for core"? Or am I doing something wrong? Thanks, Matthias The setup was as follows: - Checked out Genode tags/10.05 - Set up demo scenario for Linux (used the provided config and build.config files) - Changed base/src/core/main.cc as follows (svn diff: ) Index: base/src/core/main.cc =================================================================== --- base/src/core/main.cc (revision 131) +++ base/src/core/main.cc (working copy) @@ -214,7 +214,8 @@ Ram_session_client(init_ram_session_cap).ref_account(env()->ram_session_cap()); /* transfer all left memory to init, but leave 1 MB left for core */ - size_t init_quota = platform()->ram_alloc()->avail() - 2*1024*1024; + /* Test with less mem for core */ + size_t init_quota = platform()->ram_alloc()->avail() - 100*1024; env()->ram_session()->transfer_quota(init_ram_session_cap, init_quota); PDBG("transferred %zd MB to init", init_quota / (1024*1024)); (i.e., reduced the available quota to core (drastically)) - started ./bin/core with the provided example config - started launchpad application - started and stopped liquid_fb several times, after about 7 times, the following error occurs and Genode crashes: [init -> scout -> launchpad] starting liquid_fb with quota 7340032 [init -> scout -> launchpad] using unique child name "liquid_fb" virtual Genode::Ram_dataspace_capability Genode::Ram_session_component::alloc(Genode::size_t): quota exceeded! virtual Genode::Ram_dataspace_capability Genode::Ram_session_component::alloc(Genode::size_t): memory for slab: 9216 virtual Genode::Ram_dataspace_capability Genode::Ram_session_component::alloc(Genode::size_t): used quota: 296080 virtual Genode::Ram_dataspace_capability Genode::Ram_session_component::alloc(Genode::size_t): ds_size: 4096 virtual Genode::Ram_dataspace_capability Genode::Ram_session_component::alloc(Genode::size_t): sizeof(Ram_session_component): 144 virtual Genode::Ram_dataspace_capability Genode::Ram_session_component::alloc(Genode::size_t): quota_limit: 300032 virtual bool Genode::Sliced_heap::alloc(Genode::size_t, void**): Could not allocate dataspace with size 4096 -- Matthias Gerlach OpenSynergy GmbH Rotherstr. 9, 10245 Berlin Telefon: +49 (30) 20 1818 35-45 Fax: +49 (30) 20 1818 35-02 EMail: Matthias.Gerlach@...24... www.opensynergy.com Handelsregister: Amtsgericht Charlottenburg, HRB 108616B Geschäftsführer: Frank-Peter Böhm, Rolf Morich, Stefaan Sonck Thiebaut

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users