On Wed, Apr 04, 2007 at 06:10:42PM -0700, Arjan van de Ven wrote:
On Thu, 2007-04-05 at 10:44 +1000, Herbert Xu wrote:
Stephen Hemminger [EMAIL PROTECTED] wrote:
Thanks Dave, there is a classic AB BA deadlock here.
We should break the dependency like this.
Could someone who
On Wed, Apr 04, 2007 at 02:20:23PM +0100, Christian Kujau wrote:
On Wed, 4 Apr 2007, Jarek Poplawski wrote:
So, it's a lot sooner than before. (BTW, isn't there anything
in debug log?)
No, nothing. I've set up remote-syslgging to the other node (node1
logging to node2 and vice versa) -
On Wed, Apr 04, 2007 at 06:10:42PM -0700, Arjan van de Ven wrote:
what's the exact lockdep output here?
Here's the original report:
===
[ INFO: possible circular locking dependency detected ]
2.6.20-1.2933.fc6debug #1
* Avi Kivity [EMAIL PROTECTED] wrote:
[...] But the difference in cruftiness between kvm and qemu code
should not enter into the discussion of where to do things.
i agree that it doesnt enter the discussion for the *PIC question, but
it very much enters the discussion for the question that
Hi all
As I came this morning to check the IrNET / PPP test, I started yesterday,
the device was dead and OOM messages were scrolling up the terminal. I
captured task trace, and the ftp process seems to have been the original
culprit. Below is the backtrace. Which looks like a recursive
Ingo Molnar wrote:
so right now the only option for a clean codebase is the KVM in-kernel
code.
I strongly disagree with this. Bad code in userspace is not an excuse
for shoving stuff into the kernel, where maintaining it is much more
expensive, and the cause of a mistake can be system
It is far too large to be an inline and not in any hot paths.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux-2.6.21-rc1-net/include/net/sock.h
===
--- linux-2.6.21-rc1-net.orig/include/net/sock.h
+++
Ok, a simple analysis reveals the recursive spinlock:
On Thu, 5 Apr 2007, Guennadi Liakhovetski wrote:
[bf12b220] (ppp_channel_push+0x0/0xc8 [ppp_generic]) from [bf12bf98]
(ppp_output_wakeup+0x18/0x1c [ppp_generic])
===
r7 = C38F42BC r6 = C38F4200 r5 = C38F4200
On Thu, Apr 05, 2007 at 02:04:02AM +, Andrew Morton wrote:
This looks like a locking bug in the ipv6 changes in davem's devel tree.
There are no relevant changes to drivers/net/sc92031.c in rc5-mm4.
Actually, this looks like a latent bug in sc92031. It's calling
spin_lock in the dev-open
The compiler eliminates them anyways and this makes the code easier to read
and shorter.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux-2.6.21-rc3-net/net/ipv4/tcp_ipv4.c
===
---
Ben Greear [EMAIL PROTECTED] :
[...]
It looks like this has not made it into the 2.6.20 stable series
patches... Any reason not to add it there?
No. Go ahead and submit it.
--
Ueimor
Anybody got a battery for my Ultra 10 ?
-
To unsubscribe from this list: send the line unsubscribe netdev in
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Rusty Russell [EMAIL PROTECTED] wrote:
It's easier to write a kernel-space network driver, but it's not
obviously the right thing to do until we can show that an efficient
packet-level userspace interface isn't possible. I don't think
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
so right now the only option for a clean codebase is the KVM
in-kernel code.
I strongly disagree with this.
are you disagreeing with my statement that the KVM kernel-side code is
the only clean codebase here? To me
* Avi Kivity [EMAIL PROTECTED] wrote:
so right now the only option for a clean codebase is the KVM
in-kernel code.
I strongly disagree with this.
are you disagreeing with my statement that the KVM kernel-side code is
the only clean codebase here? To me this is a clear fact :)
I only
I'll try to get to testing this, but I'm wondering if people may have
misunderstood my original post. I don't get any corruption over
Ethernet; it's just corruption on the filesystem during certain load
patterns that involve the Realtek ethernet card.
When disabling hardware checksums helps
* Rusty Russell [EMAIL PROTECTED] wrote:
It's easier to write a kernel-space network driver, but it's not
obviously the right thing to do until we can show that an efficient
packet-level userspace interface isn't possible. I don't think that's
been done, and it would be interesting to
Rick Jones wrote:
teach ethtool to print 1Mb/s for a 10G NIC and prepare
for 10G NICs where it is possible to run something other than 10G
update the ethtool.8 manpage with info re same and some grammar fixes
Signed-off-by: Rick Jones [EMAIL PROTECTED]
the likely required asbestos at the
This patch includes:
- dlpar fix:
certain resources may only be allocated when first
logical port is available, and must be removed when
last logical port has been removed
- sysfs entries:
create symbolic link from each logical port to ehea driver
Signed-off-by:
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED]
Date: Thu, 05 Apr 2007 02:21:52 +0900 (JST)
In article [EMAIL PROTECTED] (at Tue, 3 Apr 2007 15:55:51 +0900), Mitsuru
Chinen [EMAIL PROTECTED] says:
Incoming trancated packets are counted as not only InTruncatedPkts but
also InHdrErrors.
Rusty Russell wrote:
You didn't quote Anthony's point about it's more about there not being
good enough userspace interfaces to do network IO.
It's easier to write a kernel-space network driver, but it's not
obviously the right thing to do until we can show that an efficient
packet-level
On Wed, Apr 04, 2007 at 10:10:07PM +, Stephen Hemminger wrote:
Yes, you're right. Perhaps we should get the rtnl first before
tg3_full_lock(), or turn irq_sync into an atomic counter that allows
nesting.
When you start reinventing windows locks or the BKL, you know
you are going
Herbert Xu wrote:
On Thu, Apr 05, 2007 at 02:09:20PM +0200, Patrick McHardy wrote:
One possible solution is to not send MTU errors to ourselves since
we it wouldn't give us any new information. We'd need to audit the
users of icmp_send to make sure that there isn't a legitimate case
where we'd
Folks,
while doing some testing of SCTP recently I came across a scenario
where the behavior I see is not what I expect. Here is the scenario:
I have 2 interfaces on a system, each has both an IPv4 and an IPv6
address, e.g.
eth0
192.168.1.130
:::192.168.1.130
eth1
192.168.3.130
On Thu, Apr 05, 2007 at 02:16:53PM +0200, Patrick McHardy wrote:
That sounds easier. I'm currently working in that area anyway, I'll
give it a try.
Thanks Patrick!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page:
On Thu, Apr 05, 2007 at 02:09:20PM +0200, Patrick McHardy wrote:
One possible solution is to not send MTU errors to ourselves since
we it wouldn't give us any new information. We'd need to audit the
users of icmp_send to make sure that there isn't a legitimate case
where we'd want to do
On Tue, Apr 03, 2007 at 06:32:07PM +0200, Patrick McHardy wrote:
I'm not sure I understand how this would work, the ICMP message
looks the same in both cases. Or are you suggesting to
differentiate based on the source of the ICMP message?
Actually you're right, this can't work in the general
Ingo Molnar wrote:
* Rusty Russell [EMAIL PROTECTED] wrote:
It's easier to write a kernel-space network driver, but it's not
obviously the right thing to do until we can show that an efficient
packet-level userspace interface isn't possible. I don't think that's
been done, and it would
The most common trigger of these errors is that the
config option hasn't been enable wich would make the
functionality available. Therefore returning EOPNOTSUPP
gives a better idea on what is going wrong.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.22/net/core/rtnetlink.c
On Thu, 5 Apr 2007, Guennadi Liakhovetski wrote:
Ok, a simple analysis reveals the recursive spinlock:
On Thu, 5 Apr 2007, Guennadi Liakhovetski wrote:
[bf12b220] (ppp_channel_push+0x0/0xc8 [ppp_generic]) from [bf12bf98]
(ppp_output_wakeup+0x18/0x1c [ppp_generic])
===
From: Herbert Xu [EMAIL PROTECTED]
Date: Thu, 5 Apr 2007 21:44:31 +1000
On Thu, Apr 05, 2007 at 02:04:02AM +, Andrew Morton wrote:
This looks like a locking bug in the ipv6 changes in davem's devel tree.
There are no relevant changes to drivers/net/sc92031.c in rc5-mm4.
Actually,
applied
Thanks.
One thing I noticed while making the changes is that the reported speed
is kept in a u16. With 10G we are already 1/6 of the way to the
maximum. I've no idea when 100G will arrive, but euros to beliners it
will probably arrive some day which means something will have to
Hi Paolo
Paolo Galtieri wrote:
What is happening is that the check for IPV6_ADDR_MAPPED that occurs
during the add is missing when you do the remove and hence the IPv6
address is never mapped to the IPv4 address causing the lookup to
fail. Below is the patch to add the necessary checks to do
This driver's 4-packet deep TX queue is too sensible to the careless callers
ignoring its state (like netpoll in trapped mode), so add queue full check at
the start of the hard_start_xmit() method (only under #ifndef RTL8139_NDEBUG,
otherwise the queue will get stuck once dirty pointer gets out of
We're seeing some strange behavior on several systems with onboard
PCI-e pro/1000 NICs. The behavior is generally that we cannot connect
into a system until we ping from that system out. It often happens
with our tainted 2.6.18.2 kernel, but we also see similar problems on
the 2.6.20.? FC5
Here's the revises patch
Paolo
Signed-off-by: Paolo Galtieri [EMAIL PROTECTED]
--- net/sctp/socket.c.orig 2007-04-05 12:59:15.0 -0700
+++ net/sctp/socket.c 2007-04-05 13:11:37.0 -0700
@@ -627,6 +627,12 @@ int sctp_bindx_rem(struct sock *sk, stru
David,
Please consider pulling from my git tree:
git-pull git://lost.foo-projects.org/~ppwaskie/git/net-2.6.22
multiqueue
This is a branch named 'multiqueue' of a recent pull from your tree with
an updated implementation of the multiqueue implementation we've been
working on.
From: Thomas Graf [EMAIL PROTECTED]
Date: Thu, 5 Apr 2007 16:34:02 +0200
The most common trigger of these errors is that the
config option hasn't been enable wich would make the
functionality available. Therefore returning EOPNOTSUPP
gives a better idea on what is going wrong.
Sorry for the top post.
I believe this is a known issue and it was fixed in the kernel driver as
well (maybe it didn't make it into FC5 kernel?).
See the following:
http://article.gmane.org/gmane.linux.network/52168/match=e1000+factps+mn
gcg
If I'm not mistaken, the part relevant to your
On Thu, Apr 05, 2007 at 09:59:29AM -0700, David Miller wrote:
Where is the patch? :-)
Second time you've done this in two days Herbert, tsk tsk :)))
The patch was so easy that it was left as an exercise to the reader :)
[SC92031]: Fix priv-lock context
The spin_lock calls made in dev-open
On Thu, Apr 05, 2007 at 09:59:29AM -0700, David Miller wrote:
Where is the patch? :-)
Second time you've done this in two days Herbert, tsk tsk :)))
The patch was so easy that it was left as an exercise to the reader :)
I did try, but it was too much for me :-)
[SC92031]: Fix priv-lock
On Thu, 2007-04-05 at 13:36 +0200, Ingo Molnar wrote:
prototyping new kernel APIs to implement user-space network drivers, on
a crufty codebase is not something that should be done lightly.
I think you overestimate my radicalism. I was considering readv() and
writev() on the tap device.
In article [EMAIL PROTECTED] (at Thu, 05 Apr 2007 23:21:05 -0400), Brian
Haley [EMAIL PROTECTED] says:
Add link and site-local scope inline to avoid calls to ipv6_addr_type().
I disagree. Multicast scopes should also be handled appropriately.
--yoshfuji
-
To unsubscribe from this list:
In article [EMAIL PROTECTED] (at Thu, 05 Apr 2007 23:21:16 -0400), Brian
Haley [EMAIL PROTECTED] says:
Add multicast address type inline to avoid calls to ipv6_addr_type().
Signed-off-by: Brian Haley [EMAIL PROTECTED]
---
include/net/ipv6.h|5 +
net/ipv6/icmp.c | 12
Add multicast address type inline to avoid calls to ipv6_addr_type().
Signed-off-by: Brian Haley [EMAIL PROTECTED]
---
include/net/ipv6.h|5 +
net/ipv6/icmp.c | 12
net/ipv6/ip6_tunnel.c |4 ++--
net/ipv6/route.c |4 ++--
4 files changed, 13
[sorry if anyone got these multiple times, git-send-email weirdness]
This set of patches adds new IPv6 scope and address type inlines
to both clean-up the code (inspired by Arnaldo's skb cleanup) and reduce
calls to ipv6_addr_type() when we can just compare the address directly.
No functionality
Add mapped address type inline to avoid calls to ipv6_addr_type().
Signed-off-by: Brian Haley [EMAIL PROTECTED]
---
include/net/ipv6.h |6 ++
net/ipv6/ip6_flowlabel.c |6 ++
net/ipv6/ipv6_sockglue.c |2 +-
net/ipv6/tcp_ipv6.c | 13 +
net/ipv6/udp.c
Add link and site-local scope inline to avoid calls to ipv6_addr_type().
Signed-off-by: Brian Haley [EMAIL PROTECTED]
---
include/net/ipv6.h | 10 ++
net/dccp/ipv6.c |2 +-
net/ipv6/addrconf.c |6 +++---
net/ipv6/af_inet6.c
In article [EMAIL PROTECTED] (at Thu, 05 Apr 2007 23:21:25 -0400), Brian
Haley [EMAIL PROTECTED] says:
Add mapped address type inline to avoid calls to ipv6_addr_type().
Signed-off-by: Brian Haley [EMAIL PROTECTED]
---
include/net/ipv6.h |6 ++
net/ipv6/ip6_flowlabel.c |
In article [EMAIL PROTECTED] (at Thu, 05 Apr 2007 23:21:33 -0400), Brian
Haley [EMAIL PROTECTED] says:
Add loopback address type inline to avoid calls to ipv6_addr_type().
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index f6aa338..7f1aabe 100644
--- a/net/ipv6/ip6_output.c
Tantilov, Emil S wrote:
Sorry for the top post.
I believe this is a known issue and it was fixed in the kernel driver as
well (maybe it didn't make it into FC5 kernel?).
See the following:
http://article.gmane.org/gmane.linux.network/52168/match=e1000+factps+mn
gcg
Thank you! I've
Please consider this for the 2.6.20 stable branch. This fixes a
deadlock between the
bridging code and the 8139too driver. I am not the author of this
patch, but I have
tested a slightly modified version (so that it works with the 2.6.18
kernel) extensively
and it solves the deadlock. Mr.
51 matches
Mail list logo
