From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 19:13:58 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 2A69C106566B; Fri, 7 Oct 2011 19:13:58 +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 57DD18FC12; Fri, 7 Oct 2011 19:13:57 +0000 (UTC) Received: by wyj26 with SMTP id 26so5796112wyj.13 for ; Fri, 07 Oct 2011 12:13:56 -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=xQb+X0tjRKYsLS0oTiweSmHMdAoP7pTfIjJ4DjFPL8s=; b=td1RAApwTRV8gF3GCRCJmwcBgO9KaGKLCY0l01mmhL8To5ajYlb6Dss12pYskyCaLs dZlY5HfpA+XrwnbRgbKu07aoGs7racqMdydbnfxyqYDTOGgNh05A9vNd/GPCwBGEc6sV A89dsyg3CPI895iW9/yKNmSVdGfhQ5LyGp4HI= Received: by 10.216.134.217 with SMTP id s67mr2709372wei.101.1318014836246; Fri, 07 Oct 2011 12:13:56 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id ei16sm17639913wbb.21.2011.10.07.12.13.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 12:13:54 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 07 Oct 2011 12:11:54 -0700 From: YongHyeon PYUN Date: Fri, 7 Oct 2011 12:11:54 -0700 To: Sean Bruno Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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: Fri, 07 Oct 2011 19:13:58 -0000 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. So 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. I think that this behavior may be wrong in the IPMI shared/nic > > > > case. Thoughts? > > > > > > > > > > > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210261&r2=210263 > > > > > > > The main reason bce(4) needs to coordinate with NC-SI/IPMI > > firmware is to make sure only one software entity manipulates > > PHY registers. When bce(4) is loaded it will have priority > > over firmware (e.g. autoneg, speed, and duplex settings will > > be set by the host). If 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(). We > > tell firmware that host driver is still running through > > bce_pulse(). Not 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? I'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. > Sean >