Messages in this thread | | | Date | Sun, 10 Jun 2001 10:39:43 +0100 (BST) | From | arjan@fenrus ... | Subject | Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1 |
| |
In article <20010610093838.A13074@flint.arm.linux.org.uk> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |