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
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 UltraSP
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
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 whi
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 b/drivers/net/smc
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 (co
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
--- a/driv
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
+++ b/drivers/
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
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
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
+++ b/drivers/net/phy/phy_d
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 d2
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 wil
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; i+
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++)
>> +
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
>>>
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 fr
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 405E
[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.
ipc/mqueu
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 bondin
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 l
> 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 PROTECT
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 inet_ehash_bu
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.
25 matches
Mail list logo
