Re: Resolved: Unexpected page fault from 0xdc003 ad address 0x??

[Marcus Brinkmann]

At Thu, 26 Aug 2004 11:13:12 +0200,
Bas Wijnen <address@hidden> wrote:
> wortel.h:wortel_get_task_cap.)  Also, 0xdc003 is not physmem, it is task.
> Physmem is 0xdc002 (I added some extra debugging output to see such things.)

The lower 14 bits are actually the task ID: 1 wortel, 2 physmem, 3
task.  The upper bits are the thread number.  physmem starts out with
"cc002" (initially main thread, later server thread), "d0002" (later main
thread), "d4002" and "d8002" (worker threads).

> I have the feeling it has to do with the code size.  When I try to start a
> task server which only does puts ("task is running");, it works fine.

I can reproduce this now.  The issue was easily found: physmem's
container map function doesn't take into account the destination
virtual address.  The container is mapped into physmem at 0x1e6000,
but task wants to map the first 0x7000 to the load address 0x8048000.
What happens is that physmem splits it up into the fpages
0x1e6000/0x2000, 0x1e8000/0x4000 and 0x1ec000/0x1000.  Mapping
0x1e6000/0x2000 to 0x8048000 works fine, but mapping 0x1e8000/0x4000
to 0x804a000 fails because 0x804a000 is misaligned for a 0x4000 large
fpage.  So what happens is that the page will actually be mapped to
0x8048000 (rounding down 0x804a000 to the next 0x4000 large fpage),
overwriting the first mapping.  You end up with the wrong code at the
wrong place, which breaks havoc as soon as you jump to the entry point
of task from the startup code.

How I debugged this?  I set a breakpoint at the startup code, and
looked at the startup data (the mappings).  Those looked fine.  I then
looked at the page tables, which showed a gap where the second half of
the 0x4000 page should have been (actually, I didn't notice that gap
at first, but after adding debug output to physmem's container_map,
things became very clear).

I actually knew about this problem earlier, but didn't think of it
anymore.  l4_fpage_span works fine for idem-potent mappings as used
from wortel to physmem, but apparently it needs to take another
argument to take the destination address, and then take the maximum
allowed alignment for each individual fpage.

The only problem is that this leads to potentially a very large list
of fpages spanning a certain map operation (consider mapping the
region 0x0000-0x8000 to 0x1000-0x9000, and similar for much larger
regions).  So, we might have to abort the operation at some point if
we run out of space for map items in the message, and return a partial
result (always allowed).  But then the startup code must keep
requesting partial mappings until it got all of them.  (The cheap way
out would be to acknowledge that we only support 4KB pages on ia32
[ignoring 4MB pages for now], and map each page individually).

For now, however, we only map very small chunks, so it will fit into a
single message.  I will add the necessary code to physmem.  The
startup code can wait.

Thanks,
Marcus