EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Resman problems...
From: [email protected]
To: [email protected]
Date: Fri, 7 Aug 1998 07:51:22 -0600 (MDT)
	Hi.  We have been attempting to run Resman on our baja 68060, but we run
out of memory.  We don't think it is a software problem, as the program runs
just fine on a similar system.  Here is our output:

------------------------------------------------------------------------------
	
-> < st.resman
resman(0, 0, 5, "/home/creek/best/sqeapp/iocBoot/ioctest",1)
Grand Interconnect VXI Resource Manager version 2.1 beta 3 (7/18/96)
Copyright (c) 1995, 1996, KineticSystems Corporation.
For help, use -h option.

Path to RM tables is </home/creek/best/sqeapp/iocBoot/ioctest>

Path to RM tables is </home/creek/best/sqeapp/iocBoot/ioctest/>
0x1eb80e0 (tShell): memPartAlloc: block too big - 84 in partition 0xa02e8.

* Warning:  Could not create a nonvxi entry: S_memLib_NOT_ENOUGH_MEMORY


Access Fault
Program Counter: 0x00077580
Status Register: 0x3000
Access Address : 0x48562c4f
Fault Status   : 0x01450020

  8c9e _vxTaskEntry   +10 : _shell (1, 0, 0, 0, 0, 0, 0, 0, 0, 0)
 2d236 _shell         +12a: 2d254 ([1, 0, 3, 7f, 0])
 2d3c8 _shell         +2bc: _execute ([1eb8002, 1, 0, 0, &_ioGlobalStdSet])
 2d4a8 _execute       +68 : 2d254 ([0, 0, 1, ffffffff, 1eb8002])
 2d3c8 _shell         +2bc: _execute ([1eb7f3a, 0, c, c, &_ioGlobalStdGet])
 2d4e2 _execute       +a2 : _yyparse ([0, 0, ffffffff, 1eb7f3a, 1eb8002])
 861da _yyparse       +520: 84bc6 (1eefc28, 1eefc48)
 84cca _yystart       +728: _resman (0, 0, 5, 1ffd944, 1, 0, 0, 0, 0, 0, 0, 0)
1e81994 _resman        +28 : _rmShell ([0, 0, 5, 1ffd944, 2])
1e82212 _rmShell       +168: _getnonVxi ([1eb79ec, &_yyval, d, c, 1])
1e81b02 _getnonVxi     +bc : _abort (1eef8a8, 1e819dd)
 1629c _abort         +8  : _raise ([6, 1eb7998, 1e81b08, 1eef8a8, 1e819dd])
 25772 _raise         +e  : _kill ([1eb80e0, 6, 1eb7874, 162a2, 6])
 2585a _kill          +e2 : 25fb4 ([1eb80e0, 6, 0, 1eef8a8, 1eb7868])
 25fd0 _sigPendDestroy+90 : 25c30 ([1eb80e0, 1eb781c, d, c, 6])
 25e48 _sigqueue      +5d6: _sigqueue ([1eb779c, 1eb77b4, 1, 1eef57c, d])
 25a36 _sigqueue      +1c4: _shellRestart (6, 0, 1eb779c)
 2d0b0 _shellRestart  +a8 : _trcStack ([1e922, &_dbgPrintCall, 1eb80e0, 2d06a, 
6])
 7726c _trcStack      +28 : 77560 ([48562c4f, 1eb80e0, 20, 1eb80e0, 1eb779c])
shell restarted.

-> 0x1ef5eb8 (tPortmapd): memPartAlloc: block too big - 1200 in partition 
0xa02e8.
0x1ef5eb8 (tPortmapd): panic: rpc: svc_getreq: out of memory.

------------------------------------------------------------------------------

	Here is the code we are using to allocate the memory.  An example of 
this is in the Tornado manuals.

------------------------------------------------------------------------------	
    /* a32 space (some more, R.Q., 4/28/97, extra needed for one V200) */
    {
    (void *) 0x42000000,
    (void *) 0x42000000,
    0x02000000,    /* 32 Mbytes */
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
    },

    /* a32 space (some more, R.Q., for second V200) */
    {
    (void *) 0x44000000,
    (void *) 0x44000000,
    0x02000000,    /* 32 Mbytes */
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
    },

    /* a32 space (some more, R.Q., also for second V200) */
    {
    (void *) 0x46000000,
    (void *) 0x46000000,
    0x02000000,    /* 32 Mbytes */
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
    },
-------------------------------------------------------------------------------

	There are about 17 more of these 8 line statements of varying sizes.  
Usually they are around 32 Mbytes, but the later ones are the Flash ROM, and are
around 512k.
	Resman is a resource manager.  It allocates extra memory in the 68060 
for more programs and data.  As you can see, it says that the memory block is 
too big, which we assume means we ran out of memory.  From what we've been told,
we shouldn't have run out of memory.  Any ideas on why this is and/or how to fix
it would be appreciated.  Thanks.
	Donner

Replies:
Re: Resman problems... Andrew Johnson

Navigate by Date:
Prev: RE: R3.13.0.beta12 and C++ libraries Jeff Hill
Next: Re: Resman problems... Andrew Johnson
Index: 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Meeting in Berlin. Bob Dalesio
Next: Re: Resman problems... Andrew Johnson
Index: 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·