[ECOS] MPC860 Ethernet driver problem.

[Gary Thomas]

On 01-May-2001 Jonathan Larmour wrote:
> Geoff Patch wrote:
>> 
>> Hi All,
>> 
>> We have ported eCos to our custom MPC860 based board, and  we've run across
>> a problem with the Ethernet driver. The problem is that when the Ethernet
>> cable is disconnected from the board for more than a couple of seconds we
>> lose LAN connectivity permanently. In other words, when we reconnect the
>> LAN cable, we don't recover the connection.
>> 
>> I've had a look through the Ethernet driver in if_quicc.c and observed that
>> when the LAN is disconnected the function quicc_eth_can_send() starts
>> returning zero after a few transmission attempts, indicating that there are
>> no free transmit buffers available. Once we get into this state we never
>> recover from it.
>> 
>> I've implemented a quick brute force fix, which is to reinitialise the SCC
>> when this condition is detected.  This seems to work but I'm not real
>> pleased with it.
>> 
>> I'm unsure at the moment whether this is a generic problem, or something
>> that is characteristic of our particular board. Has anybody else observed
>> this problem, and if so come up with a more elegant solution?
> 
> I'm pretty sure we've tested this type of thing before on other platforms
> so I suspect quicc specific behaviour when it comes to processing the
> packet.
> 
> See if you can debug the interrupt handler after you've disconnected the
> cable to see if you ever get an interrupt, and if you do, what type it is.
> 
> I've seen another problem I believe: if the ring buffer fills up it starts
> overwriting old txbd's. But if it doesn't call the higher layer's txDone,
> the mbuf won't ever be freed as far as I can tell. Perhaps it's even the
> same problem and you're out of mbufs? Try adding a call to
> quicc_eth_TxEvent after the "No free xmit buffers" printf in
> quicc_eth_send(). I think :-).
> 
> Gary, care to comment?

More likely is that with no carrier, the "engine" won't send packets and
needs to be kicked when the carrier is restored.  If the packet is not
consumed by the ethernet chip (engine), the driver will stop trying to
send anything.

I'm sure that there is room for improvement in this driver.  In particular,
adding some timeout mechanisms to deal with the case when packets are not
going out - currently it will just get stuck.