g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

<20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  Index <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: RE: Epics base3.14.beta2 for Tornado2.2
From: "Jeff Hill" <johill@lanl.gov>
To: "'???'" <hkm@postech.ac.kr>
Cc: "Marty Kraimer" <mrk@aps.anl.gov>, "Janet Anderson" <jba@aps.anl.gov>, "'Andrew Johnson'" <anj@aps.anl.gov>, <core-talk@aps.anl.gov>
Date: Thu, 5 Dec 2002 12:39:39 -0700

 

Thanks for your help with EPICS R3.14 and Tornado 2.2,

 

Do I summarize correctly (for my colleagues) that your startup problems, related to a missing CA server UDP thread, vanished when the DHCP server component alone was excluded from vxWorks, and that the –fno-strict-alias flag (related to http://www.windriver.com/products/tornado2/gnu_relnote.pdf

) had no impact on the problem.

 

Bob Dalesio at ldalesio@lanl.gov can assist you with advanced registration for EPICS classes.

 

Thanks again.

 

Jeff

 

 

 

-----Original Message-----
From: ??? [mailto:hkm@postech.ac.kr]
Sent: Wednesday, December 04, 2002 5:33 PM
To: Jeff Hill
Subject: Re: Epics base3.14.beta2 for Tornado2.2

 

Hi.

 

First I added -fno-strict-aliasing flag options but It makes same problems.

 

DHCP server, DHCP relay agent working with Berkeley Packet Filter Driver components.

 

I Exclude DHCP server only.

 

I tested Base3.13.6 without -fno-strict-aliasing flag, It's working Well.

 

and I tested Base3.13.7 with -fno-strict-aliasing flag, It's working Well

 

 

Regards.

 

Kiman Ha,

 

PAL/POSTECH

 

 

----- Original Message -----

From: Jeff Hill

To: '???'

Sent: Thursday, December 05, 2002 12:44 AM

Subject: RE: Epics base3.14.beta2 for Tornado2.2

 

Hello,

 

Thanks for your update. Was it necessary to use the –fno-strict-aliasing flag with the Tornado 2.2 compiler? Or, was the addition of networking components to vxWorks the only fix that was required?

 

Jeff

 

-----Original Message-----
From: ??? [mailto:hkm@postech.ac.kr]
Sent: Wednesday, December 04, 2002 8:10 AM
To: Jeff Hill
Subject: Epics base3.14.beta2 for Tornado2.2

 

Dear Jeff,

 

Host : Win2K Tonado 2.2

 

Target : MVME5100 Motorola SBC.

 

 

The EPICS CA Client problem was found.

 

Because The vxWorks network application component was make some EPICS CA problems.

 

First I added DHCP server for my vxworks image.

 

I try changing some network application component and Exclude DHCP server  compnents.

 

After EPICS BASE 3.13.6, 3.13.7, BASE 3.14.beta2 was working Well.

 

 

Thank you very munch for your halp.

 

Next year I will attending EPICS School.

 

I'd like to learn more EPICS.

 

 

Regards,

 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

Kiman Ha,

 

PAL/POSTECH Control Group

 

----- Original Message -----

From: Jeff Hill

Sent: Friday, November 15, 2002 3:30 AM

Subject: RE: Epics base3.14.beta2 for Tornado2.2

 

Hello again Kiman Ha,

 

I see from your message that when iocInit is run many threads are successfully created with epicsThreadCreate(), but the CA server’s UDP thread is not running. Therefore the situation is even more of a mystery. Do you see the following failure message printed in epicsThreadCreate() when taskSpawn() returns failure?

 

"epicsThreadCreate taskSpawn failure for %s\n"

 

You might try a debug build without compiler optimizations. This can be easily accomplished by adding the following to your CONFIG_SITE file.

 

CROSS_OPT = NO

 

Alternatively you could temporarily install the flag –fno-strict-aliasing into the vxWorks specific files in the configure directory. The following has a discussion of “type based alias analysis” optimizations which are present in the new compiler.

 

http://www.windriver.com/products/tornado2/gnu_relnote.pdf

 

However, I must admit that I don’t see how the compiler optimizations could allow some threads to be created but not allow other threads to be created.

 

Jeff

 


Navigate by Date:
Prev: RE: RISC_pad in dbr_time_double Jeff Hill
Next: stripping extranneous junk out of vxWorks IOCs Jeff Hill
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
Navigate by Thread:
Prev: Re: RISC_pad in dbr_time_double Marty Kraimer
Next: stripping extranneous junk out of vxWorks IOCs Jeff Hill
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·