Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture
From: "Johnson, Andrew N." <anj@aps.anl.gov>
To: "Rivers, Mark L." <rivers@cars.uchicago.edu>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Wed, 7 May 2014 21:32:46 +0000
Hi Mark,

You could try adding a call to the gcc built-in routine __sync_synchronize(); after the last write to the asynUser structure. This implements a full memory barrier, which is equivalent to the two memory barriers inside the mutex operations. If this fixes it for ARM there is probably a better solution, but this will at least identify if this is the cause of the problem.

- Andrew

-- 
Sent from my iPad

> On May 7, 2014, at 7:52 PM, "Mark Rivers" <rivers@cars.uchicago.edu> wrote:
> 
> Hi Andrew,
> 
> Thanks for the information.
> 
> The thread processing the record does the following in devMotorAsyn.c:
> 
> - Creates an asynUser structure (pasynManager->duplicateAsynUser)
> - Creates an private message structure (pasynManager->memMalloc)
> - Populates the private message structure with a command number, interface type, and dvalue which is the velocity, etc.
> - Copies the address of the private message structure to asynUser.userData
> - Calls pasynManager->queueRequest(&asynUser)
> - Returns
> 
> While this is executing the data is "private", no other thread has access to the address of the asynUser or the private message structure
> 
> pasynManager->queueRequest causes the asyn port driver thread for this port to run.  It is passed the address of the asynUser structure.  It executes the callback function in devMotorAsyn.c.  In that callback we see that some of the data in the private message structure is OK (the command and interface fields), but the dvalue field is 0, not the value it was set to above.
> 
> The asyn port driver is certainly taking a mutex when it runs, before it reads the data.  But I am not sure we are releasing a mutex after writing to the data, since it was not really "shared" before we called pasynManager->queueRequest?
> 
> Mark
> 
> 
> 
> -----Original Message-----
> From: Johnson, Andrew N. [mailto:anj@aps.anl.gov] 
> Sent: Wednesday, May 07, 2014 12:06 PM
> To: Mark Rivers
> Cc: J. Lewis Muir; tech-talk@aps.anl.gov
> Subject: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture
> 
> Mark,
> 
> What thread synchronization is used between the two tasks that are seeing different data? The ARM memory model is stricter than the Intel one, so the code must release a mutex after writing to shared data, and take a mutex before reading from shared data. It is even possible that the epicsRingBuffer code doesn't properly follow the ARM rules, I would try running the relevant libCom tests to check that. I can't research anything more about it right now (I'm on vacation), but it's something you might want to double check.
> 
> - Andrew
> 
> -- 
> Sent from my iPad
> 
>> On May 7, 2014, at 6:34 PM, "Mark Rivers" <rivers@cars.uchicago.edu> wrote:
>> 
>> I don't think this has anything to do with the problem we are seeing on the ARM5.  
>> 
>> The problem we are seeing does not have to do with passing the status bits to the motor record, it has to do with passing information in pasynUser->userData.  This is an asyn issue, not a motor record issue.
>> 
>> Mark
>> 
>> 
>> -----Original Message-----
>> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of J. Lewis Muir
>> Sent: Wednesday, May 07, 2014 11:29 AM
>> To: tech-talk@aps.anl.gov
>> Subject: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture
>> 
>>> On 5/7/14, 11:01 AM, Jens Eden wrote:
>>> I don't know if this is the cause of the problem, but even on a
>>> single architecture, you will need a correct entry in this switch in
>>> motorApp/MotorSrc/motor.h
>> 
>> Jens posted about this to the list in February:
>> 
>> http://www.aps.anl.gov/epics/tech-talk/2014/msg00158.php
>> 
>> From that thread, it sounds like the motor module needs some work to
>> eliminate assumptions about, as Till Straumann wrote, "what storage unit
>> the compiler uses, how adjacent bits are packed across a storage-unit
>> boundary and in what order bits are allocated (LSB->MSB or MSB->LSB)."
>> 
>> Lewis
>> 



Replies:
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Torsten Bögershausen
References:
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture J. Lewis Muir
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Stephen Beckwith
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Stephen Beckwith
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Jens Eden
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture J. Lewis Muir
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Johnson, Andrew N.
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers

Navigate by Date:
Prev: RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Next: RE: [CSS] freeze and lost running PV in Boy Screens Hu, Yong
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019 
Navigate by Thread:
Prev: RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Next: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Torsten Bögershausen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·