- l4-hackers - example.com Site

Tyson vs Botha Wannna Bet!
by 5hbi＠yahoo.com 16 Jan '99

16 Jan '99

Feeling Lucky?? CASH IN ON thE FIGHT!!!! - http://209.67.19.99/want_to_bet/ TYSON V.s. BOTHA SATURDAY NIGHT JAN 16 9pm! REAL LIVE LAS VEGAS GAMBLING Place your bet online with up to the minute odds! Mike Tyson -750 Frans Botha +500 http://209.67.19.99/want_to_bet/ <a href="http://209.67.19.99/want_to_bet/index.html">CLICK HERE</a> to enter

1 0

Re: L4-Linux fails to boot - hangs setting up IDT
by Paul Phillips 15 Jan '99

15 Jan '99

Hi Jean, You were right, this was a problem encountered befor. The "magic" in the Makefile wasn't implemented because I did not have cpp in my path. I found a reference to the fix in an email to Sun-Mi Yu. I'm not home free yet, but I' closer. Thanks again! Paul Phillips -----Original Message----- From: Jean Wolter <jw5(a)os.inf.tu-dresden.de> To: Paul Phillips <pphillips(a)ivue.com> Cc: l4-hackers(a)os.inf.tu-dresden.de <l4-hackers(a)os.inf.tu-dresden.de> Date: Friday, January 15, 1999 4:53 AM Subject: Re: L4-Linux fails to boot - hangs setting up IDT >"Paul Phillips" <pphillips(a)ivue.com> writes: > >> 1.) Why are you calculating the address of the table by subtracting >> out EMULIB_CODE_ADDRESS (Which is 0xA0008000?) ? > >The emulation library is relocated to address 0xa0008000 and idt_table >is a symbol of the emulation library. If you have a look at the symbol >table you will find > >a00084a8 A idt_table > >So ((unsigned long)&idt_table - EMULIB_CODE_ADDRESS) is the offset of >the idt within our emulation library. > > >> 2.) How & why is the emulator code moved to "special page". Where is >> the "special page" set up since paging isn't set up until after this >> code is executed? > > >We have to copy the code to ensure that it is page aligned. The >special page is mapped into the address space of every unix process >when it raises its first page fault. Every unix process (L4Linux >process) starts at a fixed address, so we know, that the very first >page fault will request the emulation library page. > >> 3.) Any clue why this is hanging here? I should have a remote >> debugger set up soon, but I have -nokdb set and I don't get any >> kernel panics or reg dumps. The system just hangs. > >If my memory serves right, someone else had the same problem. For some >strange reason L4Linux raised a page fault at this point and the page >fault could not be resolved by the underlying pager. The L4Linux >server now hangs in an endless loop trying to resolve the page >fault. But I'm not sure about that. Michael? > >There is a possibility to monitor all page faults in the system, but I >don't know, how you activate that. > >Jean >-- >I get up each morning, gather my wits. >Pick up the paper, read the obits. >if I'm not there I know I'm not dead. >So I eat a good breakfast and go back to bed. Peete Seeger

1 0

Re: L4-Linux fails to boot - hangs setting up IDT
by Paul Phillips 15 Jan '99

15 Jan '99

Thanks for the input Jean. My symbol table shows: 00000000 A emulib_start 00000328 A user_level_pager 000003a0 A _user_task_init 00000478 A emulib_idt_descr 00000480 A idt_table 00000520 A emulib_debug_idt_descr 00000741 A emulib_end I am using gcc version 2.7.2.3 under Red Hat Linux 5.2. I am compiling the l4-981207 release of the L4-Linux code. Does this shed any light on the problem? Thanks again. Paul Phillips -----Original Message----- From: Jean Wolter <jw5(a)os.inf.tu-dresden.de> To: Paul Phillips <pphillips(a)ivue.com> Cc: l4-hackers(a)os.inf.tu-dresden.de <l4-hackers(a)os.inf.tu-dresden.de> Date: Friday, January 15, 1999 4:53 AM Subject: Re: L4-Linux fails to boot - hangs setting up IDT >"Paul Phillips" <pphillips(a)ivue.com> writes: > >> 1.) Why are you calculating the address of the table by subtracting >> out EMULIB_CODE_ADDRESS (Which is 0xA0008000?) ? > >The emulation library is relocated to address 0xa0008000 and idt_table >is a symbol of the emulation library. If you have a look at the symbol >table you will find > >a00084a8 A idt_table > >So ((unsigned long)&idt_table - EMULIB_CODE_ADDRESS) is the offset of >the idt within our emulation library. > > >> 2.) How & why is the emulator code moved to "special page". Where is >> the "special page" set up since paging isn't set up until after this >> code is executed? > > >We have to copy the code to ensure that it is page aligned. The >special page is mapped into the address space of every unix process >when it raises its first page fault. Every unix process (L4Linux >process) starts at a fixed address, so we know, that the very first >page fault will request the emulation library page. > >> 3.) Any clue why this is hanging here? I should have a remote >> debugger set up soon, but I have -nokdb set and I don't get any >> kernel panics or reg dumps. The system just hangs. > >If my memory serves right, someone else had the same problem. For some >strange reason L4Linux raised a page fault at this point and the page >fault could not be resolved by the underlying pager. The L4Linux >server now hangs in an endless loop trying to resolve the page >fault. But I'm not sure about that. Michael? > >There is a possibility to monitor all page faults in the system, but I >don't know, how you activate that. > >Jean >-- >I get up each morning, gather my wits. >Pick up the paper, read the obits. >if I'm not there I know I'm not dead. >So I eat a good breakfast and go back to bed. Peete Seeger

1 0

Re: L4-Linux fails to boot - hangs setting up IDT
by Jean Wolter 15 Jan '99

15 Jan '99

"Paul Phillips" <pphillips(a)ivue.com> writes: > 1.) Why are you calculating the address of the table by subtracting > out EMULIB_CODE_ADDRESS (Which is 0xA0008000?) ? The emulation library is relocated to address 0xa0008000 and idt_table is a symbol of the emulation library. If you have a look at the symbol table you will find a00084a8 A idt_table So ((unsigned long)&idt_table - EMULIB_CODE_ADDRESS) is the offset of the idt within our emulation library. > 2.) How & why is the emulator code moved to "special page". Where is > the "special page" set up since paging isn't set up until after this > code is executed? We have to copy the code to ensure that it is page aligned. The special page is mapped into the address space of every unix process when it raises its first page fault. Every unix process (L4Linux process) starts at a fixed address, so we know, that the very first page fault will request the emulation library page. > 3.) Any clue why this is hanging here? I should have a remote > debugger set up soon, but I have -nokdb set and I don't get any > kernel panics or reg dumps. The system just hangs. If my memory serves right, someone else had the same problem. For some strange reason L4Linux raised a page fault at this point and the page fault could not be resolved by the underlying pager. The L4Linux server now hangs in an endless loop trying to resolve the page fault. But I'm not sure about that. Michael? There is a possibility to monitor all page faults in the system, but I don't know, how you activate that. Jean -- I get up each morning, gather my wits. Pick up the paper, read the obits. if I'm not there I know I'm not dead. So I eat a good breakfast and go back to bed. Peete Seeger

1 0

Fiasco Bug Tracking System
by Michael Hohmuth 14 Jan '99

14 Jan '99

Hackers, I have set up a new bug tracking system for Fiasco; I hope you'll like it. I've already imported a few of your bug reports, but it's well possible that I've forgotten some. Please visit <URL:http://os.inf.tu-dresden.de/fiasco/bugs/> and tell me what you think. Use this page to report new (or old) bugs, or email your reports to <fiasco-bugs(a)os.inf.tu-dresden.de>, to make sure they won't get lost. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

2 1

L4-Linux fails to boot - hangs setting up IDT
by Paul Phillips 14 Jan '99

14 Jan '99

I am trying to boot L4-Linux using the Fiasco microkernel. The microkernel boots fine, but when L4Linux is booting, in module chead.c you have the code: /* create idt */ { extern long idt_table; struct entry_t {unsigned short w0, w1,w2,w3;} ; struct entry_t *entries = (struct entry_t *)((unsigned long)emu_lib_text + ((unsigned long)&idt_table - EMULIB_CODE_ADDRESS)); unsigned short int tmp; int i; for (i=0; i<20; i++, entries++) { tmp = entries->w1; entries->w1 = entries->w3; entries->w3 = tmp; } } My system hangs when it attempts to execute this code. I understand why you are swapping the shorts in the table (swapping the offset bytes with the selector bytes) but there are a couple of things I don't understand Several questions: 1.) Why are you calculating the address of the table by subtracting out EMULIB_CODE_ADDRESS (Which is 0xA0008000?) ? 2.) How & why is the emulator code moved to "special page". Where is the "special page" set up since paging isn't set up until after this code is executed? 3.) Any clue why this is hanging here? I should have a remote debugger set up soon, but I have -nokdb set and I don't get any kernel panics or reg dumps. The system just hangs. Thanks in advance!! Paul Phillips

1 0

Re: TCB size in ix86 L4
by Torsten Paul 08 Jan '99

08 Jan '99

Michael Hohmuth <hohmuth(a)innocent.com> writes: > can't meet real-time requirements; the task_delete operation seems to > be especially bad, sometimes disabling interrupts for more than one > second. > Yes, the measurements showed interrupt a latency of sometimes 1.5 seconds (even if the interrupt thread had the highest priority) when in the L4-Linux System had to serve a lot of calls to fork/exec. This was tested with the lat_proc benchmark from the lmbench-suite that tries to measure the latency for creating simple processes (that only call exit) Still there is only one explanation for this: disabled interrupts while flushing the complete address space of a task when doing task_delete. ciao, Torsten. -- Torsten Paul Es ist leichter, einen Atomkern zu paul(a)os.inf.tu-dresden.de // spalten als ein Vorurteil. __________________________ooO_(+ +)_Ooo________Albert Einstein_(1879-1955) U

2 1

Re: next-gen mapping
by Michael Hohmuth 07 Jan '99

07 Jan '99

"Adam 'WeirdArms' Wiggins" <awiggins(a)cse.unsw.edu.au> writes: > Would an assembler based L4 benifit from this new mapping tree > data base too? It certainly sounds easier to handle memory for. I think that the binary-tree representation is easier to implement than the trees-in-fixed-size-arrays one. One factor which complicates the latter is that the fixed-size arrays have to be efficiently allocated, deallocated, and moved around in memory. Lukas' implementation includes a generic slab allocator for tree allocation. > I'm trying to work out my dynamic data structures now. So far i have > TCB's (512 bytes), 1st level page table entries 16K, 2nd level page > table entries 1K, mapping tree nodes ??? no idea yet. I got Lukas's > paper but i failed german in my high school years :( I'm trying to > get it translated. It there any code somewhere i can look at which > would illistraight it? Or does lukas have the time to give me an > english run down? I think Gernot is trying to translate the paper using Babelfish; Lukas has sent him his paper's sources. Other than that, I'm positive that we can help you understanding it. (If you're patient enough, you might even just wait until I've finished my technical report about Fiasco's design -- but don't hold your breath, please. :) Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: TCB size in ix86 L4
by Michael Hohmuth 07 Jan '99

07 Jan '99

Adam, thanks for your replies! "Adam 'WeirdArms' Wiggins" <awiggins(a)cse.unsw.edu.au> writes: > Question here. Is Jochen's L4 got higher interupt latencies then > fiasco due to masking out interupts or is time in the kernel small enough > for real time applications. Our measurements with L4/x86 version 2 indicate that this kernel is not suitable for real-time work. The ``Taming Linux'' pager details some of these concerns <URL:http://os.inf.tu-dresden.de/papers_ps/part98.ps>. Recently, Torsten Paul did a series of measurements which show that L4/x86 often can't meet real-time requirements; the task_delete operation seems to be especially bad, sometimes disabling interrupts for more than one second. (Torsten, if you're reading this: Is this data correct?) Real-time requirements in our DROPS system are one reason why Fiasco tries to be interruptible at almost any time. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: TCB size in ix86 L4
by Michael Hohmuth 06 Jan '99

06 Jan '99

[ As a courtesy to new readers: TCB = "thread control block", the kernel data structure holding thread-specific data including the thread's stack. ] "Adam 'WeirdArms' Wiggins" <awiggins(a)cse.unsw.edu.au> writes: > I was woundering why the TCB size in ix86 L4 is 1K, how much of > the stack at the end of the TCB is actually used? Very little: Most of the time, less than 150 bytes. > Could the TCB be reduced to 512K? If not why not? ^^^^ 512 bytes? I think it could. L4/x86 has disabled hardware interrupts most of the time, so the theoretical maximal stack usage probably isn't much higher than the one we see, maybe 100 bytes more. I guess Jochen didn't know it was so little when he designed L4, and never changed it later. In the Fiasco kernel, things are different: This kernel had been written in C++, and it may be interrupted at almost any time; handlers may interrupt each other and stack up on one thread's stack. That's why the theoretical maximal stack usage is much higher. Although I haven't computed it yet, I have estimated that a < 1K stack is too small for the current implementation. That's why Fiasco by default is configured to use 2-KByte TCBs. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

2 1