Hello Jean-Francois,
I had a quick look at what has
changed between R3.14.10 and R3.14.11 WRT EPICS_CA_AUTO_ADDR_LIST and EPICS_CA_ADDR_LIST. I do see that in R3.14.11 Mantis 331
was fixed. This is certainly a relevant change, but I don’t at this time
expect the side effect that you are observing.
Ø This problem arises also with CA links between VxWorks
an Linux.
Ø On the other hand, no problem with CA links between 2 Linux IOCs
The above might be a very useful bit of information. Presumably
the same vxWorks version, vxWorks
6.7, was also used with R3.14.10? Frequently vxWorks
systems boot by default with routes limiting access only to the local subnet.
If a EPICS system is operating in a WAN environment it may be necessary to
configure routes into the vxWorks system which enable
a vxWorks based CA server to respond to requests
originating outside it's subnet. These routing restrictions might also apply to
vxWorks based CA clients communicating with off
subnet servers. See "routeLib" in the vxWorks reference manual.
Of course, the other difference between vxWorks
and Linux in your situation might be PPC (big-endian) versus Intel
(little-endian), and that might imply a missing byte swap in the CA code, but I
haven’t identified one at this time based on the source code differences.
Ø We have “CA beacon routing … ECONNREFUSED” on the 1st
booted IOC.
This indicates that the IOC is unable to identify a route
for a beacon message. A list of addresses is also configured for the beacons. When
EPICS_CA_AUTO_ADDR_LIST is YES, please type ‘casr <integer interest level>’ and send the
result. This will reveal what the address list is being set to at higher
interest levels. One can also receive an overwhelming amount of information by
typing ‘dbcar “record name”, <integer
interest level>’. At some higher interest level you should see also
the CA address list for the db ca client. You might also try “routeShow” on this vxWorks
system. If there is a problem with auto configuring the client’s address
list we should see clear evidence in this diagnostic.
With the above information, fault isolation should proceed quickly,
and maybe I won’t need to spend as much time staring at the source code.
Thanks for your help,
Jeff
______________________________________________________
Jeffrey O. Hill
Email [email protected]
LANL MS H820
Voice 505 665 1831
Los Alamos NM 87545 USA
FAX 505 665 5107
Message
content: TSPA
Hello,
We have 2 IOCs running EPICS 3.14.11 with VxWorks 6.7.
Any record on an IOC with a CA link on a record
located in the other IOC stays UDF=1 forever. This problem arises with
EPICS_CA_AUTO_ADDR_LIST= YES.
With EPICS_CA_AUTO_ADDR_LIST=NO and
EPICS-CA-ADDR-LIST= … it works. But we would like to avoid to have this
parameter to “NO” and having to maintain the host list in
ADDR-LIST.
Especially in the case where:
On IOC1 : EPICS-CA-ADDR-LIST=<IP IOC2>
And on IOC2: EPICS-CA-ADDR-LIST=<IP IOC1>
(needed for CA links in both directions)
We have “CA beacon routing …
ECONNREFUSED” on the 1rst booted IOC.
We did’nt have this problem with the previous
release.
This problem arises also with CA links between VxWorks
an Linux.
On the other hand, no problem with CA links between 2
Linux IOCs
Thanks Jeff (I think it is probably a problem for you
. . .)
J.F. Gournay
CEA Saclay
IRFU/SIS