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
