Johan Rydberg | 1 Oct 04:10 2003
Picon

wortel problems

Hi,

I have some small problems with wortel(+sigma0+physmem) that someone
might be able to help me with.

>From wortel.c, function serve_bootstrap_requests:

  /* Allocate a single page at address 0, because we don't want to
     bother anybody with that silly page.  */
  sigma0_get_fpage (l4_fpage (0, l4_min_page_size ()));

I'm not really sure why this is done, but it's not valid for PowerPC 
(region 0-0x3000 is used for exception vectors, and sigma0 treats it
as reserved.)   Why does it allocate and throw away page zero? I've 
just commented out this piece of code for the moment.

Next thing, same file, same function:

  /* Give out the memory.  First our unused fpages, then the
     fpages we can get from sigma0.  */
  if (wortel_unused_fpages_count)
    fpage = wortel_unused_fpages[--wortel_unused_fpages_count];
  else
    do
      {
        fpage = sigma0_get_any (get_mem_size);
        if (fpage.raw == l4_nilpage.raw)
          get_mem_size--;
      }
    while (fpage.raw == l4_nilpage.raw
(Continue reading)

Johan Rydberg | 1 Oct 04:23 2003
Picon

Re: wortel problems

Johan Rydberg <jrydberg <at> night.trouble.net> wrote:

: I don't know if something is failing in the communication between
: wortel and sigma0, but requesting a block of memory with the size
: if (1 << 31) makes the kernel break into the kernel debugger with
: the following message:
: 
:   map_fpage(from=c0043000, to=c004a000, base=0, sndfp=800001f7, rcvfp=10)
:   --- KD# map_fpage(): Mapping already exists. ---

I should maybe say that this also happens with the sigma0 patches [1]
that is said to correct similar (or these) problems.

It makes things a bit better though.  Sigma0 output:

...
s0: unable to allocate page of size 0x80000000 to 0x000bc001
s0: unable to allocate page of size 0x40000000 to 0x000bc001
s0: unable to allocate page of size 0x20000000 to 0x000bc001
s0: unable to allocate page of size 0x10000000 to 0x000bc001
s0: unable to allocate page of size 0x08000000 to 0x000bc001
s0: unable to allocate page of size 0x04000000 to 0x000bc001
s0: unable to allocate page of size 0x02000000 to 0x000bc001
map_fpage(from=c0043000, to=c004a000, base=1000000, sndfp=1000187, rcvfp=10)
--- KD# map_fpage(): Mapping already exists. ---

 [1] http://cgi.cse.unsw.edu.au/~sgoetz/cgi-bin/faqwiz/faqw.py?req=all#2.3

--

-- 
Johan Rydberg, Free Software Developer, Sweden
(Continue reading)

Uwe Dannowski | 1 Oct 07:57 2003
Picon

L4Ka::Pistachio CVS back online again

The public, read-only L4Ka::Pistachio CVS is back online again.
It now contains L4Ka::Pistachio 0.2 plus several post-0.2 fixes.
See

    http://l4ka.org/projects/pistachio/download.php

for details on how to access the CVS.

Uwe
Marcus Brinkmann | 1 Oct 08:56 2003
Picon

Re: wortel problems

On Wed, Oct 01, 2003 at 04:10:37AM +0200, Johan Rydberg wrote:
>   /* Allocate a single page at address 0, because we don't want to
>      bother anybody with that silly page.  */
>   sigma0_get_fpage (l4_fpage (0, l4_min_page_size ()));
> 
> I'm not really sure why this is done, but it's not valid for PowerPC 
> (region 0-0x3000 is used for exception vectors, and sigma0 treats it
> as reserved.)   Why does it allocate and throw away page zero? I've 
> just commented out this piece of code for the moment.

physmem uses 0 as the return value for a failed zalloc, so it can not be
used in physmem anyway.  Apart from that, mapping it into physmem at address
0 would prevent any exception from being created when dereferencing a null
pointer.  The best thing to do is to allocate the page at 0 and remap it
into physmem at a higher address (ie, add it to the end of available
memory), so it becomes usable.

Is this causing a panic on ppc, or does it just not work?   We can ignore
any failure (return value l4_nilpag0e) here.

> I don't know if something is failing in the communication between
> wortel and sigma0, but requesting a block of memory with the size
> if (1 << 31) makes the kernel break into the kernel debugger with
> the following message:
> 
>   map_fpage(from=c0043000, to=c004a000, base=0, sndfp=800001f7, rcvfp=10)
>   --- KD# map_fpage(): Mapping already exists. ---

sigma0 patch is supposed to fix that, if it doesn't I don't know why.

(Continue reading)

Maurizio Boriani | 1 Oct 11:51 2003
Picon

Re: RFC: PowerPC support for laden

On Tue, 2003-09-30 at 03:05, Johan Rydberg wrote:
> Hi,
> Some notes: The PowerPC platform doesn't currently have a 
> bootloader that supports modules (to my knowledge anyway), 
> therefor all modules must be embedded into one single binary
> which is loaded the the bootloader.  This binary, the piggyback,
> must parse the embedded binaries and start them.  
> 
> The build-piggyback script does exactly what the name tells you:
> it builds a finished piggyback binary from the laden binary and
> a set of modules given to the script.

I think sould be a good thing get module_table a bit complex adding it a
string for module name and another one for arg. So module_table will
has: word address for module start, module string name and module arg
string (more close to ia32 multiboot implemented by GRUB).

  .glob module_table
module_table:
  .long module_<name>_start
  .string "<name>\0"
  .string "<arg...>\0"
  ...
  ...
  .data
  .palign 12
module_<name>_start:
  .incbin "/...."
module_<name>_end:
  ...
(Continue reading)

Espen Skoglund | 1 Oct 18:40 2003
Picon

Re: wortel problems

[Espen Skoglund]
> Well, I haven't got a PowerPC to try this on.  Everything seems to
> work fine on ia32 and ia64, though.  I've attached a simple root task
> that grabs all memory from sigma0 using L4_Sigma0_GetAny().  This
> works for both ia32 and ia64.

Oh yeah, and this is with the current CVS (+ your patch).

	eSk
Marcus Brinkmann | 1 Oct 16:37 2003
Picon

Re: RFC: PowerPC support for laden

On Wed, Oct 01, 2003 at 11:51:31AM +0200, Maurizio Boriani wrote:
> I think sould be a good thing get module_table a bit complex adding it a
> string for module name and another one for arg. So module_table will
> has: word address for module start, module string name and module arg
> string (more close to ia32 multiboot implemented by GRUB).

We definitely need a comand line, but as one string (or maybe in argz form):

argv0\0argv1\0argv2\0\0

>   .long module_<name>_start
>   .string "<name>\0"
>   .string "<arg...>\0"

You need to create an index into a string table, so you don't get any
alignment issues.  Alternatively you need a size field and add padding.

> Another idea is to generalize this to have a "modulizer" which will be
> useful also for dde (serv and its modules to bootstrap) and others.

You should not mix this up.  This whole modules-into-laden thing is a hack.

Thanks,
Marcus

--

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus <at> gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann <at> ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
(Continue reading)

Espen Skoglund | 1 Oct 15:33 2003
Picon

Re: wortel problems

[Johan Rydberg]
> Johan Rydberg <jrydberg <at> night.trouble.net> wrote:
>> I don't know if something is failing in the communication between
>> wortel and sigma0, but requesting a block of memory with the size
>> if (1 << 31) makes the kernel break into the kernel debugger with
>> the following message:
>> 
>> map_fpage(from=c0043000, to=c004a000, base=0, sndfp=800001f7, rcvfp=10)
>> --- KD# map_fpage(): Mapping already exists. ---

> I should maybe say that this also happens with the sigma0 patches
> [1] that is said to correct similar (or these) problems.

You might want to try the version out of the CVS.  This is going to be
pretty much like the 0.3 release (and yes, it should fix all the
sigma0 problems).

	eSk
Johan Rydberg | 1 Oct 16:00 2003
Picon

Re: wortel problems

Espen Skoglund <esk <at> ira.uka.de> wrote:

: > I should maybe say that this also happens with the sigma0 patches
: > [1] that is said to correct similar (or these) problems.
: 
: You might want to try the version out of the CVS.  This is going to be
: pretty much like the 0.3 release (and yes, it should fix all the
: sigma0 problems).

I've tried with both the CVS version of sigma0, and a patched 0.2 version,
but neither of them work.  

The CVS version faults directly on size (1 << 31) :

s0: got msg from 0x000bc001, (0xffa0, 0xfffffdf0, 0x00000000)
s0: allocate_page (tid: 0xbc001, log2size: 31)
map_fpage(from=c0043000, to=c004a000, base=80000000, sndfp=800001f7, rcvfp=10)
--- KD# map_fpage(): Mapping already exists. ---

The memory pools look sane to me:

s0: Free memregion structures: 16
s0:
s0: Free pool (conventional memory):
s0:  0x00004000-0x00004fff   0xffffffff (anythread)
s0:  0x000c3000-0x000fffff   0xffffffff (anythread)
s0:  0x00181000-0x00215fff   0xffffffff (anythread)
s0:  0x00217000-0x0028ffff   0xffffffff (anythread)
s0:  0x002cd000-0x002cffff   0xffffffff (anythread)
s0:  0x002d2000-0x002fffff   0xffffffff (anythread)
(Continue reading)

Johan Rydberg | 1 Oct 16:21 2003
Picon

Re: wortel problems

Espen Skoglund <esk <at> ira.uka.de> wrote:

: You might want to try the version out of the CVS.  This is going to be
: pretty much like the 0.3 release (and yes, it should fix all the
: sigma0 problems).

If you apply the included patch, CVS sigma0 works as 0.2+patches.
By that I mean, it doesn't break directly on requesting (1 << 31),
but breaks on requests > (1 << 22), that it can allocate.

Index: sigma0.cc
===================================================================
RCS file: /public-cvs/pistachio/user/serv/sigma0/sigma0.cc,v
retrieving revision 1.18.2.5
diff -u -p -r1.18.2.5 sigma0.cc
--- sigma0.cc	26 Sep 2003 18:21:22 -0000	1.18.2.5
+++ sigma0.cc	1 Oct 2003 14:18:47 -0000
 <at>  <at>  -505,7 +505,8  <at>  <at>  L4_Fpage_t memregion_t::allocate (L4_Wor
     L4_Word_t low_a = (low + size - 1) & ~(size-1);
     L4_Fpage_t ret;

-    if ((high_a - low_a) < size || (owner != tid && owner != L4_anythread))
+    if (low_a > high_a || (high_a - low_a) < size
+       || (owner != tid && owner != L4_anythread))
     {
 	// Allocation failed
 	ret = L4_Nilpage;

Gmane