The fxp driver doesn't use transmit interrupts.  Under normal traffic 
patterns this works fine.  The work gets done on the next receive 
interrupt, saving the CPU cycles that would have been burned by the 
overhead on each transmit interrupt. 

But it doesn't work very well if you run crazy test programs that 
only send UDP packets in one direction.  The watchdog timer eventually 
catches things, but that takes a long long time and it puts a lot 
of "fxp0 timeout" messages on the screen. 

Netperf includes a test like that.  It's a simple way to check for 
the classic live-lock troubles where the receiver spends all its 
CPU cycles processing a packet only to discover that the input socket 
queue is full so it drops the packet. 

Has anybody else encountered this quirk?  Is this enough of a bug 
that I should send a PR? 

I found the place in the code where it sets up the transmit command.  
(That's not hard, the symbol is only used once.)  When I or-ed in 
the interrupt bit, things worked as expected.  (I forget to measure 
how much more CPU that used.) 

I tried turning on the interrupt bit when the transmit queue was 
3/4 full but either I botched the code or that wasn't a good enough 
heuristic. 



I think I've also discovered a variation of this glitch.  If the 
TCP window is big enough, throughput drops way off.  The break happens 
between 190K and 195K.  That's slightly over 128 packets which is 
the size of the fxp transmit queue. 

On a pair of 400 MHz Celerons, throughput drops from 90 megabits 
with the window under 190K bytes to under 20 when the window is over 
195K bytes.