- l4-hackers - OS Site

Fiasco Status
by COFFMAN Steven 15 Jun '01

15 Jun '01

Sorry if this was mentioned previously, but the status page for Fiasco (October 2000) mentions that Fiasco still doesn't have Flex I/O pages. Is this still the case with CVS? -Steve

2 1

Questions: porting, L4Linux status and performance.
by Martin Young 13 Jun '01

13 Jun '01

Hi Folks, I've had a look around the L4 web site and I've got a few questions... I'm interested in putting L4 on a 'new' processor core (although strictly as an unofficial spare-time activity). I have experience of porting Chorus to two different cores and I've done various other mk-related stuff so I wouldn't be going in entirely cold. Is there a recommended route for doing this? I suppose that I could either write a new implementation from scratch or port an existing one. L4Ka looks quite attactive as it already exists for more than one platform and it's available under the GPL. OTOH the L4/x86 reference manual is so short that a new implementation doesn't look too daunting. Would anybody like to guess how long either route would take? I'm also wondering how stable L4Linux (particularly the 2.2.x kernel version) actually is. I see on the mailing list that some simple commands can crash the kernel, but is this typical? I don't want to run anything large like a RH distribution but a stable kernel+bash would be great. If I were to write or port an L4 MK I expect that initial versions wouldn't be well optimised for my CPU architecture. In this situation how would it's performace compare to (for example) mach? Does L4's performane advantage come from optimisation of the implementation or from its architecture? The literature suggests the latter however I note that many L4 implementations are written in assembler and that there are performance concerns about Hazelnut. Thanks. -- Martin Young, working for: | Phone: +44(0) 1454 615151 Siroyan Limited, Bristol Design Centre, | Mobile: +44(0) 7855 758771 West Point Court, Great Park Road, | web: www.siroyan.com Bradley Stoke, Bristol BS32 4QG. UK | email: my(a)siroyan.com ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************

1 0

Re: Multiple linux servers
by Michael Hohmuth 20 Apr '01

20 Apr '01

"Vincent Legoll" <vlegoll(a)apsydev.com> writes: > Just a simple question : have you ever tried to launch multiple > copies of the linux server on the same l4 kernel ? No. Currently, L4Linux depends on standard Linux device drivers that run inside the L4Linux server task, and you cannot run two sets of drivers for the same hardware on a single machine. If you would have the two server instances use different devices and interrupts, or if you would externalize drivers (let them run in their own tasks) and make them shareable, there should be nothing in general that prevents two L4Linux servers on the same machine. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Multiple linux servers
by Vincent Legoll 19 Apr '01

19 Apr '01

Hello, Just a simple question : have you ever tried to launch multiple copies of the linux server on the same l4 kernel ? -- Vince

1 0

SMP L4 released for Alpha
by Gernot Heiser 11 Apr '01

11 Apr '01

A version of L4 for Alpha processors has been released in source form under the GNU GPL. The kernel is provides full, scalable and low-overhead support for SMP systems. It has been tested on 21064, 21164 and dual CPU 21264 systems. This is the first release of a multiprocessor version of L4, and the second 64-bit version (after MIPS, also from UNSW). The source is available from http://l4alpha.sourceforge.net. We hope that this release will stimulate external interest (and participation) in L4 development and use. UNSW Operating Systems Group disy(a)cse.unsw.edu.au http://www.cse.unsw.edu.au/~disy/

1 0

RE: l4-Linux and gasp
by Sebastian Schoenberg 27 Mar '01

27 Mar '01

The gasp .align directive should be written directly to the outfile. The warning is misleading, since some gas-versions (for alpha) use .align x as alignment to the power of two, other use the value given as argument. Sebastian --- PLEASE USE PGP !! http://os.inf.tu-dresden.de/~schoenbg/pgp-key.asc Dipl.-Inform. Sebastian Schoenberg University of Technology, Dresden Dept. of Computer Science Operating Systems Research Group Phone: +49 (351) 463 8401 Fax: +49 (351) 463 8284 > -----Original Message----- > From: Christian Stueble [mailto:stueble@cs.uni-sb.de] > Sent: Tuesday, March 27, 2001 3:11 PM > To: l4-hackers(a)kurt.inf.tu-dresden.de > Subject: l4-Linux and gasp > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hello, > > due to problems with L4Linux/Fiasco I noticed that gasp > reports the warning: > > l4_idle.pre:1836 alignment must be one of 1, 2 or 4. > l4_idle.pre:1988 alignment must be one of 1, 2 or 4. > > when compiling l4_idle.pre. Could this cause trouble? > I use gcc 2.95.2, gasp 1.2 and as 2.9.5 > > Chris > - -- > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Christian Stueble......................stueble(a)cs.uni-sb.de > PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A > > To be or not to be is true... (apocrypha of George Boole) > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 5.0i for non-commercial use > MessageID: uLWl6hG54Oh3oORs/VtBb5H+uikJFgkW > > iQCVAwUBOsCRefyJjJy/cQT1AQFTdgP+PdRya487EahMX7KzDYa/JQmLLT9gguJP > vQpd6sU6GpxmWpPr7bg4pNTN4L1QNj9WVCX6/IqW/2fJZKyeGMTfZiITLt6efnGm > PnZFH8RcOith2iROi8nyprSzv1GULEqJyrr1D7kQxVUodYmA3sxON4ToSxRi/AiU > 3k1XOab1N+o= > =MeHo > -----END PGP SIGNATURE----- > _______________________________________________ > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers >

1 0

l4-Linux and gasp
by Christian Stueble 27 Mar '01

27 Mar '01

-----BEGIN PGP SIGNED MESSAGE----- Hello, due to problems with L4Linux/Fiasco I noticed that gasp reports the warning: l4_idle.pre:1836 alignment must be one of 1, 2 or 4. l4_idle.pre:1988 alignment must be one of 1, 2 or 4. when compiling l4_idle.pre. Could this cause trouble? I use gcc 2.95.2, gasp 1.2 and as 2.9.5 Chris - -- - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble......................stueble(a)cs.uni-sb.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: uLWl6hG54Oh3oORs/VtBb5H+uikJFgkW iQCVAwUBOsCRefyJjJy/cQT1AQFTdgP+PdRya487EahMX7KzDYa/JQmLLT9gguJP vQpd6sU6GpxmWpPr7bg4pNTN4L1QNj9WVCX6/IqW/2fJZKyeGMTfZiITLt6efnGm PnZFH8RcOith2iROi8nyprSzv1GULEqJyrr1D7kQxVUodYmA3sxON4ToSxRi/AiU 3k1XOab1N+o= =MeHo -----END PGP SIGNATURE-----

1 0

Little bug in L4-Linux?
by Christian Stueble 21 Feb '01

21 Feb '01

-----BEGIN PGP SIGNED MESSAGE----- Hello, When I compile linux22, I get the follwing error message in linux22/arch/l4/x86/emulib: ------------------------- ld -m elf_i386 -N -Ttext 0xa0008000 -o emulib int_entry.o user.o ld: warning: cannot find entry symbol _start; defaulting to a0008000 cp emulib emulib-s strip emulib-s ld -m elf_i386 -r \ -defsym _user_task_init=0x`nm emulib | grep user_task_init | cut -f1 -d' '` \ -defsym user_level_pager=0x`nm emulib | grep user_level_pager | cut -f1 -d' '` \ -defsym emulib_start=0x`nm emulib | grep -w real_sys_call | cut -f1 -d' '` \ -defsym emulib_end=0x`nm emulib | grep [_L]etext | cut -f1 -d' '` \ -defsym idt_table=0x`nm emulib | grep -w idt_table | cut -f1 -d' '` \ -defsym debug_idt_table=0x`nm emulib | grep -w debug_idt_table | cut -f1 -d' '` \ -defsym emulib_idt_descr=0x`nm emulib | grep emulib_idt_descr | cut -f1 -d' '` \ -defsym emulib_debug_idt_descr=0x`nm emulib | grep emulib_debug_idt_descr | cut -f1 -d' '` \ -T link-r.ld -o emulib.o emulib-s ld: cannot open a00087c2: Datei oder Verzeichnis nicht gefunden ------------------------- The problem seems to be the command "nm emulib | grep [_L]etext | cut -f1 ..." which returns two lines instead of one: ------------- a00087c2 a00087c2 ------------- Replacing "[_L]etext" by "_etext" works fine... Is this a bug or a feature? Ciao, Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble......................stueble(a)cs.uni-sb.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

2 1

Problems compiling CVS Version 02/20/2001
by Christian Stueble 20 Feb '01

20 Feb '01

-----BEGIN PGP SIGNED MESSAGE----- Hello, I tried to compile the l4 CVS version from today, but I have some oskit/oskit10 problems: 1) l4/Makeconf seems to add oskit10 includes even if OSKIT10 is not set. Maybe the line "ifeq ($(OSKIT10),) " is wrong? 2) When I fixed that, l4/pkg/log/lib/src/doprnt.c produces an error, because oskit/boolean.h is not there. Do you mean flux/boolean.h, or should oskit10 be used instead of oskit? 3) I also tried to use oskit10, which produces errors in oskit_support and some services because of missing headers, e.g., lmm/lmm.h or flux/machine/pc/reset.h Some files seem to require oskit and some oskit10?? Ciao, Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble......................stueble(a)cs.uni-sb.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

2 1

do i need oskit for working with L4?
by Subbaraj, Thirumurugan 22 Jan '01

22 Jan '01

Hello, I have downloaded the GRUB and OSkit. How do i load the kernel/build the image with L4? Any suggestions? regards -thiru

1 0

problem starting the hello server
by Christian Rehn 11 Jan '01

11 Jan '01

Hi, I,ve got a problem starting the hello server on top of fiasco. I checked out l4-fiasco from the cvs repository and compiled it. My menu.lst looks as follows: kernel=(nd)/boot/tftpboot/rehn/rmgr -sigma0 module=(nd)/boot/tftpboot/rehn/main -nojdb module=(nd)/boot/tftpboot/rehn/sigma0 module=(nd)/boot/tftpboot/rehn/hello When I try to boot l4 rmgr starts, loads the l4 kernel and the sigma0 server but does not load the hello server (I'm not sure if it is loaded but not executed or if it is not loaded but I can not find the code that should load the hello server). Where should the hello server be loaded? Why does the rmgr "exec_load" main and the sigma0 server but not the hello server in function startup() in startup.c? Thanks, Christian

1 0

IPC
by Jordan Curzon 03 Jan '01

03 Jan '01

Hello, What is the most common way for apps(or libs) to find the task id for a service(networking for example)? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

L4 benchmarks
by Greg Law 12 Dec '00

12 Dec '00

Hi, I would like to get some benchmarks for L4 on Pentium. Specifically, I am after the times to create a process and execute a getpid (preferably in cycles). Does anyone know where I can get such info before I try and go through the pain of measuring it myself? Cheers, Greg -- Greg Law, email: gel(a)soi.city.ac.uk Dept. Of Computing, web: http://www.soi.city.ac.uk/~gel/ City University, phone: +44 20 7477 8341 London, UK. EC1V 0HB. fax: +44 20 7477 8587

1 0

Missing files in recent cvs versions
by David Welch 16 Nov '00

16 Nov '00

Hi, Some of the Makefiles in fiasco want to use Makeconf.lib.targets and Makeconf.lib.rules which don't seem to be in the cvs repository. Also the Fiasco bug tracking link gives a 404.

2 2

Ideas for some sample L4 root_task(s) [Learning L4].
by Farid Hajji 25 Oct '00

25 Oct '00

Hi Brent, this is what I'm planning to do next to get used to the L4-Ka interface. If you are interested, let's do this together. Basically it's about exercising misc. L4 syscalls in the root_task itself. Once we understand this, we can grab libmom and add L4 sysdeps to glibc and the Hurd. 01. map from sigma0 the kernel info page into the address space of the root_task. printf() its contents, especially its 'clock' field which is updated by the ukernel. sleep some useconds and printf clock again. [-> learn more about sigma0 rpc protocol, how to send/receive a message to/from sigma0, some memory managment issues in general and l4_sleep(). ] 02. activate some threads in root_task, and let each thread continouusly putc() a unique identifying character to the screen. look at the resulting pattern. A control thread could getc() chars from keyboard and use this char to start/stop the thread that prints this char. [-> learn about threads and scheduling.] Add a pager to a thread which just printf()s each page request, before forwarding it to sigma0. Alternatively, trap the request and handle it by mapping an own page to the requester. Finally, reclaim pages that are not needed anymore (how? and how to get notified about this condition?). [-> learn about pagers and the L4 application/pager protocol.] 03. create new (child) tasks and: * map/grant some pages * send/receive messages: short message, long message, with and without string dopes etc.. * synchronize threads via blocking l4-receive syscalls. [-> learn about messages, ipc calls.] 04. understand what rmgr really does, what its interfaces to the root_task and other tasks are (a.k.a. how to request/receive ressources from rmgr) and try to implement Okuji's idea about relocation of modules (glinux) so that we can boot glinux with vanilla GNU Grub (no modaddr). 05. Attach a root_task thread to one interrupt number (say com1, clock, keyboard or whatever) and printf/acknowledge each received interrupt. [-> Handling interrupts. Is it possible to get an interrupt that is already bound by rmgr? Hmmm... ] [-> What about chaining interrupts/events? ] Write a trivial device driver server (like sorta translator), e.g. a clock device, that gets clock interrupts and reads the clock page in the kernel to update its internal notion of time. Add protocol so that other threads/tasks can ask the time via RPC (simple message) from this clock server. [-> generalize this to device driver servers in general. Think about a Hurd abstraction to access such servers. Driver-Translators? Driver-IPC? ] 06. Grab the code of a real device driver from OSKit and try to turn it into a device driver server as in 05. 07. [...] Real world examples are located in RMGR source code, and in the sources of L4-Fiasco apps and L4Linux. I'll continue to use L4Ka right now though, simply because I can compile it without problems on my FreeBSD box ;-). Any suggestions? -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: 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 20 Oct '00

20 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

Trying L4ka under Bochs/FreeBSD (the saga continues...).
by Farid Hajji 15 Oct '00

15 Oct '00

Hi, [Kevin: please have a look at the bochs panic below: What's wrong with writing non-zero to CR4 when --enable-cpu-level=5 is mentioned? Is there a quick workaround to this problem? Thanks.] I'm trying to run l4ka under bochs but I'm still fighting with some bochs panic()s. This is what I've found out so far: 1. 3 modules _must_ be attached to rmgr, so that the assertion in startup() about the number of modules doesn't bite. 2. I used the following grub startup commands thru all following tests (bochs simulates disk C: from a 112M bytes regular file): grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> kernel (hd0,0)/l4ka/rmgr.debug -sigma0 [Multiboot-elf, <0x111000:0x20734:0x0>, <0x132740:0x48c:0xfcc8>, entry=0x111000] grub> module (hd0,0)/l4ka/x86-kernel [Multiboot-module @ 0x143000, 0x12769 bytes] grub> module (hd0,0)/l4ka/sigma0 [Multiboot-module @ 0x156000, 0x287a bytes] grub> module (hd0,0)/l4ka/glinux [Multiboot-module @ 0x159000, 0x143dd4 bytes] grub> boot rmgr.debug is just original rmgr binary, with another name. I tried to slightly modify rmgr in later steps... rmgr[.debug], x86-kernel and sigma0 were compiled on FreeBSD without problems. Note: compiled for 586, not 686!. They are not stripped. I was not able to compile linux22 from Dresden on FreeBSD, so I just used the binary 'glinux' from your distribution. 3. Without any modifications to the l4-ka sources, bochs panic()s right after displaying the message: check_l4_version 0x00100000 to 0x0011041c with the following error message: MOV_RdCd: read of CR4 MOV_CdRd: ignoring write to CR4 of 0x00000010 bochs: panic, MOV_CdRd: (CR4) write of 0x00000010 protected mode CS.d_b = 32 bit SS.d_b = 32 bit | EAX=00000010 EBX=ff000000 ECX=0010f40f EDX=0010a000 | ESP=0010f3f7 EBP=00109000 ESI=f0109000 EDI=00109000 | IOPL=0 NV UP DI PL NZ NA PO NC | SEG selector base limit G D | SEG sltr(index|ti|rpl) base limit G D | DS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | ES:0010( 0002| 0| 0) 00000000 000fffff 1 1 | FS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | GS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | SS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1 | EIP=0010fa55 (0010fa52) >> 77875018 0f77875018 2277875018 e077875018 : mov CR4, EAX bochs was not able to grok the instruction: mov CR4, EAX (that is EAX -> CR4). I compiled bochs-2000_0325a with the following options: ./configure --enable-cpu-level=5 \ --enable-disasm --enable-vga --enable-fpu \ --enable-x86-debugger Support for x86-debugger (DR? registers etc...) is therefore enabled. Looking at the source code of bochs-2000_0325a, file cpu/proc_ctrl.cc says in function void BX_CPU_C::MOV_CdRd(BxInstruction_t *i): [...] 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; [...] So bochs doesn't allow writing 0x00000010 (non-zero) to CR4 for now. To Kevin: Why? To Uwe: Can we avoid having to write to CR4 for now? 4. I tried to localize the exact position of that instruction in l4-ka by adding the following MYDEBUG macro to halt execution before bochs panic()s: #ifndef MYDEBUG #define MYDEBUG(str) { printf(str); for(;;) ; } #endif this helped to track down at least portions of the code that were definitely executed by bochs, as well as to see the output. This is what I've found out so far: 4.1. control definitely reaches the end of l4-ka/apps/rmgr/src/startup.c:startup(), at least just before the final: asm volatile ("pushl $" SYMBOL_NAME_STR(exit)"\n" "pushl %2\n" "ret\n" : /* no output */ : "a" (MULTIBOOT_VALID), "b" (&l4_mbi), "r" (exec_info.entry)); /*NORETURN*/ This is the output in bochs: RMGR: loading (hd0,0)/l4ka/sigma0 check_l4_version 0x00100000 to 0x0011041c RMGR: detected L4-Karlsruhe find kernel info page... found kernel info page at 0x00107000 configuring s0: (0x00200000, 0x00213000), start: 0x00200000 s0 config: 0x00200000,0x00000000,0x00200000,0x00213000 RMGR: reserve modules memory range: 156000 to 29cdd4 RMGR: starting (hd0,0)/l4ka/x86-kernel @ 0x0010f000 >>>> rmgr.debug:startup() just before asm volatile... at end of function. 4.2. control doesn't reach even the very beginning of l4-ka/apps/rmgr/src/init.c:init() where I've put the next MYDEBUG call. bochs panic()s with the same error message as before (ignoring write to CR4 of 0x00000010: mov CR4, EAX). Uwe, where does startup() exactly jumps to? I thought it was rmgr's init()??? 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

Real-time Fiasco
by kargahi 11 Oct '00

11 Oct '00

Hi L4 Hackers Would you please say me why Fiasco is a real-time u-kernel & what are the real-time properties of Fiasco? 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. Thanks.

1 0

Task generation & Fiasco scheduler
by kargahi 18 Sep '00

18 Sep '00

Hi L4 hackers I am trying to write some servers on the L4 MK but i have two problems, please guide me with enough details and simple examples. my problems are here : 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. 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. thanks so much M. KARGAHI

1 0

Compiling L4 on FreeBSD (Part 2)
by Farid Hajji 15 Sep '00

15 Sep '00

Hi Michael, I tried again to compile l4 and I'm a step further: cd l4 mkdir include/l4/log cd include/l4/log ln -s ../../../pkg/log/include/l4/log/l4log.h . Now, gmake bombs with gmake[4]: Entering directory `/tmp/l4-devel/l4/pkg/l4util/examples/perf' gmake[4]: *** No rule to make target `main.ld', needed by `perf_p6'. Stop. How can a main.ld be generated? The two other main.ld I've found: ./pkg/log/server/src/main.ld ./pkg/names/server/src/main.ld were quite old (nov 1999) and certainly not generated by gmake! I'm still suspecting an incomplete l4 distribution, probably due to CVS. Trying to compile oskit10, I'm also missing files (I already told you this). I generated a oskit10/modules.x86.pc manually by putting the name of each subdirectory of oskit10 by itself on a line. Using gcc-2.95.2, configure resumes but misses the following files: sed: ./unsupported/scripts/sym-trace.in: No such file or directory sed: ./boot/GNUmakefile.in: No such file or directory sed: ./examples/GNUmakefile.in: No such file or directory sed: ./freebsd/GNUmakefile.in: No such file or directory sed: ./fs/GNUmakefile.in: No such file or directory sed: ./fsnamespace/GNUmakefile.in: No such file or directory sed: ./linux/GNUmakefile.in: No such file or directory sed: ./netbsd/GNUmakefile.in: No such file or directory sed: ./posix/GNUmakefile.in: No such file or directory sed: ./video/GNUmakefile.in: No such file or directory sed: ./wimp/GNUmakefile.in: No such file or directory sed: ./x11/GNUmakefile.in: No such file or directory Here again, I'm suspecting an incomplete distribution due to cvs problems. Thank you, -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.

2 3

CVS Server broken? + compiling L4 on FreeBSD
by Farid Hajji 14 Sep '00

14 Sep '00

Hi Michael, I already asked this on l4-hackers, but I didn't get any replies (yet): -------- begin forwarded message ----------- begin forwarded message -------- 1. I'm missing some files, like e.g. in l4 module the file pkg/log/lib/include/l4/liblog.h (among others). [oskit10 is missing _a lot_ of files too, not only .html's] 2. In l4-hackers archive http://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/msg00399.html Michael refers to an additional "log" package. This is fine, but this package (included in l4) doesn't include liblog.h (cvs server says: nothing known about pkg/log/lib/include/l4/liblog.h) --------- end forwarded message ------------ end forwarded message -------- I did a complete "checkout l4" again in a fresh directory today, but the problem remained (the same with cvs update -d). One guess may be that the files are not present in the repository or that they have wrong permissions. Could you please check that the cvs server is running correctly (at least for l4 and oskit10)? I'm trying to compile l4 on a FreeBSD machine. I was able to compile oskit (_not_ oskit10) with gcc-2.7.2.3 and binutils-2.9.1 without problems (gcc-2.95.2 couldn't grok some asm directives because of forbidden use of certain x86 regs) except for the usual warnings. Compiling l4 with gcc-2.95.2 and binutils-2.9.1 went well, up to the point where liblog.h is required. I was not able to proceed any further at this point (liblog.h was not present either in l4-990428.tar.gz). BTW, I had to modify l4/Makeconf slightly, so that the native gcc(-2.95.2) of FreeBSD be used instead of the cross-compiler i486-linux-gcc. This is the modified part of l4/Makeconf: ifdef CROSS CPPFLAGS+= -DCROSS ifeq ($(SYSTEM),Linux) SYSTEM_TARGET= FLOPPY=/dev/fd0 else ifeq ($(SYSTEM),FreeBSD) SYSTEM_TARGET= FLOPPY=/dev/rfd0.1440 else SYSTEM_TARGET=i386-linux- endif endif endif I also tried to compile oskit10, but to no avail. Probably due to the missing files problem reported earlier (I'm not sure though...), even oskit10/configure bombed at a very early stage with the following error message: checking if compiler groks __attribute__((packed)) on structs... yes checking if compiler groks __attribute__((pure))... yes checking if compiler groks __attribute__((noreturn))... yes checking if compiler groks __attribute__((constructor))... yes configure: error: OSKit modules file ./modules.x86.pc was not found. It didn't matter wether I used gcc-2.95.2 or gcc-2.7.2.3: env CC=gcc27 MAKE=gmake ./configure env CC=gcc MAKE=gmake ./configure This is my compile environment: gcc -v Using builtin specs. gcc version 2.95.2 19991024 (release) gcc27 -v Reading specs from /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/2.7.2.3/specs gcc version 2.7.2.3 as -v GNU assembler version 2.9.1 (i386-unknown-freebsdelf), using BFD version 2.9.1 ld -v GNU ld version 2.9.1 (with BFD 2.9.1) gmake -v GNU Make version 3.79, by Richard Stallman and Roland McGrath. Built for i386--freebsd5.0 uname -rs FreeBSD 5.0-20000506-CURRENT Please help! 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

CVS server problems?
by Farid Hajji 12 Sep '00

12 Sep '00

Hi, is the CVS server currently broken? 1. I'm missing some files, like e.g. in l4 module the file pkg/log/lib/include/l4/liblog.h (among others). [oskit10 is missing _a lot_ of files too] 2. In l4-hackers archive http://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/msg00399.html Michael refers to an additional "log" package. This is fine, but this package (included in l4) doesn't include liblog.h (cvs server says: nothing known about pkg/log/lib/include/l4/liblog.h) 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: How to run Linux 2.2
by Jean Wolter 09 Aug '00

09 Aug '00

Fabio Riccardi <fabio.riccardi(a)free.fr> writes: > Hi, > > I have downloaded the last CVS sources of fiasco, oskit and linux. > > I managed to get fiasco + oskit (old and new version, all example > applications) to run, and I have succesfully recompiled Linux 2.2. I can > even boot Linux, but as soon as it frees the unused kernel memory I get > an infinite sequence of messages like this: > > root: rcvd 4bb5bc, 4bb5bc, src: a.0 > unknown request from a.0 > root: rcvd 4bb5bc, 4bb5bc, src: a.0 > unknown request from a.0 > root: rcvd 4bb5bc, 4bb5bc, src: a.0 > unknown request from a.0 > etc... This is a bug in L4Linux. It took a while to figure out what happens since the bug only happens if you say no to "Use flat clan structure". The following fix will correct this: Index: l4_pager.c =================================================================== RCS file: /home/cvs/linux22/arch/l4/x86/lib/l4_pager.c,v retrieving revision 1.2 retrieving revision 1.4 diff -u -r1.2 -r1.4 --- l4_pager.c 2000/05/12 12:29:48 1.2 +++ l4_pager.c 2000/08/09 12:58:23 1.4 @@ -77,6 +77,7 @@ ping_pong_id = template_id; ping_pong_id.id.task = n; + ping_pong_id.id.lthread = 0; pager.id.lthread = LTHREAD_NO_ROOT_PAGER; 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

How to run Linux 2.2
by Fabio Riccardi 07 Aug '00

07 Aug '00

Hi, I have downloaded the last CVS sources of fiasco, oskit and linux. I managed to get fiasco + oskit (old and new version, all example applications) to run, and I have succesfully recompiled Linux 2.2. I can even boot Linux, but as soon as it frees the unused kernel memory I get an infinite sequence of messages like this: root: rcvd 4bb5bc, 4bb5bc, src: a.0 unknown request from a.0 root: rcvd 4bb5bc, 4bb5bc, src: a.0 unknown request from a.0 root: rcvd 4bb5bc, 4bb5bc, src: a.0 unknown request from a.0 etc... Do I have to configure the rmgr in a special way? I found a configuration file on the diskette image, but it doesn't work either... What am I doing wrong? Thank you very much in advance for your help, ciao, - Fabio

1 0

Sigma0 bug?
by Christian Stueble 25 Jul '00

25 Jul '00

-----BEGIN PGP SIGNED MESSAGE----- Hello again, Last week I had some problems using fiasco on a 196 MB machine. Suzuki told me to modify l4/pkg/rmgr/server/src/memmap.h, but this does not help. (I set MEM_MAX to 256MB and the RMGR told me: "WARNING: All memory above 256 is wasted", on a 196MB machine!!). I noticed that sigma0 also defines MEM_MAX, and after setting it to 256MB, too, it works now. But, isn't it wrong that sigma0 returns memory pages up to RMGR's MEM_MAX value, even if only 196MB are available? Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble......................stueble(a)cs.uni-sb.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: wEaiE9zGKl756mb1+UDwYiIm1DkcNdUa iQCVAwUBOX2vsfyJjJy/cQT1AQGyxQQArkMBqWKaIOditHQIuoh+so+7mL0GK3i7 uPYdvQ5Ys6QDw12xhR1zhtPBA1KZcg4DE5CHzqiTY4RfKMx9X5wovIOVu1thujUv Z1OyvqjNTbCwinOoijq+yH53W7hz3aNA+ljbuJ8JghQE5lbFlHjJMkl5aFLwX93u knN6nHmSqPA= =e4UE -----END PGP SIGNATURE-----

1 0

L4 and grub difficulties
by James Riordan 20 Jul '00

20 Jul '00

I have been trying to launch L4 (Fiasco) and the hello server from a version of grub other than that supplied on the grub-ext2fs-floppy.gz image. When I take grub from the gnu server, it compiles but when I boot I get hung at: 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 4 2000 SIGMA0: Hello! RMGR: Hi there! RMGR running on L4/Pentium (hang) When I take grub from the CVS server at Dresen, I fail in compilation: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../stage1 -Wall -Wmissing-prototypes -Wunused -Os -fno-builtin -nostdinc -DFSYS_EXT2FS=1 -DFSYS_FAT=1 -DFSYS_FFS=1 -DFSYS_MINIX=1 -g -c -o pre_stage2_exec-asm.o asm.S /tmp/cc0xSXW3.s: Assembler messages: /tmp/cc0xSXW3.s:1189: Error: operands given don't match any known 386 instruction /tmp/cc0xSXW3.s:2109: Error: operands given don't match any known 386 instruction this is using the latest versions of gcc and binutils (to the best of my knowledge) montepulciano 502 # gcc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) montepulciano 503 # as --version GNU assembler 2.9.5 Might anybody have any advice on how to proceed? Thanks, james -- Dr. James Riordan email: rij(a)zurich.ibm.com IBM Forschungslaboratorium notes: James Riordan/Zurich/IBM Säumerstrasse 4 Tel +41 (0) 1 724 89 81 CH-8803 Rüschlikon, Switzerland Fax +41 (0) 1 724 89 53

4 9

L4-Linux bug
by Christian Stueble 20 Jul '00

20 Jul '00

-----BEGIN PGP SIGNED MESSAGE----- Hello, the file linux22/kernel/setup.c includes the "../arch/l4-i386/include/fake_interrupt.h" but I think it should include <l4linux/fake_interrupt.h>. Right? Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble......................stueble(a)cs.uni-sb.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: uFwTpm7e3g3EJ1l+XzVtymp/RbDe9Usn iQCVAwUBOXQZ2/yJjJy/cQT1AQHkZAQArm3523HYKSy3RbLiBFygHXyiC9PIDN8J O7jHy6edu+xotsW531deas8aWPKSakumU5UeHqGDi8FLNAsvvLj9k1nHivpq0F55 sfGmrJFaLDsWYneinB29qFJYnmWy1YkH2CymVFuzRnMPxN8IWEZwD1hkH9bQdjCo eDc/W9iNelI= =UdXf -----END PGP SIGNATURE-----

2 1

Re: L4Linux hangs on boot
by Jean Wolter 19 Jul '00

19 Jul '00

James Riordan <rij(a)zurich.ibm.com> writes: > Continuing to try to get L4Linux to boot, I run into the problem that > it cannot open an initial console: > > Partition check: > hda: hda1 hda2 hda3 hda4 > hdb: hdb1 hdb2 hdb3 > VFS: Mounted root (ext2 filesystem) readonly. > Freeing unused kernel memory: 36k freed > Warning: unable to open an initial console > > and then goes into an infinite loop of: > > Might anybody have any pointers or suggestions of what to try? Can you send me an image of your boot disk (or if you boot over the network a tar file containing all your binaries)? I would like to try to reproduce the problem here. 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

2 1

L4Linux hangs on boot
by James Riordan 19 Jul '00

19 Jul '00

Continuing to try to get L4Linux to boot, I run into the problem that it cannot open an initial console: Partition check: hda: hda1 hda2 hda3 hda4 hdb: hdb1 hdb2 hdb3 VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 36k freed Warning: unable to open an initial console and then goes into an infinite loop of: root: rcvd 4772a0, 4772a0, src: a.0 unknown request from a.0 root: rcvd 4772a0, 4772a0, src: a.0 unknown request from a.0 Actually this is the message of what happens under vmware; when I run natively, it seems to be the same but the messages go by too quickly to read. Might anybody have any pointers or suggestions of what to try? BTW: The build is from the modules "grub l4 linux22 oskit10" from the CVS server on 11 Jul 200. james -- Dr. James Riordan email: rij(a)zurich.ibm.com IBM Forschungslaboratorium notes: James Riordan/Zurich/IBM Säumerstrasse 4 Tel +41 (0) 1 724 89 81 CH-8803 Rüschlikon, Switzerland Fax +41 (0) 1 724 89 53

1 0

RH6.2 and Fiasco
by James Riordan 13 Jul '00

13 Jul '00

I'm still not having a great deal getting Fiasco + hello running. I opted for the slash and burn technique and reinstalled RedHat 6.2, downloaded fresh from the cvs server (10 July 2000) and tried to build from there. The only snag that I hit that I was not sure about was when compiling oskit10, the file oskit10/freebsd/src/lib/libc/i386/gen/alloca.S did not want to compile. There was, however, a comment in oskit mailing list suggesting that a fix ("jmp %edx " changes to "jmp *%edx"). I've appended a script at the end of this mail that make the other small changes that I needed to build. 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? james -- Dr. James Riordan email: rij(a)zurich.ibm.com IBM Forschungslaboratorium notes: James Riordan/Zurich/IBM Säumerstrasse 4 Tel +41 (0) 1 724 89 81 CH-8803 Rüschlikon, Switzerland Fax +41 (0) 1 724 89 53 O / ----------- X Cut Here ----------------------------------------------- O \ #!/bin/bash -nolineediting # # This is a build script for the Fiasco distribution on a generic RedHat 6.2 platform # James Riordan (rij(a)zurich.ibm.com) # # easier to see in color but "alias comment=echo" will also work #function comment () {echo "[01;34m"$*" [0m"} alias comment=echo function backup () { if [ ! -f $1.orig ]; then cp $1{,.orig}; fi } BUILD_ROOT=$PWD export L4_DIR=${BUILD_ROOT}/l4 if [ -d grub -a -d l4 -a -d oskit -a -d oskit10 ]; then comment all directories found else comment you seem to be in the wrong directory exit -1 fi comment making oskit cd oskit ./configure comment edit oskit/flux/config.h to get rid of HAVE_CODE16 if [ ! -f flux/config.h.orig ]; then cp flux/config.h flux/config.h.orig; fi cat << EOF | ed flux/config.h 1 /CODE16 d w q EOF make # making oskit comment making oskit10 cd $BUILD_ROOT/oskit10 ./configure comment edit oskit/config.h to get rid of HAVE_CODE16 backup oskit/config.h cat << EOF | ed oskit/config.h 1 /CODE16 d w q EOF comment edit Makeconf to get rid of have_code16 backup Makeconf cat << EOF | ed Makeconf 1 /code16 s/have_code16// w q EOF comment removing in2000 from oskit/dev/linux_scsi.h backup oskit/dev/linux_scsi.h cat << EOF | ed oskit/dev/linux_scsi.h 1 /in2000 d w q EOF comment changing freebsd/src/lib/libc/i386/gen/alloca.S backup freebsd/src/lib/libc/i386/gen/alloca.S cat << EOF | ed freebsd/src/lib/libc/i386/gen/alloca.S 1 /jmp s/%/*%/ w q EOF make exit comment making fiasco cd $BUILD_ROOT/l4 comment killing pkg/names/man/Makefile as we do not have sdc backup pkg/names/man/Makefile echo all: > pkg/names/man/Makefile comment killing pkg/l4util/examples/perf/Makefile comment as we do not need it and it does not work backup pkg/l4util/examples/perf/Makefile echo all: > pkg/l4util/examples/perf/Makefile comment change egcc to gcc in kernel/fiasco/src/Makefile backup kernel/fiasco/src/Makefile cat << EOF | ed kernel/fiasco/src/Makefile 1 /egcc /CC s/egcc/gcc w q EOF comment create dependency files I am not sure how they are supposed comment to be created but this seems to work cat > Makedeps <<EOF ifeq (\${L4_DIR},) L4DIR = ../../.. else L4DIR = \${L4_DIR} endif ifeq (\${OSKIT_DIR},) OSKITDIR = \$(L4DIR)/../oskit else OSKITDIR = \${OSKIT_DIR} endif include \$(L4DIR)/Makeconf EOF allow_null_glob_expansion=t pushd kernel/fiasco/src/ /bin/rm .*.d for file in *.cc *.c *.S *.cpp; do CC=gcc make -f ${L4_DIR}/Makedeps .$file.d; done popd make pushd pkg/log make popd make

2 1

Re: L4 and grub difficulties
by Lars Reuther 12 Jul '00

12 Jul '00

Christian Stueble <stueble(a)cs.uni-sb.de> writes: > Another question: > I think oskit10 is required now to compile the pkg package, but some > subdirectories also use oskit/flux/c/*.h include files. Do I really need both > oskit versions or should the makefiles be modified to use oskit10/oskit/c/*.h? Which packages? All packages available in our remote CVS should still use the old OSKit (version 0.6), except the Fiasco kernel. We are currently working on a support package for the latest OSKit, but aren't finished yet. Lars -- Dipl.-Inf. Lars Reuther Dresden University of Technology Department of Computer Science Operating Systems Research Group Phone: +49 (351) 463-8401 Fax: +49 (351) 463-8284 Email: reuther(a)os.inf.tu-dresden.de

1 0

Re: Problems compiling Fiasco (OSKIT)
by Pete Buechler 07 Jul '00

07 Jul '00

On Fri, 07 Jul 2000, Christian Stueble wrote: > I had the same problems. Use an older compiler. The > gcc-2.7.2.3 works for me. To compile Fiasco, > use e.g. egcs-2.91.60. I used egcs-2.91.66 for Fiasco and gcc-2.7.2.3 for oskit. Then I had to follow the directions by Edmund GRIMLEY EVANS <edmundo(a)rano.org> - remove HAVE_CODE16 from oskit/config.h - remove have_code16 from Makeconf - remove in2000 from oskit/dev/linux_scsi.h Then I had all kinds of path problems in the Makefiles, having to search for various paths and add them to the include files, plus moving header files around. And when the dust all settled, Fiasco came up and printed some stuff, but the hello server never managed to print hello to my screen. -- Pete Buechler : SuSE Linux Developer Work e-mail : peterb(a)suse.com Work web page : http://www.suse.com/~peterb Personal e-mail : peter.buechler(a)home.com

1 0

Adapting L4 to automake
by Juho Östman 09 Jun '00

09 Jun '00

I think it would be useful to adapt L4 building system to GNU automake and autoconf as I have written earlier. I have now done preliminary modification to the source tree and I'd like to know how should I continue. I already have a source tree which builds the Fiasco kernel, rmgr, sigma0 and hello server using automake generated Makefiles. There is also a lot of need of finishing up. For example it doesn't create distribution packages completely using 'make dist'. The source tree package was so large that I didn't want to post it to this mailing list but I could send it anyone who is willing to look at it.

2 1

build problems
by Edmund GRIMLEY EVANS 23 May '00

23 May '00

I've just spent some time trying to build Fiasco from the CVS source. (1) It would be nice if the build instructions and FAQ could be put with the source in CVS for the benefit of people who have to dial up. (2) The build instructions don't tell you to build oskit10 first. (3) I found I needed gcc-2.7.2.3 to build oskit10, and I had to make the following changes to make it compile: - remove HAVE_CODE16 from oskit/config.h - remove have_code16 from Makeconf - remove in2000 from oskit/dev/linux_scsi.h Which assember are other people using to build this? I'm using: GNU assembler version 2.9.5 (i386-linux) using BFD version 2.9.5.0.37 (4) I used egcs-1.1.1 to build l4, and had a series of makefile problems which might be very easy for someone else to fix. A complete log of the errors I got and how I worked around them is given below. (5) The build instructions then tell you to cd to kernel/fiasco/src and make again, but this was already done by make in l4/. (I'll tell you about my run-time problems when I try it ...) Edmund make[4]: *** No rule to make target `../../../../include/l4/log/l4log.h', needed by `.p6.c.d'. Stop. make[4]: Leaving directory `/home/ege/aferoj/l4-cvs/l4/pkg/l4util/examples/perf' $ mkdir include/l4/log ; cp -i pkg/log/include/l4/log/l4log.h include/l4/log ld -N -Ttext 0x430000 -o perf_p6 p6.o crt0.o -L../../../../lib -L../../../../../oskit/lib -L/home/drops/lib -llog -ll4util -lpci -lmc -lnames -loskit_support -lkern -lmc -lrmgr -llmm ld: cannot find -llog make[4]: *** [perf_p6] Error 1 make[4]: Leaving directory `/home/ege/aferoj/l4-cvs/l4/pkg/l4util/examples/perf' $ ( cd lib ; ln -s ../pkg/log/lib/src/liblogserver.a ../pkg/log/lib/src/liblog.a .) ld -N -Ttext 0x430000 -o perf_p6 p6.o crt0.o -L../../../../lib -L../../../../../oskit/lib -L/home/drops/lib -llog -ll4util -lpci -lmc -lnames -loskit_support -lkern -lmc -lrmgr -llmm ld: cannot find -lpci make[4]: *** [perf_p6] Error 1 make[4]: Leaving directory `/home/ege/aferoj/l4-cvs/l4/pkg/l4util/examples/perf' $ touch pkg/l4util/examples/perf/perf_p6 # It finishes building now, but we don't have perf_p6, so: $ rm pkg/l4util/examples/perf/perf_p6 ld -N -Ttext 0x430000 -o perf_p6 p6.o crt0.o -L../../../../lib -L../../../../../oskit/lib -L/home/drops/lib -llog -ll4util -lpci -lmc -lnames -loskit_support -lkern -lmc -lrmgr -llmm ld: cannot find -lpci make[4]: *** [perf_p6] Error 1 make[4]: Leaving directory `/home/ege/aferoj/l4-cvs/l4/pkg/l4util/examples/perf' # cd to that directory and do the link without -lpci # now everything is built, I think

2 2

building linux22
by Edmund GRIMLEY EVANS 22 May '00

22 May '00

And could someone please tell me what symbolic links I should create to build linux22? I assume that's what missing after I did cvs update -d. In particular, what should linux22/include/asm point at, and where should linux22/include/asm-l4/param.h find <asm/l4arch/param.h>? Edmund

2 1

Re: l4/log/l4log.h
by Michael Hohmuth 20 May '00

20 May '00

Juho Östman <jostman(a)myrealbox.com> writes: > It seems that the file 'l4log.h' is missing in the CVS distribution. > Where is it found? I have added the "log" package to the CVS distribution. (We recently introduced a dependency on the "log" package in the code we distribute; I think there even are some cross dependencies between packages... the easy fix for now just seems to be distributing the "log" package as well. :-) Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

l4/log/l4log.h
by Juho Östman 15 May '00

15 May '00

It seems that the file 'l4log.h' is missing in the CVS distribution. Where is it found?

1 0

Re: Plaese .. Could you help me ?
by Michael Hohmuth 14 Apr '00

14 Apr '00

Ricky, Jean just went into his well-deserved weekend, but he told me to tell you that he has tried your boot disk, and has been able to reproduce your problem. He got it to run by replacing your Fiasco binary with a newer version of Fiasco. So you are probably using an outdated version of the kernel. You should download a newer version from our remote-CVS server (see <URL:http://os.inf.tu-dresden.de/drops/download.html for instructions). Michael Jean Wolter <jean.wolter(a)inf.tu-dresden.de> writes: > "Ricky(Soohyung) Lee" <onlyjazz(a)cselab.snu.ac.kr> writes: > > > But, I have another problem. > > When I boot from the grub floppy disk with glinux.gz on it, > > after the message that is saying the first task is created, > > the kernel fall into the endless loop with printing out " root: rcvd > > b9002, 4bc10c, src :5.3 ". > > Would it be possible to gzip the boot disk and send it to us? Then we > could try to boot it and see, what fails. > > I´m not quite sure that I understand the scenario good enough to come > up with an explanation and a fix. Somehow the service thread (5.3) > touches a page in the adapter area (a0000-100000) and doesn´t get or > doesn´t have a mapping for it. > > Jean -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: Plaese .. Could you help me ?
by Jean Wolter 14 Apr '00

14 Apr '00

"Ricky(Soohyung) Lee" <onlyjazz(a)cselab.snu.ac.kr> writes: > But, I have another problem. > When I boot from the grub floppy disk with glinux.gz on it, > after the message that is saying the first task is created, > the kernel fall into the endless loop with printing out " root: rcvd > b9002, 4bc10c, src :5.3 ". Would it be possible to gzip the boot disk and send it to us? Then we could try to boot it and see, what fails. I´m not quite sure that I understand the scenario good enough to come up with an explanation and a fix. Somehow the service thread (5.3) touches a page in the adapter area (a0000-100000) and doesn´t get or doesn´t have a mapping for it. 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

Plaese .. Could you help me ?
by Ricky(Soohyung) Lee 14 Apr '00

14 Apr '00

Hi, everyone ! First of all, let me introduce myself . My name is Ricky Lee . I'm in the course of master's degree at Seoul National University in Korea. Thesedays I'm reading L4-related papers. And, I'm trying to make experience on L4Linux on Fiasco. But, It is not so easy for me. Today, I finally succeeded in building linux22. I really appreciate Michael Hohmuth' advices. But, I have another problem. When I boot from the grub floppy disk with glinux.gz on it, after the message that is saying the first task is created, the kernel fall into the endless loop with printing out " root: rcvd b9002, 4bc10c, src :5.3 ". I guess that it is printed out from root_pager() in l4_paper.c Can you tell me what's wrong ? And, then, what should I do? I really need to solve this problem. So, I really need your help. Please, Help me .. Thanks for your kindness . Thanks . P.S. I compiled Fiasco and Linux22 server on the Redhat package 5.2. Its kernel version is 2.0.36. Any software requirement that is mentioned in the L4linux homepage was met, I think . Can there be the reason of problem with the linux environment in which I compiled those sources ? Can anyone tell me the kernel version and H/W spec. on which you've built the L4Linux22 Server ? It'll be very helpful to me if you tell me them .. Please !!! Thank you very much !! - Ricky Lee -

1 0

IPC & invalid Thread-ID
by Christian Stueble 04 Mar '00

04 Mar '00

-----BEGIN PGP SIGNED MESSAGE----- Hello, what happens if IPC uses an invalid thread-id? Is the message although forwarded to the subsystem's chief? Ciao, Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: J7gRC3CpAZgh3vXKJpAlEFSfZz45w/ET iQCVAwUBOL5y5fyJjJy/cQT1AQFaywQAhBB4KcN8eHZXMrAPgrvJyQhbEMoRYc6j Wmpt5tBK3Tu1DmcNtTqlcGChzFIDrUiE6+Iw8eN74Bx2Dn+Cn+ohcUmSeaxEjkNl 2F8rTA/13dm/4wojmRz87uAvHWuFx+PycsXm7P3BRRqb+9aC+O1ftau6bNSqsmXC 8A/QvdUxDQg= =PFys -----END PGP SIGNATURE-----

2 3

autoconf
by Juho Östman 28 Feb '00

28 Feb '00

What do you think about adapting L4 (and Fiasco) to use autoconf? The most important immediate benefits are the possibility of using a separate build directory and configuration options. And it would be more compatible with GNU build mechanisms. If you think that is a good idea I could be voluntary to make necessary changes.

1 0

What happened to AIM?
by Gernot Heiser 21 Feb '00

21 Feb '00

Does anyone know what happened to AIM Technology? Their website, www.aim.com, seems to have vanished from the face of the earth. Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5533 \_,--._* Sydney, Australia 2052 E-mail: gernot(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

A few things I'd like to ask
by Juho �stman 04 Feb '00

04 Feb '00

I have become quite familar with L4/x86 Reference manual and L4 User manual (for MIPS) but I think they don't give enough information about designing and writing programs on to the L4 architecture. In my opinion they are a bit unclear and incomplete. Therefore I'd like to ask some questions on that subject. What kind of address space do the initial servers get? I know that sigma0 has the complete physical address space idempotently mapped but what about others? What pages do they have initially mapped? I have understood that the kernel isn't able to free memory it has allocated. Is that true? How is the destination address of an intercepted IPC delivered to the chief? What is sigma1? What should it do? Is sigma0 able to map memory above 0x40000000? How? What happens when the version numbers of a task are used up? Could they be reused? Could tasks donate interrupts like they can donate task numbers? Thanks for everyone who bothers to answer.

4 4

Re: Protected mode I/O driver architecture (Fiasco)
by Michael Hohmuth 28 Jan '00

28 Jan '00

John Nagle <nagle(a)animats.com> writes: > Once I/O flexpages are in, RMGR will be able to issue access to > device space byte by byte. That's right. > It can connect up interrupts to drivers now. Small correction: L4 currently has no interface for safely passing an interrupt assignment. All Rmgr can do when a driver asks for an interrupt is release its attachment so that the driver can attach. This opens a time window for a malicious process racing with the driver to steal the attachment. > The remaining big security problem is DMA. Of course, DMA will be restricted to processes having access to the ports controlling the DMA controller. > In most systems, device drivers are given total access to DMA > controllers. Could that be avoided, with a trusted process that > handles the DMA controllers at the request of the device drivers? > > I'm going to concentrate on PCI bus issues, since ISA is > on the way out and SCSI, USB, and IEEE-1394 devices usually work > through a PCI controller. > > For most devices, DMA is performed by DMA controllers in the > core chipset (such as the Intel 82810), not by the peripherals > themselves. It's seems to be possible to disable the ability of a > PCI device to become a bus master without disabling the ability > of the DMA controllers to execute memory and PCI bus cycles, > at least with the more modern core chipsets. > > So it ought to be possible to have a trusted process that > handles DMA and deals with the memory mapping issues. This > process would be used by device drivers that need DMA. Drivers > would not have access to the DMA controllers directly and would > be untrusted. Yes, all that is correct. A different solution would be to simply trust device drivers also. > There's the related issue of hardware discovery, or > "plug and play". Something is needed at startup to discover > all the hardware, build the hardware tree, and parcel out > hardware resources to drivers. What's planned in that area? We plan to do all this in a device-managing component. As a start, Uwe Dannowski already has added some enhancements to Rmgr that discovers PCI devices and remaps their memory-mapped I/O ports so that only one device has ports in a given high-memory superpage, enabling access control to memory-mapped I/O ports for device drivers. However, I think his changes are currently not available publicly. :( Other than that, not much has been done so far in this area. All drivers currently contain their own PCI-device-discovery code. > Is this consistent with the thinking of the L4/Fiasco/Drops > groups? If not, is there something wrong here? I think you ate pretty much inline with our thinking. Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Satellite Owners! Must See!
by VWUrkI01t＠please.org 27 Jan '00

27 Jan '00

THIS IS A ONE TIME MAILING You were sent this email because it was believed it would benefit you in some way If you do not want this email - simply delete it - TEST YOUR SATELLITE CHANNELS - DO THEY WORK? TEST THEM AND SEE Your satellite receiver - if you have Direct Tv - came with a little credit card sized programming card known as a smart card. We can, for testing purposes only, program your card to receive any and all channels offered by your satellite company without you having to pay an additional monthly fee. You will receive blacked out sporting events, pay per views, premium channels and unlimited, unrestricted access to ANY channel offered by your satellite company after we program your card. We can only program H cards. These are the cards that say "DSS ACCESS CARD" on them and they are blue. We can NOT program Dish Network cards. This service is provided for testing purposes only. To receive an order form and for more informaton - Please Call 1-770-621-5852 (24hours a day, 7 days a week).

1 0

Re: CVS server
by Michael Hohmuth 26 Jan '00

26 Jan '00

David Welch <david.welch(a)st-edmund-hall.oxford.ac.uk> writes: > The cvs server at os.inf.tu-dresden.de seems to be down, is this a > temporary problem, or has cvs access been moved or removed? Temporary problem -- sorry for the downtime. It's back up now. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Protected mode I/O driver architecture (Fiasco)
by John Nagle 26 Jan '00

26 Jan '00

A key concept of L4 is that device drivers should be outside the kernel, and not have privileges that allow them to crash the system. This requires support outside the kernel that isn't yet present. I'm writing this to ask some questions about how that will be architected. Once I/O flexpages are in, RMGR will be able to issue access to device space byte by byte. It can connect up interrupts to drivers now. The remaining big security problem is DMA. In most systems, device drivers are given total access to DMA controllers. Could that be avoided, with a trusted process that handles the DMA controllers at the request of the device drivers? I'm going to concentrate on PCI bus issues, since ISA is on the way out and SCSI, USB, and IEEE-1394 devices usually work through a PCI controller. For most devices, DMA is performed by DMA controllers in the core chipset (such as the Intel 82810), not by the peripherals themselves. It's seems to be possible to disable the ability of a PCI device to become a bus master without disabling the ability of the DMA controllers to execute memory and PCI bus cycles, at least with the more modern core chipsets. So it ought to be possible to have a trusted process that handles DMA and deals with the memory mapping issues. This process would be used by device drivers that need DMA. Drivers would not have access to the DMA controllers directly and would be untrusted. There's the related issue of hardware discovery, or "plug and play". Something is needed at startup to discover all the hardware, build the hardware tree, and parcel out hardware resources to drivers. What's planned in that area? Is this consistent with the thinking of the L4/Fiasco/Drops groups? If not, is there something wrong here? John Nagle Animats www.animats.com

1 0

CVS server
by David Welch 20 Jan '00

20 Jan '00

Hi, The cvs server at os.inf.tu-dresden.de seems to be down, is this a temporary problem, or has cvs access been moved or removed? Thanks, David Welch

1 0

main blocks forever (revisited)
by Kermit the Frog 14 Jan '00

14 Jan '00

Hello, after aplying a patch sent by Jean (thanks Jean!) everything seemed to work just fine. Except for one thing. After restarting the stopped thread, with l4_thread_ex_regs, if main() would try to do a getchar() (for instance) the re-started thread would stop ... if I change the getchar() for a for(;;); everyting works just fine. And theres one more thing, please if someone can tell me if this behaviuor is correct or not, when stopping a thread w/l4_thread_ex_regs lets say we stop it by changing its eip to a func. always_release() { for(;;) l4_thread_switch(L4_NIL_ID); } If one were to leave the original esp, when re-starting the original thread, by changing its eip to the original func., all the values contained in the stack were to be clobbered ... now ... is this normal ? should l4_thread_switch() change the values in the stack ? (of course, a workaround to this is to declare a char release_stack[] and use it when stopping the thread as its new stack). Ciao. Cervi~no Ulises <kermit(a)tower.com.ar> <ulises(a)rosario.linux.org.ar> ............................................................................... "Contrary to popular opinion, Unix is user friendly, It just happens to be very selective about who it makes friends with."

1 0

Unknown error
by Christian Stueble 13 Jan '00

13 Jan '00

-----BEGIN PGP SIGNED MESSAGE----- Hello, I hope someone can tell me why the following source produces an error (trapno 14, error 5): ------------------------------------ class BaseClass { public: virtual void print() { printf("BaseClass::print()\n"); }; }; class DerivedClass : public BaseClass { public: virtual void print() { printf("DerivedClass::print()\n"); }; }; DerivedClass dc; void main(void) { BaseClass *bc = &dc; bc->print(); } ---------------------- If dc is defined inside main(), everything works fine. Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: Mqyve75goky7Nb6fefYC/Sh3qq9PuiJi Comment: iQCVAwUBOH3OA/yJjJy/cQT1AQEzOQQAut8lc3ns0EgZiQc80OgiKjlgnLv9g4Np bOdvfgxqspDkUqV6j/D/w0I1tJc3QAwLh8EsF4t6K27dd3yqJN2JVEnvud/7wNGh as2+1S1gqhV6k6dttkY5rfPy+epp/e8ZM5jmhFiS0H/HG+F6Vq+wTAm1f3DnWpoX a1mRhzHjZ+g= =fR1c -----END PGP SIGNATURE-----

2 1

Inside L4
by Gernot Heiser 11 Jan '00

11 Jan '00

A first version of a document entitled "Inside L4/MIPS" containing annotated L4 source code is available from http://www.cse.unsw.edu.au/~disy/L4/index.html. It is still incomplete, so far covering kernel data structures, exception handling and IPC. Any feedback/suggestions/corrections/additions are highly appreciated. Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5533 \_,--._* Sydney, Australia 2052 E-mail: gernot(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

main blocks forever
by Kermit the Frog 11 Jan '00

11 Jan '00

Hello, I have the following scenario were everything goes just wrong. I have only one task running, which creates a thread using l4_thread_ex_regs ... after a 4 secs. sleep using l4_ipc_receive it changes the eip value of the thread to a piece of code that reads: void always_release() { for(;;) l4_thread_switch(L4_NIL_ID); } After doing this the main thread (# 0) tries to wait 4 secs. using l4_ipc_receive again and then change the eip of the created thread to its old eip. The problem is that the main thread never wakes up. I mean, after the 4 secs. have passed ... the main thread is still blocked. Are we in prescence of a bug ? Cheers. Cervi~no Ulises <kermit(a)tower.com.ar> <ulises(a)rosario.linux.org.ar> ............................................................................... "Contrary to popular opinion, Unix is user friendly, It just happens to be very selective about who it makes friends with."

1 0

Re: Its me again :-)
by Jean Wolter 29 Dec '99

29 Dec '99

Kermit the Frog <kermit(a)tower.com.ar> writes: > > Hello, > lets see if I have this thing right. > > Lets say that main() creates a thread that will act as a scheduler. We'll > call it sched. Now main() creates antoher thread that will have sched as > its scheduler. sche() enters an infinite loop with a l4_i386_ipc_wait in > it. Of course, it waits for an preemption RPC message. Currently external and internal preempters are not implemented. They may be released in a future version but I'm not sure about 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

Its me again :-)
by Kermit the Frog 24 Dec '99

24 Dec '99

Hello, lets see if I have this thing right. Lets say that main() creates a thread that will act as a scheduler. We'll call it sched. Now main() creates antoher thread that will have sched as its scheduler. sche() enters an infinite loop with a l4_i386_ipc_wait in it. Of course, it waits for an preemption RPC message. Now, when creating the second thread (lets call it task) with l4_thread_ex_regs, I put sched to be its preempter, anyway, sched() never gets the IPC and task() runs as if it never had any preempter asociated. Theres another thing, if inside main we put l4_thread_ex_regs to change task()'s eip and esp to (dword_t) -1 (this would likely stop task()) nothing happens, task() just runs normally. Any ideas ?? Cheers. PS: I didnt send any source code because its kind of long and I dont want to bother people w/unsolicited mail ;-), if anyone wants it please email me and ill be happy to send it Cervi~no Ulises <kermit(a)tower.com.ar> <ulises(a)rosario.linux.org.ar> ............................................................................... "Contrary to popular opinion, Unix is user friendly, It just happens to be very selective about who it makes friends with."

1 0

requesting mappings from sigma0
by Kermit the Frog 22 Dec '99

22 Dec '99

Hello, Ive been having some problems while trying to request a page from sigma0. I have included the source code ... any help ? many thanks! ------[ source begins here ]------ #include <l4/types.h> #include <l4/syscalls.h> #include <l4/ipc.h> #include <stdio.h> #define SIGMA0_ID 4 void main(void) { l4_threadid_t sigma0; l4_msgdope_t msg, result; dword_t addr, type, foo, *r_add; addr = 0x80000; type = L4_IPC_SHORT_MSG; sigma0.id.task = SIGMA0_ID; sigma0.id.lthread = 0; r_add = 0x0; while(r_add == 0x0) { addr += 4096; /* pasamos a la siguiente pagina de 4K */ printf("Vamos a pedir la region de memoria 0x%x\n", addr); l4_i386_ipc_send(sigma0,(void *) type, addr, addr, L4_IPC_NEVER, &result); printf("ipc enviado ..."); l4_i386_ipc_receive(sigma0, L4_IPC_MAPMSG(addr, 4096), r_add, &foo, L4_IPC_NEVER, &result); printf("%p recivido\n", r_add); } *r_add = 'a'; r_add++; *r_add = 0x7; r_add --; if(*r_add == 'a') printf("BINGO!\n"); printf("Done!\n"); } Cervi~no Ulises <kermit(a)tower.com.ar> <ulises(a)rosario.linux.org.ar> ............................................................................... "Contrary to popular opinion, Unix is user friendly, It just happens to be very selective about who it makes friends with."

1 1

Fiasco & oskit10
by Christian Stueble 21 Dec '99

21 Dec '99

Is it possible to compile fiasco based on oskit10? I think there are some files missing (flux/*/*)?? When compiling l4/pkg/oskit_support/lib/src/ I get an error message: --- ... Making rmgr_stubs.o {standard input}: Assembler messages: {standard input}: Error: Symbol 'rmgr_pager_id' can not be both weak and common --- If I remove '__attribute__ ((weak))' it works. Is this a bug? I use egcs-2.91.66. -Chris- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

2 1

Using g++ to compile hello?
by Christian Stueble 21 Nov '99

21 Nov '99

Hi! Is it possible to compile the test program ŽhelloŽ using the g++ compiler. I get an error message 1) main.cpp:37: undefined reference to `__throw' ...if I link main.o and crt0.o with the ld linker, and 2) crt0.o(.text+0x0): multiple definition of `_start' /usr/lib/crt1.o(.text+0x0): first defined here ...if I try to link the files with g++ -o xxxx. Can somebody help me? Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 1

Apologies for mispost
by Gernot Heiser 18 Nov '99

18 Nov '99

My last two messages were not meant for l4-hackerßos.inf.tu-dresden.de, but for one of our internal lists. Apologies, 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: gernot(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: L4 Workshop papers
by Gernot Heiser 18 Nov '99

18 Nov '99

------- Blind-Carbon-Copy From: Gernot Heiser <gernot(a)cse.unsw.edu.au> To: jaegert(a)us.ibm.com cc: Liedtke(a)ira.uka.de, Haertig(a)os.inf.tu-dresden.de, hohmuth(a)innocent.com Subject: Re: L4 Workshop papers In-reply-to: Your message of "Thu, 18 Nov 1999 10:03:10 CDT." <8525682D.0052B697.00(a)D51MTA03.pok.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: "Gernot Heiser" <gernot> Date: Fri, 19 Nov 1999 08:04:33 +1100 Sender: gernot(a)zuse.disy.cse.unsw.EDU.AU Thanks, Trent. I really have material for a number of talks, but don't see how I can find the time to write up anything before the 1st (and the students are studying for their exams). Topics: - - StrongARM kernel - - API extensions for SMP scheduling and cacheability - - SMP Alpha kernel - - supporting multiple page sizes - - portable VM implementation? Another problem is that I still haven't got a return flight. I may have to get a business class flight (which means paying the difference out of my own pocket) to be able to make it. 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: gernot(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 ------- End of Blind-Carbon-Copy

1 0

Re: RMGR-Extension to control I/O access
by Michael Hohmuth 22 Oct '99

22 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > > That is exactly what io flex pages are designed for. Initially sigma0 > > has access to all io ports and can use io flex pages to grant port > > access to other task. If sigma0 grants access a subset of the io > > address space (adressses which are accessed by in/out instructions) > > the task gets an io permission bitmap. If sigma0 (or someone else) > > grants access to the whole io address space l4 changes the iopl so > > that any thread in this task can access any port and can even disable > > interrupts. > I understand the x86 manual in that way: i/o access is permitted only if the > tasks CPL <= IOPL _and_ if appropriated bits are set to 0. No, that´s ``or,´´ not ``and.´´ > Generally, only two new IPC messages (to the RMGR or sigma0?) are > necessary: Rmgr > 1) demandPort( port_nr, size ) > 2) releasePort( port_nr, size ) Yes, that´s right. > Does someone know, why the l4 reference manual restricts the granularity of > port access to 16 byte? No, I don´t. Maybe Jochen can shed some light on this? Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Error msg: in space.cc
by Christian Stueble 22 Oct '99

22 Oct '99

Hi, if I boot Fiasco (Mar 31 1999) on my i486 machine, I get the following error message: ---- SIGMA0: Hello! i am 80000:40000, my pager is 0:0 RMGR: Hi there! RMGR: running on L4/Pentium space.cc:179: failed assertion 'size == PAGE_SIZE' ---- What does it mean? Does Fiasco only run on a Pentium machine? Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 1

Re: Question about IO-fpages
by Michael Hohmuth 22 Oct '99

22 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > I think Fiasco/L4 uses memory mapped I/O, not separated I/O? Memory-mapped I/O (that is, I/O via memory accesses in the virtual address space) and I/O via the separate 16-bit I/O address space (with in/out instructions; ``port I/O'') are completely separate from each other. It is not possible to map the port address space into the virtual memory, and that means it is not possible to replace port I/O with memory-mapped I/O. That's why, the kernel needs to support port I/O. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

A few questions
by Geoff Humphreys 20 Oct '99

20 Oct '99

Hello. I have been writing my own microkernel using ideas from L4 and other kernels. I am curious as to whether or not there would be an appreciable performance increase if the L4 system calls were split up into multiple calls. For example, the IPC call is be used to send messages, recieve messages, and to do RPC. Wouldn't it be faster if each of those were separate system calls (since it would require less if-then logic and bit manipulation)? Is there any reason not to do this? In addition, I am seeking well-commented, easy to understand scheduling algorithms or detailed descriptions of them. Right now I am using a nice, simple round-robin scheduler that doesn't even take priorities into account. It is very efficient, however. 8-) Also, does L4 have any support for semaphores? I was unable to find anything in the documentation. Thanks Geoff ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: A few questions
by Jean Wolter 20 Oct '99

20 Oct '99

"Geoff Humphreys" <xsaber0(a)hotmail.com> writes: > > Hello. I have been writing my own microkernel using ideas from L4 and other > kernels. > > I am curious as to whether or not there would be an appreciable performance > increase if the L4 system calls were split up into multiple calls. For > example, the IPC call is be used to send messages, recieve messages, and to > do RPC. Wouldn't it be faster if each of those were separate system calls > (since it would require less if-then logic and bit manipulation)? Is there > any reason not to do this? Maybe you should have a look at Jochen's micro kernel papers on our L4 page (SOSP93, SOSP95). One point was to combine the various ipc operations into one system call to reduce the number of 'kernel boundary crossings'. You add one simple if and remove an expensive switch from user to kernel and back. So this actually increases performance. > Also, does L4 have any support for semaphores? I was unable to find > anything in the documentation. There are no semaphores inside L4. All semaphores are implemented on user level. 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

Looking for L4 tutorials and documentation
by Geoff Humphreys 18 Oct '99

18 Oct '99

Hello. I am looking for L4 tutorials and documentation. I have the L4 reference manual for the 486/Pentium/Pentium pro, but I would like to find documentation with in-depth examples and benchmarks. Are such documents available, and if so, where? Thanks Geoff Humphreys ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: RMGR-Extension to control I/O access
by Jean Wolter 17 Oct '99

17 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > > Hello, > > I don´t know very much about the i386-processor and Fiasco, therefore > I would like to know if the following RMGR/Fiasco extensions are possible. > > 1) As default, no task has I/O port access. (CPL > IOPL or I/O permission > bitmap pointer invalid) > > 2) A task asks via IPC the RMGR for I/O port access, e.g. port=0x80, length=4. > > 3) The RMGR checks, if port access can be granted. If yes, the RMGR decreases > the tasks CPL and/or changes the tasks I/O permission bitmap. > > ==> Task is able to access port 0x80 - 0x83. > > The main question: I don´t know if a task is able to change the CPL > or the I/O permission bitmap of another task. That is exactly what io flex pages are designed for. Initially sigma0 has access to all io ports and can use io flex pages to grant port access to other task. If sigma0 grants access a subset of the io address space (adressses which are accessed by in/out instructions) the task gets an io permission bitmap. If sigma0 (or someone else) grants access to the whole io address space l4 changes the iopl so that any thread in this task can access any port and can even disable interrupts. So the only missing feature is an implementation of io flex pages. 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

2 1

RMGR-Extension to control I/O access
by Christian Stueble 15 Oct '99

15 Oct '99

Hello, I donŽt know very much about the i386-processor and Fiasco, therefore I would like to know if the following RMGR/Fiasco extensions are possible. 1) As default, no task has I/O port access. (CPL > IOPL or I/O permission bitmap pointer invalid) 2) A task asks via IPC the RMGR for I/O port access, e.g. port=0x80, length=4. 3) The RMGR checks, if port access can be granted. If yes, the RMGR decreases the tasks CPL and/or changes the tasks I/O permission bitmap. ==> Task is able to access port 0x80 - 0x83. The main question: I donŽt know if a task is able to change the CPL or the I/O permission bitmap of another task. Ciao, Christian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Re: Question about IO-fpages
by Jean Wolter 15 Oct '99

15 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > > It is said that always the complete IO space should be specified as > > receive fpage, why? > ? With flexpages you can map a page to an arbitrary address by specifying an according receive flex page. You are not allowed to do this with an IO-area. If someone grants you the right to access port X you can't change this to port Y by specifying a receive window in you IO address space. Therefore you have to specify your whole IO address space so that IO ports are always mapped one to one. 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

2 1

Re: Question about IO-fpages
by Christian Stueble 14 Oct '99

14 Oct '99

Am Wed, 13 Oct 1999 schrieben Sie: > Hello, > > the L4 reference manual mentions IO-fpages. Has a L4 task its own > IO address space containing IO-fpages, or maps L4 the IO-fpages > into the user memory? Ok, I found the answer at the RMGR manpage :-) > It is said that always the complete IO space should be specified as > receive fpage, why? ? Christian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------------------------------- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Question about IO-fpages
by Christian Stueble 13 Oct '99

13 Oct '99

Hello, the L4 reference manual mentions IO-fpages. Has a L4 task its own IO address space containing IO-fpages, or maps L4 the IO-fpages into the user memory? It is said that always the complete IO space should be specified as receive fpage, why? Thanks, Christian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

L4 user manual
by Christian Stueble 12 Oct '99

12 Oct '99

Hallo again, I was very enjoyed to find a L4 user manual at http://www.cse.unsw.edu.au/~disy Did I look over the link at the fiasco/L4 homepage? Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Re: Driver available?
by Michael Hohmuth 12 Oct '99

12 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > Mehnert96 and Stange96 both describe an environment to use Linux-drivers > together with L3. Is something similar available to L4/Fiasco? If yes, > where can the example implementations be found? Yes, similar frameworks have been created for a number of drivers (SCSI and ATM networking drivers come to my mind). These frameworks are more of a hackish ad-hoc nature and are in no way meant as a generic device-driver framework. These drivers (and their frameworks) have not been released publicly yet, and I don't know if there are plans to release them; I guess it would be a bit embarrasing for their authors to release them because they contain a lot of write-only, proof-of-concept code written for various research projects -- code they don't want anyone to see. ;-) Maybe these authors or my boss will bite and clarify what their stance on releasing this code is. However, and probably much more interesting to you, there is now a port of Utah university's OSKit (current snapshot 990722) to the L4/x86 and Fiasco interface. The OSKit comes with a lot of Linux and FreeBSD drivers, filesystems, and a complete IP stack that, with the help of a glue library the ``port'' consists of, just run on top of L4/x86 and Fiasco. There is a piece of news at <URL:http://os.inf.tu-dresden.de/fiasco/> about the port (look for liboskit10_support). It also tells you where to download the stuff. > Does L4-Linux directly access hardware ports? Yes, the drivers contained in L4Linux directly access I/O ports. > If yes, is it possible to prevent this behavior, e.g. by inserting a > new "virtual hardware layer"? I don't understand what you mean by ``virtual hardware layer'' and what exactly you want to do, but the answer to your question probably is yes. :) Do you want L4Linux to use drivers running in separate tasks so that it becomes possible to run L4Linux without any special hardware-access privileges? Yes, that is doable. In fact, I have been dreaming about such a setup on and off; this would make it possible to run and debug L4Linux under L4Linux. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: Driver available?
by Michael Hohmuth 11 Oct '99

11 Oct '99

Frank Mehnert <fm3(a)os.inf.tu-dresden.de> writes: > Unfortunately in German there is a paper that describes > an environment to port the Linux SCSI driver to L4: > > http://os.inf.tu-dresden.de/papers_ps/l4scsi.ps > > The source may be found at our CVS server. Nope, the SCSI package currently is not exported via our anonymous-CVS server... But if you want to release it, there probably is no problem. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Driver available?
by Christian Stueble 11 Oct '99

11 Oct '99

Hello, 1) Mehnert96 and Stange96 both describe an environment to use Linux-drivers together with L3. Is something similar available to L4/Fiasco? If yes, where can the example implementations be found? 2) Does L4-Linux directly access hardware ports? If yes, is it possible to prevent this behavior, e.g. by inserting a new "virtual hardware layer"? Ciao, Christian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

2 1

Re: Error compiling linux22
by vhandel＠chem.vu.nl 09 Oct '99

09 Oct '99

>gcc: Internal compiler error: program cc1 got fatal signal 11 Are you overclocking ? Otherwise, you probably have a bad SIMM. You should read the GCC-SIG11 FAQ that comes with every linux distro. Ramon

3 2

Re: Error compiling linux22
by Jean Wolter 08 Oct '99

08 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > > Hello, > > I tried to compile linux22 (8.10.99) and get the following error message: > > --------------- > gcc -D__KERNEL__ -I/usr/home/stueble/DA/Data/sb/linux22/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -I/usr/home/stueble/DA/Data/sb/linux22/../l4/include -I/home/drops/include -DLINUX_ON_L4 -g -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -c -o svc.o svc.c > gcc: Internal compiler error: program cc1 got fatal signal 11 [...] > Is this a compiler specific problem? This sounds either like a hardware problem (a kernel make is a good test for the memory subsystem) or a compiler problem. Does it happen every time you try to compile this particular file? Or do you get random segmentation faults (signal 11)? Jean -- Mr. Johnson has learned the first rule of not being seen. However, he has chosen a very obvious piece of covah! Kablooey!

1 0

Error compiling linux22
by Christian Stueble 08 Oct '99

08 Oct '99

Hello, I tried to compile linux22 (8.10.99) and get the following error message: --------------- gcc -D__KERNEL__ -I/usr/home/stueble/DA/Data/sb/linux22/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -I/usr/home/stueble/DA/Data/sb/linux22/../l4/include -I/home/drops/include -DLINUX_ON_L4 -g -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -c -o svc.o svc.c gcc: Internal compiler error: program cc1 got fatal signal 11 make[3]: *** [svc.o] Error 1 make[3]: Leaving directory `/usr/home/stueble/DA/Data/sb/linux22/fs/lockd' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/home/stueble/DA/Data/sb/linux22/fs/lockd' make[1]: *** [_subdir_lockd] Error 2 make[1]: Leaving directory `/usr/home/stueble/DA/Data/sb/linux22/fs' make: *** [_dir_fs] Error 2 stueble@rum:/usr/home/stueble/DA/Data/sb/linux22 > cpp: output pipe has been closed {standard input}: Assembler messages: {standard input}:1398: Warning: end of file not at end of a line; newline inserted {standard input}:1745: Warning: .stabs: Missing comma ---------------- System: gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release) GNU ld version 2.9.1 (with BFD 2.9.1.0.15) Pentium 133, SuSE 6.0 Is this a compiler specific problem? -Chris- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Re: Compiling Fiasco (PR#39)
by Michael Hohmuth 09 Sep '99

09 Sep '99

I wrote earlier: > David Waite <mass(a)ufl.edu> writes: > > > I have been having problems compiling Fiasco from the CVS drop I got about > > four days ago. The OSKit seems to be having problems with both the 'depend' > > files (they are actually getting some ELF binary tacked on to the end, > > although I haven't investigated why yet). Also, the gcc v2.95 has a problem > > with the assembly (reports invalid register use in the what looked to be > > linux scsi controller drivers) > > This seems to be a new problem triggered by the use of Gcc 2.95. I > currently cannot reproduce it (I'm still using older compiler versions). > [...] > Possible solutions would be to fix the old OSKit to compile with Gcc > 2.95, or maybe to implement some header files which emulate the old > OSKit's interface on top of the new one. BTW, according to the OSKit website, the new OSKit currently cannot be compiled with Gcc 2.95 or Egcs 1.x either, but must be compiled with Gcc 2.7.3, so upgrading now wouldn't fix this particular problem. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: GRUB network boot
by vhandel＠chem.vu.nl 02 Sep '99

02 Sep '99

>Are there instructions anywhere for how to do a network boot with >GRUB? I think there is code for it in Dresden's version of GRUB, but >not in GNU's GRUB, yet. I've just spent a few days integrating Dresden's netboot stuff into my heavily hacked version of GRUB, so I do have an idea how this works ;). The network device is called (nd). So your GRUB config could contain an entry like this: title= Netboot Linux root= (nd) kernel= /boot/vmlinuz [nfsroot options] or something similar :) Network boot works through TFTP/BOOTP. A linux HOWTO that helped me on the way is the Diskless mini-howto. You need to setup the bootp daemon on your server using a bootp configuration table, usually in /etc/bootptab. Read the diskless mini-howto and do man bootp to figure out how this works (do I need to post an example ?). Then, edit /etc/inetd.conf and uncomment the lines that look something like this: tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd bootps dgram udp wait root /usr/sbin/in.bootpd in.bootpd Pitfall: don't forget to give tftpd the directory in which your netboot files are as a parameter. You will still need to supply the complete path of that dir in GRUB (the howto's are a bit misleading, they talk about changing the root dir and stuff like that) but otherwise you would have to supply a relative path, which GRUB does not support. Now you should be ready to netboot ! PS, I have heard from people that sometimes the linux bootp daemon doesn't work. In that case you can try running the dhcp daemon with bootp support. PPS, I think there's another pitfall -- I haven't been keeping track of the development of Dresden's GRUB, but if it's similar to the version that I have at home them it's based on an old version of GRUB, which *does not compile correctly with the new gas* !!!!!! If you recompile it on an up-to-date system, GRUB'll crash on boot. So beware. This same problem occurs with the GRUB dist from uruk.org... GNU GRUB fixes this. >This one is even more off-topic, but I'll just mention it quickly: I >tried last night to install GRUB on an 8.4 GB disc. I know you always >used to have to make sure that stage2 is in the first 540 MB of the >disc, but I naively assumed that, since this was modern hardware and >the latest version of GRUB, and the BIOS was set to LBA mode, I would >be all right. But it didn't work (something like "Disc geometry >error"). Do the old restrictions still apply, then? Was it GNU GRUB ? The last time I tried GNU GRUB (a month ago or so) LBA mode didn't work for me... while I have a mere 520MB disk, for which the BIOS DOES support LBA !!!!! On some partitions I got all kinds of weird geo errors, on others I got corrupted partition information and stuff like that. I was going to try to debug it but never actually got around to it... Ramon

2 1

Re: Chief number in TID's
by Michael Hohmuth 02 Sep '99

02 Sep '99

Marcus, I think there is a misunderstanding here -- Adam's question was why is the number of the chief task a part of the thread-id data structure (l4_threadid_t). As it would be beneficial to move from 64-bit thread ids to 32-bit thread ids on 32-bit architectures like x86 and StrongARM, Adam is looking for ways to reduce the size of the thread-id data structure, and one way to do so would be to throw out the chief number. Personally, I don't think there is a real reason to keep the chief number in the thread id except for backward compatibility and for ease of porting L4 apps to a changed ABI. L4 has inherited this data structure from L3, and I would be interested in why the chief number ended up in the thread id in the first place. Jochen? Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

GRUB network boot
by Edmund GRIMLEY EVANS 02 Sep '99

02 Sep '99

Are there instructions anywhere for how to do a network boot with GRUB? I think there is code for it in Dresden's version of GRUB, but not in GNU's GRUB, yet. This one is even more off-topic, but I'll just mention it quickly: I tried last night to install GRUB on an 8.4 GB disc. I know you always used to have to make sure that stage2 is in the first 540 MB of the disc, but I naively assumed that, since this was modern hardware and the latest version of GRUB, and the BIOS was set to LBA mode, I would be all right. But it didn't work (something like "Disc geometry error"). Do the old restrictions still apply, then? Edmund

1 0

Chief number in TID's
by Adam 'WeirdArms' Wiggins 02 Sep '99

02 Sep '99

Does anyone have a 'good' reason for the chief number to be an a TID for the use of users (nothing to do with kernel internals and implimentation). Removing the chief from the TID allows 32bit TID's with a 'reasonable' number of tasks and threads per task. :) Cheers Adam

2 1

Re: Compiling Fiasco (PR#39)
by Michael Hohmuth 31 Aug '99

31 Aug '99

(I've put your bug report into our bugs database so that I won't forget about it.) David Waite <mass(a)ufl.edu> writes: > I have been having problems compiling Fiasco from the CVS drop I got about > four days ago. The OSKit seems to be having problems with both the 'depend' > files (they are actually getting some ELF binary tacked on to the end, > although I haven't investigated why yet). Also, the gcc v2.95 has a problem > with the assembly (reports invalid register use in the what looked to be > linux scsi controller drivers) This seems to be a new problem triggered by the use of Gcc 2.95. I currently cannot reproduce it (I'm still using older compiler versions). > I tried to upgrade to the newest OSKit I could find, but that didn't work > out either, because of some header files that were there before, and that > aren't now. (Is there some Fiasco files tacked on to the OSKit? I didn't > really think about that until now) We made a few bug fixes to the version of the OSKit we distribute, but we didn't add a lot of files. The main problem is that the OSKit's interface has changed a lot between releases -- all include files, for example, moved from <flux/foo.h> to <oskit/foo.h>, and all type names changed to names beginning with "oskit_" --, and some of the semantics also changed. Porting Fiasco to the new OSKit is easy enough (I once did this; the patch is somewhere in the l4-hackers archive), but because we in Dresden as a group haven't changed to the new OSKit yet, Fiasco hasn't, either. Possible solutions would be to fix the old OSKit to compile with Gcc 2.95, or maybe to implement some header files which emulate the old OSKit's interface on top of the new one. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

RE: Compiling Fiasco
by David Waite 28 Aug '99

28 Aug '99

I have been having problems compiling Fiasco from the CVS drop I got about four days ago. The OSKit seems to be having problems with both the 'depend' files (they are actually getting some ELF binary tacked on to the end, although I haven't investigated why yet). Also, the gcc v2.95 has a problem with the assembly (reports invalid register use in the what looked to be linux scsi controller drivers) I tried to upgrade to the newest OSKit I could find, but that didn't work out either, because of some header files that were there before, and that aren't now. (Is there some Fiasco files tacked on to the OSKit? I didn't really think about that until now) -David Waite

1 0

MIPS
by Gottfried F. Zojer 28 Aug '99

28 Aug '99

Hi, I m sending this posting to find out how many are using Fiasco/L4 on Mips-Processors. And I hope that there is coming in some response. Sincerely Gottfried F. Zojer

2 1

Re: NT like OS's
by Tom Linden 27 Aug '99

27 Aug '99

Are you sure you want to do this? What about all the dll's? I think it advisable to set down goals and functioanl specs before embarking on such an adventure. I also think that you should look at all the opportunities including L4-Linux from Dresden. <l3-hackers(a)os.inf.tu-dresden.de> I also have a mature, fault-tolerant operating system, originally written for IBM mainframe, which is quite portable. Hadn't planned on porting it to alpha, but it is a possibility, particularly since later alphas understand Big Endian. On Fri, 27 Aug 1999, Peter Lizon wrote: > Date: Fri, 27 Aug 1999 12:58:34 -0400 > From: Peter Lizon <peter(a)alphant.com> > To: AlphaNT Mail List <AlphaNT(a)AlphaNT.com> > Subject: Re: NT like OS's > > Yeah - this is what I was looking for, not OpenNT . . . Now can we port this > to Alpha please? Preferably by the end of the year ;) > > Peter Lizon > ----- Original Message ----- > From: Michael Rich <istan(a)alltel.net> > To: <alphant(a)alphant.com> > Sent: Friday, August 27, 1999 12:38 PM > Subject: NT like OS's > > > > I know its off the wall, but there is at least one project thats currently > > working towards an NT compatible system. Currently its only x86 > > unfortuantly, but its open source, so anyone could start work on a > different > > processor. > > > > http://www.reactos.com > > > > Michael Rich > > http://alphax86dev.cjb.net > > > > __________________________________________________ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ /_/ /_/ /_/ Tom Linden PL/I Support /_/ /_/ Kednos Corporation OpenVMS and /_/ /_/ tel 650 566 9484 Tru64 Unix /_/ /_/_____________________________________________/_/ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

1 0

Re: L4-Linux on 486
by Michael Hohmuth 27 Aug '99

27 Aug '99

I wrote: > edmundo(a)rano.demon.co.uk writes: > > > (1) The Fiasco assertion about stack space (thread.cc:316) has failed > > several times. > > I can reproduce this: Under heavy interrupt load, a thread's kernel > stack can overflow on slow machines. I'm still thinking about what > the best way is to correct the problem. I think I found a solution to this problem. I've checked it in. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: L4-Linux on 486
by Michael Hohmuth 26 Aug '99

26 Aug '99

edmundo(a)rano.demon.co.uk writes: > (1) The Fiasco assertion about stack space (thread.cc:316) has failed > several times. I can reproduce this: Under heavy interrupt load, a thread's kernel stack can overflow on slow machines. I'm still thinking about what the best way is to correct the problem. > (2) Frequently cc1 segfaults when compiling a large file. Annoyingly, > it hasn't done it since I built one with debugging symbols. Maybe this is a symptom of an undetected kernel-stack overflow: When the kernel accidentally touches user memory, this can lead to page-fault messages being sent to the thread's pager and the thread being killed. > (3) The following C code causes massive strafing[1] of the disc which > I can terminate only by rebooting as the process seems to ignore all > signals. > > { > unsigned char a[4096*1024]; > int i; > unsigned char c; > > for (c = 0; ; c++) { > for (i = 0; i < sizeof(a); i += 4096) > a[i] = c; > } > } > > On one occasion cc1 gave the same behaviour. > > Can anyone tell me if this behaviour is a bug? It might just be a > "limitation" of L4-Linux, in which I'm in trouble, because it's the > only nasty behaviour which I can reproduce in a simple way. > > I only have 8 MB of memory, by the way, so the code above is expected > to exercise the disc. I just don't expect it to be unkillable. A > program that mallocs lots of 4000-byte blocks doesn't become > unkillable in the same way. I'd say the unkillable process is a bug, but the disk thrashing is to be expected on a low-memory machine. I'll try reproducing this later -- I'll tackle the stack-overflow problem first. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: Porting Hurd to l4
by Michael Hohmuth 25 Aug '99

25 Aug '99

Matthew Vernon <matthew(a)debian.org> writes: > Is the l4 server interface descripted somewhere (as in, I need a > little more help getting started than just RTFsource :) )? I guess you mean the L4-kernel interface to be used by servers, don't you? This interface is documented in manpages at <URL:http://os.inf.tu-dresden.de/L4/l4man.html> (this is for Fiasco and L4/x86; the L4/MIPS website has manpages for the MIPS version). The L4 Reference Manual is the defining document for the L4 API (and x86 ABI); it's available at <URL:http://os.inf.tu-dresden.de/L4/l4refx86.ps.gz>. > I'm beginning to think the effort involved in porting the HURD > servers to Mach may be worthwhile in the long run. ^^^^ L4? If the Hurd wouldn't be too Mach-dependent, and would instead use a microkernel-independent object model (like "MOM", a framework Bryan Form from Utah was thinking about at one point), it should be possible to port it to L4. In fact, if you look closely, there is even some (unused and orphaned) early support for MOM in the Hurd source tree (in the libmom directory). Then, all you would need for a port to L4 would be an object framework (something like a server supporting a slim version of Mach ports) and a set of device drivers. Personally, I'd love to see a Hurd port to L4. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Porting Hurd to l4
by Matthew Vernon 24 Aug '99

24 Aug '99

Hi, Is the l4 server interface descripted somewhere (as in, I need a little more help getting started than just RTFsource :) )? I'm beginning to think the effort involved in porting the HURD servers to Mach may be worthwhile in the long run. ObHurd - what do any Hurd people here think? Matthew

4 3

L4-Linux on 486
by edmundo＠rano.demon.co.uk 23 Aug '99

23 Aug '99

Michael's patch from 1999-08-18 seems to have solved the IRQ problem I was suffering from previously. I can now do lots of heavy NFS with no problems at all. But I now have different problems, of course ... Unfortunately the latest symptoms are very vague and various. I've had spontaneous reboots, I've had the machine just stop, uninterruptible by GDB, I've had various assertions fail in Fiasco, I've had an assertion fail in Linux ("reply_and_wait error", l4_idle.S:564). Some of the failed assertions in Fiasco seem inexplicable except by something scribbling on memory as they involve bits of the scheduling code which seem simple enough not to fail only in rare circumstances. Most of the fatal events are not repeatable and have only happened to me once, but there are three things that I have seen several times: (1) The Fiasco assertion about stack space (thread.cc:316) has failed several times. (2) Frequently cc1 segfaults when compiling a large file. Annoyingly, it hasn't done it since I built one with debugging symbols. (3) The following C code causes massive strafing[1] of the disc which I can terminate only by rebooting as the process seems to ignore all signals. { unsigned char a[4096*1024]; int i; unsigned char c; for (c = 0; ; c++) { for (i = 0; i < sizeof(a); i += 4096) a[i] = c; } } On one occasion cc1 gave the same behaviour. Can anyone tell me if this behaviour is a bug? It might just be a "limitation" of L4-Linux, in which I'm in trouble, because it's the only nasty behaviour which I can reproduce in a simple way. I only have 8 MB of memory, by the way, so the code above is expected to exercise the disc. I just don't expect it to be unkillable. A program that mallocs lots of 4000-byte blocks doesn't become unkillable in the same way. Edmund [1] My trusty old 100 MB disc does sound a bit like a machine gun when there is a lot of swapping going on.

1 0

Re: L4-Linux worked on 486!
by Michael Hohmuth 18 Aug '99

18 Aug '99

Edmund, good news: I think I have found the problem! edmundo(a)rano.demon.co.uk writes: > I've investigated the ready queue after hitting "irq still active" by > doing "p (class thread_t*)0xc0000000" and "p $.ready_next" repeatedly. > In each case the threads corresponding to irqs 5 and 14 seemed to be > ready. In one case, so was the thread corresponding to irq 0. > > Just to confirm: irq 5 = 0xc014a800, irq 14 = 0xc014f000 > > I think I'm dealing with irq 5 when the error occurs because the value > 0x20 is in eax and ebx. Yep. > So presumably I should investigate the kernel stack for irq thread 14, > which was apparently preempted in some mysterious fashion by an > interrupt thread of lower priority. I see there's a kernel_sp in > thread_t. [...] I had a very similar situation, and from looking at the stack of the preempted higher-priority thread, it could tell that the higher-priority thread was voluntarily switching to the lower-priority thread by calling schedule(). However, schedule() should not have switched to the lower-priority thread if the higher-priority thread was runnable... Anyway, a close look at the scheduler revealed a race condition where a high-priority thread could become runnable after it has decided to switch to a lower-priority one. I think I have eliminated that race now. Please try the latest version of thread.cc from CVS (>= 1.51). Thanks again for testing! Michael (Taking a mental note not to throw away my good old 486 so soon because slow machines reveal much more races...) -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: L4-Linux worked on 486!
by Michael Hohmuth 18 Aug '99

18 Aug '99

edmundo(a)rano.demon.co.uk writes: > So presumably I should investigate the kernel stack for irq thread 14, > which was apparently preempted in some mysterious fashion by an > interrupt thread of lower priority. I see there's a kernel_sp in > thread_t. Can anyone tell me how to get gdb to analyse that stack for > me, to save me picking out the values that look like program addresses > from the hex dump by hand? Gdb has a command "frame <frame-address>" which should make it possible to select a different stack frame. However, this feature seems to be broken for x86 (at least in Gdb 4.17). I have made a hack to Gdb which lets you use a command "frame <frame-address> <program-counter>"; this command selects a different frame, and you can use "up" and "down" to look at nested or parent frames (sorry, no "backtrace"!). This hack only seems to work if the current frame is valid, but at least it's something to start from. I've appended a patch below. It probably would be worthwile to develop a real fix for Gdb... > I haven't been able to contact os.inf.tu-dresden.de, The network should have been back up since Monday morning. > so I'm still using the same irq.c as before I went on holiday. It > seems to be 1.16 with Michael's patch that was sent to l4-hackers on > 1999-07-23 plus the following patch: I've applied your patch. Thanks! [ from a different email: ] > Also, has anyone other than me experienced the "irq still active" > problem? I have seen mention of a PIC bug in certain Intel 486s; it > would be nice to know for certain that this problem isn't specific to > just my hardware ... No, it's not: I've just been able to reproduce your problem. (This took a while because I first had to fix a different synchronization problem I ran into when I induced the test load you described -- `cksum' + heavy CVS usage on network-mounted disk.) I'll have a look at the problem (and the data you provided -- thanks for digging in!) and post again when I know more. Later, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

"irq still active"
by edmundo＠rano.demon.co.uk 18 Aug '99

18 Aug '99

I've had another look at the kernel_sp for the irq threads after I hit "irq still active" (/linux22/arch/l4-i386/kernel/irq.c:1058). The active threads are: (thread_t *) 0xc0000000 (thread_t *) 0xc014a800 (thread_t *) 0xc014f000 The latter two correspond to tcb 5 0x15 and tcb 5 0x1e, irqs 5 and 14, which are NE2000 and ide0. I rather suspect that I have been barking up the wrong tree by looking at where kernel_sp points at. Although it looks like an execution stack, with a trail of frame pointers and program addresses adjacent to them, I can't get gdb to interpret it for me, and, suspiciously, the values of kernel_sp are equally spaced between the threads, as if all the alleged stacks are exactly the same size, which suggests that they don't have any interesting information for me. tcb 5 0x15 kernel_sp = 0xc014aee4 tcb 5 0x1e kernel_sp = 0xc014f6e4 etc Any other debugging suggestions? Also, has anyone other than me experienced the "irq still active" problem? I have seen mention of a PIC bug in certain Intel 486s; it would be nice to know for certain that this problem isn't specific to just my hardware ... Edmund

1 0

Re: L4-Linux worked on 486!
by Michael Hohmuth 16 Aug '99

16 Aug '99

Edmund GRIMLEY EVANS <edmundo(a)rano.demon.co.uk> writes: > From what you wrote, it sounds like the problem could be solved in > either of two ways: > > - make L4 priorities correspond to PIC priorities > - use a specific instead of a non-specific EOI That's correct. We went for the first solution (because AFAIK, the second one (specific EOI) is not allowed for the mode of the PIC we use -- the special fully nested mode --, or at least it not documented what happens when used in this mode). > Can either of these be implemented as a quick fix even if the long-term > solution is moving irq ack into the microkernel? I've done this already; what you've digged up is my implementation of the first solution: > I notice that linux22/arch/l4-i386/kernel/irq.c has: > > static const > /* prio for irq 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 */ > char irq_prio[] = {1, 0,15, 6, 5, 4, 3, 2,14,13,12,11,10, 9, 8, 7}; > > Can I change this? What to? > > My wild guess would be {15,14,13,4,3,2,1,0,12,11,10,9,8,7,6,5} ... > but there must be some reason for it being the way it is ... This array sorts the priority of the interrupt threads in the order of the hardware priorities. It reflects the priorities after they have been changed by programming the PIC in irq_init.cc: irq_t::init(). Jean already explained why this is the correct order: We have to make sure that IRQ8 (Fiasco's timer interrupt) has the highest priority (i.e., so that it always gets through even if other irqs are in service (i.e., haven't been acknowledged yet)), and that's why IRQ2, the cascade irq for the slave PIC (which hosts IRQ8) gets the highest priority on the master PIC. So, you shouldn't change this array. Now, to debug your problem (some irq's in-service flag is still set after we think we're acknowledged the irq), here are some tips: I suggest you try to find out if there are other irq threads which are in the ready queue and which have been preempted before they have acknowledged their interrupt. In an L4Linux setup, these threads are 5.10 to 5.20 (in hexadecimal task.lthread format, as understood by the built-in kernel debugger Jdb). Then we can try to understand why that thread has been preempted by walking up its kernel stack. Some random hints: In Jdb, you can use `r n' and `r p' to traverse the ready queue (mnemonics: ``ready next'', ``ready prev''). Look at a thread_t by typing something like `t 5.10'. For Gdb, .gdbinit has a macro which can be used like this: "tcb 5 0x10" prints thread's 5.10 thread_t. I've added a command `k p' to Jdb which prints out the state of the PICs. Maybe you can see something suspect there? You can switch back and forth between remote Gdb and Jdb by using "set jdb::use_nested = 0" in Gdb and by pressing `V s' in Jdb. (Of course, all this only works if you haven't completely disabled Jdb with the "-nojdb" command-line switch.) > > There was a long discussion about that and it looks like irq > > acknowledge will move to the micro kernel. > > Was this an e-mail discussion accessible to people like myself, or a > discussion in the coffee room in TU Dresden? An electronic coffee room meant for L4 implementors on various architectures (a private mailing list hosted by USNW). Do you think that more of the internal kernel-design-and-interface discussion should take place in public? If so, we might try to pursuade the other members of that other mailing list to move more of their discussions here. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: L4-Linux worked on 486!
by Michael Hohmuth 12 Aug '99

12 Aug '99

edmundo(a)rano.demon.co.uk writes: > Jochen Liedtke asked, and I think it's a crucial question: > > > are the interrupts constantly disabled from raising the interrupt > >until executing that code? > > Looking at the code, I think the answer is yes. (There is, however, > quite a lot of code between the interrupt happening and the > non-specific EOI being issued, and there are lots of macros and > conditional compilations, so I might be wrong. Unfortunately, you are wrong: Fiasco likes to enable interrupts (because it is a real-time kernel), and there is no guaranty at all that irqs will remain disabled until the EOI is issued (even if the irq thread enters the kernel with interrupts disabled). > Is it possible to inspect the state of the interrupt-disable flag > using remote gdb?) Yes, with "info registers" (or "i r" for short). But when you're in the debugger, it will be too late. > In which case I no longer understand what Jean Wolter wrote about > priority assignment to interrupt threads. If interrupts are > constantly disabled from raising the interrupt until the > non-specific EOI, how can the priorities matter? If the PIC can > "deliver" an interrupt with higher priority while interrupts are > disabled, It can't. > and if the non-specific EOI then acknowledges the highest-priority > interrupt that was delivered, It doesn't, in the sense of "deliver" you defined above. > as opposed to the hightest-priority interrupt that is being > serviced, then we are always in trouble if we issue a non-specific > EOI with interupts disabled. In this case, should we reenable > interrupts before doing the EOI? > > But I can't think why the PIC should have been designed this way. It isn't. Unspecific EOI acknowledges the latest irq that has been accepted by the CPU, and if the CPU is in "cli" mode, it will not accept an irq no matter what its hardware priority in the PIC is. So, given that the CPU operates in "cli" mode, hardware priorities don't matter. But it doesn't operate in "cli" mode at all times. And even if it would, there are problems with the irq threads' software priorities: Unlike L4/x86, Fiasco doesn't deliver an irq-IPC message to an interrupt thread if there is a different thread with a higher priority; instead, the irq ``sender'' is blocked and queued in the irq thread's sender queue. This can lead to a thread different from the irq thread being scheduled and, as a consequence, to interrupts being enabled in the CPU ("sti" mode). > [...] > To reconcile this, I am lead to conclude that my inspection of the > code is mistaken, interrupts are not disabled constantly from raising > the interrupt until issuing the EOI, and this is deliberately so, This is correct. > but somehow we are ending up in the wrong interrupt thread after a > higher-priority interrupts interrupts a lower-priority one. Yep. Maybe some event or IPC caused an lower-priority irq thread to be scheduled before a higher-priority irq thread could acknowledge its irq. > I'm really out of my depth here. Can anyone recommend a good book, or > other source of information, about x86 and PIC programming? (I don't > need an introduction to assembler programming, as I did a lot of 6502 > and 8080 as a child, but I don't know much about x86 specifics or > about interrupt details.) I don't know of any good book describing PIC programming. The best reference I could find was a specification of the ``legacy interrupt controller'' for the PowerPC CHRP platform (which probably emulates the PIC's interface for old x86-PC hardware). But this is only a specification and not a programming manual. Among other places, it's available in Chapter 4 of <URL: ftp://ftp.austin.ibm.com/pub/technology/spec/chrp/inwork/CHRP_IORef_1.0.pdf>. You might also want to try doing a websearch on "programmable interrupt controller programming" or somesuch; I just did a quick search, and <URL:http://www.geocities.com/SiliconValley/Bay/8302/interupt.htm> seems to be a nice intro, but it doesn't discuss the special fully nested mode Fiasco uses. A search on "special fully nested mode" brought up a description of a PCI bridge containing PIC functionality at <URL:http://www.intel.com/design/intarch/techinfo/430tx/ticTOC.htm>. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: L4-Linux worked on 486!
by Michael Hohmuth 12 Aug '99

12 Aug '99

edmundo(a)rano.demon.co.uk writes: > L4-Linux is running quite nicely for me now, but I can still crash it > by doing cksum /usr/bin/* over CVS. It dies after saying "irq still > active". (To get that message I'm using the patch that Michael Hohmuth > posted to the list on July 25.) > > I think I may have found a bug in the SANITY code in > linux22/arch/l4-i386/kernel/irq.c, by the way. [...] > This is what I did to linux22/arch/l4-i386/kernel/irq.c: > > In timer_irq_thread(), I moved > > #ifdef SANITY > irqs_in_progress &= ~(1 << TIMER_IRQ); > #endif > > from its present position just before the call to > l4_i386_ipc_receive() to just before the call to > execute_bottom_halves(). This got rid of the "irq active" messages > which I think are spurious. > > Sorry for the lack of patch but I've rather lost control of the > versions of that file ... My patch you mentioned already contains a similar change... Can you send my (in private email) the output of "cvs diff irq.c" (before you do "cvs update")? Anyway, I've now checked in my sanity-checking changes in linux22/arch/l4-i386/kernel/irq.c. I suggest you use that version for testing. > What I have been doing is telling GDB "symbol-file .../vmlinux" to > inspect what's happening in Linux, then "symbol-file .../kernel.image" > to go back to inspecting Fiasco. There's probably some way of defining > macros to make that switching a bit easier. I don't know if GDB could > use both sets of symbols at the same time. Me neither. > (This is a bit off topic, but does anyone know a better solution to > this one? I tell GDB "p spong" and get a value that is totally wrong. > This is because the variable has been optimised into a register. So to > find out its value I use "disassemble" and "info registers". Is there > a quicker way?) Unfortunately, no, AFAIK. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

L4-Linux worked on 486!
by suzukis＠file.phys.tohoku.ac.jp 05 Aug '99

05 Aug '99

Hi, Just I could boot L4-Linux and execute "ls" etc on 486, without rebooting. At present, it seems that Fiasco must be recent version, but the version of L4-Linux does not matter. Both of the previous snapshot (L4-Linux 2.0.21) and the anonymous CVS version (linux22 which I checked out July/26) are working. I remember, after the announcement of linux22 availability via CVS, I experienced several 486 rebooting caused by "ls". So I will continue to search the critical point. After several trying of remote debug, I think "kernel"-debugger is not so much powerful to detect how L4-Linux "server" breaks down. It's not easy for me to understand what happens in the server program from the system calls. Therefore, now I'm looking for a remote-debug-stub for server program on Fiasco. The document of the OSKit tells that the debug-stub in the OSKit is easy to re-use for user-spaced programs, I will try. But there's any working debug-stub? suzuki P.S. By the way, wait_for_keypress() (linux22/drivers/char/tty_io.c) of the latest linux22 works well? It is called when mounting the root filesystem on floppy, or on ramdisk loaded via floppy, like: printk(KERN_NOTICE "VFS: Insert root floppy and press ENTER\n"); wait_for_keypress(); (from linux/fs/super.c). In my testing, the latest linux22 is killed when it calls wait_for_keypress(). But the previous snapshot of L4-Linux (2.0.21) safely passes wait_for_keypress(). The message from the debugger (when linux22 is killed) is like this: grub> kernel=(fd0)/rmgr -nopentium -configfile -sigma0 [Multiboot-elf, <0x100000:0x20320:0x0>,<0x121320:0x418:0x26dac>,entry=0x100000] grub> module=(fd0)/main -nokdb -nojdb [Multiboot-module @ 0x149000, 0x24200 bytes] grub> module=(fd0)/sigma0 [Multiboot-module @ 0x16e000, 0xcb26 bytes] grub> module=(fd0)/rmgr.cfg [Multiboot-module @ 0x17b000, 0x56d bytes] grub> module=(fd0)/glinux.gz init=/bin/sh root=/dev/fd1 [Multiboot-module @ 0x17c000, 0xe428 bytes] RMGR: loading task (fd0)/glinux.gz init=/bin/sh root=/dev/fd1 from 0x17c000-0x260238 to [ 0x3ff000-0x4b2170 0x4b4000-0x4fe034 ] RMGR: starting task (fd0)/glinux.gz init=/bin/sh root=/dev/fd1 from 0x17c000-0x260238 at entry 0x3ff000 via trampoline page code 0x26114c [...snip...] VFS: Insert root floppy and press ENTER Dump of trap_state at 0xc0141fb4: EAX 00000000 EBX 00000001 ECX 004e1646 EDX 00000001 ESI 00000000 EDI 00000000 EBP 00000000 ESP 00d05f5c EIP 00000003 EFLAGS 00013a92 CS 0023 SS 002b DS 002b FS 002b GS 002b trapno 6, error 00000000, from user mode

3 7

Re: L4-Linux worked on 486!
by Jean Wolter 03 Aug '99

03 Aug '99

Edmund GRIMLEY EVANS <edmundo(a)rano.demon.co.uk> writes: > > Thanks for your reply. > > >From what you wrote, it sounds like the problem could be solved in > either of two ways: > > - make L4 priorities correspond to PIC priorities > - use a specific instead of a non-specific EOI > > Can either of these be implemented as a quick fix even if the long-term > solution is moving irq ack into the microkernel? > > I notice that linux22/arch/l4-i386/kernel/irq.c has: > > static const > /* prio for irq 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 */ > char irq_prio[] = {1, 0,15, 6, 5, 4, 3, 2,14,13,12,11,10, 9, 8, 7}; > > Can I change this? What to? It looks like Michael already changed that. The PIC is programmed with irq8 at the highest priority (thats the timer used by L4) and the threads have the same priority. So if you still have problems you should discuss this with Michael. He is currently not in Dresden but IIRC he will be back next week. 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 worked on 486!
by Jean Wolter 03 Aug '99

03 Aug '99

edmundo(a)rano.demon.co.uk writes: > > > >It dies after saying "irq still active". > > >(To get that message I'm using the patch that Michael Hohmuth > > > posted to the list on July 25.) > > > I think I may have found a bug in the SANITY code in > > > linux22/arch/l4-i386/kernel/irq.c, by the way. See below. > > > > I remember, I've ever seen same message & following crash, > > thanks for the patch. > > Unfortunately I still don't understand why the irq is "still active". The problem is the following: Normally the pic only forwards one interrupt to the CPU and signals the next one after the current interrupt has been acknowledged. L4 uses a special PIC mode ("special fully nested mode" or something similar), that allows the pic to signal more than one interrupt to the CPU. It uses priorities to decide whether a newly arrived interrupt should be forwarded to the CPU. So it is possible that more than one interrupt is delivered to the CPU before the interrupt handler was able to acknowledge its own interrupt. If we use "unspecific end of interrupt" to acknowledge the interrupt we acknowledge the one with the highest priority. > > Here's the corresponding bit of code in irq.c. (The lines which aren't > indented as much as they should be came from Michael's debugging > patch.) > > > mask = 1 << (irq & 7); > if (irq < 8) > { > outb(inb(0x21) | mask, 0x21); /* block the irq */ > outb(0x20, 0x20); /* acknowledge the irq */ We use unspecific end of interrupt to acknowledge the irq. > > outb(0x0B, 0x20); > if (inb(0x20) & mask) > enter_kdebug("irq still active"); Now we read the "in service register" of the pic and find out that our interrupt is still active. Due to fiasco being preemptive and a wrong priority assignment to our interrupt threads it happened that a thread with a higher L4 priority which handled an irq with a lower pic priority accidently acknowledged the wrong interrupt. > If you look at the bottom of kernel/fiasco/src/irq.h you'll find an > unused function irq_ack() which does roughly the same thing, because > acknowleding the IRQ is something that ought to be done by L4/Fiasco, > but is at present done by Linux. > > So why do we get "irq still active" during heavy use of the network > card? Is there a PIC expert in the house? I hope the explanation above was clear enough :) > > Is it possible that the problem is caused by the interrupt not being > acknowledged quickly enough? If so, maybe I should move the ack from > Linux into Fiasco ... There was a long discussion about that and it looks like irq acknowledge will move to the micro kernel. 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

2 1

Re: any documents for remote debug newbies?
by Michael Hohmuth 23 Jul '99

23 Jul '99

suzukis(a)file.phys.tohoku.ac.jp writes: > I was reading the manpage of L4 (telling "-comspeed" as the option > for rmgr) and not of Fiasco (telling it as for main). I was wondering > why rmgr does not understand options like "-comspeed", "-comport". I think the Rmgr manual tells you to apply the "-comspeed" option to the L4 kernel binary (grubboot.img, or, in our case, main) -- at least, that's what it should tell you. It probably need to be made less confusing. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: recent GAS and l4/kernel/fiasco/src/entry.S
by Michael Hohmuth 23 Jul '99

23 Jul '99

OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> writes: > From: suzukis(a)file.phys.tohoku.ac.jp > > If I change the register name from "%dl" to "%edx" in the entry.S > > (leaving the opcode "bt" as it is), the recent GAS could assemble it. > > Anybody found such behaviour? My GAS is broken? > > The code "bt $2, %dl" is invalid. The bit test call only accepts > 16bits and 32bits registers, so that should be "btw $2, %dx" or "btl > %2, %edx". Thanks; I've fixed this in the CVS version now. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: any documents for remote debug newbies?
by Michael Hohmuth 22 Jul '99

22 Jul '99

suzukis(a)file.phys.tohoku.ac.jp writes: > As Edmund reported previously, also I found that L4-Linux (2.0.21) > could boot but not work well on my 486 PC (of course, I added > -nopentium option for rmgr). However, same kit (fiasco/rmgr/sigma0 > /glinux) works well on Pentium PC. I fixed some fatal 486-related bugs last night (alas, I didn't have an 486 to test with earlier). L4Linux 2.2 can now boot multi-user on Fiasco on my 486. This version currently is only available from remote CVS. I hope to get to making some new snapshots soon, as L4Linux 2.2 now is quite stable on Fiasco. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

3 2

Re: any documents for remote debug newbies?
by suzukis＠file.phys.tohoku.ac.jp 21 Jul '99

21 Jul '99

Michael points out: >>Just I've tried by adding "-comspeed 9600" option to rmgr, also > ^^^^ >"-comspeed 9600" is not an Rmgr option but an option for the Fiasco >kernel, like this: (slightly edited from my menu.lst) I see! Adding the option to the Fiasco kernel, GDB successfully connects to the target PC. Sooner I will check the revised Fiasco. I was reading the manpage of L4 (telling "-comspeed" as the option for rmgr) and not of Fiasco (telling it as for main). I was wondering why rmgr does not understand options like "-comspeed", "-comport".

1 0

any documents for remote debug newbies?
by suzukis＠file.phys.tohoku.ac.jp 20 Jul '99

20 Jul '99

Hello. As Edmund reported previously, also I found that L4-Linux (2.0.21) could boot but not work well on my 486 PC (of course, I added -nopentium option for rmgr). However, same kit (fiasco/rmgr/sigma0 /glinux) works well on Pentium PC. I'm trying remote debugging, but yet I couldn't connect gdb and fiasco-system. I removed "-nokdb" option for main (fiasco kernel) module, thus fiasco-system on target 486 PC enters remote debugging mode, and waits for gdb instructions via serial cable, like this. ------------------------------------------------------- on target PC console ------------------------------------------------------- RMGR: loading (fd0)/sigma0 RMGR: detected new-style DD-L4 RMGR: starting (fd0)/main proto=0x10136c Welcome to Fiasco! DD-L4/x86 microkernel (c) 1998 TU Dresden - May 17 1999 KDB: init ------------------------------------------------------- Then I started gdb on host PC (Debian 2.1 on Pentium PC - gdb is from binary package). Though it seems that some packets sent & received via serial cable, but gdb could not complete the connection. gdb says, ------------------------------------------------------- on host PC ------------------------------------------------------- % cat .gdbinit file kernel.image set remotedebug 1 set remotebaud 115200 #set remotebaud 9600 target remote /dev/ttyS0 % gdb kernel.image GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-pc-linux-gnu"... Sending packet: $Hc-1#09...putpkt: Junk: WJW B% Sending packet: $Hc-1#09...putpkt: Junk: W B% Sending packet: $Hc-1#09...putpkt: Junk: W B% Sending packet: $Hc-1#09...putpkt: Junk: W B% Timed out. Timed out. Timed out. Ignoring packet error, continuing... Sending packet: $qOffsets#4b...putpkt: Junk: W B% Sending packet: $qOffsets#4b...putpkt: Junk: W B% Sending packet: $qOffsets#4b...putpkt: Junk: W B]% Sending packet: $qOffsets#4b...putpkt: Junk: % Timed out. Timed out. Timed out. Couldn't establish connection to remote target Malformed response to offset query, timeout -------------------------------------------------------------------- Slowing the remotebaud to 9600, the result is just same. When I boot small Linux system on the target 486 PC, the baudrait returned by setserial command is 115200. ASCII messages redirected to /dev/ttyS1 on the target PC are well transfered to /dev/ttyS0 on the host PC, so I suppose there's no physical troubles (e.g. staled cable or port), and I ought to have forgotten some points to configure. I'm not enough-skilled to find my wrong points. There's any useful documents to excersize remote debugging? I want some sample program... the document in GDB is difficult for me, because I must add several functions to generic (and incomplete) i386-stub.c, before excersize remote debugging. suzuki

2 2

Re: Booting fiasco kernel on cyrix
by Michael Hohmuth 20 Jul '99

20 Jul '99

Kazuto MIYOSHI <kaz(a)earth.email.ne.jp> writes: > I've been trying to boot fiasco kernel on my CYRIX MII machine > (I had believed that CYRIC has binary compatibility with Pentium.) > > Booting from floppy image downloaded, it says > > space.cc:193 failed assertion(size==PAGE_SIZE)... > > and I found out that 'size' is actually SUPERPAGE_SIZE. > > I suspect that there is a little bit differnce between CYRIX and > Pentium, with the ability to treat 4MB pages, and I tried to disable > superpage facility by changing cpu.feature_flags like this: > cpu.feature_flags &= ~(CPUF_PAGE_GLOBAL_EXT|CPUF_4MB_PAGES); > This modification successfully generates "HELLO" message on console, > but after printing it, the same assertion still fails. I'd be interested in a backtrace. Do you have a second machine available which you could use for remote debugging? (Implementing a back-trace facility for Jean's built-in low-level debugger (jdb) is also an option, but I'm not sure I can get to this during this week. Any takers?) > Does not fiasco run on CYRIX cpu at all (why?), or does anyone have > good idea to avoid this problem? Fiasco is supposed to run on the Cyrix CPU, but without a test machine it's difficult to say what exactly the problem is. I found and fixed a few 486-related bugs today, but I'm not sure they're related to your problems. You might want to try the latest version anyway (but currently it's available only via remote CVS). Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Booting fiasco kernel on cyrix
by Kazuto MIYOSHI 11 Jul '99

11 Jul '99

Hello. I've been trying to boot fiasco kernel on my CYRIX MII machine (I had believed that CYRIC has binary compatibility with Pentium.) Booting from floppy image downloaded, it says space.cc:193 failed assertion(size==PAGE_SIZE)... and I found out that 'size' is actually SUPERPAGE_SIZE. I suspect that there is a little bit differnce between CYRIX and Pentium, with the ability to treat 4MB pages, and I tried to disable superpage facility by changing cpu.feature_flags like this: // cpu info; need to do this before setting up page tables because // we need to know whether we can use 4MB pages. cpuid(&cpu); #if 1 cpu.feature_flags &= ~(CPUF_PAGE_GLOBAL_EXT|CPUF_4MB_PAGES); #endif // the first thing to set up is the page-level allocator so that we // can allocate page tables from it kmem::init(mbi_pa); This modification successfully generates "HELLO" message on console, but after printing it, the same assertion still fails. Does not fiasco run on CYRIX cpu at all (why?), or does anyone have good idea to avoid this problem? my environment: fiasco-l4-990428.tar.gz fiasco-l4-990428.patch-01 grub-l4-981207.tar.gz oskit-l4-990428.tar.gz grub-ext2fs-floppy

1 0

Re: none
by Michael Hohmuth 08 Jul '99

08 Jul '99

benben xiao <xiaoxiaoben(a)hotmail.com> writes: > I recently see the Fiasco resoure.I have a problem that I found > main.cc > 55 kernel_thread_t *kernel=new(&config::kernel_id); > call main.cc 80 kernel_thread_t::operator new(size_t,threadid_t id);. > I don't know how to transmit the parameter of type size_t. You don't -- the compiler generates it implicitly. There is a difference between the "new" operator and the "operator new" function. For more information please consult a good book on C++. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: L4-Linux with l4-gmd
by Michael Hohmuth 08 Jul '99

08 Jul '99

edmundo(a)rano.demon.co.uk writes: > Since I'm unable to run L4-Linux with Fiasco on my 486 - I can boot > with init=/bin/sh but it reboots as soon as I do anything that > involves a fork - I thought I'd try L4-Linux with the old, non-free > L4. So I downloaded l4-gmd/486/obj/l4.exe [...] This ancient version doesn't work with L4Linux -- it's too buggy. :-( > But how do I make grubboot.img out of l4.exe, if this is what I'm > supposed to do? (The man page for rmgr says the modules should be ELF > files.) If you want to try it anyway: Copy l4.exe to l4/l4/kernel/l4-gmd/src, cd to l4/l4/kernel/l4-gmd and type "make". If all goes well, this should build a grubboot.img binary. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

L4-Linux with l4-gmd
by edmundo＠rano.demon.co.uk 07 Jul '99

07 Jul '99

Since I'm unable to run L4-Linux with Fiasco on my 486 - I can boot with init=/bin/sh but it reboots as soon as I do anything that involves a fork - I thought I'd try L4-Linux with the old, non-free L4. So I downloaded l4-gmd/486/obj/l4.exe and found an old menu.lst, which contains examples such as: kernel= (fd0)/rmgr -configfile module= (fd0)/grubboot.img boothack nowait module= (fd0)/rmgr.cfg.linux module= (fd0)/glinux.gz root=/dev/sda1 kernel= (fd0)/rmgr module= (fd0)/grubboot.img boothack nowait module= (fd0)/hello (Main difference: there is no sigma0 module.) But how do I make grubboot.img out of l4.exe, if this is what I'm supposed to do? (The man page for rmgr says the modules should be ELF files.) Edmund

1 0

(no subject)
by benben xiao 06 Jul '99

06 Jul '99

hi hackers: I recently see the Fiasco resoure.I have a problem that I found main.cc 55 kernel_thread_t *kernel=new(&config::kernel_id); call main.cc 80 kernel_thread_t::operator new(size_t,threadid_t id);. I don't know how to transmit the parameter of type size_t. Thanks. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Re: Error while Compiling L4Linux
by Jean Wolter 30 Jun '99

30 Jun '99

Christian Ceelen <ceelen(a)ira.uka.de> writes: > I downloaded the L4Linux (and all other Components) through the CVS, > configured it and tried to compile it. I received a lot of error > messages and the compiler stoped without building the kernel (tried > it with 2.0 and 2.2). What's wrong or where can I find a working > version? We are currently changing our build environment and unfortunatly the l4 libraries on our ftp server are some older versions. There are some Makefiles missing. We have to fix this. In the meantime you can either fetch a current copy of l4sys and l4util using cvs or install some missing links by yourself. Simply create include/l4/{sys,util} in your l4 directory and link all header files from the pkg/l4{sys,util}/include/l4/ to it. I will ask Michael to provide a new snapshot for the l4 libraries. 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

Error while Compiling L4Linux
by Christian Ceelen 30 Jun '99

30 Jun '99

Hi, I downloaded the L4Linux (and all other Components) through the CVS, configured it and tried to compile it. I received a lot of error messages and the compiler stoped without building the kernel (tried it with 2.0 and 2.2). What's wrong or where can I find a working version? Thanks, Christian Ceelen eMail: Christian.Ceelen(a)ira.uka.de error log /home/l4/l4/linux22 $make all (...) /home/l4/l4/linux22/include/asm/processor.h:19: l4/sys/types.h: No such file or directory In file included from /home/l4/l4/linux22/include/linux/unistd.h:9, from init/main.c:16: /home/l4/l4/linux22/include/asm/unistd.h:29: l4/sys/kdebug.h: No such file or directory /home/l4/l4/linux22/include/asm/processor.h:223: parse error before 4_threadid_t' +many more in processors.h Here is now the exit: /home/l4/l4/linux22/include/linux/sched.h:303: field ss' has incomplete type make: *** [init/main.o] Error 1 /home/l4/l4/linux22 $

1 0

Re: netboot support for GRUB
by Michael Hohmuth 16 Jun '99

16 Jun '99

OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> writes: > I was asked why we hadn't integrated the netboot support in the > DROPS version of GRUB into GNU GRUB. That is just because we don't > have the time. If the developers can adapt the code to GNU GRUB, > I would be glad to merge the change with GNU GRUB. There is no GNU > GRUB webpage yet, so I attach the draft below. What's the difference between GNU GRUB and Erich Boleyn's original GRUB? (Your draft webpage doesn't say this, but it should.) Does Erich still maintain GRUB? There is a potential licensing problem because parts of the netboot code we've started from are licensed under a BSD license while GRUB is GPL'd, so it may be illegal to aggregate the two. So far, we've chosen to ignore this problem. What's your stance on this? Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

3 3

Re: latest cvs & previous snapshot are compatible ?
by Michael Hohmuth 12 Jun '99

12 Jun '99

suzukis(a)file.phys.tohoku.ac.jp writes: > The latest Fiasco which is available through CVS has > the compatiblity with the previous snapshot (at 990428)? In theory, yes. However, we don't do a lot of integrative testing with what we check into our CVS repository; so what you get from the CVS can be less stable than what you find in the snapshots, although we do aim to having a working state at all times. > I've just compiled new Fiasco (main, rmgr, sigma0), > sample server (hello) and L4-Linux 2.2 on my PC. > I copied them into the grub-ext2-fs-floppy > (thus, grub is same with that of the previous snapshot), > but I could not make them work well, even hello server > does not run. Oops, this shouldn't happen. :( > (Sorry, I can't report displayed message at present.) The error messages are important to diagnose the problem. > I will check some couples of the combinations among > old/new kernel, old/new pager, old/new server, etc. > If compiled correctly, the new programs can cooporate > with old programs? Yes, this should be possible. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

2 1

netboot support for GRUB
by OKUJI Yoshinori 12 Jun '99

12 Jun '99

Hello, I was asked why we hadn't integrated the netboot support in the DROPS version of GRUB into GNU GRUB. That is just because we don't have the time. If the developers can adapt the code to GNU GRUB, I would be glad to merge the change with GNU GRUB. There is no GNU GRUB webpage yet, so I attach the draft below. Thanks, OKUJI ---------------------------------------------------------------------- OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> ^o-o^ http://duff.kuicr.kyoto-u.ac.jp/~okuji (in English) m /

1 0

latest cvs & previous snapshot are compatible ?
by suzukis＠file.phys.tohoku.ac.jp 11 Jun '99

11 Jun '99

Hello, The latest Fiasco which is available through CVS has the compatiblity with the previous snapshot (at 990428)? I've just compiled new Fiasco (main, rmgr, sigma0), sample server (hello) and L4-Linux 2.2 on my PC. I copied them into the grub-ext2-fs-floppy (thus, grub is same with that of the previous snapshot), but I could not make them work well, even hello server does not run. (Sorry, I can't report displayed message at present.) I will check some couples of the combinations among old/new kernel, old/new pager, old/new server, etc. If compiled correctly, the new programs can cooporate with old programs? suzuki

1 0

Re: L4Linux 2.2; Remote CVS
by Jean Wolter 10 Jun '99

10 Jun '99

suzukis(a)file.phys.tohoku.ac.jp writes: > ARCH := l4-mips > ---------------------------------------------------------- > > So, when I started make config, it generates the symbolic > links from the sources for MIPS. In linux/Makefile (2.0.21), > ARCH was defined as "l4-i386". Did I download anything > different from L4Linux/x86? Or I don't have to mind? There are currently two L4Linux architectures, one for x86 and the other one for MIPS (MIPS is still under development). Simply change ARCH to l4-i386 to build L4Linux for x86. 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

L4Linux 2.2; Remote CVS
by Michael Hohmuth 10 Jun '99

10 Jun '99

Hackers, we've released a port of the Linux kernel version 2.2 (available via remote CVS -- see below). It runs quite stably on L4/x86, but we have to conduct some more tests with Fiasco; that's why, we haven't released a snapshot yet. Also, we have set up read-only access to parts of our CVS repository: you can now access via CVS the latest (unstable) code of L4Linux 2.0, L4Linux 2.2, Fiasco, Rmgr (and other components of the L4 development environment), and our versions of the OSKit and GRUB. For access information, please visit <URL:http://os.inf.tu-dresden.de/drops/download.html>. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: SMP-Fiasco,Compare it with QNX
by Michael Hohmuth 09 Jun '99

09 Jun '99

"Gottfried F. Zojer" <go.enzoy(a)carinthia.com> writes: > First I was a OS/2 Programmer also using the Watcom-Compiler.For the > reason that the support of IBM was uncalculatable I tried to find > something different there I can use my Watcom skills.And I found > QNX.But it was simple to expensive for my use but I was thrilled from > it s abilities.So I will ask some question to the list in the hope of > feedback. > 1)Tried somebody to compile FIASCO with a different compiler then GNU > GCC No. I don't think that adapting the code to a different compiler would be a big problem, but so far nobody thought this to be a worthwile project. > 2)Are there any plans to support SMP or other forms to use this > kernel in High Performance Computing or Clustering. We plan to add SMP support, but haven't yet committed any resources to this project. > 3)From QNX I own the Demodisk(IAT-Internet Appliances Toolkit).Exist > something similar for FIASCO and DROPS. Not yet, but this is a good idea. Maybe later this year... ;) > 4)Tried somebody FIASCO kernel on Embedded products from AMD and > Jumptec. No; we don't have access to this hardware. But we do want to support it, and we're willing to work with anyone planning to get Fiasco going on it. Cheers, Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

SMP-Fiasco,Compare it with QNX
by Gottfried F. Zojer 09 Jun '99

09 Jun '99

Hello, I m a newbie to this list and also in case of Kernel-programming. So I writing this mail with the hope that any feedback is coming. First I was a OS/2 Programmer also using the Watcom-Compiler.For the reason that the support of IBM was uncalculatable I tried to find something different there I can use my Watcom skills.And I found QNX.But it was simple to expensive for my use but I was thrilled from it s abilities.So I will ask some question to the list in the hope of feedback. 1)Tried somebody to compile FIASCO with a different compiler then GNU GCC 2)Are there any plans to support SMP or other forms to use this kernel in High Performance Computing or Clustering. 3)From QNX I own the Demodisk(IAT-Internet Appliances Toolkit).Exist something similar for FIASCO and DROPS. 4)Tried somebody FIASCO kernel on Embedded products from AMD and Jumptec. Nice greetings from Austria Gottfried F. Zojer

1 0

Re: Ein paar Fragen/Anmerkungen zur neuen Directory Struktur
by Jean Wolter 04 Jun '99

04 Jun '99

Jean Wolter <jw5(a)inf.tu-dresden.de> writes: > > Hallo, > Sorry for the German language posting, I accidently picked the wrong mailing list. 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

Ein paar Fragen/Anmerkungen zur neuen Directory Struktur
by Jean Wolter 04 Jun '99

04 Jun '99

Hallo, nachdem nun etwas Zeit für die liegen gebliebenen Arbeiten ist, habe ich versucht, das Repository zu übersetzen. Das ging natürlich nicht. Zwei Gründe: 1. Die privaten Includedirs sind nicht gesetzt (mit einem "PRIVATE_INCDIR='../include' make" kommt man ein Stück weiter). Sollen die privaten includes lokal gesetzt werden, dann müssen alle Makefiles angepaßt werden oder setzen wir das global? 2. Es gibt Unstimmigkeiten über die Lokation der L4 Headerfiles (ehemals libl4sys). Micha vermutet sie unter l4/sys/, sie liegen aber unter l4/. Was ist nun richtig und wer passt es an? 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:
by Michael Hohmuth 31 May '99

31 May '99

"benben xiao" <xiaoxiaoben(a)hotmail.com> writes: > When I see fiasco kernel, I have a simple question: > I don't know > #if 0 > ... > ... > #endif > what do '0' mean there? This is a way to comment out unused code: Everything between "#if 0" and "#endif" is stripped by the preprocessor, and is ignored by the compiler. For more information about the C/C++ preprocessor, please refer to the GNU CPP manual. On most systems, you can browse it with "info cpp". The answer to your particular question is in "info cpp conditional deletion". Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: Default attributes of tasks/lthreads
by Michael Hohmuth 31 May '99

31 May '99

Robert Kaiser <rob(a)sysgo.de> writes: > The question came up while writing a test suite for a microkernel > we are currently developing. It's API is not identical, but quite > similar to L4's (we would like to run L4Linux on it in the future). If your kernel's API is similar enough: Is there a chance of releasing your test suite as open source? We probably could adapt it to our implementations, and having a test suite for Fiasco and L4/x86 would be very useful. > I can certainly handle this behavior, but I was just wondering > what would be a "clean" design. From what I just learned, there > is in fact a difference between a thread being created and a thread > being re-started into a new context: In the first case, the thread's > scheduling parameters are inherited from the caller, in the latter > case, they retain whatever values they had before. So the caller > of lthread_ex_regs has to be aware of wether the thread already > exists or not. Yes, that's true. What you proposed earlier in this thread (make it possible to set scheduling parameters for not-yet-existing local threads) seems to be somewhat cleaner, but I think the current behavior isn't very difficult to handle; tasks have to keep track of thread states anyway because they manage the allocation of local thread ids themselves. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: Default attributes of tasks/lthreads
by Michael Hohmuth 31 May '99

31 May '99

Robert Kaiser <rob(a)sysgo.de> writes: > I have a question regarding the default scheduling parameters > of newly created tasks and lthreads under L4: > > When I create a new task with the task_new syscall, according > to the L4 manual, that task's lthread 0 starts running immediately. > > But what are it's scheduling parameters (timeslice duration, > priority) in this case ? > > Similarly, when I create a new lthread with lthread_ex_regs, > how are it's scheduling parameters determined ? The parameters are inherited from the creating thread. There usually is a way to change the parameters before the new thread starts running: Use the thread_schedule system call before serving the thread's first page fault. > Also, is it possible to set these parameters for an lthread > that does not yet exist (The manual doesn't explicitly state > this, but the fact that -conceptually- all lthreads of a task > always exist would suggest that this is indeed possible) ? Good question. I think this is not really defined in the manual. The current implementations don't support what you suggest; instead, the scheduling parameters are inherited from the creating thread once the new thread is ``really'' created. Do you have an application where this behavior is a problem? Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

3 2

(no subject)
by benben xiao 31 May '99

31 May '99

Hi Hackers: When I see fiasco kernel, I have a simple question: I don't know #if 0 ... ... #endif what do '0' mean there? Please pardon my poor english! Thank you! ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Default attributes of tasks/lthreads
by Robert Kaiser 27 May '99

27 May '99

Hi Hackers, I have a question regarding the default scheduling parameters of newly created tasks and lthreads under L4: When I create a new task with the task_new syscall, according to the L4 manual, that task's lthread 0 starts running immediately. But what are it's scheduling parameters (timeslice duration, priority) in this case ? Similarly, when I create a new lthread with lthread_ex_regs, how are it's scheduling parameters determined ? Also, is it possible to set these parameters for an lthread that does not yet exist (The manual doesn't explicitly state this, but the fact that -conceptually- all lthreads of a task always exist would suggest that this is indeed possible) ? Thanks for any 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: GMD paper
by Michael Hohmuth 25 May '99

25 May '99

I wrote a few minutes ago: > This paper is now available (along with many other interesting papers > from Jochen) from <URL:http://i30www.ira.uka.de/images/b_publications_on.gif>. ^^^^ Oops, although you probably like GIFs, this one isn't of particular utility. Here's the correct URL: <URL:http://i30www.ira.uka.de/publications/index.html>. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: GMD paper
by Michael Hohmuth 25 May '99

25 May '99

"Adam 'WeirdArms' Wiggins" <awiggins(a)cse.unsw.edu.au writes: > Anyone know where I can get a copy of: > > Jochen Liedtke: > Improved Address Space Switching on Pentium Processors by > Transparently Multiplexing User Address Spaces > (GMD technical report) This paper is now available (along with many other interesting papers from Jochen) from <URL:http://i30www.ira.uka.de/images/b_publications_on.gif>. The URL for the paper you're looking for is <URL:http://i30www.ira.uka.de/publications/pubcat/As-pent.ps>. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: Please help me!
by Michael Hohmuth 25 May '99

25 May '99

"benben xiao" <xiaoxiaoben(a)hotmail.com> writes: > Hi; > When I see the file "init.h" in "l4/server/sigma0/src/",I meet a problem. > Although I have know: > #define L4_NORETURN __attribute__((noreturn)) > but I don't understand the function definition: > void init(struct multiboot_info *mbi, unsigned int flag, > l4_kernel_info_t *info) L4_NORETURN; > there why we can use "L4_NORETURN" and what is the effect of > "L4_NORETURN". __attribute__((noreturn)) is an extension supported by the GNU C compiler. It is intended to be used with functions that are not supposed to return. When a function declared with this attribute looks like it returns anyway, the compiler issues a warning. Please consult the Gcc documentation for more details (on most system, you can run "info gcc 'c extensions' 'function attr'"). Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: basis of L4-Linux
by Michael Hohmuth 25 May '99

25 May '99

suzukis(a)file.phys.tohoku.ac.jp writes: > uname returned Linux 2.0.21(or 20?) - I remember, L4-Linux > seems to be based old kernel source. But the L4-Linux source > also seems to include something taken from later kernel > source (ex. Configure.help). L4-Linux will be rewritten > from the later Linux kernel (ex. 2.0.36, or 2.2.x)? > Or, will be a branch from the old kernel? We have been working internally on a port of Linux 2.2 to L4, and I'm positive that we can release it ``soon.'' > If asking about L4-Linux is off-topic, please let me know > who/where I could ask about L4-Linux. No, that's fine, you're on-topic. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Please help me!
by benben xiao 25 May '99

25 May '99

Hi; When I see the file "init.h" in "l4/server/sigma0/src/",I meet a problem. Although I have know: #define L4_NORETURN __attribute__((noreturn)) but I don't understand the function definition: void init(struct multiboot_info *mbi, unsigned int flag, l4_kernel_info_t *info) L4_NORETURN; there why we can use "L4_NORETURN" and what is the effect of "L4_NORETURN". Thank you! ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

basis of L4-Linux
by suzukis＠file.phys.tohoku.ac.jp 21 May '99

21 May '99

Hello, Just I've checked Fiasco (990428), L4-Linux (981207) and grub-ext2fs-floppy. Although compiling OSKit was truncated as FAQ (relocation trucated), Fiasco & L4-Linux was bootable on my PC which Debian 2.0. Except of X window system, most work well, as original Linux. It was quite impressive & exciting! I've never impressed as such. uname returned Linux 2.0.21(or 20?) - I remember, L4-Linux seems to be based old kernel source. But the L4-Linux source also seems to include something taken from later kernel source (ex. Configure.help). L4-Linux will be rewritten from the later Linux kernel (ex. 2.0.36, or 2.2.x)? Or, will be a branch from the old kernel? If asking about L4-Linux is off-topic, please let me know who/where I could ask about L4-Linux. Sorry for poor English.

1 0

Re: What is RMGR?
by Michael Hohmuth 10 May '99

10 May '99

°í¿µ¿õ <yuko(a)os.korea.ac.kr> writes: > Anyone know the relation between L4 and RMGR? > I cannot understand. -_- > > I want to know > 1) If L4 kernel could boot without RMGR?. RMGR is essential part of L4? Yes, and no, respectively. It is well possible to construct L4-based or Fiasco-based systems without Rmgr, and we have done so in the past. However, nowadays we always use Rmgr because it provides a very convenient way for bootstrapping a system. > 2) If it is essential module for L4, the size of L4 microkernel must > include RMGR size? Even then it probably wouldn't count because once the system is up and running, Rmgr is mostly idle. It certainly doesn't hurt the system performance because it doesn't induce a measurable load on the CPU caches. > I want to get related papers or documentation. Except for the manpage at <URL:http://os.inf.tu-dresden.de/L4/l4libman/rmgr.html>, there aren't any. Rmgr just happens to be an application everyone uses. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

GMD paper
by Adam 'WeirdArms' Wiggins 10 May '99

10 May '99

Anyone know where I can get a copy of: Jochen Liedtke: Improved Address Space Switching on Pentium Processors by Transparently Multiplexing User Address Spaces (GMD technical report) Cheers Adam

2 1

Re: New Fiasco snapshot
by Michael Hohmuth 10 May '99

10 May '99

David Welch <david.welch(a)st-edmund-hall.oxford.ac.uk> writes: > I am having problems using the snapshot. It builds and boots > ok but as soon as I try to fork/exec another program it freezes. > > I am using a Cyrix processor (without the 4MB page extensions), > and the latest Fiasco snapshot (including the released patches) as > well as the latest L4Linux server and patches. [...] I suppose by fork/exec you mean the corresponding L4Linux system calls? If your problem is related to your CPU not having 4MB-page extensions, then there's a good chance that I will come across it this week: Other people have reported problems with non-Pentium CPUs too, so my sysadmin has organized an old 486 for me to debug Fiasco on. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: L4 threadid ver0 and ver1 bits
by Michael Hohmuth 10 May '99

10 May '99

"Adam 'WeirdArms' Wiggins" <awiggins(a)cse.unsw.edu.au> writes: > I think they were seperate in the Intel for efficiency reasons, Yes, that's right: The way the bits are laid out in thread ids, it takes the kernel only one AND and one OR to compute the address of the thread control block; no shifts or lookups necessary. (Fiasco actually currently adds a shift because the kernel stack contained in the thread control blocks is larger to accommodate for the fact that higher-level languages need more stack space.) Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

L4 threadid ver0 and ver1 bits
by Daniel Potts 10 May '99

10 May '99

Hi, What is the precise meaning of the ver0 and ver1 bits in the L4 thread ids? Cheers, Daniel

2 3

New Fiasco snapshot
by Michael Hohmuth 10 May '99

10 May '99

Hackers, I've made available a new Fiasco source code snapshot (990428), nicknamed version 0.6. It contains numerous bug fixes and two new features: - Long-message IPC has been implemented (but hasn't yet been tested extensively). - Jean Wolter has contributed a new stand-alone kernel debugger. It allows you to see critical kernel state on your text console. I've also released new snapshots for the L4 runtime support (required) and for our version of the OSKit, as well as a new patch for L4Linux. Please find the stuff here: ftp://ftp.inf.tu-dresden.de/pub/os/L4/fiasco/fiasco-l4-990428.tar.gz ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/l4-990428.tar.gz ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/oskit-l4-990428.tar.gz ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/linux-l4-981207.patch-02.gz Our admins are busy figuring out how to allow CVS access from the outside world. In the future this will allow you to access up-to-date source code without waiting for a new snapshot. Please visit <URL:http://os.inf.tu-dresden.de/fiasco/use.html> for updated build instructions. Have fun! Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: Patch for Fiasco 0.6
by Michael Hohmuth 04 May '99

04 May '99

kermit the frog <kermit(a)tower.com.ar> writes: > Well, what i saw is that the WHOLE directory structure changed ... and the > Makefile has a -I/home/drops (or something) which doesnt seems to be > needed since Fiasco compiles anyway ... These changes allow people working on only part of the source tree to check out (or unpack) only what they're working on and otherwise use what's been installed in /home/drops (DROPS_STDDIR in l4/Makeconf). > It would be nice to have the old dir. structure back ... (; It will get even better (read: more confusing ;) in the next snapshot: We've moved all include files to package-specific subdirectories to reduce clutter in <l4/*.h>, requiring changes to many source files (e.g., <l4/ipc.h> becomes <l4/sys/ipc.h>). We thought that indroducing some software-development guidelines now would hurt less than introducing them later. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Patch for Fiasco 0.6
by Michael Hohmuth 04 May '99

04 May '99

It looks like the Fiasco-0.6 snapshot has been sewed together with too hot a needle (thanks to Hoi-sun lee for reporting this problem). Please apply the patch appended below to make it compile. (This patch will also appear on the Fiasco ftp site as fiasco-l4-990428.patch-01.gz.) Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

deceit operations for clans+chiefs.
by Daniel Potts 01 May '99

01 May '99

Assume task A is the chief of task B, which is the chief of task C, which is the chief of task D. ;-) * Now, D does an ipc call to A. A successfully receives the message from D via the chiefs (C and B). * Now when A replies to this, the message first gets intercepted by B. * B sends a deceiting ipc to D with A as the virtual sender. This gets intercepted by C. * C sends a deceiting ipc to D with A as the virtual sender. This step fails (?!) due to direction preservation not holding. That is when C checks nchief on A it returns L4_NC_OUTER_CLAN, and nchief on D returns L4_NC_SAME_CLAN, which is not equal, and therefore not direction preserving. Have I got this scenario correct? Assuming that each cheif can obtain the virtual sender as part of it's ipc api. Cheers, Daniel

2 2

Re: Still missing something ...
by Michael Hohmuth 28 Apr '99

28 Apr '99

kermit the frog <kermit(a)tower.com.ar> writes: > Hello, thanks for always answering (im such a pain in the ... (-: > > Well, this time, after following Michael's instructions (heres a piece of > the code) : > th = l4_myself(); > printf("rmgr_init()\n"); > rmgr_init(); > printf("Hello, task: %d, thread: %d\n", th.id.task, th.id.lthread); > > sigma0.id.task = 2; > sigma0.id.lthread = 0; > > recv.id.task = rmgr_get_task(6); > recv.id.chief = th.id.task ; > recv.id.lthread = 0; > recv = l4_task_new(recv, 5, (dword_t) task+(4096*2), (dword_t)task, > sigma0); > > All i get is : 'sys_id_nearest' > > What is that ?? Argh, the library code snippet I sent you uses l4_nchief(), a binding for the sys_id_nearest system call, a call which has only been fixed recently. I really should release a new code snapshot... I'll try to do this later today (and I'll try to make the source code more accessible in order to avoid such problems in the future). For now, you can try the Fiasco patch below, or you can modify the librmgr.c file I sent you to find out its Rmgr server by querying its pager using l4_thread_ex_regs() instead of using l4_nchief() -- just change the "#if 0" in rmgr_init() to "#if 1". Sorry, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Still missing something ...
by kermit the frog 28 Apr '99

28 Apr '99

Hello, thanks for always answering (im such a pain in the ... (-: Well, this time, after following Michael's instructions (heres a piece of the code) : th = l4_myself(); printf("rmgr_init()\n"); rmgr_init(); printf("Hello, task: %d, thread: %d\n", th.id.task, th.id.lthread); sigma0.id.task = 2; sigma0.id.lthread = 0; recv.id.task = rmgr_get_task(6); recv.id.chief = th.id.task ; recv.id.lthread = 0; recv = l4_task_new(recv, 5, (dword_t) task+(4096*2), (dword_t)task, sigma0); All i get is : 'sys_id_nearest' What is that ?? Cheers. Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ...............................................................................

1 0

Re: Am i missing something here ?
by Michael Hohmuth 27 Apr '99

27 Apr '99

kermit the frog <kermit(a)tower.com.ar> writes: > First of all, thanks for replying. I happen to have another problem. If i > try to create a new task, no matter what i do i always get the message > > 'KDB: task new: not chief' > > the line im using to create a task is as follows: > recv = l4_task_new(recv, 6, (dword_t) task+(4096*2), (dword_t)task, > L4_NIL_ID); > Where task is a function defined void task(void); Im asuming here that the > stack will begin , lets say to pages from the code page (task + (4096*2)). > > Am i missing something here ?? (-: Yes: In order to be allowed to create or delete a task, you must be the task's ``chief.'' When the system boots, Rmgr (task 4) is the chief of all other tasks, and thus is the only task which may create new tasks. Your task (probably task 5) initially cannot create any task. The current owner of a chief right to nonexistent tasks can transfer the right using the l4_task_new() system call. There is an Rmgr protocol message which allows tasks to request chief rights to specific tasks from Rmgr. I'll append below a library which wraps the Rmgr protocol into C bindings. With it it you can request a new chief right using the sequence: rmgr_init(); error = rmgr_get_task(number); (The library also contains functions called rmgr_task_new() and rmgr_task_new_with_prio() which lets Rmgr create a new task, but these currently don't work with Fiasco because they require long-message IPC. Long-message IPC has only been implemented recently, and I'm currently testing it; it will be included in the next release.) Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: Am i missing something here ?
by kermit the frog 27 Apr '99

27 Apr '99

Yeah, that could be a solution (the loop) but, ass soon as i try to create the new task it dumps the register contents and then asks me if i want to reboot ... i guess ill have to recompile it with a different # and boot to try every new configuration ... Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ............................................................................... On Tue, 27 Apr 1999, Gernot Heiser wrote: > >>>>> "ktf" == kermit the frog <kermit(a)tower.com.ar> writes: > > ktf> Well, ive attached the source code of my program. To anser to your > ktf> question, recv is initialized to task=6; ltherad=0; i know that my program > ktf> starts with task=5 so im using the next task available. > > That doesn't guarantee that this task isn't in use (e.g. for a device > driver). I'm not sure how fiasco allocates initial tasks. You'd be > better off running a loop trying all task ids. > > 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: Am i missing something here ?
by kermit the frog 27 Apr '99

27 Apr '99

Well, ive attached the source code of my program. To anser to your question, recv is initialized to task=6; ltherad=0; i know that my program starts with task=5 so im using the next task available. Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ...............................................................................

1 0

Re: Am i missing something here ?
by Michael Hohmuth 27 Apr '99

27 Apr '99

kermit the frog <kermit(a)tower.com.ar> writes: > Heres the thing, whenever I start 2 or more task/threads that contain some > sort of a 'pause' in the for l4_i386_ipc_receive(L4_NIL_ID ... it seems to > be that all tasks/threads block forever, eventhough they have a TIMEOUT of > 4 secs, sometimes even less. I think you are seeing a bug in the timeout code which I happened to fix last week. Please try the patch appended below. I'll probably also release a new Fiasco snapshot soon. BTW, does anyone think a public CVS repository for Fiasco would be helpful? If so, please email me privately. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Am i missing something here ?
by kermit the frog 26 Apr '99

26 Apr '99

While "testing" some REALLY simple servers that I wrote I noticed something, maybe this is a bug or maybe Im plain dumb and im missing something (-; Heres the thing, whenever I start 2 or more task/threads that contain some sort of a 'pause' in the for l4_i386_ipc_receive(L4_NIL_ID ... it seems to be that all tasks/threads block forever, eventhough they have a TIMEOUT of 4 secs, sometimes even less. Example for 2 tasks: Initialization stuff . . for(;;){ printf("."); /* wait 4 sec */ l4_i386_ipc_receive(L4_NIL_ID, 0, &d1, &d2, L4_IPC_TIMEOUT(0,0,255,8,0,0), &result); } In this example you have 2 tasks which do the same thing, just printf("something"); . Very simple, but they seem to block. The same thing happens if you create a new thread with l4_thread_ex_regs, and you have the same loop (for ... printf ... l4_ipc_recev) in a function, say my_thread, and send &my_thread as the EIP. Well, if you happen to remove those 'pauses' all threads/tasks seem to work just fine (although if youre printing in each of them you cant see anything (-: So thats it. Did anyone had this error ?? Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ...............................................................................

1 0

Re: using L4-Linux
by Michael Hohmuth 01 Apr '99

01 Apr '99

edmundo(a)rano.demon.co.uk writes: > I had it sort of running just now ... > [...] > I then had no cursor, but a shell, with which I could walk around the > file system using pwd, cd and echo *. It reboots as soon as I do > anything that involves a fork, such as ls, cat or sh. So I'll worry > about configuring X later, right? :-) > I built main and sigma0 myself under Debian 2.1, i.e. gcc 2.7.2.3 and > binutils 2.9.1.0.19a, from the sources dated 981207. Everything else > was already on grub-ext2fs-floppy from the ftp site. I compile on a > 686 machine and run Fiasco on a 486 machine. I have tried the boot floppy you sent me, and I was able to boot L4Linux into multiuser mode. However, I had to replace "glinux.gz" with my own, self-compiled L4Linux server image because the one on the boot floppy didn't contain drivers for my SCSI card. One thing you might want to try is booting a newer L4Linux binary (the one one your floppy is pretty old). I'll send you mine under separate cover. If this also doesn't work, I guess that Fiasco has a problem with 486s. Right now I cannot test this because I currently don't have a working 486, but I probably will get one the week after the next. Michael PS: I have uploaded a new grub-ext2fs-floppy.gz which contains the newest version of all binaries, including Fiasco and working configuration files. It's at <URL:ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/grub-ext2fs-floppy.gz>. -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

2 1

Fiasco/OSKit-0.96 patch (was Re: "relocation truncated")
by Michael Hohmuth 27 Mar '99

27 Mar '99

OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> writes: > Thanks for your answer. Could you show the patch you made for newer > OSKit? I'd like to see what changes are needed for different version > of OSKit. I'll append the patch below. You should only use it for informational purposes, and you shouldn't try actually applying it (I pretty sure it doesn't apply cleanly). This patch really only is a quick hack. There are many modifications involving changes to type names and include file names. Fiasco probably should be fixed not to rely on OSKit's type names so religiously. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

None
by Robert Kaiser 24 Mar '99

24 Mar '99

Hello Hackers, this might be slightly offtopic, but... I see the rmgr man-page mentions a document titled "Guidelines for implementing os servers on top of L4". Is this document available on the Web ? If so, where can I download it ? 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

2 1

None
by Cervino Ulises 18 Mar '99

18 Mar '99

> Hello, im a student of comp. science in Argentina, and for my final projects > i intend to develop an OS over fiasco, so far all ive been doing is reading > about L4 and testing some things with fiasco, if someone is interested or > did something with fiasco (coded any servers or anything) id love to know. > > Thanks !!

1 0

Re: using L4-Linux
by Michael Hohmuth 17 Mar '99

17 Mar '99

edmundo(a)rano.demon.co.uk writes: > 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. When you don't use a config file, Rmgr parses its command line for configuration info. Usually it skips over options starting with "-", but maybe the boot floppy contains an old Rmgr binary which doesn't. Copying a new binary (which you should find at l4/server/rmgr/src/rmgr) to the floppy should fix this problem. > 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", These messages have no meaning, and they will be removed. Ignore them. ;) > and the last kernel message, before the machine reboots by itself, > is "INIT: version 2.75 booting". All quotations may be approximate. Hmm... a little bit of debugging would maybe help. Do you have a second machine available which you could connect to the first one using a null-modem cable? > 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 These messages are also mostly informational. > Can anyone suggest what I can try next? Does anyone have this working? Well, we have... I suggest that you copy an image of your floppy using `dd' and send it to me; maybe I have overlooked something in the distribution. > 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'".) This rings a familiar bell; I thought I had fixed this before -- I'll check tomorrow. > Does someone have working binaries of "main" and "sigma0" that I could > try, to see if there's something strange about my hardware? I don't think it's your hardware; it's just that we always test using Pentiums, and on i486s Fiasco cannot use 4-MB pages which may trigger a few bugs. We'll find them. ;) Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

3 2

l4-hackers: new mailing-list policy
by Michael Hohmuth 17 Mar '99

17 Mar '99

Since a few days, the mailing list manager for l4-hackers only accepts messages sent by list members. This policy has been implemented to reduce the amount of spam. Until a few minutes ago, messages sent by non-members disappeared into a black hole. I just got bitten by this myself because my subscription address used to be different from my sender address. We have changed this now so that illegitimate senders get a bounce message. I will re-send a few of my messages which vanished into the black hole later today. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: "relocation truncated"
by Michael Hohmuth 17 Mar '99

17 Mar '99

OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> writes: > From: edmundo(a)rano.demon.co.uk > Subject: "relocation truncated" > Date: Sun, 14 Mar 1999 12:48:47 +0000 > > > Does anyone with knowledge of x86 assembler understand this problem, > > and can they fix it? > > l4-oskit is rather old version of OSKit, and more recent version can > be compiled without such a error. I haven't compiled Fiasco with > oskit-0.97, but that will be fine, perhaps. The latest version is > available from the home page of the Flux Research Group, > http://www.cs.utah.edu/projects/flexmach/. There are a few changes necessary to compile Fiasco with the new OSKit. I have already done these changes once in a quick-and-dirty fashion, but I haven't merged them into the main trunk yet (and haven't updated them lately) because we haven't decided yet how and when we switch all our other DROPS components over to the new OSKit. Also, the new OSKit is so large that distributing a modified version of it is inconvenient; that's why we have to make sure that the latest official version fits our needs. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

2 1

Re: 486/Pentium version problems
by Michael Hohmuth 17 Mar '99

17 Mar '99

Edmund GRIMLEY EVANS <edmundo(a)rano.demon.co.uk> writes: > Following the instructions at os.inf.tu-dresden.de/fiasco/use.html I > built Fiasco and the Hello World server worked. Excellent! Cool! > 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. This is a misleading message that should be fixed. It only means that Rmgr is not running on L4/486, and that it *will* try to request 4-MB pages from its Sigma0 memory server. Can you give us a hint on what exectly went wrong, or where the system hung? > 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? They should run on both architectures. However, I haven't tested Fiasco (main) a lot on 486s, so there may be minor problems. The other programs have been tested on both Pentiums and 486s. Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: implementations of L4
by Michael Hohmuth 17 Mar '99

17 Mar '99

Edmund GRIMLEY EVANS <edmundo(a)rano.demon.co.uk> writes: > 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. Fiasco hasn't really been designed for portability, even though it might serve as a model for future implementations (if someone would clean it up a bit ;). The reason it has been implemented in a high-level language is that this improves its maintainability. > * 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? No. There is no such beast. > * 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? Yes, that's right. The L4 web site at <URL:http://os.inf.tu-dresden.de/L4/> needs a major overhaul. Thanks for your suggestion. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

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

Re: multiple servers
by Paul Phillips 27 Jan '99

27 Jan '99

Michael, Thanks again for responding. 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): 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); } Thanks, Paul Phillips -----Original Message----- From: Michael Hohmuth <hohmuth(a)innocent.com> 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: Tuesday, January 26, 1999 11:21 AM Subject: Re: multiple servers >Paul, > >thanks for trying Fiasco and L4Linux! > >"Paul Phillips" <pphillips(a)ivue.com> writes: > >> Right now I'm trying to run two servers concurrently. This is just a >> "proof of concept" for now. I am trying to run the "hello" server >> (relocated to 0x2400000) along with the L4-Linux server. I load the >> "hello"server first and then L4-Linux. L4-linux gets to the >> "Calibrating delay loop.." and hangs. I am obviously forgetting >> something here. Is the printf used by the hello server causing a >> problem? > >No, I don't think so. > >I take it that without `hello', L4Linux works correctly. My guess >would be that hello has trouble running at the memory location you >linked it at. Did you see `hello's output ("hello: My thread-id >is...") at least once? > >Did you get `hello' to work without L4Linux? > >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. > >> BTW - I ran across the problem of the "relocation truncated ...." The >> problem is in the oskit/libsmp/x86/boot.S which contains the >> trampoline code. When the jump is made to the 32 bit code some linkers >> have a problem resolving the long jump. >> >> ljmp $KERNEL_CS,......... >> >> The fix is to put the ".code32" before the jump. This problem has >> been fixed in the latest release of the OSkit. > >Thanks for the hint! > >Michael >-- >hohmuth(a)innocent.com, hohmuth(a)sax.de >http://www.sax.de/~hohmuth/

1 0

Re: gcc VS g++
by Paul Phillips 26 Jan '99

26 Jan '99

Thanks Michael, 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 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. One of your correspondence mentions a version of egcs, and I'm not sure of the relationships between gcc and egcs. Thanks, Paul Phillips -----Original Message----- From: Michael Hohmuth <hohmuth(a)innocent.com> 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: Tuesday, January 26, 1999 11:22 AM Subject: Re: gcc VS g++ >"Paul Phillips" <pphillips(a)ivue.com> writes: > >> When I compile Fiasco with CC=gcc I get a message : >> >> KERNEL: no page fault handler for region: 0xffff0000, error 0x0. > >> However, when I compile with CC=g++ I get no such message. > >> Any ideas why this is happening? > >Obviously, the `gcc' driver uses a different compiler than the `g++' >driver ("gcc -v" and "g++ -v" should tell you that.) However, without >further context (like a backtrace) it's hard to tell what exactly went >wrong. > >Michael

1 0

Re: multiple servers
by Paul Phillips 26 Jan '99

26 Jan '99

Michael, Thanks for responding, -----Original Message----- From: Michael Hohmuth <hohmuth(a)innocent.com> 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: Tuesday, January 26, 1999 11:21 AM Subject: Re: multiple servers >Paul, > >thanks for trying Fiasco and L4Linux! > >"Paul Phillips" <pphillips(a)ivue.com> writes: > >> Right now I'm trying to run two servers concurrently. This is just a >> "proof of concept" for now. I am trying to run the "hello" server >> (relocated to 0x2400000) along with the L4-Linux server. I load the >> "hello"server first and then L4-Linux. L4-linux gets to the >> "Calibrating delay loop.." and hangs. I am obviously forgetting >> something here. Is the printf used by the hello server causing a >> problem? > >No, I don't think so. > >I take it that without `hello', L4Linux works correctly. My guess >would be that hello has trouble running at the memory location you >linked it at. Did you see `hello's output ("hello: My thread-id >is...") at least once? > Yes, both 'hello' and L4Linux run correctly (some bugs in L4, but that's OK for now) when running as a single server. I do see the 'hello' output one time only: "hello: My id is 80000" , in the middle of the Linux bootup messages. I tried 'hello' at the default 0x200000 as well as 0x2400000. Both perform the same. >Did you get `hello' to work without L4Linux? > Yes, no problem! >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. I have GDB running, but because the system hangs I can't generate a backtrace. Any ideas? Thanks Paul Phillips

1 0

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

26 Jan '99

"Paul Phillips" <pphillips(a)ivue.com> writes: > When I compile Fiasco with CC=gcc I get a message : > > KERNEL: no page fault handler for region: 0xffff0000, error 0x0. > However, when I compile with CC=g++ I get no such message. > Any ideas why this is happening? Obviously, the `gcc' driver uses a different compiler than the `g++' driver ("gcc -v" and "g++ -v" should tell you that.) However, without further context (like a backtrace) it's hard to tell what exactly went wrong. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: multiple servers
by Michael Hohmuth 26 Jan '99

26 Jan '99

Paul, thanks for trying Fiasco and L4Linux! "Paul Phillips" <pphillips(a)ivue.com> writes: > Right now I'm trying to run two servers concurrently. This is just a > "proof of concept" for now. I am trying to run the "hello" server > (relocated to 0x2400000) along with the L4-Linux server. I load the > "hello"server first and then L4-Linux. L4-linux gets to the > "Calibrating delay loop.." and hangs. I am obviously forgetting > something here. Is the printf used by the hello server causing a > problem? No, I don't think so. I take it that without `hello', L4Linux works correctly. My guess would be that hello has trouble running at the memory location you linked it at. Did you see `hello's output ("hello: My thread-id is...") at least once? Did you get `hello' to work without L4Linux? 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. > BTW - I ran across the problem of the "relocation truncated ...." The > problem is in the oskit/libsmp/x86/boot.S which contains the > trampoline code. When the jump is made to the 32 bit code some linkers > have a problem resolving the long jump. > > ljmp $KERNEL_CS,......... > > The fix is to put the ".code32" before the jump. This problem has > been fixed in the latest release of the OSkit. Thanks for the hint! Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

2025

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