users

users@lists.genode.org

2357 discussions

Cluttered trace messages on Genode/OKL4v2
by Frank Kaiser 31 Aug '10

31 Aug '10

Hello In my environment running Genode on top of OKL4 V2.1 I occasionally observed cluttered debug output on the serial console, sometimes accompanied by a roottask page fault. A close inspection of the system showed that this happens when core writes debug output messages on its own while in parallel debug messages are sent by other protection domains. In core debug messages processed by Genode::printf() and Genode::vprintf() are processed by Okl4_console::vprintf() which infact is the call of the base class methode Console::vprintf(). The implementation in the files okl4_console.cc and console.cc shows that there is no lock to serialize trace output from different sources. The outcome is that core's trace server and any other core thread can concurrently write to OKL4's character-oriented debug interface leading to the mix-up of two debug messages. I could solve the problem by simply copying the solution from the class Log_console used by the other protection domains: * Adding a Lock object to the class Okl4_console private: Lock _lock; * Substituting the call of the base class method Console::vprintf() by providing a dedicated method Okl4_console::vprintf() public: inline void vprintf(const char *format, va_list list) { Lock::Guard lock_guard(_lock); Console::vprintf(format, list); } These two changes fix the problem w/o affecting any caller code using Okl4_console::vprintf(). It leaves the base class methode Console::vprintf() unmodified so that its usage in different derived classes is not compromised. I'd appreciate if this or an equivalent fix could find its way into one of the next Genode baselines on Sourceforge. Regards Frank

2 1

Fiasco.OC + Genode
by Pablo Montesinos 30 Aug '10

30 Aug '10

Hi, I've been using Fiasco.OC released on June. I've noticed that the 3rd_fiasco.tar.bz package is from february. I was wondering if you knew whether anyone had tried using the Fiasco.OC with the current Genode distribution. Thanks, Pablo

2 4

Handling division-by-zero
by mx＠...19... 27 Aug '10

27 Aug '10

Hi all, I'm working with Genode 10.05 on top of the OKL4 Microkernel. Recently, my application raised a division-by-zero. Shame on me - but I was very astonished when I found out that the root task (core) handles this error rather by chance than explicitly, for there's no real handler registered. The error ipc the kernel sends to core, arrives in the sleep_forever function within core's main thread which sleeps in an ipc call expected never to return. On the division-by-zero, this ipc returns indeed, causing the ipc_client to indicate that its receive buffer be too small for the incoming message (containing the kernel-saved thread context). Upon that, core's main thread acknowledges the ipc to the kernel and performs the sleep_forever action again. The offending application thread is aborted by the kernel. One might call that a proper handling, in fact, it's correct, but it would have been very nice to have a real handler inside of core giving a simple hint on the error. The current implementation makes it very hard to debug such errors (In fact, I had to debug into core to see where the 'copy_utcb_to_msgbuf' failed, then into the kernel itself to see what was actually signalled to core and then finally into my application's threads upon the very faint idea what to look for). Furthermore, if the message buffer inside of core would have been big enough to take the kernel's ipc, even the initial 'hint' where to start debugging would have been missing ;) Could you please make core at least a little more verbose at this point? By the way I found out that the handler for an invalid-opcode is missing as well, but I don't know if there's a chance to catch those errors inside the root task, for they cause the kernel itself to enter the kernel debugger and hence halting the system (so rather an OKL4 issue). Regards Sven -- Sven Fülster

2 2

Announcement: Genode OS Framework version 10.08 released
by Stefan Kalkowski 11 Aug '10

11 Aug '10

We are happy to announce release 10.08 of the Genode OS Framework. This new version brings support for hardware accelarated graphics and wireless networking. The release introduces the Gallium3D software stack alongside the Intel graphics execution manager, which can be used by Genode applications to perform hardware-accelerated 3D graphics on Intel GMA platforms. The integration of the MadWifi project into our Linux device-driver environment enables the use of a broad range of wireless network cards. The newly introduced block-session interface is showcased by the new ATAPI driver, a service providing ROM files as loop-device, and by a block-device driver for Genode's paravirtualized OKLinux version. Release-notes summary for version 10.08 --------------------------------------- * Hardware-accelerated 3D graphics via Gallium3D and Intel GEM * Wireless networking using MadWifi * Block device interface, ROM loop service * ATAPI driver, ISO 9660 file system * Update of Qt4 to version 4.6.3 * Dynamic linker for ARM EABI You can find the complete release notes for the version 10.08 here: http://genode.org/documentation/release-notes/10.08/ The new release is available to the project's subversion repository and at the Genode download page: http://genode.org/download/latest-release Regards -- 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

Second anniversary of the Genode OS Framework
by Norman Feske 10 Aug '10

10 Aug '10

Hi there, the upcoming version 10.08 of the Genode OS Framework will be the 8th release since the initial publication two years ago in August 2008. We invite you to celebrate its second anniversary together with us. As last year, we will gather for a barbecue and a campfire at the river Elbe in Dresden on 12th of August, 6 pm near Moritzburger Str. 1 in Dresden Check out the map for finding the location: http://maps.google.de/maps/ms?ie=UTF8&msa=0&msid=103318122554571178078.0004… We'd be happy about you joining us. We will provide beverages and barbecue both vegetarian and non-vegetarian. If you plan to attend, please send a short note to info@...1... Cheers Norman -- 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 1

LWIP
by Peter Nguyen 22 Jul '10

22 Jul '10

Hi, I've noticed that when connecting to the test web server via TAP, connections seem to be a bit slow. I've added some test code to "download" some data on the web server, and at most, i'm only getting around 1.5K/s (using wget). Is there something i can do to improve the connection speed, or am I basically stuck with this? Peter

3 2

pthread_create
by stephane frenot 13 Jul '10

13 Jul '10

Hello the list, I am newbie to the genode framework. I am using the x86_64 port for linux with libc repository. I am trying to integrate legacy application that use calls such as pthread_create. The call does not exist, and I wonder which solution is the best. Do I need to wrap all thread creation through genode thread service call ? /stephane -- http://perso.citi.insa-lyon.fr/sfrenot work here : http://tinyurl.com/2ts4xf sleep here : http://tinyurl.com/33p2gt play here : http://tinyurl.com/3yarjz --- Stephane Frenot Université de Lyon, INRIA INSA-Lyon, CITI, F-69621, France

2 1

About Genode::Signal reception
by Frank Kaiser 06 Jul '10

06 Jul '10

Hello I want to use the Genode signalling scheme to control asynchrones data exchange between a client and a server. To get familiar with it I started with a test implementation on the server side. The server's main function fills some data into a buffer and instantiates a Signal receiver thread which shall dump the buffer content on signal reception. Then it instantiates a Signal transmitter to fire a signal at the receiver for one time. The unexpected outcome is that it looks as if the receiver gets the signal twice. This is the implementation in main(): Signal_receiver s_rcvr; Signal_context ct; Receiver *ser_rx = new (env()->heap()) Receiver(s_rcvr, srv.transmit); Signal_context_capability send_cap = s_rcvr.manage(&ct); Signal_transmitter tx(send_cap); tx.submit(); The receiver thread's entry() function (class Receiver derived from class Thread<>; the constructor's 2nd parameter is a handle to the buffer already filled with data, which is accessed thru _transmit inside the function): void entry() { uint8_t ch[32]; int cnt = 0; while (1) { Signal signal = _receiver.wait_for_signal(); #if 1 for (unsigned out = 0; out < sizeof(ch); ++out) { int rd = _transmit.read_byte(); if (rd >= 0) ch[out] = uint8_t(rd); else break; } ++cnt; ch[31] = '\0'; printf("Found characters: %s\n", &ch[0]); ch[0] = '\0'; printf("Caught signals: %d\n", cnt); #endif } } The debug output shows that the 2 printf()s inside the while() loop are called 2 times, which clearly indicates that _receiver.wait_for_signal() returned 2 times. I wonder what goes wrong, and what I should do to get rid of this odd behaviour. Regards Frank

2 3

Constructing objects from dataspaces
by Frank Kaiser 05 Jul '10

05 Jul '10

Hello I recently stumbled over a missing placement new operator in the Genode framework. I needed an object to be shared between a client and a server. The server should construct the object. The client should connect to the server, and in response receive a capability allowing the client to access the data held by the object. The class defining the object provides a constructor to do some necessary initialisation of the object. It looks like this: class Object { ... Object(...) : ... { ... } }; The chosen approach is to create a dataspace capability with the size of the object. On the server side the object is instantiated: Dataspace_capability cap = env()->ram_session()->alloc(sizeof(Object)); Object *obj = static_cast<Object *>(env()->rm_session()->attach(cap)); However, this does not work as expected, since this way Object's constructor is never called. To achieve this applying the new operator is required: Dataspace_capability cap = env()->ram_session()->alloc(sizeof(Object)); Object *obj = new(env()->rm_session()->attach(cap)) Object(); However, this does not work either, because it leads to a type error with the placement parameter. The reason is that the only publicly available placement new operator is: void *operator new(Genode::size_t size, Genode::Allocator *allocator) And worse, its implementation tries to effectively allocate the object's space, something which is not wanted in the given context. What is needed here is a new operator which just returns the placement parameter as the address of the object so that its constructor is invoked when applying the operator. Something like this: void *operator new(Genode::size_t size, void *addr) { return addr; } I found such an operator locally defined in some Genode source files (allocator_avl.cc for instance). I wonder why such an operator is not publicly available although its usefulness is obvious. For the time being I created a local inplementation for my purpose by cloning it from an exisiting one. It would be helpful to have it generally thru a system include file. Regards Frank

2 1

Question regarding parent capabilities
by Steffen Liebergeld 09 Jun '10

09 Jun '10

Hi, for my porting efforts, I need to map the physical parent Capability into the protection domain of a newly created Child. To do so, I extended the Cpu_session with a method "native_thread", which --given a Genode::Capability-- will tell me the "physical" Capability of a thread. I map the parent capability into a known place of the child address space using the assign_parent method of Platform_pd. Unfortunately at this point I am stuck. Can you give me some advice on where assign_parent is called and how I can provide it with the correct capability (as my tries of implementing that in Process::Process have failed)? Many thanks in advance, Steffen -- Dipl.-Inf. Steffen Liebergeld <steffen@...37...> Security in Telecommunications TU Berlin/ Deutsche Telekom Laboratories Ernst-Reuter-Platz 7, 10587 Berlin Phone: +30 8353 58 263 Web: http://www.t-labs.tu-berlin.de/sect

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users