Hi, On Fri, Oct 7, 2011 at 3:11 PM, YongHyeon PYUN <pyu...@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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
