On 10/3/22 04:14, Andriy Gapon wrote:
I must admit that the condition in question is fairly long and
non-trivial and I cannot decipher it, but these two lines look wrong to me:
(t->inp_flags2 & INP_REUSEPORT) ||
(t
On Fri, 2013-02-08 at 10:16 -0800, Jack Vogel wrote:
> For those that may have run across the story on Slashdot about this NIC,
> here is our statement:
>
> Recently there were a few stories published, based on a blog post by an
> end-user, suggesting specific network packets may cause the Intel®
http://markmail.org/message/brpfcifnf2742pff
So, these never happened. *sigh*
I think they should. Any objections?
Sean
signature.asc
Description: This is a digitally signed message part
A note from cluster...@freebsd.org
It looks like there is some amount of instability or bugginess in some
of the Broadcom firmware(management) on the bce(4) chipeset shipped on
later generations of the Poweredge 2950 from Dell:
bce0:
Specifically, we've seen that newer (9 and higher) have issu
> FreeBSD has too many knobs, but it would be nice if the bge defaults weren't
> so broken, so that they don't need overriding.
>
> Bruce
So many knobs ... well here's more. :-)
http://people.freebsd.org/~sbruno/bge_config_update.txt
At least this gets a man page update with references to ma
Version 0.2 of patches to bge(4). I'm not totally happy with it, but
comments welcome. I need better explanations of usage for the man page.
I've dropped bge_rxd completely here as it was suggested to not even
bother adjusting it.
http://people.freebsd.org/~sbruno/bge_config_update_1.txt
> I
Version 0.2 of patches to bge(4). I'm not totally happy with it, but
comments welcome. I need better explanations of usage for the man page.
I've dropped bge_rxd completely here as it was suggested to not even
bother adjusting it.
http://people.freebsd.org/~sbruno/bge_config_update_1.txt
> I
Running 9.2 in production load mail servers. We're hitting the
"watchdog" message and crashing with the stable/9 version. We're
reverting the change from 2 weeks ago and seeing if it still happens.
We didn't see this from stable/9 from about a month ago.
Sean
ref:
http://svnweb.freebsd.org/ba
On Wed, 2013-07-24 at 14:07 -0700, Sean Bruno wrote:
> Running 9.2 in production load mail servers. We're hitting the
> "watchdog" message and crashing with the stable/9 version. We're
> reverting the change from 2 weeks ago and seeing if it still happens.
> We di
On Wed, 2013-07-24 at 14:23 -0700, Sean Bruno wrote:
> On Wed, 2013-07-24 at 14:07 -0700, Sean Bruno wrote:
> > Running 9.2 in production load mail servers. We're hitting the
> > "watchdog" message and crashing with the stable/9 version. We're
> > reverti
> >
> > bce0: mem
> > 0xda00-0xdbff irq 36 at device 0.0 on pci1
> > miibus0: on bce0
> > brgphy0: PHY 1 on miibus0
> > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
> > bce0: Ethernet add
On Wed, 2013-07-24 at 14:07 -0700, Sean Bruno wrote:
> Running 9.2 in production load mail servers. We're hitting the
> "watchdog" message and crashing with the stable/9 version. We're
> reverting the change from 2 weeks ago and seeing if it still happens.
>
> http://svnweb.freebsd.org/base?view=revision&revision=236216
>
>
Ok, confirmed after ~50 reboots.
There is a timing problem in this revision that I don't fully
understand. Adding printf's inside bce_reset() will cause the existing
code to succeed, and sometimes the existing code in this r
On Thu, 2013-08-01 at 17:14 -0500, Joe Moog wrote:
> On Aug 1, 2013, at 4:27 PM, Joe Moog wrote:
>
> > On Aug 1, 2013, at 3:55 PM, Ryan Stone wrote:
> >
> >> Have you tried using only two ports, but both from the NIC? My suspicion
> >> would be that the problem is in the lagg's handling of mo
On Mon, 2014-03-31 at 20:42 +0200, mxb wrote:
> Hi list,
>
> hopefully this is the right place to have my question regarding CARP on
> 10-STABLE.
>
> I have two nodes with following setup(node1):
>
> lagg0: flags=8943 metric 0
> mtu 9000
>
> options=8407bb
> ether 00:25:90:e3:71:f
On Tue, 2014-05-20 at 23:52 -0700, Adrian Chadd wrote:
> Hi Robert,
>
> This patch uses CPU_FIRST() and CPU_NEXT() to iterate over the CPU IDs.
>
> Think this is alright?
>
> -a
>
>
> Index: sys/netinet/in_rss.c
> ===
> --- sys/ne
The Bytemark Site of freebsd.org is experiencing periodic stalls and
crashes on the machines being used as routers. I have heard of a
rumored patch that exists "somewhere" to resolve this, but when I asked
at BSDCan, I got no takers. Any thoughts?
FreeBSD igw0.bme.freebsd.org 11.0-CURRENT FreeB
On Fri, 2014-06-20 at 16:21 -0700, hiren panchasara wrote:
> Reviving an old thread where Steve found this problem: A call to
> getpeername on a connected tcp socket returns ENOTCONN with no prior
> errors being reported by previous socket calls.
>
> Please look at
> http://lists.freebsd.org/pipe
Looks like we're pushing the BCM5716 really hard. Is there any way to
give the net adapter a bit more space?
e.g.
dev.bce.0.com_no_buffers: 130228
Sean
hw.bce.msi_enable: 1
hw.bce.tso_enable: 1
dev.bce.0.%desc: Broadcom NetXtreme II BCM5716 1000Base-T (C0)
dev.bce.0.%driver: bce
dev.bce.0.%lo
On Thu, 2011-12-15 at 07:00 -0800, John Baldwin wrote:
> On Tuesday, December 13, 2011 2:00:14 pm Sean Bruno wrote:
> > Looks like we're pushing the BCM5716 really hard. Is there any way to
> > give the net adapter a bit more space?
> >
> > e.g.
> > dev.bce
Doing a lot of compiles recently and keep noting this noise in
sys/dev/ie:
/dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function
'ieget':
/dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:682: warning:
passing argument 1 of 'bcopy' discards qualifiers from pointer target
t
Trying some hackery today in my netboot environment with the Dell 12G
R620. I had to disable some bios calls in bios.c after reviewing an
email from Doug Ambrisko, and I see a pretty hard failure of bge(4) on
stable/7 with yahoo modifications on i386.
I've tried disabling msi via:
//depot/ya
> As you see ukphy(4) was attached to bge2 so it may cause various
> issues.
> Is bge2 ASF/IPMI enabled interface? It seems ASF handling in
> bge(4) causes more trouble on recent controllers. Unfortunately
> disabling ASF may also trigger other problems like NMI.
> I believe bge(4) should always
On Fri, 2012-02-24 at 10:06 -0800, YongHyeon PYUN wrote:
> On Thu, Feb 23, 2012 at 10:23:23AM -0800, Sean Bruno wrote:
> >
> > > As you see ukphy(4) was attached to bge2 so it may cause various
> > > issues.
> > > Is bge2 ASF/IPMI enabled interface? It seems
>
> Hmm, so I have yet to test this, but I found several bugs related to transmit
> in em(4) and igb(4) recently just reading the code. (Mostly unnecessary
> scheduling of tasks for transmit.) I've included your change of restarting
> TX when link becomes active. I've also updated it to fix r
Hey, I just found a bind bug ticket in my queue about bind. I noted
that on stable/6 stable/7 stable/9 & head the referenced code "fails".
It seems that this is a problem, but I have no idea if its a real
problem or not. Our devs think it is. Anyway, here is a code snippet
to show the failure i
On Thu, 2012-03-15 at 16:59 -0700, Sean Bruno wrote:
> Hey, I just found a bind bug ticket in my queue about bind. I noted
> that on stable/6 stable/7 stable/9 & head the referenced code "fails".
>
> It seems that this is a problem, but I have no idea if its a real
&
On Fri, 2012-02-24 at 10:06 -0800, YongHyeon PYUN wrote:
> On Thu, Feb 23, 2012 at 10:23:23AM -0800, Sean Bruno wrote:
> >
> > > As you see ukphy(4) was attached to bge2 so it may cause various
> > > issues.
> > > Is bge2 ASF/IPMI enabled interface? It seems
We're running a service with a 82576 configured with 4 queues and a
maxed rxd/txd configuration:
http://people.freebsd.org/~sbruno/igb_stats.txt
We still see, under higher load spikes, a tendency to drop packets (I
suspect an application issue at this point, but want to attempt to
alleviate some
On Wed, 2012-04-18 at 00:28 -0700, Luigi Rizzo wrote:
> On Tue, Apr 17, 2012 at 04:24:24PM -0700, Sean Bruno wrote:
> > We're running a service with a 82576 configured with 4 queues and a
> > maxed rxd/txd configuration:
> >
> > http://people.freebsd.org/~sbrun
sted.
>
> Let me know how it goes please :)
>
> Jack
>
>
> On Wed, Apr 18, 2012 at 9:27 AM, Sean Bruno
> wrote:
> On Wed, 2012-04-18 at 00:28 -0700, Luigi Rizzo wrote:
> > On Tue, Apr 17, 2012 at 04:24:24PM -0700, Sean Bruno wrote:
&
On Wed, 2012-04-18 at 09:49 -0700, Sean Bruno wrote:
> ok, good. that at least confirms that I correctly translated between
> the driver code and documented specification.
>
> I will try 8k as a test for now and see how that runs.
>
> sean
For now, I've patched on
On Thu, 2012-04-19 at 07:09 -0700, Jack Vogel wrote:
> OH, well that's interesting to know, thanks John.
>
> Jack
>
Front end box looks pretty happy today at 8k descriptors.
http://people.freebsd.org/~sbruno/igb_8k_stats.txt
Under peak, we're approaching 20MBytes/sec in and out of the
interfa
I noted a small nit in the comments of sys/dev/e1000/if_igb.h
Index: if_igb.h
===
--- if_igb.h(revision 234466)
+++ if_igb.h(working copy)
@@ -52,7 +52,7 @@
#define IGB_MAX_TXD4096
/*
- * IGB_RXD: Maximum numbe
http://people.freebsd.org/~sbruno/if_igb.c.txt
Scenario I've just seen:
8 core machine
2 igb(4) interfaces
set num_queues=4
igb0:0 --> cpu0
igb0:1 --> cpu1
igb0:2 --> cpu2
igb0:3 --> cpu3
igb1:0 --> cpu0
igb1:1 --> cpu1
igb1:2 --> cpu2
igb1:3 --> cpu3
I suspect, that we need a static global to
On Wed, 2012-04-25 at 06:32 -0700, John Baldwin wrote:
> CPU IDs are not guaranteed to be dense. However, you can use
> CPU_FIRST() and
> CPU_NEXT() with your static global instead.
>
Ah, does CPU_NEXT() reset to 0 when it reaches the end of its list of
CPUs?
> OTOH, if igb were to just leave
8 core box with 2 igb(4) interfaces serving internet traffic in/out over
here in Yahoo land.
This is configuring igb(4) allow 32k TXD/RXD descriptors(but only
configuring for 8k), 4 queues per interface and changing the logic of
the call to bus_bind_intr() such that it will iterate over all cpus
On Thu, 2012-04-26 at 11:13 -0700, Juli Mallett wrote:
> Queue splitting in Intel cards is done using a hash of protocol
> headers, so this is expected behavior. This also helps with TCP and
> UDP performance, in terms of keeping packets for the same protocol
> control block on the same core, but
On Wed, 2012-04-25 at 12:30 -0700, Sean Bruno wrote:
> On Wed, 2012-04-25 at 06:32 -0700, John Baldwin wrote:
> > CPU IDs are not guaranteed to be dense. However, you can use
> > CPU_FIRST() and
> > CPU_NEXT() with your static global instead.
> >
> Ah, does
On Thu, 2012-05-03 at 15:33 -0700, Sean Bruno wrote:
>
> On Wed, 2012-04-25 at 12:30 -0700, Sean Bruno wrote:
> > On Wed, 2012-04-25 at 06:32 -0700, John Baldwin wrote:
> > > CPU IDs are not guaranteed to be dense. However, you can use
> > > CPU_FIRST() and
>
On Tue, 2012-05-08 at 21:36 -0700, Sean Bruno wrote:
> On Thu, 2012-05-03 at 15:33 -0700, Sean Bruno wrote:
> >
> > On Wed, 2012-04-25 at 12:30 -0700, Sean Bruno wrote:
> > > On Wed, 2012-04-25 at 06:32 -0700, John Baldwin wrote:
> > > > CPU IDs are not guara
Trying to use two interfaces connected to the same network with the same
default router. The two interfaces have two different IPs on the
same /28 and point at the same default router of .1. I have
successfully configured the machine such that data is coming *in* on
both interfaces, but the outpu
On Tue, 2012-05-15 at 12:02 -0700, Li, Qing wrote:
> The route selection is based on a hash function of source-ip and
> destination-ip when
> RADIX_MPATH is enabled. You do not need to perform specific actions, other
> than perhaps
> setting varying weights on each entry as an option. So depen
On Tue, 2012-05-15 at 12:55 -0700, Sean Bruno wrote:
>
> On Tue, 2012-05-15 at 12:02 -0700, Li, Qing wrote:
> > The route selection is based on a hash function of source-ip and
> > destination-ip when
> > RADIX_MPATH is enabled. You do not need to perform specific
On Tue, 2012-05-15 at 16:14 -0700, David DeSimone wrote:
> suggests that there is only ONE default route, pointing to ONE
> interface, igb0. Without an extra default route that is also pointing
> to igb1, I can't see how the system woudl ever forward traffic out
> igb1,
> unless it was directed to
On Thu, 2012-05-17 at 01:27 -0700, Eugene M. Zheganin wrote:
> The problem is that this topic lacks the documentation like totally.
> From the commit comments I understand that with RADIX_MPATH I can
> use
> more than one route towards the destination, but I really cannot find
> anywhere the ans
On Thu, 2012-05-17 at 10:56 -0700, Li, Qing wrote:
> It is not working properly in one case, of load balancing among
> physical
> interfaces having a single prefix, all are attached to the same
> physical
> link, and reaching a single first-hop router.
>
>
Ah, I see. thank you for the clarifi
> > What am I missing here?
> >
>
> Did you try to use ipfw instead of RADIX_MPATH?
>
> Try something like this:
>
> route add default $router -interface $if1
> ipfw add $number fwd $router ip from $ip2 to any out via $if2
>
I think I've configued lagg(4) into doing what I really want, which
On Tue, 2012-05-29 at 03:20 -0700, Dag-Erling Smørgrav wrote:
> Given the choice between the following adapters:
>
Here's my list of "stuff and things", I hope this is helpful
> Broadcom 5720
Haven't gotten this one working on the Dell R series I'm testing
(thought this was a 1G chipset)
>
Was trolling around inside of bce(4) and the Broadcom docs today and
made the following update to the man page. Thoughts?
Sean
http://people.freebsd.org/~sbruno/bce_man.txt
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/list
On Thu, 2012-05-31 at 05:46 -0700, Warren Block wrote:
> On Wed, 30 May 2012, Sean Bruno wrote:
>
> > Was trolling around inside of bce(4) and the Broadcom docs today and
> > made the following update to the man page. Thoughts?
> >
> > Sean
> >
> > htt
On Thu, 2012-05-31 at 10:15 -0700, Sean Bruno wrote:
> On Thu, 2012-05-31 at 05:46 -0700, Warren Block wrote:
> > On Wed, 30 May 2012, Sean Bruno wrote:
> >
> > > Was trolling around inside of bce(4) and the Broadcom docs today and
> > > made the following
On Thu, 2012-05-31 at 12:49 -0700, Warren Block wrote:
> One other idea that's a little shorter on multiple values:
>
> "this value can only be of the set 1, 2, 4 or 8 (default 2)."
>
> --> "this value can only be of the set 1, 2 (default), 4 or 8."
Hrm, I don't really like the look of that in
On Thu, 2012-06-07 at 23:54 -0700, Daniel Braniss wrote:
> Hi
> I will be 'experimenting' with 10g in the next few months, so
> I need to buy some cards,
> After googling for some time, I noticed that there is not realy much real
> info, and some of it is a bit dated.
> Since these cards are pric
Just noted this happened today, running stable/9 ish from august 10th.
It looks like I got a good and valid crashdump off of this if anyone is
interested.
igb0: port
0xe880-0xe89f mem
0xfbe6-0xfbe7,0xfbe4-0xfbe5,0xfbeb8000-0xfbebbfff irq 32
at device 0.0 on pci5
igb0: Using MSIX
Since I saw other panics on our stable/9 I started poking around and found this
one lying around too.
And, I have a crashdump here as well. Not sure about reproduction, but I see
it happened on two seperate servers
over the course of the day. Here is one of them.
igb0: port 0xe880-0xe89f
me
On Thu, 2012-08-16 at 09:56 -0700, John wrote:
> Hi Folks,
>
>I have an R820 I'm testing. The system seems to boot up fine, but
> no network adapters show up. From pciconf -l :
>
> none4@pci0:1:0:0: class=0x02 card=0x1f5c1028 chip=0x168a14e4
> rev=0x10 hdr=0x00
> none5@pci0:1:0:1:
The following reply was made to PR kern/171524; it has been noted by GNATS.
From: Sean Bruno
To: bug-follo...@freebsd.org, dhoj...@brainbits.net
Cc:
Subject: Re: kern/171524: [ipmi] ipmi driver crashes kernel by reboot or
shutdown
Date: Tue, 11 Sep 2012 12:56:16 -0700
It looks like the fix
> > igb+lagg worked for us on 8.3. Haven't tried it since moving to 9.0
> > and 9-STABLE on those three boxes.
> >
> > igb+lagg doesn't work for him on 9.0. Although, I don't recall if
> > non-LACP options were tried earlier in this thread, or if it's just
> > the LACP mode that's failing. If o
On Fri, 2013-01-18 at 18:10 +0530, Venkat Duvvuru wrote:
> Hi,
> I have to submit some patches for Emulex's "oce" driver. Could you please
> let me know if http://www.freebsd.org/send-pr.html is the correct way of
> submitting them?
>
> /Venkat
Yes please. That would be the first place so that
We moved an application stack from BSD4(BOO!) to BSD7(YAY!) recently and
got a great performance increase, so first: GOOD JOB.
Periodically, we are seeing strings of duplicate ACK being sent in
<100uSec deltas. I can't imagine that this should be happening, but
there it is. I've sanitized an ex
Looks like the higher end HP Proliant servers are coming with 10GE
adapters.
When I was at MeetBSD I ran into an engineer that was working on this
driver and I failed to document his contact information.
If anyone has that contact, I'd really appreciate it.
Sean
__
On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote:
> It looks like I'm unfortunate enough to have to deploy on a machine
> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
> apparently has hardware issues, according to this thread:
>
> http://sourceforge.net/tracker/ind
We're seeing igb(4) hit the OACTIVE handling parts of igb_start_locked()
on 7 with hw.igb.rxd/txd set to 4096 periodically and seeing the
machines fall off the network soon after. The logic to handle the unset
of OACTIVE in igb_txeof() doesn't ever seem to fire and the machine is
only accessible o
On Mon, 2011-01-03 at 13:02 -0800, Robin Sommer wrote:
> Hello all,
>
> quite a while ago I asked about the problem below. Unfortunately, I
> haven't found a solution yet and I'm actually still seeing these
> timeouts after just upgrading to 8.2-RC1. Any further ideas on what
> could be triggering
On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote:
> On 1/23/2011 10:21 AM, Mike Tancsa wrote:
> > On 1/21/2011 4:21 AM, Jan Koum wrote:
> > One other thing I noticed is that when the nic is in its hung state, the
> > WOL option is gone ?
> >
> > e.g
> >
> > em1: flags=8843 metric 0 mtu 1500
>
On Tue, 2011-02-01 at 12:05 -0800, Jack Vogel wrote:
> At this point I'm open to any ideas, this sounds like a good one Sean,
> thanks.
> Mike, you want to test this ?
>
> Jack
>
>
> On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno
> wrote:
>
>
On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
> To those who are going to test, here is the if_em.c, based on head,
> with my
> changes, I have to leave for the afternoon, and have not had a chance
> to build
> this, but it should work. I will check back in the later evening.
>
> Any blatan
On Tue, 2011-02-01 at 13:51 -0800, Mike Tancsa wrote:
> On 2/1/2011 4:43 PM, Jack Vogel wrote:
> > To those who are going to test, here is the if_em.c, based on head, with my
> > changes, I have to leave for the afternoon, and have not had a chance to
> > build
> > this, but it should work. I will
On Tue, 2011-02-01 at 12:50 -0800, Mike Carlson wrote:
> Hey net@,
>
> I have a FreeBSD 8.2-RC2 system running on a HP DL180 G6, using the
> onboard Intel controller, and it is our primary Bacula storage node and
> director node.
>
> We have 96 clients that are scheduled to run at 8:30pm. After
t;
> > On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote:
> >
> >> On 2/1/2011 5:03 PM, Sean Bruno wrote:
> >>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
> >>>> To those who are going to test, here is the if_em.c, based on head,
> >>>&g
meh, patience is not one of my character traits. :-)
Sean
On Fri, 2011-02-04 at 10:12 -0800, Jack Vogel wrote:
> Was curious too, but being more patient than you :)
>
> Jack
>
>
> On Fri, Feb 4, 2011 at 10:09 AM, Sean Bruno
> wrote:
> Any more data on this
So, I note that the tuneable bge_allow_asf is set to 0. This
effectively disabled IPMI for a few controllers that I have. Is there
any reason to *not* turn it on?
Sean
if_bge.c::
static int bge_allow_asf = 0;
TUNABLE_INT("hw.bge.allow_asf", &bge_allow_asf);
bge0@pci0:1:0:0:class=0x0
Not sure what's going on here, but I've installed an updated 7-stable on
a VM in my Fedora kvm enabled laptop and I see that /dev/ed0 is having
issues when doing network operations. I could have sworn that we
resolved this, but can't remember what what the fix was (probably I
switched to a fake /d
On Mon, 2011-08-15 at 06:53 -0700, Darren Baginski wrote:
> Hi!
>
> Could please some tell me if bug
> http://lists.freebsd.org/pipermail/freebsd-net/2011-February/027895.html
> was fixed in any release?
> If not is there any workaround?
> I'm still facing with it 8.2-RELEASE.
> Sorry if that que
On Wed, 2011-09-07 at 16:19 -0700, Arnaud Lacombe wrote:
> Hi,
>
> On Mon, Sep 5, 2011 at 2:59 AM, Arnaud Lacombe wrote:
> > Hi folks,
> >
> > We have been trying to track down a bad mbuf management for about two
> > weeks on a customized 7.1 base. I have finally been able to reproduce
> > it wit
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 inte
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
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)
> respectivel
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
>
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
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 I
Didn't realize this until my ride to work today, but Broadcom has their
programming spec/docs up on a public page. Just thought folks would
like to know.
http://www.broadcom.com/support/ethernet_nic/open_source.php
Sean
___
freebsd-net@freebsd.org mai
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 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)
> respectivel
>
> 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 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
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
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
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, 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
> > > 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, 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
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 "
https://reviews.freebsd.org/D506
This patch implements an attempt to adjust the MTU/MSS of a connection
to work around poor networks that block ICMP fragmentation needed
indications.
sean
p.s. I intend on working on a full PLPMTU implementation after working
this into the tree.
This sort of looks like the hardware failed to respond to us in time?
Too busy?
sean
panic: spin lock held too long
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or dist
On Mon, 2014-09-08 at 12:09 -0700, Sean Bruno wrote:
> This sort of looks like the hardware failed to respond to us in time?
> Too busy?
>
> sean
>
This seems to be affecting my 10/stable machines from 15Aug2014.
Not a lot of churn in the code so I don't think this is
On Mon, 2014-09-08 at 15:34 -0400, Eric van Gyzen wrote:
> >> Unread portion of the kernel message buffer:
> >> spin lock 0x812a0400 (callout) held by 0xf800151fe000
> (tid
> >> 13) too long
>
> TID 13 is usually a kernel idle thread, which would seem to
> indicate
> a dangling
On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote:
> Hi,
>
> We recently released a new tech report "Design Overview of Multipath TCP
> version 0.4 for FreeBSD-11" [1]. The report provides some details on
> various aspects of the implementation (session management, data-level
> retransmis
On Wed, 2014-09-17 at 12:58 +1000, Nigel Williams wrote:
> On 17/09/14 08:48, Sean Bruno wrote:
> > On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote:
> >> Hi,
> >>
> >> We recently released a new tech report "Design Overview of
> Multipath T
1 - 100 of 191 matches
Mail list logo
