Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Sep 2011 18:39:08 -0700
From:      Sean Bruno <seanbru@yahoo-inc.com>
To:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Cc:        "davidch@freebsd.org" <davidch@freebsd.org>, Pyun YongHyeon <yongari@freebsd.org>
Subject:   Re: bce(4) with IPMI
Message-ID:  <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com>
In-Reply-To: <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2011-09-29 at 17:53 -0700, Sean Bruno wrote:
> On Thu, 2011-09-29 at 12:10 -0700, Sean Bruno wrote:
> > On Thu, 2011-09-29 at 10:01 -0700, Sean Bruno wrote:
> > > We've been getting reports of odd behavior on our Dell R410 machines
> > > when trying to use IPMI.  The servers have two NIC's that we have
> > > assigned as the IPMI interface(bce0) and production interface(bce1)
> > > respectively.
> > > 
> > > Since we don't actually configure bce0 in FreeBSD, we've found that the
> > > IPMI interface deactivated when bce(4) loads.  I assume that the driver
> > > is not initializing the interface correctly in this case and the default
> > > case is to turn the interface off.  Does it make sense to completely
> > > turn off the interface when there is an active link on the port, but no
> > > configuration assigned?
> > > 
> > > Sean
> > > 
> > > p.s. Dell's IPMI implementation is ... um ... more difficult than it
> > > needs to be.
> > > 
> > 
> > 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

Just a bit more here.  

bce0: <Broadcom NetXtreme II BCM5716 1000Base-T (C0)> mem
0xda000000-0xdbffffff irq 36 at device 0.0 on pci1
bce0: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xda000000
bce0: attempting to allocate 1 MSI vectors (16 supported)
msi: routing MSI IRQ 256 to vector 49
bce0: using IRQ 256 for MSI
miibus0: <MII bus> on bce0
brgphy0: <BCM5709C 10/100/1000baseTX PHY> PHY 1 on miibus0
brgphy0: OUI 0x0050ef, model 0x003c, rev. 8
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bce0: bpf attached
bce0: Ethernet address: 78:2b:cb:38:f1:cf
bce0: [MPSAFE]
bce0: [ITHREAD]
bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.3);
Flags (MSI|MFW); MFW (NCSI 2.0.11)
bce1: <Broadcom NetXtreme II BCM5716 1000Base-T (C0)> mem
0xdc000000-0xddffffff irq 48 at device 0.1 on pci1
bce1: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xdc000000
bce1: attempting to allocate 1 MSI vectors (16 supported)
msi: routing MSI IRQ 257 to vector 50
bce1: using IRQ 257 for MSI
miibus1: <MII bus> on bce1
brgphy1: <BCM5709C 10/100/1000baseTX PHY> PHY 1 on miibus1
brgphy1: OUI 0x0050ef, model 0x003c, rev. 8
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bce1: bpf attached
bce1: Ethernet address: 78:2b:cb:38:f1:d0
bce1: [MPSAFE]
bce1: [ITHREAD]
bce1: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.3);
Flags (MSI|MFW); MFW (NCSI 2.0.11)





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1317346748.2777.36.camel>