From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 18:43:29 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 1FE081065673 for ; Thu, 29 Sep 2011 18:43:29 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id CF84C8FC0C for ; Thu, 29 Sep 2011 18:43:28 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B4A3028429; Thu, 29 Sep 2011 20:27:15 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id E44FA28424; Thu, 29 Sep 2011 20:27:14 +0200 (CEST) Message-ID: <4E84B882.7040400@quip.cz> Date: Thu, 29 Sep 2011 20:27:14 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Sean Bruno References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@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: Thu, 29 Sep 2011 18:43:29 -0000 Sean Bruno wrote: > We've been getting reports of odd behavior on our Dell R410 machines > when trying to use IPMI. The servers have two NIC's that we have > assigned as the IPMI interface(bce0) and production interface(bce1) > respectively. > > Since we don't actually configure bce0 in FreeBSD, we've found that the > IPMI interface deactivated when bce(4) loads. I assume that the driver > is not initializing the interface correctly in this case and the default > case is to turn the interface off. Does it make sense to completely > turn off the interface when there is an active link on the port, but no > configuration assigned? I had similar problem few years ago with bge interface. There is following loader tunable option for it: hw.bge.allow_asf Allow the ASF feature for cooperating with IPMI. Can cause sys- tem lockup problems on a small number of systems. Disabled by default. Is it possible that something similar is needed for bce too? Miroslav Lachman