bce(4) with IPMI

[YongHyeon PYUN]

On Tue, Oct 11, 2011 at 12:52:25PM -0700, Sean Bruno wrote:
> 
> > > > The Broadcom MFW is configured to load/not load through an NVRAM 
> > > > option that is likely not affected by the iDRAC BIOS settings.
> > > > To disable MFW you'd need to run the user diagnostic utility
> > > > (UXDIAG.EXE) with the following command line:
> > > > 
> > > > C:\>uxdiag -mfw 0
> > > > 
> > > > To turn it back on run the following:
> > > > 
> > > > C:\>uxdiag -mfw 1
> > > > 
> > > > You can find a bootable CD with the user diagnostic here:
> > > > http://www.broadcom.com/support/license.php?file=NXII/Xdiag-5.2.2.iso
> > > > 
> > > > Dave
> > > > 
> > > 
> > > Ah, ok.  
> > > 
> > > 
> > > Pyun:
> > > 
> > > Should I do this on a host and validate your changes?
> > > 
> > 
> > That would be great if you can. Because some part of code is not
> > executed in my patch when firmware is not running. Previously
> > bce(4) executed that code regardless of firmware running state.
> > 
> > > Sean
> > > 
> > > 
> 
> 
> Ran this on my Dell R410.  I can clearly see that the tool is
> "disabling" the MFW bit, and that the dell bios interface to the IPMI
> controller/DRAC is impaired, however ...
> 
> The system still thinks that the MFW bit is "ON" and proceeds normally
> in this case.  The code still fails to detect that MFW is disabled.
> 
> In addition, the IPMI driver attaches to "something" and I can poke at
> it via ipmitool.  So, from the driver perspective, the attempt to detect
> MFW enabled doesn't work as the chipset still thinks that its "on".
> 

My patch relied on existing bce(4)'s logic for management firmware
state since public data sheet does not mention anything about that.
Probably David can give us more information.

> I've commented out the code block that we're trying to work around in
> the yahoo code base for now.  
> 
> Sean
>