Network problem when using jtag debugger on EP8260

Network problem when using jtag debugger on EP8260

[Jeff Mintz]

I am attempting to debug the Linux Kernel on an Embedded Planet 8260
board,
using a COP JTAG debugger.  I am encountering a behavior where when I
halt
the kernel, and resume, the kernel's ability to access the network seems
to
be disturbed.  I am wondering if anyone has seen something like this
before.

Let me clarify the problem:

[Case 1]
- I boot the Linux kernel (version 2.4.22, obtained from Embedded
Planet)
- When I get to the prompt, I halt the target using the debugger.  The
target always seems to halt at address 0x904.
- I resume the target.  A network access (such as "ls") takes about 7
seconds, instead of being instantaneous.  (I'm not using a ramdisk, so
ls
uses NFS).
- If I halt and resume again, network access is slowed down even
further, certainly to the point of being unusable.

[Case 2]
- When I get to the prompt, I issue the command "while(true); do true;
done" which sets the kernel off and running infinitely (until I stop it
with Ctrl-C).
- Using the debugger, I halt the target.  I am not at 0x904, but
somewhere else, either in the kernel code, or in what seems to be a user

application page.
- I can stop, singlestep, resume, set and hit breakpoints using the
debugger.  When I finally stop the while loop, the network is fine.  All

of my debugging activity did nothing to disturb network access.

[Case 3]
- Same as Case 2.  This time, after halting the target, I set a
breakpoint on the first line in the function fcc_enet_rx.  I resume the
target.  This breakpoint is hit about 15 times, and then it is not hit
anymore.  When I attempt to stop the while loop, the network access has
been disturbed.

[Case 4]
- Same as Case 1.  This time, before I halt the target using the
debugger,
I unplug the ethernet cable.  Then I halt the target, and it is again
at 0x904.
- Now I resume the target using the debugger.
- Now I plug in the ethernet cable to the target again.
- Network accesses (i.e. ls) works fine.


My primary goal is to fix Case 1.  I do not want to lose network access
when I halt the kernel when it is idle.  Case 2 gives me hope that this
is possible, because this is a case where I can halt the Linux kernel
without disturbing the network access.

The JTAG debugger I am using is a Green Hills Probe.  I have also tried
with
an Agilent E5900B Emulation Probe and seen similar behavior.

Some questions:
- Has anyone seen this before?  If so, is there a known remedy or
workaround?  (For example, is there a kernel patch?  Is there a way to
recover from this slowed network state?)  If not, does anyone have
a theory to explain why I am seeing this behavior?
- Does this occur on the BDI2000 debugger?  I don't have access to one
of
those, but I hear that is the best JTAG debugger for Linux.  If anyone
can
easily try some of these test cases on other debuggers and let me know
the
results, that would be helpful.
- Is there any reason to think that the scenario I described in Case 1,
halting the target while at the shell prompt, is something that users
typically don't do (and hence, I shouldn't worry about it)?


Thanks in advance,
Jeff Mintz
Green Hills Software


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Network problem when using jtag debugger on EP8260

[Steven Blakeslee]

I've used an Abatron on the EP8260 and I never saw any network problems.

-----Original Message-----
From: Jeff Mintz [mailto:jmintz@ghs.com]
Sent: Thursday, November 20, 2003 8:17 PM
To: linuxppc-embedded@lists.linuxppc.org
Subject: Network problem when using jtag debugger on EP8260



I am attempting to debug the Linux Kernel on an Embedded Planet 8260
board,
using a COP JTAG debugger.  I am encountering a behavior where when I
halt
the kernel, and resume, the kernel's ability to access the network seems
to
be disturbed.  I am wondering if anyone has seen something like this
before.

Let me clarify the problem:

[Case 1]
- I boot the Linux kernel (version 2.4.22, obtained from Embedded
Planet)
- When I get to the prompt, I halt the target using the debugger.  The
target always seems to halt at address 0x904.
- I resume the target.  A network access (such as "ls") takes about 7
seconds, instead of being instantaneous.  (I'm not using a ramdisk, so
ls
uses NFS).
- If I halt and resume again, network access is slowed down even
further, certainly to the point of being unusable.

[Case 2]
- When I get to the prompt, I issue the command "while(true); do true;
done" which sets the kernel off and running infinitely (until I stop it
with Ctrl-C).
- Using the debugger, I halt the target.  I am not at 0x904, but
somewhere else, either in the kernel code, or in what seems to be a user

application page.
- I can stop, singlestep, resume, set and hit breakpoints using the
debugger.  When I finally stop the while loop, the network is fine.  All

of my debugging activity did nothing to disturb network access.

[Case 3]
- Same as Case 2.  This time, after halting the target, I set a
breakpoint on the first line in the function fcc_enet_rx.  I resume the
target.  This breakpoint is hit about 15 times, and then it is not hit
anymore.  When I attempt to stop the while loop, the network access has
been disturbed.

[Case 4]
- Same as Case 1.  This time, before I halt the target using the
debugger,
I unplug the ethernet cable.  Then I halt the target, and it is again
at 0x904.
- Now I resume the target using the debugger.
- Now I plug in the ethernet cable to the target again.
- Network accesses (i.e. ls) works fine.


My primary goal is to fix Case 1.  I do not want to lose network access
when I halt the kernel when it is idle.  Case 2 gives me hope that this
is possible, because this is a case where I can halt the Linux kernel
without disturbing the network access.

The JTAG debugger I am using is a Green Hills Probe.  I have also tried
with
an Agilent E5900B Emulation Probe and seen similar behavior.

Some questions:
- Has anyone seen this before?  If so, is there a known remedy or
workaround?  (For example, is there a kernel patch?  Is there a way to
recover from this slowed network state?)  If not, does anyone have
a theory to explain why I am seeing this behavior?
- Does this occur on the BDI2000 debugger?  I don't have access to one
of
those, but I hear that is the best JTAG debugger for Linux.  If anyone
can
easily try some of these test cases on other debuggers and let me know
the
results, that would be helpful.
- Is there any reason to think that the scenario I described in Case 1,
halting the target while at the shell prompt, is something that users
typically don't do (and hence, I shouldn't worry about it)?


Thanks in advance,
Jeff Mintz
Green Hills Software


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Network problem when using jtag debugger on EP8260

[Wolfgang Denk]

Dear Jeff,

in message <3FBD6775.C471A57B@ghs.com> you wrote:
>
> using a COP JTAG debugger.  I am encountering a behavior where when I halt
> the kernel, and resume, the kernel's ability to access the network seems to
> be disturbed.  I am wondering if anyone has seen something like this before.

Yes, we have seen this before. It is kind of a know problem.

> My primary goal is to fix Case 1.  I do not want to lose network access
> when I halt the kernel when it is idle.  Case 2 gives me hope that this
> is possible, because this is a case where I can halt the Linux kernel
> without disturbing the network access.
>
> The JTAG debugger I am using is a Green Hills Probe.  I have also tried
> with
> an Agilent E5900B Emulation Probe and seen similar behavior.

We use the BDI2000, and see the same. This is independed of the brand
of JTAG debugger used.

> Some questions:
> - Has anyone seen this before?  If so, is there a known remedy or
> workaround?  (For example, is there a kernel patch?  Is there a way to
> recover from this slowed network state?)  If not, does anyone have
> a theory to explain why I am seeing this behavior?

Yes, we have seen this.

Here is the theory:

When the debugger halts the CPU, it does NOT stop the  CPM.  Actually
ther  eis no way to stop the CPM. So if you have set up your ethernet
driver and provided it with a list of  buffer  descriptors,  the  CPM
will  continue to receive packets from the net and stuff theminto the
avialiable buffers. But when the CPU is stopped (in debug mode), than
the  coherence  between  cache  and  external  memory  is  no  longer
maintained.  The CPM during that time continues to work as programmed
and uses it's BDs sequentially, but the cache does not  get  updated.
When  the  CPU resumes operation, the cache contents is incorrect and
this is the cause of the driver problem.

We implemented a workaround once, but I don;t think we checked it  in
into  our  source  tree  because  it  involves  a certail performance
overhead (although it was quite useful during debugging).

If you're interested I think I can dig it out again.

> - Does this occur on the BDI2000 debugger?  I don't have access to one

Yes, it does.

> those, but I hear that is the best JTAG debugger for Linux.  If anyone can

Yes, it is :-)

But this is a problem of the CPU/CPM, not of the debugger.

> - Is there any reason to think that the scenario I described in Case 1,
> halting the target while at the shell prompt, is something that users
> typically don't do (and hence, I shouldn't worry about it)?

The easiest way to avoid the problem is to use  a  separated  network
for  the target - if only the target itself accesses the net (for NFS
root operation) all traffic will stop when you stop  the  CPU  -  but
make  sure there are no broadcast packets on it (i.e. don't work in a
windoze environment).


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A witty saying proves nothing, but saying  something  pointless  gets
people's attention.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Network problem when using jtag debugger on EP8260

[Wolfgang Denk]

Dear Jeff,

in message <3FBE9C69.36C74D2F@ghs.com> you wrote:
>
> > We implemented a workaround once, but I don;t think we checked it  in
> > into  our  source  tree  because  it  involves  a certail performance
> > overhead (although it was quite useful during debugging).
> >
> > If you're interested I think I can dig it out again.
>
> I would be very interested in the workaround, if you can dig it out.  It would
> be very helpful for our development.  Please send it, if you can.

I've put the patch on our FTP server. Please see

	ftp://ftp.denx.de/pub/patches/README.fcc_cache
	ftp://ftp.denx.de/pub/patches/fcc_cache.patch

Hope it helps.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Quantum particles: The dreams that stuff is made of.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/