l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wortel problems


From: Johan Rydberg
Subject: Re: wortel problems
Date: Wed, 1 Oct 2003 16:00:26 +0200

Espen Skoglund <address@hidden> 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)
s0:  0x0030a000-0x0034ffff   0xffffffff (anythread)
s0:  0x00357000-0x03f76fff   0xffffffff (anythread)
s0:
s0: Free pool (non-conventional memory):
s0:  0x002d0000-0x002d1fff   0xffffffff (anythread)
s0:
s0: Alloc pool:
s0:  0x00000000-0x00003fff   0x00034001 (kernel)
s0:  0x00005000-0x000c2fff   0x00034001 (kernel)
s0:  0x00100000-0x00180fff   0x00034001 (kernel)
s0:  0x00216000-0x00216fff   0x000bc001 (root server)
s0:  0x00290000-0x002ccfff   0x000bc001 (root server)
s0:  0x00300000-0x00309fff   0x000bc001 (root server)
s0:  0x00350000-0x00356fff   0x000bc001 (root server)

With a patched 0.2 version of sigma, it fails on addresses greater than
(1 << 22), that it _can_ allocate memory for.  For sizes less than
(1 << 23), it works perfectly until the kernel runs out of memory.

When size is (1 << 24), sigma0 can allocate memory, but when it sends over
the fpage, it fails on address 1400000 for some reason (base address is
1000000).   It seems that it can map address 1000000 to 13ff000 without
any problems.

Dumping the ptable gives the following information:

01000000 [0005e001]: tree=c005e000
01000000 [01000002]:   phys=01000000  map=c004f3d0   4KB rwx (~~~) user
01001000 [01001002]:   phys=01001000  map=c004f3dc   4KB rwx (~~~) user
...
013fe000 [013fe002]:   phys=013fe000  map=c006240c   4KB rwx (~~~) user
013ff000 [013ff002]:   phys=013ff000  map=c0062418   4KB rwx (~~~) user
bf000000 [00050001]: tree=c0050000
bf000000 [0004e182]:   phys=0004e000  map=bf000000   4KB rwx (RWX) user
..

I changed the kernel so it dumped a few extra variables, that might be
usefull:

map_fpage(from=c0043000, to=c004a000, base=1000000, sndfp=1000187, rcvfp=10)
map_fpage(t_size=0, f_addr=01400000, offset=0, t_num=c00, f_num=c00, f_size=0, 
          t_addr=1400000)
--- KD# map_fpage(): Mapping already exists. ---


-- 
Johan Rydberg, Free Software Developer, Sweden
http://rtmk.sf.net | http://www.nongnu.org/guss/

Playing Hooverphonic - Someone




reply via email to

[Prev in Thread] Current Thread [Next in Thread]