On Fri, 2007-11-02 at 16:35 -0700, Max Asbock wrote:
I built the newest bnx2x code against the net-2.6 kernel and ran a
number of stress tests with netperf and pktgen. I did not encounter
any
errors.
Max
Thanks,
Eliezer
-
To unsubscribe from this list: send the line unsubscribe
The issue shows up reliably when starting the system though some
(re)configuration operations on the network interface makes the issue
disapear.
One way to get the kernel to see the advertisments is to restart the interface
with its vlans or (as below) keeping the interface in promiscuous mode.
David Miller a écrit :
From: Andi Kleen [EMAIL PROTECTED]
Date: Sun, 4 Nov 2007 00:18:14 +0100
On Thursday 01 November 2007 11:16:20 Eric Dumazet wrote:
Some quick comments:
+#if defined(CONFIG_SMP) || defined(CONFIG_PROVE_LOCKING)
+/*
+ * Instead of using one rwlock for each
But I suspect distributions kernels enable CONFIG_HOTPLUG_CPU so
num_possible_cpus() will be NR_CPUS.
Nope, on x86 num_possible_cpus() is derived from BIOS tables these days.
-Andi
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
Andi Kleen a écrit :
But I suspect distributions kernels enable CONFIG_HOTPLUG_CPU so
num_possible_cpus() will be NR_CPUS.
Nope, on x86 num_possible_cpus() is derived from BIOS tables these days.
Good to know, thank you Andi for this clarification.
-
To unsubscribe from this list: send the
Hi,
I've been doing some tests for bonding of 2.6.24-rc1 and noticed some problems.
My first goal was to see how bonding works with IPoIB slaves but I also tried it
with Ethernet.
Basically, what I see is that after a while commands like ifconfig or ip stucks.
I only use sysfs to configure
[NETLINK]: Fix unicast timeouts
Commit ed6dcf4a in the history.git tree broke netlink_unicast timeouts by
moving the schedule_timeout() call to a new function that doesn't propagate
the remaining timeout back to the caller. This means on each retry we start
with the full timeout again.
On Sun, Nov 04, 2007 at 02:37:59PM +1100, Benjamin Herrenschmidt wrote:
On Fri, 2007-11-02 at 11:03 -0500, Olof Johansson wrote:
On Fri, Nov 02, 2007 at 08:14:43AM +0100, Stefan Roese wrote:
This patch adds support for the 405EX to the new EMAC driver. Some as on
AXON, the 405EX handles
fwiw i also brought the TCP_DEFER_ACCEPT problems up the end of last year:
http://www.mail-archive.com/netdev@vger.kernel.org/msg28916.html
it's possible the final message in that thread is how we should define the
behaviour, i haven't tried the TCP_SYNCNT idea though.
-dean
-
To unsubscribe
Eric Dumazet wrote, On 11/04/2007 12:31 PM:
David Miller a écrit :
From: Andi Kleen [EMAIL PROTECTED]
Date: Sun, 4 Nov 2007 00:18:14 +0100
On Thursday 01 November 2007 11:16:20 Eric Dumazet wrote:
...
Also the EHASH_LOCK_SZ == 0 special case is a little strange. Why did
you add that?
He
Jarek Poplawski wrote, On 11/04/2007 06:58 PM:
Eric Dumazet wrote, On 11/04/2007 12:31 PM:
...
+static inline int inet_ehash_locks_alloc(struct inet_hashinfo *hashinfo)
+{
...
+if (sizeof(rwlock_t) != 0) {
...
+for (i = 0; i size; i++)
+
Jarek Poplawski a écrit :
Jarek Poplawski wrote, On 11/04/2007 06:58 PM:
Eric Dumazet wrote, On 11/04/2007 12:31 PM:
...
+static inline int inet_ehash_locks_alloc(struct inet_hashinfo *hashinfo)
+{
...
+ if (sizeof(rwlock_t) != 0) {
...
+ for (i = 0; i size;
From: Andi Kleen [EMAIL PROTECTED]
Date: Sun, 4 Nov 2007 13:26:38 +0100
But I suspect distributions kernels enable CONFIG_HOTPLUG_CPU so
num_possible_cpus() will be NR_CPUS.
Nope, on x86 num_possible_cpus() is derived from BIOS tables these days.
And similarly on SPARC64 is will be set
Add PHY IDs for Marvell 88E1240. It seems to have close enough programming
models to /1112 for basic support at least.
Also clean up whitespace in the ID list a bit.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index
It gets quite verbose to see every single PHY driver being registered
by default.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index c046121..f6e4848 100644
--- a/drivers/net/phy/phy_device.c
+++
Eric Dumazet wrote, On 11/04/2007 10:23 PM:
Jarek Poplawski a écrit :
Jarek Poplawski wrote, On 11/04/2007 06:58 PM:
Eric Dumazet wrote, On 11/04/2007 12:31 PM:
...
+static inline int inet_ehash_locks_alloc(struct inet_hashinfo *hashinfo)
+{
...
+ if (sizeof(rwlock_t) != 0) {
...
+
On Sunday 04 November 2007 22:56:21 David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
This makes a huge different as we have to set NR_CPUS to 4096
in order to handle the cpu numbering of some UltraSPARC-IV
machines.
Really? Hopefully you have a large enough stack then. There
are
If timeout causes the loop to end, a postfix decrement causes its value to
become 4294967295 (unsigned int), not 0.
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index dd18af0..41f3c8f 100644
--- a/drivers/net/smc911x.c
+++
And there was another one...
--
If timeout causes the loop to end, a postfix decrement causes its value to
become 4294967295 (unsigned int), not 0.
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index dd18af0..fac1d2a 100644
---
On Sun, 2007-04-11 at 02:17 +0100, Jarek Poplawski wrote:
So, even if not full ntohl(), some byte moving seems to be
necessary here.
I thinking you were close. I am afraid my brain is congested, even the
esspresso didnt help my thinking.
It could be done with just fshift on the slow path
Darn, another. Sorry for the noise; I also removed a whitespace in this one
--
If timeout causes the loop to end, a postfix decrement causes its value to
become 4294967295 (unsigned int), not 0.
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/drivers/net/smc911x.c
Two related patches from Rumen G. Bogdanovski
to help prevent overcommit on the standby.
On the last two attempts I have managed to send somewhat bogus patches.
So I started from scratch. I tool the original patches, fixed
up what scripts/checkpatch.pl didn't like, then compared the output
to my
From: Rumen G. Bogdanovski [EMAIL PROTECTED]
This patch makes the master daemon to sync the connection when it is about
to close. This makes the connections on the backup to close or timeout
according their state. Before the sync was performed only if the
connection is in ESTABLISHED state
From: Rumen G. Bogdanovski [EMAIL PROTECTED]
This patch fixes the problem with node overload on director fail-over.
Given the scenario: 2 nodes each accepting 3 connections at a time and 2
directors, director failover occurs when the nodes are fully loaded (6
connections to the cluster) in this
From: Andi Kleen [EMAIL PROTECTED]
Date: Mon, 5 Nov 2007 00:01:03 +0100
On Sunday 04 November 2007 22:56:21 David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
This makes a huge different as we have to set NR_CPUS to 4096
in order to handle the cpu numbering of some UltraSPARC-IV
From: David Miller [EMAIL PROTECTED]
Date: Sun, 04 Nov 2007 20:24:54 -0800 (PST)
From: Andi Kleen [EMAIL PROTECTED]
Date: Mon, 5 Nov 2007 00:01:03 +0100
If it's for sparse cpu ids -- x86 handles those with an
translation array.
I would rather not do this, so much assembler code
26 matches
Mail list logo
