bce(4) with IPMI

[Arnaud Lacombe]

Hi,

On Fri, Oct 7, 2011 at 3:11 PM, YongHyeon PYUN <pyunyh at gmail.com> wrote:
> On Mon, Oct 03, 2011 at 04:06:18PM -0700, Sean Bruno wrote:
>> On Mon, 2011-10-03 at 15:30 -0700, David Christensen wrote:
>> > > > > I should probably say, this is freebsd7.  So I'll peruse the
>> > > changelogs
>> > > > > and see if 7 is missing something here.
>> > > > >
>> > > > > sean
>> > > >
>> > > > commenting this change out seems to be helping quite a bit with my
>> > > > issue.  I think that this behavior may be wrong in the IPMI shared/nic
>> > > > case.  Thoughts?
>> > > >
>> > > >
>> > > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210261&r2=210263
>> > >
>> >
>> > The main reason bce(4) needs to coordinate with NC-SI/IPMI
>> > firmware is to make sure only one software entity manipulates
>> > PHY registers.  When bce(4) is loaded it will have priority
>> > over firmware (e.g. autoneg, speed, and duplex settings will
>> > be set by the host).  If you don't bring up the interface in
>> > the host the firmware isn't authorized to do so, which sounds
>> > like your problem.
>> >
>> > Current bce(4) behavior notifies firmware that host driver
>> > is running when resetting the device in bce_attach().  We
>> > tell firmware that host driver is still running through
>> > bce_pulse().  Not sure how to handle the FreeBSD model where
>> > the driver load doesn't immediately bring the link up.
>> >
>> > Dave
>> >
>>
>> Hrm, understood.
>>
>> What are your thoughts on noting that the IPMI f/w is running and
>> leaving the interface up?  I'm poking around trying to find the right
>> register bits at initialization to see that this is the case.
>>
>
> How about disabling bce_pulse() for IPMI interface? I guess this
> may result in not sending heart beat from driver to firmware such
> that firmware may take over control back from driver.
> The problem of the approach would be we don't know whether IPMI is
> active in driver at attach time and we may need some way to take
> control back from firmware once admin changed his/her mind to use
> the controller as a normal interface.
>
>> What's even more strange is that our freebsd6 instances don't have this
>> problem.
>>
>
> Can't explain either but probably stable/6 bce(4) may have used old
> firmware.
>
I may look ignorant, but shouldn't the link between the BCM and the
MAC/PHY be totally independent from any OS involvement ? The BCM
should still be able to communicate with the outer world even if the
OS badly screw the NIC configuration, as long as the BCM is alive.

 - Arnaud