I've changed kernel to rc4 and completely changed hardware.
Now this is
I've got new trace, but this is another problem as i can see and connected
with pppoe
===
[ INFO: possible circular locking dependency detected ]
2.6.21-rc4 #1
--
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
> e
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.
>
>
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 (unte
> 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 infini
> 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_if
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
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 a
"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 dev
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 major
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 :
> > > Subject: Re: [ofa-general] Re: dst_ifdown breaks in
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 w
> Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
>
> > Quoting Eric W. Biederman :
> > Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
> >
> > "Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
> >
> > >> > Why is neighbo
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 'st
> Quoting Eric W. Biederman :
> 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 ca
Now to convert the last one, skb->data, that will allow many simplifications
and removal of some of the offset helpers.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
arch/ia64/sn/kernel/xpnet.c |6 +-
drivers/atm/ambassador.c |2 +-
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 http://vger.kernel.org/ma
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() (hen
> 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?
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 fil
> 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
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
===
---
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
=
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
th
[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
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
> > > 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
> > 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 unsubsc
> 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 som
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 dst->n
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: 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
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 b/drivers/net/cxg
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
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,
- monitor
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
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
> 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
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 wher
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 p
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 involv
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 "
> 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?)
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 mist
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 cras
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
> 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 inli
48 matches
Mail list logo
