https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #18 from Michael Tuexen tue...@freebsd.org ---
(In reply to Craig Rodrigues from comment #17)
Ahh. Thanks for the hint. Will do.
Best regards
Michael
--
You are receiving this mail because:
You are on the CC list for the bug.
On 06/17/15 at 03:10P, Jean-Francois HREN wrote:
Hello, while investigating a freeze on a modified FreeBSD 9.3 I stumbled upon
a potential bug in netinet/tcp_output.c
If an error occurs while processing a TCP segment with some data and the FIN
flag,
the back out of the sequence number
On Wed, Jun 17, 2015 at 7:00 AM, Lakshmi Narasimhan Sundararajan
lakshm...@msystechnologies.com wrote:
[lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$ diff -c5pt ixl_txrx.c
ixl_txrx.c.mod
*** ixl_txrx.c Fri Jun 12 06:56:51 2015
--- ixl_txrx.c.mod Fri Jun 12 06:56:33 2015
***
Notice to Appear,
This is to inform you to appear in the Court on the June 22 for your case
hearing.
You are kindly asked to prepare and bring the documents relating to the case to
Court on the specified date.
Note: The case will be heard by the judge in your absence if you do not come.
You
As Ryan said, its there to keep queues marked as hung from
getting more work scheduled on them. I really don't know what
to make of it if commenting it out is somehow improving things :)
I would suggest more careful analysis of what is going wrong
before committing anything like deleting this.
hselasky added a comment.
lawrence: It is someone well known to be using FreeBSD. This patch makes such a
big difference when applied to +10Gbit/s connections that we can run 2 TCP
streams totalling 37.5 GBit/s on a single 2.x GHz CPU core instead of only one.
REPOSITORY
rS FreeBSD src
lstewart added a comment.
Ok, but that's anecdotal and gives us reviewers nothing to go on - without any
methodology or raw data who knows whether the LRO change is solely responsible
for the improvement and if it introduced any undesired side effects. It's also
possible that with tuning, the
lstewart added a comment.
I hope I didn't delete it... from what I could see online, the Abandon
Phabricator action is the means by which a reviewer indicates they have
permanently rejected the patch (as opposed to suggesting changes).
As to people using the patch, can you say who and why?
hselasky added a comment.
lstewart: OK, just don't delete this patch, because some people are using it.
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D1761
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: hselasky,
lstewart abandoned this revision.
lstewart added a comment.
Hans,
Just because some hardware is capable of coalescing more than 64k of data
doesn't mean we should feel obligated to support the functionality. I'd be
curious to understand the anticipated use cases that led to hardware support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #16 from Michael Tuexen tue...@freebsd.org ---
(In reply to Alan Somers from comment #15)
Yes, you can failover from one ISP to another. Currently this is done by having
corresponding entries in a single routing table for the
Hi,
I’ve got problems with HP NC550SFP NIC
(http://www.emulex.com/products/ethernet-networking-storage-connectivity/ethernet-networking-adapters/hp-branded/nc550sfp/overview/
)
Setup information:
I’m intended to use this system for traffic monitoring:
switchport configured for traffic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200323
--- Comment #14 from commit-h...@freebsd.org ---
A commit references this bug:
Author: eri
Date: Wed Jun 17 12:23:05 UTC 2015
New revision: 284512
URL: https://svnweb.freebsd.org/changeset/base/284512
Log:
If there is a system with a
Hi FreeBSD folks,
I am part of Panasas and working on evaluating IXL over FreeBSD
[11-CURRENT] on Intel Taylor Pass platform for our next product.
In that regard, while evaluating performance, we found the Tx performance
to be very poor. We found it to be so because the tx interrupts are spread
On Jun 17, 2015, at 11:48 AM, Sergey Akhmatov wrote:
Hi,
I’ve got problems with HP NC550SFP NIC
(http://www.emulex.com/products/ethernet-networking-storage-connectivity/ethernet-networking-adapters/hp-branded/nc550sfp/overview/
)
Beware
The driver was unusable until fixes were applied
I've tried 10.1-RELEASE, then 10-STABLE and finaly 11-CURRENT with the
same result.
Beware
The driver was unusable until fixes were applied on 21st December.
http://svnweb.freebsd.org/base/stable/10/sys/dev/oce/?view=log
Better use a recent 10-STABLE if possible.
Hello, while investigating a freeze on a modified FreeBSD 9.3 I stumbled upon
a potential bug in netinet/tcp_output.c
If an error occurs while processing a TCP segment with some data and the FIN
flag,
the back out of the sequence number advance does not take into account
the increase by 1 due to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #14 from Michael Tuexen tue...@freebsd.org ---
(In reply to Alan Somers from comment #13)
I think interfaces can assign fibs to packets, it is a field in the mbuf packet
header. It makes sense to use this information in case you
On Jun 17, 2015, at 2:58 PM, Sergey Akhmatov wrote:
I've tried 10.1-RELEASE, then 10-STABLE and finaly 11-CURRENT with the same
result.
Sorry, in that case I don't know what it might be.
Have you tried disabling adapter intelligence? rxcsum, txcsum, lro, etc?
Borja.
Tried disabling all offloadings available, doesn't help.
Sorry, in that case I don't know what it might be.
Have you tried disabling adapter intelligence? rxcsum, txcsum, lro, etc?
___
freebsd-net@freebsd.org mailing list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #15 from Alan Somers asom...@freebsd.org ---
(In reply to Michael Tuexen from comment #14)
You're right about the interface FIB. It will take incoming packets with a
certain FIB. But it's not completely general; it's possible
It sounds like a promisc bug in the driver, just as you say, but just to
test it some more:
I see that you are running both in PPROMISC and PROMISC.
What happen if you remove the PPROMISC and only let tcpdump set it's own
PROMISC?
Running in monitor mode is the correct way to sniff
22 matches
Mail list logo
