RE: 8xx_io/enet.c

["Stephan Linke" <Stephan.Linke@epygi.de>]

Hi Joakim,

> > Since the errors are reported on packet base it is always the last
packed
> > that get's corrupted. (I think it's like this: when there are no more
> > buffers the CPM simply continues writing on the current buffer causing
this
> > problem).
>
> I think not, once the CPM has received a packet in a BD, it
> closes that BD and
> will not modify that BD until you tell the CPM its free again. Atleast
> this should be the case for the SCC, don't know if the FEC is supposed
> to do the same
>

we are using the one in the 2.4.18 kernel (hardhead). Sorry I don't actualy
know wich patch. :(

But I recall that we had this problem with fec.c while our CPU was under
heavy load. But I think it's the same situation on enet.c.
Finaly you are right. SCCE_ENET_BSY dosn't cause such problems. At the FEC
there is no BSY interrupt event. There's only BD_ENET_RX_OV signaling a
buffer overflow. Since that is an error condition the buffer has to be
discarded leading to the  condition I tried to describe.
It looks like BD_ENET_RX_OV occures in enet.c ONLY for 'oversized' frames.
On FEC it occures on missing BD's too cuasing that stupid behavior.
I didn't expect that mutch of a difference. Sorry.


Stephan


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