EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  <19971998  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  Index 1994  1995  1996  <19971998  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 
<== Date ==> <== Thread ==>

Subject: Re: NFS mounting and channel access
From: "Jeff Hill" <[email protected]>
To: "Ralph Quan" <[email protected]>, <[email protected]>
Cc: <[email protected]>
Date: Wed, 9 Apr 1997 13:46:23 -0600
Hello all,

Sorry about the late reply - I have been on vacation.

----------
> From: Ralph Quan <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: NFS mounting and channel access
> Date: Sunday, March 30, 1997 6:45 PM
> 
> 
> Has anyone seen the following problem:
> 
> We're using Epics 3.12 on a Heurikon Nitro60 IOC with vxWorks 5.2,
> and when not using NFS mounting, all seems normal.
> However, when using the NFS mounting and channel access to invoke a
> function on the IOC, we've gotten a variety of errors involving 
> channel access after we write to a file through the NFS mount.
> Invoking the function directly from the vxWorks shell 
> does not create a problem.
> This problem occurs with a Dec Alpha running Epics 3.12 as well as with
> a Sun Sparc2 running Epics 3.11.

I just rebooted my Heurikon Nitro60 IOC so that it uses NFS, vxWorks 5.2,
and EPICS 3.13. I ran the standard tests and there does not appear to
be any problems with this configuration. I have used NFS many times with
EPICS 3.12 in the past without problems.

Are you experiencing an easily reproducible fault or an intermittent fault?

> 
> For example, here is some of the vxWorks output:
> 
> CA event: A call to "assert (0)" failed in ../caserverio.c at 143
> Please send a copy of the output from "tt (0xcce09c)" and a copy of this
message
> to the author or "[email protected]"
> task: 0Xd153e4 taskwd
> task cda700  suspended
> task cce09c CA event suspended
> 
> -> tt (0xcce09c)
>  12012 _vxTaskEntry   +10 : _event_task (cce22c, 0, 0, 0, 0, 0, 0, 0, 0,
0)
> e5337c _event_task    +88 : e53524 (cce24e)
> e535ce _event_task    +2da: e6cc0c (cfad90, d00084, 0, ccebca)
> e6cff4 _write_notify_reply+1490: _cas_send_msg (cd126c, 0)
> e692ae _cas_send_msg  +1b6: _epicsAssert (e690ba, 8f, e690b8)
> e7a32e _epicsAssert   +56 : _taskSuspend (cce09c)
> value = 0 = 0x0
> 

The above would occur only if the internal data structures of the CA server

have been corrupted. Is it possible that the use of NFS has rearranged
the memory allocation within your IOC and therefore placed the ca server's
data structures in a position where some errant application program
is writing on them?

Please reproduce this problem in a compact EPICS system that does not
include your site specific modifications and send us a copy of the ASCII
database and any other configuration/startup files involved.

Thanks.

Jeff

Navigate by Date:
Prev: Re: ioc re-connect problem Jeff Hill
Next: R3.13 for HP-UX Johnny Tang
Index: 1994  1995  1996  <19971998  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: Re: NFS mounting and channel access Jeff Hill
Next: EPICS meeting R. Keitel
Index: 1994  1995  1996  <19971998  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 
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 ·