Date: Sun, 30 Oct 2011 17:23:49 -0700 From: YongHyeon PYUN <pyunyh@gmail.com> To: Hooman Fazaeli <hoomanfazaeli@gmail.com> Cc: freebsd-net@freebsd.org, Jason Wolfe <nitroboost@gmail.com>, Emil Muratov <gpm@hotplug.ru>, Jack Vogel <jfvogel@gmail.com> Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled Message-ID: <20111031002349.GA1679@michelle.cdnetworks.com> In-Reply-To: <4EAD116A.8090006@gmail.com> References: <CAAAm0r1iS3z-7CBJ=xYDf%2BJOA1Q2nU0O54Twbyb7FjvgWHjKVw@mail.gmail.com> <4EA7E203.3020306@sepehrs.com> <CAAAm0r3Nr2t8cCetPkFnLQ-3KwqHw_0SpqbtvYPRUkSP=9n8CA@mail.gmail.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111031002349.GA1679>