Synopsis: [patch] [net] Removing an unavailable sysctl from manpage
State-Changed-From-To: open->patched
State-Changed-By: ae
State-Changed-When: Mon Apr 8 10:15:00 UTC 2013
State-Changed-Why:
Committed to the head/. Thanks!
Responsible-Changed-From-To: freebsd-net->ae
Responsible-Changed-By: a
Synopsis: [tcp] [patch] An error of calculating TCP sequence number will
resault in the machine to restart
State-Changed-From-To: open->analyzed
State-Changed-By: glebius
State-Changed-When: Mon Apr 8 11:01:18 UTC 2013
State-Changed-Why:
Grab the PR. I've reproduced it.
Responsible-Changed-Fro
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
Hi,
On Sun, 7 Apr 2013, Lev Serebryakov wrote:
LS>(1) I have a lot of "could not encode error response" in
LS>/var/log/messages after change of hardware. It looks like, every
LS>request from mrtg for "unexistent" interface leads to this message.
LS>I'll reconfigure mrtg, of course, but it is ann
Hello, Harti.
You wrote 8 апреля 2013 г., 15:40:07:
LS>>(1) I have a lot of "could not encode error response" in
LS>>/var/log/messages after change of hardware. It looks like, every
LS>>request from mrtg for "unexistent" interface leads to this message.
LS>>I'll reconfigure mrtg, of course, but i
Hi,
The patch in question can be found at
http://people.freebsd.org/~syrinx/snmp/libbsnmp-20121029-01.diff , I am
also attaching it to this e-mail. I didn't commit it yet, since I did not
manage to get it properly reviewed or get confirmation from Harti that it
solved his problem. Error responses
On 05.04.2013 13:09, Matt Miller wrote:
Hey Rick,
I believe Juan and I have root caused this crash recently. The t_state =
0x1, TCPS_LISTEN, in the link provided at the time of the assertion.
In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set on the
socket and we should never
Sephe,
On Sat, Apr 06, 2013 at 06:04:25PM +0800, Sepherosa Ziehau wrote:
S> Hope the following analysis helps; IMHO, the reporter probably had hit
S> the same bug:
S>
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/1ff9b7d322dc5a26f7173aa8c38ecb79da80e419
Thanks for hint! The commit me
Hi,
In the transmit path, if enqueue mechanism is used instead of blocking on the
lock, the throughput is not good in some scenarios (especially single queue,
multiple connections).
For example:
if (TRY_LOCK(&wq->tx_lock)) {
status = oce_multiq_transmit(ifp, m, wq);
UNLOCK(&
On 8 April 2013 10:14, Duvvuru,Venkat Kumar
wrote:
> Hi,
> In the transmit path, if enqueue mechanism is used instead of blocking on the
> lock, the throughput is not good in some scenarios (especially single queue,
> multiple connections).
> For example:
> if (TRY_LOCK(&wq->tx_lock)) {
>
Hey Andre,
Looks OK to me.
Note that tcps_rcvdwhileclosing is a new stat Juan added (I had omitted the
rest of that diff b/c adding a new stat wasn't that interesting to the
discussion). If you want that stat added, we can prepare a patch with the
rest of the changes (or, I'm sure you know alrea
On Mon, Apr 8, 2013 at 1:14 PM, Duvvuru,Venkat Kumar <
venkatkumar.duvv...@emulex.com> wrote:
> Hi,
> In the transmit path, if enqueue mechanism is used instead of blocking on
> the lock, the throughput is not good in some scenarios (especially single
> queue, multiple connections).
> For example:
12 matches
Mail list logo
