Network problem when using jtag debugger on EP8260
wd at denx.de
Sat Nov 22 02:51:15 EST 2003
in message <3FBD6775.C471A57B at 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
> 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
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
A witty saying proves nothing, but saying something pointless gets
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-embedded