On Tuesday, October 11, 2011 3:52:25 pm Sean Bruno wrote:
> In addition, the IPMI driver attaches to "something" and I can poke at
> it via ipmitool. So, from the driver perspective, the attempt to detect
> MFW enabled doesn't work as the chipset still thinks that its "on".
The ipmi driver attach
On Thu, 2011-10-13 at 13:58 -0700, David Christensen wrote:
> > Ran this on my Dell R410. I can clearly see that the tool is
> > "disabling" the MFW bit, and that the dell bios interface to the IPMI
> > controller/DRAC is impaired, however ...
> >
> > The system still thinks that the MFW bit is "
> Ran this on my Dell R410. I can clearly see that the tool is
> "disabling" the MFW bit, and that the dell bios interface to the IPMI
> controller/DRAC is impaired, however ...
>
> The system still thinks that the MFW bit is "ON" and proceeds normally
> in this case. The code still fails to det
On Tue, 2011-10-11 at 15:49 -0700, YongHyeon PYUN wrote:
> On Tue, Oct 11, 2011 at 12:52:25PM -0700, Sean Bruno wrote:
> >
> > > > > The Broadcom MFW is configured to load/not load through an NVRAM
> > > > > option that is likely not affected by the iDRAC BIOS settings.
> > > > > To disable MFW y
On Tue, Oct 11, 2011 at 12:52:25PM -0700, Sean Bruno wrote:
>
> > > > The Broadcom MFW is configured to load/not load through an NVRAM
> > > > option that is likely not affected by the iDRAC BIOS settings.
> > > > To disable MFW you'd need to run the user diagnostic utility
> > > > (UXDIAG.EXE) w
> > > The Broadcom MFW is configured to load/not load through an NVRAM
> > > option that is likely not affected by the iDRAC BIOS settings.
> > > To disable MFW you'd need to run the user diagnostic utility
> > > (UXDIAG.EXE) with the following command line:
> > >
> > > C:\>uxdiag -mfw 0
> > >
On Tue, Oct 11, 2011 at 11:00:30AM -0700, Sean Bruno wrote:
> On Mon, 2011-10-10 at 17:46 -0700, David Christensen wrote:
> > > > I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I
> > > couldn't
> > > > see any driver detection of this status. So, when I add this:
> > > >
> > > > >
On Mon, 2011-10-10 at 17:46 -0700, David Christensen wrote:
> > > I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I
> > couldn't
> > > see any driver detection of this status. So, when I add this:
> > >
> > > > if ((ifp->if_flags & IFF_UP) == 0 &&
> > > >(sc->bce_fl
> > I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I
> couldn't
> > see any driver detection of this status. So, when I add this:
> >
> > > if ((ifp->if_flags & IFF_UP) == 0 &&
> > >(sc->bce_flags & BCE_MFW_PRESENT_FLAG) == 0){
> > > printf("%s: BCE d
On Mon, Oct 10, 2011 at 01:35:05PM -0700, Sean Bruno wrote:
> On Mon, 2011-10-10 at 12:06 -0700, YongHyeon PYUN wrote:
> > Did you capture this message generated after disabling IPMI/DRAC in
> > BIOS? I thought you had to use Broadcom's separate program to
> > disable management firmware.
> >
> >
On Mon, 2011-10-10 at 12:06 -0700, YongHyeon PYUN wrote:
> Did you capture this message generated after disabling IPMI/DRAC in
> BIOS? I thought you had to use Broadcom's separate program to
> disable management firmware.
>
> Does the last patch solve the problem?
> It's still not clear to me. The
On Mon, Oct 10, 2011 at 11:24:06AM -0700, Sean Bruno wrote:
> On Mon, 2011-10-10 at 10:47 -0700, YongHyeon PYUN wrote:
> > On Mon, Oct 10, 2011 at 09:42:22AM -0700, Sean Bruno wrote:
> > > On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote:
> > > >
> > > > Could you try attached patch?
> > >
On Mon, 2011-10-10 at 10:47 -0700, YongHyeon PYUN wrote:
> On Mon, Oct 10, 2011 at 09:42:22AM -0700, Sean Bruno wrote:
> > On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote:
> > >
> > > Could you try attached patch?
> >
> > Yeah, this does work on the r410 ... however, I can't test the
> >
On Mon, Oct 10, 2011 at 09:42:22AM -0700, Sean Bruno wrote:
> On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote:
> >
> > Could you try attached patch?
>
> Yeah, this does work on the r410 ... however, I can't test the
> "negative" case here where the bce(4) driver runs across a chipset whe
On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote:
>
> Could you try attached patch?
Yeah, this does work on the r410 ... however, I can't test the
"negative" case here where the bce(4) driver runs across a chipset where
sc->bce_flags & BCE_MFW_ENABLE_FLAG == 0
I tried disabling the Dell
> Thanks for testing.
> Committed with r226123.
> I also noticed that bce(4) may support BCM5716S because brgphy(4)
> already supports BCM5709S. Can you test attached patch on BCM5716S?
I don't have a 5716S system or NIC for testing.
Dave
___
freebsd-n
On Fri, Oct 07, 2011 at 04:25:56PM -0700, David Christensen wrote:
> > > That's a typo then, 5709 and 5716 share the same ASIC ID.
> > >
> >
> > Thanks for confirmation.
> > Could you review the attached patch?
>
> Looks good. ASIC ID matches my Dell R210 system:
>
> bce0: mem
> 0xda00-0x
> > That's a typo then, 5709 and 5716 share the same ASIC ID.
> >
>
> Thanks for confirmation.
> Could you review the attached patch?
Looks good. ASIC ID matches my Dell R210 system:
bce0: mem 0xda00-0xdbff
irq 16 at device 0.0 on pci2
miibus0: on bce0
bce0: Ethernet address: b8:ac:6
> Because driver already initialized CPUs and context I thought
> moving bce_pulse() to bce_init() was too late. If that's doable it
> would be more correct way to address this issue.
>
Moving bce_pulse() is a minimum. It might be necessary to move
some other code out of bce_attach()/bce_detach(
On Fri, Oct 07, 2011 at 02:23:10PM -0700, David Christensen wrote:
> > > so, I cracked open my R410 this morning to see what the Ethernet
> > chipset
> > > had for a indentification mark. It is definitely stamped as a
> > BCM5716,
> > > so I'm confused.
> > >
> > > bce(4) has code to handle the 57
On Fri, Oct 07, 2011 at 02:17:06PM -0700, David Christensen wrote:
> > > Can't explain either but probably stable/6 bce(4) may have used old
> > > firmware.
> >
> > Ok, I can once again reach the IPMI controller if I remove this:
> >
> > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1
> Whoa ... ok, so now I've run into something horrible.
>
> According to dmidecode, a Dell R410 has a Broadcom 5716 chipset on it.
> On Board Device 2 Information
> Type: Ethernet
> Status: Enabled
> Description: Embedded Broadcom 5716 NIC 1
> On Board Device 3 Information
> > Can't explain either but probably stable/6 bce(4) may have used old
> > firmware.
>
> Ok, I can once again reach the IPMI controller if I remove this:
>
> http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210263&r2=21
> 0262&pathrev=210263
>
> Since the driver has control over the
> > so, I cracked open my R410 this morning to see what the Ethernet
> chipset
> > had for a indentification mark. It is definitely stamped as a
> BCM5716,
> > so I'm confused.
> >
> > bce(4) has code to handle the 5716 chipset, but its never being
> executed
> > AFAIK. What's going on here?
> >
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 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
On Fri, Oct 07, 2011 at 01:11:50PM -0700, Sean Bruno wrote:
> On Fri, 2011-10-07 at 12:11 -0700, YongHyeon PYUN wrote:
> > > 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 o
On Fri, 2011-10-07 at 12:11 -0700, YongHyeon PYUN wrote:
> > 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.
Ok, I can once again reach the IPMI controller if I remov
Hi,
On Fri, Oct 7, 2011 at 3:11 PM, YongHyeon PYUN 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
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
> > > >
> > >
On Fri, Oct 07, 2011 at 09:23:30AM -0700, Sean Bruno wrote:
>
> >
> > bce0@pci0:1:0:0:class=0x02 card=0x028c1028 chip=0x163b14e4
> > rev=0x20 hdr=0x00
> > vendor = 'Broadcom Corporation'
> > class = network
> > subclass = ethernet
> > bce1@pci0:1:0:1:cla
>
> bce0@pci0:1:0:0:class=0x02 card=0x028c1028 chip=0x163b14e4
> rev=0x20 hdr=0x00
> vendor = 'Broadcom Corporation'
> class = network
> subclass = ethernet
> bce1@pci0:1:0:1:class=0x02 card=0x028c1028 chip=0x163b14e4
> rev=0x20 hdr=0x00
> vendor
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 a
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
> > > i
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
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 pro
On Thu, 2011-09-29 at 16:48 -0700, Matthew Franz wrote:
> I have a pair of brand new R410's I've been using for CARP+PFSYNC
> pair. I believe the LOM was disabled by default and have not tried to
> use it, IIRC. Been using bce0 as the outside interface with no issues
> and bce1 as the sync
>
I have a pair of brand new R410's I've been using for CARP+PFSYNC
pair. I believe the LOM was disabled by default and have not tried to
use it, IIRC. Been using bce0 as the outside interface with no issues
and bce1 as the sync
I'm running FreeBSD 8.2 though. I can get more details about the
ha
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 a
On Thu, 2011-09-29 at 11:27 -0700, Miroslav Lachman wrote:
> 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)
> > r
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 foun
40 matches
Mail list logo
