On Wed, Mar 08, 2006 at 04:32:58PM -0800, Andrew Morton wrote:
Ravikiran G Thirumalai [EMAIL PROTECTED] wrote:
On Wed, Mar 08, 2006 at 03:43:21PM -0800, Andrew Morton wrote:
Benjamin LaHaise [EMAIL PROTECTED] wrote:
I think it may make more sense to simply convert local_t into a
On Thu, Mar 09, 2006 at 07:14:26PM +1100, Nick Piggin wrote:
Ravikiran G Thirumalai wrote:
Here's a patch making x86_64 local_t to 64 bits like other 64 bit arches.
This keeps local_t unsigned long. (We can change it to signed value
along with other arches later in one go I guess)
Ravikiran G Thirumalai wrote:
On Thu, Mar 09, 2006 at 07:14:26PM +1100, Nick Piggin wrote:
Ravikiran G Thirumalai wrote:
Here's a patch making x86_64 local_t to 64 bits like other 64 bit arches.
This keeps local_t unsigned long. (We can change it to signed value
along with other arches
From: Dave Jones [EMAIL PROTECTED]
Date: Wed, 8 Mar 2006 22:50:00 -0500
We're leaking an skb in a failure path in this function.
Coverity #632
Signed-off-by: Dave Jones [EMAIL PROTECTED]
I'll apply this, thanks a lot Dave.
-
To unsubscribe from this list: send the line unsubscribe netdev in
From: Benjamin LaHaise [EMAIL PROTECTED]
Date: Tue, 7 Mar 2006 13:19:10 -0800
At this point I'd just like to stir up some discussion, so please
comment away with any ideas and concerns.
I don't like this :-)
Not because you put x86_64 stuff in there, I know we can abstract
all of that stuff
From: Rick Jones [EMAIL PROTECTED]
Date: Tue, 7 Mar 2006 13:50:59 -0800 (PST)
Since such stacks are rapidly fading into the mists of time, and since
it is perfectly legal and not entirely uncommon to use a TCP window up
to 65535 bytes when window scaling is not in use, we want to allow an
On Wed, 8 Mar 2006, Francois Romieu wrote:
Geert Uytterhoeven [EMAIL PROTECTED] :
On Tue, 7 Mar 2006, Ralf Baechle wrote:
[...]
I'm just not convinced of having such a workaround as a build option.
The average person building a a kernel will probably not know if the
option needs to be
On Thu, 09 Mar 2006 11:39:06 +0800, Zhu Yi wrote:
On Wed, 2006-03-08 at 13:23 +0100, Jiri Benc wrote:
I don't think it's a good idea to misuse 'iwconfig sens' for this.
This has been discussed on ipw2100-devel ML. Jean will change the manual
for 'iwconfig sens'.
On Thursday 09 March 2006 09:06, Ravikiran G Thirumalai wrote:
On Wed, Mar 08, 2006 at 04:32:58PM -0800, Andrew Morton wrote:
Ravikiran G Thirumalai [EMAIL PROTECTED] wrote:
On Wed, Mar 08, 2006 at 03:43:21PM -0800, Andrew Morton wrote:
Benjamin LaHaise [EMAIL PROTECTED] wrote:
Hello Stephen,
2) How to setup the same environment (for non-java savvy people) with
freely available software (Sun JDK okay). I can figure out how to get JDK
IDEA is available for download at http://www.jetbrains.com/idea
You can use either evaluation license or download an EA build and use
Andi Kleen wrote:
What happens if there are multiple producers? Could happen when
this would be used for the socket queue.
Then just serialize the producers against each other or try to decouple more.
In reality every communication can be modelled
with a simple unidirectional pipe or set of
Thanks for the clarification of the usage model. While our needs are
certainly much less complex,
it is useful to know the range of options.
There are no hard rules on what you need to be multicasting and as an
example you could send periodic(aka time based) samples from the kernel
on a
Just to clarify this should be reproducable with any Java Debug tool
(IntelliJ, Eclipse, etc) The slow down increases with the scope of the
current Frame. If you have a simple scope of say 5 basic objects then
things are slow but liveable. If you have a large scope of say 22
objects several of
Balbir Singh wrote:
snip
Hello, Jamal,
Please find the latest version of the patch for review. The genetlink
code has been updated as per your review comments. The changelog is provided
below
1. Eliminated TASKSTATS_CMD_LISTEN and TASKSTATS_CMD_IGNORE
2. Provide generic functions called
I was hoping someone might have some ideas on what might have happened
with the following oops/BUG(). This is on an embedded PPC running
2.6.16-rc5. From the description I got from my coworker who say this, he
was doing NFS on the system and at the time the oops occured his desktop
linux box
On Wed, 08 Mar 2006 23:29:48 -0800 (PST)
David S. Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 08 Mar 2006 23:24:22 -0800
I have gotten massive strace's and the java VM is:
1) Turning on TCP_NODELAY
2) Sending small packets.
Java is
After several days of operation of Netgear MA311 card, the card becomes
to seek improperly and needs reset. This patch tries to reset the card
when this situation occurs.
Mar 9 06:45:16 berkeley kernel: wlan0: Error -5 writing packet to BAP
Mar 9 06:45:16 berkeley kernel: hermes @ f992a000:
On Thu, Mar 09, 2006 at 01:18:26PM +0300, Evgeniy Polyakov wrote:
Ok, I hacked quite a bit in the patch, but I think nothing major was
changed, basically patch rejects.
And I'm now unable to bind to 0.0.0.0 address, i.e. bind() does not
fail, but all connections are refused.
Bind to machine's
Benjamin LaHaise a écrit :
Hello again,
This patch introduces the use of rcu for the ipv4 established connections
hashtable, as well as the timewait table since they are closely intertwined.
This removes 4 atomic operations per packet from the tcp_v4_rcv codepath,
which helps quite a bit
Just out of curiosity was the window size changed in 2.6.15? Just
trying to get an idea of what might have changed in 2.6.15 that
triggered this. (In 2.6.14 and 2.4.27 things run very fast)
On 3/9/06, Stephen Hemminger [EMAIL PROTECTED] wrote:
On Wed, 08 Mar 2006 23:29:48 -0800 (PST)
David S.
On a second thought, do you think we still need one rwlock per hash chain ?
TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
On this x86_64 machine, we 'waste' 8 MB of ram for those rwlocks.
With RCU, we touch these rwlocks only on TCP connection
creation/deletion,
On Thu, Mar 09, 2006 at 09:43:00AM -0800, Benjamin LaHaise ([EMAIL PROTECTED])
wrote:
On Thu, Mar 09, 2006 at 01:18:26PM +0300, Evgeniy Polyakov wrote:
Ok, I hacked quite a bit in the patch, but I think nothing major was
changed, basically patch rejects.
And I'm now unable to bind to
Completely untested, not entirely sure it compiles. For whatever
reason, softmac is sending custom events to userspace already, but it
should _really_ be sending the right WEXT events instead. Comments? If
this looks good, please apply it.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
On Thu, Mar 09, 2006 at 07:41:08PM +1100, Nick Piggin wrote:
Considering that local_t has been broken so that basically nobody
is using it, now is a great time to rethink the types before it
gets fixed and people start using it.
I'm starting to get more concerned as the per-cpu changes that
Dan Williams wrote :
Completely untested, not entirely sure it compiles. For whatever
reason, softmac is sending custom events to userspace already, but it
should _really_ be sending the right WEXT events instead. Comments? If
this looks good, please apply it.
Good catch ! Thanks
--- linux-2.6-2.6.15/net/ipv4/tcp_output.c.orig 2006-01-02 19:21:10.0
-0800
+++ linux-2.6-2.6.15/net/ipv4/tcp_output.c 2006-03-09 10:41:46.0
-0800
@@ -45,6 +45,11 @@
/* People can turn this off for buggy TCP's found in printers etc. */
int sysctl_tcp_retrans_collapse = 1;
Ok, I've heard your arguments, let's allow full 16-bit
windows by default in 2.6.17, but please pick a better
name for the sysctl knob :-) How about something like
tcp_workaround_signed_windows?
So make the naming change, and allow full 16-bit windows
by default, and I'll apply this patch.
Rick Jones a écrit :
On a second thought, do you think we still need one rwlock per hash
chain ?
TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
On this x86_64 machine, we 'waste' 8 MB of ram for those rwlocks.
With RCU, we touch these rwlocks only on TCP
On Thu, 9 Mar 2006 12:29:08 -0600
Eric Molitor [EMAIL PROTECTED] wrote:
Just out of curiosity was the window size changed in 2.6.15? Just
trying to get an idea of what might have changed in 2.6.15 that
triggered this. (In 2.6.14 and 2.4.27 things run very fast)
No, window size hasn't changed,
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Thu, 9 Mar 2006 08:33:15 -0800
A possible solution would be to set cwnd bigger for loopback.
If there was a clean way to know that connection was over loopback,
then doing something in tcp_init_metrics() to set INIT_CWND
if
Jean Tourrilhes wrote:
Dan Williams wrote :
Completely untested, not entirely sure it compiles. For whatever
reason, softmac is sending custom events to userspace already, but it
should _really_ be sending the right WEXT events instead. Comments? If
this looks good, please apply it.
Completely untested, not entirely sure it compiles. For whatever
reason, softmac is sending custom events to userspace already, but it
should _really_ be sending the right WEXT events instead. Comments? If
this looks good, please apply it.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
Dan Williams wrote:
Completely untested, not entirely sure it compiles. For whatever
reason, softmac is sending custom events to userspace already, but it
should _really_ be sending the right WEXT events instead. Comments? If
this looks good, please apply it.
Signed-off-by: Dan Williams
On Thu, Mar 09, 2006 at 07:25:25PM +0100, Eric Dumazet wrote:
On a second thought, do you think we still need one rwlock per hash chain ?
TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
On this x86_64 machine, we 'waste' 8 MB of ram for those rwlocks.
With RCU, we
From: Benjamin LaHaise [EMAIL PROTECTED]
Date: Thu, 9 Mar 2006 12:50:44 -0800
Hrm, maybe use cmpxchg? That gets rid of the lock and automatically
provides us with hashed spinlocks on archs without a cmpxchg
implementation.
I don't think we even need to go there, here's why.
Once we have RCU
From: Eric Dumazet [EMAIL PROTECTED]
Date: Thu, 09 Mar 2006 20:32:16 +0100
#define PTRS_PER_CACHELINE ((L1_CACHE_BYTES - sizeof(rwlock_t))/sizeof(struct
hlist_head))
struct hash_agg_bucket {
rwlock_t wlock;
struct hlist_head chains[PTRS_PER_CACHELINE];
};
A division by a
I did open up a bug with SUN about this. It looks like most clients
dont set TCP_NODELAY on debug sockets but the JDK itself has
TCP_NODELAY hardcoded.
In the meantime is there a way to set or disable Appropriate Byte
Counting on a per interface basis? (I know that its a protocal but the
abiltiy
On Thu, 9 Mar 2006 15:13:39 -0600
Eric Molitor [EMAIL PROTECTED] wrote:
I did open up a bug with SUN about this. It looks like most clients
dont set TCP_NODELAY on debug sockets but the JDK itself has
TCP_NODELAY hardcoded.
In the meantime is there a way to set or disable Appropriate Byte
On Thu, 2006-03-09 at 14:36 -0600, Larry Finger wrote:
Dan Williams wrote:
Completely untested, not entirely sure it compiles. For whatever
reason, softmac is sending custom events to userspace already, but it
should _really_ be sending the right WEXT events instead. Comments? If
this
On Thu, Mar 09, 2006 at 01:12:20PM -0800, David S. Miller wrote:
Once we have RCU in place for the TCP hash tables, we have the chance
to code up dynamically sized hash tables. With the current locking,
this is basically impossible, with RCU it can be done.
Nice!
So Ben can you work to
* Andrew Morton [EMAIL PROTECTED] [060309 12:19]:
Begin forwarded message:
Date: Thu, 9 Mar 2006 01:24:06 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6197] New: unregister_netdevice: waiting for ppp9
to become free. Usage count = 658
From: Baruch Even [EMAIL PROTECTED]
Date: Thu, 9 Mar 2006 23:56:39 +0200
We need to remove all references to the device when we receive the
NETDEV_UNREGISTER notification.
Signed-off-by: Baruch Even [EMAIL PROTECTED]
Good spotting Baruch. Once this gets a positive test result
I'll apply
Jiri Benc wrote :
On Thu, 09 Mar 2006 11:39:06 +0800, Zhu Yi wrote:
On Wed, 2006-03-08 at 13:23 +0100, Jiri Benc wrote:
I don't think it's a good idea to misuse 'iwconfig sens' for this.
This has been discussed on ipw2100-devel ML. Jean will change the manual
for 'iwconfig sens'.
Stephen Hemminger [EMAIL PROTECTED] :
On Thu, 9 Mar 2006 00:06:33 +0100
Francois Romieu [EMAIL PROTECTED] wrote:
[...]
So instead of #1..#6 from 07/03/2006, #1..#3 from 08/03/2003
which actually cover (with minor differences) #4..#6 from 07/03/2006
should be pushed ?
Right.
Done.
Geert Uytterhoeven [EMAIL PROTECTED] :
[...]
So when compiling for Cobalt, we work around the hardware bug, while for other
platforms, we just disable MWI?
Wouldn't it be possible to always (I mean, when a rev 65 chip is detected)
work around the bug?
Of course it is possible but it is not
This patch is changes the initial TCP congestion window for connections that
are over the loopback device. This gives better for performance for applications
that do lots of small writes. It might also help for idiotic benchmarks.
See: http://bugzilla.kernel.org/show_bug.cgi?id=6177
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Thu, 9 Mar 2006 14:56:43 -0800
This patch is changes the initial TCP congestion window for connections that
are over the loopback device. This gives better for performance for
applications
that do lots of small writes. It might also help for
The Coverity checker spotted this dead code (note that (clock_ctrl == 7)
is already handled above).
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.16-rc5-mm3-full/drivers/net/tg3.c.old 2006-03-09
23:25:25.0 +0100
+++ linux-2.6.16-rc5-mm3-full/drivers/net/tg3.c
The Coverity checker noted that the call to prism2_hw_reset() was dead
code.
Does this patch change the code to what was intended?
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.16-rc5-mm3-full/drivers/net/wireless/hostap/hostap_hw.c.old
2006-03-09 23:28:30.0 +0100
On Thu, 09 Mar 2006 15:06:22 -0800 (PST)
David S. Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Thu, 9 Mar 2006 14:56:43 -0800
This patch is changes the initial TCP congestion window for connections that
are over the loopback device. This gives better for
From: Benjamin LaHaise [EMAIL PROTECTED]
Date: Thu, 9 Mar 2006 13:35:16 -0800
On Thu, Mar 09, 2006 at 01:12:20PM -0800, David S. Miller wrote:
So Ben can you work to figure out what the bind(0.0.0.0)
problem was? Once that is fully resolved, I think I'll apply
your RCU patch to
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Thu, 9 Mar 2006 15:11:47 -0800
Then the dst would get changed, no breakage.
Not with a TC action rewrite on input, that would happen after
loopback does the netif_rx().
Interface specific hard-coded metrics are wrong from every single
possible
I had to do some minor fixups, and kill some trailing whitespace
added by this patch, but looks good, applied.
Thanks a lot Rick.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Adrian Bunk [EMAIL PROTECTED]
Date: Fri, 10 Mar 2006 00:06:50 +0100
The Coverity checker spotted this dead code (note that (clock_ctrl == 7)
is already handled above).
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Applied, thanks Adrian.
-
To unsubscribe from this list: send the line
The Coverity checker spotted these two unused variables.
Please check whether this patch is correct or whether they should be
used.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/chelsio/espi.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
---
From: Xiaolan Zhang [EMAIL PROTECTED]
Date: Wed, 8 Mar 2006 22:02:31 -0500
I am working on a separate patch for Unix datagram, instead of mixing the
two into one patch.
James, is this Ok with you?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 06 Mar 2006 14:20:06 +0100
Sorry, thats just as broken as before. Better patch attached.
Applied, thanks Patrick.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo
David S. Miller wrote:
I had to do some minor fixups, and kill some trailing whitespace
added by this patch, but looks good, applied.
Thanks a lot Rick.
You're welcome. If the fixups were related to things I may have botched
in the patch process, please let me know so I might be able to
From: Rick Jones [EMAIL PROTECTED]
Date: Thu, 09 Mar 2006 15:34:33 -0800
David S. Miller wrote:
I had to do some minor fixups, and kill some trailing whitespace
added by this patch, but looks good, applied.
Thanks a lot Rick.
You're welcome. If the fixups were related to things I
From: Benjamin LaHaise [EMAIL PROTECTED]
Date: Tue, 7 Mar 2006 14:59:10 -0800
The patch below merges the use of the wait queue lock and socket spinlock
into one. This gains us ~100-150Mbit/s on netperf, mostly due to the fact
that because we know how the spinlock is used, we can avoid the
David S. Miller [EMAIL PROTECTED] wrote:
Like Sun is going to give me the source?...
And if Sun doesn't support their userland products well that is
somehow the Linux kernel's problem?
Presumably they tested this on Solaris and it ran OK.
Maybe Solaris (and Windows?) have special-case
This patch is correct, these two variables are unused in this driver. Thanks for
catching this!
Signed-off-by: Scott Bardone [EMAIL PROTECTED]
Adrian Bunk wrote:
The Coverity checker spotted these two unused variables.
Please check whether this patch is correct or whether they should be
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 8 Mar 2006 14:53:11 +0200
What I was trying to figure out was, how can we re-enable the trick
without hurting TSO? Could a solution be to simply look at the frame
size, and call tcp_send_delayed_ack if the frame size is small?
The change
From: Andrew Morton [EMAIL PROTECTED]
Date: Thu, 9 Mar 2006 15:45:05 -0800
Maybe Solaris (and Windows?) have special-case handling for local TCP. It
seems a bit odd to me that loopback would use normal handling for things
like slow-start and congestion, but I'm sure there's a good reason ;)
From: Rick Jones [EMAIL PROTECTED]
Date: Thu, 09 Mar 2006 15:51:14 -0800
Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
of small packets? What happens to it with this ABC stuff going?
X wants the packets to go out immediately, in fact as Jim
Getty's mentioned during
Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
of small packets? What happens to it with this ABC stuff going?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi,
As per request from Stephen, I have enclosed the patch for Unix Datagram
getpeersec.
As always, comments are welcome!
thanks,
Catherine
--
From: [EMAIL PROTECTED]
This patch implements an API whereby an application can determine the
label of its peer's Unix datagram sockets via the
Also X on Linux doesn't use TCP over loopback. It seems to use AF_UNIX.
is this problem only over loopback? or is it just harder to see it over
a real link?
rick
onlist no need for cc
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Thu, 09 Mar 2006 15:54:50 -0800 (PST)
David S. Miller [EMAIL PROTECTED] wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Thu, 09 Mar 2006 15:51:14 -0800
Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
of small packets? What happens to it with this ABC stuff
David S. Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Thu, 09 Mar 2006 15:51:14 -0800
Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
of small packets? What happens to it with this ABC stuff going?
X wants the packets to go out immediately, in fact as Jim
Quoting David S. Miller [EMAIL PROTECTED]:
Description
To improve efficiency (both computer and network) a data receiver
may refrain from sending an ACK for each incoming segment,
according to [RFC1122]. However, an ACK should not be delayed an
inordinate amount of
David S. Miller wrote:
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 8 Mar 2006 14:53:11 +0200
What I was trying to figure out was, how can we re-enable the trick
without hurting TSO? Could a solution be to simply look at the frame
size, and call tcp_send_delayed_ack if the frame size
On Thu, Mar 09, 2006 at 10:06:29AM -0600, Kumar Gala wrote:
I was hoping someone might have some ideas on what might have happened
with the following oops/BUG(). This is on an embedded PPC running
2.6.16-rc5. From the description I got from my coworker who say this, he
was doing NFS on
Quoting r. Michael S. Tsirkin [EMAIL PROTECTED]:
Or does __tcp_ack_snd_check delay until we have at least two full sized
segments?
What I'm trying to say, since RFC 2525, 2.13 talks about
every second full-sized segment, so following the code from
__tcp_ack_snd_check, why does it do
On Wednesday 08 March 2006 11:45, Eric Dumazet wrote:
Andi Kleen a écrit :
Can you send tested patches with proper descriptions and signed off lines
please?
-Andi
You are welcome Andi :)
Applied. Please put the description next time into the attachment too
(or better send
Baruch Even [EMAIL PROTECTED] wrote:
+ case NETDEV_UNREGISTER:
case NETDEV_GOING_DOWN:
case NETDEV_DOWN:
/* Find every socket on this device and kill it. */
This brings up the question as to why we need to flush it on
NETDEV_GOING_DOWN and NETDEV_DOWN as
On Thu, 9 Mar 2006, Catherine Zhang wrote:
As per request from Stephen, I have enclosed the patch for Unix Datagram
getpeersec.
As always, comments are welcome!
Looks fine to me.
Acked-by: James Morris [EMAIL PROTECTED]
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this
Its pretty bad on both. But most Java developers debug via localhost.
The slowdowns don't occur on Windows, Solaris, or the unoficial JDK
port to BSD. But I dont know what kernels support ABC. For now I will
see what sun does with the bug report and then chase after IBM. IBM
tends to be more
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Fri, 10 Mar 2006 02:10:31 +0200
But with the change we are discussing, could an ack now be sent even
sooner than we have at least two full sized segments? Or does
__tcp_ack_snd_check delay until we have at least two full sized
segments? David,
From: Rick Jones [EMAIL PROTECTED]
Date: Thu, 09 Mar 2006 16:21:05 -0800
well, there are stacks which do stretch acks (after a fashion) that
make sure when they see packet loss to do the right thing wrt sending
enough acks to allow cwnds to open again in a timely fashion.
Once a loss
From: Eric Molitor [EMAIL PROTECTED]
Date: Thu, 9 Mar 2006 22:39:16 -0600
Its pretty bad on both. But most Java developers debug via localhost.
The slowdowns don't occur on Windows, Solaris, or the unoficial JDK
port to BSD. But I dont know what kernels support ABC. For now I will
see what
81 matches
Mail list logo
