From: Rusty Russell [EMAIL PROTECTED]
Date: Sat, 17 Mar 2007 21:33:58 +1100
On Fri, 2007-03-16 at 13:38 -0700, Jeremy Fitzhardinge wrote:
David Miller wrote:
Perhaps the problem can be dealt with using ELF relocations.
There is another case, discussed yesterday on netdev, where
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Sun, 18 Mar 2007 00:12:24 -0300
Here is the bugger, it wasn't because {transport,network,mac}_header
is unsigned after all :-)
Please consider pulling from the usual place:
David Miller wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient addressing mode on a given cpu, you'd be
patching up indirect calls and crap like that. Just say no...
Instead
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient addressing mode on a given cpu, you'd be
patching up indirect calls and crap like that. Just say no...
That wouldn't handle inlines
do_tcp_sendpages() should not iterate 'pages' as an array since
it is not an array of 'struct page *', but a pointer to a single
entity of 'struct page *' passed on the stack as a parameter to
tcp_send_page() (hence it would crash if poffset + psize PAGE_SIZE,
because pages[1] and beyond most
On Sun, Mar 18, 2007 at 02:43:46PM +0200, Dan Aloni wrote:
do_tcp_sendpages() should not iterate 'pages' as an array since
it is not an array of 'struct page *', but a pointer to a single
entity of 'struct page *' passed on the stack as a parameter to
tcp_send_page() (hence it would crash
Andi Kleen wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient addressing mode on a given cpu, you'd be
patching up indirect calls and crap like that. Just say no...
Alexey, Roland,
In debugging kernel lockup that occurs with IP over InfiniBand in 2.6.21-rc4:
( https://bugs.openfabrics.org/show_bug.cgi?id=402 )
I noticed the following code in dst_ifdown:
/* Dirty hack. We did it in 2.2 (in __dst_free),
* we have _very_ good reasons not to repeat
* this
The bigger problem is that you don't know what registers you can
clobber. For the pv_ops in hand-written asm, that a big pain. The code
either has to assume the worst, or the relocator has to do something
more sophisticated (like look for push/pop pairs surrounding the call,
perhaps?).
You
Andi Kleen wrote:
You could use the dwarf2 unwind tables. They have exact information
what register has what. But it would likely get complicated.
Yes. And would they be accurate for hand-written asm, which is where we
have this problem?
J
-
To unsubscribe from this list: send the line
Hi Jeff,
Here's 3 minor updates for myri10ge in 2.6.21:
1. use regular firmware on Serverworks HT2100
2. update wcfifo and intr_coal_delay default values
3. update driver version to 1.3.0-1.225
Please apply.
Thanks,
Brice
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
[PATCH 1/3] myri10ge: use regular firmware on Serverworks HT2100
Use the regular firmware on Serverworks HT2100 PCIe ports since this
chipset provides aligned PCIe completions.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c |8
1 file changed, 8
Update the default value of 2 module parameters:
* wcfifo disabled
* intr_coal_delay 75us
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-rc/drivers/net/myri10ge/myri10ge.c
Driver version is now 1.3.0-1.225.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-rc/drivers/net/myri10ge/myri10ge.c
===
---
Hi,
I am facing a problem when I run tc on the bonded nic cards.
When I run tc on a single nic card, it worked perfectly fine. But when I
run tc on a bond of two nics, tc gives poor performance. The two nics
were bonded in round-robin (load balancing) mode. I created a qdisc, class
and a
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
Best Regards,
- Arnaldo
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sun, Mar 18, 2007 at 10:29:10AM -0700, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
You could use the dwarf2 unwind tables. They have exact information
what register has what. But it would likely get complicated.
Yes. And would they be accurate for hand-written asm, which is where we
Hi Jeff,
I'm submitting a set of bug fixes for inclusion in 2.6.21.
The patches are built against Linus'git tree.
Here is a brief description:
- ethtool -g/G should only apply to queue sets bound to the given port,
- the driver will attempt to load the FW if it hits a version mismatch,
-
From: Divy Le Ray [EMAIL PROTECTED]
Limit ethtool -g/-G to the given port's queues.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
---
drivers/net/cxgb3/cxgb3_main.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c
From: Divy Le Ray [EMAIL PROTECTED]
The driver attempts to upgrade the FW if the card has the wrong version.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
---
drivers/net/Kconfig|1 +
drivers/net/cxgb3/cxgb3_main.c | 25 +
drivers/net/cxgb3/t3_hw.c
From: Divy Le Ray [EMAIL PROTECTED]
T3B2 does not lose its pcie config space on reset.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
---
drivers/net/cxgb3/t3_hw.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c
From: Divy Le Ray [EMAIL PROTECTED]
Under rare conditions, the MAC might hang while generating a pause frame.
This patch fine tunes the MAC settings to avoid the issue, allows for
periodic MAC state check, and triggers a recovery if hung.
Also fix one MAC statistics counter for the rev board
From: Dan Aloni [EMAIL PROTECTED]
Date: Sun, 18 Mar 2007 14:43:46 +0200
do_tcp_sendpages() should not iterate 'pages' as an array since
it is not an array of 'struct page *', but a pointer to a single
entity of 'struct page *' passed on the stack as a parameter to
tcp_send_page() (hence it
On Sun, Mar 18, 2007 at 02:49:27PM -0700, David Miller wrote:
From: Dan Aloni [EMAIL PROTECTED]
Date: Sun, 18 Mar 2007 14:43:46 +0200
do_tcp_sendpages() should not iterate 'pages' as an array since
it is not an array of 'struct page *', but a pointer to a single
entity of 'struct page
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Sun, 18 Mar 2007 18:49:28 -0300
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
Pulled, thanks a lot!
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo
Andi Kleen wrote:
Yes. All inline assembly tells gcc what registers are clobbered
and it fills in the tables. Hand clobbering in inline assembly cannot
be expressed with the current toolchain, so we moved all those
out of line.
But again I'm not sure it will work anyways. For once you would
Hello!
This is not new code, and should have triggered long time ago,
so I am not sure how come we are triggering this only now,
but somehow this did not lead to crashes in 2.6.20
I see. I guess this was plain luck.
Why is neighbour-dev changed here?
It holds reference to device and
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
This is not new code, and should have triggered long time ago,
so I am not sure how come we are triggering this only now,
but somehow this did not lead to crashes in 2.6.20
I see. I guess
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
This is not new code, and should have triggered long time ago,
so I am not sure how come we are triggering this only now,
but somehow this did not lead to crashes in 2.6.20
I see. I guess
Hello!
Hmm. Something I don't understand: does the code
in question not run on *each* device unregister?
It does.
Why do I only see this under stress?
You should have some referenced destination entries to trigger bad path.
This should happen not only under stress.
F.e. just try to ssh to
Hello!
It should be cleared and we should be sure it will not be destroyed
before quiescent state.
I'm confused. didn't you say dst_ifdown is called after quiescent state?
Quiescent state should happen after dst-neighbour is invalidated.
And this implies that all the users of
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
Hmm. Something I don't understand: does the code
in question not run on *each* device unregister?
It does.
Why do I only see this under stress?
You should have some referenced
Why is neighbour-dev changed here?
It holds reference to device and prevents its destruction.
If dst is held somewhere, we cannot destroy the device and deadlock
while unregister.
BTW, can this ever happen for the loopback device itself?
Is it ever unregistered?
--
MST
-
To unsubscribe
It should be cleared and we should be sure it will not be destroyed
before quiescent state.
I'm confused. didn't you say dst_ifdown is called after quiescent state?
Quiescent state should happen after dst-neighbour is invalidated.
And this implies that all the users of dst-neighbour
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Can dst-neighbour be changed to point to NULL instead, and the neighbour
released?
It should be cleared and we should be sure it will not be destroyed
before quiescent state.
Seems, this is the only
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Can dst-neighbour be changed to point to NULL instead, and the neighbour
released?
It should be cleared
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Can
Quoting Eric W. Biederman ebiederman@lnxi.com:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
Michael S. Tsirkin [EMAIL PROTECTED] writes:
Why is neighbour-dev changed here?
It holds reference to device and prevents its destruction.
If dst is held somewhere, we
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
Quoting Eric W. Biederman ebiederman@lnxi.com:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
Michael S. Tsirkin [EMAIL PROTECTED] writes:
Why is
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 00:42:34 +0200
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
Quoting Eric W. Biederman ebiederman@lnxi.com:
Subject: Re: [ofa-general] Re: dst_ifdown breaks
Michael S. Tsirkin [EMAIL PROTECTED] writes:
Why is neighbour-dev changed here?
It holds reference to device and prevents its destruction.
If dst is held somewhere, we cannot destroy the device and deadlock
while unregister.
BTW, can this ever happen for the loopback device itself?
Is
On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient addressing mode on a given cpu, you'd be
patching up indirect calls and crap
This reverts commit 18babd38547a042a4bfd4154a014d1ad33373eb0.
Michael Barkowski points out that it's wrong, and I agree. The
patch causes a problem rather than fixes one after another
patch ucc_geth: Fix BD processing was applied. Before that
patch, current packet should be blocked. However
Luciano Ruete wrote:
After an:
# ip ru flush
I loose all my ip rules but the priority 0 one.
[EMAIL PROTECTED]:~# ip ru
0: from all lookup 255
[EMAIL PROTECTED]:~#
Ok with that, but now i'm not able to insert any new rule.
This leads to a total loose of conectivity.
[EMAIL
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
Quoting David Miller [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 00:42:34 +0200
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: dst_ifdown breaks
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting
David Miller [EMAIL PROTECTED] writes:
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 00:42:34 +0200
Hmm. Then the code moving dst-dev to point to the loopback
device will have to be fixed too. I'll post a patch a bit later.
Does this look sane (untested)?
From: ebiederman@lnxi.com (Eric W. Biederman)
Date: Sun, 18 Mar 2007 23:30:39 -0600
Sure. In the network namespace case I think the careful ordering of the
shutdown handles that case. Even with per network namespace lo
unregistered it still existed until the network namespace actually
49 matches
Mail list logo
