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 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 b
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 w
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 ?
I
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 probl
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 clu
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.4
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
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:
stable/7/sys/
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
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 a
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 IPv4
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 see
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
date=200
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 t
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 tim
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 time
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 o
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
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
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: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
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
more
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 more
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, though
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 'boa
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. Odd
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, especially
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 appr
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 thin
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 IPv4
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 m
* 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
> develo
> 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 furth
35 matches
Mail list logo
