Re: CAC problem between RTEMS and vxWorks

[Benjamin Franksen <benjamin.franksen@helmholtz-berlin.de>]

On Friday, September 21, 2012 10:33:20 you wrote:
> I'm familiar with some of the issues that you guys pointed out, they can
> definitely bite you.  While double-checking your suggestions I found that
> one of the channels that was being monitored came from another vxWorks IOC
> (mistake on my part).  Surprise, surprise...it never has any disconnect
> issues.  Following that lead, I found that the problems seem to be centered
> around a dynamically assigned pv in one of my two sequencers.  When I
> hard-coded that pv assignment the problems went away.  This remains
> consistent.  What's confusing me a bit is that I use dynamic assignment in
> the working sequencer, I just don't do any reassignments.
> 
> Ben - Any known issues with dynamic assignment/reassignment?  Perhaps
> specific to RTEMS?

Not until now.

Let me re-state the issue, so we are clear what's happening:

Scenario 1: you are using either static assign, or assign at runtime, but in 
the latter case for each channel you assign at most once. This works as 
expected.

Scenario 2: you re-assign at runtime. This fails (sometimes?), when some 
participant is rebootet. I guess it is not the IOC hosting the client (i.e. 
the SNL program) that gets re-bootet, but the server (where the PV resides), 
because you are talking about failing re-connects. It is not completely clear 
to me which side is VxWorks, which is RTEMS, and which causes problems when 
rebootet, but my guess is that: the SNL program runs on a VxWorks IOC; the 
servers are VxWorks and RTEMS; re-connect fails only if the server OS is RTEMS 
and if the channel gets re-assigned at runtime.

Jeff:

Dynamic re-assign means in CA terms that the sequencer will issue a 
ca_clear_channel (for some connected channel), immediately followed by a 
ca_create_channel (to some other PV). Hmmm, what happens if there is a race 
between the ca_clear_channel call and the disconnect event caused by the IOC 
reboot? (Just think loud here.)

It should be possible to devise a simple test client that issues a long 
sequence of such create/clear calls to check whether this is a CA problem. 
Unfortunately my automatic test setup does not yet support RTEMS, so this will 
take some time for me to do.

On Friday, September 21, 2012 11:37:03 Wesley Moore wrote:
> From: "J. Lewis Muir" <jlmuir@imca-cat.org>
> > There have been a number of bug fixes related to pvAssign.  You
> > can find these in the release notes (just search in the page for
> > 
> > "pvAssign"):
> >   http://www-csr.bessy.de/control/SoftDist/sequencer/Notes.html
> > 
> > What version of the sequencer are you using?
> 
> I'm using 2-1-9.  

In 2.1.9 all issues know to me have been resolved.

> Looking through all the release notes and also seq_if.c. 
> I'm thinking of trying to de-assign the channel between uses.

As a short-term work-around, this seem sensible.

Cheers
Ben

-- 
Ben Franksen
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

Attachment: signature.asc
Description: This is a digitally signed message part.