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: RE: Resman problems...
From: [email protected] (Jeff Hill)
To: "'[email protected]'" <[email protected]>, "[email protected]" <[email protected]>
Date: Fri, 7 Aug 1998 10:20:21 -0600
All,

Note that the VXI resource manager involved here is from Kinetics systems corporation,
and it isn't the VXI resource manager that is supplied in EPICS base. The resource manager
supplied with EPICS was written before commercial options became available under vxWorks. 
There is certainly no reason why a commercial resource manager would be incompatible with 
EPICS. I mention this only as an explanation of why on this mail list we are not easily able 
to easily answer questions about the Kinetic Systems product involved here.

In reference to Andrew Johnson's response:
I suspect  that the Kinetic Systems resource manager involved here is attempting to program into some
VXI cards their address range in A32 space. I suspect that Donner needs the 68060 to become VXI bus master
and access some VXI cards in A32 space, and that the VXI cards don't have bus master capabilities. I am 
guessing that the Kinetics Systems resource manager has set up two specialized memory partitions for A32 VXI
cards and A24 VXI cards, and that Donner will need to use memPartAddToPool() instead of memAddToPool()
to expand these regions. He will need to of course consult the Kinetics Systems documentation to determine 
the correct partition id to use, or instead I am guessing that Kinetic Systems supplies convenience routines or configuration 
parameters that determine the regions in A24 and A32 that can be assigned to VXI cards by the resource manager.

Admittedly all of this is pure speculation on my part.

Jeff

On Friday, August 07, 1998 7:51 AM, [email protected] [SMTP:[email protected]] wrote:
> 
> 	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

Navigate by Date:
Prev: tsDefs.... Bonnie Madre
Next: clarification of Resman problems Elaine Best
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: Re: Resman problems... Andrew Johnson
Next: tsDefs.... Bonnie Madre
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 ·