- l4-hackers - example.com Site

using L4-Linux
by edmundo＠rano.demon.co.uk 15 Mar '99

15 Mar '99

The nearest I've got to running L4-Linux so far, apparently, was by dd-ing grub-ext2fs-floppy onto a floppy, adding "main" and "sigma0", which I compiled myself, then booting with the following menu.lst: title = Linux kernel=(fd0)/rmgr -nopentium -sigma0 module=(fd0)/main -nokdb module=(fd0)/sigma0 module=(fd0)/glinux.gz root=/dev/hda2 The first error that I get is: RMGR: ERROR: while parsing config file: syntax error at line 1, col 2 Does this matter? I don't know which config file it's talking about. There's a rmgr.cfg.linux on the floppy, but I'm not booting with it, because it made things worse when I tried using it. At "RMGR: WARNING: there were 1 boot errors - continue?" I press return ... Then I get a mixture of kernel start-up messages and L4 errors which move too quickly for me to note them exactly. There are several screens full of "sigma0 denies mapping", and there's a "Hmm, strange, that shouldn't happen any more", and the last kernel message, before the machine reboots by itself, is "INIT: version 2.75 booting". All quotations may be approximate. I just tried it again, for about the fifth time, and it didn't get as far this time. This time its last words were: Partition check: hda: hda1 hda2 VFS: Mounted root (ext2 filesystem) readonly. wake_up_process: ipc failed wake_up_process: ipc failed wake_up_process: ipc failed ... wake_up_process: ipc failed Can anyone suggest what I can try next? Does anyone have this working? I'm using the files dated 981207 and it's a 486 machine that I'm using. (The other machines that I tried grind to a halt very early on with "space.cc:179: failed assertion `size == PAGE_SIZE'".) Does someone have working binaries of "main" and "sigma0" that I could try, to see if there's something strange about my hardware? The Hello World server does run, by the way. Edmund

1 0

"relocation truncated"
by edmundo＠rano.demon.co.uk 15 Mar '99

15 Mar '99

I wrote to Hohmuth about this, but he might be away or busy ... http://os.inf.tu-dresden.de/fiasco/faq.html#5992 says: [v0.5 981012] Build problem when building oskit/examples/multiboot-smp: "relocation truncated" I cannot reproduce this problem. However, as this binary isn't needed, you can work around this problem by "touch oskit/examples/multiboot-smp". (hohmuth 98/10/24) I got exactly this error when I tried building Fiasco. It was preceded by a warning coming from boot.S, which might be connected, so I'm copying the edited highlights below. Does anyone with knowledge of x86 assembler understand this problem, and can they fix it? How come it only affects some people? Is it caused by different versions of the assembler? Isn't the assembler part of gcc? I'm using standard gcc 2.7.2.3, so which other packages should I check the versions of? I'm using Debian's binutils version 2.9.1.0.19a-2, for example, as released with Debian 2.1. I got the same assembler warning several times when building L4-Linux. Edmund gcc -c -MD -DHAVE_CONFIG_H -I. -I../libsmp/x86 -I- -I.. -I.. -I../flux/c -nostdinc -DASSEMBLER -MD ../libsmp/x86/boot.S /tmp/cca03216: Assembler messages: /tmp/cca03216:538: Warning: warning: missing prefix `*' in absolute indirect address, maybe misassembled! ... ... ... ld -Ttext 100000 -L../lib \ -o multiboot-smp ../lib/multiboot.o multiboot-smp.o \ -lsmp -lkern -lmc -llmm ../lib/crtn.o ../lib/libsmp.a(boot.o): In function `_SMP_TRAMP_START_': boot.o(.text+0x29): relocation truncated to fit: R_386_16 _SMP_TRAMP_32_ENTRY_ make[2]: *** [multiboot-smp] Error 1 make[2]: Leaving directory `/usr/local/tmp/L4/l4/oskit/examples' make[1]: *** [examples/all.MAKE] Error 2 make[1]: Leaving directory `/usr/local/tmp/L4/l4/oskit' make: *** [oskit] Error 2

3 3

send/receive confusion
by edmundo＠rano.demon.co.uk 15 Mar '99

15 Mar '99

Dear Hackers, I've been studying the descriptions of IPC in the L4 Reference Manual (x86) and the L4 User Manual (MIPS) and would be grateful if someone could confirm to me that I've correctly understood some points which are not explicitly stated in those manuals. Here's are my hypotheses/deductions; please tell me if I'm right or wrong! (1) Both the "send message descriptor" and the "receive message descriptor" allow in-line data, strings and fpages to be transmitted in both directions. In fact, the names are confusing and they might better be referred to as "client message descriptor" and "server message descriptor" as the only differences between them relate to the way the other party is addressed - plus one little optimisation for the case where a "receive message descriptor" wants to receive just an fpage. (2) If you want to transmit some data from thread S to thread T, one way of doing it is to get thread S to do a SEND operation and thread T to do a RECEIVE FROM operation, but you could equally well get thread S to do a RECEIVE FROM and thread T to do a SEND, as the "RECEIVE FROM" and "SEND" IPC types have nothing to do with "receive" and "send", really. (3) When you do a CALL operation, specifying both a "send message descriptor" and a "receive message descriptor" in the same system call, in most cases you probably only want to send data with the former and only receive data with the latter. Since both descriptors have space for both directions, you can use the same message descriptor as both send message descriptor and receive message descriptor, if you want. But you don't have to. Edmund

2 3

Re: send/receive confusion
by gernot＠cse.unsw.edu.au 14 Mar '99

14 Mar '99

Edmundo, I think I now understand the source of your confusion. In the Intel version of the L4 manual (at least in my copy of Sep 96), on p25 where the "rcv descriptor" is explained, the option "mem" has the top 30 bits of the descriptor word as "*snd msg/4". That should, of course, read "*rcv msg/4". Also, further to what I wrote in my previous mail: GH> - one or more page mappings or grants, provided that GH> - the "m" bit is set in the send descriptor, and GH> - the beginning of the sender's direct string (starting with the GH> register part) contains at least one valid "send fpage", and GH> - the receive descriptor either has the form of a valid "receive GH> fpage", or points to a "message" struct containing a valid "receive GH> fpage", and GH> - there is no error The second last bullet should read: - the receive descriptor either has the form of a valid "receive fpage" and the "m" bit is set, or points to a "message" struct containing a valid "receive fpage", and Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser(a)unsw.edu.au v http://www.cse.unsw.edu.au/~gernot PGP fingerprint: 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F

1 0

implementations of L4
by Edmund GRIMLEY EVANS 12 Mar '99

12 Mar '99

I've been trying to find out about existing implementations of L4. Perhaps people could correct or add to what I have discovered: * The original L4 by Jochen Liedtke. Written in assebler. For i486 and i586. NOT FREE and therefore utterly useless :-) * L4/MIPS from Australia. Written in assembler? GNU. * L4/Alpha from Dresden and Australia. Written in assembler? Not yet released but probably GNU? * Fiasco from Dresden. Written in C++, and designed for portabilty rather than efficiency, but only runs on i486 and i586 at present. GNU. * A version of L4 for x86 from Dresden written in C. I saw this mentioned in the list archive. Is it really separate from Fiasco? * L4/ARM in assembler. Unfinished? I saw this in the archive, too. If this list could be corrected and completed, could it be put on the L4 website, with links, as it must be what a lot of casual readers are interested in knowing? Edmund

2 1

486/Pentium version problems
by Edmund GRIMLEY EVANS 12 Mar '99

12 Mar '99

Following the instructions at os.inf.tu-dresden.de/fiasco/use.html I built Fiasco and the Hello World server worked. Excellent! Then I tried building L4-Linux and it didn't work ... Then I noticed that grub-ext2fs-floppy apparently already contains everything you need to run L4-Linux except for L4 itself. So I just copied the fiasco "main" that I had built onto the floppy image as supplied, hacked menu.lst a bit at random, and tried that. That didn't work either, but the thing that caught my attention was a message something like this: RMGR: L4/Pentium ... I was running this on a 486. So my questions are: Do the same executables (main, rmgr, sigma0, glinux.gz) run on both 486 and Pentium, or do different versions have to be built? If the latter, are the versions in grub-ext2fs-floppy supposed to work only on Pentium? If so, how can I build a version for 486 when compiling on a 686 machine? (And also, could the code be made to run on both? It would make life easier ...) Edmund

1 0

ADV: New Daul Mount Copy Holder
by remove＠1vm.com 24 Feb '99

24 Feb '99

Amazing new copy holder can be mounted directly on your computer monitor or it can be used freestanding. Unique design is specifically engineered to increase your efficiency while reducing eye strain, stress, and fatigue. Quality Rubbermaid features include adjustable viewing positions, non-glare surface, spring load paper clamp and detachable line guide. Folds flat for easy out-of-the-way storage. This isn't a cheap clip on, but a full platform copy holder. Special internet savings click here http://www.1vm.com/~rcc and save over $20 from comparable models. Sender: Robert Craig Corp. Phone: 1-800-890-7510 Email: robertcraigcorp(a)prodigy.net Details: http://www.1vm.com/~rcc Remove: REMOVE(a)1vm.com To be removed from future service notifications reply to: REMOVE(a)1vm.com

1 0

Big break!
by Ronald 24 Feb '99

24 Feb '99

Start your own 1-900 business! People are making $$$ week, after week in the 1-900 business. We'll teach you all of our "incredible secrets that will take your new exciting business to a whole new level! It's The Simplest and Most Exciting Business You Could Ever Start! *You'll use our "state" of the art equipment! *You'll use our "Live 1 on 1 Psychics" & "Chat Line" girls! *You'll use our incredible Date Line program(s)! No chargbacks! Quick payouts! No expertise needed! Complete programs start at only $99 (no additional charges) The only thing you'll have to do is advertise! This is an excellent turn key business. We also have excellent turn key programs if you want to own your own "top" of the line adult web site. ACT NOW!!! For a free color brochure: reply to: mailto:megagreen@usa.net?subject=brochure with the following information please: NAME:____________________________ ADDRESS:____________________________ CITY/STATE/ZIP:____________________________ PHONE:____________________________ (optional) remove at: mailto:xpoc@eudoramail.com?subject=remove

1 0

Re: L4 Mapping question
by Michael Hohmuth 23 Feb '99

23 Feb '99

"Adam 'WeirdArms' Wiggins" <awiggins(a)cse.unsw.edu.au> writes: > What TID does the kernel use for its ipc to Sigma0 to request > memory mapping for kernel usage. L4/x86 uses task 1, local thread 0, for communication with Sigma0. The Fiasco kernel doesn't do any IPC operations on behalf of itself -- so no thread id here. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: L4 Mapping question
by Michael Hohmuth 23 Feb '99

23 Feb '99

Robert Kaiser <rob(a)sysgo.de> writes: > I was aware that the bookkeeping would have to be in the kernel, otherwise > flush couldn't work as described in the manual. Only, how does it work ? > > Theoretically, each task could map each of it's pages to up to 2047 other > tasks. So, the kernel would need to maintain ~2K entries per mapped page > and task. This can't be! The only explanation I can think of right now > is that the kernel allocates room for entries dynamically, assuming that > the actual number of required entries will always be far less than > the theoretical limit. But that would mean you can break the system > simply by doing a big enough number of mappings. Each mapping of a physical page from virtual address VA1 in a task T1 to VA2 in T2 is kept track of using a kernel data structure called ``mapping entry.'' This data structure is allocated dynamically, but from a fixed-size pool (where the size can be specified at compile time or boot time). It's true that you can break the system by establishing an excessive number of mappings. There are several ways to deal with that, but I don't think any of them has been implemented in the freely-available research kernels; one way is detailed in Jochen Liedtke et al.'s paper ``Preventing Denial-of-Service Attacks on a µ-Kernel for WebOSes'' which is available from <URL:http://os.inf.tu-dresden.de/papers_ps/jochen/Denhot.ps>. > On Mon, 22 Feb 1999, Volkmar Uhlig wrote: > > In the current L4-implementation of Jochen Liedtke, one mapping entry is 16 > > Bytes.The Alpha implementation (done by me) needs 32 Bytes per entry (64 > > bit address space - and a lot of trix). The Fiasco kernel does not use > > lists. They need about 4 Bytes per entry + an some overhead per frame (I > > left bevore it was finished) > > I am getting the distinct feeling that I am missing something > very simple :-(. So, at the risk of looking like a complete fool: > How do you keep track of up to 2K tasks in a 16 Byte entry ? The 16-bytes structure is what I described as a ``mapping entry'' above. Mapping entries belonging to one physical page are linked to each other in a binary-tree structure using pointers. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: L4 Mapping question
by Michael Hohmuth 23 Feb '99

23 Feb '99

vuhlig(a)us.ibm.com writes: > The idea is, that the kernel can revoke pages from sigma 0, what is not > implemented yet. [...] I don't think it is a part of the Sigma0 specification that Sigma0 should be able to handle the case where the kernel revokes mappings of pages mapped into Sigma0. Instead, Sigma0 is pretty safe to assume that it magically owns---and has access to---all physically- addressable memory (maybe with the exception of the kernel-private code and data sections; the experts are still out on this one). Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: L4 Mapping question
by Michael Hohmuth 23 Feb '99

23 Feb '99

I wrote: > The resource manager Rmgr (which is normally used to startup L4/x86 > and Fiasco) handles the nitty-gritty details of telling the kernel > where it should find its Sigma0 server. In order to avoid any confusion: In a typical booting scenario on the x86, the Rmgr bootstrappig code runs even before the L4 or Fiasco kernel has been started. It is invoked directly by the boot loader and handles all initializations to be done before the kernel starts up: It finds the raw ELF binaries for the kernel and Sigma0 which the boot-loader has dropped in memory, interpretes them (i.e., moves them to their load addresses), configures the kernel (e.g., tells it the location of Sigma0 and Rmgr task entry points), and starts it. For more information, please read the Rmgr manpage at <URL:http://os.inf.tu-dresden.de/L4/l4libman/rmgr.html>. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

L4 Mapping question
by Robert Kaiser 23 Feb '99

23 Feb '99

Hi all, I have a question regarding mapping in L4: I read in the L4 reference manual that Sigma0 maps each page only once. It does allow multiple mappings of a page to the same address space (i.e. task), but it does not allow multiple mappings to different tasks. Is this a specific feature of Sigma0 or is this true of all pagers ? I'm asking because I wonder how the fpage_unmap operation works: If a task is allowed to map a page to an unlimited number of different tasks (i.e. 2047 as there are up to 2048 tasks), then the bookkeeping involved in implementing fpage_unmap would require that a pager would theoretically need to keep track of up to 2047 tasks per page in order to allow fpage_unmap to revoke all mappings of a particular page. That looks like a tremendous overhead, so there must either be some limit to the number of mappings or there is something else I'm missing. Could someone please enlighten me about this ? Thanks in advance Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO RTS GmbH Carl-Zeiss-Str. 41 phone: (49) 6131 9138-80 D-55129 Mainz / Germany fax: (49) 6131 9138-10

3 3

Re: L4 Mapping question
by Michael Hohmuth 23 Feb '99

23 Feb '99

"Adam 'WeirdArms' Wiggins" <awiggins(a)cse.unsw.edu.au> writes: > A related question here. Is there any particular reason/need for > sigma zero to be a once off pager? Why not have an inteligent resource > manager for sigma zero? In L4/x86 and Fiasco, this is easily possible. Sigma0 runs on user level and can be substituted at boot time with any program you like. The resource manager Rmgr (which is normally used to startup L4/x86 and Fiasco) handles the nitty-gritty details of telling the kernel where it should find its Sigma0 server. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

INCREASE YOUR PROFITS INSTANTLY!
by Shawn 23 Feb '99

23 Feb '99

***INCREASE YOUR PROFITS*** ACCEPT CREDIT CARDS FOR YOUR BUSINESS AND INCREASE YOUR PROFITS 30%-50%! *INTERNET *STOREFRONT *HOMEBASED OR *MAIL ORDER BUSINESS WE SPECIALIZE IN HELPING THE SMALL BUSINESS OWNER! IF YOU CALL IN THE NEXT FIVE DAYS, YOU WILL RECEIVE: NO APPLICATION FEE NO PROGRAMMING FEE CALL 1-888-264-9272 OUR BUSINESS HOURS ARE 9:00 A.M. TO 6:00 P.M. MST Remove at: mailto:mcau@hotbot.com?subject=remove

1 0

RE: L4 Mapping question
by vuhlig＠us.ibm.com 22 Feb '99

22 Feb '99

Hi Robert, the 5 mappings are on average (and configurable!). They are not assigned to one particular frame. I used the term frame in the context of available physical memory. you need some additional mapping entries for devices (like video frame buffer). The kernel must keep track of the mappings, because otherwise the pager can not revoke a page from an address space, where the page was indirectly mapped to. (e.g. A=pager mapps to B and maps to C, D, and E. Hereby, A is only aware of the mapping to B.) But the kernel concept allows to map any available/mapped memory from one address space to another. Volkmar Robert Kaiser <rob(a)sysgo.de> on 02/22/99 11:43:16 AM Please respond to Robert Kaiser <rob(a)sysgo.de> To: Volkmar Uhlig/Watson/IBM cc: Subject: RE: L4 Mapping question Hi Volkmar Thanks again for your response! On Mon, 22 Feb 1999 vuhlig(a)us.ibm.com wrote: > there is one mapping entry per associated page per address space. that > means, if you map a page to 2 address spaces you need 2 mappings. The > current L4 version allocates the mappings statically (currently 5 entries > per frame, but this is configurable at startup time). I seem to have a little difficulty with the term "frame". It may have to do with the fact that I don't have much of an Intel background (I'm developing mostly for MIPS machines). Does it mean something like "physical page" ? If so, that would mean that there is a hard (though configurable) limit of five address spaces that can share any given page. Is that correct ? > The idea is, that the kernel can revoke pages from sigma 0, what is not > implemented yet. I don't see the case, where you want to map a lot of pages > into all address spaces. The case I had in mind is shared memory between user tasks running on top of a -say- L4Linux server (and possibly being unaware that they are in a microkernel environment). I would not like the microkernel to impose a limit on the number of tasks that can share a given piece of memory. > Furthermore is your calculation not right. You can > map a page to multiple address spaces multiple times (at different virtual > addresses) - so there is no limit of needed mapping-entries per page. Oops, I hadn't thought of that! Would it be such a bad idea to move the bookkeeping for fpage_unmap out of the microkernel altogether? I mean, the pager has to do some bookkeeping anyway (like Sigma0 marks all pages once it maps them so it can refuse multiple mapping attempts). So, if the fpage_unmap syscall would just unmap a given fpage for a *single*, given address space and the pager would be responsible for making one fpage_unmap call for each task it has previously mapped the fpage to, then all bookkeeping would be in one place (i.e. the pager). This would simplify the microkernel, reduce it's memory footprint and leave the implementation details up to the user-space pager, which seems to me like the "microkernel way" of doing things. Of course, this would result in more system calls being made (thus more overhead), but I guess that in the usual cases (such as up to five tasks sharing a page) this should be negligible. I suppose there must be some other good reason why it wasn't done this way... Thanks again Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO RTS GmbH Carl-Zeiss-Str. 41 phone: (49) 6131 9138-80 D-55129 Mainz / Germany fax: (49) 6131 9138-10

2 1

RE: L4 Mapping question
by vuhlig＠us.ibm.com 22 Feb '99

22 Feb '99

Hi Robert, there is one mapping entry per associated page per address space. that means, if you map a page to 2 address spaces you need 2 mappings. The current L4 version allocates the mappings statically (currently 5 entries per frame, but this is configurable at startup time). The idea is, that the kernel can revoke pages from sigma 0, what is not implemented yet. I don't see the case, where you want to map a lot of pages into all address spaces. Furthermore is your calculation not right. You can map a page to multiple address spaces multiple times (at different virtual addresses) - so there is no limit of needed mapping-entries per page. Volkmar

1 0

RE: L4 Mapping question
by Robert Kaiser 22 Feb '99

22 Feb '99

Volkmar, Thanks very much for your response ! On Mon, 22 Feb 1999, Volkmar Uhlig wrote: > The bookkeeping is done by the kernel. this is necessary, because the > sender (e.g. pager) does not know, if the receiver of the page maps it to > other address spaces. Therefore the flush operation must be asynchronus. > Example: A is pager and maps a page to B. B maps it to C, D, E, and F. if A > flushes the page, it is removed from B, C, D, E and F. So, multiple mappings are in fact possible (that's what I wanted to know). I was aware that the bookkeeping would have to be in the kernel, otherwise flush couldn't work as described in the manual. Only, how does it work ? Theoretically, each task could map each of it's pages to up to 2047 other tasks. So, the kernel would need to maintain ~2K entries per mapped page and task. This can't be! The only explanation I can think of right now is that the kernel allocates room for entries dynamically, assuming that the actual number of required entries will always be far less than the theoretical limit. But that would mean you can break the system simply by doing a big enough number of mappings. > In the current L4-implementation of Jochen Liedtke, one mapping entry is 16 > Bytes.The Alpha implementation (done by me) needs 32 Bytes per entry (64 > bit address space - and a lot of trix). The Fiasco kernel does not use > lists. They need about 4 Bytes per entry + an some overhead per frame (I > left bevore it was finished) > I am getting the distinct feeling that I am missing something very simple :-(. So, at the risk of looking like a complete fool: How do you keep track of up to 2K tasks in a 16 Byte entry ? Thanks for your response Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO RTS GmbH Carl-Zeiss-Str. 41 phone: (49) 6131 9138-80 D-55129 Mainz / Germany fax: (49) 6131 9138-10

1 0

Re: Deceiving IPC question: Bug or Feature?
by Michael Hohmuth 03 Feb '99

03 Feb '99

gernot(a)cse.unsw.edu.au writes: > We have noticed the following re deceiving IPC in L4/MIPS. > > Assume task A is the chief of task B, which is the chief of task C. aa > is a thread in A, bb a thread in B, cc a thread in C. > > aa does a closed receive from bb. bb sends a deceiving message to aa > with cc as the virtual sender. aa receives the message (although the > virtual sender is different from the source specified in the > receive). The kernel returns to aa the virtual sender specified by bb > (i.e., cc), but the C bindings discard this information, so aa cannot > see it using the C interface. > > If in the otherwise identical situation aa does a closed receive from cc > it does NOT receive the message. > - is this the correct behaviour? I think this should be reversed: aa should receive the message in the second scenario, but not in the first. > - do all L4 versions show this behaviour? We never really used deceiving IPC with L4/x86 version 2 because it was broken, and I don't know about Jochen's version 3 or L4/Alpha. In Fiasco, deceiving IPC hasn't been implemented yet; it's not a priority for us right now. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Deceiving IPC question: Bug or Feature?
by gernot＠cse.unsw.edu.au 02 Feb '99

02 Feb '99

We have noticed the following re deceiving IPC in L4/MIPS. Assume task A is the chief of task B, which is the chief of task C. aa is a thread in A, bb a thread in B, cc a thread in C. aa does a closed receive from bb. bb sends a deceiving message to aa with cc as the virtual sender. aa receives the message (although the virtual sender is different from the source specified in the receive). The kernel returns to aa the virtual sender specified by bb (i.e., cc), but the C bindings discard this information, so aa cannot see it using the C interface. If in the otherwise identical situation aa does a closed receive from cc it does NOT receive the message. My questions: - do all L4 versions show this behaviour? - is this the correct behaviour? Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser(a)unsw.edu.au v http://www.cse.unsw.edu.au/~gernot PGP fingerprint = 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F

1 0

Re: Aiee: scheduling in interrupt (PR#9)
by Michael Hohmuth 29 Jan '99

29 Jan '99

> From: roux(a)ecoledoc.lip6.fr (Cedric ROUX) > Subject: some bugs > To: l4-hackers(a)os.inf.tu-dresden.de > Date: Fri, 11 Dec 1998 13:23:47 +0100 (MET) > > [...] > i could run koules with svgalib !! but, a program of mine don't > work. If someone could try it to see if it's my machine or what ? > available at : > http://www.ecoledoc.lip6.fr/~roux/demo/lost.tar.gz > and a binary is provided at : > http://www.ecoledoc.lip6.fr/~roux/demo/lost > If you could try it with a clean linux to see what should be > the correct behavior, then try it with fiasco. > It's just a poor animation with some sound (maybe sound is necessary for it > to behave bad, don't know). > When i run it under fiasco, it runs a little, then it blocks, so i press > ctrl+c, that nornmally should end up the program and give me back the > shell, but not, it just continues a little more, and stops again, and so on > until the end of the program. > Then i see a lot of "Aiee: scheduling in interrupt 00422ba (activ 10000)" > with sometimes a 0 in place of the 10000. > This works too with patch3, i don't have put patch4, but don't think > it is relevent. > And when i press Esc, it simply reboots. > > [...] What kind of sound driver did you use with L4Linux? Did you compile it into the L4Linux server, or did you use some kind of module? Please note that normal kernel modules for monolithic Linux cannot be used with L4Linux. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

RE: Aiee: scheduling in interrupt (PR#9)
by Sebastian Schoenberg 29 Jan '99

29 Jan '99

That means, you cannot take your binary compiled for your standard Linux, but you can take the source code without any changes and compile it for the L4Linux architecture. Sebastian -----Original Message----- From: Michael Hohmuth [SMTP:fiasco-bugs@os.inf.tu-dresden.de] Sent: Friday, January 29, 1999 4:41 PM To: roux(a)ecoledoc.lip6.fr Cc: l4-hackers(a)os.inf.tu-dresden.de Subject: Re: Aiee: scheduling in interrupt (PR#9) What kind of sound driver did you use with L4Linux? Did you compile it into the L4Linux server, or did you use some kind of module? Please note that normal kernel modules for monolithic Linux cannot be used with L4Linux. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Cash in on Superbowl Sunday!!
by z78c＠hotmail.com 29 Jan '99

29 Jan '99

Superbowl XXXIII - JANUARY 31, 1999 Dear Sports Fan, WIN BIG gives you the opportunity to make the game more exiting and profitable, with our online sportsbook. You can make a friendly wager on the SUPERBOWL or any other pro sporting event. Or play our many interactive casino games that come with our free sopftware package. Visa Mastercard and American Express accepted and for a limited time we are offering a complimentary 10% of your initial deposit added to your account upon sign-up ! Please visit our website for more info: http://204.71.176.71/members6/game-online Please contact interrupt(a)hotmail.com if you have recieved this message in error. Thank you, and happy gaming!

1 0

Re: gcc VS g++
by Michael Hohmuth 27 Jan '99

27 Jan '99

"Paul Phillips" <pphillips(a)ivue.com> writes: > FYI gcc is version 2.7.2.3 > g++ is egcs-2.90.29 980515 (egcs-1.0.3 release) > The GNU manual simple says that gcc uses 'C' linkage and g++ calls gcc and > uses C++ linkage. I don't thoroughly understand what might be meant with ``linkage'' here, but I don't think that linkage is a problem unless you combine modules compiled with different compilers. I have successfully used Fiasco kernels compiled with the `gcc' driver from Gcc 2.7.2.3, so certainly its ``linkage'' is alright. One possible other reason for this problem is that you might be trying to compile Fiasco without optimization ("-O" flag). For Gcc 2.7.2.3 I know for sure that this doesn't work: Optimization must be enabled to allow inline-assembler code to work; if it's not, the compiler skips the register-conflict-detection pass which makes sure arguments for inline-assembler code are put into the correct CPU registers. Maybe this has been corrected in Egcs (I haven't tried). > I won't try to solve this problem right now as g++ seems to work OK. Your > makefile uses gcc however, and I am wondering which I should be using. The Makefile shipped with the distribution should be using `egcc', a driver which belongs to Egcs, so it should be using Egcs 1.0 or 1.1. I recommend using a version of Egcs if you have access to it; Egcs 1.1 is best. > One of your correspondence mentions a version of egcs, and I'm not > sure of the relationships between gcc and egcs. Gcc and Egcs are two different compiler distributions which both include a C compiler and a C++ compiler. Normally, only one of the distributions is installed on one system; the front ends (driver programs) `gcc' and `g++' access the same compiler distribution, and one can compile both C and C++ source files with both drivers. However, newer Linux distributions confusingly come with both Gcc and Egcs, and both distributions contain both the C compiler and the C++ compiler. The driver program `gcc' is made to access Gcc, while `g++' and `egcc' use Egcs. As I said, all of these drivers can compile C code and C++ code, but they access different compiler distributions. The reason why both Egcs and Gcc are installed is that the Linux-2.0 kernel cannot be compiled with compilers newer than Gcc 2.7.2.x for political reasons (Linus Torvalds and the Egcs team like to blame and yell at each other for that). However, supplying only this old version of Gcc is unsatisfying because the newer C++ compilers offer more features and are more standards-compliant. Does this clear up some confusion? Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: multiple servers
by Michael Hohmuth 27 Jan '99

27 Jan '99

"Paul Phillips" <pphillips(a)ivue.com> writes: > I believe I have found a couple of bugs in Fiasco which were causing the > multiple server problem, and probably some other problems. In > /fiasco/src/time.h : > the code for set( microseconds): >From the first impression, your fix looks right. Thanks for tracking this down! I still wonder why I haven't ever seen this problem... I think I tried booting L4Linux and `hello' concurrently, but maybe the order in which they're started makes a difference. I almost can't believe that I wrote that routine... :-) It must have been late at night. I probably didn't invest much thought into it because I was thinking I was going to rewrite it soon. The timeout handling also suffers from at least two other problems: It disables interrupts while traversing a linear linked list of unknown length, that is, potentially for an unacceptably long time; and it suffers from the ``page fault may re-enable interrupts'' problem because it potentially touches a TCB in a 4-MB kernel region for which a reference to its shared page table hasn't yet been inserted into the current task's page directory (this is done ``on demand'' in the page fault handler). This is just one more example why doing kernel synchronization using interrupt-disabling is a bad idea. [ from a different email ] > >Why did you relocate it to 0x2400000? It should be able to run (even > >concurrently with L4Linux) at the memory location it is linked to > >using the distributed version of l4/server/hello/Makefile, 0x200000. > I thought perhaps GRUB was trying to load both 'hello' and L4Linux at the > same physical address and that was the reasoning behind my relocating it. It > makes no difference. GRUB is never trying to load boot modules to conflicting memory addresses; the modules (in this case, ELF binaries) are not interpreted at all---GRUB just locates them linearly behind what has been loaded as the ``kernel,'' which in our case is Rmgr, the resource and boot manager. Once it has been started by GRUB, Rmgr interprets the ELF binaries and loads them to their destination addresses. Rmgr makes sure these addresses don't conflict---otherwise you will see an ugly (and not very informative, I'm afraid) assertion failure. Thanks again! Michael [ code included for reference so that the bug tracking system sees it, too ] > inline void > timeout_t::set(unsigned long long abs_microsec) > { > // XXX uses cli/sti > > _wakeup = abs_microsec; > _flags.set = 1; > > unsigned flags = get_eflags(); > cli(); > > if (!timer::first_timeout) > { > timer::first_timeout = this; > _prev = _next = 0; > } > else > { > timeout_t *ti = timer::first_timeout; > > for (;;) > { > if (ti->_wakeup >= _wakeup) > { > // insert before ti > _next = ti; > _prev = ti->_prev; > ti->_prev = this; > if (_prev) _prev->_next = this; > /***** here you need to set timer::first_timeout since you just replaced it > */ > else timer::first_timeout = this; > /**********/ > goto done; > } > > if (ti->_next) > { > ti = ti->_next; > continue; > } > /**** here you need to put a break in case ti->wakeup < timeout, > and and ti->_next==0 . > Otherwise you loop here with interrupts disabled forever */ > else break; > /********************/ > } > > // insert as last item after ti > ti->_next = this; > _prev = ti; > _next = 0; > } > > done: > set_eflags(flags); > } -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0