On Wed, 24 Aug 2011 10:02:22 -0700 Andy Cress <[email protected]> wrote:
> Thanks Jesse, that helps. > > The upshot of all this is that I believe we need an alternative way of > detecting mng_mode for onboard IPMI BMCs, which could be implemented > in a check_mng_mode_ipmi() routine perhaps. The cases I'm most > interested in are Intel S5000PAL and S5520UR motherboards > (80003ES2LAN and 82575EB NICs, respectively). > > Option 1: check_mng_mode_ipmi() I know that this information could be > queried using a local KCS interface with the IPMI GetChannelAccess > command, which should not be too difficult if the OpenIPMI driver is > already there (#ifdef CONFIG_IPMI). what about something not so kernel based. It seems to me all we are missing is a user-space override that communicates to the driver "yeah, I know (as the administrator) that I'm not using IPMI, so port power down is okay." We could do this with a small driver enhancement possibly using ethtool private flags that would allow the driver to "override" the check_mng_mode_generic result, and power down the phy anyway. This functionality in the driver would allow for a user space script to query ipmi, make sure it was disabled, and then enable the "override" via ethtool. > Option 2: Allow a compile-time driver option to toggle whether or not > the check_mng_mode_generic() returns according to the existing > hard-coded bits, or returns a hard-coded zero (allowing those > functions to occur), which would require the user to ensure that IPMI > LAN had been disabled before exercising this. > > Would you like me to take a stab at implementing option 1, or do you > have a better idea? > > Andy > > -----Original Message----- > From: Jesse Brandeburg [mailto:[email protected]] > Sent: Wednesday, August 24, 2011 12:25 PM > To: Andy Cress > Cc: Dave, Tushar N; [email protected] > Subject: Re: [E1000-devel] e1000e check_mng_mode issue > > On Tue, 23 Aug 2011 14:38:18 -0700 > Andy Cress <[email protected]> wrote: > > > Tushar, > > > > Thanks for running this down. So that means that the current driver > > implementation would never allow a NIC which has a BMC sideband > > connection physically to ever power off the PHY. > > > > That doesn't seem like the right approach. I realize that it would > > be difficult to convey whether an IPMI session is active or not and > > it > > I'm not an ipmi expert, but as I understand it, if the BMC firmware is > *running on our networking chip* then I think we could identify that. > If we are running as JUST the smbus transport layer, we just have a > simple wire interface for smbus, that can receive packets from an > external BMC at any time. The NIC actually knows nothing about the > smbus connection except maybe that it *might* have added a MAC address > to our receive filter. > > > may not be desirable to power down the PHY if there could be > > incoming IPMI management traffic, but there should be a way to > > detect if the IPMI configuration has the channel enabled or not. > > If IPMI LAN is not enabled, the PHY can safely be powered down. > > In the case of an external BMC, this becomes really difficult to know > (I'm not sure it isn't possible, however) > > > > Obviously it would be simple to ignore these bits in the driver to > > get it to work, but that's not optimal. > > > > If the BMC is asserting these bits without regard to the > > configuration of the IPMI LAN channels, perhaps that is where the > > bug could be pursued, to fix the firmware? Or should the driver > > use another mechanism to discern whether IPMI LAN is enabled or not > > (KCS, ...)? > > we have had zero luck getting external BMC vendors to update their > code. One time we managed to get Intel to fix its external BMC. The > lesson we've learned so far is changing BMCs is really really hard. > > I think the bits are actually decided by the "type" of NVRAM image we > are loading, it is statically set at manufacturing time. > > > > > Andy > > > > -----Original Message----- > > From: Dave, Tushar N [mailto:[email protected]] > > Sent: Tuesday, August 23, 2011 5:07 PM > > To: Andy Cress; [email protected] > > Subject: RE: e1000e check_mng_mode issue > > > > Andy, > > These bits gets set by internal BMC firmware when the code is > > initialized. It does not depend on whether there is currently an > > active IPMI session. > > > > -Tushar > > > > -----Original Message----- > > From: Andy Cress [mailto:[email protected]] > > Sent: Friday, August 12, 2011 2:30 PM > > To: Dave, Tushar N; [email protected] > > Subject: RE: e1000e check_mng_mode issue > > > > Tushar, > > > > But if 'management mode' means that IPMI LAN is enabled or in use, > > then this indication is yielding a false result, because IPMI LAN is > > disabled. Those bits are always set regardless of the state of the > > IPMI LAN configuration. > > > > So what drives those bits? Does the IPMI firmware drive them, or > > do they depend on the NIC firmware, or ...? > > > > Andy > > > > -----Original Message----- > > From: Dave, Tushar N [mailto:[email protected]] > > Sent: Friday, August 12, 2011 4:58 PM > > To: Andy Cress; [email protected] > > Subject: RE: e1000e check_mng_mode issue > > > > Andy, > > > > The define constant name (i.e. E1000_MNG_IAMT_MODE) is little > > confusing. The objective of e1000_check_mng_mode_generic() is to > > check if Management is enabled or not. It doesn't care about what > > MNG mode is enabled(e.g AMT or IPMI). > > > > If Management is enabled then FMSW (bit 3:1) should have value 0x3 > > (This value is loaded from EEPROM word 13h). > > So all e1000_check_mng_mode_generic() does is check if the FMSW's > > bit 3:1 is equivalent to value 0x3. > > > > Let me know if you have any more queries. > > > > -Tushar > > > > > > -----Original Message----- > > From: Andy Cress [mailto:[email protected]] > > Sent: Friday, August 12, 2011 1:23 PM > > To: Dave, Tushar N; [email protected] > > Subject: RE: e1000e check_mng_mode issue > > > > Tushar, > > > > Right, my eth0 is 80003ES2LAN. > > Attached is the 'ethtool -e eth0' output (eth0.e). > > > > Andy > > -----Original Message----- > > From: Dave, Tushar N [mailto:[email protected]] > > Sent: Friday, August 12, 2011 12:48 PM > > To: Andy Cress; [email protected] > > Subject: RE: e1000e check_mng_mode issue > > > > Andy, > > Thanks for your patience. I am looking into this. > > (assuming your eth0 device is 80003ES2LAN) Can you provide 'ethtool > > -e eth0' output? > > > > -Tushar > > > > > > -----Original Message----- > > From: Andy Cress [mailto:[email protected]] > > Sent: Tuesday, August 09, 2011 2:21 PM > > To: [email protected] > > Subject: [E1000-devel] e1000e check_mng_mode issue > > > > > > This may apply to other NICs with an IPMI BMC instead of AMT, but > > here's my configuration: > > Baseboard: Intel S5000PAL > > Onboard NICs (2): 80003ES2LAN > > And this has an IPMI BMC on the baseboard with sideband connections > > to the onboard NICs. > > > > # ethtool -I eth0 > > driver: e1000e > > version: 1.0.2.5-NAPI > > firmware-version: 1.0-0 > > bus-info: 0000:07:00.0 > > > > For the e1000e driver, the 80003ES2LAN uses the > > e1000_check_mng_mode_generic() routine in manage.c. It seems to > > always return 0x18006 from the firmware semaphore register, > > regardless of whether or not the firmware has any IPMI LAN channels > > enabled or not. This routine is the same in the latest stable > > e1000e-1.4.4.tar.gz. > > > > The code indicates that it is checking for E1000_MNG_IAMT_MODE (3 << > > 1), and the 0x06 part is always set. Does this mean that the > > firmware semaphore register bits that are checked apply to Intel > > AMT, but not to IPMI? > > > > Should there be a different routine for IPMI (non-AMT) management > > systems? > > > > Andy ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
