headers
jamal | 1 Jun 2009 01:40
Picon
Picon

Re: [BUG] net_cls: Panic occured when net_cls subsystem use

On Sun, 2009-05-31 at 21:55 +0200, Jarek Poplawski wrote:

> But then, there could be "tc filter replace" with only this
> (n->nlmsg_type == RTM_NEWTFILTER && (n->nlmsg_flags&(NLM_F_CREATE)))
> which can't get here with a newly created tp, I guess.

Right - because in that case tp would already exist and would
be found in the lookup.

> I'm almost sure these commands (right or wrong) can trigger such a 
> leak:
> 
> $ sudo tc qdisc add dev lo root handle 1: htb
> $ sudo tc filter add dev lo proto ip pref 1 handle 800::1 u32 match
u32 0 0 classid 1:1
> $ sudo tc filter add dev lo proto ip pref 2 handle 800::1 u32 match
u32 0 0 classid 1:1
> RTNETLINK answers: File exists

You are good - A tip of my hat and a wag of my finger at you;->
Ok, now i looked a lot closer at all 8 classifiers
and u32 is the only one that can fault. It just needs to be fixed.
I will wait until Minoru's patch and then i will submit a fix for it.
Of course the commands from user space are a little rude ;->

cheers,
jamal
Permalink | Reply | 0 comments |
headers
Grant Grundler | 1 Jun 2009 01:43
Favicon

Re: tulip_rxtx_stop() on Cobalt Qube2

On Sun, May 31, 2009 at 11:02:22PM +0200, Florian Fainelli wrote:
> Hi Grant,
...
> > The RX/TX engines are in a wedged state to begin with. :(
> 
> I suppose this is due to the Bootloader, either CoLo or the original Cobalt 
> microservers bootloader.

Yeah - either bootloader or BIOS - whatever talked to the NIC most recently.

...
> > I have not tested or even compiled this patch...will do so on parisc/ia64
> > machines once I get some feedback on this patch.
> >
> > And I just noticed pci_clear_master() is not called *anywhere*. :(
> > Need to add such a call after tulip_stop_rxtx() some place (many places?).
> > This patch is just RFC and not suitable for merging upstream.
> 
> The patch below does not help on my Qube2, I am still having the same message 
> appearing.

Are you sure?

I thought I removed all calls to tulip_stop_rxtx() in the initialization
code path and didn't think it would get called. Did I overlook one?
Can you add "dump_stack()" to tulip_stop_rxtx() failure case?

Can you also modify the driver version to make sure you are using
the correct/most recenly built module?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Morton | 1 Jun 2009 02:03

Re: 2.6.30rc7: ksoftirqd CPU saturation (x86-64 only, not x86-32) (e1000e-related?)

Let's cc netdev on this.

Presumably it is a post-2.6.29 regression.

On Sun, 31 May 2009 23:59:35 +0100 Nix <nix <at> esperi.org.uk> wrote:

> I've just compiled a 64-bit kernel for a couple of quad-core Nehalems
> (one L5520, one Core i7) for the first time. Both were using 32-bit
> kernels happily before, and one (the Core i7) is happy afterwards: but
> the other sees two ksoftirqd threads saturating the CPU (well, half of
> it, this being a 4-core box).
> 
> Magic sysrq says:
> 
> [  179.097118] ksoftirqd/3   R  running task        0    13      2
> [  179.103635]  ffff88063f90dec0 ffffffff8057ee2a 0000000000000000 0000000000000000
> [  179.111830]  ffff88063f90dee0 ffffffff8057ee2a 0000000000000000 ffff88063f90a768
> [  179.120002]  0000000000004000 000000000000d1e8 ffff88063f90a770 ffff88063f90a768
> [  179.128162] Call Trace:
> [  179.130844]  [<ffffffff8057ee2a>] ? thread_return+0x3e/0xc1
> [  179.136940]  [<ffffffff8057ee2a>] ? thread_return+0x3e/0xc1
> [  179.143055]  [<ffffffff8057eeb6>] schedule+0x9/0x1d
> [  179.148399]  [<ffffffff80229bbc>] do_softirq+0x34/0x72
> [  179.154033]  [<ffffffff80256f9c>] ksoftirqd+0x63/0xe5
> [  179.159570]  [<ffffffff80256f39>] ? ksoftirqd+0x0/0xe5
> [  179.165188]  [<ffffffff80264d29>] kthread+0x55/0x80
> [  179.170527]  [<ffffffff802288fa>] child_rip+0xa/0x20
> [  179.175962]  [<ffffffff80264cd4>] ? kthread+0x0/0x80
> [  179.181399]  [<ffffffff802288f0>] ? child_rip+0x0/0x20
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nix | 1 Jun 2009 02:16
Picon

Re: 2.6.30rc7: ksoftirqd CPU saturation (x86-64 only, not x86-32) (e1000e-related?)

On 1 Jun 2009, Andrew Morton said:

> Let's cc netdev on this.
>
> Presumably it is a post-2.6.29 regression.

I don't know: the earliest kernel this machine has ever run was
2.6.30rc5, and this failing 2.6.30rc7 kernel is the first 64-bit kernel
I've ever run on it. So currently I have one single data point.

I plan to try out 2.6.29 (and back to 2.6.25 or thereabouts) tomorrow
and see if it ever worked: if it did I'll bisect for it (rendered tricky
by the out-of-tree e1000e driver, but doable: it would be easier if I
had a clue where the e1000-devel git tree is, if anywhere, but I still
have no idea despite considerable searching).

It seems to go wrong instantly, so replication is trivial, and this
system can compile a kernel in slightly under a minute, so it shouldn't
take too long to complete the bisection.
Permalink | Reply | 0 comments |
headers
jie.yang | 1 Jun 2009 04:07
Favicon

[PATCH net-next]atl1c: fix spelling error

Fix spelling error

Signed-off-by: Jie Yang <jie.yang <at> atheros.com>
---
diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index 598c294..8475ff4 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
 <at>  <at>  -1115,7 +1115,7  <at>  <at>  static int atl1c_stop_mac(struct atl1c_hw *hw)

 	AT_READ_REG(hw, REG_TXQ_CTRL, &data);
 	data &= ~TXQ_CTRL_EN;
-	AT_WRITE_REG(hw, REG_TWSI_CTRL, data);
+	AT_WRITE_REG(hw, REG_TXQ_CTRL, data);

 	for (timeout = 0; timeout < AT_HW_MAX_IDLE_DELAY; timeout++) {
 		AT_READ_REG(hw, REG_IDLE_STATUS, &data);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Mike Christie | 1 Jun 2009 04:25
Picon
Favicon

Re: [SCSI] cxgb3i: Include net/dst.h for struct dst_cache

ccing cxgb3i driver maitainer.

Herbert Xu wrote:
> Hi:
> 
> [SCSI] cxgb3i: Include net/dst.h for struct dst_cache
> 
> This driver needs dst_cache->dev so it should include net/dst.h
> to ensure that it builds.  While net/tcp.h probably includes it
> already, we shouldn't rely on that since there is no guarantee
> that this won't change in future.
> 
> Signed-off-by: Herbert Xu <herbert <at> gondor.apana.org.au>
> 
> diff --git a/drivers/scsi/cxgb3i/cxgb3i_iscsi.c b/drivers/scsi/cxgb3i/cxgb3i_iscsi.c
> index 9212400..8b49731 100644
> --- a/drivers/scsi/cxgb3i/cxgb3i_iscsi.c
> +++ b/drivers/scsi/cxgb3i/cxgb3i_iscsi.c
>  <at>  <at>  -13,6 +13,7  <at>  <at> 
>  
>  #include <linux/inet.h>
>  #include <linux/crypto.h>
> +#include <net/dst.h>
>  #include <net/tcp.h>
>  #include <scsi/scsi_cmnd.h>
>  #include <scsi/scsi_device.h>
> 

Looks ok.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Miller | 1 Jun 2009 06:51
Favicon

Re: [PATCH net-next]atl1c: fix spelling error

From: <jie.yang <at> atheros.com>
Date: Mon, 1 Jun 2009 10:07:58 +0800

> Fix spelling error
> 
> Signed-off-by: Jie Yang <jie.yang <at> atheros.com>
 ...
>  <at>  <at>  -1115,7 +1115,7  <at>  <at>  static int atl1c_stop_mac(struct atl1c_hw *hw)
>  
>  	AT_READ_REG(hw, REG_TXQ_CTRL, &data);
>  	data &= ~TXQ_CTRL_EN;
> -	AT_WRITE_REG(hw, REG_TWSI_CTRL, data);
> +	AT_WRITE_REG(hw, REG_TXQ_CTRL, data);
>  
>  	for (timeout = 0; timeout < AT_HW_MAX_IDLE_DELAY; timeout++) {
>  		AT_READ_REG(hw, REG_IDLE_STATUS, &data);

A spelling error would occur on human language text.

That's not what this is.

The code is referring to the wrong register, so it's a bug not a
spelling error.

Please fix your commit message and resubmit.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Miller | 1 Jun 2009 06:58
Favicon

Re: 2.6.30rc7: ksoftirqd CPU saturation (x86-64 only, not x86-32) (e1000e-related?)

From: Nix <nix <at> esperi.org.uk>
Date: Mon, 01 Jun 2009 01:16:26 +0100

> I plan to try out 2.6.29 (and back to 2.6.25 or thereabouts) tomorrow
> and see if it ever worked: if it did I'll bisect for it (rendered tricky
> by the out-of-tree e1000e driver, but doable: it would be easier if I
> had a clue where the e1000-devel git tree is, if anywhere, but I still
> have no idea despite considerable searching).

Why are you using the out-of-tree e1000e driver?  What's wrong
with the one in the tree? :-)

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
Permalink | Reply | 0 comments |
headers
Jarek Poplawski | 1 Jun 2009 08:06
Picon

Re: [BUG] net_cls: Panic occured when net_cls subsystem use

On Sun, May 31, 2009 at 07:40:16PM -0400, jamal wrote:
> On Sun, 2009-05-31 at 21:55 +0200, Jarek Poplawski wrote:
> 
> > But then, there could be "tc filter replace" with only this
> > (n->nlmsg_type == RTM_NEWTFILTER && (n->nlmsg_flags&(NLM_F_CREATE)))
> > which can't get here with a newly created tp, I guess.
> 
> Right - because in that case tp would already exist and would
> be found in the lookup.

But how about that (of course extremely rude) case "tc filter replace"
is run with a new prio?

Thanks,
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Joe Perches | 1 Jun 2009 08:44

[PATCH] atl1c_main.c: add wait_for_idle routine

Slight refactoring of duplicated wait for idle checks
Spelling fix

Signed-off-by: Joe Perches <joe <at> perches.com>

diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index fc1092b..5d2c8f7 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
 <at>  <at>  -164,6 +164,24  <at>  <at>  static inline void atl1c_irq_reset(struct atl1c_adapter *adapter)
 }

 /*
+ * atl1c_wait_until_idle - wait up to AT_HW_MAX_IDLE_DELAY reads
+ * of the idle status register until the device is actually idle
+ */
+static u32 atl1c_wait_until_idle(struct atl1c_hw *hw)
+{
+	int timeout;
+	u32 data;
+
+	for (timeout = 0; timeout < AT_HW_MAX_IDLE_DELAY; timeout++) {
+		AT_READ_REG(hw, REG_IDLE_STATUS, &data);
+		if ((data & IDLE_STATUS_MASK) == 0)
+			return 0;
+		msleep(1);
+	}
+	return data;
+}
+
(Continue reading)

Permalink | Reply | 2 comments |

Gmane