Hi Jeff,
Thanks for running the tests.
We see this same problem from an application running at priority 102. I
was using ca_test in an attempt to isolate the behaviour from our
applications. Connections from the host to the IOC using ca_test
succeed when ca_test on the ioc fail.
Our network masks are now set at FFFFFF00. We spent a day last week
upgrading to this more restrictive mask on all our iocs when our hosts
changed to the same mask for security reasons.
I've been hoping to get the time to move to R3.13.4 and now looks like a
good time to give it a shot. I'll make sure that everything is built
against the same EPICS version.
Thanks again.
Geoff
Jeff Hill wrote:
>
> Geoff,
>
> I am unable to reproduce the behavior you describe with
> vxWorks 5.4 / pc486 BSP and EPICS R3.13.3 at our site.
>
> Do you see this problem only with ca_test or do other IOC
> initiated CA connections from the sequencer or the database
> links also fail?
>
> Does ca_test fail to connect to this IOC when it is run from
> a workstation?
>
> Does your network have many devices that are configured with
> the wrong subnet mask. If so this can cause problems with
> CA broadcasting based name resolution. This can be detected
> if you run "snoop icmp" on a Solaris machine and you
> see many ICMP destination unreachable responses to CA's
> broadcasted attempts to find process variables.
>
> I notice that the R3.14 version of ca_test has been upgraded to
> call ca_clear_channel() and ca_task_exit() to clean up before it
> returns. This might result in improved behavior under vxWorks.
> Nevertheless, I was unable to reproduce your problem with the
> earlier R3.13 version of ca_test on vxWorks 5.4.
>
> Running a CA program on vxWorks directly from the shell can
> be problematic because (on vxWorks 5.4) the shell by default
> runs at one notch below the highest possible priority. This might
> cause problems because CA spawns off various auxiliary threads
> that run at priorities above and below the priority of the
> initiating thread. You could avoid these problems
> by spawning ca_test to run at a lower priority. Nevertheless, I
> was unable to reproduce your problem with the earlier R3.13
> version of ca_test initiating at the shells default priority
> (on vxWorks 5.4 this is priority level 1). Imp not certain of
> this, but I seem to recall that earlier version (possibly
> your vxWorks 5.3.1) run the shell at the very highest priority
> (priority level 0).
>
> Make certain that the ca_test that you are using was compiled
> against the same version of EPICS that you have loaded into your
> IOC.
>
> Jeff
>
> > -----Original Message-----
> > From: Geoff Savage [mailto:[email protected]]
> > Sent: Thursday, March 29, 2001 10:00 AM
> > To: [email protected]
> > Subject: Re: ca client connection pattern
> >
> >
> > I neglected to include an error message. Here is the same command
> > (ca_test) issued three times in a row.
> >
> > -> ld < ca_test.o
> >
> > value = 67088952 = 0x3ffb238
> > -> ca_test "CTL_PROC_00/MEM"
> >
> > Not Found CTL_PROC_00/MEM
> > value = -1 = 0xffffffff = dataMutex + 0xfc22c4f7
> > ->
> > ->
> > ->
> > ->
> > -> ca_test "CTL_PROC_00/MEM"
> >
> > name: CTL_PROC_00/MEM
> > native type: -1
> > native count: 0
> > CA.Client.Diagnostic..............................................
> > Message: "The request was ignored because the specified channel is
> > disconnec
> > ted"
> > Severity: Error
> > Source File: ../ca_test.c Line Number: 193
> >
> > < I hit ^C here >
> >
> > 178934 vxTaskEntry +60 : shell ()
> > 155cbc shell +18c: 155ce8 ()
> > 155ef0 shell +3c0: execute ()
> > 156070 execute +d8 : yyparse ()
> > 18ef78 yyparse +7a8: 18cedc ()
> > 18d054 yystart +8f8: ca_test ()
> > 3b790a0 ca_test +18 : 3b79120 ()
> > 3b79348 ca_test +2c0: ca_signal_with_file_and_lineno ()
> > 3c97eac ca_signal_with_file_and_lineno+12c: taskSuspend ()
> > tShell restarted.
> >
> > -> ca_test "CTL_PROC_00/MEM"
> >
> > name: CTL_PROC_00/MEM
> > native type: 6
> > native count: 1
> > DBR_STRING 57.60
> > DBR_SHORT 57
> > DBR_FLOAT 57.6009
> > DBR_ENUM 57
> > DBR_CHAR 57
> > DBR_LONG
> > 57
> > DBR_DOUBLE 57.6009
> > DBR_STS_STRING 0 0 Value: 57.60
> > DBR_STS_SHORT 0 0 Value: 57
> > DBR_STS_FLOAT 0 0 Value: 57.6009
> > DBR_STS_ENUM 0 0 Value: 57
> > DBR_STS_CHAR 0 0 Value: 57
> > DBR_STS_LONG 0 0 Value: 57
> > DBR_STS_DOUBLE 0 0 Value: 57.6009
> > DBR_TIME_STRING 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> > 57.60
> > DBR_TIME_SHORT 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> > 57
> > DBR_TIME_FLOAT 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> > 57.6009
> > DBR_TIME_ENUM 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> > 57
> > DBR_TIME_CHAR 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> > 57
> > DBR_TIME_LONG 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> > 57
> > DBR_TIME_DOUBLE 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> > 57.6009
> > DBR_GR_STRING 0 0 Value: 57.60
> > DBR_GR_SHORT 0 0
> > 100 0 90 60 0 0 Value:
> > 57
> > DBR_GR_FLOAT 0 0 2
> > 100.000 0.000 90.000 60.000 0.000 0.000 Value:
> > 57.6009
> > DBR_GR_ENUM 0 0 Value: 57
> > DBR_GR_CHAR 0 0
> > 100 0 90 60 0 0 Value:
> > 57
> > DBR_GR_LONG 0 0
> > 100 0 90 60 0 0 Value:
> > 57
> > DBR_GR_DOUBLE 0 0 2
> > 100.000 0.000 90.000 60.000 0.000 0.000 Value:
> > 57.6009
> > DBR_CTRL_STRING 0 0 Value: 57.60
> > DBR_CTRL_SHORT 0 0
> > 100 0 90 60 0 0
> > 100 0
> > Value: 57
> > DBR_CTRL_FLOAT 0 0 2
> > 100.000 0.000 90.000 60.000 0.000 0.000
> > 100.000 0.000
> > Value: 57.6009
> > DBR_CTRL_ENUM 0 0 Value: 57
> > DBR_CTRL_CHAR 0 0
> > 100 0 90 60 0 0
> > 100 0
> > Value: 57
> > DBR_CTRL_LONG 0 0
> > 100 0 90 60 0 0
> > 100 0
> > Value: 57
> > DBR_CTRL_DOUBLE 0 0 2
> > 100.000 0.000 90.000 60.000 0.000 0.000
> > 100.000 0.000
> > Value: 57.600948
> >
> >
> > value = 0 = 0x0
> > ->
> >
> > Geoff Savage wrote:
> > >
> > > Hi,
> > >
> > > I'm running a ca client on an ioc and connecting to pv on a different
> > > ioc. On one boot of the processor the connection happens with no
> > > problems. On the next boot of the processor the connection attempt
> > > fails. This pattern has continued for the last two days. The ca client
> > > processor is an mv2304 and pv processor has been an mv162 and mv2301.
> > >
> > > I have tested the connections between the processors with ping.
> > >
> > > Any ideas?
> > >
> > > Thanks
> > >
> > > Geoff
- Replies:
- RE: ca client connection pattern Jeff Hill
- References:
- RE: ca client connection pattern Jeff Hill
- Navigate by Date:
- Prev:
RE: ca client connection pattern Jeff Hill
- Next:
RE: ca client connection pattern Jeff Hill
- 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: ca client connection pattern Jeff Hill
- Next:
RE: ca client connection pattern Jeff Hill
- 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
| 
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·