Date: Fri, 7 Oct 2011 13:55:10 -0700 From: YongHyeon PYUN <pyunyh@gmail.com> To: Arnaud Lacombe <lacombar@gmail.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, David Christensen <davidch@broadcom.com>, Pyun YongHyeon <yongari@freebsd.org>, Sean Bruno <seanbru@yahoo-inc.com>, "davidch@freebsd.org" <davidch@freebsd.org> Subject: Re: bce(4) with IPMI Message-ID: <20111007205510.GD11808@michelle.cdnetworks.com> In-Reply-To: <CACqU3MUS1pKByD7_vhcoCe85bSnUhWESerQLeqq=HTRBb0p0Sg@mail.gmail.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <CACqU3MUS1pKByD7_vhcoCe85bSnUhWESerQLeqq=HTRBb0p0Sg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111007205510.GD11808>