At 07:15 PM 8/18/2008, Robert Watson wrote:
On Mon, 18 Aug 2008, Mike Tancsa wrote:
At 06:32 PM 8/18/2008, Kip Macy wrote:
Could you please check that this doesn't happen on HEAD as well?
This same code has been in 8 since shortly after the branch.
I dont have any easy way to
On Sun, 3 Aug 2008, Robert Watson wrote:
This is an advance warning that, late next week, I will be merging a fairly
large set of changes to the IPv4 and IPv6 protocols layered over the
inpcb/inpcbinfo kernel infrastructure. To be specific, this affects TCP,
UDP, and raw sockets on both
At 04:14 AM 8/18/2008, Robert Watson wrote:
On Sun, 3 Aug 2008, Robert Watson wrote:
This is an advance warning that, late next week, I will be merging
a fairly large set of changes to the IPv4 and IPv6 protocols
layered over the inpcb/inpcbinfo kernel infrastructure. To be
specific, this
On Monday 18 August 2008 09:37:51 am Mike Tancsa wrote:
At 04:14 AM 8/18/2008, Robert Watson wrote:
On Sun, 3 Aug 2008, Robert Watson wrote:
This is an advance warning that, late next week, I will be merging
a fairly large set of changes to the IPv4 and IPv6 protocols
layered over the
At 10:24 AM 8/18/2008, John Baldwin wrote:
Author: kmacy
Date: Thu Jul 31 22:42:27 2008
New Revision: 181075
URL: http://svn.freebsd.org/changeset/base/181075
Log:
MFC ARP update hooks and change to arpresolve to do arp
resolution without a
pending mbuf to transmit
Modified:
At 10:24 AM 8/18/2008, John Baldwin wrote:
Edit src/sys/conf/files
Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy
Edit src/sys/netinet/tcp_subr.c
Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy
Edit src/sys/netinet/tcp_syncache.c
Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy
got it
On Mon, Aug 18, 2008 at 9:22 AM, Mike Tancsa [EMAIL PROTECTED] wrote:
At 10:24 AM 8/18/2008, John Baldwin wrote:
Edit src/sys/conf/files
Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy
Edit src/sys/netinet/tcp_subr.c
Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy
At 12:55 PM 8/18/2008, Kip Macy wrote:
got it
Thanks. The problem manifests itself soon after boot. There is
nothing special about the box, it has 2 em network interfaces doing a
lot of sendmail as well as local recursive DNS for itself and a few
other sendmail boxes and also talks to a
Hi Mike,
Could you please check that this doesn't happen on HEAD as well? This
same code has been in 8 since shortly after the branch.
Thanks,
Kip
On Mon, Aug 18, 2008 at 10:14 AM, Mike Tancsa [EMAIL PROTECTED] wrote:
At 12:55 PM 8/18/2008, Kip Macy wrote:
got it
Thanks. The problem
At 06:32 PM 8/18/2008, Kip Macy wrote:
Hi Mike,
Could you please check that this doesn't happen on HEAD as well? This
same code has been in 8 since shortly after the branch.
Hi,
I dont have any easy way to migrate the box to HEAD and then
back. Can I just boot a kernel from HEAD ?
On Mon, Aug 18, 2008 at 3:42 PM, Mike Tancsa [EMAIL PROTECTED] wrote:
At 06:32 PM 8/18/2008, Kip Macy wrote:
Hi Mike,
Could you please check that this doesn't happen on HEAD as well? This
same code has been in 8 since shortly after the branch.
Hi,
I dont have any easy way to migrate
On Mon, 18 Aug 2008, Mike Tancsa wrote:
At 06:32 PM 8/18/2008, Kip Macy wrote:
Could you please check that this doesn't happen on HEAD as well? This same
code has been in 8 since shortly after the branch.
I dont have any easy way to migrate the box to HEAD and then back.
Can I just
Same thing.
http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019220.html
--
Best regards
Vladimir Korkodinov
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail
At 04:27 AM 8/14/2008, Vladimir Korkodinov wrote:
Same thing.
http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019220.html
Well, that narrows it down a bit since you are not running with Intel
nics. It seems to be in the commits below between
date=2008.07.30.18.00.00
and
On Thu, Aug 14, 2008 at 10:29:09AM -0400, Mike Tancsa wrote:
At 04:27 AM 8/14/2008, Vladimir Korkodinov wrote:
Same thing.
http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019220.html
Well, that narrows it down a bit since you are not running with Intel
nics. It seems to be in
At 06:20 AM 8/12/2008, Robert Watson wrote:
Anyone out there running name servers, NFS over UDP, and other UDP
workloads: your testing of this patch prior to commit would be much
appreciated.
Not sure if this is related or not, but I am seeing a 'boatload' of
strange proxy arp issues.
On Wed, 13 Aug 2008, Mike Tancsa wrote:
At 06:20 AM 8/12/2008, Robert Watson wrote:
Anyone out there running name servers, NFS over UDP, and other UDP
workloads: your testing of this patch prior to commit would be much
appreciated.
Not sure if this is related or not, but I am seeing a
At 04:41 PM 8/13/2008, Robert Watson wrote:
Well, it shouldn't be related, but sometimes things get tricky with
locking if it turns out that extra locking at one layer was masking
a lack of locking at another. Let's try to diagnose this one a bit
more before concluding that is the case,
On Wed, 13 Aug 2008, Mike Tancsa wrote:
At 04:41 PM 8/13/2008, Robert Watson wrote:
Well, it shouldn't be related, but sometimes things get tricky with locking
if it turns out that extra locking at one layer was masking a lack of
locking at another. Let's try to diagnose this one a bit
At 04:46 PM 8/13/2008, Mike Tancsa wrote:
At 04:41 PM 8/13/2008, Robert Watson wrote:
Well, it shouldn't be related, but sometimes things get tricky with
locking if it turns out that extra locking at one layer was masking
a lack of locking at another. Let's try to diagnose this one a bit
On Wed, Aug 13, 2008 at 05:16:27PM -0400, Mike Tancsa wrote:
At 04:46 PM 8/13/2008, Mike Tancsa wrote:
At 04:41 PM 8/13/2008, Robert Watson wrote:
Well, it shouldn't be related, but sometimes things get tricky with
locking if it turns out that extra locking at one layer was masking
a lack
At 05:25 PM 8/13/2008, Jeremy Chadwick wrote:
I will try a kernel before the em changes, as thats the only other thing
I can think of off the top of my head.
I commented out em from the kernel and loaded up a previous version
via kld, but still the same thing, although not nearly as much
On Wed, Aug 13, 2008 at 05:35:21PM -0400, Mike Tancsa wrote:
At 05:25 PM 8/13/2008, Jeremy Chadwick wrote:
I will try a kernel before the em changes, as thats the only other thing
I can think of off the top of my head.
I commented out em from the kernel and loaded up a previous version
On Wed, 13 Aug 2008, Mike Tancsa wrote:
At 05:25 PM 8/13/2008, Jeremy Chadwick wrote:
I will try a kernel before the em changes, as thats the only other thing
I can think of off the top of my head.
I commented out em from the kernel and loaded up a previous version via kld,
but still
At 06:22 PM 8/13/2008, Robert Watson wrote:
Any suggestions on what kernel to go back to start from ?
I'm concerned by the presence of multiple ARP entries for a single
IP -- I'll need to reread the ARP code to refresh my memory, but in
general I would expect to see at most one in-progress
At 06:22 PM 8/13/2008, Robert Watson wrote:
I'm concerned by the presence of multiple ARP entries for a single
IP -- I'll need to reread the ARP code to refresh my memory, but in
general I would expect to see at most one in-progress or complete
ARP entry for any particular IP address at a
At 06:22 PM 8/13/2008, Robert Watson wrote:
I'm concerned by the presence of multiple ARP entries for a single
IP -- I'll need to reread the ARP code to refresh my memory, but in
general I would expect to see at most one in-progress or complete
ARP entry for any particular IP address at a
On Mon, 11 Aug 2008, Mike Tancsa wrote:
At 05:21 PM 8/8/2008, Robert Watson wrote:
http://www.watson.org/~robert/freebsd/netperf/20080808-7stable-rwlock-inpcb.diff
These incude the inpcb/inpcbinfo read/write locking changes (although not
yet for raw/divert sockets). Any testing,
At 05:21 PM 8/8/2008, Robert Watson wrote:
http://www.watson.org/~robert/freebsd/netperf/20080808-7stable-rwlock-inpcb.diff
These incude the inpcb/inpcbinfo read/write locking changes
(although not yet for raw/divert sockets). Any testing, especially
with heavy UDP loads, would be much
Robert, reviews of sorecv_drgram:
/* XXXRW: sbwait() may not be as happy without sblock(). */
error = sbwait(so-so_rcv);
Does not need XXX, sbwait waits for data, it's not really related
to sblock(). remove comment.
The variable orig_resid can be removed, I think
On Sun, 3 Aug 2008, Robert Watson wrote:
This is an advance warning that, late next week, I will be merging a fairly
large set of changes to the IPv4 and IPv6 protocols layered over the
inpcb/inpcbinfo kernel infrastructure. To be specific, this affects TCP,
UDP, and raw sockets on both
* David G Lawrence [EMAIL PROTECTED] [080805 11:37] wrote:
The thrust of this change is to replace the mutexes protecting the inpcb
and inpcbinfo data structures with read-write locks (rwlocks). These
That's really cool and directly affects my current work project. I'm
developing
On Wed, 6 Aug 2008, Alfred Perlstein wrote:
* David G Lawrence [EMAIL PROTECTED] [080805 11:37] wrote:
The thrust of this change is to replace the mutexes protecting the inpcb
and inpcbinfo data structures with read-write locks (rwlocks). These
That's really cool and directly affects my
The thrust of this change is to replace the mutexes protecting the inpcb
and inpcbinfo data structures with read-write locks (rwlocks). These
That's really cool and directly affects my current work project. I'm
developing (have developed, actually) a multi-threaded, 5000+ member VoIP/SIP
Dear all:
This is an advance warning that, late next week, I will be merging a fairly
large set of changes to the IPv4 and IPv6 protocols layered over the
inpcb/inpcbinfo kernel infrastructure. To be specific, this affects TCP, UDP,
and raw sockets on both IPv4 and IPv6. I will post a
35 matches
Mail list logo
