Hi,
On 2012-06-08 Kevin Peterson wrote:
> I'm getting an access fault during iocInit when I load
> iocAdminVxWorks.db from devIocStats:
> My vme is using VxWorks 6.8, base-3.14.12.2, and devIocStats-3-1-7 (from
> synApps_5_6). The problem also occurs with devIocStats 3.1.9.
>
> I've used the debugger to trace the fault to the iocInit.c:doRecordPini
> for the record iockmp:DAT_MBUF_MAX.
>
> The problem doesn't occur with VxWorks 5.5.2.
Has anybody looked at upgrading iocStats for the new network stack in vxWorks
6.8? Wind River replaced the network stack code and associated buffer pool
(again), such that the code in iocStats/devIocStats/os/vxWorks/osdClustInfo.c
is now wrong; on our vxWorks 6.8 systems both _pNetSysPool and _pNetDpool are
NULL, so neither devIocStatsGetClusterInfo() nor devIocStatsGetClusterUsage()
are correct any more. For some reason the APS Controls IOCs that have loaded
iocStats have not been crashing when they initialize the record that Kevin
mentions above, but his IOC (using the same vxWorks OS configuration, but a
different CPU board) does crash.
- Andrew
--
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte
- References:
- VxWorks 6.8 & devIocStats Kevin Peterson
- Navigate by Date:
- Prev:
VxWorks 6.8 & devIocStats Kevin Peterson
- Next:
RE: ASYN 4-19 createParam return status Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
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:
VxWorks 6.8 & devIocStats Kevin Peterson
- Next:
Runaway connection count on IOC michael.abbott
- Index:
1994
1995
1996
1997
1998
1999
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
|