From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 19:29:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B309B106566B for ; Wed, 12 Oct 2011 19:29:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 316F28FC14 for ; Wed, 12 Oct 2011 19:29:17 +0000 (UTC) Received: by wyj26 with SMTP id 26so1584525wyj.13 for ; Wed, 12 Oct 2011 12:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=fP1e2eFlTrWuy3c+gR5mQheGLBAND2l11OmBx3tk+dE=; b=qhPDl1fzS5qjNjrcMxiN2xo5BZ/qjl/1686GWev7iSnQZuIlTIUcT7JBO6wg0MLeyB io2n+gqaLirYqzWNp3bpUrPnzsL/YIs4efQB9gMMQ6nXmHmtxg1xNUGV6erIZD1O/44X LGljGNNx47H7HSkm/CC5Drva6Dstvb00hoFnE= Received: by 10.216.134.166 with SMTP id s38mr120354wei.71.1318447756825; Wed, 12 Oct 2011 12:29:16 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id n21sm1782204wbp.2.2011.10.12.12.29.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Oct 2011 12:29:15 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Oct 2011 12:27:30 -0700 From: YongHyeon PYUN Date: Wed, 12 Oct 2011 12:27:30 -0700 To: Karim Message-ID: <20111012192730.GB9138@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> <4E95DDEB.1090500@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E95DDEB.1090500@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: if_msk.c link negotiation / packet drops X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 19:29:18 -0000 On Wed, Oct 12, 2011 at 02:35:23PM -0400, Karim wrote: > Hi, > On 11-10-12 01:03 PM, YongHyeon PYUN wrote: > >On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: [...] > >Hmm, that indicates driver lost established link. msk(4) will > >detect this condition and stop RX/TX MACs until it knows PHY > >re-established a link. This may be the reason why you see occasional > >packet drops. However I don't know why PHY loses established link > >in the middle of working. > > > Yes, I am convinced this lost of link is related to the packet drops as > well. At this point we can safely discard cabling issues or router > issues (physical ones that is) since the same happens on a different > network with different cables. > >> From the code in e1000phy_status: > >> > >>static void > >>e1000phy_status(struct mii_softc *sc) > >>{ > >> struct mii_data *mii = sc->mii_pdata; > >> int bmcr, bmsr, ssr; > >> > >> mii->mii_media_status = IFM_AVALID; > >> mii->mii_media_active = IFM_ETHER; > >> > >> bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > >> bmcr = PHY_READ(sc, E1000_CR); > >> ssr = PHY_READ(sc, E1000_SSR); > >> > >> if (bmsr& E1000_SR_LINK_STATUS) > >> mii->mii_media_status |= IFM_ACTIVE; > >> > >> > >>I can see the bmsr& E1000_SR_LINK_STATUS check failing when the problem > >>occurs. As a side note why are we ORing the same call twice isn't the > >>same thing as calling it once: > >> > >>bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > >> > >The E1000_SR_LINK_STATUS bit is latched low so it should be read > >twice. If you want to read once use E1000_SSR_LINK bit of > >E1000_SSR register but I remember that bit was not reliable on some > >PHY models. > Thanks for the explanation and the alternative. The ssr register seems > to give me the right bit (E1000_SSR_LINK) but it also gives me an extra > bit 0x0100 that is not defined in e1000phyreg.h. Any idea what that bit > would be/means? > I guess it's related with advanced power saving. It would indicate current Energy detect status in PHY POV. Generally Marvell's PHY will enter into automatic power saving mode when it does not see any energy signal on the link. I don't know exact time when it enters into that mode but it would take less than 10 seconds if PHY do not see energy signal from link partner once it initiated auto-negotiation. However, e1000phy(4) always disables energy detect feature in e1000phy_reset() so it wouldn't affect your issue, I guess. One interesting thing is that 0x100 of E1000_SSR register indicates energy detect status is in "Sleep mode" which means it didn't detect energy signal(i.e. lost link). I'm not sure whether this bit report correct status when energy detect feature is disabled though. Can you check whether your switch supports energy detect feature? Or if your switch support EEE feature, try disabling it. > >By chance, does your back-ported driver include r222219? > >If yes, did you cold boot after applying the change? > >Warm boot does have effect. > I do have this patch in the back-ported driver and due to several > reasons I didn't cold boot the appliance. We will give that a try and see. > Ok, let me know whether that makes any difference or not. > To be more precises I have included msk patches up to r222516. > > Thanks! [...]