| info | A BUSINESS PROPOSAL FROM MR. SHA NAVAS
Dear Friend,
I am Mr. Sha Navas,Executive Director and Chief Financial Officer of the Bank of India,London Branch 4th floor,63 Queen Victoria Street,London EC4N 4UA.I have a secured business suggestion for you.if interested please contact me at : shanavasindia09@gmail.com. Regards,Mr. Sha Navas.
--
| Oct 24, 1:02 pm 2009 |
| Dominik Brodowski |
| Oct 24, 12:43 pm 2009 |
| Dominik Brodowski | [RFC] more PCMCIA cleanup patches for 2.6.33
Hej,
In addition to the patches already submitted as RFC on Oct 19th, I'm
interested in your input to this patch series. They'll be sent to the
PCMCIA list shortly, with CC to other lists if deemed appropriate. If
all goes well, I'll ask Linus to pull both patch series once 2.6.32
is released.
pcmcia: use dynamic debug instead of custom infrastructure
pcmcia: use dynamic debug in PCMCIA socket drivers
pcmcia: extend error reporting and debug messages in core
pcmcia: ...
| Oct 24, 12:42 pm 2009 |
| Dominik Brodowski |
| Oct 24, 12:42 pm 2009 |
| Dominik Brodowski | [PATCH 08/16] pcmcia: use dynamic debug infrastructure, ...
Convert PCMCIA drivers to use the dynamic debug infrastructure, instead of
requiring manual settings of PCMCIA_DEBUG. Only some rare debug checks are
now hidden behind "#ifdef DEBUG" or "#if 0".
Also, remove all usages of the CS_CHECK macro and replace them with proper
Linux style calling and return value checking. The extra error reporting may
be dropped, as the PCMCIA core already complains about any (non-driver-author)
errors.
CC: netdev@vger.kernel.org
Signed-off-by: Dominik Brodowski ...
| Oct 24, 12:42 pm 2009 |
| Frederik Nosi | iwl3945, after a while stops working with "No space for Tx"
Hi,
first sorry if somebody is not the right contact, got the adressess from ./scripts/get_maintainer.pl -f drivers/net/wireless/iwlwifi.
From some kernel versions now, after some time that im using this card it stops working and on messages i get this errors:
Oct 24 14:38:24 kotys NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
[snip pulseaudio's stuppid log spam warning]
Oct 24 14:40:07 kotys kernel: iwl3945 0000:04:00.0: Error sending ...
| Oct 24, 6:44 am 2009 |
| Eric Dumazet |
| Oct 24, 6:34 am 2009 |
| David Miller | Re: [PATCH net-next-2.6] xfrm6_tunnel: RCU conversion
Nice work Eric, I applied all of your RCU conversions to
net-next-2.6, thanks!
Applying: ipv6 sit: RCU conversion phase I
Applying: ipv6 sit: RCU conversion phase II
Applying: xfrm6_tunnel: RCU conversion
Applying: ipip: convert hash tables locking to RCU
Applying: ip6tnl: convert hash tables locking to RCU
Applying: gre: convert hash tables locking to RCU
--
| Oct 24, 6:09 am 2009 |
| Eric Dumazet | [PATCH net-next-2.6] xfrm6_tunnel: RCU conversion
xfrm6_tunnels use one rwlock to protect their hash tables.
Plain and straightforward conversion to RCU locking to permit better SMP
performance.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv6/xfrm6_tunnel.c | 47 ++++++++++++++++++++++----------------
1 files changed, 28 insertions(+), 19 deletions(-)
diff --git a/net/ipv6/xfrm6_tunnel.c b/net/ipv6/xfrm6_tunnel.c
index 81a95c0..438831d 100644
--- a/net/ipv6/xfrm6_tunnel.c
+++ b/net/ipv6/xfrm6_tunnel.c
@@ -23,7 ...
| Oct 23, 9:19 pm 2009 |
| Eric Dumazet | [PATCH 2/2 net-next-2.6] ipv6 sit: RCU conversion phase II
SIT tunnels use one rwlock to protect their hash tables.
This locking scheme can be converted to RCU for free, since netdevice
already must wait for a RCU grace period at dismantle time.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv6/sit.c | 45 +++++++++++++++++++++++++++------------------
1 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 8cdcc2a..b6b1626 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -77,8 ...
| Oct 23, 8:52 pm 2009 |
| Eric Dumazet | [PATCH 1/2 net-next-2.6] ipv6 sit: RCU conversion phase I
SIT tunnels use one rwlock to protect their prl entries.
This first patch adds RCU locking for prl management,
with standard call_rcu() calls.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/ipip.h | 1
net/ipv6/sit.c | 73 +++++++++++++++++++++++++++++--------------
2 files changed, 51 insertions(+), 23 deletions(-)
diff --git a/include/net/ipip.h b/include/net/ipip.h
index 86f1c8b..290effb 100644
--- a/include/net/ipip.h
+++ b/include/net/ipip.h
@@ ...
| Oct 23, 8:51 pm 2009 |
| David Miller |
| Oct 24, 4:29 am 2009 |
| David Miller | Re: [PATCH] atm: Cleanup redundant tests on unsigned
From: Eric Dumazet <eric.dumazet@gmail.com>
Conversely, the reader can say "Wow this can be negative? There's
tests missing elsewhere! ... oh, nevermind it's unsigned"
That really wastes people's time too.
I suspect I'll apply these patches. :-)
--
| Oct 24, 6:19 am 2009 |
| Krishna Kumar2 |
| Oct 24, 6:45 am 2009 |
| David Miller |
| Oct 24, 6:40 am 2009 |
| Krishna Kumar2 |
| Oct 24, 7:00 am 2009 |
| David Miller | Re: [RFC] [PATCH] udp: Don't save dst in udpv6_sendmsg()
From: Krishna Kumar2 <krkumar2@in.ibm.com>
Eric Dumazet or someone else made comments recently about how
nobody uses connected UDP sockets.
And if someone actually does, they can complain and we can
go back to looking into it :-)
--
| Oct 24, 6:49 am 2009 |
| Divy Le Ray |
| Oct 23, 5:29 pm 2009 |
| David Miller |
| Oct 24, 7:07 am 2009 |
| David Miller |
| Oct 24, 6:53 am 2009 |
| David Miller |
| Oct 24, 6:48 am 2009 |
| David Miller |
| Oct 24, 6:46 am 2009 |
| David Miller | Re: Irq architecture for multi-core network driver.
From: David Daney <ddaney@caviumnetworks.com>
You can't do this, at least within the same flow, since as you even
mention in your original posting this can result in packet reordering
which we must avoid as much as is possible.
--
| Oct 24, 6:23 am 2009 |
| David Miller | Re: Irq architecture for multi-core network driver.
From: Jesse Brandeburg <jesse.brandeburg@gmail.com>
I think requiring irqbalanced for optimal behavior is more
than reasonable.
And since we explicitly took that policy logic out of the
kernel it makes absolutely no sense to put it back there.
It's policy, and policy is (largely) userspace.
--
| Oct 23, 8:19 pm 2009 |
| David Miller | Re: Irq architecture for multi-core network driver.
From: ebiederm@xmission.com (Eric W. Biederman)
It knows what network devices are named, and looks for those keys
in /proc/interrupts. Anything names 'ethN' will not be moved and
if you name them on a per-queue basis properly (ie. 'ethN-RX1' etc.)
it will flat distribute those interrupts amongst the cpus in the
machine.
So if you're doing "silly stuff" and naming your devices by some other
convention, you would end up defeating the detations built into
irqbalanced.
Actually, let's not ...
| Oct 24, 6:26 am 2009 |
| David Miller |
| Oct 24, 6:13 am 2009 |
| Christoph Lameter |
| Oct 23, 6:52 pm 2009 |
| Pekka Enberg | Re: [PATCH 0/5] Candidate fix for increased number of GF ...
Regardless, patches 1-2 and should _really_ go to Linus' tree (and
eventually -stable) while we figure out the rest of the problems. They
fix obvious regressions in the code paths and we have reports from
people that they help. Yes, they don't fix everything for everyone but
we there's no upside in holding back fixes that are simple one line
fixes to regressions.
Pekka
--
| Oct 23, 11:48 pm 2009 |
| Mel LKML | Re: [PATCH 0/5] Candidate fix for increased number of GF ...
Hi,
This is the same Mel as mel@csn.ul.ie. The mail server the address is
on has no power until Tuesday so I'm not going to be very unresponsive
until then. Monday is also a public holiday here and apparently they
are upgrading the power transformers near the building.
And also patch 5 please which is the revert. Patch 5 as pointed out is
probably a red herring. Hwoever, it has changed the timing and made a
difference for some testing so I'd like to know if it helps yours as
well.
As ...
| Oct 24, 6:46 am 2009 |
| Frans Pop |
| Oct 24, 6:51 am 2009 |
| Sven Geggus |
| Oct 24, 7:02 am 2009 |
| Christoph Lameter |
| Oct 23, 7:03 pm 2009 |
| David Miller |
| Oct 24, 7:02 am 2009 |
| David Miller |
| Oct 24, 7:00 am 2009 |
| David Miller |
| Oct 24, 6:12 am 2009 |
| Cyrill Gorcunov | Re: [RFC] net,socket: introduce build_sockaddr_check hel ...
[David Miller - Sat, Oct 24, 2009 at 06:12:09AM -0700]
| From: Cyrill Gorcunov <gorcunov@gmail.com>
| Date: Sat, 24 Oct 2009 01:43:06 +0400
|
| > Or say it could be something like that
| >
| > #define __sockaddr(type, src) \
| > ({ build_sockaddr_check(sizeof(type)); (type *) src; })
| >
| > and say in function af_inet.c:inet_getname instead of
| >
| > struct sockaddr_in *sin = (struct sockaddr_in *)uaddr;
| >
| > we may write like
| >
| > struct sockaddr_in *sin = ...
| Oct 24, 9:32 am 2009 |
| David Miller |
| Oct 24, 6:55 am 2009 |
| Eric Dumazet | Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
Hmm... I'll make some experiments Monday and post results, but it seems very
promising.
Do you think the "on_each_cpu(flush_backlog, dev, 1);"
we perform right before calling netdev_wait_allrefs() could be changed
somehow to speedup rcu callbacks ? Maybe we ould avoid sending IPI twice to
cpus ?
Thanks
--
| Oct 24, 7:24 am 2009 |
| Stephen Hemminger | Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
On Sat, 24 Oct 2009 06:35:53 +0200
Actually, anything that requires more than one pass through the loop is
broken. Devices and protocols should be cleaning up on the first notifier.
The worst offender seems to be the dst cache gc code.
--
--
| Oct 24, 1:22 pm 2009 |
| Octavian Purdila | Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
Got some time today and did some experiments myself. The test is deleting 1000
dummy interfaces (interface status down, no IP/IPv6 addresses assigned) on a
UP non-preempt ppc750 @800Mhz system.
1. Ben's patch:
real 0m 3.42s
user 0m 0.00s
sys 0m 0.00s
2. Eric's schedule_timeout_uninterruptible(1);
real 0m 3.00s
user 0m 0.00s
sys 0m 0.00s
3. Simple synchronize_rcu_expedited()
This doesn't seem to work well with the UP non-preempt case since ...
| Oct 24, 4:49 pm 2009 |
| Paul E. McKenney | Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
I should hasten to add that synchronize_rcu_expedited() goes fast for
TREE_RCU but not yet for TREE_PREEMPT_RCU (where it maps safely but
This is an interesting possibility, and might fit in with some of the
changes that I am thinking about to reduce OS jitter for the heavy-duty
numerical-computing guys.
In the meantime, you could try doing the following from flush_backlog():
local_irq_save(flags);
rcu_check_callbacks(smp_processor_id(), 0);
local_irq_restore(flags);
This would ...
| Oct 24, 7:46 am 2009 |
| Eric Dumazet | Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
Thanks for the tip Paul
I believe netdev_wait_allrefs() is not a perfect candidate, because
synchronize_sched_expedited() seems really expensive.
Maybe we could call it once only, if we had to call 1 times
the jiffie delay ?
diff --git a/net/core/dev.c b/net/core/dev.c
index fa88dcd..9b04b9a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4970,6 +4970,7 @@ EXPORT_SYMBOL(register_netdev);
static void netdev_wait_allrefs(struct net_device *dev)
{
unsigned long ...
| Oct 23, 9:35 pm 2009 |
| Paul E. McKenney | Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
This could be a very useful approach!
However, please keep in mind that although synchronize_rcu_expedited()
forces a grace period, it does nothing to speed the invocation of other
RCU callbacks. In short, synchronize_rcu_expedited() is a faster version
of synchronize_rcu(), but doesn't necessarily help other synchronize_rcu()
or call_rcu() invocations.
The reason I point this out is that it looks to me that the code below is
waiting for some other task which is in turn waiting on a ...
| Oct 23, 10:49 pm 2009 |
| Eric Dumazet | Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
Normally, we need a synchronize_rcu() calls, but I feel its bit more than really
needed here.
On my dev machine, a synchronize_rcu() lasts between 2 an 12 ms
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.580259] synchronize_net() 4045596 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.588262] synchronize_net() 7769327 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.625014] synchronize_net() 4772052 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ ...
| Oct 24, 1:49 am 2009 |
| Paul E. McKenney | Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
That sounds like the right range, depending on what else is happening
on the machine at the time.
The synchronize_rcu_expedited() primitive would run in the 10s-100s
of microseconds. It involves a pair of wakeups and a pair of context
switches on each CPU.
--
| Oct 24, 6:52 am 2009 |
| Cong Wang |
| Oct 23, 7:41 pm 2009 |
| Stephen Hemminger | Re: VLAN rx acceleration bypasses bridge
On Thu, 15 Oct 2009 01:58:05 +0200
The way I see it, if you define a vlan then you need to bridge that
vlan. Mixing plain and vlanned interfaces is a mess that is hard to untangle
and probably not worth fixing.
--
| Oct 24, 11:11 am 2009 |
| Eric W. Biederman |
| Oct 23, 7:13 pm 2009 |
| Dhananjay Phadke |
| Oct 24, 10:29 am 2009 |
| Dhananjay Phadke | RE: [patch next 3/4] netxen: fix bonding support
Yes, this was a bug until recent times.
It should be fixed in 2.6.32 development cycle by this commit -
db4cfd8a6149e778befb2ff6e6f91cdc6394cbe6 ("netxen: handle firmware load errors").
This added a check for adapter->is_up before touching txq lock.
-Dhananjay
________________________________________
From: Eric W. Biederman [ebiederm@xmission.com]
Sent: Thursday, October 22, 2009 10:57 PM
To: Dhananjay Phadke
Cc: netdev@vger.kernel.org
Subject: Re: [patch next 3/4] netxen: fix bonding ...
| Oct 23, 6:54 pm 2009 |
| Ben Hutchings | Re: [PATCH kernel 2.6.32-rc5] pcnet_cs: add cis of PreM ...
[...]
If it is subject to copyright - which apparently they think it is - then
when redistributing under GPL we must be able to provide the 'preferred
form for modification'. So that leads to the question, is this blob or
hex file the preferred form?
I know very little about CIS but it appears to have a fairly simple
structure that could perhaps be constructed with a hex editor. However,
if a manufacturer or a later maintainer actually compiles it from a file
in some other format which has ...
| Oct 24, 1:33 pm 2009 |
