In article <[EMAIL PROTECTED]> (at Fri, 06 Apr 2007 02:37:52 -0400), Brian
Haley <[EMAIL PROTECTED]> says:
> static inline int ipv6_addr_scope_linklocal(const struct in6_addr *a)
> {
> return ((a->s6_addr32[0] & htonl(0xFFC0)) == htonl(0xFE80) ||
> ((a->s6_addr32[0] & htonl(0xFF0
YOSHIFUJI Hideaki / wrote:
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.
Yes, I
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. Ro
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 added
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_outp
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_flo
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
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 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 insert
[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 loopback address type inline to avoid calls to ipv6_addr_type().
Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
---
include/net/ipv6.h|7 +++
net/ipv6/ip6_output.c |5 +++--
net/ipv6/route.c |8 +++-
3 files changed, 13 insertions(+), 7 deletions(-)
diff --git a
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
On Friday 06 April 2007 07:18, Herbert Xu wrote:
> Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
> > 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()
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
Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
> 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,
> otherwis
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.
Qem
> 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]: Fi
On Thu, 2007-04-05 at 10:17 +0300, Avi Kivity wrote:
> 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
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-
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 proble
On Tue, Apr 03, 2007 at 11:19:16PM +0200, Olaf Hering wrote:
> From: [EMAIL PROTECTED]
>
> https://bugzilla.novell.com/show_bug.cgi?id=SUSE39204
Wow, registering for Novell's bugzilla is painful. And in the end I
get "Access denied" on that bug. Can you give us this information
some other way?
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Thu, 5 Apr 2007 14:33:19 -0700
> 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 yo
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.
>
> Signe
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. Inc
Oops, the patch I sent previously was for an older 2.6 kernel. I'm
testing on a 2.6.10+ SCTP patches up to 2.6.17. Here is a revised patch
for 2.6.21:
Paolo
Signed-off-by: Paolo Galtieri <[EMAIL PROTECTED]>
--- linux-2.6.21/net/sctp/socket.c 2007-03-26 06:58:14.0 -0700
+++ lin
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
r
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 kern
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
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 th
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 g
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.
>
> A
On Thu, 5 Apr 2007, Guennadi Liakhovetski wrote:
> Ok, a simple analysis reveals the recursive spinlock:
>
> On Thu, 5 Apr 2007, Guennadi Liakhovetski wrote:
>
> > [] (ppp_channel_push+0x0/0xc8 [ppp_generic]) from []
> > (ppp_output_wakeup+0x18/0x1c [ppp_generic])
> ===> ^^
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
==
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
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 gene
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 ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.
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 wan
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
::
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
Herbert Xu wrote:
> 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,
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
> y
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 th
* 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 thi
> 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 help
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->o
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 netde
Ok, a simple analysis reveals the recursive spinlock:
On Thu, 5 Apr 2007, Guennadi Liakhovetski wrote:
> [] (ppp_channel_push+0x0/0xc8 [ppp_generic]) from []
> (ppp_output_wakeup+0x18/0x1c [ppp_generic])
===>
> r7 = C38F42BC r6 = C38F4200 r5 = C38F4200 r4 = 00
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
===
--- linux-2.6.21-rc3-net.orig/net/ipv4/tcp_ip
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
+++ linux-2.6.21-rc1-net
* 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
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 crash
The function is quite big and has several call sites and nothing
to collapse by compiler optimization on inlining.
Besides it's nicer to read in a in .c file.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc3-net/include/net/tcp.h
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 th
* 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
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 spinloc
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 In
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 users
* 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 th
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: J
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.
> > >
> > > Cou
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
--
62 matches
Mail list logo
