From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 14:10:56 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 23C0216A417 for ; Thu, 13 Sep 2007 14:10:56 +0000 (UTC) (envelope-from robertw@expressyard.com) Received: from ssg1.ssginnovations.com (ssginnovations.com [205.145.135.135]) by mx1.freebsd.org (Postfix) with ESMTP id D84AE13C465 for ; Thu, 13 Sep 2007 14:10:55 +0000 (UTC) (envelope-from robertw@expressyard.com) Received: from server1.ssgi.local (unknown [205.145.129.164]) by ssg1.ssginnovations.com (Mail Daemon) with ESMTP id 0FB994128; Thu, 13 Sep 2007 10:15:00 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Sep 2007 10:11:22 -0400 Message-ID: <85D4F2C294E8434CA0AF7757415326866236A2@server1.ssgi.local> In-Reply-To: <20070913112624.GC13071@cdnetworks.co.kr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD nfe driver and IPMI cards Thread-Index: Acf1+W+yEidDPnlmTLW9yXLdvOpmJgAEgNEQ References: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> <20070912004554.GA8992@cdnetworks.co.kr> <85D4F2C294E8434CA0AF775741532686623694@server1.ssgi.local> <20070913112624.GC13071@cdnetworks.co.kr> From: "Robert Wojciechowski" To: Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, Josh Mouch Subject: RE: FreeBSD nfe driver and IPMI cards 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, 13 Sep 2007 14:10:56 -0000 > You may only want to enable IPMI Tx/Rx. Blindly enabling entire MAC > generates more problems. forcedeth uses different bits for IPMI Rx/Tx. >=20 Oh, hmm. I didn't see anything in forcedeth 0.60 that only enabled the IPMI Rx/Tx. It does turn out that I was looking at an older version, though, and that they now set the packet filter to non-promisc mode just in case before starting the Rx. I updated the patch to include that. > > > > I have attached my new patch to this email that does the above, > > guarded by the sysctl. > > >=20 > Btw, it seems there is typo in the patch. You used sc- > >nfe_process_limit > instead of sc->nfe_enable_ipmi in enable_ipmi value range check. In > order to check IPMI capability you don't need '&' operator. >=20 Oops, yes. The typo and dereferencing were mistakes, thanks for catching that. Updated in the patch. > > I have no idea how to handle the second case you mentioned, during > > attach. It does indeed cause a disruption in IPMI, but only for a few > > seconds. Where is the MAC and PHY reset and if it wasn't reset when > > using IPMI, what problems could it cause? > > >=20 > It's somewhat complex. MAC reset is done by nfe(4) whereas all PHY > related handling is done by its PHY driver(ciphy(4), e1000phy(4), > rgephy(4), rlphy(4) etc) and link state change event can also > enable/disable MAC. See nfe_link_task(). > Witout proper reset operation of PHY, some functions like automatic > MDI/MDI-X detection, wakeup from powerdown mode, special page register > settings wouldn't be activated which in turn result in operating at > legacy mode. In worst case the PHY wouldn't work at all and you may > see no link, i.e. "no career" message. >=20 This is probably also a problem for many other NICs I'm assuming? Not many drivers seem to handle detection of ASF/IPMI and initialize carefully to avoid causing problems. That being said, with the changes in this current patch at least a machine is manageable if you reboot/shutdown/unload the module. Perhaps handling the attach perfectly will have to wait until Nvidia opens up the specs. -- Robert