Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: RE: DEC driver DMA Underflow
From: "Jeff Hill" <johill@lanl.gov>
To: "'Matt Rippa'" <mrippa@gemini.edu>, <tech-talk@aps.anl.gov>
Date: Wed, 25 Nov 2009 15:10:04 -0700
> Is CA designed to survive such an event?

Yes, if the IP kernel stalls the socket and then resumes data transmission
later, or if the IP kernel disconnects the socket. I do recall that on the
AFEL project at LANL that network interface resets didn?t result in proper
recovery of the situation by the vxWorks IP kernel. This was observed with
vxWorks running on the NI CPU030 VXI CPU, and the conclusion was based on
the IP kernel being unresponsive to ping, telnet, etc.

The CA design in EPICS R3.14 _is_ more robust in congestion stall situations
since it will disconnect the application, but not the socket when there is
an unresponsive circuit timeout. This design avoids positive congestion
feedback. Also, many subtle issues have been fixed in R3.14.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA


> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
> On Behalf Of Matt Rippa
> Sent: Wednesday, November 25, 2009 1:24 PM
> To: tech-talk@aps.anl.gov
> Subject: DEC driver DMA Underflow
> 
> Hello -
> 
> We're running an IOC on a MVME2700 board with VxWorks5.5 and
> EPICS 3.13.9. Yesterday we logged a DMA underflow event from the
> network which resulted in a restart of the driver. CA couldn't
> survive and we quickly had S_errno_ENOBUFS. We had to reboot to
> recover.
> 
> Does the DMA underflow indicate a bus error? Is CA designed to
> survive such an event? Short of upgrading to EPICS 3.14.x is
> there anything that can be done to prevent this?
> 
> Thanks,
> -Matt
> 
> 
> 
> Here's some relevant code from the end driver:
> 
> /* restart if DMA underflow is detected */
> 
> if (pTxD->tDesc0 & PCISWAP(TDESC0_UF))
> {
>   LOG_MSG ("%s%d - fatal DMA underflow\n",
>   (int) DRV_NAME, pDrvCtrl->unit, 0, 0, 0, 0);
> 
>    dec21x4xStop (pDrvCtrl);
>    pDrvCtrl->txCleaning = FALSE;
>    netJobAdd ((FUNCPTR)dec21x4xRestart, (int)pDrvCtrl, 0, 0, 0, 0);
>    return;
> }



References:
DEC driver DMA Underflow Matt Rippa

Navigate by Date:
Prev: RE: DEC driver DMA Underflow Mark Rivers
Next: Re: DEC driver DMA Underflow Matt Rippa
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: DEC driver DMA Underflow Andrew Johnson
Next: SNL Question: dynamic assignment and event flag Kim, Kukhee
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·