| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: Problems with Channel Access calls on an IOC moving from R3.13.7 -> 3.14.8 |
| From: | "Hammonds, John P." <[email protected]> |
| To: | "Jeff Hill" <[email protected]>, <[email protected]> |
| Date: | Mon, 11 Dec 2006 11:52:47 -0600 |
|
Jeff,
I finally got a change to get back to this. I have done the tt printout that you suggested. See the output below
tt 0x27598f8 19b9a8 vxTaskEntry +60 : 77a6110 () 77a6180 epicsThreadPrivateGet+f8 : sequencer () 7685df8 sequencer +1a0: ss_entry () 76860b8 ss_entry +280: 765ab00 (e8402a60) 765ab00 dbAddrSetup +880: 767fb4c () 767fb4c LoadAncParamFiles+624: ca_array_put () 771e8d8 ca_array_put +37c: 76e974c (761ac50) 76e974c dbChannelIO::write(epicsGuard<epicsMutex> &, unsigned int, unsigned long, void const *)+818: 4 () value = 0 = 0x0
LoadAncParamFiles is the routine that I have managed to tracking this to. This is C code that is called by the sequencer that performs the basic Pseudo-code in my previous message.
I am not familiar with debugging from this information. Is there a way from this to determine where in the code failure occurred? I am currently not configured to run with the Tornado tools.
Thanks, John
John Hammonds Data Acquisition Systems Manager Intense Pulsed Neutron Source (630)252-5317
From: Jeff Hill
[mailto:[email protected]]
John,
The ETIMEDOUT indicates that there are problems building a TCP/IP circuit to 192.168.6.101:5064. To get that far the UDP services on 192.168.6.101:5064 must have been responding ok so presumably the local host has a route to 192.168.6.101. Nevertheless you might try pinging 192.168.6.101 from this host. Modern versions of vxWorks include the ping command, or not, depending on build options. Depending on the options you supply to the ping command you can get some coarse information about network responsiveness. You might also look at ifShow to see if there are any link errors on either host. You might also test to see if the IP kernel is working before and after this code runs. A change might indicate corruption of the IP kernel’s data structures.
I can’t speculate about the exception with instruction address 0x4 other than to guess that the code was clobbered or a nill function pointer was used. I might be able to make further guesses if you sent the output from “tt <task id>” in this case “tt 0x275bfd8”. This will provide a stack trace. There are also ways to request a stack trace from the debugging facilities supplied with Tornado.
Note also that “preemptive callback mode” was the default for vxWorks prior to R3.14, but in R3.14 non-preemptive mode is the default and you must specifically request “preemptive callback mode” invariant of the OS you are running on. This maybe wouldn’t be a significant issue with the pseudo code that you sent.
Jeff
From: Hammonds, John
P. [mailto:[email protected]]
I am working on moving our detector data acquisition code from R3.13.7 to R3.14.8 and am having trouble with a piece of the code that makes channel access calls from C code. I have 2 crates both running as VxWorks IOC. One of these is a master crate that reads setup data from a file and loads this into the iocs. The slave crate basically handles Sample environment and beamline control stuff. The master crate does ca_put C library call to write data to the slave crate. On moving this to R3.14.8 I am having trouble getting connection between the crates. The basic code does ca_create_channel() ( Under 3.13 I was using ca_search()) ca_pend_io() I now added code to check for ECA_NORMAL ca_put() ca_pend_io() ca_clear_channel()
I get the following messages coming out of the IOC. This code has worked well under 3.13. Anyone have ideas for what could be going on here?
iocsand1> CAC: Unable to connect because "S_errno_ETIMEDOUT" CA.Client.Exception............................................... Warning: "Virtual circuit disconnect" Context: "192.168.6.101:5064" Source File: ../cac.cpp line 1142 Current Time: WED DEC 06 2006 11:41:56.170496250 .................................................................. CAC: Unable to connect because "S_errno_ETIMEDOUT" CA.Client.Exception............................................... Warning: "Virtual circuit disconnect" Context: "192.168.6.101:5064" Source File: ../cac.cpp line 1142 Current Time: WED DEC 06 2006 11:43:16.170493050 .................................................................. CAC: Unable to connect because "S_errno_ETIMEDOUT" CA.Client.Exception............................................... Warning: "Virtual circuit disconnect" Context: "192.168.6.101:5064" Source File: ../cac.cpp line 1142 Current Time: WED DEC 06 2006 11:44:36.170489850 .................................................................. Setting sand0A:chngr_0:veto.DESC to SAND Sample Chan
program Exception current instruction address: 0x00000004 Machine Status Register: 0x0008b030 Condition Register: 0x44000049 Task: 0x275bfd8 "ipns_daq" filename="../../../src/libCom/taskwd/taskwd.c" line number=174 task 0x275bfd8 suspended
John Hammonds Data Acquisition Systems Manager Intense Pulsed Neutron Source (630)252-5317
|