We're developing a PPC8260 application using the tornado tools and
Singlestep debugger. When trying to attach the solaris Host-based
target-server to the WDBagent running on the target board:
tgtsvr.ex (FW17GCU-A@sunx214): Mon Jun 3 19:01:40 2002
Connecting to target agent...
Error: rpccore backend client RPC: Timed out
failed.
Connecting to target agent...
Error: rpccore backend client RPC: Timed out
failed.
I've tried resetting each element of my environment, the target board,
the host workstation, and even tried starting a local copy of the
tornado_registry... all to no avail.
I've been using scripts for my environment and setup, so I'm pretty sure
everything is set up as before (when things were working fine).
I checked Windriver's dB for similar issues and I found 8 TSR/Forum
message chains asking similar questions, only 2 were given any kind of
suggested solutions, neither solution helped me. (one was reset
everything, the other was a Win/NT based solution).
Has anyone out there been able to isolate this issue? Any success making
it go away?
Not sure, but the version of vxWorks/Tornado you are using could be in
play. You
mention that this worked before, so you don't have a DHCP server running,
which
could be taking the only available SNARF protocol in pre T2.0.2 for PPC. You
are
sure the kernel is using END or Network for the WDB agent. How about the
target server line? You might want to use the logging for WTX/Backend
communication
in case this may shed some light. Do you have a target shell installed? I am
from the
pre-GUI days and I absolutely need to have the visibility that the target
shell gives me.
Plus, I always will build in the symbol table in case networking goes awry
during the
downloadable symbol table load, it is too late to bite me. Are you using the
target's IP address or a name which is known to your DNS/NIS server? Well, I
have ran out of the obvious WAGs. (are you building from the IDE or from the
command line?) Could you put a telnet server on your board to verify the
networking? Good luck......
"Eric Geelen" <Eric....@tellabs.com> wrote in message
news:3CFC0BAE...@tellabs.com...
Thanks
Hsing Yuan
"drdiags" <drd...@attbi.com> wrote in message news:<HiUK8.161825$L76.246171@rwcrnsc53>...
This is the output she saw:
>>>>>>>>>>>>>>>>
Killing this session log viewer will not kill the Target Server.
Current session log is available in:
/home/tlabas-2/aovermye/.wind/launchLog.GCU_TEST_SW12
Command: tgtsvr 172.17.55.122 -V -n GCU_TEST_SW12 -B wdbrpc -f elf -c /vobs/gu.elf -Root
{$HOME/stuff}
tgtsvr.ex (GCU_TEST_SW12@sunsw12-121): Fri Jun 7 14:35:10 2002
Connecting to target agent... succeeded.
Attaching C++ interface... succeeded.
Attaching elf OMF reader for PPC CPU family... succeeded.
Warning: Target server cache for agent memory is full.
Use the '-m' option to increase the target server cache.
Warning: Can't checksum core file, length is not valid.
tgtsvr.ex (GCU_TEST_SW12@sunsw12-121): Fri Jun 7 14:37:09 2002
Error: rpccore backend client RPC: Timed out
tgtsvr.ex (GCU_TEST_SW12@sunsw12-121): Fri Jun 7 14:37:12 2002
Error: rpccore backend client RPC: Timed out
>>>>>>>>>>>>>>>>>
Anyone know what the reference to using the '-m' is? I tried adding it to the tgtsvr command
line with no effect.
Thanks, eh!
Eric.
BTW, drdiags ( Frederic?) I did try setting a different name for the target, or even just
choosing a different IP address. At first I thought it would be a suitable workaround, but it
doesn't always work. I'll look into the WDB configuration in the kernel, but if these weren't
correctly set, would it work at all?
> Command: tgtsvr 172.17.55.122 -V -n GCU_TEST_SW12 -B wdbrpc -f elf -c /vobs/gu.elf -Root
> {$HOME/stuff}
Is there some reason why you are specifying all these options? When
using the -c option make very sure that the core file you point the
target server matches the image on the target...
> tgtsvr.ex (GCU_TEST_SW12@sunsw12-121): Fri Jun 7 14:35:10 2002
> Connecting to target agent... succeeded.
> Attaching C++ interface... succeeded.
> Attaching elf OMF reader for PPC CPU family... succeeded.
> Warning: Target server cache for agent memory is full.
> Use the '-m' option to increase the target server cache.
> Warning: Can't checksum core file, length is not valid.
>
> tgtsvr.ex (GCU_TEST_SW12@sunsw12-121): Fri Jun 7 14:37:09 2002
> Error: rpccore backend client RPC: Timed out
>
> tgtsvr.ex (GCU_TEST_SW12@sunsw12-121): Fri Jun 7 14:37:12 2002
> Error: rpccore backend client RPC: Timed out
> >>>>>>>>>>>>>>>>>
>
> Anyone know what the reference to using the '-m' is? I tried adding it to the tgtsvr command
> line with no effect.
It allows you to increase the size of the target memory cache on the
host. If you are using really large images this might need to be
increased to get reasonable performance. Try searching previous posts
to this group for some hints on sizes. It should never need to be
bigger than the physical RAM size on your target, so if in doubt try
setting it to that.
There are some other guidelines for debugging rpc timout problems,
check out this app note for some troubleshooting guidelines:
http://web1.windriver.com/cgi-bin/windsurf/techtips/public/viewSum.cgi?372
HTH,
John...
The reason I said to look at the kernel configuration was to make sure
that your
target server and kernel configuration agreed. If the kernel was configured
to
use serial port and the target server END/Network..., but as you state it
appears
to work sometimes, so that theory doesn't hold water. The -m option can be
set from the target server IDE configuration or adding it to your script
doing something like this:
tgtsvr.exe pcServer -n pcs1 -V -m 4194304 -B wdbrpc -Bt 60 -Br 2
-R e:\ -RW -c E:\proj\pcServer\default\vxWorks
The reason I asked about DHCP Server is that this is a problem with
T2.0/DHCP Server/WDB Agent using END because of the use of
the SNARF method by both and only one SNARF allowed. This
changed in T2.0.2. Core files match what's on the target versus what
is being pointed to by the target server? What does your target
server line look like? Pass the frustration on to your WRS support
engineer, maybe he/she can extract a clue that can get you over the
hump. Good luck and relax if you can......
"Eric Geelen" <Eric....@tellabs.com> wrote in message
news:3D011E67...@tellabs.com...