From owner-freebsd-net@FreeBSD.ORG Wed Sep 12 12:47:32 2007 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 A0FF516A417 for ; Wed, 12 Sep 2007 12:47:32 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by mx1.freebsd.org (Postfix) with SMTP id 5D3D013C46A for ; Wed, 12 Sep 2007 12:47:32 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 14643 invoked from network); 12 Sep 2007 12:20:51 -0000 Received: from unknown (24.144.77.243) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 12 Sep 2007 12:20:49 -0000 Message-ID: <46E7D9A2.2090106@seclark.us> Date: Wed, 12 Sep 2007 08:20:50 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pyunyh@gmail.com References: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> <20070912004554.GA8992@cdnetworks.co.kr> In-Reply-To: <20070912004554.GA8992@cdnetworks.co.kr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, Robert Wojciechowski , Josh Mouch Subject: Re: FreeBSD nfe driver and IPMI cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 12:47:32 -0000 Pyun YongHyeon wrote: >On Tue, Sep 11, 2007 at 03:01:53PM -0400, Robert Wojciechowski wrote: > > Hello, > > > > > > > > I'm the FreeBSD nfe driver from > > http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html > > with FreeBSD 6-stable with good results for the most part. The only > > issue I've experienced is that during a detach/shutdown of if_nfe, the > > IPMI IP address I have set on my servers ceases to respond as well as > > the ability to manage the servers. > > > > > > > > I traced the problem down to nfe_stop() and the fact that it completely > > disables the Rx and Tx on the NIC. I have patched the driver to not > > disable the Rx/Tx and IPMI continues to work after a 'ifconfig nfe0 > > down', 'shutdown -p now', etc. > > > > > > > > Does anyone have any comments on this change I've made and any possible > > side effects? Can this be included in the mainstream distribution of the > >Because MAC is still alive if's possible to recieve a packet. All DMA >maps are unloaded and buffers are already freed in nfe_stop so it >would cause panic I guess. But I'm not familiar with IPMI so I'm not >sure. > > > nfe drivers (and updated in 7-CURRENT) without causing any adverse > > problems? > > > >I have no experience on IPMI but the change you've made would not >completely solve the issue. I guess supporting IPMI needs lots of >more work including: > o Autodetect IPMI capability. > o Autodetect active IPMI session in device attach and don't blindly > reset MAC/PHY. > o Don't blindly stop Tx/Rx on device detach. >Given that lack of publicly available datasheet for the hardware >supporing IPMI would be severly limited. Fortunately Linux seems to >have basic IPMI support in their forcedeth driver. Their code doesn't >easy to read but you may see what should be done in driver. However >I have no idea what we can do when active IPMI session is present in >driver attach phase. Normally PHY driver would reset PHY hardware >itself in driver attach which in turn would result in losing the IPMI >connection. > > > www.intel.com/design/servers/ipmi -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)