Date: Thu, 13 Sep 2007 10:11:22 -0400 From: "Robert Wojciechowski" <robertw@expressyard.com> To: <pyunyh@gmail.com> Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, Josh Mouch <jmouch@expressyard.com> Subject: RE: FreeBSD nfe driver and IPMI cards Message-ID: <85D4F2C294E8434CA0AF7757415326866236A2@server1.ssgi.local> In-Reply-To: <20070913112624.GC13071@cdnetworks.co.kr> References: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> <20070912004554.GA8992@cdnetworks.co.kr> <85D4F2C294E8434CA0AF775741532686623694@server1.ssgi.local> <20070913112624.GC13071@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?85D4F2C294E8434CA0AF7757415326866236A2>