On Sun, Oct 30, 2011 at 12:27:14PM +0330, Hooman Fazaeli wrote: > > I finally managed to re-produce an affect similar to Jason's case. It > may not be the exact same issue, but it is a serious problem and must > be addressed. > > 1. Push out packet on em/igb with high rate. > 2. Disconnect cable and wait for a few seconds. "netstat -ind" shows that > Drops are increasing. > 3. Re-connect the cable. Both sides of like re-negotiate and the links > comes up. > 4. But ..., no packets is ever transmitted again and Drops still increasing! > > This is because em/lem/igb and some other interfaces (i.e., bce) have > a check at the very beginning of their _start function > which checks link status and immediately returns if it is inactive. > This behavior causes if_snd to fills up in step 2 and when this happens, > IFQ_HANDOFF never calls if_start again, even when the link becomes > active again. > > A cable unplug is not necessary to trigger the issue. Any temporary > link loss (e.i., during re-negotiation) can potentially lead to > aforementioned problem. > > IMHO, this is not a driver issue and the real fix would be to change > IFQ_HANDOFF to call if_start when the queue is full. >
It would be normal not to call IFQ_HANDOFF when driver queue is full since it would be waste of time to invoke driver TX routine again. If driver fails to send queued frames again when it re-established a link it sounds like a driver bug. Of course, there is a problem here as driver can send queued frames without knowing how much time the frame queued in TX queue. Depending on application this behavior may or may not useful. > Jason, If you are interested, I can prepare a patch for you > to address this issue in if_em and see if it helps. > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
