Just I could boot L4-Linux and execute "ls" etc on 486, without rebooting.
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. See below.
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.
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.
It took me ages to discover how to find out the current location (program counter) of a given thread. (If you've got thread_t *t, the thread is running at *(void *)((char *)t+0x7ec), IIRC.)
If there's one good thing to come out of my playing around with L4-Linux, I've learnt a bit about GDB ...
(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?)
Edmund
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 ...