On Mon, Feb 19, 2007 at 03:56:23PM -0800, Stephen Hemminger wrote:
Linux 2.6.20-rc4 appears to take 4 microseconds on my P4 3GHz for a
non-blocking UDPv4 recvfrom() call, both on loopback and ethernet.
Linux 2.6.18 on my 64 bit Athlon64 3200+ takes a similar amount of time.
recvfrom
On Fri, Feb 16, 2007 at 08:06:25AM -0800, Ben Greear wrote:
...
Well, I had lockdep and all of the locking debugging I could find
enabled, but
it did not catch this problem..I had to use sysctl -t and manually dig
through the backtraces
to find the deadlock
It may be that lockdep
From: Adrian Bunk [EMAIL PROTECTED]
Date: Tue, 20 Feb 2007 01:07:21 +0100
On Mon, Feb 05, 2007 at 06:01:42PM -0800, David Miller wrote:
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:30:53 -0800
From: Adrian Bunk [EMAIL PROTECTED]
Add proper prototypes for some functions in
From: Noriaki TAKAMIYA [EMAIL PROTECTED]
Date: Tue, 20 Feb 2007 12:24:32 +0900 (JST)
More fix is needed for __xfrm6_bundle_create().
Signed-off-by: Noriaki TAKAMIYA [EMAIL PROTECTED]
Acked-by: Masahide NAKAMURA [EMAIL PROTECTED]
--
John Heffner ha scritto:
Sorry for the confusion. The patch I attached to my message was
compile-tested only.
Well I've read your reply by night and I haven't seen that you attached
a patch. Sorry for that.
Kind regards,
Angelo
-
To unsubscribe from this list: send the line unsubscribe
From: Marcel Holtmann [EMAIL PROTECTED]
Date: Sun, 18 Feb 2007 00:10:52 +0100
here are some patches for the Bluetooth subsystem. All of them are
pending patches that can be finally included since the missing core
functionality has been merged upstream.
...
Please pull from
Hi,
I created a patch that uses watchdog_task but fixes the race condition
that occurred in old the e1000 driver.
I've obtained information about the panic caused by the old e1000 driver
using e1000_watchdog_task. According to the crash dump, the panic was
caused by a timer_list whose contents
On Mon, Feb 19, 2007 at 07:13:07PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Monday 19 February 2007 16:14, Eric Dumazet wrote:
Because O(1) is different of O(log(N)) ?
if N = 2^20, it certainly makes a difference.
Yes, 1% of chains might have a length 10, but yet 99% of the
bert hubert [EMAIL PROTECTED] writes:
Hi people,
I'm trying to save people the cost of buying extra servers by making
PowerDNS (GPL) ever faster, but I've hit a rather fundamental problem.
Linux 2.6.20-rc4 appears to take 4 microseconds on my P4 3GHz for a
non-blocking UDPv4 recvfrom()
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Tue, 20 Feb 2007 12:25:23 +0300
What you miss is the fact, that upper layers of the tree are always in the
cache. So its access cost nothing compared to every time new entry in
the hash table.
It will not be on a real computer spending reasonable
On Tuesday 20 February 2007 10:25, Evgeniy Polyakov wrote:
On Mon, Feb 19, 2007 at 07:13:07PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Monday 19 February 2007 16:14, Eric Dumazet wrote:
Because O(1) is different of O(log(N)) ?
if N = 2^20, it certainly makes a difference.
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 20 Feb 2007 11:04:15 +0100
Using a jenkin's hash permits a better hash distribution for a litle
cpu cost. I will post later a distribution simulation based on the
data gathered from the same real server.
Actually someone (I think it was Evgeniy
On Tue, Feb 20, 2007 at 01:57:45AM -0800, David Miller ([EMAIL PROTECTED])
wrote:
What you miss is the fact, that upper layers of the tree are always in the
cache. So its access cost nothing compared to every time new entry in
the hash table.
It will not be on a real computer spending
On Tue, Feb 20, 2007 at 02:12:09AM -0800, David Miller ([EMAIL PROTECTED])
wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 20 Feb 2007 11:04:15 +0100
Using a jenkin's hash permits a better hash distribution for a litle
cpu cost. I will post later a distribution simulation based on
On Tue, Feb 20, 2007 at 11:04:15AM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
You totally miss the fact that the 1-2-4 MB cache is not available for you at
all. It is filled by User accesses. I dont care about DOS. I care about real
servers, servicing tcp clients. The TCP service/stack
On Tuesday 20 February 2007 11:12, David Miller wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 20 Feb 2007 11:04:15 +0100
Using a jenkin's hash permits a better hash distribution for a litle
cpu cost. I will post later a distribution simulation based on the
data gathered from the
On Tuesday 20 February 2007 11:30, Evgeniy Polyakov wrote:
On Tue, Feb 20, 2007 at 02:12:09AM -0800, David Miller ([EMAIL PROTECTED])
wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 20 Feb 2007 11:04:15 +0100
Using a jenkin's hash permits a better hash distribution for a litle
On Tuesday 20 February 2007 11:44, Evgeniy Polyakov wrote:
On Tue, Feb 20, 2007 at 11:04:15AM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
You totally miss the fact that the 1-2-4 MB cache is not available for
you at all. It is filled by User accesses. I dont care about DOS. I care
about
On Tue, Feb 20, 2007 at 12:10:22PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
Please explain why you choseh = jhash_2words(faddr, laddr, ports);
h ^= h 16;
h ^= h 8;
jhash is very good, no need to try to be smarter, shufling some bytes... and
adding artifacts.
On Tue, Feb 20, 2007 at 12:09:51PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
If we want to optimize tcp, we should reorder fields to reduce number of
cache
lines, not change algos. struct sock fields are currently placed to reduce
holes, while they should be grouped by related fields
On Tuesday 20 February 2007 12:10, Eric Dumazet wrote:
Yep, it happend to be my tests :)
Jenkins hash was slower and had significant artifacts for some usage
cases ended up with extremely long chain length.
One can find more details at
On Tuesday 20 February 2007 12:29, Evgeniy Polyakov wrote:
On Tue, Feb 20, 2007 at 12:09:51PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
If we want to optimize tcp, we should reorder fields to reduce number of
cache lines, not change algos. struct sock fields are currently placed to
On Tue, Feb 20, 2007 at 12:34:59PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
Getting into account that network stack with NAPI schedules several
packets to be queued into socket and all that happens without any
infuence from userspace, trie/tree wins again in that regard that
On Tue, Feb 20, 2007 at 12:30:18PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Tuesday 20 February 2007 12:10, Eric Dumazet wrote:
Yep, it happend to be my tests :)
Jenkins hash was slower and had significant artifacts for some usage
cases ended up with extremely long chain
On Tue, Feb 20, 2007 at 12:25:23PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
And there is _no_ O(1) - O(1) is just a hash entry selection, then you
need to add the whole chain path, which can be long enough.
For example for the length 9 you have 1000 entries - it is exactly size
of
On 2/20/07, David Miller [EMAIL PROTECTED] wrote:
Actually someone (I think it was Evgeniy in fact) made such
comparisons and found in his studies that not only does the current
ehash xor hash function distribute about as well as jenkins, it's
significantly cheaper to calculate :-)
However,
On Tue, Feb 20, 2007 at 07:07:16AM -0800, Michael K. Edwards ([EMAIL
PROTECTED]) wrote:
On 2/20/07, David Miller [EMAIL PROTECTED] wrote:
Actually someone (I think it was Evgeniy in fact) made such
comparisons and found in his studies that not only does the current
ehash xor hash function
In general, TCP code uses sk for struct sock pointer.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_ipv4.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 0ba74bb..f6793b4 100644
---
On 2/20/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Jenkins _does_ have them, I showed tests half a year ago and in this
thread too. Actually _any_ hash has them it is just a matter of time
to find one.
I think you misunderstood me. If you are trying to DoS me from
outside with a hash
On Tue, Feb 20, 2007 at 07:49:11AM -0800, Michael K. Edwards ([EMAIL
PROTECTED]) wrote:
On 2/20/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Jenkins _does_ have them, I showed tests half a year ago and in this
thread too. Actually _any_ hash has them it is just a matter of time
to find one.
On Tuesday 20 February 2007 16:49, Michael K. Edwards wrote:
On 2/20/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Jenkins _does_ have them, I showed tests half a year ago and in this
thread too. Actually _any_ hash has them it is just a matter of time
to find one.
I think you
On Tuesday 20 February 2007 16:59, Evgeniy Polyakov wrote:
On Tue, Feb 20, 2007 at 07:49:11AM -0800, Michael K. Edwards
([EMAIL PROTECTED]) wrote:
On 2/20/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Jenkins _does_ have them, I showed tests half a year ago and in this
thread too. Actually
Kenzo Iwami wrote:
Hi,
I created a patch that uses watchdog_task but fixes the race condition
that occurred in old the e1000 driver.
I've obtained information about the panic caused by the old e1000 driver
using e1000_watchdog_task. According to the crash dump, the panic was
caused by a
Stephen Hemminger wrote:
If a workqueue function that needs RTNL is running when skge_down
is called then a deadlock is possible. Fix by only clearing the timer,
and handling the flush_scheduled_work on removal. This work queue is only
ever used for the old fiber based boards.
Signed-off-by:
Francois Romieu wrote:
flush_scheduled_work() in net_device-close has a slight tendency
to deadlock with tasks on the workqueue that hold RTNL.
rtl8169_close/down simply need the recovery tasks to not meddle
with the hardware while the device is going down.
Signed-off-by: Francois Romieu
On Tue, Feb 20, 2007 at 05:08:12PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
Adding XOR with constant value does not change distribution.
Variable salt will end up with differnet buckets for the same flow.
It is forbidden - it is not the situation created for passwd/des decades
ago.
Ayaz Abdulla wrote:
The napi poll routine was missing the call to the optimized rx process
routine. This patch adds the missing call for the optimized path.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
---
Ayaz Abdulla wrote:
There seems to be an issue when both MSI-X is enabled and NAPI is
configured. This patch disables MSI-X until the issue is root caused.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
ACK patches 2-3
Will await resend of entire patch series, after patch #1 is updated
-
On Tuesday 20 February 2007 17:20, Evgeniy Polyakov wrote:
On Tue, Feb 20, 2007 at 05:08:12PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
Adding XOR with constant value does not change distribution.
Variable salt will end up with differnet buckets for the same flow.
It is forbidden -
On Tue, Feb 20, 2007 at 05:38:19PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
It is secrecy, not security - attacker will check the source and find
where constant per-boot value is added and recalculate attack vector -
we all were college students, it would be even more fun to crack.
On Tue, Feb 20, 2007 at 07:59:07PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
I've attached source code and running script.
$ ./run.sh
Yep, of course.
--
Evgeniy Polyakov
#include stdlib.h
#include stdio.h
#include errno.h
#include string.h
#include unistd.h
#include time.h
On Tuesday 20 February 2007 17:59, Evgeniy Polyakov wrote:
On Tue, Feb 20, 2007 at 05:38:19PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
It is secrecy, not security - attacker will check the source and find
where constant per-boot value is added and recalculate attack vector -
we
Hi,
This patch enables dynamic adding / removing of ehea ports
by DLPAR tool. It creates a subnode for each logical port
in the sysfs. Furthermore, it has attributes that show
the associated eth device, the logical port number, and the
path in the open firmware device tree.
Logical ports can be
On Tuesday 20 February 2007 18:05, Evgeniy Polyakov wrote:
On Tue, Feb 20, 2007 at 07:59:07PM +0300, Evgeniy Polyakov
([EMAIL PROTECTED]) wrote:
I've attached source code and running script.
$ ./run.sh
Yep, of course.
Your test program is just bogus. artefacts come from your 'random'
On Tue, Feb 20, 2007 at 06:53:59PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
I've attached source code and running script.
$ ./run.sh
Yep, of course.
Your test program is just bogus. artefacts come from your 'random' generator.
You just increment a counter, assuming the key
On Tue, Feb 20, 2007 at 08:55:50PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
Here is a dump of possible addr/port pairs which end up badly
distributed:
8e363a50:27652 - c0a80001:20480
8e363a50:35529 - c0a80001:20480
8e363a50:40919 - c0a80001:20480
8e363a50:46720 - c0a80001:20480
Ralf Baechle wrote:
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
applied
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
The napi poll routine was missing the call to the optimized rx process
routine. This patch adds the missing call for the optimized path.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
--- orig/drivers/net/forcedeth.c2007-02-20 03:17:21.0 -0500
+++ new/drivers/net/forcedeth.c
There seems to be an issue when both MSI-X is enabled and NAPI is
configured. This patch disables MSI-X until the issue is root caused.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
--- orig/drivers/net/forcedeth.c2007-02-20 03:29:04.0 -0500
+++ new/drivers/net/forcedeth.c
This patch removes checksum offload feature in mcp65 chipsets as they
are not supported in hw.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
--- orig/drivers/net/forcedeth.c2007-02-20 03:30:16.0 -0500
+++ new/drivers/net/forcedeth.c 2007-02-20 03:30:29.0 -0500
@@
Dave, Alan, Jon,
Max Krasnyansky wrote:
TIPC code is a bit inconsistent in masking out upper bits of various
message fields when packing them into the headers. For the most part
things seem to be ok but we happened to hit a corner case in our labs
when broadcast counter reached certain value
Max Krasnyansky wrote:
Fixes an oops in the non-blocking mode.
Signed-off-by: Max Krasnyansky [EMAIL PROTECTED]
---
net/tipc/socket.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 2a6a5a6..767f791 100644
---
On Tuesday 20 February 2007 19:00, Evgeniy Polyakov wrote:
As you can see, jhash has problems in a really trivial case of 2^16,
which in local lan is a disaster. The only reason jenkins hash is good
for hashing purposes is that is it more complex than xor one, and thus
it is harder to find a
You need the flow control fix and the tx_timeout fix posted for 2.6.20 (stable)
and current git tree.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 02, 2007 at 11:28:46AM -0800, Stephen Hemminger wrote:
This patch does the Marvell errata before auto negotiation
(from drivers/phy/marvell.c). The Yukon II chips have an internal
version of the same PHY, so perhaps this errata is necessary for them
as well.
For test only, but
On Tue, Feb 20, 2007 at 07:55:15PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Tuesday 20 February 2007 19:00, Evgeniy Polyakov wrote:
As you can see, jhash has problems in a really trivial case of 2^16,
which in local lan is a disaster. The only reason jenkins hash is good
for
On 2/20/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
And here are another ones which produce the same hash value.
Of course searching for pair for jhash('jhash is broken')
will require more steps, but it is doable.
That means that if attacker has a full control over one host, it can
create a
On Tuesday 20 February 2007 20:06, Evgeniy Polyakov wrote:
I added to my 'simulator_plugged_on_real_server' the average cost
calculation, relative to number of cache line per lookup.
ehash_size=2^20
xor hash :
386290 sockets, Avg lookup cost=3.2604 cache lines/lookup
393667 sockets,
All right, Eric, you and me so clevvah, let's embarrass our own selves
designing this thing in public instead of picking on poor Evgeniy.
Which would you rather RCU, a 2-left hash or a splay tree? 2-left
hash gets you excellent occupation fraction before the first real
collision, so you can be
On Tue, Feb 20, 2007 at 11:13:50AM -0800, Michael K. Edwards ([EMAIL
PROTECTED]) wrote:
On 2/20/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
And here are another ones which produce the same hash value.
Of course searching for pair for jhash('jhash is broken')
will require more steps, but it
On Tue, Feb 20, 2007 at 08:17:31PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
I shown your test was bogus. All your claims are just bogus.
I claim your 'true random data' is a joke. rand() in your program is a pure
joke.
Care to reread your mail about your true random case with hash
On Mon, 19 Feb 2007 23:15:02 -0800
Chris Wedgwood [EMAIL PROTECTED] wrote:
On Sun, Feb 11, 2007 at 04:57:55PM +0200, Matti Aarnio wrote:
With the skge driver there seems to be some sort of problem to work
in a system with memory above the 4 GB of PCI address space.
The chipset
On 2/20/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
How I like personal insults - it is always fun to read about myself from
people who never knew me :)
On this occasion, I did not set out to insult you. I set out to
suggest an explanation for why cooler and grayer heads than mine are
not
On 2/20/07, Michael K. Edwards [EMAIL PROTECTED] wrote:
Correct. That's called a weak hash, and Jenkins is known to be a
thoroughly weak hash. That's why you never, ever use it without a
salt, and you don't let an attacker inspect the hash output either.
Weak in a cryptographic sense, of
On Mon, Feb 19, 2007 at 06:59:16PM -0500, Lennart Sorensen wrote:
I am also noticing the receive error count going up, and the source is
this code:
if (status 0x01) /* Only count a general error at the */
lp-stats.rx_errors++; /* end of a packet. */
It appears this means I
From: Joe Jin [EMAIL PROTECTED]
Date: Fri, 9 Feb 2007 17:34:24 +0800
This patch for adjust inet6_exit() to inverse sequence to inet6_init().
At ipv6_init, it first create proc_root/net/dev_snmp6 entry by call
ipv6_misc_proc_init(), then call addrconf_init() to create the corresponding
Adrian Bunk [EMAIL PROTECTED] wrote:
} /* end rxrpc_create_call() */
+EXPORT_SYMBOL(rxrpc_create_call);
A blank line between the end of the function and the EXPORT_SYMBOL please.
David
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Tue, Feb 20, 2007 at 10:59:46AM +, David Howells wrote:
Adrian Bunk [EMAIL PROTECTED] wrote:
} /* end rxrpc_create_call() */
+EXPORT_SYMBOL(rxrpc_create_call);
A blank line between the end of the function and the EXPORT_SYMBOL please.
Please discuss this with Andrew [1] and tell
From: [EMAIL PROTECTED] (Lennart Sorensen)
Subject: Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
Date: Mon, 19 Feb 2007 19:02:31 -0500
On Tue, Feb 20, 2007 at 08:56:39AM +0900, takada wrote:
/proc/cpuinfo with MediaGXm :
:
flags : fpu tsc msr cx8 cmov mmx cxmmx
bogomips
From: Dale Farnsworth [EMAIL PROTECTED]
Remove the use of CONFIG_MV643XX_ETH_[012] variables on most
platforms. Instead, platform-specific code enables the ports
supported by the hardware. After this patch, these config
variables are only used in arch/ppc, so also move them from
On Tue, Feb 20, 2007 at 05:15:20AM -0700, Dale Farnsworth wrote:
From: Dale Farnsworth [EMAIL PROTECTED]
Remove the use of CONFIG_MV643XX_ETH_[012] variables on most
platforms. Instead, platform-specific code enables the ports
supported by the hardware. After this patch, these config
On Tue, Feb 20, 2007 at 08:34:13PM +0900, takada wrote:
I posted with 2.6.20 + enabled X86_OOSTORE.
The clflush sze line is in /proc/cpuinfo. but clfush is not in flags line.
BTW, can we use WBINVD instruction? I tested compile only.
Do you know a method to change dynamically without #ifdef
On 2/8/07, Greg KH [EMAIL PROTECTED] wrote:
And it should also alow for proper power management functionality, using
the changes that Linus put into the driver core about 8 months ago.
Don't worry, I have input patches queued up next for you Dmitry :)
Greg,
Could you please forward me
Mark Brown wrote:
This patch provides code paths which allow the natsemi driver to use the
external MII port on the chip but ignore any PHYs that may be attached to it.
The link state will be left as it was when the driver started and can be
configured via ethtool. Any PHYs that are present can
applied to #vioc branch of netdev-2.6.git, which will be merged into
#ALL for a period of review and testing.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 20, 2007 at 11:50:13AM +0100, Andi Kleen wrote:
P4s are pretty slow at taking locks (or rather doing atomical operations)
and there are several of them in this path. You could try it with a UP
kernel. Actually hotunplugging the other virtual CPU should be sufficient
with recent
Dale Farnsworth wrote:
From: Dale Farnsworth [EMAIL PROTECTED]
Remove the use of CONFIG_MV643XX_ETH_[012] variables on most
platforms. Instead, platform-specific code enables the ports
supported by the hardware. After this patch, these config
variables are only used in arch/ppc, so also move
On Tue, Feb 20, 2007 at 05:27:14PM +0100, bert hubert ([EMAIL PROTECTED]) wrote:
I've done so, with some interesting results. Source on
http://ds9a.nl/tmp/recvtimings.c - be careful to adjust the '3000' divider
to your CPU frequency if you care about absolute numbers!
These are two groups,
On Tuesday 20 February 2007 17:27, bert hubert wrote:
On Tue, Feb 20, 2007 at 11:50:13AM +0100, Andi Kleen wrote:
P4s are pretty slow at taking locks (or rather doing atomical operations)
and there are several of them in this path. You could try it with a UP
kernel. Actually hotunplugging
On Tue, Feb 20, 2007 at 11:27:30AM -0500, Jeff Garzik wrote:
It was a mis-feature that the supported ports were ever user-selectable.
Which ports the hardware supports should be specified by platform-specific
code, not by the user.
arch/mips/momentum/jaguar_atx/platform.c | 21
On Tue, Feb 20, 2007 at 07:41:25PM +0300, Evgeniy Polyakov wrote:
It can be recvfrom only problem - syscall overhead on my p4 (core duo,
debian testing) is bout 300 usec - to test I ran read('dev/zero', data,
0) in a loop.
nsec I assume?
The usec numbers for read(fd, c, 0) where fd is
On Tue, Feb 20, 2007 at 06:02:32PM +0100, bert hubert ([EMAIL PROTECTED]) wrote:
On Tue, Feb 20, 2007 at 07:41:25PM +0300, Evgeniy Polyakov wrote:
It can be recvfrom only problem - syscall overhead on my p4 (core duo,
debian testing) is bout 300 usec - to test I ran read('dev/zero', data,
On Tue, Feb 20, 2007 at 08:11:20PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
I would try it today - but it is a bit late in Moscow already - and
there are some things to complete yet. So, tomorrow I will create a patch
and run it, but I seriously doubt that there is _that_ high
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/8139too.c | 40 ++---
drivers/net/hamradio/baycom_epp.c | 13 +--
On Tue, Feb 20, 2007 at 07:41:25PM +0300, Evgeniy Polyakov wrote:
On Tue, Feb 20, 2007 at 05:27:14PM +0100, bert hubert ([EMAIL PROTECTED])
wrote:
I've done so, with some interesting results. Source on
http://ds9a.nl/tmp/recvtimings.c - be careful to adjust the '3000' divider
to your CPU
On Tue, Feb 20, 2007 at 09:48:59PM +0300, Evgeniy Polyakov wrote:
Likely first overhead related to cache population or gamma-ray radiation.
If it happens only one (it does in my test), then everything is ok I
think. Bert, how frequently you get that long recvfrom()?
I have plotted the average
On Tue, Feb 20, 2007 at 08:33:20PM +0100, bert hubert wrote:
I'm investigating this further for other system calls. It might be that my
measurements are off, but it appears even a slight delay between calls
incurs a large penalty.
Make sure your system is idle. Userspace bloat means that
On Tue, Feb 20, 2007 at 02:40:40PM -0500, Benjamin LaHaise wrote:
Make sure your system is idle. Userspace bloat means that *lots* of idle
activity occurs in between timer ticks on recent distributions -- all those
You hit the nail on the head. I had previously measured with X shut down,
On Tue, 20 Feb 2007 21:45:05 +0100
bert hubert [EMAIL PROTECTED] wrote:
On Tue, Feb 20, 2007 at 02:40:40PM -0500, Benjamin LaHaise wrote:
Make sure your system is idle. Userspace bloat means that *lots* of idle
activity occurs in between timer ticks on recent distributions -- all those
On Tue, 20 Feb 2007 01:02:14 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
On Tue, Nov 28, 2006 at 11:47:19PM -0800, Andrew Morton wrote:
On Wed, 29 Nov 2006 08:36:09 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
On Mon, Nov 27, 2006 at 10:24:55AM -0800, Stephen Hemminger wrote:
On Fri,
I measure a huge slope, however. Starting at 1usec for back-to-back system
calls, it rises to 2usec after interleaving calls with a count to 20
million.
4usec is hit after 110 million.
The graph, with semi-scientific error-bars is on
http://ds9a.nl/tmp/recvfrom-usec-vs-wait.png
The code to
On Tue, Feb 20, 2007 at 01:31:32PM -0800, Stephen Hemminger wrote:
On Tue, 20 Feb 2007 01:02:14 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
On Tue, Nov 28, 2006 at 11:47:19PM -0800, Andrew Morton wrote:
On Wed, 29 Nov 2006 08:36:09 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
On
Jeff,
Please apply and forward upstream this patch series.
This is the followup to the collision of patches that
landed on your doorstep last week. It rolls up the
patches from Jens and Kou.
--linas
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
On Tue, Feb 20, 2007 at 02:02:00PM -0800, Rick Jones wrote:
The slope appears to be flattening-out the farther out to the right it
goes. Perhaps that is the length of time it takes to take all the
requisite cache misses.
The rate of flattening out appears to correlate with the number of
I'm trying to figure out which processes have the most impact, I had already
killed anything non-essential. But that still leaves 140 pids.
btw if you have systemtap on your system you can see who is doing evil
with
http://www.fenrus.org/cstop.stp
also.. running vmstat 3 and looking at the
From: Jens Osterkamp [EMAIL PROTECTED]
This version moves the medium variable to the card specific structure and
changes the GMII_* to BCM54XX_* #defines.
This patch adds improved version of enable_fiber for both the 5421 and
the 5461 phy. It is now possible to specify with these wether you
As of 2.6.20-git4, the spider_net driver does not compile.
This appears to be due to some archaic usage involving kobjects.
It also fixes a nasty double-free during ifdown of the interface.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: Jens Osterkamp [EMAIL PROTECTED]
Cc: Kou Ishizaki
From: Kou Ishizaki [EMAIL PROTECTED]
Add auto negotiation support for Celleb.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 176 ++-
drivers/net/spider_net.h | 10 ++
From: Kou Ishizaki [EMAIL PROTECTED]
This patch moves calling init_firmware() from spider_net_probe() to
spider_net_open() so as to use the driver by built-in.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 247
From: Kou Ishizaki [EMAIL PROTECTED]
This patch adds or changes some HW specific settings for spider_net on
Celleb.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/Kconfig |2 +-
drivers/net/spider_net.c |8 +++-
1 - 100 of 128 matches
Mail list logo
