Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

In article <[e-mail]> you wrote:
> Is this a change of requirements for ethernet drivers?  Many other drivers
> do exactly the same (drop the first few packets while they're negotiating
> with a hub), unless they're using 10base2, even back to the days of 2.0
> kernels.

I think it would make sense, from the other sides perspective, to only return 
from the "up" function when you actually can send packets[1]. Sure, pump show
this most of all because it does

"up"
send DHCP req
wait
if failed "down"
	  wait
	  repeat

and that sucks if you always eat the first packets after an up...

xircom had this bug for a loooong time, 8139too just got it a few weeks ago
and, well, from an applications point of view expecting to be able to send
packets when the interface is up makes sense.

Applications like pump must be robust against "random" packetloss, and,
well, pump is. Just not against the "targeted" packetloss of loosing every
first few packets.

Greetings,
   Arjan van de Ven

[1] I know this is not always easy for the driverwrite. For one, xircom
    will eat every first few packets, so the driver would have to send a few
    fake packets to get going.