On Wed, 2004-12-15 at 10:03, Thomas Spatzier wrote:

jamal [off-list ref] wrote on 15.12.2004 14:50:27:

quoted

When you netif_stop_queue you should never receive packets anymore
at the device level. If you receive any its a bug and you should drop
them and bitch violently. In other words i think what you have at the
moment is bandaid not the solution.

When we do a netif_stop_queue, we do not get any more packets.
So this behaviour is ok. The problem is that the socket write
queues fill up then and get blocked as soon as they are full.

This is the strange part. Anyone still willing to provide a sample
program that hangs?

quoted

Can you describe how your driver uses the netif_start/stop/wake
interfaces?

Before the patch we are talking about:
When we detect a cable pull (or something like this) we call
netif_stop_queue and set switch off the IFF_RUNNING flag.
Then when we detect that the cable is plugged in again, we
call netif_wake_queue and switch the IFF_RUNNING flag on.

Not too bad except user space doesnt get async notification.

And with the patch:
On cable pull we switch off IFF_RUNNING and call
netif_carrier_off. We still get packets but drop them.
When the cable is plugged in we switch on IFF_RUNNING and
call netif_carrier_on.

Ok, thats something you need to change.
Why you are setting that IFF_RUNNING flag?
Look at e1000 they do it right there. 

On link up:
	netif_carrier_on(netdev);
	netif_wake_queue(netdev);
On Link Down:
	netif_carrier_off(netdev); // wonder if these need swapping
	netif_stop_queue(netdev);

Still, I think we need to resolve the original problem.
And I have a feeling we wont be seeing any program which 
reproduces it ;->

cheers,
jamal