Experimental Physics and
Industrial Control System

Kazuro FURUKAWA <[email protected]> · Wed, 25 Nov 2009 17:13:20 +0900

Hello Jean-Francois, hello Jeff, 

If I understand the issue correctly, I think it lies in the network 
interface handling, and we need to tweak the EPICS build script for 
vxWorks-6.7.  (We've never used vxWorks-6 other than 6.7.)  The 
same occurred in R3.14.10. 

Unless we use "-DBSD=44" for osdSock.h, incorrect network interface 
structure is assumed, and an incorrect list of interfaces is 
constructed, then the EPICS_CA_{,AUTO_}ADDR_LIST behavior becomes 
wrong. 

For example, we use these variables in 
CONFIG_SITE.Common.vxWorksCommon to build R3.14.11 for vxWorks-6.7. 

BSD_DEFINE_VERSION_6.7 = -DBSD=44
OP_BSD_DEFINE = $(BSD_DEFINE_VERSION_$(VXWORKS_VERSION))
VXWORKS_VERSION = 6.7
VX_GNU_VERSION_6.7 = 4.1.2
OP_SYS_CPPFLAGS += -DvxWorks $(OP_BSD_DEFINE)
OP_SYS_CFLAGS += -fno-builtin $(OP_BSD_DEFINE)
WORKBENCH_VERSION = 3.1

I'm sorry that I forgot to report this, although this was found by 
Tomohiro Okazaki before ICALEPCS09. 

Cheers, Kazuro. 

>>> On Tue, 24 Nov 2009 10:14:56 ,  "Jeff Hill" <[email protected]> wrote;
> 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.
> 
> o  This problem arises also with CA links between VxWorks an Linux.
> o  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.
> 
> o  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 93routeShow94 on this vxWorks system. 
> If
> there is a problem with auto configuring the client92s address list we 
> should
> see clear evidence in this diagnostic.
> 
> With the above information, fault isolation should proceed quickly, and
> maybe I won92t need to spend as much time staring at the source code.
> 
> Thanks for your help,
> 
> Jeff
> ______________________________________________________
> Jeffrey O. Hill           Email         <mailto:[email protected]>
> [email protected]
> LANL MS H820              Voice        505 665 1831
> Los Alamos NM 87545 USA   FAX          505 665 5107
> 
> Message content: TSPA
> 
> From: [email protected] 
> [mailto:[email protected]]
> On Behalf Of GOURNAY Jean-Francois
> Sent: Tuesday, November 24, 2009 7:38 AM
> To: [email protected]
> Subject: CA problem w EPICS 3.14.11 & VxWorks 6.7
> 
> 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

-----
Kazuro FURUKAWA <[email protected]>
 Linac&KEKB,  High Energy Accelerator Research Organization (KEK), Japan
 Telephone: +81-29-864-5200 x4316,  Facsimile: +81-29-864-0321

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System