Sample applications freeze during execution

[Andrew Price-5]

Hi,

I'm currently evaluating using the L4ka:Pistachio kernel on the x86 architecture as the core of an operating system project I am part of.

I'm building from the latest sources on the Mercury repository system with GCC 4.4.1 and Binutils 2.19.1.20090418 on Arch Linux (Linux 2.6.x). The build process completes flawlessly. I am trying to boot into the kernel through GRUB (I'm testing on VMware Workstation 6.5.2), by loading kickstart at the kernel, followed by the modules x86-kernel, sigma0, then one of the sample applications (pingpong, grabmem. l4test). Kickstart boots into the system, but once the kernel has loaded the system appears nonoperational:

[pasted below]

KickStart 0.13.06

Detected multiboot compliant loader

_kernel    (0x00816000-0x00840995)   => 0x001444a0

  (0x00816000-0x00829192) -> 0x00100000-0x00113192

  (0x0082a000-0x0082a4b8) -> 0x00115000-0x001154b8

  (0x0082b000-0x0083500e) -> 0x00116000-0x0012000e

  (0x00836000-0x00839fe8) -> 0x00141000-0x00144fe8

 sigma0    (0x00841000-0x00857a8d)   => 0x00020000

  (0x00842000-0x0084a410) -> 0x00020000-0x00028410

 roottask  (0x00858000-0x0085ee02)   => 0x00300000

  (0x008f9000-0x0085d040) -> 0x00300000-0x00304040

Launching kernel ...

[/paste end]

But nothing more.

When I built the kernel will spin wheels enabled, I noticed it was animating as if the kernel was still functioning. I also attempted building with other kernel configurations enabled and disabled - all resulting in the same outcome. I then attempted to modify one of the sample applications (grabmem), and I discovered that I could write directly to the screen buffer (0xb8000), which shows the application does load (but it is strange since as far as I know, printf also writes directly to the screen buffer, but printf does not appear to be doing anything). Also at the same time I discovered the system hangs during any attempt to communicate with sigma0 (through the functions provided in l4/sigma0.h).

I also noticed, in the kernel's build directory there is an include directory. However I don't see these files being referenced anywhere by the user code.

( The prebuild 0.4 image functions correctly under VMWare. )

I don't understand what I am doing wrong, and if I may have missed any steps to get the system functioning?

Also, I could write directly to 0xb8000 from the roottask. From my understanding, only sigma0 was suppose to have all physical memory allocated to it at boot, therefore for my roottask (or any other thread) to access the physical memory at this location I would need it mapped into the thread's local address space. So could some one please explain the memory protection and clear this up? Also, I'm unsure of at what location in virtual memory the kernel has been mapped.

Thanks for all your help,

Andrew

[Philipp Kupferschmied]

Hi Andrew,

> I then attempted to modify one of the sample applications (grabmem),
> and I discovered that I could write directly to the screen buffer (0xb8000),
> which shows the application does load (but it is strange since as far as I
> know, printf also writes directly to the screen buffer, but printf does not
> appear to be doing anything).

If I'm not mistaken, both the kernel and the user implementation of printf
write to the serial port and not to the screen buffer by default.
For the kernel, you can change that behavior in the Debugger section of the
configuration menu by changing 'Kernel Debugger console' from 'Serial Port'
to 'Keyboard'.

> Also at the same time I discovered the system
> hangs during any attempt to communicate with sigma0 (through the functions
> provided in l4/sigma0.h).

Once you have proper debugger output, you could enable some tracepoints to
find out what's going on here. A hanging system at that early stage might
for example be caused by incorrectly handled pagefaults.

> I also noticed, in the kernel's build directory there is an include
> directory. However I don't see these files being referenced anywhere by the
> user code.

Not sure if I understand your problem here. The generated header files are just
used for building the kernel, not for building userlevel stuff.

> Also, I could write directly to 0xb8000 from the roottask. From my
> understanding, only sigma0 was suppose to have all physical memory allocated
> to it at boot, therefore for my roottask (or any other thread) to access the
> physical memory at this location I would need it mapped into the thread's
> local address space. So could some one please explain the memory protection
> and clear this up? Also, I'm unsure of at what location in virtual memory the
> kernel has been mapped.

When a pagefault occurs in the roottask, a pagefault IPC is sent to Sigma0.
If the pagefault occurred on a page of conventional memory (*), Sigma0 will
simply hand out the appropriate page (so the kernel will map it into the faulting
thread's address space), but only once. Thus, the roottask or some kind of memory
manager could/should simply grab all required memory at startup and then implement
more sophisticated pagefault handling policies.

(*) Note that the framebuffer is not part of the conventional memory pool, but
it seems that Sigma0 hands it out anyway when it's just touched.

HTH,
Philipp