- l4-hackers - example.com Site

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

Re: L4ka and Bochs (was: L4ka and plex86?)
by Farid Hajji 16 Oct '00

16 Oct '00

Hi Volkmar and Kevin, trying to get l4ka running under bochs would probably require slight modifications to the bochs sources, so that 4 MB pages (bit 4 PSE of CR4) can be supported (please see summary below). > ------------------ BoSnip ------------------- > > // Only allow writes of 0 to CR4 for now. > > // Writes to bits in CR4 should not be 1s as CPUID > > // returns not-supported for all of these features. > ------------------ EoSnip ------------------- > > So what happens is that we initialize 4MB pages (located in the first level > page dirs). > If bochs does not support 4MB pages - you are pretty much out of luck - we > currently do not support > 4K pages only. The kernels virtual view of physical memory is mapped as 4MB > pages. Furthermore, > RMGR and L4Linux assumes 4MB/Super-pages. So if you have absolutely no > possibility to get a normal > Pentium System - we have to do some mid-major :) changes of the startup > code. I don't hope that it would be necessary to tweak the l4ka sources so much (at least not for that 4MB problem). Looking at the sources of bochs, I think that it would be _much_ easier to add support for the PSE bit (bit 4 of CR4) to bochs itself at two places, rather than modifying l4ka. This is what I've found out so far (sorry for lengthy message): ---------- cut here ----------- cut here ------------- cut here -------------- Summary: ======== 1. About superpages, PSE bit etc... - - - - - - - - - - - - - - - - - - Intel Architecture Software Developer's Manual Volume 3: System Programming Order-Nr: 243192 http://developer.intel.com/design/pentiumii/manuals/24319202.pdf Section 3.6 Paging (Virtual Memory): PG-Flag (Bit 31 of CR0) enables paging translation, >= 386 PSE-Flag (Bit 4 of CR4) 4k or 4MB pages, >= 586 PAE-Flag (Bit 5 of CR4) 36Bit physical addr, >= 686 Section 3.6.2.1 Linear Address Translation (4 kByte Pages) Section 3.6.2.2 Linear Address Translation (4 MByte Pages) Section 3.6.2.3 Mixing 4kByte and 4MByte pages Section 3.8.2 Linear Address Translation With Extended Adressing Enabled (2 MByte or 4 MByte Pages). ====> PSE bit is only used while translating linear addresses to physical ====> addresses. paging directory entries and page table entries have slighly ====> different format (?) when 4 MB pages are involved. See figures ====> 3-14, 3-15, 3-18, 3-19, 3-20, 3-21. ====> In bochs, this is mainly located in the file: ====> bochs-2000_0325a/cpu/paging.cc 2. L4ka sources - - - - - - - - 2.1: l4-ka/kernel/src/x86/init.c:init_paging() .............................................. #if defined(CONFIG_ARCH_X86_I586) || defined(CONFIG_ARCH_X86_I686) /* Turn on super pages. */ enable_super_pages(); #endif ====> I configured with CONFIG_ARCH_X86_I586 to avoid having to: ====> #if defined(CONFIG_ARCH_X86_I686) ====> enable_global_pages(); ====> setup_sysenter_msrs(); ====> #endif 2.2: l4-ka/kernel/include/x86/cpu.h:enable_super_pages() ........................................................ INLINE void enable_super_pages() { __asm__ __volatile__ ("mov %%cr4, %%eax\n" "orl $0x10, %%eax\n" "mov %%eax, %%cr4\n" : : : "eax"); } ====> Turning on bit 4 of CR4 (PSE) enables 4 MB pages. ====> Volkmar: In Section 3.6.2.2 (at the End), the note says ====> Volkmar: that the TLBs _must_ be flushed (invalidated) after setting ====> Volkmar: or clearing the PSE bit. Forgot to do it? ====> This is the instruction that crashes bochs. 3. Bochs sources: - - - - - - - - - 3.1 output of bochs.out logfile: ................................ WBINVD: (ignoring) MOV_RdCd: read of CR4 MOV_CdRd: ignoring write to CR4 of 0x00000010 bochs: panic, MOV_CdRd: (CR4) write of 0x00000010 >> mov CR4, EAX ====> Bochs panic()s because it doesn't support CR4 bits yet (see below). ====> l4ka (enable_super_pages()) tries to set the PSE bit in CR4 because ====> it needs 4 MB superpages. 3.2 bochs-2000_0325a/cpu/proc_ctrl.cc: ...................................... This file contains the implementation of the x86-instructions. Let's look at the missing/buggy parts that were reported in bochs.out above: 3.2.1: WBINVD: (ignoring): . . . . . . . . . . . . . void BX_CPU_C::WBINVD(BxInstruction_t *i) { bx_printf("WBINVD: (ignoring)\n"); #if BX_CPU_LEVEL >= 4 invalidate_prefetch_q(); if (BX_CPU_THIS_PTR cr0.pe) { if (CPL!=0) { bx_printf("WBINVD: CPL!=0\n"); exception(BX_GP_EXCEPTION, 0, 0); } } BX_INSTR_CACHE_CNTRL(BX_INSTR_WBINVD); #else UndefinedOpcode(i); #endif } ====> BX_CPU_LEVEL was defined to be 5, so invalidate_prefetch_q() ====> was called. WBINVD (invalidates TLB etc...) seems to be okay. 3.2.2: read of CR4: . . . . . . . . . . void BX_CPU_C::MOV_RdCd(BxInstruction_t *i) { // mov control register data to register <snip> case 4: // CR4 #if BX_CPU_LEVEL == 3 val_32 = 0; bx_printf("MOV_RdCd: read of CR4 causes #UD\n"); UndefinedOpcode(i); #else bx_printf("MOV_RdCd: read of CR4\n"); val_32 = BX_CPU_THIS_PTR cr4; #endif break; <snip> } ====> This seems to be okay once more. The contents of the variable ====> cr4 can be read on this BX_CPU_LEVEL of 5. 3.2.3: ignoring write to CR4 of 0x00000010....., then panic() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . void BX_CPU_C::MOV_CdRd(BxInstruction_t *i) { // mov general register data to control register <snip> case 4: // CR4 #if BX_CPU_LEVEL == 3 bx_panic("MOV_CdRd: write to CR4 of 0x%08x on 386\n", val_32); UndefinedOpcode(i); #else // Protected mode: #GP(0) if attempt to write a 1 to // any reserved bit of CR4 bx_printf("MOV_CdRd: ignoring write to CR4 of 0x%08x\n", val_32); if (val_32) { bx_panic("MOV_CdRd: (CR4) write of 0x%08x\n", val_32); } // Only allow writes of 0 to CR4 for now. // Writes to bits in CR4 should not be 1s as CPUID // returns not-supported for all of these features. BX_CPU_THIS_PTR cr4 = 0; #endif break; <snip> } ====> This has to be tweaked, perhaps by adding a call to a new ====> CR4_change() function (like CR3_change()), which can ====> then be added to paging.cc. If the change is minimal, ====> modifying variable cr4 directly may be enough. Anyway, ====> in paging.cc, the translation functions must take into ====> account the PSE bit it cr4!!! 3.3 bochs-2000_0325a/cpu/paging.cc .................................. // Translate a linear address to a physical address, for // a data access (D) Bit32u BX_CPU_C::dtranslate_linear(Bit32u laddress, unsigned pl, unsigned rw) { <snip long code which uses cr0, cr3 but not cr4 (yet)> } // Translate a linear address to a physical address, for // an instruction fetch access (I) Bit32u BX_CPU_C::itranslate_linear(Bit32u laddress, unsigned pl) { <snip long code which uses cr0, cr3 but not cr4 (yet)> } ====> these functions will have to additionally take into ====> account the value in cr4 (e.g. PSE bit), so that ====> 4 MB pages are supported. ---------- cut here ----------- cut here ------------- cut here -------------- 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 2