Date: Wed, 12 Sep 2007 08:20:50 -0400 From: Stephen Clark <Stephen.Clark@seclark.us> To: pyunyh@gmail.com Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, Robert Wojciechowski <robertw@expressyard.com>, Josh Mouch <jmouch@expressyard.com> Subject: Re: FreeBSD nfe driver and IPMI cards Message-ID: <46E7D9A2.2090106@seclark.us> In-Reply-To: <20070912004554.GA8992@cdnetworks.co.kr> References: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> <20070912004554.GA8992@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46E7D9A2.2090106>