From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 20:09:37 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 1CE881065670 for ; Fri, 7 Oct 2011 20:09:37 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9E5D68FC08 for ; Fri, 7 Oct 2011 20:09:35 +0000 (UTC) Received: by wwe3 with SMTP id 3so6110749wwe.31 for ; Fri, 07 Oct 2011 13:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CtlW0YxKidBwcyty2yMeXtFmQ1QN8agRtnVSLB5biGY=; b=Q1YIL2OljbNd0h5CNy1ldLUaQnECyrWBPjXaEVU8q+Q2/IsXDUwMTl2ebiqKD7r31y DeAB9FSUHsbSUi1Bk1qHUFI1bm+arhqgTlyXUW9R2Ifs9VwYjZ/KGD4sIrPJWxAhl5PK u+s4YNr/8qDzO1dyOzmoYGfivu1Nb3VMzVnTM= MIME-Version: 1.0 Received: by 10.216.21.74 with SMTP id q52mr1250717weq.36.1318018174330; Fri, 07 Oct 2011 13:09:34 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Fri, 7 Oct 2011 13:09:34 -0700 (PDT) In-Reply-To: <20111007191154.GB11808@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> Date: Fri, 7 Oct 2011 16:09:34 -0400 Message-ID: From: Arnaud Lacombe To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , David Christensen , Pyun YongHyeon , Sean Bruno , "davidch@freebsd.org" Subject: Re: bce(4) with IPMI 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: Fri, 07 Oct 2011 20:09:37 -0000 Hi, On Fri, Oct 7, 2011 at 3:11 PM, YongHyeon PYUN wrote: > On Mon, Oct 03, 2011 at 04:06:18PM -0700, Sean Bruno wrote: >> On Mon, 2011-10-03 at 15:30 -0700, David Christensen wrote: >> > > > > I should probably say, this is freebsd7. =A0So I'll peruse the >> > > changelogs >> > > > > and see if 7 is missing something here. >> > > > > >> > > > > sean >> > > > >> > > > commenting this change out seems to be helping quite a bit with my >> > > > issue. =A0I think that this behavior may be wrong in the IPMI shar= ed/nic >> > > > case. =A0Thoughts? >> > > > >> > > > >> > > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=3D210261= &r2=3D210263 >> > > >> > >> > The main reason bce(4) needs to coordinate with NC-SI/IPMI >> > firmware is to make sure only one software entity manipulates >> > PHY registers. =A0When bce(4) is loaded it will have priority >> > over firmware (e.g. autoneg, speed, and duplex settings will >> > be set by the host). =A0If you don't bring up the interface in >> > the host the firmware isn't authorized to do so, which sounds >> > like your problem. >> > >> > Current bce(4) behavior notifies firmware that host driver >> > is running when resetting the device in bce_attach(). =A0We >> > tell firmware that host driver is still running through >> > bce_pulse(). =A0Not sure how to handle the FreeBSD model where >> > the driver load doesn't immediately bring the link up. >> > >> > Dave >> > >> >> Hrm, understood. >> >> What are your thoughts on noting that the IPMI f/w is running and >> leaving the interface up? =A0I'm poking around trying to find the right >> register bits at initialization to see that this is the case. >> > > How about disabling bce_pulse() for IPMI interface? I guess this > may result in not sending heart beat from driver to firmware such > that firmware may take over control back from driver. > The problem of the approach would be we don't know whether IPMI is > active in driver at attach time and we may need some way to take > control back from firmware once admin changed his/her mind to use > the controller as a normal interface. > >> What's even more strange is that our freebsd6 instances don't have this >> problem. >> > > Can't explain either but probably stable/6 bce(4) may have used old > firmware. > I may look ignorant, but shouldn't the link between the BCM and the MAC/PHY be totally independent from any OS involvement ? The BCM should still be able to communicate with the outer world even if the OS badly screw the NIC configuration, as long as the BCM is alive. - Arnaud