- l4-hackers - example.com Site

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