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/mv643xx_eth.c |2 +-
drivers/net/mv643xx_eth.h |4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
Dale
On Sat, Sep 29, 2007 at 01:24:47AM -0400, Jeff Garzik wrote:
Markus Brunner wrote:
this are the changes to the smc911x driver, which were necessary
to get it running on the Magic Panel R2 (smsc9115).
It is a SH3-DSP based board. The other patches are available on
the linuxsh-dev mailinglist.
On Sat, Sep 29, 2007 at 01:29:25AM -0400, Jeff Garzik wrote:
Nobuhiro Iwamatsu wrote:
This patch supports Hitachi Solution Engine (SuperH) of smc91x.
Please apply this patch .
diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
index 6ff3a16..af9e6bf 100644
--- a/drivers/net/smc91x.h
On Fri, 28 Sep 2007 21:48:18 +0200 Laurent Riffard [EMAIL PROTECTED] wrote:
Hi,
From time to time, I experience some complete network hangs:
Suddenly, all network connections become unresponsive. Even ping
127.0.0.1 doesn't work. SysRq-w does not show any blocked processus.
When such
Le 29.09.2007 10:31, Andrew Morton a écrit :
On Fri, 28 Sep 2007 21:48:18 +0200 Laurent Riffard [EMAIL PROTECTED] wrote:
Hi,
From time to time, I experience some complete network hangs:
Suddenly, all network connections become unresponsive. Even ping
127.0.0.1 doesn't work. SysRq-w does
From: Laurent Riffard [EMAIL PROTECTED]
Date: Sat, 29 Sep 2007 11:22:06 +0200
Could a router problem prevent ping 127.0.0.1 from working ?
Two things that are new and could cause these problems:
1) We dynamically allocate the loopback device now.
2) We have the network namespace stuff.
On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
On Fri, 28 Sep 2007, Cedric Le Goater wrote:
I just found that warning in my logs. It seems that it's been
happening since rc7-mm1 at least.
WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
tcp_fastretrans_alert()
Ilpo Järvinen wrote:
On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
On Fri, 28 Sep 2007, Cedric Le Goater wrote:
I just found that warning in my logs. It seems that it's been
happening since rc7-mm1 at least.
WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
Herbert Xu wrote:
Herbert Xu [EMAIL PROTECTED] wrote:
On Fri, Sep 28, 2007 at 06:55:32PM +0200, Patrick McHardy wrote:
Looking at ip_input.o as example (everything without forced inlining):
textdata bss dec hex filename
2076 8 02084 824
Herbert Xu wrote:
Eric W. Biederman [EMAIL PROTECTED] wrote:
Currently we have the call path:
macvlan_open - dev_unicast_add - __dev_set_rx_mode -
__dev_set_promiscuity - ASSERT_RTNL - mutex_trylock
When mutex debugging is on taking a mutex complains if we are not
allowed to sleep. At
Corey Hickey wrote:
Patchset try 2 addresses the review by Michael Buesch.
Patchset try 3 addresses the review by Patrick McHardy.
Patchset try 4 has a few cosmetic improvements.
Nobody reviewed my last set of patches, and I wasn't pushy about asking.
Since it's been a while, I ported the
Eric W. Biederman wrote:
void rtnl_unlock(void)
{
- mutex_unlock(rtnl_mutex);
- if (rtnl rtnl-sk_receive_queue.qlen)
+ struct net *net;
+
+ /*
+ * Loop through all of the rtnl sockets until none of them (in
+ * a live network namespace) have queue packets.
+
Eric W. Biederman wrote:
Because of the global nature of garbage collection, and because of the
cost of per namespace hash tables unix_socket_table has been kept
global. With a filter added on lookups so we don't see sockets from
the wrong namespace.
Currently I don't fold the namesapce
Patrick McHardy [EMAIL PROTECTED] writes:
I'm wondering why this receive queue processing on unlock is still
necessary today, we don't do trylock in rtnetlink_rcv anymore, so
all senders will simply wait until the lock is released and then
process the queue.
Good question, I should probably
Patrick McHardy [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Because of the global nature of garbage collection, and because of the
cost of per namespace hash tables unix_socket_table has been kept
global. With a filter added on lookups so we don't see sockets from
the wrong
Herbert Xu [EMAIL PROTECTED] writes:
Eric W. Biederman [EMAIL PROTECTED] wrote:
Currently we have the call path:
macvlan_open - dev_unicast_add - __dev_set_rx_mode -
__dev_set_promiscuity - ASSERT_RTNL - mutex_trylock
When mutex debugging is on taking a mutex complains if we are
Patrick McHardy wrote:
Corey Hickey wrote:
Patchset try 2 addresses the review by Michael Buesch.
Patchset try 3 addresses the review by Patrick McHardy.
Patchset try 4 has a few cosmetic improvements.
Nobody reviewed my last set of patches, and I wasn't pushy about asking.
Since it's been a
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
I'm wondering why this receive queue processing on unlock is still
necessary today, we don't do trylock in rtnetlink_rcv anymore, so
all senders will simply wait until the lock is released and then
process the queue.
Good
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Currently I don't fold the namesapce into the hash so multiple
namespaces using the same socket name will be guaranteed a hash
collision.
That doesn't sound like a good thing :) Is there a reason for
not avoiding the
Eric W. Biederman wrote:
Regardless of the correctness of where we have ASSERT_RTNL.
I think not actually taking the mutex on the assertion failure path
(just so we can release it), is still a good deal regardless.
Agreed. I actually have an identical patch somewhere that
I wanted to submit
On Sat, 29 Sep 2007, Cedric Le Goater wrote:
Ilpo Järvinen wrote:
On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
On Fri, 28 Sep 2007, Cedric Le Goater wrote:
I just found that warning in my logs. It seems that it's been
happening since rc7-mm1 at least.
WARNING: at
Patrick McHardy [EMAIL PROTECTED] writes:
Maybe I can save you some time: we used to do down_trylock()
for the rtnl mutex, so senders would simply return if someone
else was already processing the queue *or* the rtnl was locked
for some other reason. In the first case the process already
On Sat, Sep 29, 2007 at 05:21:23PM +0200, Patrick McHardy wrote:
Unfortunately gcc doesn't perform tail call optimization when the
address of a parameter or local variable is passed to an extern
function before the tail call, which NF_HOOK does for the skb.
You mean the struct sk_buff **pskb
On Sun, Sep 30, 2007 at 08:26:01AM +0800, Herbert Xu wrote:
Indeed. The only other case I can think of is defragmentation.
But even there we should be able to squeeze it into the original
skb :)
OK it won't be pretty but it's definitely doable. We simply
swap the contents of that skb with
On Sat, Sep 29, 2007 at 05:32:41PM +0200, Patrick McHardy wrote:
For unicast addresses its not strictly necessary since they may
only be changed under the RTNL anyway. The reason why it takes
the tx_lock is for consistency with multicast address handling,
which can't rely on the RTNL since
From: Patrick McHardy [EMAIL PROTECTED]
Date: Sat, 29 Sep 2007 17:21:23 +0200
Unfortunately gcc doesn't perform tail call optimization when the
address of a parameter or local variable is passed to an extern
function before the tail call, which NF_HOOK does for the skb.
To which Herbert later
On Sat, Sep 29, 2007 at 05:13:39PM -0700, David Miller wrote:
The reason is that if we have to COW or resize the SKB it
could result in a realloc of the sk_buff struct which is
why we need the **pskb thing.
But strangely I can't find any skbuff.h interfaces that
require that any longer
On Sat, Sep 29, 2007 at 11:18:18AM -0600, Eric W. Biederman wrote:
Regardless of the correctness of where we have ASSERT_RTNL.
I think not actually taking the mutex on the assertion failure path
(just so we can release it), is still a good deal regardless.
Provided that you add a might_sleep
28 matches
Mail list logo
