l4-hackers

l4-hackers@os.inf.tu-dresden.de

2827 discussions

Patches for L4linux
by basant mudalgi 22 Aug '05

22 Aug '05

Hi dont know if this is the right place to send this mail to. I am pretty new to the whole l4 concept. I have been trying to download the l4linux-2.6.12 on my pathetic dial-up connection which is obviously taking longer than expected. i would like to know if there are patches which i can apply to the standard linux (monolithic) kernel to make it an l4linux kernel and save a lot of download time and effort. ie. something like: linux-2.6.xx ----patch----> l4linux-2.6.xx If so where do i find them? If not ...could anyone do the favour? Regards ------------ Basant Mudalgi

2 1

l4linux based distro
by PhilT 19 Aug '05

19 Aug '05

Is L4Linux good enough to be included in a standard Linux distro? I was wondering if anyone was planning to do so? I am trying to compile L4Linux under Ubuntu but am getting lots of error messages during the compile. My lack of knowledge of Linux/L4 etc means it will probably be difficult to ever get this working. Does anyone have pre-compile binaries? Many thanks Rabbit

3 2

RT-Drops : Admission Server
by Arthur Mielimonka 18 Aug '05

18 Aug '05

Hi, when we (Erlangen INF 6) were in Dresden you told us about an Admission Server which assures that periodic realtime-threads can reserve cpu-time with a validation that no over-reservation is made. I didn't find it in the remote-cvs, would you please add it or send it to me? Thanks, Arthur PS: See http://os.inf.tu-dresden.de/papers_ps/steinberg-diplom.pdf , chapter 3.1.3 for the Programming model for Admission Servers

2 1

Via C3 Assertion Failed
by Christoph Mueller 18 Aug '05

18 Aug '05

Hello, I tried to run the demo-CD on my laptop that has a Via C3 CPU. The following error occured: >Assertion failed: '!(*pte & INTEL_PTE_VALID)' > in .../boot/ia32/boot_cpu.cc:450 in function (null) at 00300539 Some more info about the processor: $ cat /proc/cpuinfo: processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Ezra stepping : 8 cpu MHz : 798.007 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1592.52 Is there a way to run DROPS on Via C3 or should i reinstall the energy-intensive Intel Pentium 3? Thanks, Christoph

2 1

Re: Reboot does not work anymore!
by Frank Mehnert 17 Aug '05

17 Aug '05

On Wednesday 17 August 2005 15:48, Leon Brits wrote: > > Should not does any matter. But how do you set the video mode, via GRUB > > vbeset of via --vbemode parameter of l4con? > > grub Hmm. Very strange. When you reboot via the l4con console you most probably mean the pkg/loader/example/run program. Could you please disassemble that binary objdump -ld loader/example/run/OBJ-x86_586-l4v2/run | less and search for pc_reset, right? That function should come from oskit10 and we did not change anything there. Frank -- ## Dept. of Computer Science, Dresden University of Technology, Germany ## ## http://os.inf.tu-dresden.de/~fm3 ##

1 0

Reboot does not work anymore!
by Leon Brits 17 Aug '05

17 Aug '05

Hi all, I've moved to the latest CVS checkout of L4 and L4Env and now the "Reboot Sequence" in the console (Shift-6-6) does not work anymore. It prints the second "rebooting" message and then just hangs. Any suggestions? Thanks Leon NB. It is the first time I am using l4con instead of con.

2 1

c++ stl in l4/pkg/libstdc++
by Bert van Leeuwen 17 Aug '05

17 Aug '05

Hi, Can somebody (Frank?) please give me some pointers on how to replace the STL in l4/pkg/libstdc++ for gcc 3.3.x (i.e. /l4/pkg/libstdc++/lib/src-v3 and l4/pkg/libstdc++/contrib/libstdc++-v3)? It seems to be rather an old version, and I would like to try a newer version to eliminate possible sources of error in my program. I tried just replacing drops/include/c++/3.3 with the STL on my box, but that gave hundreds of compile errors. (My program is hanging sporadically, and everytime I get a backtrace into the hung thread, it is somewhere inside STL list. I cannot reproduce this behaviour in linux, only in L4, so I want to see if replacing the STL with a newer version will help) Thanks, Bert

2 1

prebuilt environment
by Julian Stecklina 16 Aug '05

16 Aug '05

Hello, is there somewhere a prebuilt build environment for Fiasco/L4-Env/ DROPS? My primary development box (and in fact all PCs I own) run FreeBSD and I do not plan to switch to some GNU/Linux which most parts of the build process seem to assume. Even a Linux build would be useful to me, as I could run it using the Linuxulator. Regards, -- Julian Stecklina (Of course SML does have its weaknesses, but by comparison, a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god.) -- Thant Tessman

2 4

Re: What happens on timeslice overrun?
by Udo A. Steinberg 15 Aug '05

15 Aug '05

On Mon, 15 Aug 2005 15:17:20 +0200 Rene Wittmann (RW) wrote: RW> > When a thread is preempted (that means it gets involuntarily RW> > descheduled), the remaining time quantum is saved and later RW> > restored when the thread is scheduled again. If the thread RW> > yields its scheduling context (that means it voluntarily RW> > gives it away), the time quantum is no longer available to RW> > the thread. A yield can happen in two ways depending on the RW> > target thread id specified: RW> > RW> > 1) if the target ID is the NIL_ID, then the thread yields its active RW> > scheduling context to noone - the time is effectively gone. This is RW> > what next_reservation does. Note that the kernel checks RW> > the user-specified RW> > ID, to guard against the case where a thread wants to RW> > yield its active RW> > scheduling context and the time quantum on that scheduling RW> > context expires RW> > simultaneously. RW> > RW> > 2) if the target ID is a valid thread ID in the system, then RW> > the action RW> > depends on whether the specified thread is ready to run: RW> > a) if it is, then the current thread donates the current scheduling RW> > context to the specified thread and that thread then becomes the RW> > current thread. This is similar to what happens during RW> > a donating IPC. RW> > RW> > b) if the specified thread is not ready, then the current RW> > scheduling RW> > context is gone, similar to 1) RW> > RW> How can I specify the target ID? When creating the thread? But how? The target thread ID for l4_thread_switch, i.e. the thread to yield to, is a parameter to that system call. The L4 interface (see L4.V2 manual) describes the ABI for x86: The following registers are defined for Fiasco: EAX scheduling context ID ESI low part of the target thread ID After the system call returns, the following registers are defined: EAX return value (0 = success, -1 = failure) ECX low part of remaining time on yielded sched. context (if EAX is 0) EDX high part of remaining time on yielded sched. context (if EAX is 0) You probably need not concern yourself with these low-level details of the L4 ABI - there should be bindings in l4/pkg/l4sys that provide high-level interfaces to l4_thread_switch. -Udo.

1 0

AW: What happens on timeslice overrun?
by Rene Wittmann 15 Aug '05

15 Aug '05

> RW> I have 2 questions on the RT part in DROPS: > RW> > RW> 1.) I have 2 RT working threads, each with 3 timeslices: > RW> Thread 1: period=10ms > RW> ts1=30ms prio1=50 > RW> ts2=10ms prio2=30 > RW> ts3=20ms prio3=50 > RW> > RW> Thread 2: period=10ms > RW> ts1=20ms prio1=40 > RW> ts2=5ms prio2=30 > RW> ts3=10ms prio3=40 > RW> > RW> Assume both threads are ready at the same time. > RW> So thread 1 starts and does its work until it releases the > RW> voluntarily or it's preempted by its preempter-thread. So say it > RW> releases voluntarily after 20ms. > > When you say "it's preempted by its preempter thread", do you > mean the situation when a preempter with a higher priority > than the current thread receives a preemption IPC from the > kernel and thus preempts the current thread? > That's what I meant. The preempter has a higher priority and receives the IPC and thus "tells" (via IPC or via common variable if in same address space) the thread to stop the work. > RW> Who will get the left 10ms? I guess nobody. > > When a thread is preempted (that means it gets involuntarily > descheduled), the remaining time quantum is saved and later > restored when the thread is scheduled again. If the thread > yields its scheduling context (that means it voluntarily > gives it away), the time quantum is no longer available to > the thread. A yield can happen in two ways depending on the > target thread id specified: > > 1) if the target ID is the NIL_ID, then the thread yields its active > scheduling context to noone - the time is effectively gone. This is > what next_reservation does. Note that the kernel checks > the user-specified > ID, to guard against the case where a thread wants to > yield its active > scheduling context and the time quantum on that scheduling > context expires > simultaneously. > > 2) if the target ID is a valid thread ID in the system, then > the action > depends on whether the specified thread is ready to run: > a) if it is, then the current thread donates the current scheduling > context to the specified thread and that thread then becomes the > current thread. This is similar to what happens during > a donating IPC. > > b) if the specified thread is not ready, then the current > scheduling > context is gone, similar to 1) > How can I specify the target ID? When creating the thread? But how? > RW> Or can I assign my left time to a specific thread, say > ts2 of thread > RW> 1, that is has 20ms after recognizing that ts1 was finished 10ms > RW> earlier?I could do with l4_rt_change_timeslice(), but this would > RW> probably not work for the the current period! (or yes?) > > A thread can yield the current scheduling context to another > thread as described in 2a) above. Note that the thread will > yield the current scheduling context (which may not > necessarily be the thread's own active scheduling context). > As an example consider: > A sends a donating IPC to B, now B runs on A's scheduling > context. If B yields to C, then C will run on A's time and B > will not donate its own scheduling context. If the current > scheduling context is in fact the active scheduling context > of the donating thread, then realize that the donating thread > will likely encounter a timeslice overrun soon after the > yield (the donatee will consume the time quantum until it runs out). > If you'd rather avoid that, then the donatee will have to > yield the scheduling context back to the owner (the original > donator) who then has to yield it to noone. > > Changes to the time quantum of a scheduling context are only > visible the next time that scheduling context becomes the > current scheduling context. That means if you change the > current scheduling context, then the change will not be > visible immediately. > OK, that's clear now. > RW> 2.) Consider we have a deadline miss. And we say > RW> l4_rt_next_period(): would it wait for the beginning of the next > RW> (which means: > RW> period 1: deadline miss > RW> period 2: call next period (because we think we're > RW> still in period 1)+ wait to end of period > RW> period 3: normal work) > RW> Or do I have to care that we do not call > RW> l4_rt_next_period() in case of a deadline miss? > > If your thread misses its deadline right before it wanted to > call l4_rt_next_period, then l4_rt_next_period blocks the > thread until the end of the new period started due to the > deadline miss. Since this is likely not what the thread > intended to do, it's the preempter's job to handle that > situation, e.g. by ex_regs'ing the thread out of it's > l4_rt_next_period call. > OK, clear. Thanks, Rene

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers