rwatson added a subscriber: bz.
rwatson added a comment.
Many of these changes are not sufficient to address the underlying problems
in this code, as the lock covers loop iteration but fails to protect the
stability of the 'ifp' or 'ia' pointer outside of the loop. It could be that
this prev
rwatson accepted this revision.
rwatson added a comment.
This revision is now accepted and ready to land.
This seems generally sensible.
I'm not quite sure about keeping the "Non-standard RSS hash types" comment,
as M_HASHTYPE_OPAQUE is basically intended to be a catch-all for any other
On 21 Aug 2016, at 19:18, Andrey V. Elsukov wrote:
> On 21.08.16 20:33, Adrian Chadd wrote:
>>> Does this make sense?
>>
>> Right. Let me go and look into it a little more. I think we may want
>> to revert the change (which just landed to -11, so maybe revert that
>> too) so I can test both of
On Sun, 3 Jan 2016, Rui Paulo wrote:
NetBSD 7.0 has just introduced these two syscalls. And Linux also has them.
Does FreeBSD have them? Or plan to support them in the future?
FreeBSD does not have them. It doesn't seem especially hard to implement,
though. Do you know any major applicatio
rwatson accepted this revision.
rwatson added a comment.
Seems sensible.
REVISION DETAIL
https://reviews.freebsd.org/D1805
To: davide, kmacy, np, lstewart, rrs, julian, adrian, rwatson
Cc: emaste, freebsd-net
___
freebsd-net@freebsd.org mailing list
rwatson requested changes to this revision.
rwatson added a comment.
This revision now requires changes to proceed.
Looks like some serious transcription errors are in this patch.
INLINE COMMENTS
sys/kern/uipc_sockbuf.c:225 Should this be so->so_rcv?
sys/kern/uipc_sockbuf.c:234 Should this be
rwatson added a comment.
Seems reasonable. I'm slightly surprised that any code other than sbwait()
actually implements the sleep on sb_acc, and wonder if either a use of
abstraction improvement, or an actual abstraction improvement, is needed to fix
t4_ddp.c.
REVISION DETAIL
https://reviews
rwatson added a comment.
np@'s comments are good ones, both with respect to ACK clocking and BPF -- but
this will also affect local firewalls that do state tracking and/or
transformation, and likewise will run into problems.
Given this discussion, I'm increasingly convinced that this is Not A G
rwatson added a comment.
Historically, I believe that we've allowed additional trailer content/padding
to be included at the end of mbuf chains that isn't in the IP datagram, and is
silently ignored, as it isn't included in the IP packet length. I may
misunderstand what was going on there, but
Dear all:
As you may have spotted from recent commits to 11-CURRENT, I've been working
through the mbuf allocator and mbuf consumers (protocols, device drivers)
trying to reduce consumer dependence on the specifics of the mbuf layout --
i.e., using M_SIZE() instead of caller assumptions about MLE
On Mon, 1 Dec 2014, George Neville-Neil wrote:
On a slight tangent. I ran VIMAGE kernels vs. non VIMAGE kernels for both a
VANILLA kernel and a PF kernel (PF on but no rules) as a quick smoke test
today. The raw forwarding performance was unchanged between kernels with
and without VIMAGE on
rwatson added a comment.
This patch is probably safe if limited to UDP.
REVISION DETAIL
https://reviews.freebsd.org/D1201
To: rodrigc, alfredperlstein, melifaro, glebius, hrs, wollman, bryanv, rpaulo,
adrian, bz, gnn, hiren, rwatson
Cc: freebsd-net, emaste, gnn, rwatson
__
rt
remain disabled by default (something we might think about revisting prior to
11.0).
Robert
-- Forwarded message --
Date: Sat, 15 Mar 2014 00:57:50 + (UTC)
From: Robert Watson
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org
Su
On Sat, 24 Aug 2013, Alexander V. Chernikov wrote:
On 24.08.2013 00:54, Adrian Chadd wrote:
I'd like to commit this to -10. It migrates the if_lagg locking
from a rw lock to a rm lock. We see a bit of contention between the
transmit and
We're running lagg with rmlock on several hundred heavi
On Tue, 4 Dec 2012, Andre Oppermann wrote:
For most if not all ethernet drivers from 100Mbit/s the TX DMA rings are so
large that buffering at the IFQ level doesn't make sense anymore and only
adds latency. So it could simply directly put everything into the TX DMA
and not even try to soft-qu
On Tue, 4 Dec 2012, John Baldwin wrote:
Q2: Are there any case studies or benchmarks for buf_ring, or it is just
blindly being used because someone claimed it was better and offered it for
free? One of the points of locking is to avoid race conditions, so the
fact that you have races in a su
On Sun, 2 Dec 2012, Choupani wrote:
I'm working on kernel in FreeBSD-9. I need to protect a
common resource (for example a queue).
There are 4 points for access (read/write) this common resource as bellows:
1. ether_input() – hardware interrupt
2. ip_input() & ip_output() – software interrupt
Panics along these lines often occur if there is a concurrency bug in a device
driver such that it modifies an mbuf after dispatching to the network stack.
E.g., by freeing it, reusing it, an errant dereference, etc. Not guaranteed,
but that is where I'd start.
Robert
On Sat, 17 Nov 2012, Ad
On Thu, 24 May 2012, Vijay Singh wrote:
Folks, I am trying to understand the need to hold the V_tcbinfo lock in part
of this function [code included below for reference].
At present this causes the socket upcall to be called with the V_tcbinfo
lock held, which I'd like to avoid. We release t
On Thu, 5 Jan 2012, Navdeep Parhar wrote:
Looks like there's a case where tcp_detach could return with the inp lock
held. I see an XXXRW comment questioning this possibility, but we should
either add an assertion to verify that the case does not occur, or unlock
the inpcb before returning.
On Fri, 30 Dec 2011, Maxim Sobolev wrote:
On 12/30/2011 4:46 PM, Maxim Sobolev wrote:
I see. Would you guys mind if I put that NULL pointer check into the code
for the time being and turn it into some kind of big nasty warning in
8-stable branch only?
I could also open a ticket, put all deb
On Mon, 7 Nov 2011, Maxim Sobolev wrote:
On 11/7/2011 3:25 PM, Bjoern A. Zeeb wrote:
Now if you are clever you'd also log the inp there as the above will only
prove the case that something is wrong but still not help us in anything to
figure out what.
Good point, thank you Sir.
Would that
On Wed, 28 Sep 2011, Mikolaj Golub wrote:
On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote:
KM> Sorry, didn't look at the images (limited bw), I've seen something KM>
like this before in timewait. This "can't happen" with UDP so will be KM>
interested in learning more about the bug.
The pa
On Mon, 6 Jun 2011, grarpamp wrote:
I know we've got polling. And probably MSI-X in a couple drivers. Pretty
sure there is still one CPU doing the interrupt work? And none of the
multiple queue thread spreading tech exists?
Actually, with most recent 10gbps cards, and even 1gbps cards, we pr
On Fri, 4 Feb 2011, Prabhu Hariharan wrote:
When I delete an IP-address from an interface, the TCP (and other)
connections using that local IP-address are not getting purged. The telnet
or ssh sessions on the other end just get hung, as FreeBSD address-deletion
doesn't handle this situation
On Sat, 15 Jan 2011, William Allen Simpson wrote:
Who's the kernel expert on TCP around here? ISC wants me to port TCPCT to
FreeBSD. Although I've joined this list (some time ago), I've not seen any
traffic discussing TCP'ish things. Need somebody willing to walk me through
the processes a
On Wed, 15 Dec 2010, Bjoern A. Zeeb wrote:
I would request two things:
1) the extra couple of months; this will not prevent the evitable removal
yet only defer it.
Sounds good to me -- my goal is not to remove NETNATM, rather, the remove code
that doesn't compile or work. I'm happy to si
On Wed, 10 Nov 2010, Randy Bush wrote:
bjoern zeeb just received the itojun award. congratulations, bjoern. and
than you for all the hard work on the ipv6 stack.
Indeed -- many congratulations, Bjoern! The slow road from an experimental
protocol in an experimental network stack to one widel
On Sat, 23 Oct 2010, Lawrence Stewart wrote:
One observation though: net.inet.tcp.reass.cursegments was non-zero (it was
just 1) after 30 rounds, where each round is (as earlier) 15-concurrent
instances of netperf for 20s. This was on the netserver side. And, it was
zero before the netperf ru
On Thu, 14 Oct 2010, Attilio Rao wrote:
No, what I'm saying is: UMA needs to not call its drain handlers, and
ideally not call into VM to fill slabs, from the dumping context. That's
easy to implement and will cause the dump to fail rather than causing the
system to hang.
My point is, howeve
On Fri, 8 Oct 2010, Attilio Rao wrote:
GENERAL FRAMEWORK ARCHITECTURE
Netdump is composed, right now, by an userland "server" and a kernel
"client". The former is run on the target machine (where the dump will
phisically happen) and it is responsible for receiving the packets
containing cor
On Thu, 30 Sep 2010, Julian Elischer wrote:
On 9/30/10 10:49 AM, Ryan Stone wrote:
It's not a big thing but it would be nice to replace the m_next and
m_nextpkt fields with queue.h macros.
funny, I've never even thought of that..
I have, and it's a massive change touching code all over the
On Tue, 31 Aug 2010, Garrett Wollman wrote:
In article <4c7d02bb.40...@freebsd.org> an...@freebsd.org writes:
sendto() will not be touched or modified. It's just that on a TCP socket
the tcp protocol will not perform an implied connect anymore. The only
thing that changes is TCP dropping a
On Tue, 31 Aug 2010, Andre Oppermann wrote:
I'm not entirely comfortable with this change, and would like a chance to
cogitate on it a bit more. While I'm not aware of any applications
depending on the semantic for TCP, I know that we do use it for UNIX domain
sockets.
I don't have any plan
On Sun, 29 Aug 2010, Andre Oppermann wrote:
When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years ago
the semantics of sendto(2) with regard to TCP sockets were changed.
It became possible directly do a sendto(2) call with the target address in
the *to argument instead of do
On Sun, 29 Aug 2010, Sadish Kulasekere wrote:
I need to know how to send packet from the kernel level. Can someone please
point me to any documentation?
Hi Sadish:
Take a look at the socket(9) man page, which is the KPI used by in-kernel
consumers of sockets such as the NFS client and serve
Dear all:
When the new link layer framework was introduced in 8.0, one of our ATM
stacks, netnatm, was left behind. As a result, it neither compiles nor runs
in 8.x and 9.x. This e-mail serves two purposes:
(1) To solicit a volunteer who can work on the netnatm stack in 9.x, with
potentia
On Tue, 24 Nov 2009, John Baldwin wrote:
Now that no drivers in the tree use if_watchdog and if_timer, this patch
just removes them completely. Since if_timer was a short that was adjacent
to if_index, removing if_timer would have still left a padding hole in the
form of a short on all of ou
On Sat, 17 Oct 2009, rihad wrote:
Just rebooted with the "ifp->if_snd.ifq_drv_maxlen = 1024;" kernel, all ok
so far. There's currenlty only 1000 or so entries in the ipfw table and
around 350-400 net mbps load, so I'll wait a few hours for the numbers to
grow to >2000 and 460-480 respectively
On Sat, 17 Oct 2009, rihad wrote:
P.S.: BTW, there's a small admin-type inconsistency in FreeBSD 7.1:
/etc/rc.firewall gets executed before values set by /etc/sysctl.conf are in
effect, so "queue 2000" isn't allowed in ipfw pipe rules (as
net.inet.ip.dummynet.pipe_slot_limit is only 100 by de
On Thu, 15 Oct 2009, rihad wrote:
meaning that USABLE_TX_BD is expected to be smaller than MAX_TX_BD. What if
MAX_TX_BD is itself way smaller than 1024, which I'll eventually set
ifq_drv_maxlen to? Can a driver guru please comment on this? In a few days
I'm going to try it anyway, and if the
On Sun, 11 Oct 2009, Harsha Srinath wrote:
I'm running an updated HEAD kernel and got a page fault in
ifindex_alloc_locked() in if.c. I figured that the problem was caused by the
(pluggable) network card of my laptop and found that during the
initialization of the interface, cb_event_thread()
On Wed, 7 Oct 2009, rihad wrote:
Suggestions like increasing timer resolution are intended to spread out the
injection of packets by dummynet to attempt to reduce the peaks of
burstiness that occur when multiple queues inject packets in a burst that
exceeds the queue depth supported by combin
On Wed, 7 Oct 2009, rihad wrote:
Robert Watson wrote:
On Wed, 7 Oct 2009, rihad wrote:
snapshot of the top -SH output in the steady state? Let top run for a
few minutes and then copy/paste the first 10-20 lines into an e-mail.
Sure. Mind you: now there's only 1800 entries in each o
On Wed, 7 Oct 2009, rihad wrote:
snapshot of the top -SH output in the steady state? Let top run for a few
minutes and then copy/paste the first 10-20 lines into an e-mail.
Sure. Mind you: now there's only 1800 entries in each of the two ipfw
tables, so any drops have stopped. But it only t
On Wed, 7 Oct 2009, rihad wrote:
rihad wrote:
I've yet to test how this direct=0 improves extensive dummynet drops.
Ooops... After a couple of minutes, suddenly:
net.inet.ip.intr_queue_drops: 1284
Bumped it up a bit.
Yes, I was going to suggest that moving to deferred dispatch has probabl
On Wed, 7 Oct 2009, Eugene Grosbein wrote:
On Tue, Oct 06, 2009 at 08:28:35PM +0500, rihad wrote:
I don't think net.inet.ip.intr_queue_maxlen is relevant to this problem, as
net.inet.ip.intr_queue_drops is normally zero or very close to it at all
times.
When net.isr.direct is 1, this queue
On Mon, 22 Jun 2009, Jerry Toung wrote:
may be someone has seen this already before I dig into the issue myself. A
consistent crash with the following trace. Unread portion of the
kernel message buffer:
This is a NULL pointer dereference -- could you tell me what specific version
of
On Fri, 5 Jun 2009, Barney Cordoba wrote:
I'm getting a panic in sbflush where mbcnt is 0 and sb_mb is not empty. Any
clues as to what might cause this? It happening during a load test.
sbflush() panics are typically symptoms of bugs elsewhere in the network stack
or kernel, often race condit
On Fri, 24 Apr 2009, pluknet wrote:
2009/4/23 Robert Watson :
On Thu, 23 Apr 2009, pluknet wrote:
Please, give me comment on this. The panic is on 6.2-REL. Is it known to
be fixed in the latter releases?
It may well be -- there have been quite significant architectural
improvements to
The following reply was made to PR kern/132734; it has been noted by GNATS.
From: Robert Watson
To: Mikolaj Golub
Cc: Alexey Illarionov , bug-follo...@freebsd.org
Subject: Re: kern/132734: panic in net/if_mib.c
Date: Thu, 23 Apr 2009 20:33:43 +0100 (BST)
On Thu, 23 Apr 2009, Mikolaj Golub
On Thu, 23 Apr 2009, pluknet wrote:
Please, give me comment on this. The panic is on 6.2-REL. Is it known to be
fixed in the latter releases?
It may well be -- there have been quite significant architectural improvements
to socket life cycle (etc) between 6.2 and 7.x releases, which may well
On Sun, 19 Apr 2009, Jon Otterholm wrote:
I have a router running 6.4R that does not forward packets if I disable
PROMISC on the interface. Hardware is a Dell PE with two Intel 82541EI
chipsets (if_em). I have a number (~100) of vlan-interfaces on em0.
Everything works as aexpected if I turn o
:39:18 + (UTC)
From: Robert Watson
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org
Subject: svn commit: r191253 - head/sys/net
Author: rwatson
Date: Sat Apr 18 20:39:17 2009
New Revision: 191253
URL: http://svn.freebsd.org/changeset/base/191253
Log
On Thu, 16 Apr 2009, Narek Gharibyan wrote:
I would like to know is there any solution to problem show below, because we
use FreeBSD 7.0 in our network structure and we are meeting face to face to
this problem everyday\
Hi Narek:
As Kip mentions, this panic message (a fatal trap in a softwar
On Sat, 11 Apr 2009, Karim Fodil-Lemelin wrote:
I think it would be desirable to make a change to more flexible m_tag types
for 8.0, but I'm not sure I have time to implement/test it. Is this
something you might be interested in working on? I'm thinking of basically
replacing the m_tag_free
On Fri, 10 Apr 2009, Karim Fodil-Lemelin wrote:
Thank you for the answer, clear and concise. I asked the question because I
had modified pf_get_mtag() to use uma directly in the hope that it would be
faster then calling malloc. But since pf_mtag is 20bytes, malloc will end up
using a fixed 32b
On Fri, 10 Apr 2009, Karim Fodil-Lemelin wrote:
Is there any plans on getting the mbuf tags sub-system integrated with the
universal memory allocator? Getting tags for mbufs is still calling malloc
in uipc_mbuf.c ... What would be the benefits of using uma instead?
Hi Karim:
Right now there
On Wed, 8 Apr 2009, Barney Cordoba wrote:
Is there any work being done on lighter weight locks for queues? It seems
ridiculous to avoid using queues because of lock contention when the locks
are only protecting a couple lines of code.
My reading is that there are two, closely related, things
On Tue, 7 Apr 2009, Barney Cordoba wrote:
When I enabled LOCK_PROFILING my side modules, such as
if_ibg, stopped working. It seems that the ifnet structure or something
changed with that option enabled. Is there a way to sync this without
having to integrate everything into a specific kernel
On Tue, 7 Apr 2009, Barney Cordoba wrote:
Have you tried LOCK_PROFILING? It would quickly tell you if driver locks
were a source of significant contention. It works quite well...
When I enabled LOCK_PROFILING my side modules, such as if_ibg, stopped
working. It seems that the ifnet structu
On Tue, 7 Apr 2009, Sepherosa Ziehau wrote:
On Sun, Apr 5, 2009 at 9:34 PM, Ivan Voras wrote:
Robert Watson wrote:
On Sun, 5 Apr 2009, Ivan Voras wrote:
I thought this has something to deal with NIC moderation (em) but
can't really explain it. The bad performance part (not the jum
On Mon, 6 Apr 2009, Julian Elischer wrote:
while this is true, m_pullup ALWAYS does things so in fact you want to
always put it in a test to see if it is really needed..
Then m_pullup() should be fixed? Keeping the expression of the pullup short
makes the network code a lot more compact, wh
On Tue, 7 Apr 2009, Sepherosa Ziehau wrote:
This issue is almost entirely independent from things like the cache line
miss issue, unless you hit the uncommon case of having to do work in
m_pullup(), in which case life sucks.
It would be useful to use DTrace to profile a number of the workfull
On Mon, 6 Apr 2009, Ivan Voras wrote:
I think we're talking slightly at cross purposes. There are two
transfers of interest:
(1) DMA of the packet data to main memory from the NIC
(2) Servicing of CPU cache misses to access data in main memory
By the time you receive an interrupt, the DMA is
On Mon, 6 Apr 2009, Barney Cordoba wrote:
Is there a way to give a kernel thread exclusive use of a core? I know you
can pin a kernel thread with sched_bind(), but is there a way to keep other
threads from using the core? On an 8 core system it almost seems that the
randomness of more cores i
On Mon, 6 Apr 2009, Ivan Voras wrote:
I'd like to understand more. If (in netisr) I have a mbuf with headers, is
this data already transfered from the card or is it magically "not here
yet"?
A lot depends on the details of the card and driver. The driver will take
cache misses on the descri
On Sun, 5 Apr 2009, Ivan Voras wrote:
The argument is not that they are slower (although they probably are a bit
slower), rather that they introduce serialization bottlenecks by requiring
synchronization between CPUs in order to distribute the work. Certainly
some of the scalability issues in
On Sun, 5 Apr 2009, Barney Cordoba wrote:
I'm curious as to your assertion that hardware transmit queues are a big
win. You're really just loading a transmit ring well ahead of actual
transmission; there's no need to force a "start" for each packet queued. You
then have more overheard managing
On Sun, 5 Apr 2009, Ivan Voras wrote:
I thought this has something to deal with NIC moderation (em) but can't
really explain it. The bad performance part (not the jump) is also visible
over the loopback interface.
FYI, if you want high performance, you really want a card supporting
multiple
On Sun, 5 Apr 2009, Ivan Voras wrote:
I thought this has something to deal with NIC moderation (em) but can't
really explain it. The bad performance part (not the jump) is also visible
over the loopback interface.
FYI, if you want high performance, you really want a card supporting multiple
On Sun, 5 Apr 2009, Ivan Voras wrote:
I'm developing an application that needs a high rate of small TCP
transactions on multi-core systems, and I'm hitting a limit where a kernel
task, usually swi:net (but it depends on the driver) hits 100% of a CPU at
some transactions/s rate and blocks fur
On Fri, 20 Mar 2009, rajasooriyar lakshman wrote:
I am new to FreeBSDMy question is regarding a compilation of a routing
protocol in FreeBSD 7.0.
I am trying to run a adhoc routing protocol called, Dynamic Source Routing
(DSR) on my freebsd router (7.0).. I have got the implementation fr
On Sat, 21 Mar 2009, Rui Paulo wrote:
I just updated the base system tcpdump to 4.0.0. Most noticeably this new
version includes a new output format.
Please report any regressions.
Cool, thanks for working on this!
Robert N M Watson
Computer Laboratory
University of Cambridge
__
On Mon, 16 Feb 2009, Robert Watson wrote:
The following schedule is proposed, assuming nothing goes horribly wrong
with the new USB code in the next few weeks, and remaining nits relating to
USB network and 802.11 drivers are handled:
16 February 2009HEADS UP to lists (this e-mail
On Sun, 15 Mar 2009, Robert Watson wrote:
16 February 2009HEADS UP to lists (this e-mail)
01 March 2009 Disable build of all IFF_NEEDSGIANT drivers
in 8.x
Slightly delayed while USB NDIS was sorted out, I will be moving ahead with
disabling the build of all IFF_NEEDSGIANT drivers
On Sun, 15 Mar 2009, Robert Watson wrote:
On Mon, 16 Feb 2009, Robert Watson wrote:
16 February 2009HEADS UP to lists (this e-mail)
01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x
Slightly delayed while USB NDIS was sorted out, I will be moving ahead with
On Mon, 16 Feb 2009, Robert Watson wrote:
16 February 2009HEADS UP to lists (this e-mail)
01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x
Slightly delayed while USB NDIS was sorted out, I will be moving ahead with
disabling the build of all IFF_NEEDSGIANT
On Thu, 12 Mar 2009, Richard Tector wrote:
Robert Watson wrote:
On Tue, 10 Mar 2009, Richard Tector wrote:
Just a me too on 7.1-STABLE amd64 (as of 2009-03-05 at least). Note this
does not happen with a 7.1-RELEASE kernel, so I'm assuming it's not
userland.
This problem is beli
On Tue, 10 Mar 2009, Richard Tector wrote:
Just a me too on 7.1-STABLE amd64 (as of 2009-03-05 at least). Note this
does not happen with a 7.1-RELEASE kernel, so I'm assuming it's not
userland.
This problem is believed fixed as of r189531, committed 8 March -- could you
try updating and see
On Mon, 2 Mar 2009, Rui Paulo wrote:
On 1 Mar 2009, at 21:26, Julian Elischer wrote:
Luigi Rizzo wrote:
Hi, I am planning to split netinet/ip_fw2.c in a number of smaller files
to make it more manageable, and while i do this I would also like to move
the files related to ipfw2 (namely ip_fw
On Mon, 16 Feb 2009, Robert Watson wrote:
The following schedule is proposed, assuming nothing goes horribly wrong
with the new USB code in the next few weeks, and remaining nits relating to
USB network and 802.11 drivers are handled:
16 February 2009HEADS UP to lists (this e-mail
On Mon, 23 Feb 2009, david guéluy wrote:
By using a PFIL_HOOK on FreeBSD 7.1-prerelease, I notice that I receive some
packets from 0.0.0.0 to 0.0.0.0.
A buggy program in userland produce these packets when the shutdown system
call is used on a socket which is not connected.
Even if it's a
On Sat, 21 Feb 2009, Robert Watson wrote:
Something like the following may help -- build-tested but not not run-time
tested:
I've now committed this patch to head as r188962 -- thanks for the report!
Robert N M Watson
Computer Laboratory
University of Cambridge
Index: in_
On Wed, 18 Feb 2009, dikshie wrote:
does anyone see this panic on -HEAD:
panic: _rw_wlock_hard: recursing but non-recursive rw radix node head @
/usr/src/sys/net/route.c:831
kdb_enter() at kdb_enter+0x3a
panic() at panic+0x136
_rw_wlock_hard() at _rw_wlock_hard+0x66
_rw_wlock() at _rw_wlock+
On Tue, 17 Feb 2009, Krassimir Slavchev wrote:
if_sr and if_ar are really simple and could probably be converted
"trivially".. especially if their netgraph code is used.
however I wonder if anyone still has that hardware (they are drivers for
two sync serial cards).
I still have such Digi/
(Bcc to arch@)
On Mon, 26 May 2008, Robert Watson wrote:
Just to keep track of things:
http://wiki.freebsd.org/NONMPSAFE_DEORBIT
Delayed by about six months, the merge and switch to the new USB stack in 8.x
means that we're now fairly close to being able to pick up this project
* Robert Watson [090202 17:06]:
On Sun, 1 Feb 2009, Derek Tattersall wrote:
In order to become familiar with multicast implementation using FreeBSD, I
found via Google a pair of test programs which multicast sent a simple
text message and received the text message. I added some code to
On Sun, 1 Feb 2009, Mitar wrote:
Is there any progress on this error reported:
http://freebsd.monkey.org/freebsd-net/200805/msg00026.html
I have the same or very similar issue. On my server large HTTP uploads are
failing because there are only one direction data transmissions (when
reading/
On Sun, 1 Feb 2009, Derek Tattersall wrote:
In order to become familiar with multicast implementation using FreeBSD, I
found via Google a pair of test programs which multicast sent a simple text
message and received the text message. I added some code to report the
source address, because non
The following reply was made to PR kern/129719; it has been noted by GNATS.
From: Robert Watson
To: Dan Nelson
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-b...@freebsd.org,
freebsd-net@FreeBSD.org
Subject: Re: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL
Date: Mon, 2
On Wed, 17 Dec 2008, Dan Nelson wrote:
I've been trying to solve an intermittent connectivity problem where a
server stops seeing incoming packets. It happened today, and when the
system was shutting down, it paniced and rebooted. The gdb stack trace is a
little mangled due to inlined functi
On Wed, 28 Jan 2009, Per Hurtig (work) wrote:
How differently are TCP packets treated compared to e.g. SCTP packets, while
traversing the FreeBSD network stack (up to and including the IP-layer when
using ipfw)?. I do not assume that the firewall (ipfw) is explicitly
configured to check for e
On Sun, 11 Jan 2009, Jason DiCioccio wrote:
So I've got various vmcores here from kmem_malloc failures.. I already know
that it's an excess of mbufs that's causing the crash, I'm just trying to
figure out what the mbufs contain so that I can try and figure out where
they came from..
Current
the output of uname -a on the system?
Thanks,
Robert N M Watson
Computer Laboratory
University of Cambridge
On Mon, Jan 5, 2009 at 9:13 PM, Robert Watson wrote:
On Fri, 2 Jan 2009, Lin Jui-Nan Eric wrote:
After running "netstat -s -p tcp", we found that lots of packets are
discar
On Fri, 2 Jan 2009, Lin Jui-Nan Eric wrote:
After running "netstat -s -p tcp", we found that lots of packets are
discarded due to memory problems. We googled for it, and found that sysctl
oid "net.inet.tcp.reass.maxsegments" became 0, therefore packets never
reassembled.
Then we checked our
On Tue, 30 Dec 2008, Yony Yossef wrote:
I'm facing lots of UDP "Connection refused" errors while running
multistream iperf test. Analyzing it with wireshark showed several "ICMP
Port Unreachable" problems.
I've overriden it with "sysctl net.inet.udp.blackhole=1",
but I'm not
sure this is the
On Tue, 30 Dec 2008, Max Laier wrote:
On Tuesday 30 December 2008 12:49:55 Ferner Cilloniz wrote:
I do not think I could ever be more tired of this topic but I cannot seem
to understand what to do. I have tried more about a month now to send
arbitrary UDP packets from a kernel module but cann
On Wed, 24 Dec 2008, Yony Yossef wrote:
I'm facing lots of UDP "Connection refused" errors while running multistream
iperf test. Analyzing it with wireshark showed several "ICMP Port
Unreachable" problems.
I've overriden it with "sysctl net.inet.udp.blackhole=1", but I'm not sure
this is th
On Wed, 24 Dec 2008, Bruce Simpson wrote:
Hartmut Brandt wrote:
In any case there is still an Todo on my side: the routing information for
NETNATM is currently lost somewhere between L2 and L3 :-) I guess I come
back to you in the new year to fix this issue... Have to fetch my ATM
equipment
1 - 100 of 428 matches
Mail list logo
