- l4-hackers - example.com Site

Re: RH6.2 and Fiasco
by Michael Hohmuth 24 Oct '00

24 Oct '00

James, are you still having problems with Fiasco? Ißm just now catching up with my email... James Riordan <rij(a)zurich.ibm.com> writes: > Now that it is built, it crashes at boot time: > > RMGR: loading (hd1,1)/fiasco/sigma0 > RMGR: detected new-style DD-L4 > RMGR: starting (hd1,1)/fiasco/main -nokdb proto=0x10128c > > Welcome to Fiasco! > DD-L4/x86 microkernel (c) 1998 TU Dresden - Jul 13 2000 > KDB: init > L4KD -BP----------------------------------------------EIP: f00011c9 > > (hang) > > Any further suggestions? This is the kernel-debugger prompt. Have you tried typing "g" (mnemonic: Go) here? Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: CVS server problems?
by Michael Hohmuth 24 Oct '00

24 Oct '00

suzukis(a)flavor1.ipc.hiroshima-u.ac.jp writes: > >did anyone tried to use flux' oskit instead of oskit10 with l4? > > I think Fiasco is (although slowly) moving from oskit to oskit10. Towards > to the newest Flux OSkit will be after it. In my previous building of Fiasco, > it was still dependent on both of oskit & oskit10. So, replacing oskit by > oskit10 seems to be long way. Is it so difficult work? No, it is not that difficult, but we haven't switched to oskit10 because of two reasons: First, the newer OSKit is GPL'd, and we have to maintain a version of Fiasco that is not under the GPL to be able to sell commercial licenses. Such licenses are one way for us to continue financing Fiasco development. That said, however, I agree that a port of Fiasco to the newer OSKit would be worthwile; the old OSKit has compilation problems with newer compilers and binutils. It just isn't an option to completely depend on it; it must be possible to compile Fiasco with older OSKit's as well. So I would like to see everything that's needed from the OSKit hidden in behind a module interface that can be implemented by either the old or the new OSKit. We just haven't got around to implement this kind of abstraction. Maybe one of you can contribute? Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: CVS server problems?
by Michael Hohmuth 24 Oct '00

24 Oct '00

L4 hackers, I'm slowly working my way up through my email archive... Sorry for not responding for so long -- I've been quite busy and had trouble keeping up with my email. Farid Hajji <farid.hajji(a)ob.kamp.net> writes: > I was able to compile flux' oskit on FreeBSD-5.X out of the box without > any problems (using gmake, gcc-2.95.2 and binutils-2.9.1). So there is > definitely something wrong with the CVS server at Dresden :-( The CVS-server problems have finally been fixed two weeks or so ago. (Our bug-tracking database is still in trouble... The problems are due to a change in our server architectue because of stability problems with our Linux SMP server.) Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

RE: first experiences with l4ka on a real pentium
by Brent Fulgham 20 Oct '00

20 Oct '00

Farid, Nice work on the BOCHS write-up. I'll have to give it a try at some point. Anyway -- I also get the endless loop when booting from GRUB. I'll have to try the Dresden binary to see if this corrects the problem. If so, we'll have to see if Okuji or Gord would be willing to add whatever changes were necessary to the main GRUB tree. Since Okuji reads this mailing list, I'm hoping he'll do so (hint, hint ;-) Thanks, -Brent

2 1

L4KA mailing list
by Uwe Dannowski 19 Oct '00

19 Oct '00

Hi L4KA users! To take L4KA-specific discussions off l4-hackers, we've set up a dedicated mailing list for L4KA. To subscribe to the list, send mail containing only the word "subscribe" (without the qoutes) in the body to l4ka-request(a)ira.uka.de . To unsubscribe send the word "unsubscribe". Posting to the list is restricted to list members. Cheers, Uwe

1 0

first experiences with l4ka on a real pentium
by Farid Hajji 19 Oct '00

19 Oct '00

Hi Brent, [I Cc-ed this to contact(a)l4ka.org and l4-hackers. L4Ka reports from other users would be great too.] > I'm curious because I get similar problems to your > description when trying to boot the L4KA kernel > on a K6-2 chip. > > However, in my case the boot process seems to work > fine as far as the initial sigma0 task starts, then > rmgr in debug mode will print an error message > (or a "Hello from RMGR" message depending on the build > I use). > > Basically, the boot fails before getting into glinux > and if rmgr and the kernel are built for debugging > they will trap the error and stop. In "runnable" > mode, I just get a soft reboot. I just tried L4Ka on a real pentium box: CPU: Pentium/P54C (199.43-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8> real memory = 134217728 (131072K bytes) I was able to boot the provided root_task template, but not glinux (yet). I booted entirely from floppy, since I can't use the hd of this production FreeBSD-box for experiments. I compiled l4ka for 586 (not 686) with kernel debugger, sigma0, rmgr and the template root_task. The first thing to do was to disable the call to the kernel debugger on startup in l4-ka/kernel/src/init.c:init() #if defined CONFIG_DEBUG_KDB_ONSTART enter_kdebug("startup"); #endif I did this because I wanted to keep the kernel debugger but I didn't found out how to use it to resume booting. I then had to figure out, that the LINKBASE address in l4-ka/root_task/Makefile had to be changed to a real existing physical address: < LINKBASE=0x0c200000 > LINKBASE=0x07200000 If not, the following error message appears: RMGR: loading task (fd0)/l4ka/root_task from 0x159000_0x15a6bc to [0xc200000-0xc201504 cannot allocate page at 0xc200000 : owned by 0x89] Return reboots, "k" enters L4 kernel debugger. Trying to display the memory regions with the kernel debugger was easy. E.g. "d158fb0" shows a dump at address 00159000 which started like this: 00159000: 46 .... <after 46: ELF...> I wished the kdb was documented somewhere, not only in its sources :( The screen handling is also not perfect yet (see above with 'd' command). Dumping c200000 hangs the machine, probably because that address is outside of the physical range. After fixing LINKBASE, booting with the following menu.lst entry was successful: title=L4Ka without kernel debugger on start kernel=(fd0)/l4ka/rmgr -sigma0 module=(fd0)/l4ka/x86-kernel.nokdb module=(fd0)/l4ka/sigma0 module=(fd0)/l4ka/root_task.7200000 root_task is just a hello world, followed by an endless loop. This is the contents of the screen then: ----- cut here ---------- interrupt association failed (e0044800 irq: 2) interrupt association failed (e0046000 irq: 8) sigma0_main: kernel_info_page is at 0x00107000 sigma0: map 4M page at 5800000 to 4040001 sigma0: map 4M page at 5c00000 to 4040001 sigma0: map 4M page at 6000000 to 4040001 sigma0: map 4M page at 6400000 to 4040001 sigma0: map 4M page at 6800000 to 4040001 sigma0: map 4M page at 6c00000 to 4040001 sigma0: map 4M page at 7000000 to 4040001 sigma0: map 4M page at 7400000 to 4040001 RMGR: total RAM size = 130688 KB (reported by bootloader) received 122152 KB RAM from sigma0 204 KB reserved for RMGR RMGR: attached irqs = [<!0> 1 <!2> 3 4 5 6 7 <!8> 9 a b c d e f] RMGR: loading task (fd0)/l4ka/root_task.7200000 to [0x7200000-0x7201504] RMGR: starting task (fd0)/l4ka/root_task.7200000 at entry 0x7200000 via trampoline page code 0x3140. main: started. <<<-- appears over sigma0_main: ... <<<-- due to missing screen handling. ----- cut here ------------- So far, so good. I then tried to boot glinux with the following menu.lst entry: title=L4Ka with glinux kernel=(fd0)/l4ka/rmgr -sigma0 module=(fd0)/l4ka/x86-kernel.nokdb module=(fd0)/l4ka/sigma0 module=(fd0)/l4ka/glinux.gz -s knowing that I don't have any linux root partition on that FreeBSD box. Anyway, I just wanted to see glinux start and no more for now. As you can see from menu.lst, I had to gzip -9 glinux to fit it on one floppy. GRUB should be able to load gzipped modules. Booting this resulted in the following output screen: ----- cut here -------------- sigma0_main: kernel_info_page is at 0x00107000 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 ----- cut here -------------- The last line being constantly redrawn in an (endless?) loop. I didn't try anything else, because I was not able to compile Dresden's L4Linux on FreeBSD (I used l4ka.org's glinux binary). At least the root_task seems to work and this is very good for now. Based on root_task, L4 servers can be build, probably with flux' oskit (which compiles w/o problems on FreeBSD too!). The we can start thinking about libmom and porting the Hurd to L4Ka. I can't resume tests on a real pentium right now, so I'll have to look at bochs sources to add support for 4MB superpages. This will take its time though, since I'm not an x86 expert :-). Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

3 4

RE: first experiences with l4ka on a real pentium
by Brent Fulgham 19 Oct '00

19 Oct '00

Farid, > [I Cc-ed this to contact(a)l4ka.org and l4-hackers. L4Ka > reports from other users would be great too.] > (I'll also CC the L4 groups) > I then had to figure out, that the LINKBASE address in > l4-ka/root_task/Makefile > had to be changed to a real existing physical address: > > < LINKBASE=0x0c200000 > > LINKBASE=0x07200000 > > If not, the following error message appears: > > RMGR: loading task (fd0)/l4ka/root_task from 0x159000_0x15a6bc > to [0xc200000-0xc201504 cannot allocate page at > 0xc200000 : owned by 0x89] > Return reboots, "k" enters L4 kernel debugger. > Yes, I saw this as well. > So far, so good. > I then tried to boot glinux with the following menu.lst entry: > > title=L4Ka with glinux > kernel=(fd0)/l4ka/rmgr -sigma0 > module=(fd0)/l4ka/x86-kernel.nokdb > module=(fd0)/l4ka/sigma0 > module=(fd0)/l4ka/glinux.gz -s > > knowing that I don't have any linux root partition on that > FreeBSD box. > Anyway, I just wanted to see glinux start and no more for now. As you > can see from menu.lst, I had to gzip -9 glinux to fit it on > one floppy. > GRUB should be able to load gzipped modules. Booting this resulted in > the following output screen: > In my case, for a split second I actually did see the start of a standard Linux 2.2-series boot sequence. But it almost immediately reboot. > I didn't try anything else, because I was not able to compile > Dresden's L4Linux on FreeBSD (I used l4ka.org's glinux binary). > At least the root_task seems to work and this is very good for now. > Based on root_task, L4 servers can be build, probably with flux' oskit > (which compiles w/o problems on FreeBSD too!). The we can start thinking > about libmom and porting the Hurd to L4Ka. > Yes, this is excellent news. But why do you feel the OsKit is necessary? It seems that with a working L4KA it should be possible to follow the example of the hello-world template to produce servers of our own. Or perhaps it's just easier with OsKit? I must admit I haven't taken the time to master that beast :) > I can't resume tests on a real pentium right now, so I'll have to look > at bochs sources to add support for 4MB superpages. This will take its > time though, since I'm not an x86 expert :-). > Me neither. Luckily, I do have a second machine for working with this. Unfortunately, it's another AMD K6-2 so it may suffer from problems we don't forsee yet. But it will probably be helpful data for the L4 hackers. After all, it should work on all Intel-ish processors. Thanks, -Brent

2 1

[Patch] Bochs with 4M superpages runs L4Ka
by Farid Hajji 19 Oct '00

19 Oct '00

Hi, [Kevin: would you please have a closer look at this patch? I'm not an x86 expert and this is at best a premature first try at it. -Thanks] the following patch: http://home.kamp.net/home/farid.hajji/l4ka-bochs/ enables 4 MB superpages in bochs. With this hack, you can boot (among others) L4Ka+root_task without problems on your favorite workstation ;-) (at least I hope so!). Please refer to the file SUPERPAGES in the patched bochs sources for a quick overview. General instructions and screen shots can be found on the above URL. BEWARE: That hack is very alpha and not tested at all! Don't rely on it too much for now. At least, it won't destroy your system, since everything is emulated in software. Bochs may be slow (it is!) but at least it's more secure than plex86 or vmware and it runs on non- intel boxes too. If you find any bugs (e.g. bochs panics()), please try to track them down and fix the sources as far as possible. It is easier than it sounds because bochs sources are very clear and because you can insert printf()s everywhere. Try this with a real processor! Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

1 0

Re: Task generation & Fiasco scheduler
by Michael Hohmuth 17 Oct '00

17 Oct '00

"kargahi"<kargahi(a)moe.or.ir> writes: > 1. I tried more than a few times to create a 'task' with the l4_task_new > system call but i couldn't. If possible, please send me some examples and > describtion on creating tasks except the L4 manuals. In order to create a new task using l4_task_new, you need to own a task-creation right first. You can get one from Rmgr using the librmgr.a library call rmgr_get_task(). After that, l4_task_new() should work. Also, please don't forget that the new task needs a pager. I'll append a simple example below. > 2. I am looking for the manager of resource CPU( scheduler ). Please guide > me that where is the scheduler and how i can change it with my algorithm. Most of it is implemented in thread_t::schedule(). Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: Real-time Fiasco
by Michael Hohmuth 17 Oct '00

17 Oct '00

"kargahi"<kargahi(a)moe.or.ir> writes: > Would you please say me why Fiasco is a real-time u-kernel & what > are the real-time properties of Fiasco? For Fiasco, "Real-Time" means that Fiasco implements static ``hard'' thread priorities, and the worst-case time to react to an event such as an interrupt or a timeout are bound. To keep the bound low, Fiasco is is fully preemtible in kernel mode, and it guarantees that ``independent thread groups'' are always executable no matter what is going on in the kernel. > After that, please say me how the priorities affect the timeslice of a task > and where the timeslice of a task is allocated to it. The scheduler uses two variables: Priorities determine the order in which threads are executed (thread_t::schedule()). The time-slice length determines when the kernel considers running a different thread of the same priority. The kernel has the concept of a "current time slice" which is the number of clock ticks the current thread can execute without being preempted. The current time slice (timeslice_ticks_left) is checked in thread_timer_interrupt(), and it is initialized in thread_t::schedule(). Please not that it is not set on every kernel-context switch -- only when a thread is preempted or voluntarily goes to sleep (that is, only in thread_t::schedule(), not in thread_t::switch_to()). Different L4 kernels handle scheduling differently. Jean Wolter has a short paper describing the current state of the art for some L4 implementations that I'm sure he will make available for the asking. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0