Hi,
This patch enables the DROP_EN flag to each RX queue if TX flow
control is disabled. It (mostly) mirrors what the ixgbe driver does.
This prevents a single full RX ring from stalling the rest of the RX rings.
How's it look? (indenting and such aside, thanks google.)
-a
Index: sys/dev/e10
Hi,
A bunch of us spent a whole bunch of time on the driver before and
after 10.0-REL happened to squish a number of ixgbe hanging and out of
order bugs.
Please update. :)
-a
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/li
On 08/09/2014 17:05, Ing. Aleš Nechvátal wrote:
I was experiencing similar behaviour on a machine acting as a gateway. It
has one X520-SR2, both SPF+ ports used to connet to another machines with
the same NICs. One of the NICs suddenly stopped to pass data through and the
the ifconfing down up cy
Let me remove my concerns earlier in the thread -- this patch won't
negatively affect any of our drivers; and the problem I mentioned with ixl
would require a change somewhere further up the stack.
---
- Eric Joyner
On Mon, Sep 8, 2014 at 5:05 AM, Rick Macklem wrote:
> Hans Petter Selasky wrote
Hi Folks,
On Thu, Aug 28, 2014 at 12:39:09PM -0400, George Neville-Neil wrote:
> Adrian,
>
> Can you put this into a Phabricator for review?
>
> Lars,
>
> How have you been testing this?
Did the newcwv patch make its way into Phabricator? I don't think I would have
seen if it did.
>
> On 27
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
I was experiencing similar behaviour on a machine acting as a gateway. It
has one X520-SR2, both SPF+ ports used to connet to another machines with
the same NICs. One of the NICs suddenly stopped to pass data through and the
the ifconfing down up cycle was needed to make it work again, that in bett
On Sep 5, 2014, at 9:15 PM, John Case wrote:
> For many years I would build FreeBSD firewalls and they would be very, very
> simple - I just set gateway_enable="yes" in rc.conf and everything just
> worked.
>
> However, these firewalls *always* had real, routable IPs no both sides. Both
> int
On 09/08/2014 15:19, Sean Bruno wrote:
> 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 s
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 new. The
afflicted machi
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 08/09/2014 15:38, Eric Joyner wrote:
Getting local / remote faults is strange; are these stats from after you
rebooted?
When the crash happens I just do:
# ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig up ixi1
After that the two interface ports return to work.
In no time
Getting local / remote faults is strange; are these stats from after you
rebooted?
---
- Eric Joyner
On Fri, Sep 5, 2014 at 8:39 PM, Marcelo Gondim
wrote:
> On 05/09/2014 17:17, Marcelo Gondim wrote:
>
>> On 05/09/2014 16:49, Adrian Chadd wrote:
>>
>>> Hi,
>>>
>>> But is the airflow in the unit
Hi Ryan,
Thanks for responding.
Just for the record, I removed my natd and ipdivert lines, so that
sshuttles divert rules were the only rules on the system ... I made my
system work without my own natd/divert by putting some static route
definitions into rc.conf.
Anyway, it still worked fi
Hi
Sorry for the late response, I'll be using an ARM processor for a 1G link.
My first issue came when doing what you suggested, and try the "emulated
netmap mode". I need to cross compile the code from my x86, which I think I
did correctly by setting up my arm toolchain and passing the kernel so
Hans Petter Selasky wrote:
> On 09/06/14 00:09, Rick Macklem wrote:
> > Hans Petter Selesky wrote:
> >> On 09/05/14 23:19, Eric Joyner wrote:
> >>> There are some concerns if we use this with devices that ixl
> >>> supports:
> >>>
> >>> - The maximum fragment size is 16KB-1, which isn't a power of
Hi,
You have a bug in the "Needs MFC" state which has not been touched in 7 or more
days. This email serves as a reminder that you may want to MFC this bug or
marked it as completed.
In the event you have a longer MFC timeout you may update this bug with a
comment and I won't remind you again
17 matches
Mail list logo
