>From Chas:

we had a little power problem on saturday afternoon so i havent been
wasnt able to reply earlier until i went in today and 'fixed' the problem.
but, after some thought, i think ->xoff should probably be volatile.
[see the attached patch].  eric picked up the 2nd edition of linux
device driver programming and the interrupt chapter is fairly useful.
see page 278, 'race conditions'   since xoff is set to 1 in only one
place it seems likely that this is a race condition.  clip_pop()
unsets ->xoff but after xmit_start exits, it resets xoff back to 1.
of course, the clip code cant recover from this situation either.
i think the flow control for clip could be cleaner.  like

. spin_lock on xoff_lock before changing xoff always or change xoff to
  atomic_t (is xchg() atomic?  i cant find any docs on it)
. stop the netif_queue BEFORE sending the pdu to the card driver
. allow clip to recover from XOFF->XOFF conditions