Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: tRipTask is using CPU
From: "Jeff Hill" <johill@lanl.gov>
To: "EPICS-tech-talk" <tech-talk@aps.anl.gov>
Date: Tue, 16 Sep 2003 10:29:06 -0600
So we know that tRipTask is the culprit. It's using all available CPU at
priority 101. The CA server threads run at a much lower priority and are
therefore not allowed to initialize themselves. 

RIP stands for routing information protocol and it is used to exchange
routing tables between routers.

There could be a configuration problem, but the 100% CPU usage certainly
leads one to be suspicious of a bug in vxWorks. You might try typing
"checkStack" to see if tRipTask has sufficient stack to run properly.

You may or may not need to have the RIP component installed in your vxWorks
system. Is your vxWorks host being used as a router? If not, then the
simplest solution may be to just undefine the INCLUDE_RIP option, rebuild
vxWorks, and then reboot your system.

Jeff

> -----Original Message-----
> From: Dennis Armstrong [mailto:dba@ing.iac.es]
> Sent: Tuesday, September 16, 2003 9:52 AM
> To: Jeff Hill
> Cc: tech-talk@aps.anl.gov
> Subject: Re: Problems using Epics R3.14.3 with mvme5110 PowerPc
> 
> No error messages when iocinit runs, no tcp or udp on port 5064
> hovever the spyReport shows the following high usage on  tRipTask :-
> 
> NAME          ENTRY         TID   PRI   total % (ticks)  delta % (ticks)
> --------     --------      -----  ---   ---------------  ---------------
> tExcTask     excTask    1efe5290    0     0% (       0)    0% (       0)
> tLogTask     logTask    1efe26f0    0     0% (       0)    0% (       0)
> tShell       shell      1eee7460    1     0% (       0)    0% (       0)
> tRlogind     rlogind    1eef7b50    2     0% (       0)    0% (       0)
> tWdbTask     wdbTask    1eeefe30    3     0% (       0)    0% (       0)
> tAioIoTask1  aioIoTask  1eff43b0   50     0% (       0)    0% (       0)
> tAioIoTask0  aioIoTask  1efed130   50     0% (       0)    0% (       0)
> tNetTask     netTask    1efa41a0   50     0% (       1)    0% (       1)
> tAioWait     aioWaitTas 1effb630   51     0% (       0)    0% (       0)
> tPortmapd    portmapd   1eefaf40   54     0% (       0)    0% (       0)
> tTelnetd     telnetd    1eef57a0   55     0% (       0)    0% (       0)
> tRipTimerTas ripTimer   1eee86a0  100     0% (       0)    0% (       0)
> tRipTask     ripTask    1eef21f0  101    97% (    1551)   97% (    1551)
> syncNTP                 1eb41ed0  109     0% (       0)    0% (       0)
> cbHigh                  1eb23c90  128     0% (       0)    0% (       0)
> timerQueue              1ef019e0  129     0% (       0)    0% (       0)
> scanOnce                1eb18c70  129     0% (       0)    0% (       0)
> scan0.1                 1eaf2400  133     0% (       0)    0% (       0)
> scan0.2                 1eaf7c10  134     0% (       0)    0% (       0)
> cbMedium                1eb294a0  135     0% (       0)    0% (       0)
> scan0.5                 1eafd420  135     0% (       0)    0% (       0)
> scan1                   1eb02c30  136     0% (       0)    0% (       0)
> scan2                   1eb08440  137     0% (       0)    0% (       0)
> scan5                   1eb0dc50  138     0% (       0)    0% (       0)
> scan10                  1eb13460  139     0% (       0)    0% (       0)
> cbLow                   1eb3d3b0  140     0% (       0)    0% (       0)
> dbCaLink                1eb1e480  149     0% (       0)    0% (       0)
> CAS-TCP                 1eaecbf0  181     0% (       0)    0% (       0)
> errlog                  1ee40aa0  189     0% (       0)    0% (       0)
> errlog                  1eea5c10  189     0% (       0)    0% (       0)
> errlog                  1ea1d2b0  189     0% (       0)    0% (       0)
> taskwd                  1fffef50  189     0% (       0)    0% (       0)
> KERNEL                                    2% (      35)    2% (      35)
> INTERRUPT                                 0% (       0)    0% (       0)
> IDLE                                      0% (       0)    0% (       0)
> TOTAL                                    99% (    1587)   99% (    1587)
> 
> 
> Jeff Hill wrote:
> 
> >Hello Dennis,
> >
> >
> >
> >>I tried to telnet to port 5064 on the IOC but it reports connection
> >>refused. It looks like the IOC isn't listening on this port.
> >>The only tcp ports it recognizes are 23, 111 and 513
> >>Any suggestions as to what's missing in the IOC?
> >>
> >>
> >
> >Type "inetstatShow". On a normal EPICS system you will see CA's TCP
> daemon
> >listening on port 5064, but based on your experiments so far I am
> guessing
> >that you will not. On a normal system there will also be a UDP server
> socket
> >attached to port 5064.
> >
> >Type "spyClkStart" followed by "spyReport". I am going to guess that
> there
> >is a thread in the system that is using 100% of the CPU. This might be
> a
> >device driver or the processing load of a large database.
> >
> >If that isn't the cause, then please check to see if there are any
> error
> >messages when iocInit runs, when your application loads, or when your
> >application is compiled and linked.
> >
> >Jeff
> >
> >
> >
> >>-----Original Message-----
> >>From: Dennis Armstrong [mailto:dba@ing.iac.es]
> >>Sent: Tuesday, September 16, 2003 7:32 AM
> >>To: tech-talk@aps.anl.gov
> >>Subject: Problems using Epics R3.14.3 with mvme5110 PowerPc
> >>
> >>Hi all
> >>
> >>I am having trouble connecting to our new PowerPc card using EPICS
> >>r3.14.3.
> >>
> >>I have built EPICS base and some of the extensions.
> >>
> >>I can boot the ioc with an epics database (the demo.db one fron the
> >>sequencer extension)
> >>I can access the datebase when logged into the ioc from a console ie
> >>dbpf, dbgf and dbl commands all work
> >>and I can access the various pv fields.
> >>
> >>I cannot access the database from outside the ioc using caget or medm.
> >>caget returns an "Invalid channel name" when
> >>accessing any of the PowerPC PV's although it is quite happy to access
> >>the other iocs running EPICS R3.13.1
> >>
> >>I tried to telnet to port 5064 on the ioc but it reports connection
> >>refused. It looks like the ioc isn't listening on this port.
> >>The only tcp ports it recognises are  23,  111 and  513
> >>Any suggestions as to whats missing in the ioc?
> >>
> >>regards
> >>
> >>Dennis Armstrong
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> 
> 


Jeff
__________________________________________________________
Jeffrey O. Hill               Mail         JOHill@lanl.gov
LANL MS H820                  Voice        505 665 1831
Los Alamos NM 87545 USA       Fax          505 665 5107



Navigate by Date:
Prev: Re: Problems using Epics R3.14.3 with mvme5110 PowerPc Dennis Armstrong
Next: aps cvs access Geoff Savage
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: about edm zhaozhuo
Next: aps cvs access Geoff Savage
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·