Re: dcache BUG()

[David Blythe <blythe@routefree.com>]

Dan Malek wrote:


> There may be something else wrong with the Ethernet driver itself.
> When I updated it to the 2.4_devel baseline, there were some weird
> cache management calls that didn't make sense.  My updates were to
> use the standard non-coherent cache management functions, and I
> changed the logic to make sense (to me :-).  From this quick update,
> I noticed it would be nice to make the transmit more efficient
> and higher performance by handling multiple frames, but it should
> function properly.

There are a large number of bugs in the 405 ethernet driver.  We (I)
were waiting until we had resolved this reference count problem, and had
a some workable solution to the starvation under packet floods problem
discussed a few weeks ago with other embedded processors before posting
a patch (i.e., have the driver stand up to reasonable stress tests).
Among the bugs are:

leaks of all the receive buffers, plus other memory on every device
close,
not checking for failed allocations in skb allocations,
poor choice of cache operations when manipulating buffers,
race conditions in data structure access between the rxde and rxeob
interrupt handlers

In either event we had proven to ourselves that this "reference count"
bug happened with other nic cards when used with the 405GP processor, so
we are reasonably certain that it is not specific to the 405 ethernet
driver.  As Eli mentioned ping flooding demonstrates the problem too so
we still believe that it is a generic atomic op problem.  However, we
can only make it happen on our 405GP walnut board(s) and not our
prototype 405GP board(s) (they both have rev D processors).

Just to refresh everyone's memory, the other reference count problems we
were seeing were "Freeing alive device" messages indicating the dev
reference count had gone to zero, and another one in the skb code when
ping flooding with large packet sizes (causing lots of fragments to be
generated).

	david

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