From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 20:17:16 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 63E211065675 for ; Wed, 12 Oct 2011 20:17:16 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 17BBD8FC13 for ; Wed, 12 Oct 2011 20:17:15 +0000 (UTC) Received: by qyk4 with SMTP id 4so551522qyk.13 for ; Wed, 12 Oct 2011 13:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sSKVKHl/GMp+Jk6vNaElU2491bzDRhsIQ8PNYxI2URg=; b=QkTwVvroXFaUGLIQnSfe227Bk5Gth6XoctFHPQq1/8oqv9b+D/c8WbIRfFF5CJBBVV SCQ1dtaWJloZIbULr8qU55f79+2e2AIEfIc2ds/HraCtvHz+58K5LEBW7f1GURf8n/Lz Ti+NouUr4s8Jz7WhoE7G10UMVAqE1re0m4uuE= Received: by 10.229.66.29 with SMTP id l29mr138139qci.134.1318450635313; Wed, 12 Oct 2011 13:17:15 -0700 (PDT) Received: from [192.168.1.71] ([208.85.112.101]) by mx.google.com with ESMTPS id et6sm4259740qab.4.2011.10.12.13.17.13 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 13:17:14 -0700 (PDT) Message-ID: <4E95F5C5.5050609@gmail.com> Date: Wed, 12 Oct 2011 16:17:09 -0400 From: Karim User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> <4E95DDEB.1090500@gmail.com> <20111012192730.GB9138@michelle.cdnetworks.com> In-Reply-To: <20111012192730.GB9138@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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 20:17:16 -0000 On 11-10-12 03:27 PM, YongHyeon PYUN wrote: > 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. > The way I understand this is EEE only works on GE ports and because this is set to 100MB it should be disabled. Moreover Cisco's has something called Green Ethernet which works on all ports but AFAIK the switch we're plugged in does not have those features. I find it disconcerting that the E1000_SSR register reports both E1000_SSR_LINK (0x400) and 'Sleep mode' (0x100) at the same time but I guess, as you mentioned, this might not be correctly reported. I will assume we can disregard that bit for now. >>> 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. So far so good, will have to give it the night to see. Again, thanks for all the help, Karim.