bce(4) with IPMI

[YongHyeon PYUN]

On Fri, Oct 07, 2011 at 04:09:34PM -0400, Arnaud Lacombe wrote:
> 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.
> 

Correct. I just wanted to know the effect of bce_pulse() because I
don't have bce(4) controllers with management firmware.

>  - Arnaud
>