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
<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:
Re: NFS mounting and channel access Jeff Hill
- Next:
EPICS meeting R. Keitel
- 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
|