PPC405GP Ethernet Driver

Chris Johns chrisj at rtems.org
Thu Aug 4 00:28:48 UTC 2005


Doyle, Bryon Thomas (Bryon) wrote:
> Hello again, I have managed to correct the previous flaw of my driver eating up all
> the available mbufs, thanks to everybody who gave their input.

Great.

> Now however I have
> a seemingly more insidious problem. I have been testing the driver using the netdemo
> application and setting up my host PC to constantly ping away at the board. I have
> noticed something rather strange, after a completely random interval of time the
> board hangs. I have had the board test for several hours, and then in other instances
> it hung after only a couple of minutes, the only constant is that sometime the board
> does eventually hang.  I am inclined to think that a memory leak is the problem but
> I have no clue where it could be. My mbuf usage is normal, and all the wrap bits and
> buffers for the hardware DMA access buffers are properly configured. 

When you say the board hangs, do you mean the networking code stops 
responding or the processor locks up and needs a reset ?

The differences are:

1) Networking hang could mean a race condition or missed or lost 
interrupt, or incorrect buffer chain in the networking device.

2) The CPU hang could mean a loop in an interrupt, bad DMA cycle or 
general pointer problem.

> Has anyone experienced a similar problem with RTEMS?

Yes. Any where I have had to play with network drivers. Maybe it says 
something about me !

I have seen this sort of problem occur when you get another packet about 
the same time or within a specific period of time around the arrival of 
your expected data (ping data). The random nature is provided by the PC 
software. For example an arp cache refresh or a Windows network browse 
packet. These are normally broadcast packets so your board will see them.

I suggest a few things to try.

Start a ping on the PC to an address that does not exist. This will 
cause arp broadcast packets. If the hang happens in a more repeated 
manner you have a way to expose the driver bug.

Increase the size of the ping. Pay attention to the point the ping data 
spans more than one ethernet frame. Also test with a ping of 30K+ bytes. 
Start a number of pings on the PC to the same box with different sizes.

Run a flood ping.

-- 
  Chris Johns



More information about the users mailing list