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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: CA problem w EPICS 3.14.11 & VxWorks 6.7 |
From: | "Jeff Hill" <[email protected]> |
To: | "'GOURNAY Jean-Francois'" <[email protected]>, <[email protected]>, "'Kazuro FURUKAWA'" <[email protected]> |
Date: | Wed, 25 Nov 2009 09:55:42 -0700 |
Jean Francois, The “Channel Access
Address List” printout from the ‘casr “1”’ ( ‘casr 3’ and ‘dbcar “VME-TST-CA-O”,
3’ are preferable) diagnostic indicates that the auto-configured address list
is empty. That certainly is very consistent with what Kazuro-san is reporting.
I cc’d to Janet, and perhaps she can update the next
release of the build files. If Okazaki-san’s fix isn’t
sufficient let me know, and I will take another look. Cheers, Jeff
Message
content: TSPA From: GOURNAY Jean-Francois [mailto:[email protected]]
Hello Jeff, hello Kazuro Thanks for your replies. Jeff, I have included the trace of the 2
following commands : Dbcar “VMETST-CA-O”, “2” Casr “1” Before these commands, I did a dbtr
“VMETST-CA-O”, surprisingly UDF becomes 0 but the value (supposed to be
retrieved through a CA link to VMETST) is 0 (it should be “223”). Both VxWorks IOCs are on the same network
(132.166.33.10 and 132.166.33.11) Kazuro, I will pass the information to my colleague
in charge of the VxWorks support. He had already a lot of trouble with the IP
stack of the new release of VxWorks (2nd Ethernet port of our
MVME5500 not working, problem of connection with rlogin, problem with connect
function of socket.h). Recompiling with gnu instead of diab helps for some
point (wancomEnd.c) but there are still pending problems. J.F. Gournay CEA Saclay IRFU/SIS De : Jeff Hill [mailto:[email protected]]
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 ______________________________________________________ Message content: TSPA From: [email protected]
[mailto:[email protected]] On Behalf Of GOURNAY
Jean-Francois 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 |